Skip to content

OSPF and inter-area links

September 18, 2011
By Administrator in All, Routing protocols

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

Network topology

Network topology

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.

Tags: , , ,

Comment Feed

No Responses (yet)



Some HTML is OK

or, reply to this post via trackback.