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.
Solution
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.
About Aruba Networks 
After aplying this we still experiance ARP/5/ARP_DUPLICATE_IPADDR_DETECT messages cross member ports in the stack. What do you recommend?
which version is this ? I have been this behavior in the past, but it went away with an update (this was on 5500HI).
We see this as well, on both IRF stacks, and single switches. I have enabled mac-roaming, but we still see the ARP/5/ARP_DUPLICATE_IPADDR_DETECT when the client seems to roam from AP to AP. On a single switch, it just shows the same IP, and same MAC in the message, but from two different ports, so I assume this is for the brief moment it takes the device to roam from one AP to another.
See examples:
Non-IRF
Version 5.20.99, Release 2220P02
HP A5120-48G-PoE+ EI Switch with 2 Interface Slots
%Apr 17 08:19:36:647 2015 la-switch1 ARP/5/ARP_DUPLICATE_IPADDR_DETECT: Detected an IP address conflict. The device with MAC address 489d-246c-fbe5 connected to GigabitEthernet1/0/50 in VLAN 1 and the device with MAC address 489d-246c-fbe5 connected to GigabitEthernet1/0/49 in VLAN 1 are using the same IP address 10.115.3.24.
IRF (2 members)
Version 5.20.99, Release 2221P06
HP A5120-24G-PoE+ EI Switch with 2 Interface Slots
%Apr 17 04:45:53:699 2015 stc-switch2 ARP/5/ARP_DUPLICATE_IPADDR_DETECT: -Slot=2; Detected an IP address conflict. The device with MAC address 94db-c937-5e51 connected to GigabitEthernet1/0/25 in VLAN 1 and the device with MAC address 94db-c937-5e51 connected to GigabitEthernet2/0/43 in VLAN 1 are using the same IP address 10.15.2.159.
Hi
We also have this issue with a 5120 stack (version 5.20.99, Release 2220P01).
mac-address mac-roaming enable and mac-address station-move quick-notify enable are issued.
In our case there are two redundant wireless controllers which both have some AP’s that terminate on them. So when roaming between AP’s, clients also roam between controllers.
I don’t find much explanation on the hp docs about those commands and why there should be an IP address conflict in the first place.
Any ideas?
thx
Hi,
Come accross the same issue, now on two 5120’s just like Peter. In IRF stacked, roaming between them takes several seconds for the switch to update the MAC address table to the other member switch. While the same command’s as Peter are inserted.
This command fixes it on Comware 7, but isn’t availeble on Comware 5:
mac-address mac-move fast-update
Isn’t there anything else that can be done or is this an design flaw in IRF on Comware?
Kind Regards
Bastiaan
Hi Bastiaan,
It seems the ARP table and destination port is by default maintained independent of the Layer2 MAC address table destination port.
The Comware7 command “mac-address mac-move fast-update” will update the ARP table when the MAC address moves in the Layer2 MAC table.
On Comware5, the same function is available with the command “mac-address station-move quick-notify enable”,
I hope this helps!
best regards,Peter.
Hi Peter and Bastiaan
I’ve issued the “mac-address station-move quick-notify enable” command on the 5120 ‘s but no luck.
There is however a ‘known issue’ that seems to correspond (sort of) with the symptoms:
– Symptom: The switch prints a message indicating an IP address conflict when a newly online wireless client obtains the IP address of a wireless client that just went offline.
– Condition: This symptom occurs if the following conditions exist:
Wireless clients obtain IP addresses through DHCP.
A wireless client comes online after another wireless client goes offline.
According to hp support it could be a software bug. I will try a firmware upgrade and report back.
Best Regards
Peter
Hi both Peters,
The “mac-address station-move quick-notify enable” was also enabled in the 5120 setup.
The problem is when an wireless client roams between two AP’s, and both ap’s are spilt over the two IRF members, the MAC address changed lacked behind. Mostly a few seconds while an broadcast (notify switches) was send from the AP which was receiving the wireless client. While when two AP’s are connected to the same IRF switch, this behaviour is not seen. So it’s definitely IRF related.
This is on a customer site, and he’s going to create a support case aswell. Have you made any progress on it?
Regards,
Bastiaan
Hi Bastiaan, that behavior is supposed to be handled by the mac-address mac-roaming enable command (control plane based mac synchronization between irf members).
If this is not working, then it looks like a bug and you will need a support case.
Are you running latest software on the 5120?
best regards,Peter
Hi
As promised I have some feedback about the ‘Duplicate IP’ issue. Turns out that a firmware upgrade on the 5120 switches removed the messages. The FW version with the issue (in our case) was: 5.20.99, Release 2220P01. After upgrade to 5.20.99, Release 2221P20 there were no more duplicate IP messages.
Best Regards
Peter
That is good news!
I have a 5120 running Version 5.20, Release 2208P01.
The mac-address mac-roaming command is not available. Should i upgrade the switch for this to work?
Hi All,
I know that this post was wrote long time ago, but I found this and I experience the same issue with my 5500 HP switches. I have hopefullness that you still can see this message.
My release is 5.20.99, Release 2220P02 and I saw that uprade can solve the messages on logs.
My question is: This messages on the log are only information logs or it really impact on performance of network?
Best Regards,
Claudio
Olá Cláudio,
Você conseguiu resolver este problema em sua rede?
Did you solve this problem in your LAN?
Thanks
Hi people,
I have those same messages with my 5500 HP Switch. I have some Wireless AP and some PC Wireless Client are changing between two of them.
My switch is H3C S5500-28C-EI with Software Version 5.20 Release 2221P02.
Hi can I resolve this problem??