This is a quick primer on running IRF on a couple of HP 5800.
IRFv2 systems are connected using any 10GbE interface:
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.
port group interface Ten 1/0/53
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:
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.
The switch with a higher priority.
The switch with the longest system up-time. (The member switches exchange system up-time in the IRF hello packets)
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
%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
%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
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.