View Full Version : OSPF Issues
midsizewisp
10-27-2009, 01:06 PM
I don't know if this is related to some of the PPPoE issues people are seeing, but we are seeing some odd problems with OSPF. We swapped a 10.5 mile link that had been using Trango TLink-45s with two Rocket Ms using the same frequency and Airmax enabled. Ack is set to 15.7 miles.
OSPF had been fine with the Trangos but we are seeing it reset every few minutes with the Rockets. We've noticed some other odd OSPF issues on other links as well but dismissed it. Now it's looking like it is an issue.
If we make any changes to the Rockets, our OSPF session drops. We have to reboot the routers and/or the Rockets to get it to come back.
Any idea what could be going on?
twinkletoes
10-27-2009, 01:08 PM
setting ack too high can cause problems. lots of problems in my experience. get it close to 10.5 miles. i imagine you are using WDS mode too, right?
midsizewisp
10-27-2009, 09:48 PM
Yes, we are using WDS. ACK doesn't seem to affect the link.
UBNT-Edmundas
10-28-2009, 04:20 AM
I don't know if this is related to some of the PPPoE issues people are seeing, but we are seeing some odd problems with OSPF. We swapped a 10.5 mile link that had been using Trango TLink-45s with two Rocket Ms using the same frequency and Airmax enabled. Ack is set to 15.7 miles.
OSPF had been fine with the Trangos but we are seeing it reset every few minutes with the Rockets. We've noticed some other odd OSPF issues on other links as well but dismissed it. Now it's looking like it is an issue.
If we make any changes to the Rockets, our OSPF session drops. We have to reboot the routers and/or the Rockets to get it to come back.
Any idea what could be going on?
Please post your configuration files as well. Thanks!
ubntwifi
10-30-2009, 02:54 AM
Hi guys,
I have same problem. I have a ptp with rocket M Ver 5.0.2 in bridging and in each side I have a router Mikrotik with OSPF configured.
Now my problem is that OSPF link goes down for 1/2 ms every 1 or 2 hours and then came back up, even if seem that wifi link is up.
OSPF sends hello packet through multicast, so my question is: does rocket M have a multicast problem?
First of install rocket M products I have installed Mikrotik ptp, and I haven't OSPF problem.
I hope to receive an answer
Regards
UBNT-Edmundas
10-30-2009, 06:54 AM
Hi guys,
I have same problem. I have a ptp with rocket M Ver 5.0.2 in bridging and in each side I have a router Mikrotik with OSPF configured.
Now my problem is that OSPF link goes down for 1/2 ms every 1 or 2 hours and then came back up, even if seem that wifi link is up.
OSPF sends hello packet through multicast, so my question is: does rocket M have a multicast problem?
First of install rocket M products I have installed Mikrotik ptp, and I haven't OSPF problem.
I hope to receive an answer
Regards
Hello,
what is configured interval to send OSPF hello packets?
Is it correct that your link is not passing OSPF traffic for a half millisecond (1/2 ms) every 1-2 hours? Or you wanted to say, that link isn't passing any OSPF packet for 30sec and later it starts working again?
-Edmundas
ubntwifi
11-01-2009, 11:45 PM
Hi,
OSPF hello interval is 10 ms.
No, it isn't correct that OSPF isn't passing traffic for 1 or 2 ms (not half ms). I want to say that every 1 or 2 hours OSPF link goes down and then came back up, so I think that Rocket M5 has problem with multicast packet: is it possible?
With Mikrotik ptp I haven't this problem.
Best regards
UBNT-Edmundas
11-02-2009, 07:42 AM
Hi,
OSPF hello interval is 10 ms.
No, it isn't correct that OSPF isn't passing traffic for 1 or 2 ms (not half ms). I want to say that every 1 or 2 hours OSPF link goes down and then came back up, so I think that Rocket M5 has problem with multicast packet: is it possible?
With Mikrotik ptp I haven't this problem.
Best regards
1-2 milliseconds is very short time period. You see errors regarding OSPF on Mikrotik router boards? Or how do you know, that OSPF link goes down for 1-2ms?
ubntwifi
11-02-2009, 11:41 PM
Yes I have errors on mikrotik routers (see attachment). I think that OSPF must stay up always.
On the other ptp link with mikrotik radio I haven't this problem and OSPF goes down only when I reboot it.
So which is problem on Rocket 5? Multicast???
Regards
ubntwifi
11-02-2009, 11:44 PM
Sorry....attachment
http://www.prometeo.org/images/ForWeb/OSPF.jpg
midsizewisp
11-03-2009, 02:49 AM
That's exactly what our logs look like. We sent our configuration files to support.
Tamiris
11-03-2009, 07:27 AM
Actually, on couple of links w OSPF I stopped to use Rockets because same issue, and we lost already two important customers... I suppose ospf drops because of frequent ethernet drop/reset on Rocket. Ubiquty team, please re-consider the approach of this ethernet driver that restarts n times per day... it broke our business for nothing/ aka very "stupid" cause.
UBNT-Edmundas
11-03-2009, 07:47 AM
Yes I have errors on mikrotik routers (see attachment). I think that OSPF must stay up always.
On the other ptp link with mikrotik radio I haven't this problem and OSPF goes down only when I reboot it.
So which is problem on Rocket 5? Multicast???
Regards
Please send Support info files for deeper investigation from both RocketM5 devices to edmundas@ubnt.com
Thanks!
UBNT-Edmundas
11-03-2009, 07:54 AM
That's exactly what our logs look like. We sent our configuration files to support.
Please resend these files to edmundas@ubnt.com also don't forget to mention the problem or the link to this forum thread.
Thanks!
Hi,
I don't know if this is related to some of the PPPoE issues people are seeing, but we are seeing some odd problems with OSPF. We swapped a 10.5 mile link that had been using Trango TLink-45s with two Rocket Ms using the same frequency and Airmax enabled. Ack is set to 15.7 miles.
OSPF had been fine with the Trangos but we are seeing it reset every few minutes with the Rockets. We've noticed some other odd OSPF issues on other links as well but dismissed it. Now it's looking like it is an issue.
If we make any changes to the Rockets, our OSPF session drops. We have to reboot the routers and/or the Rockets to get it to come back.
Any idea what could be going on?
:icon_exclaim: We would like to use MSTP (IEEE 802.1Q-2003) via RocketM5 P2P bridge which also does not seem to work stable, yet. "Multicast Data: Allow All" is enabled on both devices of course.
:icon_arrow: Maybe that's also in relation to this problem... :icon_neutral:
-Florian
j.snopek
11-21-2009, 03:00 PM
Please resend these files to edmundas@ubnt.com also don't forget to mention the problem or the link to this forum thread.
Thanks!
Did they sent to you their configs? I have same problem but with quagga on linux. Only way how I'm able to start ospf is start quagga on both routers and after that I must restart both rockets between these routers. If I restart quagga after that I must restart both rockets again to allow multicasts. Chechbox Multicast Data: Allow All is checked on both rockets. Same problem is on nanostation m5 with airos 5.0.2. I don't know if is this problem on older airos, I don't test it, but I can, if you will want.
kozul
06-24-2010, 05:01 AM
We had some problems with OSPF after we changed existing equipment on our links with rockets M5. We use Mikrotik routers and since we started to implement Ubiquty rocket M5 this problem gave me much headache until I figured out what is going on. There are differences between the OS version on Rocket M5.
- On one link we have a pair of rockets M5 (Firmware Version:XM.v5.1.2 Build Number:3998) and there was no problem with OSPF on that link. Everything is working good with option Multicast Data - Allow All turned off.
- Later we changed equipment on the other link with another pair of rockets M5 but these were with new firmware (Firmware Version:XM.v5.2 Build Number:5132) and OSPF would not work at all. Mikrotik could not see any of OSPF neighbour. All the settings were the same as are on the first link and the only difference was the firmware.On this pair of rockets I had to turn on option Multicast Data - Allow all and after that OSPF is working good.
dragonfly
06-24-2010, 06:29 AM
Is there an update on this yet? We're having the same problems with only ONE of FOUR links. I don't see why.
UBNT-Mike.Ford
06-24-2010, 01:10 PM
Hey Guys,
I have asked my software team to follow up with you.
Thanks,
Mike
Have you tried 5.2.1 beta2 - http://www.ubnt.com/forum/showthread.php?t=19265 ?
wimaxwireless
06-24-2010, 03:13 PM
The OSPF issues are not only through the Rockets but I have tried bullets, nanobriges and rockets over the last week. The weired thing is we have the exact same configuration working at one sight on a rocket and can't get it working at the mirror sight.
However and this is where it gets weired, the mirror sight which has a good coonection was routed through a secondary sight that has a poor line of sight and is now working?????
All radios are on the latest firmware.
osnet
06-24-2010, 05:29 PM
We have a lot of circuit running OSPF with AIROS 3.x without problem also the with the Rocket but only with the version 5.2 beta 7 or beta 8 not with the 5.2 and the older ones.
boydsoftprez
06-25-2010, 06:24 AM
My mikrotik logs look exactly the same. I seem to have found a workaround (maybe). If you disable multicast in the ubnt radios then run your ospf neighbors point to point or point to multi point it seems to work ok... I have only been testing this approach for 24hours so I dont have concrete info yet.
http://wiki.mikrotik.com/wiki/Manual:OSPF-examples
lambert
07-27-2010, 10:36 AM
My mikrotik logs look exactly the same. I seem to have found a workaround (maybe). If you disable multicast in the ubnt radios then run your ospf neighbors point to point or point to multi point it seems to work ok... I have only been testing this approach for 24hours so I dont have concrete info yet.
How has this been working for you? I have similar issues which did not seem to improve with point-to-point. Running 5.2.1 beta 2, with AirMax on, I have had a neighbor association last 30 hours, but not longer, yet. Other days, it still drops out multiple times. It seems to drop out more often when we have rain. 6.9km/4.3mi link with -62 to -65 signal.
http://www.ubnt.com/forum/showthread.php?t=21871
jauer
09-30-2010, 02:49 PM
Have you found a resolution?
I'm having the same problem with a 7 mile link using PowerBridge M5s.
Smokeping shows no packet loss across the link in over 20 hours.
In that same period I have over 900 OSPF state changes.
I've disabled WPA thinking the AES rekey was dropping but that didn't help.
Link works great other than the OSPF drop problem...
dbedani
10-08-2010, 07:10 AM
Here I have 2 ptp link working with Nano Station M5, firmware XM.v5.2.
So, to have the hability to work with OSPF, i shoul disable the Airmax.
I donīt have problems anymore with neighbors OSPF... so, the M5 without Airmax, is just a normal nano station.. :S
Any news, release firmware?
Alfabi
10-08-2010, 08:59 AM
My mikrotik logs look exactly the same. I seem to have found a workaround (maybe). If you disable multicast in the ubnt radios then run your ospf neighbors point to point or point to multi point it seems to work ok... I have only been testing this approach for 24hours so I dont have concrete info yet.
http://wiki.mikrotik.com/wiki/Manual:OSPF-examples
im can confirm, OSPF with ptmp on MT working without any problem with on/off Airmax, inside ospf network
iellison
11-05-2010, 12:09 PM
Is there any timeframe in which to expect a real fix for this issue? We are rolling out several Rocket M5 links and I'm getting OSPF errors galore. All routers are Mikrotik. Same errors as has been reported already (MD5 Authentication errors, etc).
darren
11-08-2010, 06:53 AM
We are seeing the same OSPF issues on Mikrotik routers, any fix would be much appreciated, we are still seeing the problem putting ospf into pmtp mode.
Orbitalnet ltd:icon_frown:
UBNT-Edmundas
11-08-2010, 07:14 AM
We are intensively investigating these problems. At the moment there are no quick solution for it. Sometimes OSPF traffic gets lost between AP-WDS and STA-WDS devices, what initiates routers to change their routes. We hope to get it solved until v5.3 final release if we will be able to catch the problem.
-Edmundas
vlad8
11-08-2010, 07:15 AM
also look at your MT routers, we have had problems on different routers with different ROS version like 3.x and 4.x. Try to update each router to the firmware 4.13
UBNT-Edmundas
11-08-2010, 07:32 AM
also look at your MT routers, we have had problems on different routers with different ROS version like 3.x and 4.x. Try to update each router to the firmware 4.13
What was happening (what symptoms) in your network, when you have used older RouterOS versions, or different on some routers?
-Edmundas
vlad8
11-10-2010, 08:12 AM
the ospf reset every 5-10 minutes
twinkletoes
11-10-2010, 08:39 AM
is everyone with OSPF problems using NoACK by any chance?
i saw similar problems go away with NoACK disabled...
NZFoxnet
11-10-2010, 11:17 AM
I spent weeks on my OSPF issues - seemed to be all newer versions of AirOS and any version of ROS.
I did two things that fixed my issues.
1) I set all my OSPF interfaces to PTMP - The OSPF would drop 2-3 times a day instead of every couple of hours
2) I turned off auto negotiate on the lan interfaces in AirOS. My OSPF concurrency is now in the days.
Mike
iellison
11-11-2010, 10:21 AM
is everyone with OSPF problems using NoACK by any chance?
i saw similar problems go away with NoACK disabled...
Not using No Ack here, none of our PtP's are that long of a shot. NBMA seems to be more reliable thus far, but we of course would prefer to get back to PtMP / Broadcast.
autosoap
11-22-2010, 10:32 AM
We have a PtP link using rockets which are having similar problems. It seems to be occurring on links with little no traffic (backup links). I've tried turned airmax off which doesn't seem to have helped. OSPF is bouncing roughly every 10-15 minutes.
rebel2234
11-22-2010, 02:57 PM
We are intensively investigating these problems. At the moment there are no quick solution for it. Sometimes OSPF traffic gets lost between AP-WDS and STA-WDS devices, what initiates routers to change their routes. We hope to get it solved until v5.3 final release if we will be able to catch the problem.
-Edmundas
I did some preliminary testing to track this OSPF problem down and I will post here what I found. From the limited testing I did it seems it might be ARP related. I have attached an Image to help visualize. When using WDS we don't seem to have problems so I set out to see what was different when not using WDS.
Using AP/STA WDS:
When using this scenario everything works like it is supposed to. I can do a ping from Router A to network 10.10.11.1/24 with no problems. Looking at the ARP table on Router A I can see the "Correct" MAC addresses for all of the devices on the 192.168.1.0/24 network (Both UBNT devices and Router B's MAC address).
Using AP/STA without WDS:
When using this mode is where things go weird. When logged into Router A I cannot ping the 10.10.11.1/24 network but I can ping 192.168.1.2. A look at the ARP table on Router A says that: Both Router B and UBNT Bridge B have the same MAC address (00:15:6D:XX:XX:XX). Maybe Proxy ARP, IDK? I was able to get OSPF working with this mode by making the UBNT radios gateway into its directly attached router (like shown in the diagram). If I don't have the gateways set up as shown it will not work. Something I have noticed that is weird is when I have it working in this manner I do a ping from router A to 10.10.11.1 it will reply with double answers. Looked something like this:
Ping 10.10.11.1
Reply from 10.10.11.1: bytets=32 time=1ms
Reply from 192.168.1.12: bytets=32 time=1ms
Reply from 10.10.11.1: bytets=32 time=1ms
Reply from 192.168.1.12: bytets=32 time=1ms
Reply from 192.168.1.12: bytets=32 time=1ms
Reply from 10.10.11.1: bytets=32 time=1ms
Reply from 10.10.11.1: bytets=32 time=1ms
Reply from 192.168.1.12: bytets=32 time=1ms
Reply from 10.10.11.1: bytets=32 time=1ms
Reply from 10.10.11.1: bytets=32 time=1ms
Reply from 10.10.11.1: bytets=32 time=1ms
Reply from 10.10.11.1: bytets=32 time=1ms
Reply from 10.10.11.1: bytets=32 time=1ms
Reply from 10.10.11.1: bytets=32 time=1ms
After a few seconds it would stop doing double pings and just reply with the 10.10.11.1 and continue to run with out any problems. I could reproduce this problem by clearing the Dynamic ARP on both Mikrotik boxes, then the double pings would show up again and then clear up within a few seconds (after the dynamic arp entry for UBNT Bridge B in router A flushed).
RouterOS 3.30 and 2 RB433AH
2 UBNT NanoStation Loco M2's
Hope this helps!
ether3al
11-30-2010, 07:49 PM
I am having the same issue, just have pair of NSM5's in the lab at present but will be PBM5's in the field. I have an two Ethernet links and the UBNT link for this topology, Ethernet links are fine.
I have tried NoAck and AirMax off with no luck. I am running 5.3 beta 4 on both Nanos.
I keep getting:
*Dec 1 2010 15:13:46.355 AEDT: %OSPF-5-ADJCHG: Process 1, Nbr x.x.x.x on GigabitEthernet0/1.5 from FULL to DOWN, Neighbor Down: Dead timer expired
*Dec 1 2010 15:13:53.731 AEDT: %OSPF-5-ADJCHG: Process 1, Nbr x.x.x.x on GigabitEthernet0/1.5 from LOADING to FULL, Loading Done
*Dec 1 2010 15:14:38.987 AEDT: %OSPF-5-ADJCHG: Process 1, Nbr x.x.x.x on GigabitEthernet0/1.5 from FULL to DOWN, Neighbor Down: Dead timer expired
*Dec 1 2010 15:14:40.875 AEDT: %OSPF-5-ADJCHG: Process 1, Nbr x.x.x.x on GigabitEthernet0/1.5 from LOADING to FULL, Loading Done
ether3al
11-30-2010, 08:11 PM
Ok I have rolled back to 5.2.1 and the link is now stable...
We have 5.3 beta 3 working fine. Since its a broadcast issue, just set ospf to non-broadcast and define the neighbors. Not the perfect setup but it works. 2 rocket m5's with a quagga/linux and cisco router.
Any other way was overall unreliable, now we are at almost 2 weeks without a issue.
stejk2
12-30-2010, 07:25 AM
We are intensively investigating these problems. At the moment there are no quick solution for it. Sometimes OSPF traffic gets lost between AP-WDS and STA-WDS devices, what initiates routers to change their routes. We hope to get it solved until v5.3 final release if we will be able to catch the problem.
-Edmundas
I can confirm this issues. I have two rocket AP-WDS and STA-WDS firmware 5.2.1. I tried 5.3-beta4. Airmax Off. Sometime OSPF multicast traffic gets lost. I set configuration OSPF to non-broadcast (unicast) and define neighbors. This is OK. Problem is with packet lost OSPF multicast.
justin_s_h
01-04-2011, 06:23 PM
I can confirm this issues. I have two rocket AP-WDS and STA-WDS firmware 5.2.1. I tried 5.3-beta4. Airmax Off. Sometime OSPF multicast traffic gets lost. I set configuration OSPF to non-broadcast (unicast) and define neighbors. This is OK. Problem is with packet lost OSPF multicast.
This is an OSPF question, but does setting the neighbors disable any of the OSPF functionality? Is this simply a discovery problem that can be fixed by setting them?
Thanks
popcorrin
01-07-2011, 04:41 PM
Man I really appreciate the effort all you guys have put in to diagnosing this. I am thinking of using OSPF on my network but when I see issues such as this, it makes me hesitant.
It does irritate me that no one from ubiquiti has followed up on this issue. You would think this would be a concern they would want to address.
Calebcz
01-24-2011, 05:12 AM
Since its a broadcast issue, just set ospf to non-broadcast and define the neighbors. Thanks for posting this, finally it works (2xBulletM5 5.2.1 in WDS bridge).
oeyre
01-24-2011, 02:36 PM
We found that running BFD underneath resolved our issues without having to change modes.
If you are running Mikrotik routers simply run an EOIP tunnel across your backhaul link. Run your OSPF within that tunnel and all it right with the world.
If you are running Mikrotik routers simply run an EOIP tunnel across your backhaul link. Run your OSPF within that tunnel and all it right with the world.
EoIP has large overhead and should be avoided when possible.
Using a different OSPF discovery mode is a far better solution.
MT RouterOS also seems to have a "ptmp" OSPF interface network-type that looks interesting. It apparently is similar to NBMA (for maximum stability across wireless links) without having to specifically define NBMA neighbors. Their docs don't come right out and say it but I assume it uses unicast after neighbors have found each other.
UBNT-Matt
01-25-2011, 12:02 PM
Yes, we have seen that using NBMA w/ unicast it works a little better because otherwise when multicast packets drop or arrive out of order it causes OSPF issues.
We are looking at ways to make OSPF work better, but so far we have seen OSPF with NBMA to work better.
-Matt
Yeah EOIP does add some overhead but I have a couple links I am only loosing 5 megs or so. means the difference between 40 megs and 35 megs I can deal with that. I should not have to change my OSPF setup to accommodate software "issues". Really irks me.
I have not tired 5.3 yet. Maybe that will fix it all. I prefer to run all my backhaul links in point-to-point.
guibzh
04-05-2011, 12:05 PM
I would like to know if this issue is resolved on 5.3 firmware.
We are planing on enabling OSPF on our 5Ghz Airmax network.
Thank you
stejk2
04-05-2011, 12:11 PM
This issue is not resolved on 5.3 firmware.
Wifi442
04-05-2011, 12:21 PM
OSPF with NBMA is working great here over my rocket backhauls. Took a little while to get it figured out but now its fine. No problems at all.
sep78
04-05-2011, 12:41 PM
OSPF with NBMA is working great here over my rocket backhauls. Took a little while to get it figured out but now its fine. No problems at all.
It is not fixed in 5.3, NBMA is the only way we have it working too.
Bernardo
04-05-2011, 12:49 PM
OSPF with NBMA is working great here over my rocket backhauls. Took a little while to get it figured out but now its fine. No problems at all.
Yup, you're right, but since I switched off Airmax on all of my PtMP 5GHz backhaul links, OSPF even works with broadcast without a hitch.
Definitely a Airmax thing.
Switch Airmax back on, and OSPF starts re-associating its neighbors a few times a day.
Another thing I noted, was a significant decrease in ping times over those links, from 30ms - 40ms to 3ms - 4ms on a 40km link, same in most other cases. Overall responsiveness is way better now.
saludos
Bernardo
guibzh
04-05-2011, 02:08 PM
Well thank you for your feedbacks.
Any similar problems with other routing protocols EIGRP or BGP (even if it is using tcp)?
I heard about some issues with MPLS also (something with MTU size) is there anyone who could confirm that?
It would be great to have a list of unresolved issues somewhere (like on the wiki) to help people to make their choice concerning their network architecture design.