I have three routers. Router A is the gateway to the internet. Routers B and C are remote connected through a wireless link.
OSPF has been running fine on this network segment for years.
Today, suddenly, the ospf falls apart.
Router A says routers B and C are neighbors.
Routers B and C do not show A as a neighbor and no routes are exchanged. I have torn the entire ospf config apart and re-entered it and still no go.
Anyone seen this before?
Can you ping the other routers reliably? I have been using OSPF also for years in my network and have not seen a problem exactly like that. But sounds like your getting one way communication though one of your links.
My links are running well both ways.
When I turn on debugging in the logs, I see hellos going out from routers B and C towards A, A receives the hello’s
but never responds to them and doesnt log any errors. It’s obviously hearing them since A is inserting B and C as neighbors.
This started happening in two locations in my network, 50 miles apart, at about the same time today after a major link went down causing a great big route flap system wide. I have rebooted and even upgraded the firmware on one router set to the latest version 6 candidate. Still no adjacency.
While I still cannot say why these ospf links decided to go sideways, I have found a solution so I post it here for others to use.
I went and configured the links in question as nbma links. That cleaned it up immediately. Why they would work in the default multicast mode for several years
and suddenly go off, I have no idea. But this solves it.
Other multicast streams in the environment (especially if they use the same address) or blocking of multicast inadvertently can tear down OSPF. I’ve seen both happen numerous times.
Are you using switches that are capable of IGMP snooping?
No switches at all. Routers are linked with Ubiquiti Rocket wireless links. Its highly weird.
I am racing throughout my network changing links in order to kwwp things working.
Which firmware are you running on the Rockets? Do you have administrative control of the Rockets? Or is that another department? There is a setting for multicast on the Advanced tab. If someone changed the setting, it could have blocked the OSPF multicast traffic. Older AirOS firmwares had issues passing OSPF. Sometimes it worked, sometimes not. StarOS had the same issues. As I understand it MikroTik has had similar issues.
The work around is to run NBMA or Point-to-Point OSPF network type on wireless links. My network uses OSPF point-to-point across all wireless backhauls. Works well. With older versions of AirOS, we still had occasions of one end getting out of sync, but it would reconnect.
AirOS 5.5.2 and up is much better. I’m seeing neighbor associations last until something actually happens to the link. I have no idea if OSPF multicast traffic behaves better with the newer firmware. I’m perfectly happy running non-multicast OSPF across my wireless links. Point-to-point requires less link specific configuration than NBMA which means the OSPF configs are simpler. So I use that where I only have two devices on the segment.
We are now suspecting that it may be a firmware bug in the Ubiquiti that they say is fixed in 5.5.4, we have been running 5.5.2 and 5.5.3. I agree that nbma is the preferred fix, but thats a big project as we have 140+ tower locations and some of the feeds are point to multipoint which makes switching to nbma a challenge, but its one we are going to have to deal with.
bney -
You may have just solved the SAME issue for me.
I could not get OSPF to run over a PtP link with RocketM5’s running v5.5.6 with multicast enabled in Advanced.
Also have another PtP link with the same issue, RocketM5’s running v5.5.4 - multicast enabled in Advanced.
Changed to NBMA and right up they came.
Thanks!
That wireless link as NBMA definition is nothing new. When I set OSPF up for my network then I recall as having read some advice to do just that. The main WIKI is silent, but examples do state it: http://wiki.mikrotik.com/wiki/Manual:OSPF-examples#NBMA_networks