Category Archives: Switching

Routallica – WAN / Metallica – One

Original song courtesy of Metallica
No copyright infringement intended, just having fun

Routallica – WAN

I can’t connect to anything
Can’t tell if this is routing or bridging
Deep down inside I want to ping
This terrible access-list stops me

Now that the routes are passed to me
Network is convergin, but I cannot see
And there are not many neighbors here
Nothing is up but loopbacks

Hold my frames as I wait for STP
Oh please, broadcasts, don’t storm me

Back in the WAN it’s much too serial
Terrible speeds that I must feel
But I look forward to police
Police those excess TCP bursts

Weighted RED is throttling me
Just like a greedy TCP stream
Class-based shaping’s buffering me
Dropping tokens from the bucket

Hold my updates as I split horizons
Oh please, RIP, route me

Now the network’s gone, I’m just one
Oh redundant link, help me
Split my brain as my peer faces death
Oh please, VSS, help me

VLANs imprisoning me
No adjacency
Asymmetric routing
I cannot ping
I cannot trace
Trapped in my shell
Subnet my holding cell

Black holes have poisoned my routes
Taken my ping
Taken my peering
Taken my ARPs
Taken my V(e)RFs
Taken my pools
Left me with Frame Relaaay


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 PSE ID 4, IfIndex 9437185, Detection Status 3.
#May 11 13:38:30:978 2000 HP-KC51-V IFNET/4/INTERFACE UPDOWN:
Trap 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

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

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

IRF on HP 5800

This is a quick primer on running IRF on a couple of HP 5800.

IRFv2 systems are connected using any 10GbE interface:

  • CX4
  • SFP+
  • XFP

A best practice of connecting IRF members is connecting them in a ring-like fashion. This guarantees that one link failure will not disrupt the stack. For example, if you have four devices, you should connect them like this: 1) – 2 – 3 – 4 – (1, with the first being connected to both the second and the fourth. Should the link between members 2 and 3 fail, what you’ll get is this 3-4-1-2.

Ok, enough of the theory. Let’s plug a couple of 10G SFP+ modules now.

%Apr 26 13:25:30:548 2000 HP OPTMOD/4/MODULE_IN: -Slot=2;
Ten-GigabitEthernet2/0/54: The transceiver is STACK_SFP_PLUS.


Now we proceed to configure basic stuff about the IRF stack:

System View: return to User View with Ctrl+Z.

irf domain [ID]

The domain ID is not necessary to match on the other members of the stack, but you should keep it the same for the sake of clarity later on.


Now we should renumber the IRF member ID if needed. To make more sense of this step, one should know that every IRF-enabled HP device assumes it is member number 1. That means that you should renumber every switch after the first one for the current stack. If two members have the same ID, they cannot form an IRF stack.

irf member 1 renumber [X]

In order for the renumbering to take place, the device should be reloaded. It is not necessary to save the configuration for the renumbering to take effect, but we should save it anyway. Issue a save, followed by a reboot and the device shall be renumbered.

Now it’s time we configured the logical IRF ports. Remember, an IRF port can be either a physical 10G port, or an aggregation group. In order to assign such a port to a logical IRF port, we should prepare the former first, by shutting it down. For example, we will use two physical 10G ports, namely Ten1/0/53 and Ten1/0/54.

interface Ten 1/0/53
interface Ten 1/0/54

Now the ports are ready to be assigned to the logical IRF ports. Remember, the logical IRF ports on a device are only 2, and they connect in a cross-link fashion, namely Port 1 on a device connects to Port 2 on the other and vice versa.

irf-port 1/1
port group interface Ten 1/0/53

irf-port 1/2
port group interface Ten 1/0/54

By now you should have noticed the bolded prefix 1 in front of some of the interface commands. This is the current chassis number, and by default it is one (1). The time you will notice its significance is when you move on to configuring the second, third and so-on device from the stack. Remember, changing the IRF Member ID will change the whole internal addressing of the current device. The port Ten 1/0/53 would become Ten 2/0/53 on the second member of the stack, the IRF logical ports would become irf-port 2/1 and irf-port 2/2, and so on.

The same principle applies backwards, when you have an operating stack, and you renumber a device/chassis. Say, you renumber 2 to 3 and 3 to 2. What would happen is that when they get rebooted, they would download the configuration from the master switch, and end up with “exchanged” configurations from each other.

This seems like a good time to introduce the Master/Slave concepts of IRF. Basically, there is a priority value that plays an important role in the election, but there are a couple of pitfalls too. Let’s see what the process is:

Master election is held each time the topology changes, for example, when the IRF virtual device is established, a new member switch is plugged in, the master switch fails or is removed, or the partitioned IRF virtual devices merge. The master is elected based on the following rules in descending order:

  1. The current master, even if a new member has a higher priority. (When an IRF virtual device is being formed, all member switches consider themselves as the master, and this rule is skipped). If an election is held, and the current topology has 2 masters and N slaves, election is heldonly between the current 2 masters.
  2. The switch with a higher priority.
  3. The switch with the longest system up-time. (The member switches exchange system up-time in the IRF hello packets)
  4. The switch with the lowest bridge MAC address.

After a master election, all slave member switches initialize and reboot with the configuration on the master, and their original configuration, even if has been saved, will be lost.

Phew, I got carried away. Now that we have set up the logical IRF ports, we can bring back up the physical ports they comprise.

interface Ten 1/0/53
undo shutdown
%Apr 26 13:28:46:723 2000 HP IFNET/3/LINK_UPDOWN: Ten-GigabitEthernet1/0/53 link status is UP.

interface Ten 1/0/54
undo shutdown
%Apr 26 13:28:46:723 2000 HP IFNET/3/LINK_UPDOWN: Ten-GigabitEthernet1/0/54 link status is UP.

Save the configuration now! The next command will cause the device to reboot, and lose all unsaved changes.

Just to illustrate a point, issue a display irf topology. If you have any ports in the DISABLED or DOWN state (and you most probably will), you need to activate the irf-port configuration with the following command

irf-port-configuration active

The device should now activate its interfaces, send/receive IRF hello packets, form adjacencies and then if not the master, proceed to reboot itself and join the stack. You can also just reboot instead of activating the irf-port configuration, and the result would still be the same, though don’t forget to save the configuration either way.

Another pitfall you need to watch out for is if you configure all the ports, issue irf-port-config active, and then plug-in the SFP+. If not the master, the device will catch you off-guard and reboot 🙂

If you plug out one/all SFP+ transceivers and sever the IRF member from the stack, the irf-port configuration is not erased. Thus if you replug it later, the device will join the stack and reboot itself.

There you have it, a crash-course in IRF configuration. It was a lengthy post, but non-exhaustive nonetheless. For more info, check out the documentation for your specific device, as a couple of things depend on it, e.g. the maximum number of devices you’re able to join to the stack.