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 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp