-----Original Message-----
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
Of Alexander Arseniev
Sent: Wednesday, April 19, 2017 8:12 AM
To: adamv0...@netconsultings.com; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] improving global unicast convergence (with or without
BGP-PIC)
Sorry, "Juniper’s “Provider Edge Link Protection for BGP” (Cisco’s BGP
PIC Edge)" is not there in 15.1R5:
[edit]
user@labrouter# set protocols bgp group IBGP family inet unicast protection
^
syntax error.
[edit]
user@labrouter# run show version
Hostname: labrouter
Model: mx240
Junos: 15.1R5.5
The "Juniper BGP PIC for inet" (in global table) is definitely there:
https://www.juniper.net/techpubs/en_US/junos/information-
products/topic-collections/release-notes/15.1/topic-83366.html#jd0e6510
So, what feature in the global table You were surmising to helps the OP?
HTH
Thx
Alex
On 19/04/2017 13:42, adamv0...@netconsultings.com wrote:
Wow, hold on a sec, we’re starting to mix things here,
Sorry maybe my bad, cause I’ve been using Cisco terminology,
Let me use juniper terminology:
I’d recommend using Juniper’s “Provider Edge Link Protection for BGP”
(Cisco’s BGP PIC Edge). –which in Junos for some reason was supported
only for eBGP session in routing-instance –that changes since 15.1.
-that’s what me and OP is talking about (at least I think that’s what
OP is talking about)
Cmd:
set routing-instances radium protocols bgp group toCE2 family inet
unicast protection
What you mentioned below is Juniper’s “BGP PIC Edge” (Cisco’s BGP PIC
Core).
Cmd:
[edit routing-instances routing-instance-name routing-options]
user@host# set protect core
adam
netconsultings.com
::carrier-class solutions for the telecommunications industry::
*From:*Alexander Arseniev [mailto:arsen...@btinternet.com]
*Sent:* Wednesday, April 19, 2017 1:28 PM
*To:* adamv0...@netconsultings.com; 'Michael Hare';
juniper-nsp@puck.nether.net
*Subject:* Re: [j-nsp] improving global unicast convergence (with or
without BGP-PIC)
Hi there,
BGP PIC for inet/inet6 is primarily for complete ASBR failure use case:
When the BGP Prefix Independent Convergence (PIC) feature is enabled
on a router, BGP installs to the Packet Forwarding Engine the second
best path in addition to the calculated best path to a destination.
The router uses this backup path when an egress router fails in a
network and drastically reduces the outage time. You can enable this
feature to reduce the network downtime if the egress router fails.
https://www.juniper.net/techpubs/en_US/junos/topics/concept/use-
case-for-bgp-pic-for-inet-inet6-lu.html
The original topic was for eBGP peer failure use case.
I admit You could make BGP PIC to work for the original topic scenario
if You don't do eBGP->iBGP NHS on ASBR and inject eBGP peer interface
subnet into Your IGP and into LDP/RSVP (if LDP/RSVP are in use).
HTH
Thx
Alex
On 19/04/2017 13:21, adamv0...@netconsultings.com
<mailto:adamv0...@netconsultings.com> wrote:
I see, so it’s sort of a “half way through” solution, where the
convergence still needs to be done in CP and then when it comes to
DP programming –that’s going to be fast cause just one INH needs
to be reprogramed.
Not sure I‘m convinced though, would rather recommend upgrading to
15.1 to get PIC capability for inet0.
adam
netconsultings.com
::carrier-class solutions for the telecommunications industry::
*From:*Alexander Arseniev [mailto:arsen...@btinternet.com]
*Sent:* Wednesday, April 19, 2017 1:09 PM
*To:* adamv0...@netconsultings.com
<mailto:adamv0...@netconsultings.com>; 'Michael Hare';
juniper-nsp@puck.nether.net <mailto:juniper-nsp@puck.nether.net>
*Subject:* Re: [j-nsp] improving global unicast convergence (with
or without BGP-PIC)
Hi there,
The benefit is that value of INH mapped to a 100,000s of prefixes
can be quickly rewritten into another value - for a different INH
pointing to another iBGP peer.
Without INH, the forwarding NH value of EACH and EVERY prefix is
rewritten individually and for longer period of time.
Your example of "correctly programmed INH" with LFA show 2
preprogrammed forwarding NHs which is orthogonal to the original
topic of this discussion.
INH could be preprogrammed with one or multiple forwarding NHs,
and to achieve "multiple forwarding NHs" preprogramming, one uses
ECMP, (r)LFA, RSVP FRR, etc.
HTH
Thx
Alex
On 19/04/2017 12:51, adamv0...@netconsultings.com
<mailto:adamv0...@netconsultings.com> wrote:
Of Alexander Arseniev
Sent: Wednesday, April 19, 2017 11:51 AM
- then 203.0.113.0 will appear as "indirect" and You can have the
usual
INH
benefits. Example from my lab:
show krt indirect-next-hop | find "203.0.113."
Indirect Nexthop:
Index: 1048592 Protocol next-hop address: 203.0.113.0
RIB Table: inet.0
Policy Version: 1 References: 1
Locks: 3 0x9e54f70
Flags: 0x2
INH Session ID: 0x185
INH Version ID: 0
Ref RIB Table: unknown
Next hop: #0 0.0.0.0.0.0 via ae4.100
Session Id: 0x182
IGP FRR Interesting proto count : 1
Chain IGP FRR Node Num : 1
IGP Resolver node(hex) : 0xb892f54
IGP Route handle(hex) : 0x9dc8e14 IGP
rt_entry
protocol : Static
IGP Actual Route handle(hex) : 0x0 IGP Actual
rt_entry protocol : Any
Disclaimer - I haven't tested the actual convergence with this
setup.
But what good is an indirect next-hop if it's pointing to just a single
forwarding next-hop??
Example of correctly programed backup NHs for a BGP route:
...
#Multipath Preference: 255
Next hop: ELNH Address 0x585e1440 weight 0x1, selected <<<eBGP
primary path
Next hop: ELNH Address 0x370c8698 weight 0x4000 <<< PIC
backup
via iBGP
Indirect next hop: 9550000 1048589 INH Session ID: 0x605
Next hop: 10.0.20.1 via ae1.0 weight 0x1 <<< IGP primary path
Next hop: 10.0.10.1 via ae0.0 weight 0xf000 <<< LFA backup path
-I doubt you can get this with a static default route
For the above you need to allow for multiple NHs to be programed into
FIB
using:
set policy-options policy-statement ECMP then load-balance per-
packet
set routing-options forwarding-table export ECMP
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
