OSPF Design question/problem
Posted: Sun Jun 03, 2012 4:09 pm
The attached diagram shows a segment of my network that I'm having trouble with.
Yellow IP addresses are Loopback IP's attached to a Bridge called 'loopback'. (as per 'best practices')
The two RB450g's in the middle of the diagram are running bridges - called Backhaul - with the interfaces that connect to the M5's in that bridge (to minimize hop count).
ALL the RB450g's in the diagram are running OSPF. The two 450g's that are configured with Backhaul bridges are running OSPF on the IP that is attached to the Backhaul Bridge interface. They need to do OSPF because they attach to other segments.
All three RB450g's that are running as Routers have alternaet path to 0.0.0.0. However 10.255.255.33 is the preferred path due to latency and Bandwidth available at that end followed by 10.255.255.20, and lastly 10.255.255.45.
All RB450g's are running 5.16. All are running NTP synced to the same time source. All running Simple Authentication (not MD5).
All the UBNT M5's are in Client/AP-Bridge mode. (NOT WDS)
10.255.255.33 is DR (priority 99), and 10.255.255.20 is BDR (priority 85) and 10.255.255.45 is priority 75. The other two RB450g's are priority 0. All RB450g's are in Area 0. The are no ASBR's in this diagram.
I've tried both NBMA and Broadcast mode for OSPF.
In NBMA mode I never achieved convergence on ALL routers at the same time - the neighbors tab would show at least 2 of the 5 RB450g's with a 'router ID' of 0.0.0.0. State changes would not propagate, or if they did they were VERY slow.
Myself and two people checked the configurations of all the RB450g's at least 10 times. There was no reason why convergence should not have happened.
In Broadcast I'm seeing dozens of state changes an our as the multicast's get 'lost' (which is not unexpected I guess), causing breif periods of 'icmp unreachable' responses to running pings.
THIS TOPOLOGY WORKED before the link to the router at 10.255.255.45 was added a couple weeks ago - that required a Ethernet interface be added to the Backhaul Bridge at 10.255.255.65. NMBA started to fail then. I switched to Broadcast mode a couple nights ago because in NBMA mode the default route was disappearing at random times for 10 to 120 minutes at a time - often requiring one or more RB450g's to be rebooted.
I use NBMA everywhere else in the network - with similar topology, but this is the only segment where there are two RB450g's 'back to back' running as Bridges...
I'd REALLY rather not eliminate the bridges but I'm about ready to do just that... although I don't know if it'll help.
I'm open to suggestions
Yellow IP addresses are Loopback IP's attached to a Bridge called 'loopback'. (as per 'best practices')
The two RB450g's in the middle of the diagram are running bridges - called Backhaul - with the interfaces that connect to the M5's in that bridge (to minimize hop count).
ALL the RB450g's in the diagram are running OSPF. The two 450g's that are configured with Backhaul bridges are running OSPF on the IP that is attached to the Backhaul Bridge interface. They need to do OSPF because they attach to other segments.
All three RB450g's that are running as Routers have alternaet path to 0.0.0.0. However 10.255.255.33 is the preferred path due to latency and Bandwidth available at that end followed by 10.255.255.20, and lastly 10.255.255.45.
All RB450g's are running 5.16. All are running NTP synced to the same time source. All running Simple Authentication (not MD5).
All the UBNT M5's are in Client/AP-Bridge mode. (NOT WDS)
10.255.255.33 is DR (priority 99), and 10.255.255.20 is BDR (priority 85) and 10.255.255.45 is priority 75. The other two RB450g's are priority 0. All RB450g's are in Area 0. The are no ASBR's in this diagram.
I've tried both NBMA and Broadcast mode for OSPF.
In NBMA mode I never achieved convergence on ALL routers at the same time - the neighbors tab would show at least 2 of the 5 RB450g's with a 'router ID' of 0.0.0.0. State changes would not propagate, or if they did they were VERY slow.
Myself and two people checked the configurations of all the RB450g's at least 10 times. There was no reason why convergence should not have happened.
In Broadcast I'm seeing dozens of state changes an our as the multicast's get 'lost' (which is not unexpected I guess), causing breif periods of 'icmp unreachable' responses to running pings.
THIS TOPOLOGY WORKED before the link to the router at 10.255.255.45 was added a couple weeks ago - that required a Ethernet interface be added to the Backhaul Bridge at 10.255.255.65. NMBA started to fail then. I switched to Broadcast mode a couple nights ago because in NBMA mode the default route was disappearing at random times for 10 to 120 minutes at a time - often requiring one or more RB450g's to be rebooted.
I use NBMA everywhere else in the network - with similar topology, but this is the only segment where there are two RB450g's 'back to back' running as Bridges...
I'd REALLY rather not eliminate the bridges but I'm about ready to do just that... although I don't know if it'll help.
I'm open to suggestions