[j-nsp] MC-LAG on QFX5100
wimclend at gmail.com
Mon Jul 10 13:07:24 EDT 2017
I can’t remember the exact version offhand. it was in the 14.1X53 range I believe. It’s been live for a while though.
I think we may have run into issues with some MC-LAG on ex4600s (mostly the same as qfx5100…) in the 14.1X53-D30 range maybe? I think they were resolved with D35? I’m sorry I can’t provide clearer detail, it was a while back.
the L2-only QFX5100 MC-LAG pair we had the arp issue for the management vlan was I think on a slightly older version of 14.1X53 — D20 or 21 maybe? But as I say once we configured VRRP the issues resolved in that scenario.
> On Jul 10, 2017, at 1:04 PM, Vincent Bernat <bernat at luffy.cx> wrote:
> ❦ 10 juillet 2017 12:36 -0400, William McLendon <wimclend at gmail.com> :
>> if you are running a routing protocol over the particular VLAN on the
>> MC-LAG peers (which is a supported config in Junos MC-LAG
>> implementation) make sure you are running VRRP between the MC-LAG
>> peers, even though it seems unnecessary. VRRP seems required for any
>> ARP sync to occur for a given IRB interface. Without it one side can
>> learn the ARP entry but not the other. Clearing arp cache seems to
>> fix it temporarily but then it pops up again after ARP ages out.
>> We ran into this issue in a similar scenario with MC-LAG L2-only
>> switches where you could only ping the default gateway from one node
>> unless you issued a clear arp, and then it would work until ARP timer
>> ran out again. Once we configured VRRP that issue was resolved.
> Which version do you use? I specifically configured VRRP for this reason
> but still ran into ARP problems.
> There's small choice in rotten apples.
> -- William Shakespeare, "The Taming of the Shrew"
More information about the juniper-nsp