OSPF Redistribute Static won't install in routing table but in database

[Ryan Tian]

Here is the network

otherRouter-SiteArouter -- {Provider Allstream Switched Ethernet) -- SiteBrouter

                             |

                       router(10.96.20.16, which has 10.1.44.1/24 interface)   

Gi0/0 is Switched Ethernet interface facing provider

SiteArouter# 

interface GigabitEthernet0/0
ip address 192.168.254.130 255.255.255.0

SiteBrouter# 

interface GigabitEthernet0/0
ip address 192.168.254.1 255.255.255.0

I put two routers in OSPF area 0, they build OSPF neighbor through gi0/0. Any network statement on SiteArouter can be advertised to SiteBrouter, no problem, otherRouter's OSPF routes can pass through provider's network too.

The issue is: I have a valid static route on SiteArouter, it can be redistributed to otherRouter locally as OE2 normally, but on SiteBrouter, this route installed and will disappear after 5 seconds (I confirmed it every time to clear ip route *), and I can see it through  "siteBrouter# show ip os data external", just not in routing table!  

But otherRouter (as in topology) connecting to SiteArouter locally can receive OE2 normally! 

I followed this link and troubleshot and suspect Allstream Switched Ethernet issue, any idea? How do I talk/challenge them?

http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/7112-26.html

SiteArouter#

ip route 10.1.44.0 255.255.255.0 10.96.20.

router ospf 200

redistribute static subnets

======================

SiteBrouter#sh ip route os | i 10.1.44                      //no 10.1.44.0/24 route
SiteBrouter#clear ip route *
SiteBrouter#sh ip route os | i 10.1.44
O E2 10.1.44.0/24 [110/1] via 192.168.254.3, 00:00:03, GigabitEthernet0/0               //this route showed up after cleared routes
SiteBrouter#sh ip route os | i 10.1.44
O E2 10.1.44.0/24 [110/1] via 192.168.254.3, 00:00:06, GigabitEthernet0/0               //it will stay for 5 seconds
SiteBrouter#sh ip route os | i 10.1.44
O E2 10.1.44.0/24 [110/1] via 192.168.254.3, 00:00:08, GigabitEthernet0/0
SiteBrouter#sh ip route os | i 10.1.44
O E2 10.1.44.0/24 [110/1] via 192.168.254.3, 00:00:09, GigabitEthernet0/0
SiteBrouter#sh ip route os | i 10.1.44                                                                          //it disappeared/removed
SiteBrouter#sh ip route os | i 10.1.44
SiteBrouter#sh ip os data external

OSPF Router with ID (10.64.10.2) (Process ID 200)

Type-5 AS External Link States

LS age: 1762
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 10.1.44.0 (External Network Number )                                                  //it is still in database
Advertising Router: 10.96.10.2
LS Seq Number: 80000001
Checksum: 0xDD99
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 1
Forward Address: 10.96.20.16
External Route Tag: 0

[Ryan Tian]

Thank you the lab, it is exactly my scenario!

Forget my static neighbor, it worked because I removed network 10.96/11 as your first solution.

However,I have several routers need to build relation to SiteArouter through 10.96/11, so it will be your 2nd solution.

So I changed 10.96/11 to point-to-point and also another nei router 10.96.20.35, it won't build stable neighborship, up and down, I guess because it is NOT a point-to-point link, it is router subinterface then to switch VLAN, no direct connection.

Whenever I change it to broadcast, for sure neighbourship is fine but O E2 will be gone.

SiteArouter#

interface GigabitEthernet0/1.100
encapsulation dot1Q 100
ip address 10.96.10.2 255.224.0.0
no ip redirects
ip ospf network point-to-point
ip ospf 200 area 0

10.96.20.35#

interface GigabitEthernet0/1.100
encapsulation dot1Q 100
ip address 10.96.20.35 255.224.0.0
ip ospf network point-to-point
ip ospf 200 area 0

10.96.20.35#

*Apr 27 20:13:24.605: %OSPF-5-ADJCHG: Process 200, Nbr 10.96.20.2 on GigabitEthe
rnet0/1.100 from LOADING to FULL, Loading Done
*Apr 27 20:13:25.301: %OSPF-5-ADJCHG: Process 200, Nbr 10.96.20.2 on GigabitEthe
rnet0/1.100 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
*Apr 27 20:13:26.393: %OSPF-5-ADJCHG: Process 200, Nbr 10.96.10.2 on GigabitEthe
rnet0/1.100 from LOADING to FULL, Loading Done
*Apr 27 20:13:33.153: %OSPF-5-ADJCHG: Process 200, Nbr 10.96.10.2 on GigabitEthe
rnet0/1.100 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
*Apr 27 20:13:34.605: %OSPF-5-ADJCHG: Process 200, Nbr 10.96.20.2 on GigabitEthe
rnet0/1.100 from LOADING to FULL, Loading Done
*Apr 27 20:13:36.173: %OSPF-5-ADJCHG: Process 200, Nbr 10.96.20.2 on GigabitEthe
rnet0/1.100 from FULL to DOWN, Neighbor Down: Adjacency forced to reset

[Rolf Fischer]

That's why I asked for the "show ip ospf interface" output earlier. When you have several neighbors on segment 10.96/11, some of the options I mentioned are out of the question.

Generally there are two approaches: Set the FA to 0.0.0.0 or make SiteB router install the internal OSPF route to the non-zero FA. So I have a couple of questions again:

1) On SiteA router you have a static route pointing to 10.96.20.16 and you redistribute this route into OSPF. Is 10.96.20.16 also an OSPF neighbor? And if so, could you do the redistribution on that neighbor router instead?

2) On SiteB router you have a static route which overwrites the OSPF route for network 10.96/11. I have not yet understood why. Does the static route point to another next-hop than the OSPF route would?

3) Changing the OSPF network type on interfaces of the 10.96/11 segment should be the last resort solution when you have neighbors here. You have more than one neighbor, so point-to-point won't work. You could use point-to-multipoint (in this case you should adjust the timers as well) and this has to be consistent on all interfaces of the neighbors on this segment. You don't have to change the network type of interfaces in other segments. Again, this should be the very last resort solution and we should discuss the details before you implement it. But let's try to find a better option first.

[Ryan Tian]

Thanks Rolf,

1) On SiteA router you have a static route pointing to 10.96.20.16 and you redistribute this route into OSPF. Is 10.96.20.16 also an OSPF neighbor? And if so, could you do the redistribution on that neighbor router instead?

10.96.20.16 is ASA, not in OSPF. I put it in OSPF before but it will receive a lot of "O" routes, that customer doesn't want to see those, and distribute list is not in ASA 8.4, don't have to plan to migrate to 9.2 which support that. I also tried to use 10.1.44.0 to build new area 144 but that will bypass ASA which i don't want. Another solution is to create extra interface to build OSPF nei with SiteArouter and use area filter to block other "O" routes, but I need to get permission to add interface. So it is better to just use pure static for ASA.

2) On SiteB router you have a static route which overwrites the OSPF route for network 10.96/11. I have not yet understood why. Does the static route point to another next-hop than the OSPF route would?

My OSPF is new, other production traffic relies on the static routes. So I can make any change on OSPF but not static routes. SiteBrouter 10.96/11 's next-hop is HSRP virtual IP of SiteArouter's provider side (in OSPF world, it should .2 or .3 the physical IPs)

siteBrouter# sh ip route | i 10.96
S 10.96.0.0/11 [1/0] via 192.168.254.1

3) Changing the OSPF network type on interfaces of the 10.96/11 segment should be the last resort solution when you have neighbors here. You have more than one neighbor, so point-to-point won't work. You could use point-to-multipoint (in this case you should adjust the timers as well) and this has to be consistent on all interfaces of the neighbors on this segment. You don't have to change the network type of interfaces in other segments. Again, this should be the very last resort solution and we should discuss the details before you implement it. But let's try to find a better option first.

Yes, I tried put point-to-multipoint on SiteArouter yesterday but didn't work out, maybe need more details.

===========================

Since I know where the issue is, I am considering to create a new subinterface for all OSPF devices (they are physically connected in trunk port), create some small network like /29, then all OSPF neighborship build on that and I should discard 10.96/11 and 10.64/11 for both sites for OSPF.

============================

update: my new idea may not work because static route 10.96/11 is always on siteBrouter and ASA 10.96.20.16 is the entry for 10.1.44.0/24, I guess new OSPF neighborship still get the same issue we have now... :(

[Rolf Fischer · Accepted solution]

Hm, this is really tricky ...

At least I understand now why it is as it is, thanks for the additional information.

Well, I know a way to trick this FA rules but it is quite ugly. Of course I cannot recommend something like this for production environments, but it may be used as a temporary workaround in a migration scenario like yours.

I guess you are familiar with the concept of recursive routes? The next-hop IP of a route belongs to a subnet, and there is no connected interface for this subnet. So a second routing-table lookup is needed in order to determine the exit-interface.

On SiteA router you could do something like this:

no ip route 10.1.44.0 255.255.255.0 10.96.20.16
!
ip route 10.1.44.0 255.255.255.0 192.168.1.1
ip route 192.168.1.1 255.255.255.255 10.96.20.16
!
SiteA#show ip cef 10.1.44.0 255.255.255.0
10.1.44.0/24, version 16, epoch 0
0 packets, 0 bytes
  via 192.168.1.1, 0 dependencies, recursive
    next hop 10.96.20.16, FastEthernet1/0 via 192.168.1.1/32
    valid glean adjacenc

192.168.1.1/32 is just an example, just use a private network which does not exist in your routing domain. Do not propagate this network in OSPF (no network statement).

So routing for 10.1.44/24 towards the ASA will continue to work localy but SiteA router (ASBR) will now set the FA to 0.0.0.0 and SiteB router can skip the check.

SiteB#show ip ospf database external 10.1.44.0
            OSPF Router with ID (10.64.10.2) (Process ID 200)
                Type-5 AS External Link States
  Routing Bit Set on this LSA
  LS age: 206
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.1.44.0 (External Network Number )
  Advertising Router: 10.96.10.2
  LS Seq Number: 80000002
  Checksum: 0xC130
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 0.0.0.0 <<<<<<<<<<<<
        External Route Tag: 0

[Ryan Tian]

Thanks Rolf,

it is amazing, just works! Let it work this way at this moment.

Yes, it is pretty ugly :-)

I really don't know when I can get rid of /11, so I will try to persuade ASA customer to create a new interface/IP then I can build neighbourship correctly, all other OSPF routers I have full control. 

I had ignored OSPF FA which I shouldn't, nowI learned and understood OSPF better, also the recursive route - never used before. Thanks again!

[Rolf Fischer]

Ryan, you're welcome! Thanks for using the rating system :)

[Ryan Tian]

Hi Rolf,

Report you back :-)

I removed the HSRP facing providers, no static routes leaking out. So I removed those tricky recursive routes and all back to normal now. Thanks again!

[Ryan Tian]

SiteBrouter# sh ip os data exter 10.1.44.0

OSPF Router with ID (10.64.10.2) (Process ID 200)

Type-5 AS External Link States

LS age: 1758
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 10.1.44.0 (External Network Number )
Advertising Router: 10.96.10.2
LS Seq Number: 80000029
Checksum: 0x4CEF
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 10.96.20.16
External Route Tag: 0

SiteArouter#sh ip os data exter 10.1.44.0

OSPF Router with ID (10.96.10.2) (Process ID 200)

Type-5 AS External Link States

LS age: 1966
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 10.1.44.0 (External Network Number )
Advertising Router: 10.96.10.2
LS Seq Number: 80000029
Checksum: 0x4CEF
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 10.96.20.16
External Route Tag: 0