Cisco – OSPF Area Backbone(0) is Inactive

ciscoospfrouterrouting

I am having a puzzling issue with OSPF connectivity on one of my routers. The other routers in my network have formed an adjacency and are working correctly, but this last one is a case I've never seen before. All of the interfaces on the remaining router are up and functional and are connected to AREA 0 just as the other two routers are. However, a show ip ospf command results in the following:

 Area BACKBONE(0) (Inactive)

        Number of interfaces in this area is 3

Additionally, I get nothing if I try to ping 224.0.0.5 or 224.0.0.6 from this router. I've tried restarting the OSPF process on the router as well as rebooting the router itself, but it makes no difference. When I turn debugging on, I can see the router isn't even sending OSPF hello messages. What could be the cause of something like this?

The router interfaces are configured as follows for the router in question:

f0/0 - 111.1.0.2/8
f0/1 - 112.1.0.2/8
f0/2/0 - (Vlan5) 122.0.0.1/8
f0/2/3 - (Vlan88) 10.10.10.1/28

Here is the entire router config along with OSPF process info and interface statuses:

router_1#sh ip ospf 
 Routing Process "ospf 10" with ID 122.0.0.1
 Start time: 00:00:19.304, Time elapsed: 18:57:25.596
 Supports only single TOS(TOS0) routes
 Supports opaque LSA
 Supports Link-local Signaling (LLS)
 Supports area transit capability
 Router is not originating router-LSAs with maximum metric
 Initial SPF schedule delay 5000 msecs
 Minimum hold time between two consecutive SPFs 10000 msecs
 Maximum wait time between two consecutive SPFs 10000 msecs
 Incremental-SPF disabled
 Minimum LSA interval 5 secs
 Minimum LSA arrival 1000 msecs
 LSA group pacing timer 240 secs
 Interface flood pacing timer 33 msecs
 Retransmission pacing timer 66 msecs
 Number of external LSA 0. Checksum Sum 0x000000
 Number of opaque AS LSA 0. Checksum Sum 0x000000
 Number of DCbitless external and opaque AS LSA 0
 Number of DoNotAge external and opaque AS LSA 0
 Number of areas in this router is 1. 1 normal 0 stub 0 nssa
 Number of areas transit capable is 0
 External flood list length 0
 IETF NSF helper support enabled
 Cisco NSF helper support enabled
    Area BACKBONE(0) (Inactive)
    Number of interfaces in this area is 3
    Area has no authentication
    SPF algorithm last executed 01:36:13.484 ago
    SPF algorithm executed 3 times
    Area ranges are
    Number of LSA 1. Checksum Sum 0x00F9B7
    Number of opaque link LSA 0. Checksum Sum 0x000000
    Number of DCbitless LSA 0
    Number of indication LSA 0
    Number of DoNotAge LSA 0
    Flood list length 0

 router_1#sh ip int br
    Interface                  IP-Address      OK? Method Status                Protocol
    FastEthernet0/0            111.1.0.2       YES NVRAM  up                    up      
    FastEthernet0/1            112.1.0.2       YES NVRAM  up                    up      
    FastEthernet0/2/0          unassigned      YES unset  up                    up      
    FastEthernet0/2/1          unassigned      YES unset  administratively down down    
    FastEthernet0/2/2          unassigned      YES unset  administratively down down    
    FastEthernet0/2/3          unassigned      YES unset  up                    up      
    Vlan1                      unassigned      YES NVRAM  administratively down down    
    Vlan5                      122.0.0.1       YES NVRAM  up                    up      
    Vlan88                     10.10.10.1      YES NVRAM  up                    up      

router_1#sh run
Building configuration...

Current configuration : 3904 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname router_1
!
boot-start-marker
boot-end-marker
!
enable secret 5 $1$iXM1$Rcki3hrzpXULV8lCJXDqY1
!
no aaa new-model
!
!
ip cef
!
!
no ip domain lookup
multilink bundle-name authenticated
!
!
!
username thedoctor privilege 15 secret 5 $1$KUwA$VWYQeI/fm8LacwgysL7RK/
archive
 log config
  hidekeys
!
!
!
class-map match-all data-inmmediate
 match ip dscp af13 
class-map match-all class-all
 match any 
class-map match-all data-priority
 match ip dscp af23 
class-map match-all data-routine
 match ip dscp default 
class-map match-all data-flash
 match ip dscp default 
 match ip dscp af33 
class-map match-all video
 match ip dscp cs4  33  af41  35  af42 
class-map match-all data-flash-override
 match ip dscp 31 
class-map match-all voice
 match ip dscp cs5  41  42  43  44 
!
!
policy-map ecn-llq-enable
 class voice
  priority 48
 class video
  bandwidth percent 1
  random-detect dscp-based
  random-detect exponential-weighting-constant 1
  random-detect ecn
  random-detect dscp 32   8     16    16   
  random-detect dscp 33   16    24    16   
  random-detect dscp 34   24    32    16   
  random-detect dscp 35   32    40    16   
  random-detect dscp 36   40    48    16   
 class data-flash-override
  bandwidth percent 35
  random-detect dscp-based
  random-detect exponential-weighting-constant 1
  random-detect ecn
  random-detect dscp 31   70    4000  2    
 class data-flash
  bandwidth percent 1
  random-detect dscp-based
  random-detect exponential-weighting-constant 1
  random-detect ecn
  random-detect dscp 30   80    96    16   
 class data-priority
  bandwidth percent 1
  random-detect dscp-based
  random-detect exponential-weighting-constant 1
  random-detect ecn
  random-detect dscp 22   96    112   12   
 class data-inmmediate
  bandwidth percent 1
  random-detect dscp-based
  random-detect exponential-weighting-constant 1
  random-detect ecn
  random-detect dscp 14   112   128   8    
 class data-routine
  bandwidth percent 25
  random-detect dscp-based
  random-detect exponential-weighting-constant 1
  random-detect ecn
  random-detect dscp 0   2     4000  2    
policy-map shape-all-ncw
 class class-all
  shape average 128000
  service-policy ecn-llq-enable
policy-map shape-all-hnw
 class class-all
  shape average 1000000
  service-policy ecn-llq-enable
!
!
!
!         
interface FastEthernet0/0
 description Intermidiate_Router_GW
 ip address 111.1.0.2 255.0.0.0
 ip ospf cost 400
 duplex auto
 speed auto
 service-policy output shape-all-hnw
!
interface FastEthernet0/1
 description Router2
 ip address 112.1.0.2 255.0.0.0
 ip ospf cost 600
 duplex auto
 speed auto
 service-policy output shape-all-hnw
!
interface FastEthernet0/2/0
 description ENCRYPTION1
 switchport access vlan 5
!
interface FastEthernet0/2/1
 shutdown
!
interface FastEthernet0/2/2
 shutdown
!
interface FastEthernet0/2/3
 description AF_NM
 switchport access vlan 88
!
interface Vlan1
 no ip address
 shutdown
!
interface Vlan5
 description ENCRYPTION1
 ip address 122.0.0.1 255.0.0.0
!
interface Vlan88
 description AF_NM
 ip address 10.10.10.1 255.255.255.248
!
router ospf 10
 log-adjacency-changes
 network 111.0.0.0 0.255.255.255 area 0
 network 112.0.0.0 0.255.255.255 area 0
 network 122.0.0.0 0.255.255.255 area 0
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 120.0.0.1
ip route 122.1.1.0 255.255.255.0 122.0.0.2
ip route 122.1.2.0 255.255.255.0 122.0.0.2
!         
!
ip http server
ip http access-class 23
ip http authentication local
ip http timeout-policy idle 60 life 86400 requests 10000
!
access-list 23 permit 10.10.10.0 0.0.0.7
!
!
control-plane
!
!
line con 0
 login local
line aux 0
line vty 0 4
 privilege level 15
 login local
 transport input telnet
line vty 5 15
 privilege level 15
 login local
 transport input telnet
!
scheduler allocate 20000 1000
!
end

Best Answer

Well, this is kinda funny. Firstly, I should mention that this is a project that I was recently asked to work on where everyone that previously worked on it has left the company and there is next to no documentation. All I had to go on was a grossly inaccurate network topology diagram which I am in the process of redrawing.

Anyway, after investigating a million other things, I traced the tremendous mess of cables behind the server racks to look at the multiple ethernet cables from the segment that wasn't talking to the rest of the network. This is where I saw no link lights for the ethernet ports on the back of a server whereas the front panel showed several green lights. What I found out is that the front panel of the server will show those green lights even when it isn't turned on! Since it was off, there was no active connection from that particular server rack to the rest of the network. After turning it on, I checked the router again and AREA 0 is no longer inactive. It now has its OSPF neighbors and routes that it should have and the end devices are able to communicate properly. So, everything works now that the server has been turned on.

In summary, one needs to always ask the following two questions:

Are you sure it's plugged in?
Have you tried turning it off and on again?

OSPF Backbone

Why is area 0 the backbone area in OSPF? Why must all other areas connect to it?

This is explained very well in RFC 3509, Section 1.2¹:

1.2 Motivation

In OSPF domains the area topology is restricted so that there must be a backbone area (area 0) and all other areas must have either physical or virtual connections to the backbone. The reason for this star-like topology is that OSPF inter-area routing uses the distance-vector approach and a strict area hierarchy permits avoidance of the "counting to infinity" problem. OSPF prevents inter-area routing loops by implementing a split-horizon mechanism, allowing ABRs to inject into the backbone only Summary-LSAs derived from the intra-area routes, and limiting ABRs' SPF calculation to consider only Summary-LSAs in the backbone area's link-state database.

OSPF is usually considered a link-state protocol. What some people miss is that OSPF uses both link-state protocol and distance-vector protocol algorithms.

Routes within the backbone, or a non-backbone area are computed as a link-state protocol does (ref Dijkstra's algorithm).
When OSPF must carry non-backbone routes through the backbone, it uses some distance-vector behavior (i.e. parts of the Bellman Ford algorithm) to propagate Type3 LSA metrics into non-backbone areas.

Simple example of OSPF's distance-vector behavior:

<-- Area 5 --><-- Area 0 --><--           Area 4           -->

R5-----------R1-----------R2------------R3---------------------R4
     Cost 3      Cost 5        Cost 7            Cost 12

               LSA-->          LSA-->
               Type3 LSA       Type3 LSA
               {From R1}       {From R2}
               R5 cost is 3    R5 cost is 8

Consider what happens to a /32 Loopback route for R5.

R5 sends a Type1 LSA containing the /32 Loopback
R1 (Area 5 ABR), is connected to Area 0; it translates the Type1 LSA into a Type3 LSA with a cost of 3.
R2 (Area 4 ABR) receives R1's Type3 LSA (metric 3) and changes the metric to R5's Loopback, based on R2's cost to R1. Now R2's Type3 LSA for R5 has a cost of 8. This is the distance-vector behavior I mentioned above.

Requiring all non-backbone routes to go through the backbone is a loop-prevention mechanism.

Connecting non-backbone OSPF areas at an ABR

If 2 areas aren't connected through area 0 (discontiguous), how does OSPF behaving as a link state protocol increase the possibility of routing loops?

As we saw above, OSPF uses distance-vector behavior to send routes through the Area 0 backbone. Distance-vector protocols have well-known limits, such as the count-to-infinity problem. OSPF would be vulnerable to the same issues, if we didn't have boundaries on its behavior.

¹_{RFC 3509 describes Cisco IOS's ABR behavior}

How does the backbone area prevent routing loops in ospf

Imagine a network with three areas: 0, 1 and 2. Area 0 is connected to 1 and 2; area 1 is connected to 0 and 2; and area 2 is connected to 0 and 1. Further, imagine that in this network, there is nothing special about area 0 -- in this network, backbone rules don't apply.

Area 1 learns about routes from area 2 from two sources: area 2 and area 0. Now let's say that because of metrics, the shortest path to area 2 is through area 0 (instead of your direct connection). Area 0 also learns about area 2 from area 1 and area 2. But because of misconfigured metrics, the shortest path to area 2 is through area 1.

So if you send data from area 1 to area 2, the packets get forwarded to area 0, but area 0 forwards them back to area 1. This is a classic routing loop.

Instead, if we make area 0 a backbone, and say areas can only receive routes from the backbone, then there is only one possible path to area 2 -- through the backbone. Area 1 will ignore routes being advertised directly from area 2. In this way there are no multiple paths, and therefore no loops.

Best Answer

Related Solutions

Routing – Why must all areas connect to an Area 0 backbone in OSPF

OSPF Backbone

Connecting non-backbone OSPF areas at an ABR

How does the backbone area prevent routing loops in ospf

Related Topic