cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
241
Views
15
Helpful
5
Replies
Highlighted
Enthusiast

OSPF Design Considerations for Broadcast Networks

I’m designing an OSPF network for a new VPLS cloud. I’ve done this before using a /24 for the interface uplinks to the VPLS. I’m curious if anyone has experience with larger (or even this large) of a subnet for OSPF broadcasts.

 

We have around 100 routers running OSPF, all in area 0. Not the best design, I know - but until we can redesign the entire network we’re stuck with it. The VPLS deployment will be for edge devices and I’d like to know if anyone has had successful deployments with 100+ routers in a single broadcast and OSPF area.

 

Routers are ISR 4331 and ASR 1004s (for the DR and BDR).

 

Thanks in advance!

5 REPLIES 5
Hall of Fame Expert

Re: OSPF Design Considerations for Broadcast Networks

Hello rlyons989,

if the VPLS service supports the use of 802.1Q Vlan tags you can divide the 100 routers in four groups using subinterfaces.

In the past I have seen backbone Vlan in a POP with 50 devices in the same subnet.

To be noted OSPF DR election is not pre-emptive if an OSPF DR is already elected a new device with highest OSPF RID and highest priority cannot take over as a result of this the OSPF DR can be the device with the highest uptime.

In that case the OSPF DR was a Sun workstation speaking OSPF for this reason.

All the effort is on the DR and BDR nodes that must mantain 100 OSPF adjacencies.

If the VPLS service does not support the use of Vlan tags, there is no other choice then keeping all devices in the same broadcast domain.

 

Hope to help

Giuseppe

 

Enthusiast

Re: OSPF Design Considerations for Broadcast Networks

Thanks Giuseppe!  I appreciate the quick reply!

Yes the VPLS supports VLAN tags.  One option includes creating a /29 for each remote site and making a mini-broadcast network consisting of the (1) remote site and (3) hubs.  The concerns I see with this design are...

  1. Requires a lot more configuration - an additional sub-interface on each of the (3) hubs for each remote site.
  2. Increased risk because changes need to be made to each every hub whenever a new site is added
  3. Greater VLAN and private IP space consumption
  4. If every remote site to hub sites link remain in area 0, then all we've done is reduce the broadcast size
  5. If we move each remote site into it's own area (and summerize) then we reduce the routers per area and route table, but add a lot of complexity to the design.  Is it worth it if everything will work fine on a /24 (or /23) area 0 design.

In the end, the only recommendations I've found are from long out-of-date publications.  I wonder, are those limitations still are valid with newer router's CPU and memory capacity?

 

Hall of Fame Expert

Re: OSPF Design Considerations for Broadcast Networks

Hello rlyons989,

about the max number of routers in the same area the old numbers of up to 50 are obsolete.

The usage of 800 routers in a single area has been reported here in the forums.

Not only the routers CPU and memory are much more powerful but also links are much more reliable.

 

However, the max number of routers in the same LAN segment is a different matter then the max numbers of routers in the same area.

The OSPF Hello packets list all the OSPF neighbor RIDs heard on link and must be processed by all devices.

 

I agree that using a dedicated Vlan subnet for each remote site makes sense only if you put each site in a different OSPF area.

However, if you have three Hub routers you can divide the load on them using 3 or 4 Vlans as I have proposed it is an intermediate design.

Each Hub router will be DR in one LAN segment, BDR in another LAN segment and DR other in the third /fourth LAN segment.

 

Hope to help

Giuseppe

 

VIP Expert

Re: OSPF Design Considerations for Broadcast Networks

"Not only the routers CPU and memory are much more powerful but also links are much more reliable."

In addition to what Giuseppe has noted, how Cisco's OSPF paces LSAs, both the routine one and the changes, goes a long way to keep OSPF Dijkstra's algorithm calculations from causing issues. (Also later Cisco IOS images support an incremental Dijkstra's algorithm optional feature.)  (Reason I mention this, I've seen Brand X OSPF go into OSPF meltdown when Cisco does not.  I.e. don't assume you can place the same number of Brand X OSPF routers into the same area.)

Enthusiast

Re: OSPF Design Considerations for Broadcast Networks

Thanks guys, appreciate the help!

CreatePlease to create content
Content for Community-Ad
July's Community Spotlight Awards