Hi, We have a few cases of this right now pending a maintenance window to resolve:
https://bst.cloudapps.cisco.com/bugsearch/bug/cscui93977 Sent from my iPhone > On Jul 13, 2017, at 5:02 PM, Šturmankin Miroslav > <miroslav.sturman...@swan.sk> wrote: > > 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.sturman...@swan.sk > _______________________________________________ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/