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-91. OSPF Network Suffering from a Chronically Active Link Caused by a Demand Circuit

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

Figure 9-92. Problem-Resolution Flowchart

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

 R1#  show dialer  BRI1/1:1 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (2 secs) Dialer state is data link layer up  Dial reason: ip (s=192.168.254.13, d=224.0.0.5)  Current call connected 00:00:08 Connected to 57654 (R2) 

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

 R1#  debug ip ospf monitor  OSPF: Schedule SPF in area 0.0.0.0  Change in LS ID 192.168.1.129, LSA type R,  OSPF: schedule SPF: spf_time 1620348064ms wait_interval 10s 

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

 On R1 and R2:  router ospf 1   network 192.168.254.0 0.0.0.255 area 2   area 1 stub no-summary  

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.

Figure 9-93. Problem-Resolution Flowchart

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

 R1#  interface BRI1/1   ip address 192.168.254.13 255.255.255.0    ip ospf network 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

 R1#  show ip ospf interface bri1/1  BRI1/1 is up, line protocol is up  Internet Address 192.168.254.13/24, Area 1   Process ID 1, Router ID 192.168.254.13,  Network Type BROADCAST,  Cost: 64   Transmit Delay is 1 sec, State BDR, Priority 240   Designated Router (ID) 192.168.254.14, Interface address 192.168.254.14   Backup Designated router (ID) 192.168.254.13, Interface address 192.168.254.13   Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5  Hello due in 00:00:21  

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

 R1#  show dialer  BRI1/1:1 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (2 secs) Dialer state is data link layer up  Dial reason: ip (s=192.168.254.13, d=224.0.0.5)  Interface bound to profile Di1 Current call connected 00:00:08 Connected to 57654 (R2) 

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

 R1#  interface BRI1/1   ip address 192.168.254.13 255.255.255.0    no ip ospf network broadcast    !  R2# interface BRI0/1  ip address 192.168.254.14 255.255.255.0    no ip ospf network broadcast   ! 

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

 R1#  show ip ospf interface BRI1/1  BRI1/1 is up, line protocol is up   Internet Address 192.168.254.13/24, Area 1   Process ID 1, Router ID 192.168.254.13,  Network Type POINT_TO_POINT  , Cost: 64  Configured as demand circuit.  Run as demand circuit.   DoNotAge LSA allowed.   Transmit Delay is 1 sec, State POINT_TO_POINT,   Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5     Hello due in 00:00:06   Neighbor Count is 1, Adjacent neighbor count is 1     Adjacent with neighbor 192.168.254.14  (Hello suppressed)  Suppress hello for 1 neighbor(s)  

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.

Figure 9-94. Network Suffering from a Chronically Active Link Caused by a Demand Circuit Because of PPP Host Route Redistribution

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.

Figure 9-95. Problem-Resolution Flowchart

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

 R1#  interface BRI1/1    encapsulation PPP    ip address 131.108.1.1 255.255.255.0   router ospf 1    redistribute rip subnets    network 131.108.1.0 0.0.0.255 area 1   !   router rip   network 131.108.0.0  

Example 9-257 shows that a /32 route gets installed into R1's routing table for 131.108.1.2.

Example 9-257 R1 Is Installing a PPP Host Route for R2

 R1#  show ip route 131.108.1.2   Routing entry for 131.108.1.2/32  Known via "connected", distance 0, metric 0 (connected, via interface)   Routing Descriptor Blocks:   * directly connected, via BRI1/1       Route metric is 0, traffic share count is 1 

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

 R1#  show ip ospf database external 131.108.1.2  OSPF Router with ID (131.108.3.1) (Process ID 1)  Type-5 AS External Link States  LS age: 298   Options: (No TOS-capability, DC)   LS Type: AS External Link  Link State ID: 131.108.1.2 (External Network Number )  Advertising Router: 131.108.3.1   LS Seq Number: 80000001   Checksum: 0xDC2B   Length: 36  Network Mask: /32  Metric Type: 2 (Larger than any link state path)         TOS: 0         Metric: 20         Forward Address: 0.0.0.0         External Route Tag: 0 

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

 R1#  interface BRI1/1  ip address 131.108.1.1 255.255.255.0  encapsulation ppp  no peer neighbor-route  

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

 R1#  router ospf 1    redistribute rip subnets route-map rip_filter    network 131.108.1.0 0.0.0.255 area 1   !   router rip   network 131.108.0.0   !    route-map rip_filter permit 10     match ip address 1    !   access-list 1 permit 131.108.3.0 0.0.0.255  

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-96. Network with a Router That Does Not Support Demand Circuits

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

Figure 9-97. Problem-Resolution Flowchart

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

 R3#  show ip ospf interface BRI1/1  BRI1/1 is up, line protocol is up   Internet Address 131.108.1.1/24, Area 1   Process ID 1, Router ID 131.108.3.3, Network Type POINT_TO_POINT, Cost: 64  Configured as demand circuit.   Run as demand circuit.   DoNotAge LSA not allowed (Number of DCbitless LSA is 1).  Transmit Delay is 1 sec, State POINT_TO_POINT,   Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5     Hello due in 00:00:01   Neighbor Count is 1, Adjacent neighbor count is 1     Adjacent with neighbor 131.108.2.2  (Hello suppressed)  Suppress hello for 1 neighbor(s)  

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

 R3#  show dialer  BRI1/1:1 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (2 secs) Dialer state is data link layer up  Dial reason: ip (s=131.108.1.1, d=224.0.0.5)  Interface bound to profile Di1 Current call connected 00:00:08 Connected to 57654 (R2) 

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."

Figure 9-98. Demand Circuit Brings Up the Link in Multiple Areas

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

 R3#  router ospf 1   network 131.108.1.0 0.0.0.255 area 2   area 2 stub no-summary  

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.