[j-nsp] MPLS VPN BGP Local Convergence

[Phil Bedard]

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