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

[Dragan Jovicic]

Hi Alex,

To answer Your above question - when BFD goes down, BGP goes initially down
> too, but then it tries to reestablish without BFD.
> And if it succeeds, then You'd have BFD down but BFD up.
>

Is this a bug or a feature (the eternal question). Once a client protocol
registers with BFD process, why should it be up if BFD is down?

@Luis

> Even on newer Junos if you don't enable the indirect-next-hop toggle
> you'll still see krt entries with 0x2 flags.
>

You might see 0x0, 0x1, 0x2 and 0x3, last two being on later JUNOS.
0x2 means feature is not explicitly enabled via configuration. It doesn't
tell you anything about whether you have indirect-nh enabled. MPCs running
TRIO can't disable this but if you are running a mix of MPC and DPC cards
then you have to enable it explicitly. I am not aware of any other command
which will show you if this feature is running on you cards.

@adam

> Nah the KRT command doesn't tell you much, show route extensive is going
> to tell you if there's an indirect next-hop in the unilist and what
> forwarding next-hop(s) is the indirect next-hop actually pointing to along
> with its value.
>

mcast, composite, indirect next-hops (all indirect) point to unilist which
point to unicast (or aggregate which recurse to unicast).
The kernels show route extensive doesn't show you if the actual PFE
maintains route from indirect next-hop to forwarding next-hop binding on
PFE.

I'm not sure what you mean by indirect-next hop in unilist, mind showing
what you mean exactly?


>From documentation:
> On platforms containing only MPCs chained composite next hops are enabled
> by
> default.
> With Junos OS Release 13.3, the support for chained composite next hops is
> enhanced to automatically identify the underlying platform capability on
> composite next hops at startup time, without relying on user configuration,
> and to decide the next hop type (composite or indirect) to embed in the
> Layer 3 VPN label.
>


This is on recent JUNOS all MPCs,

Looking at forwarding table on routing-engine, I see full extension of vpn
and transport labels on last step of indirection, unicast next-hop. There
are no composite next-hops enabled.

# run show route forwarding-table dest 10.15.208.

Destination:  10.15.208.0/24
  Route type: user
  Route reference: 0                   Route interface-index: 0
  Multicast RPF nh index: 0
  P2mpidx: 0
  Flags: sent to PFE
  Next-hop type: indirect              Index: 1049328  Reference: 7
  Next-hop type: unilist               Index: 1049304  Reference: 2
  Nexthop: 192.168.0.229
  Next-hop type: Push 155823, Push 366897(top) Index: 1988 Reference: 2
  Load Balance Label: None
  Next-hop interface: ae18.0        Weight: 0x0
  Nexthop: 192.168.0.237
  Next-hop type: Push 155823, Push 322945(top) Index: 2137 Reference: 2
  Load Balance Label: None
  Next-hop interface: ae19.0        Weight: 0x0

A look at PFE level will also show missing composite next-hops.

Once explicitly enable I see composites.

[edit routing-options forwarding-table]
+    chained-composite-next-hop {
+        ingress {
+            l2vpn;
+            l2ckt;
+            labeled-bgp {
+                inet6;
+            }
+            l3vpn;
+        }
+    }

There's quite of few options to configure, and a few scenarios which might
affect how are they created, such as if your PE is also a P router, and if
you have degenerated PE-PE connection to name two,

[edit routing-options forwarding-table]
+    chained-composite-next-hop {
+        ingress {
+            l3vpn pe-pe-connection;
+        }
+    }

To recap, I wouldn't take all these options are configured automatically,
better check.

BR,

+Dragan
ccie/jncie