Troubleshooting Dial-on-Demand Routing Issues in OSPF

Troubleshooting Dial-on-Demand Routing Issues in OSPF

This section discusses the issues related to DDR. When OSPF is configured over a DDR link, be sure to suppress OSPF Hellos because OSPF sends Hellos over point-to-point links every 10 seconds.

The most common issues related to OSPF over DDR links are as follows:

  • Problem: OSPF Hellos are bringing up the link
  • Problem: OSPF Hellos are not getting across the link*
  • Problem: Demand circuit keeps bringing up the link

NOTE

*The problem of OSPF Hellos not getting across the link was addressed earlier in the section “Troubleshooting OSPF Neighbor Relationships.” Refer to this section for the solution to this problem.

Problem: OSPF Hellos Are Bringing Up the Link—Cause: OSPF Hellos Are Permitted as Interesting Traffic

When running OSPF for dial backup purposes over DDR links, define an access list to explicitly define the interesting traffic. OSPF uses a multicast address of 224.0.0.5 to send the Hellos. This address must be denied in the access list so that OSPF doesn’t bring up the link every 10 seconds.

Figure 9-89 shows a network experiencing this DDR problem.

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

Debugs and Verification
Example 9-245 shows the configuration on R1 that can produce this problem. In this configuration, only TCP traffic is denied. In other words, TCP traffic will not bring up the link, but any other IP traffic can do so.

Example 9-245 R1’s Access List Denies Only TCP Traffic

The output of the show dialer command in Example 9-246 indicates that the reason for the link coming up is OSPF multicast Hellos.

Example 9-246 Determining Why the DDR Link Keeps Coming Up

Solution
To solve this problem, deny OSPF Hellos in the interesting traffic. Example 9-247 shows the correct configuration change in R1. In this configuration, all traffic destined to the 224.0.0.5 address is denied. This means that OSPF Hellos or updates over this point-to-point link will not bring up the link after this configuration change.

Example 9-247 Configuring R1’s Access List to Deny OSPF Multicasts Hellos

It is not necessary to put 224.0.0.6 in the access list because only the DR uses this address. Also, because there is no DR over point-to-point links, there is no need to deny this address in the access list.

Problem: Demand Circuit Keeps Bringing Up the Link

The OSPF demand circuit feature was introduced in Cisco IOS Software Release 11.2. This feature forms the OSPF adjacency over a link and then later keeps the Layer 2 down to save the toll charges while keeping the OSPF adjacency over this link. If the link keeps coming up, it defeats the purpose of a demand circuit.

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

  • A link flap exists in the network.
  • The network type is defined as broadcast.
  • A PPP host route is getting redistributed into the OSPF database.
  • One of the routers is not capable of using a demand circuit.

Demand Circuit Keeps Bringing Up the Link—Cause: A Link Flap in the Network

The most common reason for a demand circuit to bring up the link is the existence of a link flap. A link flap occurs when a link in any part of the network goes up or down. This causes changes in the database information, and OSPF must bring up the link and refresh its database with the neighbor over the demand circuit. This is shown in the network setup in Figure 9-91. A link is flapping in area 0 and causes SPF in area 0. Because R1 is also a part of area 0, R1 will run SPF and then bring up the demand circuit link across R2 to inform its neighbor of this change.

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

Debugs and Verification
Example 9-248 shows the output of show dialer, which shows the last time the call was con-nected because of the OSPF Hello and indicates that the call has been connected for eight seconds.

Example 9-248 Determining Call History on the Dialer Interface

When a link is flapping in OSPF, it easily can be discovered with the debug ip ospf monitor command. This command output displays the exact LSA that is flapping in an area. Example 9-249 shows the output of debug ip ospf monitor, which shows that a change occurred in the OSPF database as the result of a router LSA regenerated by a router with a router ID of 192.168.1.129 because of a link flap in area 0.

Example 9-249 debug That Discovers the Culprit for a Link Flap

Solution
This is normal in demand circuits that must bring up the link and flood this change to the neighbor whenever there is a change in OSPF topology. A link flap in some area will regenerate a router LSA, which then regenerates the summary LSA for that network.

Because a link flap almost never can be avoided, a solution in this case would be to isolate this area as much as possible. In other words, try to run it as a stub or totally stubby area.

When an area is defined as a stub, no external link flap can bring up the dialup link. When the area is configured as totally stubby, no interarea flap can bring up the dialup link. This is because when an area is defined as a stub, no external LSA can enter a stub area; no external flap will be noticed in a stub area. Similarly, when an area is totally stubby, no summary LSA can exist in that area; any change in a summary LSA will not be noticed in a totally stubby area.

Example 9-250 shows that area 2 is configured as a totally stub area, so no interarea link flap can cause the link to go up.

Example 9-250 Configuring Area 2 as Totally Stubby to Prevent Interarea Link Flaps from Bringing Up the Link

The command no-summary is not really required on R2. It should be enough that the command is configured on R1, but this command will not cause any harm if it is configured on both ends.

Demand Circuit Keeps Bringing Up the Link—Cause: Network Type Defined as Broadcast

When a network type is defined as broadcast, OSPF Hellos are not suppressed. However, no flooding occurs every 30 minutes because the demand circuit is configured. So, by configuring the network type as broadcast, the only gain is optimal flooding; Hellos still bring up the link.

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

Debugs and Verification
The default network type of a PPP link is point-to-point, but someone manually changed the network type to broadcast. Example 9-251 shows the configuration on R1, which shows that the network type is defined as broadcast.

Example 9-251 R1’s BRI1/1 Interface Is Defined as Broadcast

Example 9-252 shows the output of the show ip ospf interface on the BRI 1/1 interface, which indicates that the Hellos are not suppressed.

Example 9-252 show ip ospf interface Command Output Reveals That OSPF Hellos Are Not Being Suppressed

This obviously means that OSPF Hellos will keep up the link at every Hello interval. Example 9-253 shows that the dial backup link is brought up by OSPF Hellos.

Example 9-253 OSPF Hellos Bring Up the Dial Backup Link

Solution
To solve this problem, change the network type back to point-to-point. This will keep OSPF Hellos from bringing up the link.

Example 9-254 shows the new configuration that solves this problem. The network type is not shown in the configuration because, by default, the network type on a BRI link is point-to-point.

Example 9-254 By Default, the BRI for R1 and R2 Now Is Configured as Point-to-Point

Example 9-255 shows that after changing the network type, the output of show ip ospf interface for the BRI1/1 interface indicates that it is suppressing Hellos for its neighbor over the demand circuit. Three significant things are highlighted in this example:

  • This link is now run as a point-to-point network.
  • The link is configured as a demand circuit.
  • OSPF Hellos are suppressed on this link.

Example 9-255 OSPF Hellos Are Suppressed for R1’s BRI1/1 Interface

Demand Circuit Keeps Bringing Up the Link—Cause: PPP Host Routes Are Getting Redistributed into the OSPF Database

When a PPP encapsulation is used over a link, it installs a host route for the remote neighbor’s IP address. This is normal for a PPP-encapsulated link. In OSPF, this host route never gets redistributed in the database. Specially, when OSPF is run as a demand circuit over a link, including this host route in the database can cause problems in constantly bringing up the link. Figure 9-94 shows a network in which a demand circuit perpetuates an active link as a result of PPP host routes getting redistributed into the OSPF database.

R1 is running RIP as well as OSPF and is doing redistribution of RIP into OSPF. The host route gets redistributed into the OSPF database because RIP owns the host route, which gets installed through PPP. RIP injects this route as an external route, and this causes the link flap.

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

Debugs and Verification
First, verify that the encapsulation is indeed PPP by looking into R1’s configuration. Example 9-256 shows the configuration on R1. The configuration reveals that R1’s BRI 1/1 is running PPP encapsulation. Also, R1 is redistributing RIP routes into OSPF; RIP has a network 131.108.0.0 statement, so any connected route in the range of 131.108.0.0 will be owned by RIP. This includes the PPP host routes as well.

Example 9-256 R1 Redistributes RIP Routes into OSPF

Because RIP has ownership of all the connected routes in the range for 131.108.0.0, it also owns this connected host route. When RIP is redistributed into OSPF, this host route gets redistributed as an external route in OSPF. Example 9-258 shows that this connected route is redistributed into the OSPF database because RIP has a network statement that includes this host route.

Example 9-258 Host Route Redistributed in OSPF Database as External

Solution
This problem is happening because RIP has a network statement of 131.108.0.0. By definition, any interface that falls under this address range is advertised by RIP. When the PPP connection gets established, a /32 host route is injected by PPP. This host route falls within the range of 131.108.0.0 because the BRI address is 131.108.1.0/24. Because RIP is being redistributed into OSPF, this /32 also gets redistributed into OSPF. When the link goes down, this /32 disappears and OSPF also removes it from the database, resulting in a convergence event.

When OSPF removes this route, a change in the OSPF database occurs, to bring up the demand-circuit interface again.

This problem can be solved in three ways:

  • Use no peer neighbor-route under the interface command if running Cisco IOS Software Release 11.3 or later.
  • Assign a different major network over the dialup link.
  • Filter the host route during redistribution.

Solution 1 is dependent upon the Cisco IOS Software Release being higher than version 11.3. Example 9-259 shows the new configuration on R1 that solves this problem.

Example 9-259 Removing PPP Host Routes from R1

After this command, R1 will not install the 131.108.1.2/32 route in its routing table, so this problem will not happen anymore.

Solution 2 can be difficult to implement, but if it can be done; RIP no longer will advertise the host route that gets installed by PPP.

Solution 3 is the more desirable solution because it is not dependent on any specific Cisco IOS Software release. Example 9-260 shows the new configuration that will solve this problem using this method. In this configuration, RIP is being redistributed into OSPF while filtering the connected host route through a route map. A route map normally filters routes during redistribution. The route map calls an access list; in this example, access list 1 has the connected host route that is being filtered.

Example 9-260 Filtering the Host Route During Redistribution

Demand Circuit Keeps Bringing Up the Link—Cause: One of the Routers Is Not Demand Circuit–Capable

The demand circuit will bring up the link if any router in the network does not understand the DNA LSA. DNA LSAs are discussed in detail in Chapter 8. Normally, this happens in two cases:

  • A router is a non-Cisco router with no demand circuit capability.
  • A router is a Cisco router running Cisco IOS Software earlier than Release 11.2 and does not support demand circuit.

Figure 9-96 shows a network setup in which a demand circuit perpetuates an active link because one of the routers is not demand circuit–capable. R1 is running Cisco IOS Software Release 11.1.20 and is not demand circuit–capable. All other routers are in area 1.

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

Debugs and Verification
Example 9-261 shows that R3’s BRI interface is defined as a demand circuit, but no DoNotAge LSAs are allowed in area 1.

Example 9-261 DNA LSAs Are Not Allowed in Area 1, but Hellos Still Are Suppressed

Because the OSPF Hellos are suppressed, the link will not come up during the Hello interval; however, the link will come up during LSA flooding when it’s time to refresh the LSA. Example 9-262 shows that the ISDN link is brought up because an LSA reaches the refresh time and the information is being flooded into the demand-circuit link. The output shows that an OSPF Hello packet brought up the link.

Example 9-262 LSA Flooding Brings Up the ISDN Link

Solution
The problem is happening because R1 is running an old code that does not support demand circuits. This case is mentioned in RFC 1793 for the demand circuit. The solution is not to originate any DoNotAge LSAs because the demand circuit–incapable router will not interpret them correctly.

Several solutions to this case exist. The easiest is to upgrade R1 to demand circuit–capable code.

This example represents the demand circuit bringing up the link within a single area. When multiple areas exist, a similar problem can occur. Figure 9-98 shows another setup that pro-duces this problem. R3 will bring up the ISDN link because R1 is incapable of understanding the DNA LSA. This particular case is discussed in more detail in Chapter 8, in the section “Demand Circuits.”

The solution in this case is to configure area 2 as a totally stubby area. By defining area 2 as totally stubby, no external or summary LSAs can get into area 2. This means that the indication LSA also will be blocked from entering area 2. Chapter 8 discusses the indication LSA in greater detail. Example 9-263 shows the configuration that changes area 2 into a totally stubby area. All the routers in area 2 must be configured as a stub area; otherwise, no routers will form an adjacency with R1.

Example 9-263 Configuring Area 2 as a Stub Area

The command no-summary needs to be added only to R3, but adding it on other routers in area 2 will not cause any harm. All other routers in area 2 must have at least the area 2 stub com-mand configured.

About the author

Prasanna

Leave a Comment