notes: OSPF Troubleshooting Route Advertisement

II.  Troubleshooting Route Advertisement

The most common reasons for OSPF to not share the database information about a specific link are as follows:

1.  The OSPF neighbor is not advertising routes.

      When a neighbor doesn't advertise a route, that route will not show up in the local router's routing table. 

      This means that the neighbor has not included the route in its database; otherwise, the local router must have 

      received it.

• OSPF is not enabled on the interface that is supposed to be advertised.
  
  
  OSPF includes the interface subnet address in its database only if the OSPF is enabled on that interface. OSPF might not be enabled on an interface because of an incorrect network state-ment that doesn't cover the IP address assigned on an interface or a missing network statement for that interface address. In both cases, OSPF will exclude the interface address from its data-base and will not advertise to its neighbor.
  
  
  show ip ospf database router x.x.x.x
  show ip ospf interface
  Solution: add the proper network statement for the interface you wish to include in the ospf process.
  network x.x.x.x wildcard area #
  
  
  Verification:
  show ip ospf database router x.x.x.x
  the network will appear in the output.
  show ip route x.x.x.x
  the network should be installed in the routing table.
• The advertising interface is down.
  OSPF does not advertise a network that is down. If an interface is down, the network assigned to that interface is not advertised in a router's LSA.
  
  
  show ip ospf interface
  
  
  Solution: bring up the interface, if the problem is related to layer2 check the procedure for layer 2 problem.
  Verification:
  show ip ospf interface
  show ip route x.x.x.x
  
  
• The secondary interface is in a different area than the primary interface.
  When dealing with secondary addresses, OSPF requires the secondary address to belong to the same area as the primary address. If this is not followed, OSPF will not advertise the secondary address in its router LSA.
  
  show ip ospf database router x.x.x.x
  output shows that if the secondary is in other area it will have zero no of links.
  
  Solution: change the configuration, so that the area for the secondary address should be the same as the area of primary address.
  
  Verification:
  
  show ip ospf database router x.x.x.x
  show ip route x.x.x.x
  
  

 2.  The OSPF neighbor (ABR) is not advertising the summary route.

       When OSPF is configured with more than one area, one area has to be a backbone area. The router 

       that sits at the border of the backbone and any other area is the ABR. The ABR generates the summary  

       LSA for one area and sends it to another area. When the ABR fails to generate the summary LSA, the 

      areas become isolated from each other.

• An area is configured as a totally stubby area.
  When an area is configured as a stubby area, no external LSA can be leaked into that area. Similarly, an area can be configured as a totally stubby area, which means that no external or summary LSAs can be leaked into this area.
  
  
  show ip ospf database summary x.x.x.x
  area that is configured as a totally stubby area, so no summary LSA is originated for this area by the ABR.  If there is only a single exit point, there is no need to receive specific summary LSAs in an area; the default summary LSA of 0.0.0.0 is sufficient. This is also true in the case of a totally stubby NSSA area.
  Solution:
  Because this is normal behavior, no solution is given for this. However, if multiple ABRs exist for this area and receiving a specific summary LSA is necessary to avoid suboptimal routing, just remove the no-summary keyword from the area 2 configuration on ABR. This will make area 2 a stub and all the summary LSAs will be leaked into this area.
  
  
• An ABR is not connected to area 0.
  When a router is connected to more than one area, one of those areas must be area 0. The ABR will not generate summary LSAs if it is not connected to area 0. This is standard OSPF behavior.
  
  
  show ip ospf database summary
  - no output will show for area 0.
  show ip ospf
  - output will not show that the router is an ABR.
  Solution:  create a backbone area. After a backbone area is created on R1, it will start generating summary LSAs.  If no area 0 exists in the network, one of the areas must be changed to area 0 for OSPF to work properly.
  
  
   Verification:
   show ip ospf
   show ip ospf database summary
  
  
  
  
• A discontiguous area 0 exists.
  OSPF network experiencing this problem. somehow the link is broken between 2 routers, which makes area 0 discontiguous.

          show ip route x.x.x.x
          output will show that the route is inter-area which is supposed to be intra-area.
          show ip ospf database summary x.x.x.x
          output will not show any summary because ABR is not generating

          Solution:
          This is a bad design, the backbones are attached to each other through one link.  if that link fails, the
          backbone becomes discontiguous.  to fix this problem be sure to avoid SPOF.
          Use Virtual-link between the other pair of ABRs
          
          area # virtual-link x.x.x.x

          Verification:

    show ip ospf database router x.x.x.x

    show ip route x.x.x.x

3.  The OSPF neighbor is not advertising external routes.
     Whenever there is a redistribution in OSPF, it generates an external LSA (Type 5) that is flooded
     throughout the OSPF network. External LSAs are not leaked into stub, totally stubby, and NSSA areas.

• • The area is configured as a stub or NSSA.
    In OSPF, Type 5 LSAs are not allowed in a stub or NSSA area. When entering the redistribute command on a router that is completely in a stub or NSSA area, a warning message is displayed. This redistribute command in the configuration is incapable of importing any external LSAs into a stub or NSSA area.
    
    
    R1(config)#router ospf 1 
    R1(config-router)#redistribute rip subnets  
    Warning: Router is currently an ASBR while having only one area which is a stub area
    
    
    show ip ospf database external x.x.x.x
    
    
    Solution:
    This problem can be solved in two ways. 
    
    
    1.  to make area 2 a normal area by taking out the area 2 stub command on all the routers in area 2. This is not a good solution because sometimes, a stub area does not require external LSAs.
    
    2.   is a preferred solution that involves changing the entire area as an NSSA. An NSSA permits redistribution of external routes. However, the NSSA will not generate Type 5 LSAs. It will generate Type 7 LSAs, which will be converted to Type 5 LSAs by the NSSA ABR.
    
    

    router ospf 1

    area 2 nssa
    
    Verification:
    

    show ip ospf database nssa-external x.x.x.x

    
    
    
  • The NSSA ABR is not translating Type 7 into Type 5 LSA.

             NSSA RFC 1587 states that before NSSA ABR converts from Type 7 into Type 5, all NSSA 

             ABRs must examine all NSSA ABRs for a particular NSSA. The ABR with the highest router 

             ID must do the conversion of Type 7 into Type 5. If Type 7 is not translated into Type 5 by the 

             NSSA ABR, no routers outside of NSSA become aware of the external route redistribution 

             that is happening within the NSSA. This defeats the entire purpose of NSSA.

            
             show ip ospf database nssa-external x.x.x.x
             show ip ospf database external x.x.x.x
             - output shows that type 7 are not converted to type 5.
             show ip ospf
             - this is to confirm that the router is an NSSA ABR.
             show ip ospf database external x.x.x.x
            - check if other router is doing the type7 to type5 conversion, checking further on that router,
               one segment is indeed in area0 thats why it is doing the conversion.
          
             Solution: router id plays also a  role of converting the type7 to type5 by having the highest router
             id. 
                1.  Remove the wrong network statement.

                2.  Change the router ID of R1 so that it is lower than R2's.

                3.   Change the router ID of R2 so that it is higher than R1's.

  
  

  
             Verification:
             show ip ospf database external x.x.x.x
  
  4.  The OSPF neighbor is not advertising the default route.
       Sometimes, OSPF uses a default route for destinations that are unknown to OSPF. Most of the
       time, these destinations are networks external to OSPF. Instead of importing all the external routes
       into OSPF, just one default route is needed that will be used for all unknown external destinations.
       In the absence of such a default route, all the traffic destined for any unknown address will be
       dropped by OSPF.
  
      
  

  • The default-information originate command is missing.
    OSPF does not originate the default route unless the OSPF default-information originate command is present in the OSPF configuration. This command originates the default route on the router on which it is configured. There is no other way in OSPF to generate the default route.  
    
    
    @ router that injects the external route via redistribution and is verified under ospf process command
    show ip route 0.0.0.0
    default route is not installed in the routing table.
    show ip ospf database external 0.0.0.0
    is not in the database either.
    
    
    Solution:  In this example, even though the router is receiving a default route from RIP, it's not getting redistributed into the OSPF database.
    
    
    To solve this problem, configure the default-information originate command
    
    
    Verification:
    show ip route 0.0.0.0
    
    show ip ospf database external 0.0.0.0
    
    
  • The default route is missing from the neighbor's routing table.
    OSPF will not originate the default route unless the command default-information originate is configured under router OSPF. This command has one more restriction: The router must have a default route in its routing table to originate a default route.
    R1#show ip route 0.0.0.0  
    % Network not in table
    show ip ospf database external 0.0.0.0
    - not output
    verify that default-information originate is configured under ospf routing process.
    Solution:
    This problem can be solved in two ways. 
    1.  One is to make sure that the default route is present in the routing table.  It could be derived from any other routing protocol, including static or default route information.
     
    2.  to use the always keyword with default-information originate. The always keyword instructs the router to originate the default whether or not there is a default present in the routing table.
    
    
    default-information originate always 
    
    
    Verification:
    show ip route 0.0.0.0
    show ip ospf database external 0.0.0.0
    
    
  • A neighbor is trying to originate a default into a stub area.
     When an area is defined as a stub, no external LSAs are allowed in it. This includes the Type 5 default external LSAs created by the default-information originate command on a router. An ABR automatically generates a Type 3 summary LSA default in a stub area; however, if a default-information originate command is configured on the ABR or non-ABR, it is not advertised as the default route because this command generates Type 5 LSAs, which are not allowed in a stub area.
    
    
    R1(config)#router ospf 1 
    R1(config-router)#default-information originate  
    Warning: Router is currently an ASBR while having only one area which is a stub area 
    
    
    show ip ospf database external 0.0.0.0 
     - no output
    Solution:
    In this example, all the interfaces of Router are included in area 2, which is a stub area. When the default-information originate command is configured, it simply ignores the area with a warning.
    Normally, when an area is defined as a stub, a Type 3 summary default is generated by the ABR.
    
    
    This problem can be solved in three ways:
     1.  Change the area to NSSA and then originate a Type 7 default.
    2.  Change the stub area to a normal area and then originate a default route.  is not a good one because area 2 will become a normal area and will contain unnecessary Type 5 LSAs. In this case, however, it is an acceptable solution. 
    
    
    router ospf 1 
    network 131.108.1.0 0.0.0.255 area 2  
    network 131.108.2.0 0.0.0.255 area 2  
    default-information originate  
    no area 2 stub 
    
    
    3.  Configure a static default route.
          simple to implement. The requirement is to override the summary default route that is 
          coming from the ABR in case the area is defined as a stub. If that summary default is 
          desirable, there is no need for any change in the configuration.
    
    

  •  The NSSA ABR/ASBR is not originating the Type 7 default.
    When an NSSA is defined, by default, the NSSA ABR does not originate any default route. This is not the case in stub areas or totally stubby areas. When an area is defined as a stub, the ABR originates the Type 3 default route in the form of a summary LSA. This is because a stub area cannot have any Type 5 LSAs, so the default route must not be a Type 5 LSA. This is also true in totally stubby areas.  When an NSSA area is defined with the no-summary option, the NSSA ABR automatically generates a Type 3 summary default. 
    
    
    in this case the router below is misconfigured.
    router ospf 1  
    network 131.108.1.0 0.0.0.255 area 2  
    network 131.108.2.0 0.0.0.255 area 2  
    default-information originate 
    area 2 nssa 
    
    
    show ip ospf database external 0.0.0.0
    show ip ospf database nssa-external 0.0.0.0
    
    - there will be no output
    Solution:  Originating a default route in NSSA
    
    
    router ospf 1 
    network 131.108.1.0 0.0.0.255 area 2 
    network 131.108.2.0 0.0.0.255 area 2 
    area 2 nssa default-information originate
     
    Verification:
    note:  In the past, this command worked only on an NSSA ABR, but Cisco IOS Software Release 12.0.11 and 12.1.2 provide support for this to work on NSSA ASBRs as well.
    show ip route 0.0.0.0