[c-nsp] IOS XR / advertise best-external
Marian Ďurkovič
md at bts.sk
Mon May 18 02:21:10 EDT 2015
On Sun, 17 May 2015 13:48:42 +0200, Gert Doering wrote
> RP/0/RSP0/CPU0:Cisco-F-X#sh cef 194.97.129.1
> Sat May 16 23:26:20.777 MEDST
> 194.97.129.1/32, version 76418887, internal 0x14000001 (ptr 0xa1045a14)
> [1], 0x0 (0x0), 0x0 (0x0)
> Updated May 9 14:43:16.617 Prefix Len 32, traffic index 0,
> precedence n/a, priority 4 BGP Attribute: id: 0xc4eb, Local id: 0xbc96,
> Origin AS: 65300, Next Hop AS: 65300
>
> via 10.10.11.45, 5 dependencies, recursive [flags 0x6000]
> path-idx 0 [0x9eac8c88 0x0] next hop 10.10.11.45 via 10.10.11.45/32
> via 10.10.11.241, 5 dependencies, recursive, bgp-ext, bgp-best-ext [flags
0x6060]
> path-idx 1 [0x9e5a92c0 0x0] next hop 10.10.11.241 via 10.10.11.241/32
>
> ... and indeed, it nicely load-shares packets between the primary
> service instance (behind 10.10.11.45) and the secondary service instance
> (on the base IP 10.10.11.241).
Hi Gert,
the fact that both entries are present in RIB and CEF tables is expected
behaviour. It's part of the new design, where both active and backup paths are
preinstalled into the CEF table, which allows much faster convergence when the
active path disappears. Note that the backup path has different CEF flags, which
should instruct the forwarding engine *not* to use it when another regular path
is present in CEF table.
It should be investigated why your router uses the backup path for traffic -
this is clearly wrong. One possible reason might be that the affected linecards
are running different firmware version than required by the IOS.
With kind regards,
M.
More information about the cisco-nsp
mailing list