[j-nsp] MPLS VPN BGP Local Convergence
Adam Vitkovsky
avitkovsky at gammatelecom.com
Mon Jan 26 05:53:52 EST 2015
Thank you very much Phil,
The : http://www.juniper.net/documentation/en_US/junos14.2/topics/topic-map/layer-3-vpn-pe-edge-protection.html
Is exactly what I meant.
Hopefully it's using the same external-internal multipath principles and just marks the backup path with worse weight i.e. actually programs the backup path into HW for fast failover.
The: http://www.juniper.net/techpubs/en_US/junos12.2/topics/topic-map/mpls-egress-protection-layer-3-vpn-services-configuration.html
Reminds me of some Ahmed Bashandy’s work regarding the LER protection taking place on a penultimate node.
I see this feature can be really appreciated indeed everywhere where there's MPLS hierarchy and the only protocol you can rely on to signal the egress PE router failure is BGP labeled-unicast = slow.
adam
> -----Original Message-----
> From: Phil Bedard [mailto:philxor at gmail.com]
> Sent: 26 January 2015 03:20
> To: Adam Vitkovsky; Saku Ytti; juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] MPLS VPN BGP Local Convergence
>
> There is an older feature called MPLS Egress Protection for L3VPNs which
> perhaps is being replaced by BGP PIC Edge, since they are both PE
> protection mechanisms.
>
> http://www.juniper.net/documentation/en_US/junos14.1/topics/topic-
> map/mpls-
> egress-protection-layer-3-vpn-services-configuration.html
>
> You can use the same feature for protecting labeled unicast global routes
> for something like Seamless MPLS or Inter-AS Option C setups.
>
> They also have a feature called L3VPN PE Edge Protection that is
> specifically used to setup a backup path to cover a PE-CE failure.
>
> http://www.juniper.net/documentation/en_US/junos14.2/topics/topic-
> map/layer
> -3-vpn-pe-edge-protection.html
>
>
>
> Phil
>
>
>
>
> On 1/21/15, 10:52 AM, "Adam Vitkovsky" <avitkovsky at gammatelecom.com>
> wrote:
>
> >Right the documentation is concerning the BGP PIC Edge just for MPLS
> >L3VPNs and in a context that it is a remedy for only PE failure not the
> >CE-PE link failure (I'll assume the draft has been followed though).
> >But now I'm thinking since it's configured under the routing options
> >-wouldn't it work for all AFs i.e. non VPN traffic as well?
> >Has anyone tested that please?
> >Or has anyone tested the Junos BGP PIC Edge for CE-PE link failure for
> >that matter?
> >
> >
> >adam
> >> -----Original Message-----
> >> From: juniper-nsp [mailto:juniper-nsp-bounces at puck.nether.net] On
> Behalf
> >> Of Adam Vitkovsky
> >> Sent: 20 January 2015 23:08
> >> To: Saku Ytti; juniper-nsp at puck.nether.net
> >> Subject: Re: [j-nsp] MPLS VPN BGP Local Convergence
> >>
> >> Hi Saku,
> >>
> >> Yeah the "BGP local convergence" is an old one indeed from days where
> we
> >> had to run iBGP multipath load sharing to get two paths programed into
> >>the
> >> HW.
> >> However this feature is essential for fast convergence.
> >>
> >> This feature prevents from blackholing during BGP convergence in cases
> >> where you have primary and backup egress PEs and a PE-CE link fails on
> >>the
> >> primary PE.
> >> While the BGP infrastructure is converging the ingress PEs keep on
> >>sending
> >> data towards the primary PE with the failed PE-CE link that would
> >>otherwise
> >> drop the packets.
> >> Primary PE running "MPLS VPN BGP Local Convergence" feature will keep
> >>the
> >> VPN(e.g. per in-vrf-NH) label for the failed link for some time (which
> >>would
> >> be otherwise released).
> >> But the label no longer points to the egress PE-CE in-vrf-NH but now it
> >>points
> >> to a NH label on the path towards the backup PE.
> >> So that's how the Primary PE does kind of local repair till the BGP
> >>converges
> >> and ingres PEs start using backup PE as the NH for the VPN prefixes.
> >>
> >> Right solving a PE router failure is easy as IGP will notify all PEs in
> >>no time and
> >> they can then start using the preinstalled backup path(PIC) or just
> >>reprogram
> >> the chained NHs to point to an alternate forwarding NH which should be
> >> fairly quick as well.
> >>
> >> But with failed CE-PE link all you've got to let everybody know is the
> >>slow BGP
> >> process (unless you put your CE-PE links into IGP which is the way it
> >>was
> >> done back in the old old days - pure ipv4 BGP core).
> >> This is where the BGP local convergence feature becomes handy.
> >>
> >> adam
> >> > -----Original Message-----
> >> > From: juniper-nsp [mailto:juniper-nsp-bounces at puck.nether.net] On
> >> Behalf
> >> > Of Saku Ytti
> >> > Sent: 20 January 2015 18:49
> >> > To: juniper-nsp at puck.nether.net
> >> > Subject: Re: [j-nsp] MPLS VPN BGP Local Convergence
> >> >
> >> > On (2015-01-20 16:57 +0000), Adam Vitkovsky wrote:
> >> >
> >> > > Hi Folks,
> >> > >
> >> > > Is there an equivalent to the "MPLS VPN BGP Local Convergence"
> >>feature
> >> > on Junos please?
> >> > > Possibly for non VPN prefixes as well.
> >> >
> >> >
> >>
> http://www.juniper.net/documentation/en_US/junos14.2/topics/task/confi
> >> > guration/layer3-vpn-bgp-pic-edge-configuring.html
> >> >
> >> > I don't really recall difference in 'local convergence' and BGP PIC,
> >>but I
> >> > seem to recall, 'local convergence' didn't install backup path, but
> >> > recalculated it when fault occurred.
> >> > I don't know if this inferior version is available in JunOS or if
> >>you'd even
> >> > want to run it, if it were.
> >> >
> >> > <rant>
> >> > Unfortunately only for VPN. Why oh why do we have concept of global
> >> table
> >> > and
> >> > VRF, INET should in same code path as VRF, with no special treatment.
> >> > Juniper
> >> > still introduced in 14.2 features that work only in global table.
> >>This feature
> >> > disparity between global and vrf is highly annoying. And I'm sure it
> >>adds
> >> > development costs to consider these different things. Rather than pay
> >>one
> >> > time
> >> > cost to redesign the legacy code, vendors opt to pay for decades to
> >>support
> >> > the old architecture which things they are different things.
> >> > </rant>
> >> >
> >> >
> >> > --
> >> > ++ytti
> >> > _______________________________________________
> >> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> >> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >>
> >>-------------------------------------------------------------------------
> >>--------------
> >> This email has been scanned for email related threats and delivered
> >>safely
> >> by Mimecast.
> >> For more information please visit http://www.mimecast.com
> >>
> >>-------------------------------------------------------------------------
> >>--------------
> >>
> >> _______________________________________________
> >> juniper-nsp mailing list juniper-nsp at puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/juniper-nsp
> >--------------------------------------------------------------------------
> >-------------
> > This email has been scanned for email related threats and delivered
> >safely by Mimecast.
> > For more information please visit http://www.mimecast.com
> >--------------------------------------------------------------------------
> >-------------
> >
> >_______________________________________________
> >juniper-nsp mailing list juniper-nsp at puck.nether.net
> >https://puck.nether.net/mailman/listinfo/juniper-nsp
---------------------------------------------------------------------------------------
This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com
---------------------------------------------------------------------------------------
More information about the juniper-nsp
mailing list