OSPF advertising phantom route

choudhury.amd1 · ‎08-26-2015

Hello,

Please can someone help me with an issue I'm seeing on my core network. We have ASR 9K's throughout our core network and we are using OSPF as our IGP. The problem we have is basically a prefix is being advertised by one of our routers (according to all other core routers) that does not exist, lets for arguments sake say:

192.168.1.0/26 is the correct prefix which originates from router A,

all the other routers B, C and D can see this prefix in the routing table (which it rightly should)

but they also say there is a more specific route 192.168.1.32/27 which is also being advertised by router A.

Now as you can imagine if external traffic is coming in from router B, C or D and is destined for the IP 192.168.1.2, then it is routed and all is OK.

But if external traffic is coming in from router B, C or D and is destined for the IP 192.168.1.34, then the phantom route of 192.168.32/27 is used which according to router B, C and D is being advertised by router A, but this will not get routed by router A as it does not have this prefix in the routing table.

Has anyone ever seen this bug in OSPF or IOS-XR and if so how do I correct this?, Cisco TAC is asking me to clear ospf routes on router A but I am slightly sceptical as I looked through router A's complete ospf database and this phantom route 192.168.1.32/27 does not exist. In fact there is no mention of 192.168.1.32/27 anywhere on router A. My problem is all the other routers in my network is saying that router A is advertising this phantom route but according to router A this phantom route does not exist, so even if I clear ospf routes in router A this will not fix the issue. Any ideas would be greatly appreciated, many thanks.

regards

Ahmed

Peter Paluch · ‎08-26-2015

Hi Ahmed,

I haven't seen a similar problem yet but let's take it one step at a time.

With OSPF, every route present in the routing table that comes from OSPF must be derived from some LSA in the link-state database, and that LSA in turn was originated by some particular router. The first task therefore should be to find out which router is putting this phantom route into an LSA and why.

The show route output should indicate what is the Router ID of the router that originally enters that route into one of its own LSAs:

RP/0/0/CPU0:R3# show route 1.1.1.1/32
Thu Aug 27 01:23:15.619 UTC

Routing entry for 1.1.1.1/32
  Known via "ospf 1", distance 110, metric 3, type intra area
  Installed Aug 27 01:20:31.580 for 00:02:44
  Routing Descriptor Blocks
    10.0.23.2, from 10.255.255.1, via GigabitEthernet0/0/0/0
      Route metric is 3
  No advertising protos.

Here, it is 10.255.255.1 (OSPF Router ID) that originates information about the network 1.1.1.1/32. So the particular LSA of this router that contains this network can be listed depending on the route type:

If the route type (indicated in green) is intra-area, use show ospf database router adv-router 10.255.255.1 and show ospf database network adv-router 10.255.255.1 to list all LSA-1 and LSA-2 originated by 10.255.255.1. One of them must contain this network.
If the route type is inter-area, use show ospf database summary adv-router 10.255.255.1 or perhaps even better show ospf database summary 1.1.1.1 to list either all LSA-3 originated by 10.255.255.1, or just the one describing the 1.1.1.1.
If the route type is external, use show ospf database external adv-router 10.255.255.1 or perhaps even better show ospf database external 1.1.1.1 to list either all LSA-5 originated by 10.255.255.1, or just the one describing the 1.1.1.1. Replace external with nssa-external if the network is learned as an NSSA prefix in an LSA-7.

Depending on this output, you would need to inspect the configuration on 10.255.255.1 more closely. As a rule, if the phantom network is indicated in an LSA-1 (router-LSA) or LSA-2 (network-LSA) then the router believes that network is directly connected. If the network is indicated in an LSA-3 (summary-LSA) then the router is an ABR and believes to have learned the network from another area. That another area would then need to be inspected in a similar way to find the source of that network. If the phantom network is indicated in an LSA-5 or LSA-7 then the router believes it is an ASBR and redistributes this network into OSPF from some other source.

There is a remote possibility that a router indicated this network in some of its LSAs while it does not really have a reason for doing so. This could have happened if that network existed before and does not exist now but the router "forgot" to reoriginate its corresponding LSA to omit that network. However, this would be a bug, and truly a very improbable one. Nonetheless, even so, that network absolutely must be first present in an LSA if it's still being learned, and it is very important to locate that LSA and its originating router.

Looking forward to hearing from you!

Best regards,
Peter

choudhury.amd1 · ‎08-27-2015

Hi Peter,

Many thanks for your reply, I have taken the steps that you have suggested but unfortunately all the routers are saying router A is advertising it as intra area route, but I have checked ospf database on routers that say this route is inject by router A and tried to find the LSA with no luck, the LSA just does not exist even though it's reporting that it does. I have also check router A's ospf database and cannot see this phantom route anywhere.

I think this is a bug.. why ? let me explain:

the original prefix was a /27 prefix, lets say like this 192.168.1.0/27, but we need to grow this prefix into a /26. So since we had the next available /27 free we decided to make this prefix into 192.168.1.0/26

so basically this happened 192.168.1.0/27 changed to 192.168.1.0/26

After we made this change the new prefix of 192.168.1.0/26 got advertised to the rest of the core routers and we thought all is well, until we started to use higher end of the 192.168.1.0/26 prefix we saw that the higher IP addresses from the block was not being routed to the Internet. Why? because all the cores had a more specific route to anything above .32, which is this prefix 192.168.1.32/27 (phantom). All cores are saying router A has this prefix but router A says it doesn't know anything about this prefix.

I'm pretty sure it's a bug and as explained previously TAC is asking me to clear OSPF routes on router A. But my question is if router A does not have any remnants of this phantom route within it's ospf database then how is clearing ospf routes in router A going to remedy the problem?

Regards

Ahmed

Peter Paluch · ‎08-27-2015

Hi Ahmed,

I completely agree with you - clearing the routing table is most probably not going to help. OSPF propagates LSAs, not routing table entries, and clearing a routing table is not going to affect the contents of LSAs. Clearing the OSPF process on router A could help but of course, it is a disruptive action and will cause transient outage.

But let me ask you: Do you believe you could post the output of the following three commands for me?

show route 192.168.1.0/27
show ospf database router adv-router router-A-RID
show ospf database network adv-router router-A-RID

If nothing else, I would love to have a look at the LSAs originated by your router A.

Best regards,
Peter