notes: OSPF Troubleshooting Dial-on-Demand Routing Issues

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 lin  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.
  
  
   R1# interface BRI3/0  
  ip address 192.168.254.13 255.255.255.252  
  encapsulation ppp  
  dialer map ip 192.168.254.14 name R2 broadcast 57654  
  dialer-group 1  
  isdn switch-type basic-net3  
  ppp authentication chap  
  
  
  access-list 100 deny tcp any any  
  access-list 100 permit ip any any 
  dialer-list 1 protocol ip list 100 
  
  
  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)
  
  
   
  Solution:  Deny hello packets in the interesting traffic.                                                                           

          access-list 100 deny tcp any any                                   
          access-list 100 deny ip any 224.0.0.5            
          access-list 100 permit ip any any
          dialer-list 1 protocol ip list 100
          

          Note:  

                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: OSPF Hellos are not getting across the link*
  - this was discussed in "Troubleshooting ospf neighbhor relationship.

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

           show dialer
           shows the last time the call was con-nected because of the OSPF Hello
          debug ip ospf monitor
           This command output displays the exact LSA that is flapping in an area

           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.

          

          router ospf 1 

          network 192.168.254.0 0.0.0.255 area 2 

          area 2 stub no-summary

     

•  The network type is 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.
  
  
  show ip ospf interface
  check the interface if it is configured as ospf broadcast.
  
  
  show dialer
  This obviously means that OSPF Hellos will keep up the link at every Hello interval
  
  
  Solution:  change the network type back to point-to-point. This will keep OSPF Hellos from bringing up the link.  by default network type on BRI link is point to point.
  Verification:
   show ip ospf interface
  
  
• A PPP host route is 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.  
  
  
  
  
  
  
  
  
  
  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.
  
  
  Verify that ppp is indeed used
  show interface
  
  
  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.
  
  
  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
  
  
  that a /32 route gets installed into R1's routing table for 131.108.1.2.
  
  
  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 
  show ip ospf database external 131.108.1.2  
  -output shows that this was tagged as external route.
  
  
  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:
  
  
  1.   Use no peer neighbor-route under the interface command if running Cisco IOS Software Release 11.3 or later.  dependent upon the Cisco IOS Software Release being higher than version 11.3
  
  

   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
  
  
  2.  Assign a different major network over the dialup link.
       can be difficult to implement, but if it can be done; RIP no longer will advertise the host route that gets installed by PPP.
  
  
  3.  Filter the host route during redistributio - more desirable solution because it is not dependent on any specific Cisco IOS Software release.  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.
  
  
   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
   
  
  
• One of the routers is not capable of using a demand circuit.
  
  
  The demand circuit will bring up the link if any router in the network does not understand the DNA LSA. DNA LSAs  this happens in two cases:
  
  
      1.  A router is a non-Cisco router with no demand circuit capability.
  
  
      2.  A router is a Cisco router running Cisco IOS Software earlier than Release 11.2 and does not support demand circuit.
  
  
  
  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.
  
  
  shows that R3's BRI interface is defined as a demand circuit, but no DoNotAge LSAs are allowed in area 1.
  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. below 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.
  
  
  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. below shows another setup that pro-duces this problem. R3 will bring up the ISDN link because R1 is incapable of understanding the DNA LSA.
  
  
  
  
  
  
  
  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. below  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.
  
  
  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.