This article is a natural follow up to a previous article about OSPF area border routers and inter-area links between non-backbone areas (see http://mreji.eu/content/ospf-inter-area-links).To recapitulate briefly, despite our efforts we couldn’t manage to provide redundant links through OSPF non-zero areas. The major drawback was that Cisco are not considering such a router an ABR, even if it has links in two or more areas. Respectively summary LSA are not originated and inter-area routes not advertized. There is a requirement that a cisco router must have at least one link in area 0. Then and only then it is considered a real ABR. Though this is true for an ABR this condition can be circumvented for an ASBR. There is no requirement for an ASBR to have links in area 0. And this leads us to the next obstacle. How can we make an OSPF router an ASBR and still run only OSPF routing protocol?

Simple solution

The answer is simple enough so that I couldn’t figure it out easily. We can make a router an ASBR by redistributing between multiple OSPF instances. Redistributed routes appear as external to the instance into which they are redistributed.

Topology and router configurations

With this idea in mind we make a test topology as follows:

R1 has links in area 0,1 and 3. Interface loopback1 is placed in area 3. R1 is always advertizing a default route, because it is connected to the Internet. R2 has links in area 0 and area 2. This makes R1 and R2 ABRs. R3 has links in area 1 and area 2, but not in area 0. According to cisco it is not an ABR. But R3 is running two OSPF instances namely instance 1 and 2 which are mutually redistributed. It makes R3 an ASBR. For more details see the network diagram above. Router configurations are presented below (some parts are skipped for brevity):

R1 hostname R1

interface Loopback0

ip address 10.0.100.1 255.255.255.255

!

interface Loopback1

ip address 10.0.101.1 255.255.255.0

!

interface FastEthernet0/0

ip address 10.0.0.1 255.255.255.0

duplex auto

speed auto

!

interface FastEthernet0/1

ip address 10.0.1.1 255.255.255.0

duplex auto

speed auto

!

router ospf 1

log-adjacency-changes

network 10.0.1.0 0.0.0.255 area 1

network 10.0.101.0 0.0.0.255 area 3

network 10.0.0.0 0.255.255.255 area 0

default-information originate always

!

R2 hostname R2

!

interface Loopback0

ip address 10.0.100.2 255.255.255.255

!

interface Loopback1

ip address 10.0.102.1 255.255.255.0

!

interface FastEthernet0/0

ip address 10.0.0.2 255.255.255.0

duplex auto

speed auto

!

interface FastEthernet0/1

ip address 10.0.2.1 255.255.255.0

duplex auto

speed auto

!

router ospf 1

log-adjacency-changes

network 10.0.2.0 0.0.0.255 area 2

network 10.0.0.0 0.255.255.255 area 0

!

R3 hostname R3

!

interface Loopback0

ip address 10.0.100.3 255.255.255.255

!

interface Loopback1

ip address 10.0.103.1 255.255.255.0

!

interface FastEthernet0/0

ip address 10.0.1.2 255.255.255.0

duplex auto

speed auto

!

interface FastEthernet0/1

ip address 10.0.2.2 255.255.255.0

duplex auto

speed auto

!

router ospf 1

log-adjacency-changes

redistribute ospf 2 subnets

network 10.0.2.0 0.0.0.255 area 2

network 10.0.103.0 0.0.0.255 area 2

default-information originate

!

router ospf 2

log-adjacency-changes

redistribute ospf 1 subnets

network 10.0.1.0 0.0.0.255 area 1

!

Additional notes

In addition to the two OSPF instances on R3 there is something more, which is not easily spotted in the configuration. If 10.0.0.0/8 network is configured under OSPF 1 in area 1, then the next OSPF instance cannot build adjacency on interfaces in the 10.0.0.0/8 network and its subnets. The network is already allocated to the first OSPF instance and all links lie in area 1. In such a case the following message appears under debug ospf adjacency:

R3 R3#debug ip ospf adj

OSPF adjacency events debugging is on

R3#

00:22:02: OSPF: Rcv pkt from 10.0.1.1, FastEthernet0/0, area 0.0.0.2

mismatch area 0.0.0.1 in the header

00:22:12: OSPF: Rcv pkt from 10.0.1.1, FastEthernet0/0, area 0.0.0.2

mismatch area 0.0.0.1 in the header

Routing tables and OSPF database

First on R1 we check if all routes are present:

R1 R1#sh ip route 10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks O IA 10.0.2.0/24 [110/2] via 10.0.0.2, 00:31:14, FastEthernet0/0 C 10.0.0.0/24 is directly connected, FastEthernet0/0 C 10.0.1.0/24 is directly connected, FastEthernet0/1 O IA 10.0.103.1/32 [110/3] via 10.0.0.2, 00:31:14, FastEthernet0/0 O 10.0.100.2/32 [110/2] via 10.0.0.2, 00:33:47, FastEthernet0/0 O E2 10.0.103.0/24 [110/1] via 10.0.1.2, 00:31:14, FastEthernet0/1 O 10.0.102.1/32 [110/2] via 10.0.0.2, 00:33:47, FastEthernet0/0 C 10.0.101.0/24 is directly connected, Loopback1 C 10.0.100.1/32 is directly connected, Loopback0 R1#

We see that all subnets are in the routing table, except R3 loopback0 IP address (10.0.100.3). Curiously R3 OSPF instances have picked up different router IDs as can be seen later from the OSPF database. However the explaination to this fact is not important to the problem discussed and I only note its existence. What should be pointed out is that the route to R3 looback0 (10.0.100.3) is missing because there is no network command under neither of the OSPF instances. So it is no included in LSAs. And to look at R1 OSPF database:

R3 R1#sh ip ospf database OSPF Router with ID (10.0.101.1) (Process ID 1) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 10.0.100.2 10.0.100.2 1732 0x80000006 0x00220F 3 10.0.101.1 10.0.101.1 660 0x80000006 0x000CA7 2 Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 10.0.0.1 10.0.101.1 1688 0x80000002 0x006F6D Summary Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 10.0.1.0 10.0.101.1 660 0x80000004 0x00D9E3 10.0.2.0 10.0.100.2 720 0x80000006 0x00CBEE 10.0.101.1 10.0.101.1 1937 0x80000002 0x0083D6 10.0.103.1 10.0.100.2 721 0x80000002 0x0078DE Summary ASB Link States (Area 0) Link ID ADV Router Age Seq# Checksum 10.0.100.3 10.0.101.1 416 0x80000002 0x006CEB 10.0.103.1 10.0.100.2 477 0x80000002 0x0060F6 Router Link States (Area 1) Link ID ADV Router Age Seq# Checksum Link count 10.0.100.3 10.0.100.3 278 0x80000004 0x00C071 1 10.0.101.1 10.0.101.1 662 0x80000004 0x00C370 1 Net Link States (Area 1) Link ID ADV Router Age Seq# Checksum 10.0.1.1 10.0.101.1 662 0x80000002 0x007268 Summary Net Link States (Area 1) Link ID ADV Router Age Seq# Checksum 10.0.0.0 10.0.101.1 1690 0x80000004 0x00E4D9 10.0.2.0 10.0.101.1 662 0x80000006 0x00D4E4 10.0.100.1 10.0.101.1 1939 0x80000002 0x008ECC 10.0.100.2 10.0.101.1 1690 0x80000002 0x008ECA 10.0.101.1 10.0.101.1 1939 0x80000002 0x0083D6 10.0.102.1 10.0.101.1 1691 0x80000002 0x0082D5 10.0.103.1 10.0.101.1 663 0x80000002 0x0081D4 Summary ASB Link States (Area 1) Link ID ADV Router Age Seq# Checksum 10.0.103.1 10.0.101.1 419 0x80000002 0x0069EC Router Link States (Area 3) Link ID ADV Router Age Seq# Checksum Link count 10.0.101.1 10.0.101.1 663 0x80000003 0x00D209 1 Summary Net Link States (Area 3) Link ID ADV Router Age Seq# Checksum 10.0.0.0 10.0.101.1 1691 0x80000004 0x00E4D9 10.0.1.0 10.0.101.1 663 0x80000006 0x00D5E5 10.0.2.0 10.0.101.1 663 0x80000006 0x00D4E4 10.0.100.1 10.0.101.1 1940 0x80000002 0x008ECC 10.0.100.2 10.0.101.1 1691 0x80000002 0x008ECA 10.0.102.1 10.0.101.1 1691 0x80000002 0x0082D5 10.0.103.1 10.0.101.1 663 0x80000002 0x0081D4 Summary ASB Link States (Area 3) Link ID ADV Router Age Seq# Checksum 10.0.100.3 10.0.101.1 420 0x80000002 0x006CEB 10.0.103.1 10.0.101.1 420 0x80000002 0x0069EC Type-5 AS External Link States Link ID ADV Router Age Seq# Checksum Tag 0.0.0.0 10.0.101.1 664 0x80000002 0x00132E 1 10.0.0.0 10.0.100.3 280 0x80000002 0x0083B2 0 10.0.1.0 10.0.103.1 363 0x80000002 0x0065CF 0 10.0.2.0 10.0.100.3 280 0x80000002 0x0063D1 0 10.0.100.1 10.0.100.3 280 0x80000002 0x00339C 0 10.0.100.2 10.0.100.3 280 0x80000002 0x001FB0 0 10.0.101.1 10.0.100.3 280 0x80000002 0x0028A6 0 10.0.102.1 10.0.100.3 280 0x80000002 0x0013BB 0 10.0.103.0 10.0.100.3 280 0x80000002 0x0008C7 0 R1#

A bit of explaination is needed about the information presented. The more interesting part is at the end where type-5 LSA (external) routes begin. One of them is the default route which is self-originated (colored in gray). The rest however are originated by R3 (advetritizing router 10.0.100.3 or 10.0.103.1) and are highlighted. As mentioned above R3 is known by two router IDs – one for each OSPF instance. From these LSAs only one is installed in R1 routing table. This is due to the inherent behavior of OSPF protocol. It prefers intra-area to inter-area routes and inter-area to external routes. Cost is not considered at all. And because R1 has either intra-area or inter-area LSAs (type 1, 2 or 3) for these same subnets it is not installing the external LSAs except for network 10.0.103.0/24. This subnet also deserves our attention. It is advertized on R3 under OSPF instance 1, it is located area 2 and redistributed on R3 from instance 1 to OSPF instance 2. And why does not R1 learn this route from R2 as inter-area route? What is more R1 has an inter-area host route to 10.0.103.1/32 received from R2. Be patient we shall talk about it later. Now let’s attend to R3. First let’s check what R3 thinks about itself after redistribution:

R3 R3#sh ip ospf border-routers OSPF Process 2 internal Routing Table Codes: i - Intra-area route, I - Inter-area route i 10.0.101.1 [1] via 10.0.1.1, FastEthernet0/0, ABR/ASBR, Area 1, SPF 4 I 10.0.103.1 [3] via 10.0.1.1, FastEthernet0/0, ASBR, Area 1, SPF 4 OSPF Process 1 internal Routing Table Codes: i - Intra-area route, I - Inter-area route I 10.0.100.3 [3] via 10.0.2.1, FastEthernet0/1, ASBR, Area 2, SPF 6 i 10.0.100.2 [1] via 10.0.2.1, FastEthernet0/1, ABR, Area 2, SPF 6 I 10.0.101.1 [2] via 10.0.2.1, FastEthernet0/1, ASBR, Area 2, SPF 6 R3#

So R3 indeed has become an ASBR.

Additional verification

Next let’s move to R2 and examine its route to 10.0.101.0/24. This is a loopback interface on R1 in area 3. Later when we shut down the link between R1 and R2 through area 0 we shall see if connectivity still exists.

R2 R2#sh ip route 10.0.101.1 Routing entry for 10.0.101.1/32 Known via "ospf 1", distance 110, metric 2, type inter area Last update from 10.0.0.1 on FastEthernet0/0, 01:22:45 ago Routing Descriptor Blocks: * 10.0.0.1, from 10.0.101.1, 01:22:45 ago, via FastEthernet0/0 Route metric is 2, traffic share count is 1 R2#

The route exists as a host route with next hop R1. One step more to verify connectivity through traceroute:

R2 R2#traceroute 10.0.101.1 Type escape sequence to abort. Tracing the route to 10.0.101.1 1 10.0.0.1 44 msec 44 msec * R2#

Everything is as expected. R2 reaches this network using its summary route through area 0.

Testing

Now we shut down the link between R1 and R2 to check, if R2 will reach the network through R3. Remember that R3 has no links in area 0.

R2#conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#int fa0/0 R2(config-if)#shut R2(config-if)#exit 01:59:49: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.101.1 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached 01:59:51: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down 01:59:52: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down

Under normal circumstances (as in my previous post) R2 should lose connectivity to 10.0.101.1. But is this the case?

R2 R2#sh ip route 10.0.101.1 Routing entry for 10.0.101.1/32 Known via "ospf 1", distance 110, metric 2, type extern 2, forward metric 1 Last update from 10.0.2.2 on FastEthernet0/1, 00:00:44 ago Routing Descriptor Blocks: * 10.0.2.2, from 10.0.103.1, 00:00:44 ago, via FastEthernet0/1 Route metric is 2, traffic share count is 1 R2#

R2 has installed an alternative route to the network. This is external, not an inter-area route. One final connectivity test by traceroute:

R2 R2#traceroute 10.0.101.1 Type escape sequence to abort. Tracing the route to 10.0.101.1 1 10.0.2.2 36 msec 52 msec 68 msec 2 10.0.1.1 144 msec 196 msec * R2#

That’s it! R2 is reaching the network through area 2, with next hop R3. The careful reader will see that we check connectivity to only one network. This is done not to conceal something but for the sake of simplicity. Indeed not all routes are present after R2 interface shutdown. This is R2 routing table before link shutdown with default route present:

R2 R2#sh ip route Gateway of last resort is 10.0.0.1 to network 0.0.0.0 10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks C 10.0.2.0/24 is directly connected, FastEthernet0/1 C 10.0.0.0/24 is directly connected, FastEthernet0/0 O IA 10.0.1.0/24 [110/2] via 10.0.0.1, 00:00:06, FastEthernet0/0 O 10.0.103.1/32 [110/2] via 10.0.2.2, 01:27:39, FastEthernet0/1 C 10.0.102.0/24 is directly connected, Loopback1 C 10.0.100.2/32 is directly connected, Loopback0 O E2 10.0.103.0/24 [110/1] via 10.0.0.1, 00:00:06, FastEthernet0/0 O IA 10.0.101.1/32 [110/2] via 10.0.0.1, 00:00:06, FastEthernet0/0 O 10.0.100.1/32 [110/2] via 10.0.0.1, 00:00:06, FastEthernet0/0 O*E2 0.0.0.0/0 [110/1] via 10.0.0.1, 00:00:06, FastEthernet0/0

And this is its routing table after the link went down:

R2 R2#sh ip route Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks C 10.0.2.0/24 is directly connected, FastEthernet0/1 O E2 10.0.0.0/24 [110/2] via 10.0.2.2, 00:00:00, FastEthernet0/1 O E2 10.0.1.0/24 [110/1] via 10.0.2.2, 00:00:49, FastEthernet0/1 O 10.0.103.1/32 [110/2] via 10.0.2.2, 01:30:04, FastEthernet0/1 C 10.0.102.0/24 is directly connected, Loopback1 C 10.0.100.2/32 is directly connected, Loopback0 O E2 10.0.101.1/32 [110/2] via 10.0.2.2, 00:00:49, FastEthernet0/1 O E2 10.0.100.1/32 [110/2] via 10.0.2.2, 00:00:49, FastEthernet0/1

The missing default route

One change is easily spotted: the default route has disappeared. To fix the problem we issue the following commands on R3:

R3#conf t

Enter configuration commands, one per line. End with CNTL/Z.

R3(config)#router ospf 1

R3(config-router)#default int

R3(config-router)#default-infor

R3(config-router)#default-information originate

R3(config-router)#exit

R3(config)#exit

R3#

And check R2 routing table again:

R2 R2#sh ip route Gateway of last resort is 10.0.2.2 to network 0.0.0.0 10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks C 10.0.2.0/24 is directly connected, FastEthernet0/1 O E2 10.0.0.0/24 [110/2] via 10.0.2.2, 00:55:18, FastEthernet0/1 O E2 10.0.1.0/24 [110/1] via 10.0.2.2, 00:55:18, FastEthernet0/1 O 10.0.103.1/32 [110/2] via 10.0.2.2, 00:55:18, FastEthernet0/1 C 10.0.102.0/24 is directly connected, Loopback1 C 10.0.100.2/32 is directly connected, Loopback0 O E2 10.0.101.1/32 [110/2] via 10.0.2.2, 00:55:18, FastEthernet0/1 O E2 10.0.100.1/32 [110/2] via 10.0.2.2, 00:55:18, FastEthernet0/1 O*E2 0.0.0.0/0 [110/1] via 10.0.2.2, 00:53:11, FastEthernet0/1

This time the default route is present, originated by R3.Technically the default route is an external route improted into the OSPF process on R1. R1 sends it as type -5 LSA to its neighbour R3. In OSPF only an ABR can propagate default information into attached areas. R3 is not an ABR so it cannot propagate the default route form area 1 into area 2. But being an ASBR R3 can originate a default route as long as it has one in its routing table (to prevent loops). R3 is originating type-5 LSA with advetizing router set to itself. When R1 receives this default route it will not install it because of its worse metric. If howerver R1 looses it external connection to Internet it will stop advetizing the default route (that will not happen in our test topology). R3 will be notified about this change and it will stop originating the default route as well. In this way no routing loop may occur.

Loopback interfaces revisited

And at last as promised we’ll be discussing the behavior of OSPF loopback interfaces and the problem with route to 10.0.103.0/24 network. A closer look at R2 routing table shows that after shutting down R2 interface to R1 the route to 10.0.103.0/24 network is not present (see above). The explaination lies in the behavior of OSPF loopback intefaces. I’ve mentioned about it in my previous post and won’t be discussing it any further. What is worth noting is that when redistributing loopback networks this behaviour changes. The network is not advertized as a

host route with 32 bit mask but as a true network with 24 bit mask. In this whay R2 has one intra-area host route for R3 loopback1 interface and one external E2 route for this same loopback interface with 24 bit mask. The external route is received from R1, which in turn gets it from R3 through redistribution from OSPF instance 1 into instance 2 (the network command for 10.0.103.0/24 is under instance 1). When R2 looses connectivity to R1 the external route is lost. To verify our conclusion we issue the following command:

R2#sh ip ospf database router 10.0.103.1 OSPF Router with ID (10.0.100.2) (Process ID 1) Router Link States (Area 2) Routing Bit Set on this LSA LS age: 857 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 10.0.103.1 Advertising Router: 10.0.103.1 LS Seq Number: 8000000B Checksum: 0x8220 Length: 48 AS Boundary Router Number of Links: 2 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.0.103.1 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metrics: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 10.0.2.2 (Link Data) Router Interface address: 10.0.2.2 Number of TOS metrics: 0 TOS 0 Metrics: 1 R2#

It displays the router link-state advertisements originated by R3 for area 2, OSPF instance 1. We see that indeed the loopback1 interface is advertized as stub network with 32 bit mask. To complete the investigation we check the external type5 LSA:

R2 R2#sh ip ospf database external 10.0.103.0 OSPF Router with ID (10.0.100.2) (Process ID 1) Type-5 AS External Link States Routing Bit Set on this LSA LS age: 570 Options: (No TOS-capability, DC) LS Type: AS External Link Link State ID: 10.0.103.0 (External Network Number ) Advertising Router: 10.0.100.3 LS Seq Number: 80000006 Checksum: 0xFFCB Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 1 Forward Address: 0.0.0.0 External Route Tag: 0 R2#

This time the loopback1 network is advertised as an external network with 24 bit mask. If we are curious we can check how R3 loopback1 interface is advertised in a summary LSA (type-3). We issue the following command on R1 which is getting the advertisement from R2 in area 0:

R1 R1#sh ip ospf database summary 10.0.103.1 OSPF Router with ID (10.0.101.1) (Process ID 1) Summary Net Link States (Area 0) Routing Bit Set on this LSA LS age: 1366 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 10.0.103.1 (summary Network Number) Advertising Router: 10.0.100.2 LS Seq Number: 80000003 Checksum: 0x76DF Length: 28 Network Mask: /32 TOS: 0 Metric: 2 Summary Net Link States (Area 1) LS age: 1914 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 10.0.103.1 (summary Network Number) Advertising Router: 10.0.101.1 LS Seq Number: 80000001 Checksum: 0x83D3 Length: 28 Network Mask: /32 TOS: 0 Metric: 3 Summary Net Link States (Area 3) LS age: 1928 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 10.0.103.1 (summary Network Number) Advertising Router: 10.0.101.1 LS Seq Number: 80000001 Checksum: 0x83D3 Length: 28 Network Mask: /32 TOS: 0 Metric: 3 R1#

R1 distributes the information it gets from R2 in area 0 into areas 1 and 3 as a host route again. For areas 2 and 3 the advertising router is changed to itself. So mind the different behavior of loopback interfaces when used in different types of LSAs. This example can be extended further by configuring area 1, 2 and 3 as not-so-stubby areas but the logic remains.