[j-nsp] MC-LAG on QFX5100

[William McLendon]

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.

Thanks,

Will

> 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"