OSPF doesn't notice some Address changes

xxiii · April 19, 2007, 4:44pm

2.9.42 routing-test.

I haven’t confirmed if this is still a problem in 3.0 beta yet, but we have noticed that when OSPF starts it sets up a neighbor relationship with itself and picks one if its own interface addresses as the designated router for this relationship.

If the address it picked is subsequently removed from the IP Address list, OSPF continues to use it. As a consequence the router refuses to route traffic to the relevant network (now being advertised from elsewhere in the network) because it appears that the OSPF process still believes it is a locally connected network. The correct route does appear in the IP routes list, and shows as coming from OSPF, but it refuses to go active. There are no other instances of routes relevant to that network present in the list.

One can either duplicate it as a static route and it will work, or just reboot the router so that OSPF will now pick a “valid” address for itself.

quasi-related questions:
Is there a way to reset/restart the OSPF process other than deleting/recreating its interfaces or rebooting the router?

Can it be made possible (or is it already possible somehow) to force which IP address OSPF will use for internal purposes? (for instance, if the Router-ID matches a local address, it could prefer that?)

janisk · April 20, 2007, 2:46pm

i cannot recreate that problem you just mentioned all routing table was updated correctly.

also you could check if that happens if you set up Router ID in ospf settings

could you be more specific on how to recreate that problem step by step?

like:

/sys reset
/ip ad ad ad=x.x.x.x
…

n) ip ad p
n+1)ip ad remo y

xxiii · April 25, 2007, 9:15pm

I have discovered that this only happens in routing-test and not routing (in 2.9.42). On a router using routing package, disabling the address that OSPF is using for itself immediately causes OSPF to pick a new one; in routing-test it continues to use the disabled one.

I haven’t the resources to test this at the moment using unconfigured routers, but this should theoretically show the problem (2.9.42 routing-test). Also, i’m not actually sure you need the loopbacks or the router-id explicitly set (but, you answer your question, yes, we’ve explicitly set the router-id), but this most closely mimics the situation where we saw this. Also, the router with the problem was a PC-based router, I don’t know if the problem occurs on routerboard based routers or not.

(to save time if you only want to see the part where OSPF doesn’t notice that an address its using is no longer valid you can probably just omit the router-b part of this and just see if ospf notices the address change on its 2-way on router-a first).

router a:
ether1 172.16.1.1/30
loopback0 (a bridge with no interfaces) 192.168.1.1
ospf set router id to 192.168.1.1 and add ether1 interface
add route filter on ospf-in passthrough that sets preferred-source to 192.168.1.1 (don’t know if this is relevant to the problem or not)

router b:
ether1 172.16.1.2/30
loopback0 (a bridge with no interfaces) 192.168.1.2
ospf set router id to 192.168.1.2 and add ether1 interface
add route filter on ospf-in passthrough that sets preferred-source to 192.168.1.2

Connect routers together via ethernet1’s
verify ospf running, OSPF neighbors something like:
RouterID Address State
192.168.1.1 172.16.1.1 2-Way (self)
192.168.1.2 172.16.1.2 Full (the other router)

and on router-b
192.168.1.2 172.16.1.2 2-Way (self)
192.168.1.1 172.16.1.1 Full (the other router)

Now, on router a change:
eth1 10.0.0.1/30

on router b:
eth 1 10.0.0.2/30
eth 2 172.16.1.1/30

Now, note on both routers that the Address column for the 2-Way link still shows the 172.16.1.x address.
Furthermore router-a should be seeing a 172.16.1.0/30 network in its routing table coming from the ospf advertisement from router b, but it won’t go active because its still using 172.16.1.1 as its address in the 2-Way neighbor entry even though that is no longer a valid address for router-a.

Also, they may now be trying to still establish the OSPF link using the old subnet, and one side may be stuck in ExStart. (I just altered another real world pair, and both sides are now stuck in ExStart, showing the Address as the one from the “old” subnet, now disabled on both sides.) Re-enabling the old subnet allowed the neighbor state to transition from ExStart to full. It appears the only way to fix this is to disable/delete the old subnet on both sides, then reboot both routers (or possibly delete all ospf interface and recreate them, which I suspect kills off the ospf process).

In short, the problem seems to be that OSPF doesn’t notice when the address its chosen to use for the 2-Way with itself is no longer valid/has changed. This doesn’t seem to affect the actual functionality any unless a subnet involving the relevant address is now being advertised from elsewhere in the network. When thats the case, it acts like its still a locally connected subnet, even though it does not show up as connected in the routing table, and does not show in the address list.