Re: [j-nsp] Prefix independent convergence and FIB backup path

[adamv0025]

> Of Mark Smith
> Sent: Thursday, February 08, 2018 12:02 PM
> 
> Hi list,
> 
> Test topology below. 2x MX80 with dual ip transit (full table ~600k
prefixes).
> TRA1 preferred over TRA2 (Localpref 200 set by PE1 import policy). Plain
> unlabeled inet.0, no mpls in use. In lab topology both transits belong to
same
> AS65502.
> 
> What I'm trying to accomplish is somewhat faster failover time in case of
> primary transit failure. In case of no tuning the failover (FIB
> programming) can take up to 10 minutes.
> 
> 
> 
> | TRA1 || TRA2 |   AS65502
> 
>| xe-1/3/0  | xe-1/3/0
> --- ---
> | PE1 | --ae0-- | PE2 |AS65501
> --- ---
>|
> ---
> | test pc |
> ---
> 
> In the lab PE1 and PE2 are MX80s running 15.1R6.7.
> I have configured BGP add-path and PIC edge (routing-options protect
> core) on both PEs.

Ok so first of all,
In order to achieve (Cisco term BGP PIC Edge), which seems like what you are
looking for in your setup you need to be using Juniper's "Provider Edge Link
Protection"  (that I know only the "for Layer 3 VPNs" and "for BGP Labeled
Unicast Paths" incarnation -so seems like it's not supported for inet.0.
This feature as to be combined with:
1) advertise-external on iBGP sessions on backup or both PEs -to allow
backup PE advertise the external transit routes to primary PE even when
those are not considered as overall best paths on the backup PE.
2) add-path on iBGP sessions from RRs to PEs (in inet.0) 
3) eBGP protocol preference set to less than 170 -this is needed to avoid
the looping of packets from backup PE back to primary PE (if per VRF label
is used).

How it works:
Thanks to advertise-external and add-path primary PE gets to know about the
alternative path via backup PE and thanks to "Provider Edge Link Protection"
will install this path as backup (metric 0x4000) into FIB.
Data-plane wise if primary PE loses connection to transit it will (in sub
50ms) start sending packets towards the backup PE once these packets arrive
on backup PE either with VPN label defining egress interface or with VPN
label defingin VRF in which case lookup in VRF table is done and thanks to
eBGP path having a better preference the backup PE can forward the packets
to transit -instead of looping them back to primary PE.



Juniper PIC Edge (Cisco PIC Core) (routing-options protect core)
Would be enabled on PE3 that is connected to both PE1 and PE2 in your setup.
This would allow PE3 to install primary as well as backup path into FIB,
again you need to enable advertise-external (and add-path in case of RRs)
(no need to tweak protocol distance as you're comparing two iBGP paths). 
How it works:
Thanks to advertise-external and add-path ingress PE3 gets to know about the
alternative path via backup PE and thanks to " protect core" will install
this path as backup (metric 0x4000) into FIB.
If the whole primary PE goes down or is severed from the rest of the core,
then IGP will notify PE3 that the BGP next-hop for the primary path is
unavailable at which point PE3 can switch all affected iBGP prefixes (in sub
50ms) to point to backup PE. 
Hence you also need to tweak your IGP routing change propagation timers so
that the information about the primary PE loopback is propagated across the
network to all ingress PEs (PE3 in this case) as soon as possible to
minimize the downtime.


adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Prefix independent convergence and FIB backup path

[Mark Smith]

On Thu, Feb 8, 2018 at 3:42 PM, Olivier Benghozi
 wrote:
> Here (VPNv4/v6, BGP PIC Core + PIC Edge, no addpath as not supported in vpn 
> AFI) we can see that, when possible:
> active eBGP path is backuped via iBGP path
> active iBGP path is backuped via another iBGP path
>
> We don't see:
> active iBGP backuped via inactive eBGP
> active eBGP backuped via another inactive eBGP

Ok, so this is the same that I see. Maybe IBGP->EBGP PIC will be
supported in some future junos version :)


> Note that in your case (in inet.0) there's no BGP PIC Edge feature, as I 
> understand it's just a special PIC feature needed for labelled paths toward 
> outside, and you can see that BGP PIC Core for inet already covers your eBGP 
> routes in inet.0.

This edge/core terminology is not very clear. As stated in the
documentation [1] and "MPLS in the SDN era" book (page 801-802)
"protect core" is actually PIC edge.


> Also note that in your case, PE2 (at least when using NHS) cannot quickly 
> detect a TRA1 loss anyway, so there's no usecase here, in fact...

This is correct, thanks for clarification.


> Of course you already know that having both TRA1 and TRA2 with the same 
> localpref does the trick (even without addpath), but it's not what you 
> intended to test :)

Yes I do and I tested it too. Failover was approx 1-2 seconds.
Maybe this is the way to go in production. There may be reasons why
one does not want to "load-balance" between transits though.


[1] 
https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/protect-core-edit-routing-instances.html
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Prefix independent convergence and FIB backup path

[Pavel Lunin]

Here (VPNv4/v6, BGP PIC Core + PIC Edge, no addpath as not supported in vpn
> AFI) we can see that, when possible:
>


No need for add-path in a VRF in fact. You always had it "for free" with
per PE route-distinguishers.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Prefix independent convergence and FIB backup path

[Olivier Benghozi]

Hi Mark,


Here (VPNv4/v6, BGP PIC Core + PIC Edge, no addpath as not supported in vpn 
AFI) we can see that, when possible:
active eBGP path is backuped via iBGP path
active iBGP path is backuped via another iBGP path

We don't see:
active iBGP backuped via inactive eBGP
active eBGP backuped via another inactive eBGP


I understand it works the way it was advertised for:
PIC Core: protect against another PE failure, as detected via IGP
PIC Edge: protect against a local PE-CE link failure (CE being an IP transit by 
example)
The key idea seems to react immediately to a link loss quickly detected, that 
is locally or via IGP ; not to something signalled (potentially slowly) via 
iBGP.
However, protecting iBGP routes using eBGP paths makes sense, as a PE can be 
lost and quickly detected.

It would be interesting to check if "protecting iBGP routes using eBGP ones" or 
"active eBGP using inactive eBGP" are implemented on Cisco IOS-XR gears in 
their BGP PIC implementation.


Note that in your case (in inet.0) there's no BGP PIC Edge feature, as I 
understand it's just a special PIC feature needed for labelled paths toward 
outside, and you can see that BGP PIC Core for inet already covers your eBGP 
routes in inet.0.


Also note that in your case, PE2 (at least when using NHS) cannot quickly 
detect a TRA1 loss anyway, so there's no usecase here, in fact...

Of course you already know that having both TRA1 and TRA2 with the same 
localpref does the trick (even without addpath), but it's not what you intended 
to test :)


Olivier

> Le 8 févr. 2018 à 13:02, Mark Smith  a écrit :
> 
> Hi list,
> 
> Test topology below. 2x MX80 with dual ip transit (full table ~600k
> prefixes). TRA1 preferred over TRA2 (Localpref 200 set by PE1 import
> policy). Plain unlabeled inet.0, no mpls in use. In lab topology both
> transits belong to same AS65502.
> 
> What I'm trying to accomplish is somewhat faster failover time in case
> of primary transit failure. In case of no tuning the failover (FIB
> programming) can take up to 10 minutes.
> 
> 
> 
> | TRA1 || TRA2 |   AS65502
> 
>   | xe-1/3/0  | xe-1/3/0
> --- ---
> | PE1 | --ae0-- | PE2 |AS65501
> --- ---
>   |
> ---
> | test pc |
> ---
> 
> In the lab PE1 and PE2 are MX80s running 15.1R6.7.
> I have configured BGP add-path and PIC edge (routing-options protect
> core) on both PEs.
> All looks ok on PE1. Both primary and backup paths are installed in
> FIB. PE1 converges fast.
> The backup path is missing in PE2 FIB. When PE1-TRA1 cable is cut PE1
> quickly switches to backup path but PE2 does not and the result is a
> temporary routing loop between PE1 and PE2.
> If I switch the active transit to PE2 (set LP220 on TRA2 import on
> PE2, no other changes), the situation is reversed. All looks ok on PE2
> but not on PE1. So it looks like the PIC works only on the box
> connected to primary transit (=EBGP route is better than IBGP route).
> NHS/no-NHS on ibgp export does not have an effect. Is this a bug,
> feature, or am I doing something wrong?
> 
> I know that a better solution could be to get rid of full table and
> just use 2x default route from upstream... anyways I would like to get
> more familiar with PIC.
> 
> Stable situation, all ok on PE1:
> admin@PE1> show route table inet.0 8.8.8.8
> 
> inet.0: 607797 destinations, 1823329 routes (607797 active, 0
> holddown, 0 hidden)
> @ = Routing Use Only, # = Forwarding Use Only
> + = Active Route, - = Last Active, * = Both
> 
> 8.8.8.0/24 @[BGP/170] 05:03:44, localpref 200
>  AS path: 65502 65200 25091 15169 I,
> validation-state: unverified
>> to 10.100.100.133 via xe-1/3/0.0
>[BGP/170] 05:05:55, localpref 100, from 10.100.100.40
>  AS path: 65502 65200 25091 15169 I,
> validation-state: unverified
>> to 10.100.100.137 via ae0.0
>   #[Multipath/255] 05:02:54
>> to 10.100.100.133 via xe-1/3/0.0
>  to 10.100.100.137 via ae0.0
> 
> admin@PE1> show route forwarding-table destination 8.8.8.8 table
> default extensive
> Routing table: default.inet [Index 0]
> Internet:
> 
> Destination:  8.8.8.0/24
>  Route type: user
>  Route reference: 0   Route interface-index: 0
>  Multicast RPF nh index: 0
>  Flags: sent to PFE, rt nh decoupled
>  Next-hop type: unilist   Index: 1048575  Reference: 607767
>  Nexthop: 10.100.100.133
>  Next-hop type: unicast   Index: 826  Reference: 4
>  Next-hop interface: xe-1/3/0.0Weight: 0x1
>  Nexthop: 10.100.100.137
>  Next-hop type: unicast   Index: 827  Reference: 3
>  Next-hop interface: ae0.0 Weight: 0x4000
> 
> 
> But not on PE2:
> admin@PE2> show route table inet.0 8.8.8.8
> 
> inet.0: 607798 destinations, 1215564 routes (607798 active, 607766
> holddown, 0 hidden)
> @ = Routing Use 

Re: [j-nsp] Prefix independent convergence and FIB backup path

[Mark Smith]

Hi

I did read through this thread before posting but it did not address
my question. Thanks for pointer, though.

For the other off-list reply, the loop lasts until FIB on PE2 is
converged which is in the order of magnitude of minutes (maybe 10
depending on the prefix).

On Thu, Feb 8, 2018 at 3:31 PM, Michael Hare <michael.h...@wisc.edu> wrote:
> Hi Mark-
>
> We had a long thread on a similar topic last spring, if you haven't browsed 
> through this you may find it valuable.
>
> https://puck.nether.net/pipermail/juniper-nsp/2017-April/034145.html
>
> -Michael
>
>> -Original Message-
>> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
>> Of Mark Smith
>> Sent: Thursday, February 8, 2018 6:02 AM
>> To: juniper-nsp@puck.nether.net
>> Subject: [j-nsp] Prefix independent convergence and FIB backup path
>>
>> Hi list,
>>
>> Test topology below. 2x MX80 with dual ip transit (full table ~600k
>> prefixes). TRA1 preferred over TRA2 (Localpref 200 set by PE1 import
>> policy). Plain unlabeled inet.0, no mpls in use. In lab topology both
>> transits belong to same AS65502.
>>
>> What I'm trying to accomplish is somewhat faster failover time in case
>> of primary transit failure. In case of no tuning the failover (FIB
>> programming) can take up to 10 minutes.
>>
>>
>> 
>> | TRA1 || TRA2 |   AS65502
>> 
>>| xe-1/3/0  | xe-1/3/0
>> --- ---
>> | PE1 | --ae0-- | PE2 |AS65501
>> --- ---
>>|
>> ---
>> | test pc |
>> ---
>>
>> In the lab PE1 and PE2 are MX80s running 15.1R6.7.
>> I have configured BGP add-path and PIC edge (routing-options protect
>> core) on both PEs.
>> All looks ok on PE1. Both primary and backup paths are installed in
>> FIB. PE1 converges fast.
>> The backup path is missing in PE2 FIB. When PE1-TRA1 cable is cut PE1
>> quickly switches to backup path but PE2 does not and the result is a
>> temporary routing loop between PE1 and PE2.
>> If I switch the active transit to PE2 (set LP220 on TRA2 import on
>> PE2, no other changes), the situation is reversed. All looks ok on PE2
>> but not on PE1. So it looks like the PIC works only on the box
>> connected to primary transit (=EBGP route is better than IBGP route).
>> NHS/no-NHS on ibgp export does not have an effect. Is this a bug,
>> feature, or am I doing something wrong?
>>
>> I know that a better solution could be to get rid of full table and
>> just use 2x default route from upstream... anyways I would like to get
>> more familiar with PIC.
>>
>> Stable situation, all ok on PE1:
>> admin@PE1> show route table inet.0 8.8.8.8
>>
>> inet.0: 607797 destinations, 1823329 routes (607797 active, 0
>> holddown, 0 hidden)
>> @ = Routing Use Only, # = Forwarding Use Only
>> + = Active Route, - = Last Active, * = Both
>>
>> 8.8.8.0/24 @[BGP/170] 05:03:44, localpref 200
>>   AS path: 65502 65200 25091 15169 I,
>> validation-state: unverified
>> > to 10.100.100.133 via xe-1/3/0.0
>> [BGP/170] 05:05:55, localpref 100, from 10.100.100.40
>>   AS path: 65502 65200 25091 15169 I,
>> validation-state: unverified
>> > to 10.100.100.137 via ae0.0
>>#[Multipath/255] 05:02:54
>> > to 10.100.100.133 via xe-1/3/0.0
>>   to 10.100.100.137 via ae0.0
>>
>> admin@PE1> show route forwarding-table destination 8.8.8.8 table
>> default extensive
>> Routing table: default.inet [Index 0]
>> Internet:
>>
>> Destination:  8.8.8.0/24
>>   Route type: user
>>   Route reference: 0   Route interface-index: 0
>>   Multicast RPF nh index: 0
>>   Flags: sent to PFE, rt nh decoupled
>>   Next-hop type: unilist   Index: 1048575  Reference: 607767
>>   Nexthop: 10.100.100.133
>>   Next-hop type: unicast   Index: 826  Reference: 4
>>   Next-hop interface: xe-1/3/0.0Weight: 0x1
>>   Nexthop: 10.100.100.137
>>   Next-hop type: unicast   Index: 827  Reference: 3
>>   Next-hop interface: ae0.0 Weight: 0x4000
>>
>>
>> But not on PE2:
>> admin@PE2> show route table inet.0 8.8.8.8
>>
>> inet.0: 607798 destinations, 1215564 routes (607798 active, 607766
>> holddown, 0 hidden)
>> @ = Routing Use O

Re: [j-nsp] Prefix independent convergence and FIB backup path

[Michael Hare]

Hi Mark-

We had a long thread on a similar topic last spring, if you haven't browsed 
through this you may find it valuable.

https://puck.nether.net/pipermail/juniper-nsp/2017-April/034145.html

-Michael

> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of Mark Smith
> Sent: Thursday, February 8, 2018 6:02 AM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] Prefix independent convergence and FIB backup path
> 
> Hi list,
> 
> Test topology below. 2x MX80 with dual ip transit (full table ~600k
> prefixes). TRA1 preferred over TRA2 (Localpref 200 set by PE1 import
> policy). Plain unlabeled inet.0, no mpls in use. In lab topology both
> transits belong to same AS65502.
> 
> What I'm trying to accomplish is somewhat faster failover time in case
> of primary transit failure. In case of no tuning the failover (FIB
> programming) can take up to 10 minutes.
> 
> 
> 
> | TRA1 || TRA2 |   AS65502
> 
>| xe-1/3/0  | xe-1/3/0
> --- ---
> | PE1 | --ae0-- | PE2 |AS65501
> --- ---
>|
> ---
> | test pc |
> ---
> 
> In the lab PE1 and PE2 are MX80s running 15.1R6.7.
> I have configured BGP add-path and PIC edge (routing-options protect
> core) on both PEs.
> All looks ok on PE1. Both primary and backup paths are installed in
> FIB. PE1 converges fast.
> The backup path is missing in PE2 FIB. When PE1-TRA1 cable is cut PE1
> quickly switches to backup path but PE2 does not and the result is a
> temporary routing loop between PE1 and PE2.
> If I switch the active transit to PE2 (set LP220 on TRA2 import on
> PE2, no other changes), the situation is reversed. All looks ok on PE2
> but not on PE1. So it looks like the PIC works only on the box
> connected to primary transit (=EBGP route is better than IBGP route).
> NHS/no-NHS on ibgp export does not have an effect. Is this a bug,
> feature, or am I doing something wrong?
> 
> I know that a better solution could be to get rid of full table and
> just use 2x default route from upstream... anyways I would like to get
> more familiar with PIC.
> 
> Stable situation, all ok on PE1:
> admin@PE1> show route table inet.0 8.8.8.8
> 
> inet.0: 607797 destinations, 1823329 routes (607797 active, 0
> holddown, 0 hidden)
> @ = Routing Use Only, # = Forwarding Use Only
> + = Active Route, - = Last Active, * = Both
> 
> 8.8.8.0/24 @[BGP/170] 05:03:44, localpref 200
>   AS path: 65502 65200 25091 15169 I,
> validation-state: unverified
> > to 10.100.100.133 via xe-1/3/0.0
> [BGP/170] 05:05:55, localpref 100, from 10.100.100.40
>   AS path: 65502 65200 25091 15169 I,
> validation-state: unverified
> > to 10.100.100.137 via ae0.0
>#[Multipath/255] 05:02:54
> > to 10.100.100.133 via xe-1/3/0.0
>   to 10.100.100.137 via ae0.0
> 
> admin@PE1> show route forwarding-table destination 8.8.8.8 table
> default extensive
> Routing table: default.inet [Index 0]
> Internet:
> 
> Destination:  8.8.8.0/24
>   Route type: user
>   Route reference: 0   Route interface-index: 0
>   Multicast RPF nh index: 0
>   Flags: sent to PFE, rt nh decoupled
>   Next-hop type: unilist   Index: 1048575  Reference: 607767
>   Nexthop: 10.100.100.133
>   Next-hop type: unicast   Index: 826  Reference: 4
>   Next-hop interface: xe-1/3/0.0Weight: 0x1
>   Nexthop: 10.100.100.137
>   Next-hop type: unicast   Index: 827  Reference: 3
>   Next-hop interface: ae0.0 Weight: 0x4000
> 
> 
> But not on PE2:
> admin@PE2> show route table inet.0 8.8.8.8
> 
> inet.0: 607798 destinations, 1215564 routes (607798 active, 607766
> holddown, 0 hidden)
> @ = Routing Use Only, # = Forwarding Use Only
> + = Active Route, - = Last Active, * = Both
> 
> 8.8.8.0/24 *[BGP/170] 00:02:10, localpref 200, from 10.100.100.30
>   AS path: 65502 65200 25091 15169 I,
> validation-state: unverified
> > to 10.100.100.136 via ae0.0
> [BGP/170] 1d 01:54:47, localpref 100
>   AS path: 65502 65200 25091 15169 I,
> validation-state: unverified
> > to 10.100.100.134 via xe-1/3/0.0
> 
> admin@PE2> show route forwarding-table destination 8.8.8.8 table
> default extensive
> Routing table: default.inet [Index 0]
> Internet:
> 
> Destination:  8.8.8.0/24
>   Route type: user
>   Rou