[j-nsp] Enable EVPN on existing mpls l3vpn network

Eric Oosting eric.oosting at gmail.com
Fri Feb 19 10:17:26 EST 2016


On Fri, Feb 19, 2016 at 4:14 AM, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk>
wrote:

> > tim tiriche
> > Sent: Thursday, February 18, 2016 6:44 PM
> >
> > Hello,
> >
> > I have an existing L3VPN network with NSR.
> >
> > If i want to enable EVPN, is it just a matter of enabling family evpn
> signalling
> > on the bgp neighbors?
> >
> > Will doing so, cause a session reset or affect existing production
> services or
> > something else i need to be aware of?  this will be on the junos
> > recommended 13.3R8 code.  I read NSR is not supported for EVPN.  If i
> > enable family evpn signalling will NSR be supported for existing l3vpn
> > functionality?
> >
> > -Tim
> >
> Hello Tim,
>
> Every time you'll be adding new Subsequent Address Family (EVPN) or a new
> Address Family (IPv6) on a particular BGP session the BGP speaker you are
> adding these on will need to advertise it as new capability (notifying the
> neighbour that it can now tx/rx messages for this AFI/SAFI).
> Unfortunately though, capabilities are exchanged only in the Open message
> -and that one is sent only when the TCP session is first established.
> So in order to advertise new capabilities the existing session needs to be
> torn down and brought up again.
> (and there's also the RFC requirement saying that when a neighbour
> receives unrecognized optional parameters in open message it may terminate
> the session)
>

And then there is this gem:

http://www.juniper.net/documentation/en_US/junos13.2/topics/topic-map/bgp-sessions.html

where in under certain circumstances your router switches between a more or
less optimal method of rib management, and when it changes it resets every
one of your bgp sessions.

-e


>
> You ask why on earth the capabilities can't be exchanged over the
> established TCP session in 2016?
> Well that's a good question and I myself would like to hear the story
> behind why the proposals did not fly.
>
>
> Regarding the NSR
> It works per session -so if any of the AFs or SAFs using the TCP session
> do not support NSR -the session won't be preserved across the RE
> switchovers.
> So as suggested already you should run a separate TCP session for SAFs
> that do not support NSR -this session is then not going to be protected by
> NSR.
>
>
> Couple of consideration regarding the EVPN
> Pure EVPN (i.e. without the PBB font-end) does C-MAC learning in control
> plane so make sure your BGP speakers can hold all the MAC routes you intend
> to carry.
> Also you might want to introduce mLDP into the core so EVPN can forward
> multi-destination traffic effectively.
>
>
>  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
>


More information about the juniper-nsp mailing list