Will gratuituous arp be dropped by mlag isc peer?

  • 0
  • 2
  • Question
  • Updated 2 years ago
  • Answered
  • (Edited)
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 B). 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?
Photo of Tomislav Mijocevic

Tomislav Mijocevic

  • 150 Points 100 badge 2x thumb

Posted 2 years ago

  • 0
  • 2
Photo of Henrique

Henrique, Employee

  • 10,302 Points 10k badge 2x thumb
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.
Photo of Henrique

Henrique, Employee

  • 10,302 Points 10k badge 2x thumb
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.
Photo of Tomislav Mijocevic

Tomislav Mijocevic

  • 150 Points 100 badge 2x thumb
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
Photo of Henrique

Henrique, Employee

  • 10,302 Points 10k badge 2x thumb
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.
Photo of Tomislav Mijocevic

Tomislav Mijocevic

  • 150 Points 100 badge 2x thumb
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
Photo of Henrique

Henrique, Employee

  • 10,302 Points 10k badge 2x thumb
Hi Tomislav, I would recommend you to open a GTAC case for a feature request and reference this The Hub thread for background information.
(Edited)