Introduction to OSPF

Previous Table of Contents Next


OSPF Network Types

Figure 4-3 illustrates the three different network types within which OSPF operates.


Figure 4-3  OSPF Network types.

The following list explains the physical characteristics of the OSPF network types illustrated in Figure 4-1:

  Point-to-Point. A single circuit that connects two OSPF routers, which will allow a single neighbor relationship to be built.
  Multiaccess. A circuit that has at least two OSPF routers connected to it and enables them to communicate with each other. This provides the potential for multiple neighbor relationships and adjacencies to be formed, but to prevent this, a Designated Router (DR) builds all the adjacencies and distributes them out to all connected routers.


Notes:  
OSPF Designated Routers (DR) will be fully explained in the next couple of chapters.
  Nonbroadcast Multiaccess (NBMA). NBMA networks are very similar to multiaccess networks, with the exception being that they do not allow for broadcast traffic (X.25, for example). NBMA networks also have the potential for multiple adjacencies, but the virtual circuits may not connect all routers. In some cases, this would require the adjacencies to be manually configured.


Tips:  
ITU-T standard defines how connections between DTE and DCE are maintained for remote terminal access and computer communications in PDNs. X.25 specifies LAPB, a data link layer protocol, and PLP, a network layer protocol. Frame Relay has to some degree superseded X.25.


Notes:  
You might ask what about point-to-multipoint? The RFC explains it best: “OSPF runs in one of two modes over non-broadcast networks. The first mode, called nonbroadcast multi-access or NBMA, simulates the operation of OSPF on a broadcast network. The second mode, called point-to-multipoint, treats the nonbroadcast network as a collection of point-to-point links. Nonbroadcast networks are referred to as NBMA networks or point-to-multipoint networks, depending on OSPF’s mode of operation over the network.” [RFC 2328]

Router Identification

Every router running OSPF within a network must have a unique router ID. This identification number is a 32-bit number that identifies one router to another router within an Autonomous System (AS). The router ID is used by the OSPF link-state database (LSDB) as a method of tracking each router within the AS and the links associated with it.

This identification number is unique to each OSPF router. You can employ a couple different methods to determine how your network decides upon the OSPF router ID.

To assign the router ID, OSPF uses the default method of determining the highest IP address on one of the router’s active interfaces.

The other method involves manually assigning the router ID number by configuring a loopback address on the Cisco router in question. This method has the added benefit of being much more stable than the default method because a loopback address cannot go down or lose connectivity, which would result in the need to update routing tables. Chapter 7, “Designing & Implementing an OSPF Network,” discusses loopback addresses in greater detail.


TIPS:  
Cisco is currently working on a new command to explicitly allow the setting of the router ID. It will be available in future IOS releases.

Configuring a loopback address as the OSPF router ID has a very significant benefit in its stability. The interface is essentially a software-based interface that can be used for many additional purposes such as summarizing IP address ranges or troubleshooting. They are reachable, provided they fall within the advertised IP address category.


TIPS:  
When configuring the IP address for your loopback interface, keep in mind that a “real” IP address uses valuable address space. The alternative is to use a “fake” or “bogus” IP address, which is essentially a made-up IP address that is not part of your network’s normal IP address range. RFC 1597 might be a good place to start if you decide to use this method or make the first octet the last.

Neighbors

OSPF considers two routers that have an interface located on a common network as neighbors. When OSPF discovers its neighbors, this is the first step of discovering the network and building a routing table. This process begins by the router learning the router identification numbers. On multiaccess networks, these neighbors are dynamically discovered by the OSPF Hello protocol, which will be discussed in later chapters.


TIPS:  
To build stable OSPF neighbor relationships, ensure that the number of routers per LAN is small. Use the priority command to organize which is the DR and avoid having the same router as the DR for more than one link through the use of the ip ospf priority command.

Adjacencies

For adjacencies to form, OSPF must first have discovered its neighbors. Adjacencies are formed for the purpose of exchanging routing information. Not every neighboring router will form an adjacency. The six conditions under which OSPF will form adjacencies are as follows:

  Network connectivity is point-to-point
  Network connectivity is achieved through a virtual link
  The router is the Designated Router (DR)
  The neighboring router is the DR
  The router is the backup DR
  The neighboring router is the backup DR

Adjacencies control the distribution of routing updates in the sense that only routers adjacent to the one sending an update will process it.

Designated Routers (DRs)

OSPF builds adjacencies between routers for purposes of exchanging routing information. When OSPF has to deal with non-broadcast multiaccess (NBMA) or broadcast networks, however, a problem presents itself. In these types of networks, there are multiple routers, which would result in entirely too many adjacencies. To combat superfluous adjacencies, the Designated Router is introduced.


Previous Table of Contents Next




OSPF Network Design Solutions
OSPF Network Design Solutions
ISBN: 1578700469
EAN: 2147483647
Year: 1998
Pages: 200
Authors: Tom Thomas

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net