[j-nsp] QFX mc-lag and v6 ND

[Karl Brumund]

On Sat, Feb 6, 2016 at 10:19 AM, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk>
wrote:

> > Phil Mayers
> > Sent: Friday, February 05, 2016 4:43 PM
> >
> > On 05/02/16 14:40, Adam Vitkovsky wrote:
> >
> > > -that's the only occasion the internet where NDP and MC-LAG in listed
> > > the same sentence, which is not a good sign on its own. But no
> > > explanation about how it is done, especially the part about how the ND
> > > Cache is maintained between the LAG members, which clearly is what is
> > > not happening in your case.
> >
> > I must be missing something - why would a LAG of any type do any special
> > processing of ND (or ARP, for that matter) traffic? All it has to do is
> forward
> > the reply appropriately e.g. across the MC-LAG control link if the dest
> MAC is
> > the peer switch or multi/broadcast.
> >
> > Obviously if you're doing some sort of active-active L3 forwarding on
> top of
> > the MC-LAG then special things need to happen - but did OP say that?
> >
> > Or is there some subtlety (dumb-lety?) about the way Juniper do this?
> >
> Hmm good point Phil,
> And that would require L2 link between the QFX switches.
> In that case the NS would have been flooded say from QFX1 to server as
> well as from QFX1 to QFX2 to server.
> And the NA would be switched using QFX1's MAC address so whichever link is
> the NA hashed to it should find its way back to QFX1.
> Also I assumed it's active/active setup.
>

QFX only supports active/active. :)

The NS is sourced from the VRRP link local address, not the local IRB LL IP.

Here's a packet capture:

20:24:33.397805 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32)
fe80::200:5eff:fe00:201 > ff02::1:ff00:6: [icmp6 sum ok] ICMP6, neighbor
solicitation, length 32, who has 2600:2001:1400:109::6
source link-address option (1), length 8 (1): 00:00:5e:00:02:01
0x0000: 0000 5e00 0201
 Both qfx1 and qfx2 have the LL address in the routing table as a local
address.

fe80::200:5eff:fe00:201/128
                   *[Local/0] 39w3d 00:07:51
                      Local via irb.1400

The question is why is qfx2 not switching the frame to qfx1, since the
virtual MAC should only be active on qfx1. Smells like a bug to me.

...karl

>
> Karl,
> Can you please share the related config of the two QFX switches?
>
>
> adam
>
>
>
>
>
>         Adam Vitkovsky
>         IP Engineer
>
> T:      0333 006 5936
> E:      Adam.Vitkovsky at gamma.co.uk
> W:      www.gamma.co.uk
>
> This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents
> of this email are confidential to the ordinary user of the email address to
> which it was addressed. This email is not intended to create any legal
> relationship. No one else may place any reliance upon it, or copy or
> forward all or any of it in any form (unless otherwise notified). If you
> receive this email in error, please accept our apologies, we would be
> obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or
> email postmaster at gamma.co.uk
>
> Gamma Telecom Limited, a company incorporated in England and Wales, with
> limited liability, with registered number 04340834, and whose registered
> office is at 5 Fleet Place London EC4M 7RD and whose principal place of
> business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>