[j-nsp] improving global unicast convergence (with or without BGP-PIC)
Alexander Arseniev
arseniev at btinternet.com
Wed Apr 19 09:11:56 EDT 2017
Sorry, "Juniper’s “Provider Edge Link Protection for BGP” (Cisco’s BGP
PIC Edge)" is not there in 15.1R5:
[edit]
user at labrouter# set protocols bgp group IBGP family inet unicast protection
^
syntax error.
[edit]
user at 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, adamv0025 at 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 at host# set protect core
>
> adam
>
> netconsultings.com
>
> ::carrier-class solutions for the telecommunications industry::
>
> *From:*Alexander Arseniev [mailto:arseniev at btinternet.com]
> *Sent:* Wednesday, April 19, 2017 1:28 PM
> *To:* adamv0025 at netconsultings.com; 'Michael Hare';
> juniper-nsp at 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, adamv0025 at netconsultings.com
> <mailto:adamv0025 at 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:arseniev at btinternet.com]
> *Sent:* Wednesday, April 19, 2017 1:09 PM
> *To:* adamv0025 at netconsultings.com
> <mailto:adamv0025 at netconsultings.com>; 'Michael Hare';
> juniper-nsp at puck.nether.net <mailto:juniper-nsp at 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, adamv0025 at netconsultings.com
> <mailto:adamv0025 at 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::
>
>
>
More information about the juniper-nsp
mailing list