Network – VMFocus

Load Balancing Horizon View – Failure Testing

Posted on 21 January 201411 January 2021 by Craig

In the last post Load Balancing Horizon View – Design we looked at the differences between DNS Round Robin, Windows Network Load Balancing and Load Balancers and the design concepts for internal and external use.

In this post we will focus on testing failure scenarios to understand the impact of various components failing within a design.

Lab Setup

The Horizon View environment is configured as follows:

2 x NetScaler VPX-Express in High Availability
2 x Horizon View Security Servers
2 x Horizon View Connection Servers

For the NetScaler configuration I followed the excellent Load Balancing VMware View with NetScaler guide by Dale Scriven who runs the blog vhorizon.co.uk. The only addition to this was an additional TCP Service group for 8443 (HTML5).

In the interests of sharing the configuration, below are extracts from each area.

Internal Logical Design

External Logical Design

vSphere Web Client

Horizon View Administrator

NetScaler VPX-Express Admin

Internal Connection Server Failure Scenario – Secure Gateway/Connection Unticked

I will have a two connections to my Desktop Pool, both via View Client.

Table to Show Expected Results – Internal Connection Server Failure – Secure Gateway/Connection Unticked

Criteria	Expected Result	Recovery Time
Connection Server Power Off	Desktop remains connected	n/a
Connection Server Shut Down	Desktop remains connected	n/a
NetScaler VPX-Express Power Off	Desktop remains connected	n/a
NetScaler VPX-Express Shut Down	Desktop remains connected	n/a

Table to Show Actual Results – Internal Connection Server Failure – Secure Gateway/Connection Unticked

Criteria	Actual Result	Recovery Time
Connection Server Power Off	Desktop remains connected	n/a
Connection Server Shut Down	Desktop remains connected	n/a
NetScaler VPX-Express Power Off	Desktop remains connected	n/a
NetScaler VPX-Express Shut Down	Desktop remains connected	n/a

Not much to say really, everything performed as expected.

Internal Connection Server Failure Scenario – Secure Gateway/Connection Ticked

Again, I will have a two connections to my Desktop Pool, both via View Client.

Table to Show Expected Results – Internal Connection Server Failure – Secure Gateway/Connection Ticked

Criteria	Expected Result	Recovery Time
Connection Server Power Off	Desktop session disconnect, then manual reconnect	20 seconds
Connection Server Shut Down	Desktop session disconnect, then manual reconnect	25 seconds
NetScaler VPX-Express Power Off	Desktop session disconnect, then manual reconnect	20 seconds
NetScaler VPX-Express Shut Down	Desktop session disconnect, then manual reconnect	25 seconds

Table to Show Actual Results – Internal Connection Server Failure – Secure Gateway/Connection Ticked

Criteria	Actual Result	Recovery Time
Connection Server Power Off	Desktop session disconnected after 2 seconds, manual reconnect	28 seconds to be logged back into desktop
Connection Server Shut Down	Desktop session disconnected after 4 seconds, manual reconnect	35 seconds to be logged back into desktop
NetScaler VPX-Express Power Off	Desktop session disconnected after 5 seconds, manual reconnect	33 seconds to be logged back into desktop
NetScaler VPX-Express Shut Down	Desktop session disconnected after 9 seconds, manual reconnect	41 seconds to be logged back into desktop

The Citrix NetScaler VPX offer high availability for the sharing of configuration and virtual IP address. They do not provide no session loss between appliance failure.

External Failure Scenario Expected Results

I will have a three connections to my Desktop Pool, two via View Client, one via Blast (HTML5) and the last via View Client. The Horizon View Administrator will be checked before each test to see which Security Server has the heaviest load and this one will form the test.

After each test Horizon View Administrator will be checked to find which Security Server has the heaviest load to perform the next test.

Criteria	Expected Result	Recovery Time
Security Server Power Off	Desktop session disconnect, then manual reconnect	40 seconds
Security Server Shut Down	Desktop session disconnect, then manual reconnect	40 seconds
Connection Server Power Off	Desktop session disconnect, then manual reconnect	40 seconds
Connection Server Shut Down	Desktop session disconnect, then manual reconnect	40 seconds
NetScaler VPX-Express Power Off	Desktop session disconnect, then manual reconnect	60 seconds
NetScaler VPX-Express Shut Down	Desktop session disconnect, then manual reconnect	60 seconds

External Failure Scenario Actual Results

Criteria	Actual Result	Recovery Time
Security Server Power Off	Desktop session disconnected after 14 seconds, manual reconnect	52 seconds to be logged back into desktop
Security Server Shut Down	Desktop session disconnected after 12 seconds, manual reconnect	55 seconds to be logged back into desktop
Connection Server Power Off	Desktop session disconnected after 19 seconds, manual reconnect 109 seconds reconnected, black desktop background. Timeout message 134 seconds. Second reconnect, 252 seconds reconnected, black desktop background. Timeout message 283 seconds.	Loop via View Client. Can connect via Blast (HTML5) to desktop.
Connection Server Shut Down	Desktop session disconnected after 24 seconds, manual reconnect 118 seconds reconnected, black desktop background. Timeout message 141 seconds. Second manual reconnect, 276 seconds reconnected, black desktop background. Timeout message 301 seconds.	Loop via View Client. Can connect via Blast (HTML5) to desktop.
NetScaler VPX-Express Power Off	Desktop session disconnected after 4 seconds, manual reconnect	39 seconds to be logged back into desktop.
NetScaler VPX-Express Shut Down	Desktop session disconnected after 19 seconds, manual reconnect	57 seconds to be logged back into desktop.

When a View Client connects externally, the NetScaler VPX passes traffic to the least loaded Security Server. Remember a Security Server is bound to a single Connection Server and that ALL traffic is proxied via the Security Server.

When first Security Server fails you are disconnected (as expected). When the View Client is launched again the NetScaler VPX routes traffic via the secondary Security Server and the secondary Connection Server.

Everything OK NetScaler > Security Server 01 > Connection Server 01 > Desktop
Failed Security Server NetScaler > Security Server 01 > No Access To Connection Server 01
Reconnect NetScaler > Security Server 02 > Connection Server 02 > Desktop

What I found most interesting was the Connection Server failures. In this scenario, the Security Servers are up and a Connection Server goes down.

Trying to reconnect to via the View Client, enables you to authenticate successfully, but you receive a ‘black desktop screen’ and then a connection time out.

Looking at the connection status of the NetScaler VPX-Express services, only the HTTPS SSL Bridge to 443 on Security Server 01 is down and the rest of the services are up.

When the NetScaler VPX polls the Security Server on 443 HTTPS, 4172 TCP and 4172 UDP it sees that the PCoIP services on 4172 are up and tries to reconnect back to the original TCP session, due to the fact that our Persistency Group is Source IP and that we are connecting back over the same ports.

Connecting via Blast HTTPS 8443 works, I imagine this is due to a new TCP connection being established to Security Server02, which in turn connects via Connection Server 02 which is up.

Disconnecting from the Blast Desktop, I was able to reconnect to my desktop using View Client.

Final Word

Hopefully this post has gone someway to helping you understand the failure scenarios . Knowing what to expect is key as it allows you to set expectations to both the business and users.

Load Balancing Horizon View – Design

Posted on 14 January 201411 January 2021 by Craig

Load balancing Horizon View Connection and Security Servers is key to any VDI design, the ability to provide connectivity to a desktop internally or externally is a must. The bad news is that Horizon View doesn’t come with any inbuilt load balancing techniques.

As a Horizon View Architect, we have four options open to us:

Don’t Load Balance
Use DNS Round Robin
Use Windows Network Load Balancing
Use a Load Balancer

For the purpose of this blog post, I’m going to discount Option 1 as it’s self explanatory. To perform any type of load balancing you need to have two target Connection or Security Servers. Let’s explore the rest of the options.

DNS Round Robin

This is the simplest form of load balancing. Creation of two ‘A’ records pointing to different View Connection Servers.

When a client resolves view.vmfocus.com the DNS server will send both IP address’s to the client. The client will always use the first one returned e.g.

view.vmfocus.com 10.0.0.1 10.0.0.2

The DNS server is intelligent, so that when the next client resolves view.vmfocus.com the DNS server again sends both IP Address’s. However this time they are returned the other way round e.g.

view.vmfocus.com 10.0.0.2 10.0.0.1

DNS Round Robin Advantages

It’s simple and easy to configure

DNS Round Robin Disadvantages

Their is no monitoring of the Horizon View Connection Servers at any layer of the OSI model. If a Horizon View Connection server has an issue or is powered off for maintence, DNS Round Robin will continue to send client connections.
After the initial connection to the ‘A’ record view.vmfocus.com the client (local PC) caches the IP address that view.vmfocus.com resolves to. Only when the TTL expires will the client (local PC) go to the DNS server to request another record which may be the same as the first!

Windows Network Load Balancing

More intelligent than DNS Round Robin is Windows Network Load Balancing which operates at Layer 3 of the OSI model. A special driver is installed on each Windows host and a ‘cluster IP address’ is created.

When a client resolves view.vmfocus.com the Cluster will distribute the incoming connection to the appropriate Horizon View Connection Server, this can be configured on a weighted basis e.g.

View Connection Server 1 – 10
View Connection Server 2 – 90

Which means that 90% of the traffic will be directed to View Connection Server 2.

The servers in the cluster are rather chatty, exchanging heartbeat messages, if a server isn’t reached within five seconds it is failed and any new connections are sent to other surviving servers.

Windows Network Load Balancing Advantages

Load can be distributed between the Horizon View Connection Server members using a weighted average.
Support for up to 32 servers in a cluster
Add/Remove servers into the cluster for expansion/patching
Detect server failure at network level
Included as part of Windows Server 2003/2008/2012

Windows Network Load Balancing Disadvantages

Fairly complicated to configure and maintain
Extensive network considerations such as separate Port Groups/VLANs to reduce network heartbeat chatter plus MAC Address Changes and Forged Transmits have to enabled on your Port Groups that the NLB servers reside on
Is not Layer 4 or above (service awareness)

Load Balancer

Load balancers are the ‘numero uno’ when it comes to load balancing Horizon View, offering features such as health checking where a probe is sent to the Horizon View Connection Server on a number of service connections e.g. TCP probe on 443 to ensure service availability. Perhaps the greatest reason for load balancer use is to stop new connections going to Connection/Security Server whose services are down.

The user is disconnected from the desktop and then when they reconnect they go back to the same desktop.

Load Balancer Advantages

Service awareness, actively ‘polls’ the Horizon View services (PCoIP 4172 UDP, TCP and HTTPS) to ensure they are available
Protect against failure at LAN or WAN depending on chosen model and features
No session loss with failed components
Weight load to Horizon View Connection Servers based on different factors
Offload SSL, which can become a major part of the demand for Horizon View Connection Servers
Can offer firewall features such as DDoS and IPS depending on chosen model and features
Can be used in Global Server Load Balancing configuration to protect from WAN failures (note that Desktop Pools should not spam more than one physical location due to Java Message Service requirements, see this excellent post by Simon Long)

Load Balance Disadvantages

Expensive!
Need to purchase at least two otherwise you have no high availability
Configuring can be complicated, if no ‘Horizon View’ templates are available

Horizon View Design

The purpose of this blog post was to consider the design for load balancing for Horizon View. Now that we have covered the techniques that can be used, we need to consider the requirements:

Is redundancy required?
What network throughput is required?
Can users access their desktop remotely? If so by Blast and View Client?
Can users access their desktop internally by Blast?
How will routing maintenance be undertaken?
How will upgrades be undertaken?
Is Smart Card authentication required?
Is Two Factor authentication required?
Is a Secure Connection required to the desktop?

These are some off the questions that will influence your Horizon View design. A common question is: ‘How do we govern who has access to their desktops internally and externally?’ This can only be achieved by having ‘Connection Server Tags’. Connection Server Tags are a unique reference from a desktop pool to a Connection Server to allow manipulation of desktop pool variables. Let’s work over a scenario, different users require internal and external access. To achieve this we would need at minimum:

One Security Server for remote access
One Connection Server for internal access tagged ‘internal’
One Connection Server for external access tagged ‘external’
One Desktop Pool for internal users with Connection Server restriction to ‘internal’
One Desktop Pool for external users Connection Server restriction to ‘internal and external

In reality you probably wouldn’t design for the above scenario due the single point of failures. The design below is what I would expect to see as a minimum.

Note: You need 4 x Load Balancers in this design.

Key Concept

Secure Tunnel/Gateway connection to desktop for HTTP(S) and PCoIP are key to the expected results you will achieve on your load balancing design.

HTTP(S) Secure Tunnel, PCoIP Secure Gateway & Blast Secure Gateway unticked

The connection from the View Client goes to the Connection Server, authentication is achieved and the desktop is loaded. The connection from the View Client is then established DIRECTLY to the View Desktop bypassing the View Connection Server.

Step 1 (Login to Desktop) View Client > Connection Server > View Desktop
Step 2 (Logged into Dekstop) View Client > View Desktop

In this design your Connection Servers are only required for the login, after this they become redundant. Considerations for this design:

Communications are not secure between View Client and View Desktop
Can only be used for LAN connections, Security Server requirement is to have Secure Connection/Gateway enabled (ticked).
Consider using for a design when requirement is to have desktop ‘always on’ with no disconnect if a Connection Server fails.

HTTP(S) Secure Tunnel, PCoIP Secure Gateway & Blast Secure Gateway ticked

The connection from the View Client goes to the Connection Server, authentication is achieved and the desktop is loaded. The connection from the View Client is then always PROXIED via the Connection Server to the View Desktop.

Step 1 (Login to Desktop) View Client > Connection Server > View Desktop
Step 2 (Logged into Dekstop) View Client > Connection Server > View Desktop

This can be confirmed in the View Administrator Portal be selecting Remote Sessions and you will see the Secure Gateway the desktop connection is using.

In this design your Connection Servers are always required. Considerations for this design:

Communications are secure between View Client and View Desktop
Requirement to use Security Servers (your View Client will connect and authenticate successfully, however you will see a black desktop background then a disconnect).
If you loose the Connection/Security Server, the user will be disconnected and will need to reconnect.

Basic Principles

The fundamentals of a Horizon View Load Balancing Design are driven by the requirements from the customer. The basic principles that need to be followed are:

Security Server to Connection Server is a 1 – 1 relationship.
Two Factor & Smart Card Authentication are at Connection Server level
Internal and external access control is governed by Connection Server ‘Tags’
Differences between Pool Settings require different Desktop Pools (obvious eh?)
Desktop session will always get disconnected if using Secure Connection/Gateway

In the next blog post, I will look at Horizon View Load Balancing Failure Scenarios so that you know what results to expect.

How To Configure Access Lists & Route Between VLAN’s On HP v1910 24G

Posted on 14 October 201211 January 2021 by Craig

In the previous how to, we configured layer 3 static routes and VLAN’s on the HP v1910 24G you will have noticed that all traffic can pass between VLAN’s without any restrictions. So why is this happening?

Well the answer is because we have turned on routing by giving an IP Address to each VLAN. This means the HP v1910 uses it’s own routing table to send traffic from VLAN 1 to VLAN 10.

Let’s test this. My laptop sits on VLAN 1 on IP Address 192.168.37.152 using the HP v1910G as it’s default gateway on 192.168.37.221

I have five VLAN Interfaces created which can be found under Network > VLAN Interface > Summary

Behind VLAN 10 is a device with IP Address 10.37.10.11, which I can ping

Next, I’m going to remove the VLAN Interface for VLAN 10

Don’t worry, the VLAN is still in play, we just have removed the ability to route between subnets. Now if we ping the same device we get an epic fail.

Notice we get a reply from 192.168.37.254 which isn’t an VLAN IP Address. The reason for this is that 192.168.37.254 is the default gateway for our HP v1910G. The HP v1910G is saying I haven’t got a clue how to get to 10.37.10.11, so let me send that traffic to my default gateway 192.168.37.254.

My firewall which is on 192.168.37.254 has a static route to 10.37.10.0 255.255.255.0 via 192.168.37.221 (VLAN 1 Interface on HP v1910G). When the HP v1910G receives the packet, it drops it as has no where to send the ICMP request.

So just to reiterate, that when we have an VLAN Interface, the HP v1910G will be able to route all traffic between VLAN’s, unless we do something about it.

Access Lists

This is where the Access List comes into play, an Access List specifies what source traffic is allowed to get to what destination traffic. Think of it as being in a hallway in a house and all the doors are locked. You then get given a key and you can get from the hallway into the lounge. The source is the hallway, the destination is the lounge and the key is the Access List.

So before we move any further, I want to give you a brief explanation of what I want to be able to achieve.

My laptop resides on 192.168.37.152/24 on VLAN 1 and I want to be able to connect to my HP StoreVirtual VSA which is on 10.37.20.1/24 VLAN 20.

I also have a Windows 7 machine on 10.37.20.211/24 VLAN 20.

I want to be able to get from my laptop to 10.37.20.1, but I don’t want to let any other traffic threw.

Let’s run a ping to both devices, you can see that I have connectivity to both 10.37.20.1 HP StoreVirtual VSA and 10.37.20.221 Windows 7.

So let’s create an Access List to do something about this.

Creating An Access List

We need to go to QoS from the left hand menu then onto ACL IPv4

Next we want to select Create

Now we have a choice from Basic ACL’s, Advanced ACL’s and Ethernet Frame Header ACL’s. OK what are the differences?

Basic ACL these only match source IPv4 address’s

Advanced ACL these match source and destination IPv4 address’s and also protocols on different port numbers e.g. TCP 80

Ethernet Frame Header ACL these match source and destination MAC addresses

With this is in mind, we are going to use Advanced ACL’s as we want to match interesting traffic from source to destination.

In the ACL Number section, type in 3001 and we want the match order to be Config and click Apply

You will see the ACL Number appear in the bottom table, notice we have no rules applied against it yet.

Next we want to go onto the Advanced Setup Tab at the top. We are going to enter the following information:

ACL > Select 3001
Rule ID > Select and Enter 10
Action > Permit
Source IP Address > 192.168.37.152
Source Wildcard > 0.0.0.0
Destination IP Address > 10.37.20.1
Destination Wildcard > 0.0.0.0
Protocol > IP
Click Add

Now when you click on the Summary Tab you should see your rule in place!

I want to back track slightly on some of the entries we made into the Advanced ACL, to make sure you are clear on what we did.

Rule ID this is the order in which the rules are read we entered in number 10, so this rule is read first, if you added a rule ID 9 this would get read before rule ID 10.

Wildcard this is the reverse of a normal subnet mask e.g. 255.255.255.0 becomes 0.0.0.255

TOP TIP: At the end of every Access List is always a silent deny, which means you don’t see the traffic being dropped it just happens!

Let’s see if it works shall we? Let’s ping from my laptop to a HP StoreVirtual VSA 10.37.20.1 success, what about the Windows 7 on 10.37.20.211, err also success, that’s not right!

So what the heck is going on? Well as we haven’t applied the ACL3001 to an interface, everything carries on as per normal.

To be honest, applying an Access List to an interface on the HP v1910G is a royal pain. For most switches you just choose to apply the ACL to an interface either inbound or outbound. However, on the HP v1910G you have to perform the following:

Create a QoS Classifier
Create a QoS Behavior
Create a QoS Policy using the QoS Classifier and QoS Behavior
Apply the QoS Policy to a Port

I’m not going to run through how to do this, as examples can be found in the HP v1910G Manual page 465.

How To Configure Layer 3 Static Routes & VLAN’s On HP v1910 24G

Posted on 26 September 201211 January 2021 by Craig

In the last how to, we performed the firmware upgrade and initial configuration on the HP v1910 24G.

It’s now time to start placing some VLAN’s onto our switch. A good starting point is why do we use VLAN’s?

Well a VLAN enables us to:

Logically segment a switch into smaller switches, much same way that ESXi allows you to run multiple virtual machines on the same physical hardware.
Create logical boundaries so that traffic from one VLAN to another VLAN is permitted or not permitted e.g. User VLAN accessing Server VLAN.
Reduce the broadcast domains, in the same way that a switch creates a separate collision domain for each device plugged into it. A VLAN reduces the ARP broadcasts sent out.

Before we move any further, we need to understand what purpose the VLAN’s will serve in our environment and what they will be assigned too. For me, it’s quite straight forward, the HP v1910 will be used as my main home lab switch and as such I need a VLAN for the following purposes:

Management
iSCSI
vMotion
Backup
HP Fail Over Manager

With this in mind, I would highly recommend creating a network table containing your VLAN Names, VLAN ID, Subnet and Switch IP Address. You may ask why do you bother? Well I deal with large number of clients infrastructure and I often find that I get confused as what subnet’s are doing what!

You will notice that I have assigned an IP address to the switch on every VLAN. The reason for this is the HP v1910 can also do layer 3 static routing so in my home environment the switch is the default gateway as well.

Layer 3 Static Routes

OK, lets login to the HP v1910 24G using the IP address and username/password we assigned previously.

Why use layer 3 static routes? Well I want to be able to route between VLAN’s. This is critical for my HP Failover Manager (FOM VLAN) which needs to be in a logical third site to communicate with the HP Virtual Storage Appliance (iSCSI VLAN). For each device on each VLAN they will use the switch as there default gateway. This means that the network traffic will only leave the switch if it has a destination subnet for which it is not responsible e.g. the internet.

To do this, click on Network from the left hand panel then IPv4 Routing

Click Create in the Destination IP Address enter 0.0.0.0 Mask enter 0.0.0.0 Next Hop enter 192.168.37.254 Select Preference and enter 10

So what are we actually doing? Well we are saying to the switch for ‘any destination IP address’ and ‘any subnet’ send all that traffic to this router/firewall whose IP address is 192.168.37.254 (next hop).

Hopefully it should look something like this.

Cool, let’s test it. Change a computer to use the HP v1910 24G switch as it’s default gateway.

We should now be able to ping the switch, the switches next hop and also something out on the internet.

Boom, it’s all working, let’s move on!

VLAN Configuration

Hopefully, you have already decided on your VLAN configuration and IP address’s for the switch. So let’s crack on and start configuring.

Select Network from the left hand menu then VLAN and then Create

My first VLAN ID is 10, so we enter this and click Create to the left hand side. Next Modify the VLAN description from VLAN 0010 to iSCSI and then click Apply.

Rinse and repeat until you have entered all of your VLAN’s into the switch. Here’s one I made earlier.

TOP TIP, don’t forget to click Save in the top right hand corner on a regular basis.

Great, we have created the VLAN’s now we need to assign them to some switch ports. We need to understand what happens when we change the port characteristics. The options we have are:

Untagged – what ever device we plug into this switch port will automatically be placed into this VLAN. Commonly used for devices which are not VLAN aware (most desktops/laptops).
Tagged – if a device is VLAN aware and it has been assigned to a VLAN, when it is plugged into the switch port it won’t go into the Untagged VLAN, it will go into the Tagged VLAN (think IP phones)

As this switch is for my vSphere 5 environment and vSphere is VLAN aware. We are going to set every port to be Tagged into every VLAN. What will this achieve? Well every device which is not VLAN away will go straight into the Management VLAN. Then on the port group’s within the vSwitches I can assign VLAN’s.

To do this, click Network from the left hand menu, then VLAN and finally Modify Port

By default every port will be ‘untagged’ in VLAN 1 so we don’t need to make any modifications to this. Click Select All then Tagged and last of all Enter the VLAN ID’s in this case 10,20,30,40 and click Apply.

You will receive a pop up letting you know that Access Ports will change to Hybrid Ports, we are cool with this, so Click OK.

To verify the VLAN’s have been set correctly, go to Port Detail and choose Select All, it should show the following.

Assign An IP Address To Each VLAN

I mentioned earlier on in the post that we wanted to assign an IP address to each VLAN so that the HP v1910 24G becomes the default gateway for all devices. To do this select Network from the left hand menu, then VLAN interface and Create.

Now this is when I need to refer back to my network table! We input the VLAN ID e.g. 10 and then enter the IP Address e.g. 10.37.10.221 and Mask e.g. 255.255.255.0

I always deselect ‘Configure IPv6 Link Local Address’ then click Apply.

Rinse and repeat for the rest of your VLAN’s. To make sure everything is ‘tickety boo’ click on Summary and you should be greeted with a page similar to this.

Time to test. So from your computer you should now be able to ping each VLAN IP address on the switch.

Success, that’s our HP v1910 24G configured with VLAN’s.

How To Firmware Upgrade HP v1910 24G Switch & Initial Configuration

Posted on 22 September 201211 January 2021 by Craig

So, I finally have my lab all cabled and I have a few spare minutes to start the initial configuration of the vmFocus lab.

What do we do first? Well I always start with networking and making sure that my switch is running the latest firmware. OK, I do have one exception to this, when you check the manufacturer’s website, if you have release 8.9.5 and 9.0.0, I tend to stick with 8.9.5 as it should be more proven.

Anyway, back on topic, the HP v1910 24G switch is a beast for the money, some of it’s features are:

– Gigabit
– Layer 2 Managed
– Layer3 Static Routing with 32 routes
– Access Control Lists
– STP, RSTP and MSTP
– 802.3X Flow Control
– VLAN with 256 simultaneous
– Link Aggregation
– Lifetime Warranty

It should be a worthy addition to any home lab.

Firmware Upgrade

When I first opened up the switch, I was surprised by how light it was, but comparing this to Cisco’s which I work with on a daily basis (which cost 20x the amount) doesn’t seem fair.

The HP v1910 will pick up it’s IP address via DHCP, so depending on your environment, either check your DHCP servers newest address lease when you power it on or do a ping sweep of your network using something like IPScan

If you don’t have a DHCP server I would recommend using Antamedia DHCP Server, don’t worry it’s free.

Once you have located the IP address of the HP v1910 open up a web browser and type in the address. Which in my case is http://192.168.37.104. You should hopefully be greeted with this login screen:

I was quite surprised to see a ‘random’ text generator at the login screen but kudos to HP/3COM for the addition. The default username and password is:

Username admin
Password

Once logged in, it should look something like this:

We are going to navigate to Device on the left hand side and then onto Device Management:

Now it’s time to download the latest firmware from HP, at the time of writing this blog the most recent firmware is 1910_5.20.R1512P05 which can be found here. Select this and begin the download

After the download completes select choose file

Select ‘if a file with the same name already exist, overwrite it without any prompt and also ‘reboot after the upgrade is finished’

Click on apply. It will take approximately five minutes for the switch to come back up again, so go grab a cup of coffee before we move onto the next part.

Initial Setup

The first thing we are going to do is change the name of the switch, from HP, to do this select Device from the left hand column and then Basic. Then enter a new name in ‘sysname’. As you can see mine is named SW01 (very imaginative). Don’t forgot to click ‘apply’

System time is perhaps one of the most overlooked items for networks. I can’t stress how important this is, if you are trying to troubleshoot an error and the time stamps are 10-04-00 01:12, leaves you thinking when did the issue occur?

To setup select Device from the left hand column and then System Time and then Net Time.

In this example, we are using the Source Interface as VLAN 1, which is the default VLAN. Our external NTP Servers are:

0.vmware.pool.ntp.org – 31.170.110.148
1.vmware.pool.ntp.org – 46.227.200.71

Select you time zone and click apply, once done you should see Clock Status: synchronized.

Moving down the list we are going to change the password for the admin user, select Device from the left hand column then Users then Modify. Select admin tick Password Modify and then enter your new password

The last thing we are going to do is set a static IP address for the switch, we wouldn’t want to leave it on DHCP would we? To do this select Network from the left menu, then VLAN Interface, then Modify. Select Manual and enter the static IP address.

This may sound crazy, but before you click apply, write down the last octet of the static IP. You wouldn’t believe the amount of times I do this and the moment I click save/apply I get a phone call, colleague asking for help and I forget the damn thing.

Click apply and reconnect to the switch on the new IP address and with the password the admin user we applied earlier.

In the next ‘how to’ we are going to configure some VLAN’s.