Ospf Routes

8/2/2019 Ospf Routes

1/20

Used Cars from USAUsed Cars from USA< Free Open Study >

Problem: OSPF Not Installing Any Routes in the Routing Table

This is a lso a common problem in OSPF to find routes in the database but not in the routing tab le. When OSPF finds anykind of discrepancy in the database, it does not install any routes in the routing table. This section assumes that the sender

is advertising the routes in the database. If the sender is not advertising the routes, or if the route is not even present in the

database, troubleshoot that problem first. This was discussed in the previous section, for troubleshooting when OSPF is not

advertising routes.

The most common possible causes of this problem are as follows:

The network type is mismatched.

IP addresses are flipped in dual serial-connected routers or a subnet/mask mismatch has occurred.

One side is a numbered and the other side is an unnumbered point-to-point link.

A distribute list is blocking the routes' installation.

There is a broken PVC in a fully meshed Frame Relay network with the broadcast network type.

Figure 9-66 shows a network setup that produces the OSPF route installation problem. The cloud in the middle is irrelevant. It

could be Frame relay, PPP HDLC, or something else, but it must be a point-to-point WAN link in this scenario.

Figure 9-66. OSPF Network Setup Used to Produce Route Installation Problems

Example 9-183 shows that R2 is not installing any routes in the routing table.

Example 9-183 R2 Has No Routes in Its Routing Table

R2#show ip route ospf

R2#

OSPF Not Installing Any Routes in the Routing TableCause: Network Type Mismatch

A mismatched network type produces a discrepancy in the database, and OSPF will not install those routes in the routing

table. This situation is common in NBMA networks in which one side has a point-to-point network type and the other side has

a broadcast network type. This problem also occurs if one side is defined as a point-to-multipoint network and the other side

is left as nonbroadcast.

In this example, one side is defined as broadcast and the other side is defined as point-to-point. When an interface network

type is defined as broadcast, OSPF considers that link to be a transit link and puts that link in its router LSA as a transit link.

Figure 9-67 shows the flowchart to follow to solve this problem.

Figure 9-67. Problem-Resolution Flowchart

Problem: OSPF Not Installing Any Routes in the Ro... http://cisco.iphelp.ru/faq/5/ch09lev1sec14.h

of 20 12/16/2011 09:45


2/20

Debugs and Verification

Example 9-184 shows the interface conf iguration on bo th R1 and R2. The R1 serial interface network type is broadcast, while

R2 uses the default network type, which is nonbroadcast.

Example 9-184 Network Types for R1 and R2

R1#

interface Serial0

ip address 131.108.1.1 255.255.255.0

ip ospf network broadcast

!

_____________________________________________________________________________________

R2#

interface Serial0

ip address 131.108.1.2 255.255.255.0

Example 9-185 shows the output ofshow ip ospf interface for the Serial 0 interface of both routers, which shows that there

is a network type mismatch on both ends.

Example 9-185 Determining Whether R1 and R2 Have a Network Type Mismatch on theSerial 0 Interfaces

R1#show ip ospf interface serial 0

Serial0 is up, line protocol is up

Internet Address 131.108.1.1/24, Area 0


2 of 20 12/16/2011 09:45


3/20

Process ID 20, Router ID 131.108.2.1, Network Type BROADCAST, Cost: 64

Transmit Delay is 1 sec, State DR, Priority 1

Designated Router (ID) 131.108.2.1, Interface address 131.108.1.1

Backup Designated router (ID) 131.108.2.2, Interface address 131.108.2.2

Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

Hello due in 00:00:08

Neighbor Count is 1, Adjacent neighbor count is 1

Adjacent with neighbor 131.108.2.2 (Backup Designated Router)

Suppress hello for 0 neighbor(s)

_____________________________________________________________________________________




Process ID 20, Router ID 131.108.1.2, Network Type POINT_TO_POINT, Cost: 64

Transmit Delay is 1 sec, State POINT_TO_POINT,




Adjacent with neighbor 131.108.2.1


Example 9-186 shows the output of router LSAs on each router. The router LSA is complaining that the advertising router is

unreachable. This is why the routers are not installing routes in the routing table.

Example 9-186 LSAs for R1 and R2 Indicate That the Advertising Router Is Unreachable

R1#show ip ospf database router 131.108.1.2

Adv Router is not-reachable

LS age: 418

Options: (No TOS-capability, DC)

LS Type: Router Links

Link State ID: 131.108.1.2

Advertising Router: 131.108.1.2

LS Seq Number: 80000002

Checksum: 0xFA63

Length: 60

Number of Links: 3


3 of 20 12/16/2011 09:45


4/20

Link connected to: another Router (point-to-point)

(Link ID) Neighboring Router ID: 131.108.2.1

(Link Data) Router Interface address: 131.108.1.2

Number of TOS metrics: 0

TOS 0 Metrics: 64

Link connected to: a Stub Network

(Link ID) Network/subnet number: 131.108.1.0

(Link Data) Network Mask: 255.255.255.0


TOS 0 Metrics: 64





TOS 0 Metrics: 10

_____________________________________________________________________________________

R2#show ip ospf database router 131.108.2.1


LS age: 357





LS Seq Number: 8000000A

Checksum: 0xD4AA

Length: 48

Number of Links: 2

Link connected to: a Transit Network

(Link ID) Designated Router address: 131.108.1.1



TOS 0 Metrics: 64


4 of 20 12/16/2011 09:45


5/20





TOS 0 Metrics: 10

Solution

In this example, one side of a link is shown as a point-to-point link in the database, and the other side of the same link is

shown as a transit link. This creates a d iscrepancy in the database and the router will not install anything in the routing

table.

To fix this problem, change the network type of R1 back to its default, which is point-to-point. Example 9-187 shows how to

change the network type back to point-to-point on R1.

Example 9-187 Changing Network Type Back to Point-to-Point

R1#

interface Serial0

ip address 131.108.1.1 255.255.255.0

no ip ospf network broadcast

Example 9-188 shows the output ofshow ip ospf interface for the serial interface. It shows that the network type is point-

to-point.

Example 9-188 Verifying That R1's Serial 0 Interface Is of Network Type Point-to-Point




Process ID 20, Router ID 131.108.2.1, Network Type POINT_TO_POINT, Cost: 64

Transmit Delay is 1 sec, State POINT_TO_POINT,




Adjacent with neighbor 131.108.1.2


Example 9-189 shows that R2 starts installing OSPF routes in its routing table.

Example 9-189 Confirming That OSPF Routes Now Are Being Installed


5 of 20 12/16/2011 09:45


6/20

R2#show ip route 131.108.3.0

Routing entry for 131.108.3.0/24

Known via "ospf 1", distance 130, metric 74, type intra area

Redistributing via ospf 1

Last update from 131.108.1.1 on Serial0, 01:39:09 ago

Routing Descriptor Blocks:

* 131.108.1.1, from 131.108.2.1, 14:39:09 ago, via Serial0

Route metric is 64, traffic share count is 1

OSPF Not Installing Any Routes in the Routing TableCause: IP Addresses Are

Flipped in Dual Serial-Connected Routers

The IP addressing on dual serial interfaces can cause this problem. OSPF forms a FULL adjacency because the neighbor is still

reachable, but this creates a discrepancy in the OSPF database.

This also can happen when the wrong IP subnet or mask is assigned on one side. This creates a discrepancy in the OSPFdatabase.

Figure 9-68 shows a network setup in which the addresses on the serial interfaces are flipped; for example, R1's Serial 0

address is 131.108.1.1/24. The other end of this interface goes into Serial 0 of R2, which has the 131.108.2.1/24 address

defined under Serial 0. A similar thing can be observed with the Serial 1 interface. This obviously looks like the addresses are

flipped.

Figure 9-68. OSPF Network in Which Router Serial Interface IP Addresses Are Flipped

Example 9-190 shows that R2 is not installing any routes in the routing table because of the discrepancy in the database.

Example 9-190 R2 Is Not Installing Any OSPF Routes in Its Routing Table


R2#




6 of 20 12/16/2011 09:45


7/20


Example 9-191 shows the output ofshow ip ospf neighbor, which shows that OSPF is forming FULL adjacency on both

serial links. The address column shows that the neighbor address and interface do not match. For example, in Example

9-191, R2 has two neighbors. Because R2's Serial 0 address is in the range 131.108.2.0/24, as shown in Figure 9-68, the

neighbor address on Serial 0 also should be in the same range, but it shows 131.108.1.1 as a neighbor on Serial 0.

Example 9-191 show ip ospf neighbor Command Output Indicates OSPF Adjacency

Formation on R1's Serial Links

R2#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface

131.108.2.1 1 FULL/ - 00:00:37 131.108.1.1 Serial0

131.108.2.1 1 FULL/ - 00:00:31 131.108.2.1 Serial1

Solution

To fix this problem, assign the IP address on the correct corresponding interface. Either change R1's IP addresses on its serial

links or change R2's IP addresses on its serial links. In this example, R2's serial links have been changed to match R1's. Serial

0 IP addresses and Serial 1 IP addresses have been swapped, as shown in Example 9-192.

Example 9-192 Changing IP Addresses on R2's Serial Links

R2#


7 of 20 12/16/2011 09:45


8/20

interface serial 0

no ip address

ip address 131.108.1.2 255.255.255.0

!

interface serial 1

no ip address

ip address 131.108.2.1 255.255.255.0

Example 9-193 shows that after fixing this problem, R2 installs OSPF routes in its routing table.

Example 9-193 R2's Routing Table Indicates That the Problem Has Been Resolved









R2#

OSPF Not Installing Any Routes in the Routing TableCause: One Side Is a Numberedand the Other Side Is an Unnumbered Point-to-Point Link

When OSPF creates a router LSA for point-to-point links, it adheres to the following rule to fill the Link ID and Link Data fields

within the router LSA (see Tab le 9-1).

Table 9-1. Link ID and Link Data Values for OSPF Point-to-Point Numbered and

Unnumbered Links

Type Description Link ID Link Data

1 Point-to-point Numbered Neighbor's router ID Interface IP address

1 Point-to-point Unnumbered Neighbor's router ID MIB-II ifIndex value

Table 9-1 shows that the Link Data field for unnumbered point-to-point links should have an MIB-II ifIndex value. Because the

link data value of the numbered interface does not match that of the unnumbered interface, this creates the discrepancy in

the OSPF database.

Figure 9-70 shows a network setup in which the R1 serial link is unnumbered to a loopback interface, while the R2 serial link is


8 of 20 12/16/2011 09:45


9/20

numbered.

Figure 9-70. OSPF Network with a Serial Link Unnumbered to a Loopback Interface




Example 9-194 shows the discrepancy in the OSPF database. R1's router LSA shows the MIB-II IfIndex value in the Link Data

field for Serial 0, while R2's router LSA shows the router's serial interface address in the Link Data field.

Example 9-194 Checking the OSPF Database for a Discrepancy

R2#show ip ospf database router

OSPF Router with ID (131.108.1.2) (Process ID 1)

Router Link States (Area 0)


9 of 20 12/16/2011 09:45


10/20


LS age: 855





LS Seq Number: 8000000D

Checksum: 0x55AD

Length: 60

Number of Links: 1





TOS 0 Metrics: 64

_____________________________________________________________________________________





LS age: 855





LS Seq Number: 8000000D

Checksum: 0x55AD

Length: 60

Number of Links: 1




0 of 20 12/16/2011 09:45


11/20



TOS 0 Metrics: 64

Example 9-195 shows the configuration on bo th R1 and R2, which shows that R1's serial interface is unnumbered to a

loopback address, while R2's serial interface is numbered.

Example 9-195 Serial Interface Configurations for R1 and R2

R1#

interface Loopback0

ip address 131.108.1.1 255.255.255.0

!

interface Serial0

ip unnumbered Loopback0

!

router ospf 1

network 131.108.0.0 0.0.255.255 area 0

_____________________________________________________________________________________

R2#

interface Serial0

ip address 131.108.1.2 255.255.255.0

!

router ospf 1

network 131.108.0.0 0.0.255.255 area 0

Solution

To fix this problem, make sure that both sides are either a numbered point-to-point link or an unnumbered point-to-point link.

Example 9-196 shows the new configuration that fixes this problem. In this example, R1's serial interface is assigned an IP

address.

Example 9-196 Assigning an IP Address on R1's Serial 0 Interface, Which Was

Unnumbered Before

R1#

interface Serial0

ip address 131.108.1.1 255.255.255.0

!

router ospf 1


1 of 20 12/16/2011 09:45


12/20

network 131.108.0.0 0.0.255.255 area 0

_____________________________________________________________________________________

R2#

interface Serial0

ip address 131.108.1.2 255.255.255.0

!

router ospf 1

network 131.108.0.0 0.0.255.255 area 0

Example 9-197 shows that R2 installs routes in the routing table after this problem is fixed.

Example 9-197 Confirming OSPF Route Installation









R2#

OSPF Not Installing Any Routes in the Routing TableCause: Distribute List IsBlocking the Route Installation

OSPF is a link-state protocol. When it forms an adjacency with any neighbor, it synchronizes its database with that neighbor.

Because of its link-state nature, filtering in OSPF is not possible.

Configuring distribute-list in prevents OSPF routes from being installed in the routing table. This doesn't mean that the

routes disappear from the OSPF database. It simply means that before OSPF installs the route into the routing table, it checks

for the distribute list and installs only those networks that are permitted in the distribute list. However, it keeps the routes in

the database.

Figure 9-72 shows a network setup in which OSPF is not installing any routes in the routing table. Specifically, Router 2 is not

seeing any OSPF routes in its routing table.

Figure 9-72. OSPF Network That Produces Route Installation Problems


2 of 20 12/16/2011 09:45


13/20




Example 9-198 shows the configuration on R2, which shows that R2 has distribute-list in configured and is not installing

any OSPF routes in the routing table. Access list 1, which is used in the distribute list, allows only the 10/8 and 20/8 networks

to be installed in the routing table. The remaining networks are implicitly denied. Example 9-198 also shows that the

131.108.3.0 network is not in the routing table because it is denied by the distribute list.

Example 9-198 R2 Configuration with a Distribute List

R2#

!

router ospf 1

network 131.108.0.0 0.0.255.255 area 0

distribute-list 1 in

!

access-list 1 permit 10.0.0.0



%Network not in table

R2#


3 of 20 12/16/2011 09:45


14/20

Solution

If a network is in the database but not in the routing table, make sure that the network is permitted in the distribute list.

Example 9-199 shows the new configuration that f ixes this problem. In this configuration, network 131.108.3.0 is permitted.

Example 9-199 Configuring R2's Distribute List to Permit the 131.108.3.0/24 Network

R2#

!

router ospf 1

network 131.108.0.0 0.0.255.255 area 0

distribute-list 1 in

!



access-list 1 permit 131.108.3.0 0.0.0.255

Example 9-200 shows that network 131.108.3.0/24 appears in the routing table after fixing the configuration on R2.

Example 9-200 Confirming That the 131.108.3.0 Route Is Installed









R2#

OSPF Not Installing Any Routes in the Routing TableCause: Broken PVC in a Fully

Meshed Frame Relay Network with Broadcast Network Type

The OSPF network type broadcast should never be defined on a medium that is not fully meshed. Sometimes, the medium is

fully meshed but the Layer 2 connectivity is not stable. In that case, when Layer 2 is broken, it creates an inconsistency and

the medium becomes nonfully meshed again.

Figure 9-74 shows a network experiencing this problem. Before the PVC between R1 and R2 was broken, R2 was a DR and R3

was a BDR.


4 of 20 12/16/2011 09:45


15/20

Figure 9-74. OSPF Network in Which a Broken PVC in a Fully Meshed Frame Relay Network

with Broadcast Network Type Causes Problems

Example 9-201 shows that R1 is not installing any routes in the routing table.

Example 9-201 R1 Is Not Installing Any Routes


R1#




5 of 20 12/16/2011 09:45


16/20


Example 9-202 shows the configuration on R1, R2, and R3. The configuration shows that the network type is broadcast on

all routers for the Frame Relay cloud.

Example 9-202 Confirming the Network Type on R1, R2, and R3

R1#

!

interface Serial0.1 multipoint

ip address 131.108.0.1 255.255.255.0


_____________________________________________________________________________________

R2#

!


ip address 131.108.0.2 255.255.255.0


_____________________________________________________________________________________

R3#

!



6 of 20 12/16/2011 09:45


17/20

ip address 131.108.0.3 255.255.255.0


Example 9-203 shows the output ofshow ip ospf neighbor on a ll three routers. The output on R1 shows that it considers

R2 to be the DR. However, the actual DR is R3, as shown in Figure 9-74, because it has the highest router ID. Because the

link between R1 and R3 is broken, R1 declares R2 to be the DR.

Example 9-203 Determining the Designated Router



131.108.2.1 1 FULL/DR 00:00:31 131.108.0.2 Serial0.1

_____________________________________________________________________________________



131.108.1.1 1 FULL/DROTHER 00:00:34 131.108.0.1 Serial0.1

131.108.3.1 1 FULL/DR 00:00:33 131.108.0.3 Serial0.1

_____________________________________________________________________________________



131.108.2.1 1 FULL/BDR 00:00:31 131.108.0.2 Serial0.1

Example 9-204 shows the router LSA output on R1 displaying the router LSA for R1, R2, and R3. R1 still considers R2 the DR

instead of R3. R1 shows that the Frame Relay link is a stub link because it couldn't find any network LSA generated by R2 in

the database. This Frame Relay link is defined as a transit link in both R2 and R3's database. This creates a discrepancy in

the OSPF database.

Example 9-204 OSPF Database on R1, R2, and R3 Shows Discrepancy




LS age: 148




7 of 20 12/16/2011 09:45


18/20



LS Seq Number: 8000000B

Checksum: 0x55A

Length: 48

Number of Links: 2





TOS 0 Metrics: 64





TOS 0 Metrics: 1


LS age: 1081






Checksum: 0x4F72

Length: 48

Number of Links: 2





TOS 0 Metrics: 1



8 of 20 12/16/2011 09:45


19/20




TOS 0 Metrics: 64


LS age: 306






Checksum: 0xC185

Length: 48

Number of Links: 2





TOS 0 Metrics: 1





TOS 0 Metrics: 64

Solution

The solution in this case is to run a point-to-multipoint network type. With a point-to-multipoint network type, the flooding

increases because no DR/BDR elected. If there is any connectivity problem, however, it will not create any black holes.

So, a trade-off exists between reliability and increased flooding. Selecting a point-to-multipoint network type over unstable

Frame Relay links provides reliability, while selecting a broadcast net-work type creates inconsistencies whenever any Layer 2

instability occurs.

Example 9-205 shows the new configuration changes on R1, R2, and R3. The network type is now point-to-multipoint.


9 of 20 12/16/2011 09:45


20/20

Example 9-205 Configuring R1, R2, and R3 with Point-to-Multipoint Interfaces

R1#

!


ip address 131.108.0.1 255.255.255.0

ip ospf network point-to-multipoint

_____________________________________________________________________________________

R2#

!


ip address 131.108.0.2 255.255.255.0


_____________________________________________________________________________________

R3#

!


ip address 131.108.0.3 255.255.255.0


Example 9-206 shows that R1 starts learning OSPF routes from R2 a fter the configuration changes.

Example 9-206 Confirming That R1 Is Learning OSPF Routes from R2





Last update from 131.108.0.2 on Serial0.1, 00:00:19 ago


* 131.108.0.2, from 131.108.3.1, 14:39:09 ago, via Serial0.1


R1#

< Free Open Study >


20 of 20 12/16/2011 09:45

Ospf Routes

Documents

Transcript of Ospf Routes