OSPF design considerations
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
OSPF design considerations
To prevent problems, you should consider the following design issues before you implement Open Shortest Path First (OSPF). This feature is not available on the Itanium-based versions of the Windows operating systems. This content is not available in this preliminary release.
OSPF design
There are three levels of OSPF design:
Autonomous system design
Area design
Network design
To aid in configuration and to prevent problems, you should consider the following elements for each level of OSPF design.
Autonomous system design
The following guidelines are recommended when designing an OSPF autonomous system:
Subdivide the OSPF autonomous system into areas that can be summarized.
If possible, subdivide your IP address space into a network/area/subnet/host hierarchy.
Make the backbone area a single high-bandwidth network.
Create stub areas whenever possible.
Avoid virtual links whenever possible.
Area design
The following guidelines are recommended when designing each OSPF area:
Ensure that all areas are assigned network IDs that can be expressed as a small number of summary routes.
If an area can be summarized with a single route, make the area ID the single route being advertised.
Ensure that multiple area border routers (ABRs) for the same area are summarizing the same routes.
Ensure that there are no back doors between areas and that all inter-area traffic crosses the backbone area.
Keep areas under 100 networks.
Network design
The following guidelines are recommended when designing each network:
Assign router priorities so that the least busy routers are the designated router and backup designated router.
Designate link costs to reflect bit rate, delay, or reliability characteristics.
Assign a password.
OSPF over Frame Relay
Although OSPF packets are typically multicast, OSPF was designed to operate over a nonbroadcast technology such as Frame Relay. How OSPF is configured for Frame Relay depends on how the Frame Relay virtual circuits appear as network interfaces on the server running Routing and Remote Access. Either the Frame Relay adapter appears as a single adapter for all the virtual circuits (single adapter model) or each virtual circuit appears as a separate adapter (multiple adapter model).
Single-adapter model
With the single adapter model, also known as the nonbroadcast multiple access (NBMA) model, the network for the Frame Relay service provider (also known as the Frame Relay cloud) is treated as an IP network and the endpoints on the cloud are assigned IP addresses from a designated IP network ID. To ensure that OSPF traffic is received by all of the appropriate endpoints on the cloud, you must configure the Frame Relay interface to unicast its OSPF announcements to all of the appropriate endpoints. For the server running Routing and Remote Access, this is done by designating the interface as a nonbroadcast multiple access (NBMA) network and adding OSPF neighbors. To add OSPF neighbors, see Add an OSPF neighbor.
Also, in a spoke and hub Frame Relay topology, the Frame Relay interface for the hub router must have a router priority set to 1 or greater and the Frame Relay interfaces for the spoke routers must have a router priority set to 0. Otherwise, the hub router, which is the only router that can communicate with all of the spoke routers, cannot become the designated router and adjacencies cannot form across the Frame Relay network.
Multiple-adapter model
With the multiple adapter model, each Frame Relay virtual circuit appears as a point-to-point link with its own network ID, and the endpoints are assigned IP addresses from a designated IP network ID. Since each virtual circuit is its own point-to-point connection, you can configure the interface for the point-to-point network type.
Note
- The preceding discussion also applies to other NBMA technologies such as X.25 and ATM.
Using virtual links
An OSPF routed internetwork can be subdivided into areas, which are collections of contiguous networks. All areas are connected together through a common area called the backbone area. A router that connects an area to the backbone area is called an area border router (ABR). Normally, ABRs have a physical connection to the backbone area. When it is not possible or practical to have an ABR of an area physically connected to the backbone area, you can use a virtual link to connect the ABR to the backbone.
A virtual link is a logical point-to-point connection between an ABR of an area and an ABR that is physically connected to the backbone area. For example, a virtual link is configured between the ABR of Area 2 and the ABR of Area 1. The ABR of Area 1 is physically connected to the backbone area. Area 1 is known as the transit area, the area across which the virtual link is created in order to logically connect Area 2 to the backbone.
To create a virtual link, both routers, called virtual link neighbors, are configured with the transit area, the router ID of the virtual link neighbor, matching hello and dead intervals, and a matching password.
For more information, see Add a virtual interface.
To troubleshoot a virtual link, see Troubleshooting OSPF.
External routes and ASBRs
The set of OSPF routers in an organization defines an OSPF autonomous system (AS). By default, only OSPF routes corresponding to directly connected network segments are propagated within the AS. An external route is any route that is not within the OSPF AS. External routes can come from many sources:
Other routing protocols such as RIP for IP (v1 and v2).
Static routes.
Routes set on the router through SNMP.
External routes are propagated throughout the OSPF AS through one or more autonomous system boundary routers (ASBRs). An ASBR advertises external routes within the OSPF AS. For example, if you need to advertise the static routes of a server running Routing and Remote Access, you need to enable that router as an ASBR.
For more information, see Configure an ASBR.
External route filters
By default, OSPF routers acting as ASBRs import and advertise all external routes. You may want to filter out external routes to keep the ASBR from advertising improper routes. External routes can be filtered on the ASBR by:
External route source
You can configure the ASBR to accept or ignore the routes of certain external sources such as routing protocols (RIP v2) or other sources (static routes or SNMP).
Individual route
You can configure the ASBR to accept or discard specific routes by configuring one or multiple {Destination, Network mask} pairs.
OSPF on a remote access server
If you configure a server running Routing and Remote Access using OSPF to also act as a remote access server and the static IP address pool address ranges are for a separate subnet, in order to properly advertise the route that represents all remote access clients:
Enable the server running Routing and Remote Access as an autonomous system boundary router (ASBR).
Configure OSPF route filters to Accept listed routes and then add the routes that correspond to the address ranges of your static IP address pool.
For more information, see Configure an ASBR.
OSPF on an answering demand-dial router
If you configure a server running Routing and Remote Access by using OSPF to act as the answering router in a one-way initiated connection, in order to properly advertise the routes that represent the network segments of your calling routers:
Enable the answering router as an autonomous system boundary router (ASBR).
If the answering router is also configured with static IP address pool address ranges that are for a separate subnet, add the routes that correspond to the static routes on the user accounts being used by the calling routers.
For more information, see Configure an ASBR.
For more information about using static routes for one-way initiated demand-dial connections, see One-way initiated demand-dial connections.