[j-nsp] MC-LAG on QFX5100

[Jackson, William]

We are running VRRP in all VLANS that require L3.
We also have the static ARP entries setup so they can ping between peers.
We have floating static routes so that if a MC-LAG peer loses its upstream routing, it will forward all traffic to the other MC-LAG peer over the ICL.
**if we don’t do this it black holes all traffic that hits it, bearing in mind that in active/active both peers process traffic.

Thus, what we are seeing is that when traffic comes in from the upstream link, if it goes downstream on the same node it works
, if it needs to traverse the ICL to use the downlink on the peer it fails.

But not in all the vlans on the downstream MC-AE interface.
On some it works and others it doesn’t, very inconsistent.

TAC want to create a PR.

I must say I’m quite surprised with the number of people whom have responded that they have problems with MC-LAG though, would have thought it would have been a mature technology by now.


On 10/07/2017, 19:08, "juniper-nsp on behalf of William McLendon" <juniper-nsp-bounces at puck.nether.net on behalf of wimclend at gmail.com> wrote:

    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"
    
    _______________________________________________
    juniper-nsp mailing list juniper-nsp at puck.nether.net
    https://puck.nether.net/mailman/listinfo/juniper-nsp