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" <[email protected]> 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:[email protected]] On Behalf >> Of Adam Vitkovsky >> Sent: 20 January 2015 23:08 >> To: Saku Ytti; [email protected] >> 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:[email protected]] On >> Behalf >> > Of Saku Ytti >> > Sent: 20 January 2015 18:49 >> > To: [email protected] >> > 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 [email protected] >> > 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 [email protected] >> 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 [email protected] >https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
