> Karl Brumund
> Sent: Friday, February 05, 2016 2:20 PM
>
> Thanks Adam.
>
> On Fri, Feb 5, 2016 at 3:46 AM, Adam Vitkovsky
> <adam.vitkov...@gamma.co.uk>
> 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:      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

Reply via email to