In this blog post, you learn methods and Cisco IOS commands related to troubleshooting OSPF route advertisement problems, regardless of the nature of the route that is not getting advertised to OSPF neighbors. The OSPF route can be associated with an attached network, a summary route (inter-area route), an aggregate route, a default route, or an external route.
I will discuss common reasons that can cause problems with OSPF route advertisement and show you how to fix each problem.
In this post, I assume that there are no OSPF adjacency issues. If you want to learn how to fix them, check out this guide about troubleshooting OSPF neighbor adjacency problems.
Troubleshooting OSPF Route Advertisement: Reasons That Cause an OSPF Node To Not Share a Particular Route or Network Link
Here are the common possible reasons why an OSPF-enabled router fails to advertise a particular link/route to OSPF neighbors:
- Interface is down.
- Interface is not associated with an OSPF process.
- The secondary IP address of a neighboring interface is in a different area than the primary IP address.
- The ABR router does not have an interface in area 0 or an OSPF virtual link is missing or not configured properly.
- The backbone area is discontiguous.
- The area intended to receive the summary routes (inter-routes) is a totally stubby area or a totally NSSA area.
- The subnets keyword is not used along with the redistribute command.
- The area intended to receive Type 5 LSAs advertising external routes is configured as a stubby area (stub area, totally stubby area, NSSA area, or totally NSSA area).
- OSPF stub and totally stubby areas are blocking external routes, including redistributed routes into those areas.
- The 0.0.0.0/0 route does not exist from the originating router’s routing table.
- Stubby area not allowing the OSPF default route.
- Type 7 OSPF default route configured using the wrong command.
The default-information originate command is not present in the OSPF node’s OSPF configuration. - OSPF route summarization is configured on the wrong router.
- OSPF route summarization is set up using the wrong cisco IOS command.
- The summary IP address does not have a matching IP prefix in the OSPF RIB table.
- OSPF route summarization is configured with the wrong summary IP address or subnet mask.
- OSPF route summarization is configured using the wrong OSPF area number.
- Inappropriate designated router is selected on hub and spoke networks.
Before starting discussing each reason that causes a router to not advertise a particular route/link, note that to verify if OSPF has a route to a particular IP prefix, you can use the show ip ospf rib command, the show ip route command, or the show ip ospf database command.
But it would be a bit frustrating to find out whether a router has an LSA describing a particular IP prefix, so using the show p ospf rib command would be more handy.
Basically, you cannot rely on the show ip route command unless OSPF is the only dynamic routing protocol deployed on the current routing domain.
If the same IP prefix is learned via different routing sources, including OSPF, and one of them has an administrative distance smaller than OSPF’s one, then the route to that IP prefix won’t appear as an OSPF route in the global routing table.
Therefore, the show ip route command is not a reliable command to check if a route is getting successfully advertised to a particular OSPF node.
In general, if a router is implementing OSPF only and has no static routes, using the show ip route command would be like using show ip ospf rib command; otherwise, you must use the show ip ospf rib command to check whether a route is getting shared with the current router or not.
In this guide, we prefer to use the show ip ospf rib command to avoid any confusion or ambiguity.
Keep in mind that we don’t care about OSPF route installment in this guide, therefore we assume that if a router does not have a route to a particular subnet/network, the router does not receive the corresponding LSA that describes that route/link.
The following sections examines each of the causes above, show how to get rid of each of them, and teach you how to make OSPF advertise a route again.
Troubleshooting OSPF-Enabled Interface Route Advertisement
For a router to advertise an IP-enabled interface to OSPF neighbors, the interface should be in the up/up state, meaning there are no Layer 1 or Layer 2 issues. Additionally, the interface should match a network statement or be associated with an OSPF instance using the ip osfp area command.
Here are the possible reasons why a router may not advertise a local interface in OSPF:
- Interface is down
- Interface is not associated with an OSPF process
- The secondary IP address of a neighboring interface is in a different area than the primary IP address.
In this section, I will be using the following network diagram. The OSPF routing domain consists of two routers and one OSPF area. The router IDs of R1 and R2 are 1.1.1.1 and 2.2.2.2, and the OSPF network type of Loopback interfaces is set to point-to-point.
Here are the initial router configurations used in this section.
| Router R1 | Router R2 |
Interface is Down
For an IP prefix associated with an OSPF-enabled interface to be advertised in the OSPF routing domain, the interface should be in the up/up state, meaning that the interface has no Layer 1 or Layer 2 problems.
The show ip ospf rib command output shows that R2 does not have a route to subnet 10.0.110.0/24.
R2# show ip ospf rib 10.0.110.0
%OSPF: Route not in OSPF Base Topology (MTID 0) local RIB
That means R1 does not include an entry for interface Loopback0 in its router LSA for area 0 since the interface is in area 0 according to the network diagram.
In fact, the show ip ospf database router self-originate command output states that router R1 does advertise the interface’s IP prefix into OSPF since this LSA describes the G0/2 interface only.
R1# show ip ospf database router self-originate
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 0)
LS age: 755
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 1.1.1.1
Advertising Router: 1.1.1.1
LS Seq Number: 80000002
Checksum: 0x7D7D
Length: 36
Number of Links: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.0.12.2
(Link Data) Router Interface address: 10.0.12.1
Number of MTID metrics: 0
TOS 0 Metrics: 1
The show ip ospf interface brief command states that the Loopback 0 interface is placed in area 0 but it is down, meaning there may be a Layer 1 or Layer 2 issues.
R1# show ip ospf interface brief Interface PID Area IP Address/Mask Cost State Nbrs F/C Lo0 1 0 10.0.110.1/24 1 DOWN 0/0 Gi0/2 1 0 10.0.12.1/24 1 BDR 1/1
The output of the show ip interface command indicates that the interface is administratively down.
R1# show ip interface loopback0
Loopback0 is administratively down, line protocol is down
Internet address is 10.0.110.1/24
Broadcast address is 255.255.255.255
Address determined by setup command
omitted output
Therefore, we can solve this issue by issuing the no shutdown command.
R1(config)# interface loopback 0
R1(config-if)# no shutdown
Now, router R1 can advertise IP prefix 10.0.110.0/24 into OSPF, as seen in this example.
R1# show ip ospf database router self-originate
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 0)
LS age: 3
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 1.1.1.1
Advertising Router: 1.1.1.1
LS Seq Number: 80000004
Checksum: 0x5916
Length: 48
Number of Links: 2
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.0.110.0
(Link Data) Network Mask: 255.255.255.0
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.0.12.2
(Link Data) Router Interface address: 10.0.12.1
Number of MTID metrics: 0
TOS 0 Metrics: 1
Overall, It is not enough to place an interface in a particular OSPF area using the network or ip ospf area command to be advertised in the OSPF routing domain, but the interface should be up and working.
Interface is Not Associated with an OSPF Process
If an IP-enabled interface is not participating in the OSPF process, the network/subnet associated with that interface does not get advertised to OSPF neighbors.
For example, the output of the show ip ospf interface command indicates that OSPF is not enabled on interface loopback 1.
R1# show ip ospf interface loopback 1
%OSPF: OSPF not enabled on Loopback1
Therefore, the interface would not get advertised into OSPF, and thus router R2 would not have a route to subnet 10.0.111.0/24.
The reason for this problem is the absence of a network statement that matches the interface’s IP address, along with the absence of the ip ospf area command that associates that interface with a particular OSPF area, as shown in the following show running-config command outputs.
R1# show running-config | begin router ospf router ospf 1 router-id 1.1.1.1 network 10.0.1.1 0.0.0.0 area 10 network 10.0.12.1 0.0.0.0 area 0 network 10.0.110.1 0.0.0.0 area 0
R1# show running-config interface loopback 1 Building configuration... Current configuration : 96 bytes ! interface Loopback1 ip address 10.0.111.1 255.255.255.0 ip ospf network point-to-point
To fix this problem, we place interface loopback 1 in area 0 under OSPF process 1 using the ip ospf area command.
R1(config)# interface loopback 1 R1(config-if)# ip ospf 1 area 0
The output of the show ip ospf database router self-originate command states that router R1 advertises the loopback 0 interface in area 0.
R1# show ip ospf database router self-originate
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 0)
LS age: 8
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 1.1.1.1
Advertising Router: 1.1.1.1
LS Seq Number: 80000005
Checksum: 0x22C1
Length: 60
Number of Links: 3
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.0.110.0
(Link Data) Network Mask: 255.255.255.0
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.0.111.0
(Link Data) Network Mask: 255.255.255.0
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.0.12.2
(Link Data) Router Interface address: 10.0.12.1
Number of MTID metrics: 0
TOS 0 Metrics: 1
Additionally, router R2 has a route to that interface’s subnet.
R2# show ip route 10.0.111.0
Routing entry for 10.0.111.0/24
Known via "ospf 1", distance 110, metric 2, type intra area
Last update from 10.0.12.1 on GigabitEthernet0/1, 00:03:34 ago
Routing Descriptor Blocks:
* 10.0.12.1, from 1.1.1.1, 00:03:34 ago, via GigabitEthernet0/1
Route metric is 2, traffic share count is 1
The Secondary IP Address of a Neighboring Interface is in a Different Area Than The Primary IP Address
A router interface can have multiple IP addresses. Each IP address should be in a different subnet. One IP address would be the primary address of the interface while the other ones would be secondary addresses.
When you enable OSPF on a particular interface with multiple IP addresses using the ip ospf area command in interface configuration mode, OSPF advertises all subnets attached to that interface and associates them with the area specified in that Cisco IOS command.
You can also put each subnet in a different OSPF area using the network command in router configuration mode. However, OSPF advertises only the subnet of the primary IP address and ignores those associated with the interface’s secondary IP addresses.
For example, the show ip interface command states that R1’s G0/2 interface has a secondary IP address, which is 10.0.1.1/24.
R1# show ip interface gigabitEthernet 0/2
GigabitEthernet0/2 is up, line protocol is up
Internet address is 10.0.12.1/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Secondary address 10.0.1.1/24
omitted output
Moreover, the show running-config command output indicates that IP address is associated with area 10.
R1# show running-config | begin router ospf
router ospf 1
router-id 1.1.1.1
network 10.0.1.1 0.0.0.0 area 10
network 10.0.12.1 0.0.0.0 area 0
network 10.0.110.1 0.0.0.0 area 0
Therefore, secondary subnet 10.0.1.0/24 of R1’s G0/2 interface cannot be advertised into OSPF, and thus R2 would not have a route to it, as illustrated in this example.
R2# show ip ospf rib 10.0.1.0
%OSPF: Route not in OSPF Base Topology (MTID 0) local RIB
To fix this issue, the primary and secondary IP addresses of interface G0/2 must be associated with same OSPF area. In this example, we place the G0/2 interface in area 0 using the ip ospf area command.
R1(config)# interface gigabitEthernet 0/2 R1(config-if)# ip ospf 1 area 0
This example indicates that router R1 includes an entry for the G0/2 interface’s secondary subnet in its area 0 router LSA.
R1# show ip ospf database router self-originate
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 0)
omitted output
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.0.1.0
(Link Data) Network Mask: 255.255.255.0
Number of MTID metrics: 0
TOS 0 Metrics: 1
To sum up, an OSPF neighbor does not advertise a local interface’s subnet/network when the interface is not working, OSPF is not enabled on the interface, or the subnet intended to be advertised is attached to an OSPF area that is different from the one of the interface’s primary IP address.
Troubleshooting OSPF Summary Route (Type 3 Route) Advertisement
An area border router (ABR) is an OSPF node that is connected to area 0 and any other OSPF area. A router that sits at the border of any two OSPF areas, but isn’t in the backbone area, is not considered an ABR.
When an ABR shares routing information between areas using Type 3 LSAs, called summary LSAs. For example, an ABR router is connected to areas A and B. Area B is neither an OSPF totally stubby area nor an OSPF totally NSSA area.
Instead of flooding area A’s router and network LSAs into area B so that its routers have a complete network map of area A, the router generates a summary LSA for each link in area A and injects it into area B.
OSPF nodes in area B see those links as attached to the ABR router, and they don’t know any detailed network information about area A’s network graph; thus they get the necessary data to route traffic destined to networks/subnets in area A and at the same time they won’t waste CPU cycles to calculate the SP tree due to additional routing data of area A.
Likewise, if area A is neither an OSPF totally stubby area nor an OSPF totally NSSA area, the ABR uses the same logic to share area B’s links with OSPF neighbors in area A when it advertises area B’s links to OSPF adjacent routers in area A.
In fact, OSPF totally stubby and totally NSSA areas do not allow summary LSAs (LSAs Type-3).
When a supposed ABR router does not advertise a link through summary LSAs (Type 3 LSAs), that would be because of the following reasons:
- The ABR router does not have an interface in area 0 or an active virtual link is missing or not configured properly.
- The backbone area is discontiguous.
- The area intended to receive the summary routes (inter-routes) is a totally stubby area or a totally NSSA area.
In this section, I will be using the following network diagram. The OSPF routing domain consists of six routers and is divided into five OSPF areas. The router IDs of R1, R2, R3, R4, R5, and R6 are 1.1.1.1, 2.2.2.2, 3.3.3.3, 4.4.4.4, 5.5.5.5, and 6.6.6.6.
Moreover, The OSPF network type of the Loopback interfaces is set to point-to-point so that their subnets get advertised with their real subnet masks.
Here are the initial router configurations.
| Router R1 | Router R2 | Router R3 |
| Router R4 | Router R5 | Router R6 |
The ABR Router Does Not Have an Interface in Area 0 or a Virtual Link is Missing or not Configured Properly
For an OSPF-enabled router to generate summary LSAs in order to advertise one area’s links to another, the router should have at least one interface in area 0. The interface could be physical or virtual.
Based on the following output of the show ip ospf interface brief command, router R2 is connected to area 0 via interface VL0, which is associated with an OSPF virtual link.
R2# show ip ospf interface brief Interface PID Area IP Address/Mask Cost State Nbrs F/C VL0 1 0 0.0.0.0/0 65535 DOWN 0/0 Lo0 1 12 10.0.120.2/24 1 P2P 0/0 Gi0/1 1 12 10.0.12.2/24 1 DR 1/1 Gi0/3 1 23 10.0.23.2/24 1 BDR 1/1 Gi0/6 1 26 10.0.26.2/24 1 DR 1/1
However, the virtual link is down according to the outputs of the show ip ospf virtual-links command. In fact, the OSPF virtual link is configured with the IP addresses of R2 and R6’s neighboring interfaces instead of their OSPF router IDs.
Router R2
R2# show ip ospf virtual-links Virtual Link OSPF_VL0 to router 10.0.26.6 is down Run as demand circuit DoNotAge LSA allowed. Transit area 26 Topology-MTID Cost Disabled Shutdown Topology Name 0 65535 no no Base Transmit Delay is 1 sec, State DOWN, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Router R6
R6# show ip ospf virtual-links Virtual Link OSPF_VL0 to router 10.0.26.2 is down Run as demand circuit DoNotAge LSA allowed. Transit area 26 Topology-MTID Cost Disabled Shutdown Topology Name 0 65535 no no Base Transmit Delay is 1 sec, State DOWN, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Therefore, router R2 is not actually connected to the backbone area and it would not act as an ABR and originate Type 3 LSAs, as illustrated in this example.
R2# show ip ospf database summary self-originate
OSPF Router with ID (2.2.2.2) (Process ID 1)
R2#
In fact, subnet 10.0.12.0/24, which is in area 12, would not get shared with R2’s OSPF neighbors in areas 23 and 26 since R2 cannot generate a summary LSA for it. and thus no router in the routing domain would have a route to that subnet.
To solve this problem, we have to attach router R2 to area 0. We can accomplish this by fixing the current virtual link between R2 and R6, configuring a new OSPF virtual link between routers R2 and R3 through area 23, or setting up a GRE tunnel between R2 and another router in area 0.
In these examples, we configure a virtual link between routers R2 and R3.
Router R2
R2(config)# router ospf 1 R2(config-router)# area 23 virtual-link 3.3.3.3
Router R3
R3(config)# router ospf 1 R3(config-router)# area 23 virtual-link 2.2.2.2
The show ip ospf virtual-links command output state that the OSPF virtual link is up and running.
R2# show ip ospf virtual-links Virtual Link OSPF_VL0 to router 3.3.3.3 is up Run as demand circuit DoNotAge LSA allowed. Transit area 23, via interface GigabitEthernet0/3 Topology-MTID Cost Disabled Shutdown Topology Name 0 1 no no Base 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 Adjacency State FULL (Hello suppressed) Index 1/1/4, retransmission queue length 0, number of retransmission 0 First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec
Now, router R2 can originate summary LSAs for eligible IP prefixes, as shown in this example.
R2# show ip ospf database adv-router 2.2.2.2
OSPF Router with ID (2.2.2.2) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
2.2.2.2 2.2.2.2 1869 0x80000009 0x008167 1
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.0.12.0 2.2.2.2 1869 0x80000008 0x0042D4
10.0.23.0 2.2.2.2 1869 0x80000008 0x00C843
10.0.26.0 2.2.2.2 1869 0x80000008 0x00A761
10.0.110.0 2.2.2.2 1869 0x80000008 0x0012A1
10.0.120.0 2.2.2.2 1869 0x80000008 0x009911
10.0.130.0 2.2.2.2 1869 0x80000008 0x00356A
10.0.160.0 2.2.2.2 1869 0x80000008 0x00E997
omitted output
Summary Net Link States (Area 12)
Link ID ADV Router Age Seq# Checksum
0.0.0.0 2.2.2.2 1870 0x80000008 0x0067C7
10.0.23.0 2.2.2.2 1870 0x80000008 0x00E627
10.0.26.0 2.2.2.2 1870 0x80000008 0x00C545
10.0.34.0 2.2.2.2 1870 0x80000008 0x00778A
10.0.45.0 2.2.2.2 1870 0x80000008 0x0008ED
10.0.130.0 2.2.2.2 1870 0x80000008 0x00534E
10.0.140.0 2.2.2.2 1870 0x80000008 0x00EEA7
10.0.150.0 2.2.2.2 1870 0x80000008 0x008A01
10.0.160.0 2.2.2.2 1870 0x80000008 0x00087B
omitted output
Summary Net Link States (Area 26)
Link ID ADV Router Age Seq# Checksum
10.0.12.0 2.2.2.2 1871 0x80000008 0x0042D4
10.0.23.0 2.2.2.2 1871 0x80000008 0x00C843
10.0.34.0 2.2.2.2 1871 0x80000008 0x0059A6
10.0.45.0 2.2.2.2 1871 0x80000008 0x00E90A
10.0.110.0 2.2.2.2 1871 0x80000008 0x0012A1
10.0.120.0 2.2.2.2 1871 0x80000008 0x009911
10.0.130.0 2.2.2.2 1871 0x80000008 0x00356A
10.0.140.0 2.2.2.2 1871 0x80000008 0x00D0C3
10.0.150.0 2.2.2.2 1871 0x80000008 0x006C1D
The Backbone Area is Discontiguous
Basically, an ABR doesn’t create a summary LSA for an inter-area link and advertised it into area 0. In fact, RFC 2328 prohibits generating and flooding summary LSAs (Type 3 LSAs) into the backbone area in order to advertise inter-area routes.
For example, router R5 originates a summary LSA for subnet 10.0.56.0/24, which is in area 0, and floods it to router R4, as illustrated in the output of the show ip ospf database command.
R4# show ip ospf database summary 10.0.56.0
OSPF Router with ID (4.4.4.4) (Process ID 1)
Summary Net Link States (Area 45)
LS age: 1010
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 10.0.56.0 (summary Network Number)
Advertising Router: 5.5.5.5
LS Seq Number: 80000001
Checksum: 0x10D5
Length: 28
Network Mask: /24
MTID: 0 Metric: 1
However, router R4 does not install the corresponding route in its OSPF RIB table, nor does it flood the Type 3 LSA to router R3, as shown in these examples.
Router R3
R3# show ip ospf database summary 10.0.56.0
OSPF Router with ID (3.3.3.3) (Process ID 1)
R3#
Router R4
R4# show ip ospf rib 10.0.56.0
%OSPF: Route not in OSPF Base Topology (MTID 0) local RIB
Overall, the links in one backbone area may not get advertised to all routers in the other backbone area.
To fix this issue, we have to make area 0 contiguous. In this case, creating an OSPF virtual link between routers R4 and R5 is enough.
Router R4
R4(config)# router ospf 1 R4(config-router)# area 45 virtual-link 5.5.5.5
Router R5
R5(config)# router ospf 1 R5(config-router)# area 45 virtual-link 4.4.4.4
The outputs of the show ip ospf rib and show ip ospf database summary commands indicate that R4 adds an entry for IP prefix 10.0.56.0/24 in its OSPF RIB table. The route appears as an intra-area route.
Router R4
R4# show ip ospf rib 10.0.56.0
OSPF Router with ID (4.4.4.4) (Process ID 1)
Base Topology (MTID 0)
OSPF local RIB
Codes: * - Best, > - Installed in global RIB
LSA: type/LSID/originator
*> 10.0.56.0/24, Intra, cost 2, area 0
SPF Instance 10, age 00:00:39
Flags: RIB
via 10.0.45.5, GigabitEthernet0/5
Flags: RIB
LSA: 2/10.0.56.6/6.6.6.6
The Area Intended to Receive The Summary Route (Inter-Area Route) is a Totally Stubby Area or a Totally NSSA Area
OSPF stub and NSSA areas allow LSAs Type 3, while OSPF totally stub and totally NSSA areas don’t. For example, R2 sees area 12 as a totally stub area, as indicated in the outputs of the show running-config and show ip ospf commands.
R2# show running-config | begin router ospf
router ospf 1
router-id 2.2.2.2
area 12 stub no-summary
area 23 virtual-link 3.3.3.3
network 10.0.12.2 0.0.0.0 area 12
network 10.0.23.2 0.0.0.0 area 23
network 10.0.26.2 0.0.0.0 area 26
network 10.0.120.2 0.0.0.0 area 12
R2# show ip ospf | begin Area 12
Area 12
Number of interfaces in this area is 2 (1 loopback)
It is a stub area, no summary LSA in this area
Generates stub default route with cost 1
Area has no authentication
SPF algorithm last executed 00:02:03.187 ago
SPF algorithm executed 8 times
Area ranges are
Number of LSA 4. Checksum Sum 0x0219D0
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
omitted output
Moreover, router R2 does originate any summary LSA in area 12, except the one advertising the default route, as stated in the output of the show ip ospf database command.
R2# show ip ospf database adv-router 2.2.2.2
OSPF Router with ID (2.2.2.2) (Process ID 1)
omitted output
Summary Net Link States (Area 12)
Link ID ADV Router Age Seq# Checksum
0.0.0.0 2.2.2.2 495 0x8000000B 0x0061CA
omitted output
Consequently, router R1 does not have routes to destinations outside area 12, as illustrated in the show ip ospf rib command output.
R1# show ip ospf rib
OSPF Router with ID (1.1.1.1) (Process ID 1)
Base Topology (MTID 0)
OSPF local RIB
Codes: * - Best, > - Installed in global RIB
* 10.0.12.0/24, Intra, cost 1, area 12, Connected
via 10.0.12.1, GigabitEthernet0/2
* 10.0.110.0/24, Intra, cost 1, area 12, Connected
via 10.0.110.1, Loopback0
*> 10.0.120.0/24, Intra, cost 2, area 12
via 10.0.12.2, GigabitEthernet0/2
*> 0.0.0.0/0, Inter, cost 2, area 12
via 10.0.12.2, GigabitEthernet0/2
In fact, R1’s OSPF RIB table consists of intra-area routes and the default route only.
To fix this issue, we can convert area 12 to a normal area, stub area, or NSSA area. We choose to configure area 12 as a stub area on router R2, ABR of area 12, as you can see in this example.
Router R2
R2(config)# router ospf 1 R2(config-router)# no area 12 stub no-summary
The show ip ospf command output states that area 12 becomes an OSPF stub area.
R2# show ip ospf | begin Area 12
Area 12
Number of interfaces in this area is 2 (1 loopback)
It is a stub area
Generates stub default route with cost 1
Area has no authentication
SPF algorithm last executed 00:02:26.730 ago
SPF algorithm executed 9 times
Area ranges are
Number of LSA 12. Checksum Sum 0x0686ED
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
omitted output
The output of the show ip ospf database command indicates that router R2 advertises summary LSAs in R1, which now has routes to other OSPF areas’ links, as illustrated in the show ip ospf rib command output below.
R1# show ip ospf database
OSPF Router with ID (1.1.1.1) (Process ID 1)
omitted output
Summary Net Link States (Area 12)
Link ID ADV Router Age Seq# Checksum
0.0.0.0 2.2.2.2 1555 0x8000000B 0x0061CA
10.0.23.0 2.2.2.2 366 0x80000001 0x00F420
10.0.26.0 2.2.2.2 366 0x80000001 0x00D33E
10.0.34.0 2.2.2.2 366 0x80000001 0x008583
10.0.45.0 2.2.2.2 366 0x80000001 0x0016E6
10.0.130.0 2.2.2.2 366 0x80000001 0x006147
10.0.140.0 2.2.2.2 366 0x80000001 0x00FCA0
10.0.150.0 2.2.2.2 366 0x80000001 0x0098F9
10.0.160.0 2.2.2.2 366 0x80000001 0x001674
R1# show ip ospf rib
OSPF Router with ID (1.1.1.1) (Process ID 1)
Base Topology (MTID 0)
OSPF local RIB
Codes: * - Best, > - Installed in global RIB
* 10.0.12.0/24, Intra, cost 1, area 12, Connected
via 10.0.12.1, GigabitEthernet0/2
*> 10.0.23.0/24, Inter, cost 2, area 12
via 10.0.12.2, GigabitEthernet0/2
*> 10.0.26.0/24, Inter, cost 2, area 12
via 10.0.12.2, GigabitEthernet0/2
*> 10.0.34.0/24, Inter, cost 3, area 12
via 10.0.12.2, GigabitEthernet0/2
*> 10.0.45.0/24, Inter, cost 4, area 12
via 10.0.12.2, GigabitEthernet0/2
*> 10.0.56.0/24, Inter, cost 5, area 12
via 10.0.12.2, GigabitEthernet0/2
* 10.0.110.1/32, Intra, cost 1, area 12, Connected
via 10.0.110.1, Loopback0
*> 10.0.120.0/24, Intra, cost 2, area 12
via 10.0.12.2, GigabitEthernet0/2
*> 10.0.130.0/24, Inter, cost 3, area 12
via 10.0.12.2, GigabitEthernet0/2
*> 10.0.140.0/24, Inter, cost 4, area 12
via 10.0.12.2, GigabitEthernet0/2
*> 10.0.150.0/24, Inter, cost 5, area 12
via 10.0.12.2, GigabitEthernet0/2
*> 10.0.160.0/24, Inter, cost 3, area 12
via 10.0.12.2, GigabitEthernet0/2
*> 0.0.0.0/0, Inter, cost 2, area 12
via 10.0.12.2, GigabitEthernet0/2
Troubleshooting OSPF External Route Advertisement
Here are the most common reasons why external routes redistributed by an ASBR are not advertised within the whole or a part of the OSPF routing domain, regardless of the types of OSPF areas (backbone, normal, stub, totally stub, NSSA, totally NSSA) the ASBR is attached to.
- The subnets keyword is not used along with the redistribute command
- The area intended to receive Type 5 LSAs advertising external routes is configured as a stubby area (stub area, totally stubby area, NSSA area, or totally NSSA area).
- OSPF stub and totally stubby areas are blocking external routes, including redistributed routes into those areas.
In this section, I will be using the following network diagram. The routing domain consists of four OSPF areas: 0, 12, 34 (stub area), and 356 (NSSA), and all loopback interfaces are redistributed into OSPF.
Here are the links below to download the initial router configurations.
| Router R1 | Router R2 | Router R3 |
| Router R4 | Router R5 | Router R6 |
The goal of this section is to troubleshoot the network according to the following rules:
- All R1’s loopback interfaces should be redistributed into OSPF.
- Routers in OSPF areas 29 and 38 should be able to receive LSAs advertising external routes.
- Routers in the OSPF routing domain should be able to reach R4’s loopback interfaces, which are redistributed into OSPF.
The Subnets Keyword is Not Used Along With The Redistribute Command
The redistribute command allows injecting routes from an external source into the current OSPF instance. For example, you can import routes associated with connected networks not advertised into OSPF, static routes, EIGRP routes, RIP routes, etc.
The show running-config states that only R1’s classful connected networks are being redistributed into OSPF since the redistribute connected command does not include the subnets keyword.
R1# show running-config | begin router ospf
router ospf 1
router-id 1.1.1.1
log-adjacency-changes
redistribute connected
network 10.0.12.1 0.0.0.0 area 12
If you don’t use the subnets keyword along with the redistribute command, classless IP prefixes don’t get redistributed into OSPF, and only classful IP prefixes do.
Therefore, IP prefixes 11.0.0.0/8, 140.0.0.0/16, and 198.0.113.0/24 are being successfully redistributed by router R1 in OSPF because they are classful but subnets 10.0.110.0/24, 10.0.111.0/24, and 10.0.112.0/24 aren’t because they are classless.
In addition, R1 generates Type 5 LSAs for the classful IP prefixes only, as illustrated in the following show ip ospf database external self-originate command outputs.
R1# show ip ospf database external self-originate
OSPF Router with ID (1.1.1.1) (Process ID 1)
Type-5 AS External Link States
LS age: 1946
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 11.0.0.0 (External Network Number )
Advertising Router: 1.1.1.1
LS Seq Number: 80000001
Checksum: 0x3A57
Length: 36
Network Mask: /8
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
LS age: 1946
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 140.0.0.0 (External Network Number )
Advertising Router: 1.1.1.1
LS Seq Number: 80000001
Checksum: 0xA669
Length: 36
Network Mask: /16
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
LS age: 1948
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 198.0.113.0 (External Network Number )
Advertising Router: 1.1.1.1
LS Seq Number: 80000001
Checksum: 0xD192
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
As a result, only classful networks connected to R1 are getting advertised to OSPF neighbors, as indicated in the show ip ospf rib command output below.
R2# show ip ospf rib
OSPF Router with ID (2.2.2.2) (Process ID 1)
Base Topology (MTID 0)
OSPF local RIB
Codes: * - Best, > - Installed in global RIB
* 10.0.12.0/24, Intra, cost 1, area 12, Connected
via 10.0.12.2, GigabitEthernet0/1
* 10.0.23.0/24, Intra, cost 1, area 0, Connected
via 10.0.23.2, GigabitEthernet0/3
* 10.0.26.0/24, Intra, cost 1, area 26, Connected
via 10.0.26.2, GigabitEthernet0/6
*> 10.0.34.0/24, Inter, cost 2, area 0
via 10.0.23.3, GigabitEthernet0/3
*> 10.0.35.0/24, Inter, cost 2, area 0
via 10.0.23.3, GigabitEthernet0/3
*> 11.0.0.0/8, Ext2, cost 20, fwd cost 1, tag 0
via 10.0.12.1, GigabitEthernet0/1
*> 140.0.0.0/16, Ext2, cost 20, fwd cost 1, tag 0
via 10.0.12.1, GigabitEthernet0/1
*> 198.0.113.0/24, Ext2, cost 20, fwd cost 1, tag 0
via 10.0.12.1, GigabitEthernet0/1
To fix this issue, we issue the redistribute connected subnets command in router configuration mode.
R1(config)# router ospf 1
R1(config-router)# redistribute connected subnets
Now, all R1’s Loopback interfaces’ subnets are imported to OSPF since R1 originates a Type 5 LSA for each of them, as stated in this example.
R1# show ip ospf database adv-router 1.1.1.1
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 12)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 586 0x80000003 0x008176 1
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
10.0.110.0 1.1.1.1 38 0x80000001 0x00889B 0
10.0.111.0 1.1.1.1 38 0x80000001 0x007DA5 0
10.0.112.0 1.1.1.1 38 0x80000001 0x0072AF 0
11.0.0.0 1.1.1.1 586 0x80000002 0x003858 0
140.0.0.0 1.1.1.1 586 0x80000002 0x00A46A 0
198.0.113.0 1.1.1.1 586 0x80000002 0x00CF93 0
Finally, the routes in question get advertised to router R2, R1’s only neighbor, as illustrated in the following output of the show ip ospf rib command.
R2# show ip ospf rib
OSPF Router with ID (2.2.2.2) (Process ID 1)
Base Topology (MTID 0)
OSPF local RIB
Codes: * - Best, > - Installed in global RIB
* 10.0.12.0/24, Intra, cost 1, area 12, Connected
via 10.0.12.2, GigabitEthernet0/1
* 10.0.23.0/24, Intra, cost 1, area 0, Connected
via 10.0.23.2, GigabitEthernet0/3
* 10.0.26.0/24, Intra, cost 1, area 26, Connected
via 10.0.26.2, GigabitEthernet0/6
*> 10.0.34.0/24, Inter, cost 2, area 0
via 10.0.23.3, GigabitEthernet0/3
*> 10.0.35.0/24, Inter, cost 2, area 0
via 10.0.23.3, GigabitEthernet0/3
*> 10.0.110.0/24, Ext2, cost 20, fwd cost 1, tag 0
via 10.0.12.1, GigabitEthernet0/1
*> 10.0.111.0/24, Ext2, cost 20, fwd cost 1, tag 0
via 10.0.12.1, GigabitEthernet0/1
*> 10.0.112.0/24, Ext2, cost 20, fwd cost 1, tag 0
via 10.0.12.1, GigabitEthernet0/1
*> 11.0.0.0/8, Ext2, cost 20, fwd cost 1, tag 0
via 10.0.12.1, GigabitEthernet0/1
*> 140.0.0.0/16, Ext2, cost 20, fwd cost 1, tag 0
via 10.0.12.1, GigabitEthernet0/1
*> 198.0.113.0/24, Ext2, cost 20, fwd cost 1, tag 0
via 10.0.12.1, GigabitEthernet0/1
The OSPF Area Intended to Receive Type 5 LSAs Advertising External Routes is Configured as a Stubby Area
All OSPF stub areas (stub, totally stubby, NSSA, and totally NSSA) prohibit Type 5 LSAs. Therefore, redistributed routes that are advertised via Type 5 LSA don’t get injected into stubby areas.
According to the rules above, external routes should appear on the routing tables of routers R5 and R6. However, those routers do not receive any Type 5 LSAs even though their neighbors do, as illustrated in the outputs of the show ip ospf database command.
Router R2
R2# show ip ospf database | begin Type-5
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
10.0.110.0 1.1.1.1 1229 0x80000001 0x00889B 0
10.0.111.0 1.1.1.1 1229 0x80000001 0x007DA5 0
10.0.112.0 1.1.1.1 1229 0x80000001 0x0072AF 0
10.0.120.0 2.2.2.2 1712 0x80000002 0x00F91B 0
11.0.0.0 1.1.1.1 1775 0x80000002 0x003858 0
140.0.0.0 1.1.1.1 1775 0x80000002 0x00A46A 0
198.0.113.0 1.1.1.1 1775 0x80000002 0x00CF93 0
Router R3
R3# show ip ospf database | begin Type-5
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
10.0.110.0 1.1.1.1 1287 0x80000001 0x00889B 0
10.0.111.0 1.1.1.1 1287 0x80000001 0x007DA5 0
10.0.112.0 1.1.1.1 1287 0x80000001 0x0072AF 0
10.0.120.0 2.2.2.2 1769 0x80000002 0x00F91B 0
11.0.0.0 1.1.1.1 1832 0x80000002 0x003858 0
140.0.0.0 1.1.1.1 1832 0x80000002 0x00A46A 0
198.0.113.0 1.1.1.1 1832 0x80000002 0x00CF93 0
Router R5
R5# show ip ospf database external
OSPF Router with ID (5.5.5.5) (Process ID 1)
R5#
Router R6
R6# show ip ospf database external
OSPF Router with ID (6.6.6.6) (Process ID 1)
R6#
Additionally, no external route exists in R5 and R6’s OSPF RIB tables. Only intra-area and inter-area routes are present.
Router R5
R5# show ip ospf rib
OSPF Router with ID (5.5.5.5) (Process ID 1)
Base Topology (MTID 0)
OSPF local RIB
Codes: * - Best, > - Installed in global RIB
*> 10.0.12.0/24, Inter, cost 3, area 35
via 10.0.35.3, GigabitEthernet0/3
*> 10.0.23.0/24, Inter, cost 2, area 35
via 10.0.35.3, GigabitEthernet0/3
*> 10.0.26.0/24, Inter, cost 3, area 35
via 10.0.35.3, GigabitEthernet0/3
*> 10.0.34.0/24, Inter, cost 2, area 35
via 10.0.35.3, GigabitEthernet0/3
* 10.0.35.0/24, Intra, cost 1, area 35, Connected
via 10.0.35.5, GigabitEthernet0/3
Router R6
R6# show ip ospf rib
OSPF Router with ID (6.6.6.6) (Process ID 1)
Base Topology (MTID 0)
OSPF local RIB
Codes: * - Best, > - Installed in global RIB
*> 10.0.12.0/24, Inter, cost 2, area 26
via 10.0.26.2, GigabitEthernet0/2
*> 10.0.23.0/24, Inter, cost 2, area 26
via 10.0.26.2, GigabitEthernet0/2
* 10.0.26.0/24, Intra, cost 1, area 26, Connected
via 10.0.26.6, GigabitEthernet0/2
*> 10.0.34.0/24, Inter, cost 3, area 26
via 10.0.26.2, GigabitEthernet0/2
*> 10.0.35.0/24, Inter, cost 3, area 26
via 10.0.26.2, GigabitEthernet0/2
*> 0.0.0.0/0, Inter, cost 2, area 26
via 10.0.26.2, GigabitEthernet0/2
Based on the network diagram and the show running-config command outputs below, OSPF area 26 is a stub area and area 35 is an NSSA area. Therefore, areas 26 and 35 do not allow external routes.
Router R5
R5# show running-config | begin router ospf
router ospf 1
router-id 5.5.5.5
area 35 nssa
network 10.0.35.5 0.0.0.0 area 35
Router R6
R6# show running-config | begin router ospf
router ospf 1
router-id 6.6.6.6
area 26 stub
network 10.0.26.6 0.0.0.0 area 26
Type 5 LSAs do not get advertised by ABR routers R2 and R3 into those stubby areas, thus routers R5 and R6 would not receive them and be able to reach external OSPF routes.
To fix this problem, we need to convert OSPF areas 26 and 35 to normal areas by removing the area 26 stub statement from the OSPF configurations of R2 and R6, and removing the area 35 nssa statement from the OSPF configurations of routers R3 and R5.
Router R2
R2(config)# router ospf 1 R2(config-router)# no area 26 stub
Router R3
R3(config)# router ospf 1 R3(config-router)# no area 35 nssa
Router R5
R5(config)# router ospf 1 R5(config-router)# no area 35 nssa
Router R6
R6(config)# router ospf 1 R6(config-router)# no area 26 stub
Finally, the show ip route ospf command outputs state that the issue has been fixed, and R5 and R6 receive Type 5 LSAs.
Router R5
R5# show ip route ospf | include E2|E1
E1 - OSPF external type 1, E2 - OSPF external type 2
O E2 10.0.110.0/24 [110/20] via 10.0.35.3, 00:04:50, GigabitEthernet0/3
O E2 10.0.111.0/24 [110/20] via 10.0.35.3, 00:04:50, GigabitEthernet0/3
O E2 10.0.112.0/24 [110/20] via 10.0.35.3, 00:04:50, GigabitEthernet0/3
O E2 10.0.120.0/24 [110/20] via 10.0.35.3, 00:04:50, GigabitEthernet0/3
O E2 11.0.0.0/8 [110/20] via 10.0.35.3, 00:04:50, GigabitEthernet0/3
O E2 140.0.0.0/16 [110/20] via 10.0.35.3, 00:04:50, GigabitEthernet0/3
O E2 198.0.113.0/24 [110/20] via 10.0.35.3, 00:04:50, GigabitEthernet0/398.0.113.0/24 [110/20] via 10.0.35.3, 00:03:18, GigabitEthernet0/3
Router R6
R6# show ip route ospf | include E2|E1
E1 - OSPF external type 1, E2 - OSPF external type 2
O E2 10.0.110.0/24 [110/20] via 10.0.26.2, 00:06:27, GigabitEthernet0/2
O E2 10.0.111.0/24 [110/20] via 10.0.26.2, 00:06:27, GigabitEthernet0/2
O E2 10.0.112.0/24 [110/20] via 10.0.26.2, 00:06:27, GigabitEthernet0/2
O E2 10.0.120.0/24 [110/20] via 10.0.26.2, 00:06:27, GigabitEthernet0/2
O E2 11.0.0.0/8 [110/20] via 10.0.26.2, 00:06:27, GigabitEthernet0/2
O E2 140.0.0.0/16 [110/20] via 10.0.26.2, 00:06:27, GigabitEthernet0/2
O E2 198.0.113.0/24 [110/20] via 10.0.26.2, 00:06:27, GigabitEthernet0/2
OSPF Stub and Totally Stubby Areas Are Blocking External Routes
Routers connected to OSPF stub and totally stubby areas, cannot redistribute external routes into those areas, but they can still advertise external routes into normal areas they are associated with, including the backbone.
The output of the show running-config command states that R4 is configured to redistribute its Loopback interfaces’ IP prefixes into OSPF, and area 34, the only area R4 is connected to, is a stub area.
R4# show running-config | begin router ospf router ospf 1 router-id 4.4.4.4 area 34 stub redistribute connected subnets network 10.0.34.4 0.0.0.0 area 34
However, the router does not originate a Type 5 LSA for each of those Loopback interfaces because it is only attached to one OSPF area, area 34, which is a stub area, as indicated in the following output of the show ip ospf database external self-originate command.
Consequently, it cannot redistribute external routes into the current area, i.e., the OSPF domain.
R4# show ip ospf database external self-originate
OSPF Router with ID (4.4.4.4) (Process ID 1)
R4#
To fix this issue, we can configure area 34 as a normal area, NSSA area, or totally NSSA area. The first option would increase the size of area 34 routers’ LSDBs. However, the second and third options would not.
In these examples, we configure area 34 as an NSSA area.
Router R3
R3(config)# router ospf 1 R3(config-router)# no area 34 stub R3(config-router)# area 34 nssa
Router R4
R4(config)# router ospf 1 R4(config-router)# no area 34 stub R4(config-router)# area 34 nssa
The show ip ospf database nssa-external self-originate command output indicates that R4 produces Type 7 LSAs for IP prefixes 10.0.140.0/24, 10.0.141.0/24, and 10.0.142.0/24.
R4# show ip ospf database nssa-external self-originate
OSPF Router with ID (4.4.4.4) (Process ID 1)
Type-7 AS External Link States (Area 34)
LS age: 23
Options: (No TOS-capability, Type 7/5 translation, DC, Upward)
LS Type: AS External Link
Link State ID: 10.0.140.0 (External Network Number )
Advertising Router: 4.4.4.4
LS Seq Number: 80000002
Checksum: 0xAE10
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 10.0.34.4
External Route Tag: 0
LS age: 23
Options: (No TOS-capability, Type 7/5 translation, DC, Upward)
LS Type: AS External Link
Link State ID: 10.0.141.0 (External Network Number )
Advertising Router: 4.4.4.4
LS Seq Number: 80000002
Checksum: 0xA31A
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 10.0.34.4
External Route Tag: 0
LS age: 23
Options: (No TOS-capability, Type 7/5 translation, DC, Upward)
LS Type: AS External Link
Link State ID: 10.0.142.0 (External Network Number )
Advertising Router: 4.4.4.4
LS Seq Number: 80000002
Checksum: 0x9824
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 10.0.34.4
External Route Tag: 0
The show ip ospf rib command output confirms that R4’s Loopback interfaces have been redistributed successfully into OSPF, and the corresponding Type 7 LSAs are advertised to R3.
R3# show ip ospf rib
OSPF Router with ID (3.3.3.3) (Process ID 1)
Base Topology (MTID 0)
OSPF local RIB
Codes: * - Best, > - Installed in global RIB
*> 10.0.12.0/24, Inter, cost 2, area 0
via 10.0.23.2, GigabitEthernet0/2
* 10.0.23.0/24, Intra, cost 1, area 0, Connected
via 10.0.23.3, GigabitEthernet0/2
*> 10.0.26.0/24, Inter, cost 2, area 0
via 10.0.23.2, GigabitEthernet0/2
* 10.0.34.0/24, Intra, cost 1, area 34, Connected
via 10.0.34.3, GigabitEthernet0/4
* 10.0.35.0/24, Intra, cost 1, area 35, Connected
via 10.0.35.3, GigabitEthernet0/5
*> 10.0.110.0/24, Ext2, cost 20, fwd cost 2, tag 0
via 10.0.23.2, GigabitEthernet0/2
*> 10.0.111.0/24, Ext2, cost 20, fwd cost 2, tag 0
via 10.0.23.2, GigabitEthernet0/2
*> 10.0.112.0/24, Ext2, cost 20, fwd cost 2, tag 0
via 10.0.23.2, GigabitEthernet0/2
*> 10.0.120.0/24, Ext2, cost 20, fwd cost 1, tag 0
via 10.0.23.2, GigabitEthernet0/2
*> 10.0.140.0/24, NSSA2, cost 20, fwd cost 1, tag 0, area 34
via 10.0.34.4, GigabitEthernet0/4
*> 10.0.141.0/24, NSSA2, cost 20, fwd cost 1, tag 0, area 34
via 10.0.34.4, GigabitEthernet0/4
*> 10.0.142.0/24, NSSA2, cost 20, fwd cost 1, tag 0, area 34
via 10.0.34.4, GigabitEthernet0/4
*> 11.0.0.0/8, Ext2, cost 20, fwd cost 2, tag 0
via 10.0.23.2, GigabitEthernet0/2
*> 140.0.0.0/16, Ext2, cost 20, fwd cost 2, tag 0
via 10.0.23.2, GigabitEthernet0/2
*> 198.0.113.0/24, Ext2, cost 20, fwd cost 2, tag 0
via 10.0.23.2, GigabitEthernet0/2
Additionally, R3 translates those Type 7 LSAs to Type 5 LSAs, as illustrated in the show ip ospf database command output. This way, the IP prefixes of R4’s Loopback interfaces get advertised to routers R1, R2, R5, and R6 via the Type 5 LSAs generated by R3.
R3# show ip ospf database adv-router 3.3.3.3 | begin Type-5
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
10.0.140.0 3.3.3.3 609 0x80000003 0x005F6C 0
10.0.141.0 3.3.3.3 609 0x80000003 0x005476 0
10.0.142.0 3.3.3.3 609 0x80000003 0x004980 0
Finally, the outputs of the show ip route ospf command indicate that routers R1, R2, R5, and R6 can reach subnets 10.0.140.0/24, 10.0.141.0/24, and 10.0.142.0/24.
Router R1
R1# show ip route ospf | include E2 O E2 10.0.120.0 [110/20] via 10.0.12.2, 00:23:08, FastEthernet0/0 O E2 10.0.142.0 [110/20] via 10.0.12.2, 00:20:29, FastEthernet0/0 O E2 10.0.140.0 [110/20] via 10.0.12.2, 00:20:29, FastEthernet0/0 O E2 10.0.141.0 [110/20] via 10.0.12.2, 00:20:29, FastEthernet0/0
Router R2
R2# show ip route ospf | include E2
E1 - OSPF external type 1, E2 - OSPF external type 2
O E2 10.0.110.0/24 [110/20] via 10.0.12.1, 01:52:05, GigabitEthernet0/1
O E2 10.0.111.0/24 [110/20] via 10.0.12.1, 01:52:05, GigabitEthernet0/1
O E2 10.0.112.0/24 [110/20] via 10.0.12.1, 01:52:05, GigabitEthernet0/1
O E2 10.0.140.0/24 [110/20] via 10.0.23.3, 00:20:40, GigabitEthernet0/3
O E2 10.0.141.0/24 [110/20] via 10.0.23.3, 00:20:40, GigabitEthernet0/3
O E2 10.0.142.0/24 [110/20] via 10.0.23.3, 00:20:40, GigabitEthernet0/3
O E2 11.0.0.0/8 [110/20] via 10.0.12.1, 01:52:05, GigabitEthernet0/1
O E2 140.0.0.0/16 [110/20] via 10.0.12.1, 01:52:05, GigabitEthernet0/1
O E2 198.0.113.0/24 [110/20] via 10.0.12.1, 01:52:05, GigabitEthernet0/1
Router R5
R5# show ip route ospf | include E2
E1 - OSPF external type 1, E2 - OSPF external type 2
O E2 10.0.110.0/24 [110/20] via 10.0.35.3, 01:51:22, GigabitEthernet0/3
O E2 10.0.111.0/24 [110/20] via 10.0.35.3, 01:51:22, GigabitEthernet0/3
O E2 10.0.112.0/24 [110/20] via 10.0.35.3, 01:51:22, GigabitEthernet0/3
O E2 10.0.120.0/24 [110/20] via 10.0.35.3, 01:51:22, GigabitEthernet0/3
O E2 10.0.140.0/24 [110/20] via 10.0.35.3, 00:20:54, GigabitEthernet0/3
O E2 10.0.141.0/24 [110/20] via 10.0.35.3, 00:20:54, GigabitEthernet0/3
O E2 10.0.142.0/24 [110/20] via 10.0.35.3, 00:20:54, GigabitEthernet0/3
O E2 11.0.0.0/8 [110/20] via 10.0.35.3, 01:51:22, GigabitEthernet0/3
O E2 140.0.0.0/16 [110/20] via 10.0.35.3, 01:51:22, GigabitEthernet0/3
O E2 198.0.113.0/24 [110/20] via 10.0.35.3, 01:51:22, GigabitEthernet0/3
Router R6
R6# show ip route ospf | include E2
E1 - OSPF external type 1, E2 - OSPF external type 2
O E2 10.0.110.0/24 [110/20] via 10.0.26.2, 01:52:06, GigabitEthernet0/2
O E2 10.0.111.0/24 [110/20] via 10.0.26.2, 01:52:06, GigabitEthernet0/2
O E2 10.0.112.0/24 [110/20] via 10.0.26.2, 01:52:06, GigabitEthernet0/2
O E2 10.0.120.0/24 [110/20] via 10.0.26.2, 01:52:06, GigabitEthernet0/2
O E2 10.0.140.0/24 [110/20] via 10.0.26.2, 00:21:00, GigabitEthernet0/2
O E2 10.0.141.0/24 [110/20] via 10.0.26.2, 00:21:00, GigabitEthernet0/2
O E2 10.0.142.0/24 [110/20] via 10.0.26.2, 00:21:00, GigabitEthernet0/2
O E2 11.0.0.0/8 [110/20] via 10.0.26.2, 01:52:06, GigabitEthernet0/2
O E2 140.0.0.0/16 [110/20] via 10.0.26.2, 01:52:06, GigabitEthernet0/2
O E2 198.0.113.0/24 [110/20] via 10.0.26.2, 01:52:06, GigabitEthernet0/2
Troubleshooting OSPF Default Route Advertisement
OSPF allows originating and advertising the default route. The route will be used to reach unknown network destinations. For example, you can configure an ASBR to generate the OSPF default route instead of redistributing external routes into OSPF.
This way, the routers’ LSDBs don’t get overwhelmed with link state information that may be unnecessary.
There are two ways to generate and inject the OSPF default route into an OSPF routing domain. The gateway of last resort, the 0.0.0.0/0 route, can be originated automatically or manually.
The default route is automatically originated and flooded by ABRs in totally stubby/NSSA areas. It is a Type 3 LSA route, and the scope of the route is the stubby area into which it is injected.
In addition, you can configure an OSPF node to manually originate the default route by issuing the default-information originate command in router configuration mode. In this case, the default route is advertised through the OSPF routing domain using a Type 5 LSA.
The default-information originate command requires that the current router’s routing table contain the 0.0.0.0/0 route. However, you can work around this requirement using the always keyword along with the command.
If the route is configured by an OSPF neighbor within an NSSA area or a totally NSSA area, the 0.0.0.0/0 IP prefix is advertised via a Type 5 LSA after being translated from a Type 7 LSA within non-stubby areas, and via a Type 7 LSA within the originating router’s NSSA areas.
The OSPF default route may not be advertised because one of the following reasons:
- The 0.0.0.0/0 route does not exist from the originating router’s routing table.
- Stubby area not allowing the OSPF default route.
- Type 7 OSPF default route configured using the wrong command.
- The default-information originate command is not present in the OSPF node’s OSPF configuration.
In this section, I will be using this network diagram.
Click the links below to download the routers’ configurations.
| Router R1 | Router R2 | Router R3 |
| Router R4 | Router R5 | Router R6 |
The 0.0.0.0/0 Route Does Not Exist From The Originating Router’s Routing Table
Using the default-information originate command to generate the OSPF default route is not enough, a 0.0.0.0/0 IP prefix should exist in the routing table, regardless of its source (static route, BGP route, EIGRP route,…).
For example, the output of the show running-configuration states that router R4 is configured to originate the OSPF gateway of last resort.
R4# show running-config | begin router ospf
router ospf 1
router-id 4.4.4.4
area 345 nssa
network 10.0.34.4 0.0.0.0 area 0
network 10.0.45.4 0.0.0.0 area 345
network 10.0.46.4 0.0.0.0 area 345
default-information originate
However, R4 does not originate a Type 5 LSA for the default route, as illustrated in the show ip ospf database external self-originate command output.
R4# show ip ospf database external self-originate OSPF Router with ID (4.4.4.4) (Process ID 1) R4#
In addition, the show ip route command indicates that R4’s routing table does not include the 0.0.0.0/0 route. Consequently, R4 cannot originate the default route.
R4# show ip route 0.0.0.0
% Network not in table
To solve this problem, we can configure a static default route or issue the default-information originate always command. This example configures router R4 to add a static default route with null0 as the exit interface.
R4(config)# ip route 0.0.0.0 0.0.0.0 null0
Router R4 originates a Type 5 LSA for the 0.0.0.0/0 route, as illustrated in the output of show ip ospf database external self-originate command.
R4# show ip ospf database external self-originate
OSPF Router with ID (4.4.4.4) (Process ID 1)
Type-5 AS External Link States
LS age: 28
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 0.0.0.0 (External Network Number )
Advertising Router: 4.4.4.4
LS Seq Number: 80000001
Checksum: 0xC2DF
Length: 36
Network Mask: /0
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 1
Forward Address: 0.0.0.0
External Route Tag: 1
Besides, the show ip route command outputs below state that the default route is advertised to routers R2 and R3. Of course, the default route would not get flooded into areas 12 and 345 since they are stubby areas and the route’s OSPF type is external (E2 type).
Router R2
R2# show ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via "ospf 1", distance 110, metric 1, candidate default path Tag 1, type extern 2, forward metric 2 Last update from 10.0.23.3 on GigabitEthernet0/3, 00:01:53 ago Routing Descriptor Blocks: * 10.0.23.3, from 4.4.4.4, 00:01:53 ago, via GigabitEthernet0/3 Route metric is 1, traffic share count is 1 Route tag 1
Router R3
R3# show ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via "ospf 1", distance 110, metric 1, candidate default path Tag 1, type extern 2, forward metric 1 Last update from 10.0.34.4 on GigabitEthernet0/4, 00:02:06 ago Routing Descriptor Blocks: * 10.0.34.4, from 4.4.4.4, 00:02:06 ago, via GigabitEthernet0/4 Route metric is 1, traffic share count is 1 Route tag 1
Using the null0 interface, as an exit interface, instead of a physical interface helps avoid routing loops. For example, imagine the exit interface of the static default route is GigabitEthernet 0/3. That means R4 uses router R3 as the next hop router for unknown network destinations. Similarly, router R3 is using R4 as a gateway of last resort because of the OSPF default route.
In this case, when router R3 needs to redirect IP traffic destined to an unknown destination to both routers R3 and R4, that would create a routing loop between the routers.
For example, R3 and R4 do not have a route matching subnet 11.0.0.0/24, except the 0.0.0.0/0 route. Consequently, when R3 receives an IP packet with a destination IP address in that subnet, it would forward it to R4, which would forward it back to R3; thus creating a routing loop.
At this point, we remove the default-information originate and ip route commands from R4 before moving to the next point.
R4(config)# no ip route 0.0.0.0 0.0.0.0 null0 R4(config)# R4(config)# router ospf 1 R4(config-router)# no default-information originate
Type 7 OSPF Default Route Configured Using The wrong Command.
The default-information originate command allows you to originate a Type 5 default route. The command works on routers connected to normal areas, including the backbone area. The command does not inject the default into stub areas, including NSSA and totally NSSA areas.
To advertise the OSPF default route into an NSSA area, you must use the area nssa default-information-originate command and make sure the 0.0.0.0/0 route is present in the routing table. Besides, the command does have the always keyword, unlike the default-information originate command.
The show running-config command output states that router R5 is trying to advertise the default route using the default-information originate always command. Since R5 is connected to area 345 only, which is an NSSA area, R5 cannot advertise the 0.0.0.0/0 route into area 345 using that command.
R5# show running-config | begin router ospf router ospf 1 router-id 5.5.5.5 area 345 nssa network 10.0.45.5 0.0.0.0 area 345 network 10.0.56.5 0.0.0.0 area 345 default-information originate always
In addition, the show ip route indicates that router R5 does not have a gateway of last resort.
R5# show ip route 0.0.0.0
% Network not in table
To fix this problem, we have to issue the area nssa default-information-originate command and configure a static default route since it does not exist in R5’s routing table.
R5(config)# ip route 0.0.0.0 0.0.0.0 null0 R5(config)# R5(config)# router ospf 1 R5(config-router)# area 345 nssa default-information-originate
The show ip ospf database nssa-external self-originate command states that router R5 creates a Type 7 LSA to advertise the default route. The router sets the P-bit to 1 so that the LSA gets translated by the area’s ABR to a Type 5 LSA.
R5# show ip ospf database nssa-external self-originate OSPF Router with ID (5.5.5.5) (Process ID 1) Type-7 AS External Link States (Area 345) LS age: 28 Options: (No TOS-capability, Type 7/5 translation, DC, Upward) LS Type: AS External Link Link State ID: 0.0.0.0 (External Network Number ) Advertising Router: 5.5.5.5 LS Seq Number: 80000001 Checksum: 0x8DC0 Length: 36 Network Mask: /0 Metric Type: 2 (Larger than any link state path) MTID: 0 Metric: 1 Forward Address: 10.0.56.5 External Route Tag: 0
The following show ip route command outputs indicate that the default route gets shared successfully with R4 and R6.
Router R4
R4# show ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via "ospf 1", distance 110, metric 1, candidate default path, type NSSA extern 2, forward metric 2 Last update from 10.0.46.6 on GigabitEthernet0/6, 00:06:35 ago Routing Descriptor Blocks: 10.0.46.6, from 5.5.5.5, 00:06:35 ago, via GigabitEthernet0/6 Route metric is 1, traffic share count is 1 * 10.0.45.5, from 5.5.5.5, 00:06:35 ago, via GigabitEthernet0/5 Route metric is 1, traffic share count is 1
Router R6
R6# show ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via "ospf 1", distance 110, metric 1, candidate default path, type NSSA extern 2, forward metric 1 Last update from 10.0.56.5 on GigabitEthernet0/5, 00:06:27 ago Routing Descriptor Blocks: * 10.0.56.5, from 5.5.5.5, 00:06:27 ago, via GigabitEthernet0/5 Route metric is 1, traffic share count is 1
Finally, we remove the default route’s configuration on R5.
R5(config)# no ip route 0.0.0.0 0.0.0.0 null0 R5(config)# router ospf 1 R5(config-router)# no area 345 nssa default-information-originate R5(config-router)# no default-information originate always R5(config-router)# no default-information originate
Stubby Area Not Allowing The OSPF Default Route
All types of stubby OSPF areas, including OSPF stub area, OSPF totally stub area, OSPF NSSA area, and OSPF totally NSSA area, prohibit Type 5 LSAs, including those advertising the OSPF default route. Therefore, if you configure the OSPF default route on a router outside a particular OSPF stubby area, regardless of its type, that route would not get flooded into the area.
However, if the originating router is connected to an NSSA or totally NSS area, the 0.0.0.0/0 route would be created and flooded via a Type 7 LSA into the area.
This example indicates that router R1 is configured to originate the Type 5 OSPF default route.
R1# show running-config | begin router ospf router ospf 1 router-id 1.1.1.1 area 12 stub network 10.0.12.1 0.0.0.0 area 12 default-information originate always
Since R1 is connected to area 12 only, which is a stub area, R1 fails to create a Type 5 LSA for the default route, as illustrated in the output of the show ip ospf database external command.
R1# show ip ospf database external 0.0.0.0 OSPF Router with ID (1.1.1.1) (Process ID 1) R1#
To fix this problem, we can either change the area type to normal by removing the area 12 stub statement from all routers in the area or configure the area to become an NSSA area.
In this example, we change the type of area 12 to allow external OSPF routes advertised via Type 7 LSAs, configure R1 to originate a Type 7 LSA default route using the area nssa default-information-originate command, and add a static default route so that the command works.
This way, OSPF area 12 will still be a stubby area that allows the default route and is not disrupted by unnecessary Type 5 LSAs. In addition, we remove the default-information originate always command.
Router R1
R1(config)# ip route 0.0.0.0 0.0.0.0 null0 R1(config)# router ospf 1 R1(config-router)# no area 12 stub R1(config-router)# area 12 nssa R1(config-router)# area 12 nssa default-information-originate R1(config-router)# no default-information originate always R1(config-router)# no default-information originate
Router R2
R2(config)# router ospf 1 R2(config-router)# no area 12 stub R2(config-router)# area 12 nssa
The output of the show ip ospf database nssa-external self-originate states that R1 produces a Type 7 LSA for the default route.
R1# show ip ospf database nssa-external self-originate
OSPF Router with ID (1.1.1.1) (Process ID 1)
Type-7 AS External Link States (Area 12)
LS age: 10
Options: (No TOS-capability, Type 7/5 translation, DC, Upward)
LS Type: AS External Link
Link State ID: 0.0.0.0 (External Network Number )
Advertising Router: 1.1.1.1
LS Seq Number: 80000001
Checksum: 0x8FFE
Length: 36
Network Mask: /0
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 1
Forward Address: 10.0.12.1
External Route Tag: 0
The show ip route command confirms that R2 received a Type 7 LSA advertising the default route originated by router R1.
R2# show ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via "ospf 1", distance 110, metric 1, candidate default path, type NSSA extern 2, forward metric 1 Last update from 10.0.12.1 on GigabitEthernet0/1, 00:09:48 ago Routing Descriptor Blocks: * 10.0.12.1, from 1.1.1.1, 00:09:48 ago, via GigabitEthernet0/1 Route metric is 1, traffic share count is 1
Moreover, R2 converted the Type 7 LSA that is advertising the default route into a Type 5 LSA, as shown in this example.
R2# show ip ospf database external self-originate
OSPF Router with ID (2.2.2.2) (Process ID 1)
Type-5 AS External Link States
LS age: 283
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 0.0.0.0 (External Network Number )
Advertising Router: 2.2.2.2
LS Seq Number: 80000001
Checksum: 0x68E
Length: 36
Network Mask: /0
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 1
Forward Address: 10.0.12.1
External Route Tag: 0
This way the default route gets propagated to routers R3 and R4, as illustrated in the outputs of the show ip route command below.
Router R3
R3# show ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via "ospf 1", distance 110, metric 1, candidate default path, type extern 2, forward metric 2 Last update from 10.0.23.2 on GigabitEthernet0/2, 00:06:20 ago Routing Descriptor Blocks: * 10.0.23.2, from 2.2.2.2, 00:06:20 ago, via GigabitEthernet0/2 Route metric is 1, traffic share count is 1
Router R4
R4# show ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via "ospf 1", distance 110, metric 1, candidate default path, type extern 2, forward metric 3 Last update from 10.0.34.3 on GigabitEthernet0/3, 00:07:35 ago Routing Descriptor Blocks: * 10.0.34.3, from 2.2.2.2, 00:07:35 ago, via GigabitEthernet0/3 Route metric is 1, traffic share count is 1
Finally, we remove the changes we’ve made to routers R1 and R2.
Router R1
R1(config)# no ip route 0.0.0.0 0.0.0.0 null0 R1(config)# router ospf 1 R1(config-router)# no area 12 nssa default-information-originate R1(config-router)# no area 12 nssa R1(config-router)# area 12 stub
Router R2
R2(config)# router ospf 1 R2(config-router)# no area 12 nssa R2(config-router)# area 12 stub
The default-information originate command is Not Present in The OSPF Node’s OSPF Configuration
Unlike Cisco’s implementation of EIGRP, which comes with more than one command to advertise the EIGRP default route, Cisco’s implementation of OSPF offers only one command to configure the OSPF default route, the default-information originate command.
In addition, you cannot redistribute into OSPF a default route whether it is produced by static routing or a dynamic routing protocol (RIP, EIGRP, BGP,…). This example instructs router R3 to create a static default route and redistribute it into OSPF.
R3(config)# ip route 0.0.0.0 0.0.0.0 null0 R3(config)# router ospf 1 R3(config-router)# redistribute static subnets
But the 0.0.0.0/0 does get advertised into the routing domain because R3 does not originate a Type 5 LSA for it, as indicated in the show ip ospf database command output.
R3# show ip ospf database external self-originate OSPF Router with ID (3.3.3.3) (Process ID 1) R3#
The OSPF default route would not get propagated if the default-information originate command is missing from the OSPF configuration. That would be because the command has not been issued or has been removed.
The show running-config command output indicates that R3’s OSPF configuration does not include that command.
R3# show running-config | begin router router ospf 1 router-id 3.3.3.3 network 10.0.23.3 0.0.0.0 area 0 network 10.0.34.3 0.0.0.0 area 0
To fix this problem, issue the default-information originate command in router configuration mode while keeping the static default route.
If static default route has to be removed and no default route exists in the routing table, issue the default-information originate always command; otherwise, the OSPF default route would not get originated.
R3 does not have a default route, as shown in this output of the show ip route command.
R3# show ip route 0.0.0.0
% Network not in table
R3#
This example configures router R3 to advertise the OSPF default route, even though the router doesn’t have a default route in its routing table.
R3(config)# router ospf 1
R3(config-router)# default-information originate always
Finally, the outputs of the show ip ospf database external self-originate and show ip route commands indicate that the OSFP default route is originated and advertised to R3’s OSPF neighbors.
Router R3
R3# show ip ospf database external self-originate
OSPF Router with ID (3.3.3.3) (Process ID 1)
Type-5 AS External Link States
LS age: 2
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 0.0.0.0 (External Network Number )
Advertising Router: 3.3.3.3
LS Seq Number: 80000001
Checksum: 0xE0C5
Length: 36
Network Mask: /0
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 1
Forward Address: 0.0.0.0
External Route Tag: 1
Router R2
R2# show ip route ospf omitted output Gateway of last resort is 10.0.23.3 to network 0.0.0.0 O*E2 0.0.0.0/0 [110/1] via 10.0.23.3, 00:09:51, GigabitEthernet0/3 10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks O 10.0.34.0/24 [110/2] via 10.0.23.3, 00:20:28, GigabitEthernet0/3 O IA 10.0.45.0/24 [110/3] via 10.0.23.3, 00:20:28, GigabitEthernet0/3 O IA 10.0.46.0/24 [110/3] via 10.0.23.3, 00:20:28, GigabitEthernet0/3 O IA 10.0.56.0/24 [110/4] via 10.0.23.3, 00:20:28, GigabitEthernet0/3
Router R4
R4# show ip route ospf omitted output Gateway of last resort is 10.0.34.3 to network 0.0.0.0 O*E2 0.0.0.0/0 [110/1] via 10.0.34.3, 00:11:00, GigabitEthernet0/3 10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks O IA 10.0.12.0/24 [110/3] via 10.0.34.3, 00:42:39, GigabitEthernet0/3 O 10.0.23.0/24 [110/2] via 10.0.34.3, 00:42:39, GigabitEthernet0/3 O 10.0.56.0/24 [110/2] via 10.0.46.6, 00:42:39, GigabitEthernet0/6 [110/2] via 10.0.45.5, 00:42:39, GigabitEthernet0/5
Troubleshooting OSPF Route Summarization Advertisement
Advertising an OSPF summary route, whether it is internal or external, for one or multiple network links requires that at least one IP prefix, matching that route, exits in the OSPF RIB table. It does not matter if a matching IP prefix appears as an OSPF route in the routing table or not.
Configuring an OSPF summary route for internal OSPF links can be done on only ABR routers only, and you should use the area range command in this case. On the other hand, aggregating external network links can be achieved on ASBRs only, and you have to use the summary-address command.
If an OSPF node fails to advertise an aggregate route, it would be caused by at least one of the following reasons:
- OSPF route summarization is configured on the wrong router
- OSPF route summarization is set up using the wrong cisco IOS command
- The summary IP address does not have a matching IP prefix in the OSPF RIB table
- OSPF route summarization is configured with the wrong summary IP address or subnet mask
- OSPF route summarization is configured using the wrong OSPF area number
In this section, I will be using this network diagram. The network type of R4’s Loopback interfaces is set to point-to-point, and router redistribution between EIGRP and OSPF is done properly on router R1.
Click the links below to download the routers’ configurations.
| Router R1 | Router R2 | Router R3 |
| Router R4 | Router R5 | |
The goal of this section is to demonstrate the reasons causing OSPF summarization to fail, and set up the network based on these rules:
- Configure an aggregate route for internal OSPF subnets 10.0.140.0/24, 10.0.141.0/24, 10.0.142.0/24, and 10.0.143.0/24.
- Configure a summary route for EIGRP subnets 10.0.150.0/24, 10.0.151.0/24, 10.0.152.0/24, and 10.0.153.0/24.
Let’s demonstrate each of these reasons.
OSPF Route Summarization is Configured on The Wrong Router
As mentioned before, a part or all routes of a particular OSPF area, whether they are intra-area routes, inter-area routes, or a mix of them, can be summarized by ABRs only. Therefore, configuring an aggregate route for routes in a particular area should not be done on routers not connected to area 0.
For example, the show running-config command output states that R4 is advertising a summary route for IP prefixes 10.0.140.0, 10.0.141.0, 10.0.142.0, and 10.0.143.0.
R4# show running-config | section router ospf
router ospf 1
router-id 4.4.4.4
area 34 range 10.0.140.0 255.255.252.0
network 10.0.34.4 0.0.0.0 area 34
network 10.0.140.4 0.0.0.0 area 34
network 10.0.141.4 0.0.0.0 area 34
network 10.0.142.4 0.0.0.0 area 34
network 10.0.143.4 0.0.0.0 area 34
However, R4 does not generate and advertise the associated summary route, as indicated by the following output of the show ip ospf database summary self-originate command.
R4# show ip ospf database summary self-originate OSPF Router with ID (4.4.4.4) (Process ID 1) R4#
Summary IP address 10.0.140.0 combined with subnet mask 255.255.252.0 match all R4’s Loopback interfaces, but R4 could not advertise that route because it is not an ABR router, it is not connected to area 0.
Note: if you want to learn how to calculate the summary address and subnet mask of an aggregate route, check out this guide about OSPF summarization.
Similarly, the show running-config command output below states that R2 is configured to advertise an external summary route with IP address 10.0.144.0 and subnet mask 255.255.240.0.
R2# show running-config | section router ospf
router ospf 1
router-id 2.2.2.2
summary-address 10.0.144.0 255.255.240.0
network 10.0.12.2 0.0.0.0 area 12
network 10.0.23.2 0.0.0.0 area 0
The route matches all R5’s Loopback interfaces redistributed into OSPF. However, R2 does not create an LSA Type 5 for it, as shown in this example.
R2# show ip ospf database external self-originate OSPF Router with ID (2.2.2.2) (Process ID 1) R2#
According to the network diagram, R2 is not an ASBR, and thus it cannot summarize external routes. Instead, the external summary route must be configured on router R1.
OSPF Route Summarization is Set Up Using The Wrong Cisco IOS Command
Cisco IOS offers two different commands to perform OSPF route summarization: area range and summary-address. The area range command allows you to advertise a summary route for one or many OSPF IP Prefixes of a particular area, while the summary-address command allows you to summarize external OSPF IP prefixes. External OSPF IP prefixes are not attached to a particular OSPF area.
The following show running-config command output contains the summary-address 10.0.140.0 255.255.252.0 statement.
R3# show running-config | section router
router ospf 1
router-id 3.3.3.3
area 12 range 10.0.140.0 255.255.252.0
area 34 range 10.0.144.0 255.255.252.0
summary-address 10.0.140.0 255.255.252.0
network 10.0.23.3 0.0.0.0 area 0
network 10.0.34.3 0.0.0.0 area 34
Router R3 would not advertise a summary route for R4’s Loopback interfaces using that command because it is designed to work with external OSPF routes, while IP addresses 10.0.140.0/24, 10.0.141.0/24, 10.0.142.0/24, and 10.0.143.0/24 are internal OSPF IP prefixes.
Therefore, if we want to summarize them, we should use the area range command instead of the summary-address command.
The Summary IP Address Does Not Have a Matching IP Prefix in The OSPF RIB Table
The area 34 range 10.0.144.0 255.255.252.0 statement, included in the output of the show running-config command, instructs router R3 to summarize IP addresses 10.0.144.0, 10.0.145.0, 10.0.146.0, and 10.0.147.0, which don’t appear in area 34’s LSDB.
R3# show running-config | section router
router ospf 1
router-id 3.3.3.3
area 12 range 10.0.140.0 255.255.252.0
area 34 range 10.0.144.0 255.255.252.0
summary-address 10.0.140.0 255.255.252.0
network 10.0.23.3 0.0.0.0 area 0
network 10.0.34.3 0.0.0.0 area 34
This example confirms that the command fails to generate a Type 3 LSA for that summary route.
R3# show ip ospf database summary 10.0.144.0 OSPF Router with ID (3.3.3.3) (Process ID 1) R3#
Besides, the show ip ospf rib outputs indicate that none of the IP prefixes, supposed to be summarized, exists in the OSPF RIB table. Consequently, router R3 does not inject IP prefix 10.0.144.0/22 into area 0.
R3#show ip ospf rib 10.0.144.0 %OSPF: Route not in OSPF Base Topology (MTID 0) local RIB R3#show ip ospf rib 10.0.145.0 %OSPF: Route not in OSPF Base Topology (MTID 0) local RIB R3#show ip ospf rib 10.0.146.0 %OSPF: Route not in OSPF Base Topology (MTID 0) local RIB R3#show ip ospf rib 10.0.147.0 %OSPF: Route not in OSPF Base Topology (MTID 0) local RIB
OSPF Route Summarization Configured Using The Wrong Summary IP address or Subnet Mask
According to the following output of the show running-config command, router R1 is advertising an aggregate route for external IP prefixes 10.0.150.0 and 10.0.151.0 only.
This is inconsistent with our OSPF summarization policy mentioned at the beginning of this section because router R1 should summarize IP prefixes 10.0.152.0 and 10.0.153.0 along with 10.0.150.0 and 10.0.151.0.
R1# show running-config | section router ospf
router ospf 1
router-id 1.1.1.1
summary-address 10.0.150.0 255.255.254.0
redistribute eigrp 15 subnets
network 10.0.12.1 0.0.0.0 area 12
In fact, the output of the show ip route ospf command illustrates that subnets 10.0.150.0/24 and 10.0.151.0/24 are getting summarized, while subnets 10.0.152.0/24 and 10.0.153.0/24 aren’t.
R4# show ip route ospf omitted output 10.0.0.0/8 is variably subnetted, 16 subnets, 3 masks O IA 10.0.12.0/24 [110/3] via 10.0.34.3, 01:00:57, GigabitEthernet0/3 O E2 10.0.15.0/24 [110/20] via 10.0.34.3, 01:00:57, GigabitEthernet0/3 O IA 10.0.23.0/24 [110/2] via 10.0.34.3, 01:00:57, GigabitEthernet0/3 O E2 10.0.150.0/23 [110/20] via 10.0.34.3, 01:00:57, GigabitEthernet0/3 O E2 10.0.152.0/24 [110/20] via 10.0.34.3, 01:00:57, GigabitEthernet0/3 O E2 10.0.153.0/24 [110/20] via 10.0.34.3, 01:00:57, GigabitEthernet0/3
To solve this problem, we have to calculate the corresponding aggregate IP address and subnet mask matching the IP prefixes in question, remove the current summary-address command from R1’s OSPF configuration, and then configure the external summary route using the new address and subnet mask.
OSPF Route Summarization Configured Using The Wrong OSPF Area Number
According to the following output of the show running-config command, router R1 is advertising an aggregate route for OSPF IP prefixes 10.0.140.0, 10.0.141.0, 10.0.142.0, and 10.0.143.0 only. However, the summary route is associated with the wrong area.
R3# show running-config | section router
router ospf 1
router-id 3.3.3.3
area 12 range 10.0.140.0 255.255.252.0
area 34 range 10.0.144.0 255.255.252.0
summary-address 10.0.140.0 255.255.252.0
network 10.0.23.3 0.0.0.0 area 0
network 10.0.34.3 0.0.0.0 area 34
The area id you supply to the area range command must be the OSPF area containing the IP prefixes to aggregate. Otherwise, the command won’t produce the expected result.
In fact, area 12’s LSDB does not have an IP prefix matching the summary address and subnet mask pair configured with the area range command above. Thus, R3 fails to originate and share a Type 3 LSA for the summary route.
Therefore, we have to replace 12 with 34 in the area range command in order to get the summary route advertised into all OSPF areas connected to router R3, except area 34.
Let’s fix the OSPF summarization issues we have in according to the rules above
These examples configure the network based on the OSPF summarization rules above. First, we remove the current summary-address command on router R1 and configure an external summary route using IP address 10.0.144.0 and subnet mask 255.255.240.0.
Next, we remove the summary-address and area range commands issued on routers R2, R3, and R4. Finally, we instruct R3 to originate an aggregate route for R4’s Loopback interfaces.
Router R1
R1(config)# router ospf 1
R1(config-router)# no summary-address 10.0.150.0 255.255.254.0
R1(config-router)# summary-address 10.0.144.0 255.255.240.0
Router R2
R2(config)# router ospf 1 R2(config-router)# no summary-address 10.0.144.0 255.255.248.0
Router R3
R3(config)# router ospf 1
R3(config-router)# no area 12 range 10.0.140.0 255.255.252.0
R3(config-router)# no area 34 range 10.0.144.0 255.255.252.0
R3(config-router)# no summary-address 10.0.140.0 255.255.252.0
R3(config-router)# area 34 range 10.0.140.0 255.255.252.0
Router R4
R4(config)# router ospf 1 R4(config-router)# no area 34 range 10.0.140.0 255.255.252.0
The show ip route ospf command states that external subnets 10.0.150.0/24, 10.0.151.0/24, 10.0.152.0/24, and 10.0.153.0/24 are summarized successfully.
R4# show ip route ospf
omitted output
10.0.0.0/8 is variably subnetted, 14 subnets, 3 masks
O IA 10.0.12.0/24 [110/3] via 10.0.34.3, 00:00:55, GigabitEthernet0/3
O E2 10.0.15.0/24 [110/20] via 10.0.34.3, 00:00:55, GigabitEthernet0/3
O IA 10.0.23.0/24 [110/2] via 10.0.34.3, 00:00:55, GigabitEthernet0/3
O E2 10.0.144.0/20 [110/20] via 10.0.34.3, 00:00:02, GigabitEthernet0/3
The show ip ospf database summary command output states that router R3 created a Type 3 LSA in area 0 for the summary IP prefix.
R3# show ip ospf database summary 10.0.140.0 OSPF Router with ID (3.3.3.3) (Process ID 1) Summary Net Link States (Area 0) LS age: 16 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 10.0.140.0 (summary Network Number) Advertising Router: 3.3.3.3 LS Seq Number: 8000000F Checksum: 0x8B02 Length: 28 Network Mask: /22 MTID: 0 Metric: 2
Additionally, routers R1 and R2 receive the Type 3 LSA and add the corresponding route to their OSPF RIB tables, as you can see in these examples.
Router R1
R1# show ip ospf rib
OSPF Router with ID (1.1.1.1) (Process ID 1)
Base Topology (MTID 0)
OSPF local RIB
Codes: * - Best, > - Installed in global RIB
* 10.0.12.0/24, Intra, cost 1, area 12, Connected
via 10.0.12.1, GigabitEthernet0/2
*> 10.0.23.0/24, Inter, cost 2, area 12
via 10.0.12.2, GigabitEthernet0/2
*> 10.0.34.0/24, Inter, cost 3, area 12
via 10.0.12.2, GigabitEthernet0/2
*> 10.0.140.0/24, Inter, cost 4, area 12
via 10.0.12.2, GigabitEthernet0/2
*> 10.0.140.0/22, Inter, cost 4, area 12
via 10.0.12.2, GigabitEthernet0/2
*> 10.0.144.0/20, Intra, cost 20
via Null0
Router R2
R2# show ip ospf rib
OSPF Router with ID (2.2.2.2) (Process ID 1)
Base Topology (MTID 0)
OSPF local RIB
Codes: * - Best, > - Installed in global RIB
* 10.0.12.0/24, Intra, cost 1, area 12, Connected
via 10.0.12.2, GigabitEthernet0/1
*> 10.0.15.0/24, Ext2, cost 20, fwd cost 1, tag 0
via 10.0.12.1, GigabitEthernet0/1
* 10.0.23.0/24, Intra, cost 1, area 0, Connected
via 10.0.23.2, GigabitEthernet0/3
*> 10.0.34.0/24, Inter, cost 2, area 0
via 10.0.23.3, GigabitEthernet0/3
*> 10.0.140.0/22, Inter, cost 3, area 0
via 10.0.23.3, GigabitEthernet0/3
*> 10.0.144.0/20, Ext2, cost 20, fwd cost 1, tag 0
via 10.0.12.1, GigabitEthernet0/1
Troubleshooting OSPF Route Advertisement on Hub and Spoke Network Topologies
In hub-and-spoke networks, it is easy for all LSAs in a neighbor’s LSDB not to be shared with OSPF nodes on the same media. This problem would affect any route that is expected to be advertised by an OSPF neighbor, whether it corresponds to an OSPF-enabled interface, a summary IP address, an external subnet/network, or the 0.0.0.0/0 IP prefix.
This problem occurs when an inappropriate designated router is selected. OSPF LSAs are not shared properly; thus the associated OSPF routes are missing from the OSPF RIB table.
In the rest of this section, I will be using the following network diagram. The OSPF network type of the Loopback interfaces is set to point-to-point so that their subnets get advertised with their real subnet masks.
To simulate a hub and spoke non-broadcast multiaccess network where R1 is the hub and R2 and R3 are the spokes, we set the OSPF network type of the G0/0 interfaces to non-broadcast, and, we configure R1 to initiate sending Hello packets to routers R2 and R3, but R2 and R3 won’t try to negotiate an OSPF adjacency with each other.
Click the links below to download the initial router configurations.
| Router R1 | Router R2 | Router R3 |
These examples indicate that R3 is elected the DR, R1 is chosen as the BDR, and R2 is a DROther.
Router R1
R1# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 1 FULL/DROTHER 00:01:43 10.0.0.2 GigabitEthernet0/0 3.3.3.3 1 FULL/DR 00:01:51 10.0.0.3 GigabitEthernet0/0
Router R2
R2# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 FULL/BDR 00:01:32 10.0.0.1 GigabitEthernet0/0
The OSPF DR router is responsible for flooding received LSAs from the BDR and all DROthers on the current physical link, but the BDR and DROther routers are not. Consequently, R1, the BDR in our case, will not reflood to R3 received LSAs, typically sent to IP address 224.0.0.6, from router R2, even though it can read them, and vice versa.
This way R2 and R3 would not learn OSPF LSAs advertising subnets 10.0.130.0/24 and 10.0.120.0/24, respectively, as illustrated in these examples.
Router R2
R2# show ip route ospf Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP a - application route + - replicated route, % - next hop override, p - overrides from PfR Gateway of last resort is not set R2#
Router R3
R3# show ip route ospf
omitted output
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
O 10.0.110.0/24 [110/2] via 10.0.0.1, 00:09:43, GigabitEthernet0/0
Moreover, R1 and R2 won’t exchange their Loopbacks’ associated subnets because none of them is the DR, as stated in the outputs of the following show ip route ospf command.
Router R1
R1# show ip route ospf
omitted output
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
O 10.0.130.0/24 [110/2] via 10.0.0.3, 00:10:10, GigabitEthernet0/0
Router R2
R2# show ip route ospf Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP a - application route + - replicated route, % - next hop override, p - overrides from PfR Gateway of last resort is not set R2#
Finally, R1 and R3 shared their Loopbacks’ associated subnets since R3 is the DR, as stated in these examples.
Router R1
R1# show ip route ospf
omitted output
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
O 10.0.130.0/24 [110/2] via 10.0.0.3, 00:10:10, GigabitEthernet0/0
Router R3
R3# show ip route ospf
omitted output
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
O 10.0.110.0/24 [110/2] via 10.0.0.1, 00:09:43, GigabitEthernet0/0
If the hub, router R1, is the DR, router R1 would share LSAs received from R2 with R3, and vice versa. Therefore, R2 and R3 would have routes to subnets 10.0.130.0/24 and 10.0.120.0/24, respectively, along with subnet 10.0.110.0/24. As a result, routers on subnet 10.0.0.0/24 would have full IP reachability to all subnets in the hub and spoke network.
To fix this problem, the spokes should not be able to participate in the OSPF DR and BDR election process. To achieve this, we set the OSPF priority of the R2 and R3’s GigabitEthernet 0/0 interfaces to 0, as shown in the following examples.
Since the DR election process is not preemptive, we restart the OSPF instances on R2 and R3 to allow the changes to take effect.
Router R2
R2(config)# interface gigabitEthernet 0/0
R2(config-if)# ip ospf priority 0
R2(config-if)# end
R2#
R2# clear ip ospf process
Reset ALL OSPF processes? [no]: yes
R2#
Router R3
R3(config)# interface gigabitEthernet 0/0
R3(config-if)# ip ospf priority 0
R3(config-if)# end
R3#
R3# clear ip ospf process
Reset ALL OSPF processes? [no]: yes
R3#
The following outputs of the show ip route command indicate that the routers have full reachability to all subnets in the network.
Router R1
R1# show ip route omitted output 10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks C 10.0.0.0/24 is directly connected, GigabitEthernet0/0 L 10.0.0.1/32 is directly connected, GigabitEthernet0/0 C 10.0.110.0/24 is directly connected, Loopback0 L 10.0.110.1/32 is directly connected, Loopback0 O 10.0.120.0/24 [110/2] via 10.0.0.2, 00:04:52, GigabitEthernet0/0 O 10.0.130.0/24 [110/2] via 10.0.0.3, 00:04:42, GigabitEthernet0/0
Router R2
R2# show ip route omitted output 10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks C 10.0.0.0/24 is directly connected, GigabitEthernet0/0 L 10.0.0.2/32 is directly connected, GigabitEthernet0/0 O 10.0.110.0/24 [110/2] via 10.0.0.1, 00:04:55, GigabitEthernet0/0 C 10.0.120.0/24 is directly connected, Loopback0 L 10.0.120.2/32 is directly connected, Loopback0 O 10.0.130.0/24 [110/2] via 10.0.0.3, 00:04:55, GigabitEthernet0/0
Router R3
R3# show ip route omitted output 10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks C 10.0.0.0/24 is directly connected, GigabitEthernet0/0 L 10.0.0.3/32 is directly connected, GigabitEthernet0/0 O 10.0.110.0/24 [110/2] via 10.0.0.1, 00:05:06, GigabitEthernet0/0 O 10.0.120.0/24 [110/2] via 10.0.0.2, 00:05:06, GigabitEthernet0/0 C 10.0.130.0/24 is directly connected, Loopback0 L 10.0.130.3/32 is directly connected, Loopback0
Cisco IOS Commands Used for Troubleshooting OSPF Route Advertisement Problems
Here is a list of useful Cisco IOS commands you may need to diagnose OSPF route advertisement problems.
- show intercafes
- show ip interface
- show ip route
- show ip ospf rib
- show ip ospf database
- show ip ospf
- show ip protocols
- show ip ospf interface
- show ip ospf interface brief
- show ip ospf virtual-links
- show ip ospf database
- show ip ospf database router
- show ip ospf database summary
- show ip ospf database as-summary
- show ip ospf database nssa-as-summary
- show running-config interface
- show running-config | section router ospf
Related Lessons to Troubleshooting OSPF Route Advertisement
- OSPF
- OSPF Router ID
- OSPF Null Authentication
- OSPF Plain Text Authentication
- OSPF Default Route
- Basic OSPF Configuration Lab for CCNA
- OSPF Configuration
- OSPF Passive Interface
- OSPF Virtual Link
- OSPF Stub Area
- OSPF LSA Types
- OSPF Graceful Restart
- OSPF Totally Stubby Area
- OSPF Reference Bandwidth
- OSPF Cost
- OSPF DR/BDR Election
- OSPF Hello and Dead Interval
- OSPF Metric
- OSPF MD5 Authentication
- OSPF HMAC-SHA Cryptographic Authentication
- OSPF Multi-Area
- OSPF TTL Security Check
- OSPF Graceful Shutdown
- Route Redistribution between OSPF and RIP
- OSPF Network Types
- OSPF Totally NSSA Area
- OSPF NSSA Area
- OSPF Summarization
- OSPF Route Filtering
- OSPF Type 5 LSA Filtering
- OSPF ABR Type 3 LSA Filtering
- OSPF Prefix Suppression
- OSPF Path Selection
- OSPF LSA Throttling
- OSPF SPF Throttling
- OSPF Incremental SPF
- OSPF Non-Broadcast Network Type
- OSPF Point-to-Point Network Type
- OSPF Broadcast Network Type
- OSPF Point-to-Multipoint Network Type
- OSPF vs RIP
- OSPF LSA Group Pacing
- OSPF LSA Flood Pacing
- OSPF LSA Retransmission Pacing
- Troubleshooting OSPF Neighbor Adjacency
- Troubleshooting OSPF Route Installation
- Troubleshooting OSPF Route Advertisement
- OSPF Stub Router
Conclusion
I hope this blog post helps you learn something.
Now I’d like to turn it over to you:
What did you like about this tutorial?
Or maybe you have an excellent idea that you think I need to add.
Either way, let me know by leaving a comment below right now.