On Sat, Feb 6, 2016 at 7:40 PM, Karl Brumund <li...@brumund.ca> wrote:
> > 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. > My colleague found the following. Not a bug, looks like it is designed to do exactly this in an active-active MC-LAG setup: *"Usually, a VRRP backup node does not forward incoming packets. However, when VRRP over IRB is configured in an MC-LAG active-active environment, both the VRRP master and the VRRP backup forward Layer 3 traffic arriving on the MC-AE interface. If the master fails, all the traffic shifts to the MC-AE link on the backup."* Worse yet, for Juniper handle the above they do the following nonsense with ARP for IPv4: *"Junos OS uses ARP response packet snooping to support active-active MC-LAGs, providing easy synchronization without the need to maintain any specific state. Without synchronization, if one MC-LAG peer sends an ARP request, and the other MC-LAG peer receives the response, ARP resolution is not successful. With synchronization, the MC-LAG peers synchronize the ARP resolutions by sniffing the packet at the MC-LAG peer receiving the ARP response and replicating this to the other MC-LAG peer. This ensures that the entries in ARP tables on the MC-LAG peers are consistent.* They do not describe how they synchronize the arp table but I assume this is done via ICCP. They do describe the end result of not syncing this state, which is the issue we are having with IPv6. VRRP: http://www.juniper.net/documentation/en_US/junos13.2/topics/concept/multichassis-link-aggregation-ex.html#jd0e683 ARP: http://www.juniper.net/documentation/en_US/junos13.2/topics/concept/multichassis-link-aggregation-ex.html#jd0e738 >sigh> > ...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