Header Only - DO NOT REMOVE - Extreme Networks

Will gratuituous arp be dropped by mlag isc peer?


I have 2 servers and two switches. Each server is connected to each switch and MLAG is configured. The application on the server is a redundant one, in a way that active IP address is present only on one server. Both servers (when active) send traffic only towards one switch, and can receive traffic from both switches.

The problem begins when we do a switchover (for example from server A to 😎. Server_B becomes active, takes the ownership of IP address and sends a gratuitous arp. Since traffic is sent only to switch_A switch A receives it

I read this: "However, flood and multicast traffic will traverse the ISC but will be dropped from MLAG peer port transmission by the ISC blocking filter mechanism."

That means, that switch_A gets the gratuitous arp packet, updates its' own iparp table, sends it to ISC link, and switch_B drops the packet.

Is this correct way of working, or am I missing something? Will switch_B check something against its' fdb table? What is the way of working behind it?

12 replies

Userlevel 6
Hi Tomislav,

As you have mentioned according to the UserGuide, "flood traffic will transverse the ISC but will be dropped from MLAG peer port transmission".

That means the Switch_A will get the gratuitous ARP packet and flood to the MLAG peer Switch_B.

The Switch_B will receive the packet, update the IPARP table/information and will block that flood/traffic to the MLAG port.
Henrique wrote:

Hi Tomislav,

As you have mentioned according to the UserGuide, "flood traffic will transverse the ISC but will be dropped from MLAG peer port transmission".

That means the Switch_A will get the gratuitous ARP packet and flood to the MLAG peer Switch_B.

The Switch_B will receive the packet, update the IPARP table/information and will block that flood/traffic to the MLAG port.

Great, thank you. I was thinking that the packet would be dropped by MLAG peer port (in my head meaning ISC port of switch_B) without updating the IPARP table. That is what was missing in my stream of thoughts.

Can you perhaps explain one more scenario to me. Something I noticed while testing this. It is a slightly strange scenario.
I disabled the gratuitous arp and stopped all traffic, so switches would not update.
And I also deleted IPARP and FDB table on switch_B.

When the switchover happened (A->B), nothing was updated as expected.
Then from server_B I sent only one gratuitous arp using:
arping -c 1 -U -I eth1 1.2.3.4

I noticed only switch_A updated both IPARP and fdb table. Nothing on switch_B.
Then I sent another gratuitous arp, and only then switch_B was updated.

I suspect that first arp was dismissed as fdb tables were not synchronized, but I don't know the reason why. Is there some easily explainable reason for that behavior?

I know it's a strange situation, as I deleted the tables, but I would appreciate your input.

BR//
Tomislav
Userlevel 6
Henrique wrote:

Hi Tomislav,

As you have mentioned according to the UserGuide, "flood traffic will transverse the ISC but will be dropped from MLAG peer port transmission".

That means the Switch_A will get the gratuitous ARP packet and flood to the MLAG peer Switch_B.

The Switch_B will receive the packet, update the IPARP table/information and will block that flood/traffic to the MLAG port.

Hi Tomislav,

In this case would be great to confirm if the switch_B received the gratuitous ARP from server_B by mirroring ISC interface because the tables are out of sync.

What if you delete both tables on both switches A and B, then ping both switches from the servers and then run arping command again?
Henrique wrote:

Hi Tomislav,

As you have mentioned according to the UserGuide, "flood traffic will transverse the ISC but will be dropped from MLAG peer port transmission".

That means the Switch_A will get the gratuitous ARP packet and flood to the MLAG peer Switch_B.

The Switch_B will receive the packet, update the IPARP table/information and will block that flood/traffic to the MLAG port.

Hi Henrique,

I agree, and I plan to sniff out the packets, but I am having some logistic issues.
But the question would still remain: why is switch_b not updated on first gratuitous arp / why is gratuitous arp not received by switch_b?

I tried deleting tables on both switches also, but expected things happen. First ping fails towards both switches, and the rest are successful. Arping will not give me any additional info, as this is just a gratuitous arp, there is no reply, so I don't know if it is successful or not (without sniffing).

I'll try to sniff today/tomorrow and report the results.
Henrique wrote:

Hi Tomislav,

As you have mentioned according to the UserGuide, "flood traffic will transverse the ISC but will be dropped from MLAG peer port transmission".

That means the Switch_A will get the gratuitous ARP packet and flood to the MLAG peer Switch_B.

The Switch_B will receive the packet, update the IPARP table/information and will block that flood/traffic to the MLAG port.

Hi,
I managed to capture the trace. I can see that the first arp packet is received by peer switch, but absolutely nothing happened. Only fdb table was updated (synchronized from other switch).

Plus I read your first comment again: "The Switch_B will receive the packet, update the IPARP table/information and will block that flood/traffic to the MLAG port."

That statement is true but after the fdb tables were synchronized. The original question is what will happen when fdb is cleared.

One more thing. In the sentence I mentioned as reference there is:
"...will be dropped from MLAG peer port..."

Doesn't that mean that peer will drop it on ISC link port (peer port) and not on uplink to the server (port)?

My question is:
Why the 1st gratuitous arp packet doesn't update the fdb and IPARP table?

Possible answer:
When peer switch receives the packet, it checks if packets' source MAC address is in fdb table.
Since it is not there (fdb table was cleared), switch considers it an UNKNOWN packet, and then drops the packet without updating anything.
Since the first switch updated its' fdb table based on 1st packet, peer switch synchronizes fdb tables, and when second gratuitous arp arrives, which is now considered as KNOWN packet.
Therefore it is not discarded. The switch updates it's own IPARP table.

I have some doubts about this answer, since I thought the KNOWN/UNKNOWN will be based on destination address and not source MAC.
But my tests points to that answer. Can you please confirm it?

BR//
Tomislav
Userlevel 6
Henrique wrote:

Hi Tomislav,

As you have mentioned according to the UserGuide, "flood traffic will transverse the ISC but will be dropped from MLAG peer port transmission".

That means the Switch_A will get the gratuitous ARP packet and flood to the MLAG peer Switch_B.

The Switch_B will receive the packet, update the IPARP table/information and will block that flood/traffic to the MLAG port.

Hi Tomislav, could you please send a topology with MLAG peers + servers + port connections?

Also an output for the gratuitous ARP being sent by the server?

I would like to try a similar setup in my lab and confirm this behavior.

GARP should update both FDB/ARP tables, but I'm not sure if that behavior is true when using MLAG due to the FDB sync mechanism. Need to confirm that.
Userlevel 6
Henrique wrote:

Hi Tomislav,

As you have mentioned according to the UserGuide, "flood traffic will transverse the ISC but will be dropped from MLAG peer port transmission".

That means the Switch_A will get the gratuitous ARP packet and flood to the MLAG peer Switch_B.

The Switch_B will receive the packet, update the IPARP table/information and will block that flood/traffic to the MLAG port.

Hi Tomislav,

I have just finished my lab test and saw exactly the same behavior you mentioned.

I'm currently working on some possible combinations like clear fdb, clear iparp, send arping, creating static entries, etc. to understand and confirm if this should be expected.
Userlevel 6
Henrique wrote:

Hi Tomislav,

As you have mentioned according to the UserGuide, "flood traffic will transverse the ISC but will be dropped from MLAG peer port transmission".

That means the Switch_A will get the gratuitous ARP packet and flood to the MLAG peer Switch_B.

The Switch_B will receive the packet, update the IPARP table/information and will block that flood/traffic to the MLAG port.

Hi Tomislav,

In my lab tests, when FDB is already populated in both MLAG peers with the MAC added to GARP then the first GARP packet is processed by MLAG peer. The same is true when a second GARP packet is sent.

Based on our engineering team, this is a known MLAG limitation.
Henrique wrote:

Hi Tomislav,

As you have mentioned according to the UserGuide, "flood traffic will transverse the ISC but will be dropped from MLAG peer port transmission".

That means the Switch_A will get the gratuitous ARP packet and flood to the MLAG peer Switch_B.

The Switch_B will receive the packet, update the IPARP table/information and will block that flood/traffic to the MLAG port.

HI,
Thank you for your response. This is good to know.
Can you please provide couple of more details on MLAG?

1) How often do the fdb tables sync? Is that interval configurable?
2) If one switch has new fdb entry, does it immediately push information to second switch, or does it wait for regular sync message?

I've seen this information: https://gtacknowledge.extremenetworks.com/articles/Q_A/MLAG-FDB-Sync-Explained
But I really doubt that the interval is 40 seconds. Because in my tests, and probably yours, you can see the update happens quickly.

BR//
Tomislav
Userlevel 6
Henrique wrote:

Hi Tomislav,

As you have mentioned according to the UserGuide, "flood traffic will transverse the ISC but will be dropped from MLAG peer port transmission".

That means the Switch_A will get the gratuitous ARP packet and flood to the MLAG peer Switch_B.

The Switch_B will receive the packet, update the IPARP table/information and will block that flood/traffic to the MLAG port.

Hi Tomislav, actually I could see that CheckPoint packets with the # of MAC entries is sent every 20s instead of 40s.

As soon as the MLAG peer add a new FDB entry, it will send a CheckPoint message immediately to its neighbor.

If some actions like port down/up or even "clear fdb" occur then the checkpoint happens immediately too.

That 20s period will make sure that both MLAG Peers FDB table are always in sync.

I don't believe you can check the MLAG FDB sync frequency.
Henrique wrote:

Hi Tomislav,

As you have mentioned according to the UserGuide, "flood traffic will transverse the ISC but will be dropped from MLAG peer port transmission".

That means the Switch_A will get the gratuitous ARP packet and flood to the MLAG peer Switch_B.

The Switch_B will receive the packet, update the IPARP table/information and will block that flood/traffic to the MLAG port.

Hi Henrique,
Although I consider this point closed, I still have one comment.

Since we determined that 1st gratuitous arp is going to update IPARP table in only first switch, and then 2nd arp will update iparp table in second switch only after fdb tables are synced.
Can you please check if that can be somehow improved in design area?

First gratuitous arp should update iparp and fdb table in both switches, because all other arp packets are not mandatory. Second and all subsequent packets are sent only for resilience purpose.
That means you will have cca 50% traffic loss, as switch2 will not have updated iparp table.

Maybe sync of iparp table would solve this issue? Needs to be analyzed.

P.S. I have had a case where 3 gratuitous arps were send inside 100ms and in that time fdb tables didn't have time to sync. So the second switch never updated its' iparp table. And then there was 50% traffic loss.

BR//
Tomislav
Userlevel 6
Henrique wrote:

Hi Tomislav,

As you have mentioned according to the UserGuide, "flood traffic will transverse the ISC but will be dropped from MLAG peer port transmission".

That means the Switch_A will get the gratuitous ARP packet and flood to the MLAG peer Switch_B.

The Switch_B will receive the packet, update the IPARP table/information and will block that flood/traffic to the MLAG port.

Hi Tomislav, I would recommend you to open a GTAC case for a feature request and reference this The Hub thread for background information.

Reply