Saw something the other day I had never tripped across before.  Had to do with the advertising of a default route in OSPF with a route policy applied.  I was confused as to why something was happening, so I asked two co-workers (Steve and Robert) to join me in trying to figure it out.

Ready to play?

ASR9K – IOS XR 4.3(4),   ASR1K – IOS XE 15.4(2)S

As you can see above the design was that the ASR9K would send a default route, tagged with a 510, if and only if there was already a 0.0.0.0 in the routing information base (RIB). No 0.0.0.0 in the RIB? No sending default route.

PASS #1

When I’m trying to figure out “whodunnit” I tend to make multiple “passes”.  The goal of the first pass is really to get a good solid foundational look at the “crime scene”. Nature of the “crime”, the facts, the clues, the suspects.

The FACTS

• ASR9K has no 0.0.0.0/0 in the RIB
• ASR1K is getting the 0.0.0.0/0

Admittedly I was expecting to find a quick “smoking gun”. For example, a “default-information originate always” in the configs OR that there really was a 0.0.0.0/0 in the RIB somehow.

Nope. So let’s dig in a little deeper.

PASS #2

Since I troubleshoot in a lab environment, I have the luxury of playing with the configs.  So since I honestly have no idea why this is happening…

• Remove default-information originate route-policy ospf-default(510)
  • Result: As expected…. no 0.0.0.0/0 on ASR1K
• Add default-information originate to ASR9K but don’t include the route-policy
  • Result: As expected…. no 0.0.0.0/0 on ASR1K
• Put default-information originate route-policy ospf-default(510) back in
  • Result: ARG! 0.0.0.0/0 show up on ASR1K.

Solution?

You now have all the facts and clues needed to solve this “whodunnit”.   Thoughts? Ideas? 🙂

Categories: Network Detective, OSPF, Troubleshooting

Tags: conditional default route not working, default-information originate, network detective, OSPF, Troubleshooting