On Sat, Feb 6, 2016 at 10:19 AM, Adam Vitkovsky <adam.vitkov...@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.vitkov...@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 postmas...@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@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp