[c-nsp] ASR9k LC fib programming problem
Šturmankin Miroslav
miroslav.sturmankin at swan.sk
Thu Jul 13 11:02:34 EDT 2017
Hello everyone,
I encountered a problem with traffic being forwarded to the old next-hop (no lc hw reprogramed for the new bgp next-hop) after converting route for a prefix from static to bgp.
router specifications:
ASR9006 IOS XR 4.3.4 SP4
A9K-RSP-4G
A9K-MOD160-TR + A9K-MPA-8X10GE & A9K-MPA-4X10GE
I have a bundle-ether interface spanning over two 10G links on both MPAs, which is terminating customer traffic. I have a customer with two links terminated on separate subinterfaces of the bundle and had a /24 prefix routed to a p2p /30 next-hop over the first interface.
int bundle-ether1.10
description [stat] customerA
vrf inet
ipv4 address a.a.a.1/30
encapsulation dot1q 10
router static
vrf inet
address-family ipv4 unicast
x.x.x.0/24 a.a.a.2 description customerA_static
The customer wanted to move the prefix to the second interface and convert static to ebgp advertisement.
int bundle-ether1.20
description [bgp] customerA
vrf inet
ipv4 address b.b.b.1/30
encapsulation dot1q 20
router bgp 1
vrf inet
neighbor b.b.b.2
remote-as 2
description customerA_bgp_peer
address-family ipv4 unicast
route-policy RP_ACCEPT_CUSTOMERA_PREFIXES in
The ebgp session was already established advertising other prefixes a while ago and he advertised the new prefix over bgp. I then removed the static route towards next-hop a.a.a.2 and the bgp route got installed into the routing table. However, the traffic for x.x.x.0/24 was still forwarded from the router via the first interface be1.10, even though routing table was pointing towards next-hop b.b.b.2 via be1.20. After some troubleshooting with extended ping and record route I confirmed that the traffic was leaving my router via be1.10 and returned via be1.20. So I checked fib for a problem and found out, that the fib on LC is still pointing to a.a.a.2 next-hop:
RP/0/RSP0/CPU0:a9k6#sh route vrf inet x.x.x.0/24
Thu Jul 13 16:36:47.547 CEST
Routing entry for x.x.x.0/24
Known via "bgp 1", distance 20, metric 0
Tag 111, type external
Installed Jul 12 11:35:40.360 for 1d05h
Routing Descriptor Blocks
b.b.b.2, from b.b.b.2, BGP external
Route metric is 0
No advertising protos.
RP/0/RSP0/CPU0:a9k6#sh bgp vrf inet x.x.x.0/24
Thu Jul 13 16:38:09.485 CEST
BGP routing table entry for x.x.x.0/24, Route Distinguisher: bla:bla
Versions:
Process bRIB/RIB SendTblVer
Speaker 2625784714 2625784714
Local Label: 1
Last Modified: May 27 18:14:36.243 for 2y06w
Paths: (1 available, best #1)
2
b.b.b.2 from b.b.b.2 (b.b.b.2)
Origin IGP, localpref 600, valid, external, best, group-best, import-candidate
Received Path ID 0, Local Path ID 1, version 2625784714
Community: bla bla
Extended community: RT:bla:bla
RP/0/RSP0/CPU0:a9k6#sh cef vrf inet x.x.x.0/24
Thu Jul 13 16:42:57.056 CEST
x.x.x.0/24, version 6698698982, internal 0x4000001 (ptr 0xb0d34a14) [1], 0x0 (0x0), 0x0 (0x0)
Updated Jul 12 11:35:40.369
Prefix Len 24, traffic index 0, precedence n/a, priority 3
via b.b.b.2, 7 dependencies, recursive, bgp-ext [flags 0x6020]
path-idx 0 [0xb2200544 0x0]
next hop b.b.b.2 via b.b.b.2/32
RP/0/RSP0/CPU0:a9k6#sh cef vrf inet x.x.x.0/24 hardware egress
Thu Jul 13 16:44:01.928 CEST
x.x.x.0/24, version 6698698982, internal 0x4000001 (ptr 0xb0d34a14) [1], 0x0 (0x0), 0x0 (0x0)
Updated Jul 12 11:35:40.369
Prefix Len 24, traffic index 0, precedence n/a, priority 3
via b.b.b.2, 7 dependencies, recursive, bgp-ext [flags 0x6020]
path-idx 0 [0xb2200544 0x0]
next hop b.b.b.2 via b.b.b.2/32
RP/0/RSP0/CPU0:a9k6#sh cef vrf inet x.x.x.0/24 location 0/1/CPU0
Thu Jul 13 16:48:55.236 CEST
x.x.x.0/24, version 3115832151, internal 0x4000001 (ptr 0x8a147d64) [1], 0x0 (0x0), 0x0 (0x0)
Updated Nov 9 00:24:24.757
Prefix Len 24, traffic index 0, precedence n/a, priority 3
via a.a.a.2, 3 dependencies, recursive [flags 0x0]
path-idx 0 [0x90220fe4 0x0]
next hop a.a.a.2 via a.a.a.2/32
RP/0/RSP0/CPU0:a9k6#sh cef vrf inet x.x.x.0/24 hardware egress location 0/1/CPU0
Thu Jul 13 16:50:58.198 CEST
x.x.x.0/24, version 3115832151, internal 0x4000001 (ptr 0x8a147d64) [1], 0x0 (0x0), 0x0 (0x0)
Updated Nov 9 00:24:24.757
Prefix Len 24, traffic index 0, precedence n/a, priority 3
via a.a.a.2, 3 dependencies, recursive [flags 0x0]
path-idx 0 [0x90220fe4 0x0]
next hop a.a.a.2 via a.a.a.2/32
LEAF - HAL pd context :
sub-type : IPV4, ecd_marked:0, has_collapsed_ldi:0, collapse_bwalk_required:0, ecdv2_marked:0
Leaf H/W Result:
Physical Result: 0x11680600 (LE)
Raw Data0: 0x71800003 00000000 00000000 00000000
Raw Data1: 0x4e030000 00000000 00180000 00000000
leaf_resolve_control_byte0
reserved: 0 match: 1 valid: 1
txadj_internal: 0
recursive: 1
rec_fs: 1
leaf_resolve_control_byte1
fwd: 1 default_rte: 0
dc_rte: 0
ifib_lookup: 0
fast_switch: 0
feature_lkup: 0
igp_pref: 0 non_recursive: 0
leaf_resolve_control_byte2
more_features: 0
bgp_pa_valid: 0
fast_switch: 0
ecmp_size: 3
recursive_fwd_entry
ldi_ptr: 0x4e0300 (LE)
LSP Array union:
BGP Output label:
label_msb[0]: 0 label_lsb[0]: 0
exp[0]: 0 eos[0]: 0
label_msb[1]: 0 label_lsb[1]: 0
exp[1]: 0 eos[1]: 0
label_msb[2]: 0 label_lsb[2]: 0
exp[2]: 0 eos[2]: 0
label_msb[3]: 0 label_lsb[3]: 0
exp[3]: 0 eos[3]: 0
lsp_array_ptr: 0x0
bgp_policy_accounting: 0
as_number: 0
prefix_length: 18
QPPB Prec: 0 QPPB Prec_valid: 0
QPPB QOS Group: 0 QPPB QOS Group_valid: 0
REC-SHLDI HAL PD context :
collapse_bwalk_required:0, load_shared_lb:0
rLDI eng ctx:
flags: 0x1, rldi_table_idx: 0x34e, num_entries: 0x1, urpf_ptr: 0x0
rLDI HW data for path 0 [index: 0x34e (BE)] (common to all NPs):
Raw Data0: 0x11044004 737c0000 d94b5b22 00000000
ldi_resolve_control_byte0:
match: 1 valid: 1
ldi_resolve_control_byte1:
ext_lspa: 0 leaf_ip: 1
leaf_mpls: 0
ldi_resolve_control_byte2:
first_rldi: 1
label_offset: 4
label_block_offset: 0
Other fields:
leaf_ptr: 0x737c00(LE) bgp_next_hop: 0xaaa2
NextHopPrefix:a.a.a.2/32
Please use show cef or show mpls forwarding command again
with nexthop prefix specified for nexthop hardware details
I have tried several things to reprogram the LC but no success, the record is still stuck into the LC HW:
1) added back the static route towards a.a.a.2 and removed it
2) added a static route towards b.b.b.2
3) cleared route ipv4 unicast
4) removed the prefix x.x.x.0/24 from routing table
5) shut down the be1.10 interface
Has anybody encoutered enythig similar on their a9k boxes and how did you please solve the issue (other than LC reload)? Thank you.
Regards/S pozdravom,
Miroslav Sturmankin
Oddelenie sietovej architektury
SWAN, a.s.
Borska 6, 841 04 Bratislava
miroslav.sturmankin at swan.sk
More information about the cisco-nsp
mailing list