those of you working on a daily basis with configuration and reconfiguration of network devices are likely to hit various caveats and surprises. sometimes, we hit problems that take hours to troubleshoot.

route? what route?

we’re adding new router. it has address of 172.16.0.11 that’s defined on Loopback0. this interface and all other physical interfaces of new router are included in area 0 of OSPF. neighbors see it that way as well:

RP/0/RSP0/CPU0:XR-RTR#sh route 172.16.0.11

Routing entry for 172.16.0.11/32
  Known via "ospf 0", distance 110, metric 3, type intra area
  Routing Descriptor Blocks
    10.128.0.20, from 172.16.0.11, via FortyGigE0/0/1/0.172
      Route metric is 3
  No advertising protos.

everything is OK, but the services tied to this interfaces (like BGP or LDP) don’t want to work. they won’t because… it seems that address is unreachable:

RP/0/RSP0/CPU0:XR-RTR#ping 172.16.0.11
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.11, timeout is 2 seconds:
.....

it’s weird, as it’s directly visible via FortyGigE0/0/1/0.172 interface:

RP/0/RSP0/CPU0:XR-RTR#sh run int FortyGigE0/0/1/0.172
interface FortyGigE0/0/1/0.172
 ipv4 address 10.128.0.21 255.255.255.254

the matter seems abstract - routers are directly connected to each other, everything else works but the new service (and in fact the new router) - does not. what to do here?

an important premise is to capture traffic on the new router side. ha! no traffic targeted at address assigned to its Loopback0 is visible to the new router!

ghosts?

in such situations, the only option left is to delve into the depths of IOS XR and how it constructs the forwarding table (FIB). let’s take a look at the CEF table:

RP/0/RSP0/CPU0:XR-RTR#sh cef 172.16.0.11 detail
172.16.0.11/32, version 0, broadcast
  Updated Nov 29 22:26:16.968
  Prefix Len 32

weird. the configuration is fresh (April), yet the entry made it to the CEF table back in November last year? how is that possible? let’s check more closely:

RP/0/RSP0/CPU0:XR-RTR#sh cef 172.16.0.11 internal

IPv4:default:0xe0000000[0x9d4a3294]:interface:172.16.0.11/32[ref:1 proto:ipv4 flags:0x1010001 f2:0x0 src:interface][0xa4470724]
  LDI:[ref:2 pl:a70d2e5c proto:ipv4 type:ip lvl:1 buckets:1 slots:1 fixup:0 flags:[owner locked, added to pl, depth changed]][0x9de44a10]
    slots:
    {0,p0,s0}={
      nhinfo:[type:special, linkt:link_IPv4, nh_proto:IPv4, ifh:NULLIFHNDL, spl:broadcast, flags:[owner locked, special]][0x9d3db180]
    }
    buckets:
    {0,p0,s0}={[0x9d3db180]}
  LDI_LW:[type:ip loadinfo:[0x9de44a10]][0x9dee81a8]
  PATHLIST:[ref:1 count:1 depth:1 ldi:9de44a10 type:Unspecified flags:[]][0xa70d2e5c]
    0={
      [[nh:0.0.0.0 ifh:TenGigE0_0_2_3(0x4000780) tbl:0xe0000000 type:ip flags:[none]]
      [depth:1 flags:[resolved,ldi-preferred] resolves-via: ###
        nhinfo:[type:special, linkt:link_IPv4, nh_proto:IPv4, ifh:NULLIFHNDL, spl:broadcast, flags:[owner locked, special]][0x9d3db180]
    ###]}

…everything seems very complicated, but it holds the solution to the puzzle. currently it seems, CEF believes that the route should be programmed through the interface TenGigE0/0/2/3. how is that possible? let’s see what’s happening there:

RP/0/RSP0/CPU0:XR-RTR#sh run int te0/0/2/3
interface TenGigE0/0/2/3
 ipv4 address 172.16.0.9 255.255.255.252

and everything becomes clear. the /30 mask causes the ’new’ address 172.16.0.11 to be advertised by OSPF, but we cannot send traffic to it since it is a broadcast address on one of the active interfaces.

summary

utilize IPAM. even if that’s Excel, ensure it’s properly organized Excel :)