© Copyright IBM Corp. 2011
Chapter 22. OSPF
259
Neighbors and Adjacencies
In areas with two or more routing devices,
neighbors
and
adjacencies
are formed.
Neighbors
are routing devices that maintain information about each others’ health.
To establish neighbor relationships, routing devices periodically send hello packets
on each of their interfaces. All routing devices that share a common network
segment, appear in the same area, and have the same health parameters (
hello
and
dead
intervals) and authentication parameters respond to each other’s hello
packets and become neighbors. Neighbors continue to send periodic hello packets
to advertise their health to neighbors. In turn, they listen to hello packets to
determine the health of their neighbors and to establish contact with new neighbors.
The hello process is used for electing one of the neighbors as the area’s Designated
Router (DR) and one as the area’s Backup Designated Router (BDR). The DR is
adjacent to all other neighbors and acts as the central contact for database
exchanges. Each neighbor sends its database information to the DR, which relays
the information to the other neighbors.
The BDR is adjacent to all other neighbors (including the DR). Each neighbor sends
its database information to the BDR just as with the DR, but the BDR merely stores
this data and does not distribute it. If the DR fails, the BDR will take over the task of
distributing database information to the other neighbors.
The Link-State Database
OSPF is a link-state routing protocol. A
link
represents an interface (or routable
path) from the routing device. By establishing an adjacency with the DR, each
routing device in an OSPF area maintains an identical Link-State Database (LSDB)
describing the network topology for its area.
Each routing device transmits a Link-State Advertisement (LSA) on each of its
active
interfaces. LSAs are entered into the LSDB of each routing device. OSPF uses
flooding
to distribute LSAs between routing devices. Interfaces may also be
passive
. Passive interfaces send LSAs to active interfaces, but do not receive LSAs,
hello packets, or any other OSPF protocol information from active interfaces.
Passive interfaces behave as stub networks, allowing OSPF routing devices to be
aware of devices that do otherwise participate in OSPF (either because they do not
support it, or because the administrator chooses to restrict OSPF traffic exchange or
transit).
When LSAs result in changes to the routing device’s LSDB, the routing device
forwards the changes to the adjacent neighbors (the DR and BDR) for distribution to
the other neighbors.
OSPF routing updates occur only when changes occur, instead of periodically. For
each new route, if an adjacency is interested in that route (for example, if configured
to receive static routes and the new route is indeed static), an update message
containing the new route is sent to the adjacency. For each route removed from the
route table, if the route has already been sent to an adjacency, an update message
containing the route to withdraw is sent.
Summary of Contents for RackSwitch G8000
Page 1: ...RackSwitch G8000 Application Guide...
Page 2: ......
Page 3: ...RackSwitch G8000 Application Guide...
Page 16: ...16 RackSwitch G8000 Application Guide...
Page 22: ...20 RackSwitch G8000 Application Guide...
Page 23: ...Copyright IBM Corp 2011 21 Part 1 Getting Started...
Page 24: ...22 RackSwitch G8000 Application Guide...
Page 54: ...52 RackSwitch G8000 Application Guide...
Page 55: ...Copyright IBM Corp 2011 53 Part 2 Securing the Switch...
Page 56: ...54 RackSwitch G8000 Application Guide...
Page 92: ...90 RackSwitch G8000 Application Guide...
Page 94: ...92 RackSwitch G8000 Application Guide...
Page 144: ...142 RackSwitch G8000 Application Guide...
Page 145: ...Copyright IBM Corp 2011 143 Part 4 Advanced Switch ing Features...
Page 146: ...144 RackSwitch G8000 Application Guide...
Page 148: ...146 RackSwitch G8000 Application Guide...
Page 182: ...180 RackSwitch G8000 Application Guide...
Page 184: ...182 RackSwitch G8000 Application Guide...
Page 212: ...210 RackSwitch G8000 Application Guide...
Page 258: ...256 RackSwitch G8000 Application Guide...
Page 286: ...284 RackSwitch G8000 Application Guide...
Page 294: ...292 RackSwitch G8000 Application Guide...
Page 298: ...296 RackSwitch G8000 Application Guide...
Page 310: ...308 RackSwitch G8000 Application Guide...
Page 311: ...Copyright IBM Corp 2011 309 Part 7 Network Management...
Page 312: ...310 RackSwitch G8000 Application Guide...
Page 320: ...318 RackSwitch G8000 Application Guide...
Page 332: ...330 RackSwitch G8000 Application Guide...
Page 334: ...332 RackSwitch G8000 Application Guide...
Page 345: ...Copyright IBM Corp 2011 343 Part 9 Appendices...
Page 346: ...344 RackSwitch G8000 Application Guide...
Page 357: ...Copyright IBM Corp 2011 Appendix C Notices 355 Taiwan Class A compliance statement...