[j-nsp] improving global unicast convergence (with or without BGP-PIC)

[James Bensley]

On 27 April 2017 at 14:41,  <adamv0025 at netconsultings.com> wrote:
>> James Bensley
>> Sent: Thursday, April 27, 2017 9:13 AM
>>
>> It might be worth pointing out that on Cisco you need to enable PIC Core for
>> PIC Edge to work at its best.

> So it's either Core or Core+Edge.

That's pretty much the point I was trying to make, albeit unclearly.

>> For you VPNv4/VPNv6 stuff one must enable PIC Edge with advertise best
>> external or add path etc. However enabling PIC Edge without PIC Core means
>> that backup paths will be pre-computed but not programmed into hardware.
> Again, not sure how can you enable PIC Edge but not PIC Core on Cisco?

We use PIC Core + PIC Edge however we still have some 7600s in the mix
which don't support a hierarchical FIB for labelled prefixes without
recirculating all packets (PIC Edge is basically not support for
VPNv4/VPNv6 prefixes without halving your pps rate). So you end up
with BGP computing a backup path in the BGP RIB (random prefix from
Internet table shown below as example) but there is no backup path in
CEF/FIB:

#show bgp ipv4 unicast 1.0.4.0/24
BGP routing table entry for 1.0.4.0/24, version 326263390
BGP Bestpath: compare-routerid
Paths: (3 available, best #3, table default)
  Advertise-best-external
  Advertised to update-groups:
     2          4          10
  Refresh Epoch 3
  3356 174 4826 38803 56203
    x.x.x.254 (metric 2) from x.x.x.254 (x.x.x.254)
      Origin incomplete, metric 0, localpref 100, valid, internal
      Community: xxxxx:200 xxxxx:210
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  6453 3257 4826 38803 56203
    195.219.83.137 from 195.219.83.137 (66.110.10.38)
      Origin incomplete, metric 0, localpref 100, valid, external,
backup/repair, advertise-best-external    << PIC backup path
      Community: xxxxx:200 xxxxx:211 , recursive-via-connected
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  174 4826 38803 56203
    10.0.0.7 (metric 1001) from 10.0.0.7 (10.0.0.7)
      Origin incomplete, metric 0, localpref 100, valid, internal,
best    << best path
      Community: xxxxx:200 xxxxx:212
      rx pathid: 0, tx pathid: 0x0


So one ends up having the next best path learned and computed but not
installed in to FIB. Bit of a corner case I know but Cisco know's we
love to juggle more items than we have hands!

>> In Juniper land, does one need to activate indirect-next-hop before you can
>> provide PIC Edge for eBGP vpn4/vpn6 routes?
>>
> Nope, just load-balancing.
> And then protection under neighbour stanza.
>
>> Is indirect-next-hop enabled by default on newer MX devices / Junos
>> versions?
>>
> Yes.

Just to clarify, one doesn't need to enable indirect-next-hop because
it is enabled by default, but if it were turned off for any reason, I
presume it is a requirement for PIC Edge? Or is it really not required
at all, if not, how is the Juniper equivilent working?

Looking on juniper.net it looks like one exports multiple routes from
the RIB to FIB however assuming the weight == 0x4000 those additional
paths won't be used during "normal" operations, only during a failure,
so we won't actually get any per-packet load balancing (which would be
undesirable for us), is that correct?

Cheers,
James.