IRF is used on Comware switches (and some routers as well now) to virtualize 2 or more devices as 1 virtual device.
This is a very convenient way to simplify the network setup and management. Although IRF is very easy in the daily use, we should not forget that it actually runs on multiple physical switches, so the under the hood, multiple switch ASICs and forwarding tables have to be kept in sync.
This post covers a scenario where IRF needs some additional configuration in order to make sure it still behaves as “1” switch.
Scenario: Layer2 MAC moves
Introduction of IRF MAC-Learning
When a PC is moved from a port on unit1 to a port on unit2, the MAC address of the PC will be removed when the link goes down, and will be learned again when the link on the port of unit2 comes up.
In the IRF display mac-address output, you would simply see the MAC on interface G1/0/1 first, and next on interface G2/0/1.
What you don’t see is the fact that both unit ASICs actually perform independent hardware based MAC learning.
So for the initial user on a port of unit1, the MAC address of the PC will be learned by unit2 on the internal IRF port, which is not shown in the display mac-address output (which simply shows the external ports, not the internal IRF ports).
When the PC is moved to a port on unit2, unit2 will learn the MAC on G2/0/1, but unit1 will learn the MAC on the internal IRF port again.
While this works fine for normal scenario’s, it can be challenging in combination with wireless APs configured for local forwarding.
Wireless AP with local forwarding connected to IRF
Let’s assume there is an IRF system with 2 units, each of them has an AP connected to a local port. Both APs are configured with the same SSID and perform local forwarding (local breakout).
A wireless PC is connected to AP1 (on unit1), so IRF unit1 will learn the user MAC on the AP port, e.g. G1/0/24. IRF unit2 will learn the user MAC on the internal IRF port.
When traffic arrives on the IRF system from an uplink port (assume a link-aggregation to e.g. a core switch) for this user, traffic can enter on unit1, and will be locally delivered. If traffic arrives through the uplink of unit2, it will be switched over the IRF port to unit1, who will deliver it to the user.
For this scenario, we will focus on the first example: traffic destined to the wireless user enters the IRF through an uplink of unit1.
Impact of Wireless roaming
Now the user roams from AP1 to AP2.
The wireless device has for instance a unicast session with continuous traffic with a device connected behind the core switch (traffic through the link-aggregation uplink).
At the moment the device roams, there is no physical link state change on the IRF system, since the AP port will remain online.
Unit2 will now learn the MAC address of the user through the local port of AP2 (e.g. G2/0/24), so the unit2 MAC tables will be updated. The unicast session to the uplink device will still work, since the MAC of the target device is still on the uplink link-agg.
However, the return traffic of the unicast session may be impacted.
a/ If the core system happens to use the link to unit2 (1 of the 2 links of the link-aggregation), unit2 will receive the packet with destination address of the wireless user. Since it just learned this MAC on the AP2 port, it can just deliver the frame.
b/ If the core system happens to use the link to unit1 (the other link of the link-aggregation), unit1 will receive the packet with destination address of the wireless user. Since the unit1 hardware MAC tables have not been updated yet (this would occur when the wireless user sends a broadcast), unit1 would still forward the frame out to AP1 (on G1/0/24).
This may affect the user traffic experience when performing roaming.
The same may be experienced for any user connected to unit1 (or other wireless users connected to other APs on unit1) who would be communicating with the wireless PC user.
For these scenerio’s, it is possible to enable IRF (control plane based) MAC learning propagation. When a member of the IRF system learns a new MAC address, it will notify the other members of this.
So now, any traffic coming in after the roam, would nearly instantly be forwarded by unit1 to unit2 thanks to this configuration.
Configuration on Comware5 and Comware7
Both Comware5 and Comware7 have support for this feature.
<switch> system-view [switch] mac-address mac-roaming enable
The config guides recommend this feature only for the mentioned scenario (Wireless APs with local forwarding).
This is probably due to the fact that the CPU (IRF control plane) now needs to propagate the learned MAC Addresses. In case there would be e.g. a loop and a mac-flap, this may impact the CPU load.