> Karl Brumund
> Sent: Friday, February 05, 2016 2:20 PM
>
> Thanks Adam.
>
> On Fri, Feb 5, 2016 at 3:46 AM, Adam Vitkovsky
> <[email protected]>
> wrote:
>
> > Hello Karl,
> >
> > > Karl Brumund
> > > Sent: Thursday, February 04, 2016 8:56 PM
> > >
> > > We're seeing an issue with a pair of QFX3500s, configured with
> > > MC-LAG towards servers and IPv6 Neighbor Discovery.
> > > qfx1 and qfx2 have mc-ae towards servers. If qfx1 sends NS, a server
> > > may reply on the bonded mc-ae towards qfx2 (depending on which NIC
> > > it hashes to). qfx1 never gets the NA and times out the neighbor.
> > > J documentation only seems to mention NDP and MC-LAG for EX9200s in
> > > 15.1.
> > >
> > > Anybody else seen this, or got a hint to toss our way?
> > >
> > > Thanks!
> > > ...karl
> > Was able to find this:
> >
> >
> >
> http://www.juniper.net/techpubs/en_US/junos14.2/topics/concept/interfa
> > ces-active-active-bridging-and-vrrp-over-irb-mx.html
> >
> > Junos OS supports active-active MC-LAGs by using VRRP over IRB. Junos
> > OS also supports active-active MC-LAGs by using IRB MAC address
> > synchronization. You must configure IRB using the same IP address
> > across MC-LAG peers. IRB MAC synchronization is supported on 32-bit
> > interfaces and interoperates with earlier MPC and MIC releases.
> >
> > We're using VRRP over IRB.
>
>
> > What is interesting though is I can't find anything related to how the
> > heck should NDP work over MC-LAG If anyone knows of any
> documentation
> > please let me know.
> >
> > Only this, which is leading me to believe again that MC-LAG is evil,
> > at
> least on QFX.
> http://www.juniper.net/techpubs/en_US/junos15.1/topics/concept/ipv6-
> neighbor-discovery-switches.html
> EX9200 and 15.1
>
> ...karl
>
Yeah:
"You can use NDP in a multichassis link aggregation group (MC-LAG)
active-active configuration on EX9200 switches."
-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.
adam
Adam Vitkovsky
IP Engineer
T: 0333 006 5936
E: [email protected]
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 [email protected]
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 [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
