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

[Karl Brumund]

On Sat, Feb 6, 2016 at 7:40 PM, Karl Brumund <lists at brumund.ca> wrote:

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

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