Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Every router in an area, when OSPF stabilizes after topology changes occur, should have
an identical LSDB for that area. Internal routers (routers inside a single area) have only that
area’s LSAs, but an ABR’s LSDB will contain LSAs for each area to which it connects. The
ABR does, however, know which LSAs exist in each area.
OSPF routers flood both the LSAs they create, and the LSAs they learn from their neighbors,
until all routers in the area have a copy of each of the most recent LSAs for that area.
To manage and control this process, OSPF defines several messages, processes, and neighbor
states that indicate the progress when flooding LSAs to each neighbor. This section
begins by listing reference information for the OSPF messages and neighbor states. Next,
the text describes the flooding process between two neighbors when a DR does not exist,
followed by a description of the similar process used when a DR does exist. This section
ends with a few items related to how the routers avoid looping the LSA advertisements and
how they periodically reflood the information.
OSPF Message and Neighbor State Reference
For reference, Table 6-4 lists the OSPF message types that will be mentioned in the next
few pages. Additionally, Table 6-5 lists the various neighbor states as well. Although useful
for study, when you first learning this topic, feel free to skip these tables for now.
www.CareerCert.info
Chapter 6: OSPF Topology, Routes, and Convergence 197
Table 6-4 OSPF Message Types and Functions
Message Name/number Description
Link-State Request (LSR) (3) A packet that lists the LSIDs of LSAs the sender of
the LSR would like the receiver of the LSR to supply
during database exchange
Link-State Update (LSU) (4) A packet that contains fully detailed LSAs, typically
sent in response to an LSR message
Link-State Acknowledgment (LSAck) (5) Sent to confirm receipt of an LSU message
Table 6-5 OSPF Neighbor State Reference
State Meaning
Down No Hellos have been received from this neighbor for more than the dead interval.
Attempt Used when the neighbor is defined with the neighbor command, after sending a
Hello, but before receiving a Hello from that neighbor.
Init A Hello has been received from the neighbor, but it did not have the local router’s
RID in it or lists parameters that do not pass the neighbor verification checks. This
is a permanent state when Hello parameters do not match.
2Way A Hello has been received from the neighbor, it has the router’s RID in it, and all
neighbor verification checks passed.
ExStart Currently negotiating the DD sequence numbers and master/slave logic used for
DD packets.
Exchange Finished negotiating the DD process particulars, and currently exchanging DD
packets.
Loading All DD packets are exchanged, and the routers are currently sending LSR, LSU,
and LSAck packets to exchange full LSAs.
Full Neighbors are fully adjacent, meaning they believe that their LSDBs for that area
are identical. Routing table (re)calculations can begin.
Exchange Without a Designated Router
As discussed in Chapter 5, the OSPF interface network type tells that router whether to
attempt to elect a DR on that interface. The most common case for which routers do not
elect a DR occur on point-to-point topologies, such as true point-to-point serial links and
point-to-point subinterfaces. This section examines the database exchange process on
such interfaces, in preparation for the slightly more complex process when using a DR on
an OSPF broadcast network type, like a LAN.
Every OSPF neighborship begins by exchanging Hellos until the neighbors (hopefully)
reach the 2-Way state. During these early stages, the routers discover each other by sending
multicast Hellos and then check each other’s parameters to make sure all items match
from the master. Additionally, the slave also includes the LSA headers for any LSAs that
the master did not list.
This exchange of DD messages ends with each router knowing a list of LSAs that it does
not have in its LSDB, but that the other router does have those LSAs. Additionally, each
router also ends this process with a list of LSAs that the local router already knows, but
for which the other router has a more recent copy (based on the sequence number).
Exchanging the LSAs
When the two neighbors realize that they have a shared view of the list of LSIDs, they
transition to the Loading state and start exchanging the full LSAs–but only those that
they do not yet know about or those that have changed.
For example, when the two routers in Figure 6-8 first become neighbors, neither router
will have a copy of the Type 1 LSA for the other router. So, R1 will request that R2 send
its LSA with LSID 2.2.2.2; R2 will send its Type 1 LSA; and R1 will acknowledge receipt.
The mechanics work like this:
Step 1. Transition the neighbor state to Loading.
Step 2. For any missing LSAs, send a Link State Request (LSR) message, listing the
LSID of the requested LSA.
Step 3. Respond to any LSR messages with an Link State Update (LSU), listing one or
more LSAs in each message.
Step 4. Acknowledge receipt by either sending a Link State Acknowledgment
(LSAck) message (called explicit acknowledgment), or by sending the same
LSA that was received back to the other router in an LSU message (implicit
acknowledgment).
Step 5. When all LSAs have been sent, received, and acknowledged, transition the
neighborship to the FULL state (fully adjacent).
Note: Because this section examines the case without a DR, all these messages flow as
multicasts to 224.0.0.5, the all SPF routers multicast address, unless the neighbors have
been defined with an OSPF neighbor command.
By the end of this process, both routers should have an identical LSDB for the area to
which the link has been assigned. At that point, the two routers can run the SPF algorithm
to choose the currently best routes for each subnet.
Exchange with a Designated Router
Database exchange with a DR differs slightly than database exchange when no DR exists.
The majority of the process is similar, with the same messages, meanings, and neighbor
states. The big difference is the overriding choice of with whom each router chooses to
perform database exchange.
www.CareerCert.info
Chapter 6: OSPF Topology, Routes, and Convergence 201
Type 2
10.5.5.0/28
R4
Type 1
R3
Type 1
R2
Type 1
R1
Type 1
to 224.0.0.6 (All DR)
to 224.0.0.5 (All SPF)
to 224.0.0.5 (All SPF)
1 2
2
2
Figure 6-9 Conceptual View–Exchanging the Database with a Pseudonode
Non-DR routers do not exchange their databases directly with all neighbors on a subnet.
Instead, they exchange their database with the DR. Then, the DR exchanges any
new/changed LSAs with the rest of the OSPF routers in the subnet.
The concept actually follows along with the idea of a Type 2 LSA as seen earlier in Figure
6-4. Figure 6-9 represents four Type 1 LSAs, for four real routers on the same LAN, plus a
single Type 2 LSA that represents the multiaccess subnet. The DR created the Type 2 LSA
as part of its role in life.
Figure 6-9 shows two conceptual steps for database exchange. The non-DR router (R3)
first exchanges its database with the pseudonode, and then the type 2 pseudonode exchanges
its database with the other routers. However, the pseudonode is a concept, not a
router; to make the process depicted in Figure 6-9 work, the DR takes on the role of the
Type 2 pseudonode. The messages differ slightly as well, as follows:
■ The non-DR performs database exchange with the same messages, as shown in Figure
6-9, but sends these messages to the 224.0.0.6 All-DR-routers multicast address.
■ The DR performs database exchange with the same messages but sends the messages
to the 224.0.0.5 all-SPF-routers multicast address.
Consider these two conventions one at a time. First, the messages sent to 224.0.0.6 are
processed by the DR and the BDR only. The DR actively participates, replying to the messages,
with the BDR acting as a silent bystander. In effect, this allows the non-DR router to
exchange their database directly with the DR and BDR, but with none of the other routers
in the subnet.
Key
Topic
www.CareerCert.info
202 CCNP ROUTE 642-902 Official Certification Guide
Next, consider the multicast messages from the DR to the 224.0.0.5 all-SPF-router multicast
address. All OSPF routers process these messages, so the rest of the routers–the
DROthers to use the IOS term–also learn the newly exchanged LSAs. This process completes
the second step shown in the conceptual Figure 6-9, where the DR, acting like the
pseudonode, floods the LSAs to the other OSPF routers in the subnet.
The process occurs in the background and can be generally ignored. However, for operating
an OSPF network, an important distinction must be made. With a DR in existence, a
DROther router performs the database exchange process (as seen in Figure 6-9) with the
DR/BDR only and not any other DROther routers in the subnet. For example, in Figure 6-
9, R1 acts as DR, R2 acts as BDR, and R3/R4 act as DROther routers. Because the underlying
process does not make R3 and R4 perform database exchange with each other, the
routers do not reach the FULL neighbor state, remaining in 2-Way state.
Example 6-6 shows the resulting output for the LAN shown in Figure 6-9, with four
routers. The output, taken from DROther R3, shows a 2-Way state with R4, the other
DROther. It also shows on interface Fa0/0 that its own priority is 1. This output also
shows a neighbor count (all neighbors) of 3 and an adjacent neighbor count (all fully adjacent
neighbors) of 2, again because the neighborship between DROthers R3 and R4 is not
a full adjacency.
Example 6-6 Demonstrating OSPF FULL and 2-Way Adjacencies
R3#show ip ospf interface fa0/0
FastEthernet0/0 is up, line protocol is up
Internet Address 172.16.1.3/24, Area 0
Process ID 75, Router ID 3.3.3.3, Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State DROTHER, Priority 2
Designated Router (ID) 1.1.1.1, Interface address 172.16.1.1
Backup Designated router (ID) 2.2.2.2, Interface address 172.16.1.2
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:02
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 4
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 3, Adjacent neighbor count is 2
Adjacent with neighbor 1.1.1.1 (Designated Router)
Adjacent with neighbor 2.2.2.2 (Backup Designated Router)
Suppress hello for 0 neighbor(s)
www.CareerCert.info
Chapter 6: OSPF Topology, Routes, and Convergence 203
R2
R3
R4
R1
Area 1
LSDB - Before
R2
R3
R3
Subnet 1
Type 1
Type 1
Type 1
Type 2
Figure 6-10 Flooding Throughout an Area
R3#show ip ospf neighbor fa0/0
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 4 FULL/DR 00:00:37 172.16.1.1
FastEthernet0/0
2.2.2.2 3 FULL/BDR 00:00:37 172.16.1.2
FastEthernet0/0
44.44.44.44 1 2WAY/DROTHER 00:00:36 172.16.1.4 FastEthernet0/0
Flooding Throughout the Area
So far in this section, the database exchange process has focused on exchanging the database
between neighbors. However, LSAs need to be flooded throughout an area. To do so,
when a router learns new LSAs from one neighbor, that router then knows that its other
neighbors in that same area may not know of that LSA. Similarly, when an LSA changes,
for example, when an interface changes state, a router may learn the same old LSA but
with a new sequence number, and again need to flood the changed LSA to other neighbors
in that area.
Figure 6-10 shows a basic example of the process. In this case, R2, R3, and R4 have established
neighbor relationships, with four LSAs in their LSDB in this area. R1 is again the
new router added to the internetwork.
www.CareerCert.info
204 CCNP ROUTE 642-902 Official Certification Guide
First, consider what happens as the new R1-R2 neighborship comes up and goes through
database exchange. When R1 loads, and the link comes up, R1 and R2 reach a full state
and have a shared view of the Area 1 LSDB. R2 has learned all R1’s new LSAs (should only
be R1’s Type 1 router LSA), and R1 has learned all the area 1 LSAs known to R2, including
the Type 1 LSAs for R3 and R4.
Next, think about the LSDBs of R3 and R4 at this point. The database exchange between
R1-R2 did not inform R3 nor R4 about any of the new LSAs known by R1. So, R2, when it
learns of R1’s Type 1 LSA, sends DD packets to the DR on the R2/R3/R4 LAN. LSR/LSU
packets follow, resulting in R3 and R4 learning about the new LSA for R1. If more routers
existed in area 1, the flooding process would continue throughout the entire area, until all
routers know of the best (highest sequence number) copy of each LSA.
The flooding process prevents the looping of LSAs as a side-effect of the database exchange
process. Neighbors use DD messages to learn the LSA headers known by the
neighbor, and then only request the LSAs known by the neighbor but not known by the
local router. By requesting only unknown LSAs or new versions of old LSAs, routers prevent
the LSAs advertisements from looping.
Periodic Flooding
Although OSPF does not send routing updates on a periodic interval, as do distance vector
protocols, OSPF does reflood each LSA every 30 minutes based on each LSA’s age
variable. The router that creates the LSA sets this age to 0 (seconds). Each router then increments
the age of its copy of each LSA over time. If 30 minutes pass with no changes to
an LSA–meaning no other reason existed in that 30 minutes to cause a reflooding of the
LSA–the owning router increments the sequence number, resets the timer to 0, and refloods
the LSA.
Because the owning router increments the sequence number and resets the LSAge every
1800 seconds (30 minutes), the output of various show ip ospf database commands
should also show an age of less than 1800 seconds. For example, referring back to
Example 6-5, the Type 1 LSA for R1 (RID 1.1.1.1) shows an age of 943 seconds and a sequence
number of 0x80000003. Over time the sequence number should increment once
per every 30 minutes, with the LSAge cycle upward toward 1800 and then back to 0 when
the LSA is reflooded.
Note also that when a router realizes it needs to flush an LSA from the LSDB for an area, it
actually sets the age of the LSA to the MaxAge setting (3600) and refloods the LSA. All
the other routers receive the LSA, see the age is already at the maximum, causing those
routers to also remove the LSA from their LSDBs.
No comments:
Post a Comment