NSSA external type-1 route won't propagate to area 0?

Unanswered Question

Greetings.


We have two data centers. At each location, at the outside edge, is a firewall. Just inside of the firewall is a distribution router (ABR). Just inside of the distribution routers are the Core routers, which have Gig links to each other. Those gigs are the primary flow between the DCs.


Previously, the default-route was simply a static on each Distribution router pointing to their respective firewall. Obviously, this isn't very dynamic since that will stay in the table even if the firewall's outside interface goes down.


Last weekend, I removed the static default-routes. I then made the link between each firewall and their connected distribution router an OSPF NSSA area. I then had the firewall inject a default route by this command: "area 10.17.10.48 nssa default-information-originate metric-type 1".


When this was completed at each location, I saw a full adjacency form. I then saw a default route in the table of each distribution router, learned from their connected outbound firewalls.


Strangely, when I went on the core routers at either data center, I did "sho ip route 0.0.0.0" and got a response of "subnet not in table"


Since this was a full internet outage, I didn't have much time to troubleshoot. I added a "default-information originate" to each distribution router, assuming that if the distribution saw a default-route in its table, that it would propagate it. This still did not fix it.


The firewall learned every core route from distribution, and distribution learned the default from the firewall. I just can't figure why either default wouldn't propagate into area 0.


Our core is kept very simple - there are no filters there. Frankly, I've baffled. I finally had to put the statics back on to get the late-night people back out to the internet.


Any insight here would be appreciated. I have all weekend to look at this.


Thanks in advance for any help!


CWB

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
royalblues Sat, 09/30/2006 - 05:44
User Badges:
  • Green, 3000 points or more

can you post the network diagram of your setup


Narayan

vladrac-ccna Sat, 09/30/2006 - 06:02
User Badges:
  • Silver, 250 points or more

Did you try "default-informatin originate always" on the D routers?


Is it possible to give us more details on the configs and output of show ip route in the 4 routers?


mainly:

show ip ospf database external 0.0.0.0


This looks like a FW add reachability (not know as O or OI) problem.


Let us know.

Vlad

vladrac-ccna Sat, 09/30/2006 - 06:47
User Badges:
  • Silver, 250 points or more

btw: FW add is "foward address " not firewall address>


you can find it on the output of "show ip ospf database external"


Vlad

sundar.palaniappan Sat, 09/30/2006 - 18:09
User Badges:
  • Green, 3000 points or more

Cliff,


The core routers probably do not have a route to the forwarding address of the default route and that's why they do not install the route in the routing table.


Can you configure the following command on the distribution routers (ABR) under the OSPF process.


area (area-id) nssa translate type7 suppress-fa


Let us how you did.


HTH


Sundar

thanks for the help and input, everyone. I did some testing during the maintenance window.


One thing I established: The forward-address was showing as 0.0.0.0 in the database for nssa-external (seen from the distribution router). If the firewall had been sending the proper forward-address of 10.17.10.53 for that route, I think this would have been working. I looked on the Core router and it already know where 10.17.10.53 was.


I read an older CCO article about NSSA routers not putting the correct forward-address in their LSA when the network that it points the default-route to isn't in the table. Just for fun, I put the firewall's outside interface into the NSSA area, but it didn't fix anything.


I worked with Cisco TAC and after a couple hours of being puzzled, TAC was able to reproduce it in their lab using the same devices and the same code.


As it turns out, there is a bug in Cisco PIX code that causes the PIX to improperly send the forward-address in the LSA as 0.0.0.0. It is an internal bug notification - I couldn't find it published. Our PIXes run 6.3.3. The TAC upgraded their PIX to 7.2.1(12) and the forward-table problem was fixed.


I plan to upgrade the PIXes in the next maintenance window if it works in the lab for me.


I hope this info helps everyone, and thanks for the help and input!


CWB

Actions

This Discussion