Category Archives: hp

Voice VLANs on HP Networking

In order to configure voice vlans, we need to play around with trunks and vlan tags. However, one may be surprised to find that on H3C HP hardware, there are three port link types:

  • Access
  • Trunk
  • Hybrid

So what on earth is a hybrid port? In order to answer that question, it is necessary to point out that VLAN classification of frames/packets can be based on the following:

  • Port-based
  • MAC address-based
  • Protocol-based
  • IP-subnet-based
  • Policy-based
  • Other types

Normally, everything happens on port level – depending on the VLAN access port setup, traffic entering a certain port will get classified into the correct VLAN.

A Hybrid port is  a port that can belong to multiple VLANs, can receive or send packets for multiple VLANs, used to connect either user or network devices.

That basically means that a hybrid port can do almost whatever you want it to do. For example, you can assign the port to appear as an access port to a specific MAC address, while still functioning as a trunk, while having a native vlan for untagged traffic. Also, a hybrid port can function as a trunk port with a native vlan.

So, in a nutshell, in order to configure your regular port with tagged vlan for VoIP phones + access vlan for the PC, you can either choose the classic method, or use a hybrid port. Since I presume everybody knows how to do it the old-fashioned way, let us configure it using a hybrid port.

So, what do we need for an IP phone and a PC? A tagged vlan for the Voice packets and an access vlan for the PC. Let us assume that vlan 102 is the Voice vlan, and vlan 7 is the PC vlan.

[HP-KC51-V] interface GigabitEthernet1/0/1
[HP-KC51-V-GigabitEthernet1/0/1] port link-type hybrid
[HP-KC51-V-GigabitEthernet1/0/1] port hybrid pvid vlan 7
[HP-KC51-V-GigabitEthernet1/0/1] port hybrid vlan 102 tagged
Please wait... Done.

[HP-KC51-V-GigabitEthernet1/0/1] stp edged-port enable
Warning: Edge port should only be connected to terminal. It will cause temporary loops if port GigabitEthernet1/0/1 is connected to bridges. Please use it carefully!

[HP-KC51-V-GigabitEthernet1/0/1] poe enable
#May 11 13:38:28:863 2000 HP-KC51-V POE/1/PSE_PORT_ON_OFF_CHANGE:
Trap 1.3.6.1.2.1.105.0.1: PSE ID 4, IfIndex 9437185, Detection Status 3.
#May 11 13:38:30:978 2000 HP-KC51-V IFNET/4/INTERFACE UPDOWN:
Trap 1.3.6.1.6.3.1.1.5.4: Interface 9437185 is Up, ifAdminStatus is 1, ifOperStatus is 1
#May 11 13:38:31:169 2000 HP-KC51-V MSTP/1/PFWD: hwPortMstiStateForwarding: Instance 0's Port 0.9437185 has been set to forwarding state!
%May 11 13:38:31:525 2000 HP-KC51-V IFNET/3/LINK_UPDOWN: GigabitEthernet1/0/1 link status is UP.
%May 11 13:38:31:650 2000 HP-KC51-V MSTP/6/MSTP_FORWARDING: Instance 0's GigabitEthernet1/0/1 has been set to forwarding state.

Of course, we enable stp edged-port (the portfast equivalent), as well as the PoE power for the IP phone. Let us inspect the configuration so far:

[HP-KC51-V-GigabitEthernet1/0/1]display this
#
interface GigabitEthernet1/0/1
port link-type hybrid
port hybrid vlan 102 tagged
port hybrid vlan 1 untagged
port hybrid pvid vlan 7
poe enable
stp edged-port enable
#
return

After inspecting the configuration we can observe that VLAN 1 is still permitted as an untagged vlan. However, the PVID (port vlan id), is set to 7. This may be confusing, so let’s elaborate. The untagged 1 VLAN means that the switch will pass traffic (e.g. broadcasts) from VLAN 1 down this port. The PVID of 7 means that when the switch receives untagged traffic, it will place in in VLAN 7.

Because most device management interfaces are assigned to VLAN 1, it is not a good idea to keep the port a part of this VLAN. So, let us remove the untagged VLAN 1 from the hybrid port.

[HP-KC51-V-GigabitEthernet1/0/1]undo port hybrid vlan 1
Please wait... Done.

[HP-KC51-V-GigabitEthernet1/0/1]display this
#
interface GigabitEthernet1/0/1
port link-type hybrid
undo port hybrid vlan 1
port hybrid vlan 102 tagged
port hybrid pvid vlan 7
poe enable
stp edged-port enable
#
return

Now the port is configured. There, wasn’t that difficult, right? 🙂

Advertisements

Upgrade firmware and bootrom on HP A5120

A simple software upgrade of an HP A5120 EI switch is explained in the following post.

The device software includes the Boot ROM program and the system boot file. After powered on, the device runs the Boot ROM program, initializes the hardware, and displays the hardware information. Then the device runs the boot file. The boot file provides drivers and adaption for hardware, and implements service features. The Boot ROM program and system boot file are required for the startup and running of a device.

NOTE: Regarding commands on the device, the BootROM is called bootrom, while the boot file is called boot-loader. So boot-loader and boot file are interchangeable in context, but not in syntax.

The Boot ROM program and system boot file can both be upgraded at the Boot ROM menu or at the command line interface (CLI). We will perform this upgrade by the command line this time.

dis ver
HP Comware Platform Software
Comware Software, Version 5.20, Release 2208
Copyright (c) 2010-2011 Hewlett-Packard Development Company, L.P.
HP A5120-48G EI Switch with 2 Interface Slots uptime is 0 week, 0 day, 17 hours, 56 minutes
HP A5120-48G EI Switch with 2 Interface Slots with 1 Processor
128M bytes SDRAM
16384K bytes Flash Memory
Hardware Version is REV.B
CPLD Version is 007
Bootrom Version is 607
[SubSlot 0] 48GE+4SFP Hardware Version is REV.B

This is the output of the “display version” command before the updates take place. Now, on to the real update – first, enable the bootrom security check. This should help you in case you try to update your device with a wrong boot file, but do not rely too much on it. After all, we should know what we’re doing in the first place 🙂

system-view
[HP]bootrom-update security check enable
[HP]quit

tftp [tftp server IP] get A5120EI-BTM-610.btm
 ...
File will be transferred in binary mode
Downloading file from remote TFTP server, please wait...\
TFTP: 0 bytes received in 0 second(s)
File downloaded successfully.

bootrom update file flash:/a5120ei-btm-610.btm slot 1
This command will update bootrom file on the specified board(s), Continue? [Y/N]:y
Now updating bootrom, please wait...
Succeeded to update bootrom of Board 1.

We have successfully updated the bootrom, by downloading the new file from a TFTP server. I will cover more on TFTP servers in a future blogpost.

Due to the insufficient space on the device, the current boot loader file needs to be deleted before the new one is uploaded. That is an interesting situation, where the device is left running with its boot loader in the RAM. Do not reboot the device before setting up the new boot loader or recovery steps will need to be taken.

The /unreserved parameter deletes the file from memory, as opposed to only moving it to the “Recycle Bin”. While in the Bin, the file will still take up space, hence the need for the complete removal.

delete /unreserved flash:/a5120ei-cmw520-r2208-s168.bin
The contents cannot be restored!!! Delete flash:/a5120ei-cmw520-r2208-s168.bin?[Y/N]:y
Deleting a file permanently will take a long time. Please wait...
.................................................................................................
%Delete file flash:/a5120ei-cmw520-r2208-s168.bin...Done.

tftp 192.168.15.39 get A5120EI-CMW520-R2215.bin
..
File will be transferred in binary mode
Downloading file from remote TFTP server, please wait......................................................................................................................................................................................................
TFTP: 12625865 bytes received in 198 second(s)
File downloaded successfully.

We are successful so far. Now, instruct the device to select the new boot-loader file. After that, verify that the new boot-loader will get loaded on the next reboot with the command “display boot-loader”. Do not forget to save the configuration before reloading, as missing that may make your device unbootable, and you may have to manually point to the new boot-loader again, from the bootrom (which means that you will incur downtime and would need physical access to the device – a nasty situation if you’re doing this from afar).

boot-loader file flash:/a5120ei-cmw520-r2215.bin slot 1 main
This command will set the boot file of the specified board. Continue? [Y/N]:y
The specified file will be used as the main boot file at the next reboot on slot 1!
display boot-loader
Slot 1
The current boot app is: flash:/a5120ei-cmw520-r2208-s168.bin
The main boot app is: flash:/a5120ei-cmw520-r2215.bin
The backup boot app is: flash:/
save main force
Validating file. Please wait......................
Saved the current configuration to mainboard device successfully.
Configuration is saved to device successfully.
reboot
Start to check configuration with next startup configuration file, please wait.........DONE!
This command will reboot the device. Continue? [Y/N]:y

After the reboot, check out the new version of both the bootrom and the boot-loader.

dis ver
HP Comware Platform Software
Comware Software, Version 5.20.99, Release 2215
Copyright (c) 2010-2012 Hewlett-Packard Development Company, L.P.
HP A5120-48G EI Switch with 2 Interface Slots uptime is 0 week, 0 day, 0 hour, 2 minutes
HP A5120-48G EI Switch with 2 Interface Slots with 1 Processor
128M bytes SDRAM
16384K bytes Flash Memory
Hardware Version is REV.B
CPLD Version is 007
Bootrom Version is 610
[SubSlot 0] 48GE+4SFP Hardware Version is REV.B

Always be very careful if doing this procedure remotely, backup both bootroms and bootloaders, as well as configuration files.
Never update the device during non-maintenance windows, and always be ready for the worst – which may very well be the need to physically access the device.

If the update takes place on an IRF system stack, you may speed up the procedure by enabling automatic boot-loader update during the stack formation, then updating only the master of the stack, and then rebooting the slave members.

By having the auto-update enabled, the slave members will download the new boot-loader from the master right after they have formed their neighborship. This way, you will only have to update a single device.

HP ExpertONE Certifications Update

Since the 1st of November, HP did a couple of changes to its ExpertONE certifications portfolio.

The big change consists of two tracks of certifications, namely Carrer and Affiliate, with the latter being mainly about sales.

There are also changes to the certificate titles. Here’s a map:

  • Master level -> HP Master ASE
  • Expert level -> HP ASE (CSE)
  • Professional level -> HP ATP (CSA, AIS)
  • Associate level -> HP ATA

Not much to be excited about, except for the fact that these certifications will expire, unlike their old counterparts. Even the old certifications will expire, but HP will shed more light on this matter in 2012.

More information here.

Don’t forget to check out the pdf brochure as well.

Dynamic WAN failover with IP SLA ICMP test on HP Networking

Recently I had to make use of the SLA service in order for a border router to choose between two identical service providers’ uplinks for backup reasons. The goal was to ping a specific IP, and should the ping fail (N amount of times), switch to the other provider.

The setup consisted of the HP MSR920 Router, and two uplinks to the ISPs. In case any of you are wondering, this device is a rebranded H3C MSR920.

For the sake of simplicity, let’s say that we’re connected to ISP1 via gateway 192.168.1.1 and interface eth0/0, and to ISP2 via gateway 192.168.2.1 and interface eth0/1.

First, we have to create the specific Network Quality Analyzer (NQA) entries, which resemble profiles of test and actions to be taken. You can read more about it here.

nqa entry admin one
type icmp-echo
destination ip 192.168.1.1
frequency 1500
history-record enable
reaction 1 checked-element probe-fail threshold-type consecutive 1 action-type trigger-only
source interface Ethernet0/0
ttl 255

nqa entry admin two
type icmp-echo
destination ip 192.168.2.1
frequency 1500
history-record enable
probe timeout 500
reaction 1 checked-element probe-fail threshold-type consecutive 1 action-type trigger-only
source interface Ethernet0/1
ttl 255

While it seems pretty self-explanatory, there are some pitfalls in this configuration. First, the entries are categorized by 2 strings, with the first being the admin entry, and the second the name entry. This way, admin John may have test called ISP1Ping, and admin Jack may also have a test called ISP1Ping. It seems to me that it’s a bit of overkill to use a two-dimensional array for the tests, but anyway. In my case, there is a single admin, so we’ll name the first parameter just “admin”, and the second – “one” and “two”.

There can be multiple types of tests: UDP echo, UDP jitter, UDP, VoIP, TCP, HTTP, FTP (some of them need a special NQA server at the other end). We will just use the ICMP-Echo test. We set up the destination IP, the frequency between pings in milliseconds, and we enable keeping history of the probes’ success. It is a good idea to measure the average time pings take to obtain a reply from your test verification destination, and then make the test’s icmp timeout value to be 1.3 or 1.5 times the needed trip time. There is no need to wait 2 seconds for an icmp timeout, if we know the trip takes only 20msec. On the second ISP, we set the timeout to 500msec, as we know that the icmp echo test takes 100msec for a reply.

(WARNING) The reaction command was stripped in the current version of the device, so you could only trigger the reaction, or not (effectively disabling the whole test scenario). This is important, as if there is no trigger-only statement, your tests will not alert the so-called tracker, that I’ll be explaining about in a minute.

We source the test from the specific interface for the current ISP.
(WARNING) We also set the TTL to maximum value. The default value on the current device was 20. As you notice, sometimes that might just not be enough to reach your testing destination.

track 1 nqa entry admin one reaction 1
track 2 nqa entry admin two reaction 1

Now we piece together the tests with the respective reaction. Notice that there can be multiple reactions defined for a test, and you can choose which one to associate with the tracker. It’s time to associate the trackers with something.

ip route-static 0.0.0.0 0.0.0.0 192.168.1.1 track 1 preference 150
ip route-static 0.0.0.0 0.0.0.0 192.168.2.1 track 2 preference 100

As you can see, we define two static default routes to both ISPs. We associate each route with its respective track entry. The preference value is used to prefer one router over the other – for example, if ISP1 is a fast fiber optic, while ISP2 runs on a backup ADSL line. This way, if ISP1 goes down, when it comes back up – it’ll override the default route to ISP2. Just remember that the lower the preference metric – the better, with 60 being the default metric for static routes.

nqa schedule admin one start-time now lifetime forever
nqa schedule admin two start-time now lifetime forever

We schedule our test to run as soon as we enter the commands (or as soon as the device starts) and to last forever. If you need to use the fail-over on specific times of day – you can define them here.

What have we achieved so far:

  • We have two default routes that are tracked by the NQA. One of them has a higher preference, and gets installed in the routing table by default.
  • As soon as the ICMP test fail, the NQA alerts the specific tracker, which brings down the failing default route.
  • As soon as the ICMP test succeeds, the NQA alerts the specific tracker, which brings up the failed default route.
  • If both routes are up, the one with the bigger preference is used
  • However, what if both routes are down?

    • None of the static default routes is present in the routing table
    • The device keeps on testing the links as we have explicitly set the output interfaces

  • Whichever ping test succeeds first, it will bring up a static route with a higher preference that any automatic default route. We have restored preferred connectivity.

That’s about all for the ICMP Echo part of HP’s Network Quality Analyser (or should we say H3C’s NQA?). Some complex scenarios can be created, but they do require a special NQA responder on the other end of the testing. Hopefully, I’ll cover them in the future. Thanks for reading, and have fun with networking!

Edit (Apr/2013): Corrected static route preference metrics thanks to Alisson Curunzi