Today I would like to show you strange OSPF ABR’s behaviour that denies the OSPF algorithm. Simple LSA filtering to routing table on ABR can break the LSA propagation to non-zero area.

First, let’s briefly recall the basic rules and operations of OSPF.

  • Adjacencies – routers exchange hello packets and establish neighbor adjacency.
  • Link-state advertisements – routers exchange LSAs that describe all of the router’s known links.
  • Link-state databes synchronization – by flooding LSAs throughout an area, all routers build identical link-state databases.
  • Building routing table based on SPF tree – once the databases are complete, routers run the SPF algorithm to calculate a loop-free topology describing the shortest path to every destination. Routing table is build based on the SPF tree.

After all link-state details have been flooded to all neighbors in an area and all have verified that their databases are identicalthat then the link-state databases have been synchronized and the route tables have been built.

Here I would to closer look at the ABR router, his function and operation.

Area Border Routers (ABRs) connect one or more areas to the backbone and works as a gateway for inter-area traffic. An ABR always has at least one interface that belongs to the backbone and maintain a separate link-state database for each connected areas.

Network Summary LSAs are originated by ABRs. They are sent into a single area to advertise destinations outside that area. ABR tells the internal routers of an attached area what destinations the ABR can reach. An ABR also advertises the destinations within its attached areas into the backbone with Network Summary LSAs

Once the ABR’s function and operation has been described let’s configure simple OSPF architecture with four routers which two are ABRs based on the below topology.

R1’s loopback has been added to Area 1. R2 and R3 are ABRs.
Let’s see how the R3 LS database looks like:

R3#sh ip ospf database
OSPF Router with ID (3.3.3.3) (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 1033 0x80000006 0x00CFFD 1
3.3.3.3 3.3.3.3 1270 0x80000005 0x009332 1
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.0.23.2 2.2.2.2 1292 0x80000003 0x00A553
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
1.1.1.1 2.2.2.2 1033 0x80000003 0x00899A
10.0.12.0 2.2.2.2 1033 0x80000007 0x009E70
10.0.34.0 3.3.3.3 1020 0x80000005 0x009165
Router Link States (Area 34)
Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 1020 0x80000004 0x00921D 1
4.4.4.4 4.4.4.4 937 0x80000004 0x005156 1
Net Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
10.0.34.3 3.3.3.3 1021 0x80000003 0x005888
Summary Net Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
1.1.1.1 3.3.3.3 1800 0x80000001 0x00D344
10.0.12.0 3.3.3.3 1021 0x80000003 0x00EC18
10.0.23.0 3.3.3.3 1271 0x80000003 0x000FF4


R4 gets 1.1.1.1/32 subnet as expected:

R4#sh ip ospf database summary 1.1.1.1
OSPF Router with ID (4.4.4.4) (Process ID 1)
Summary Net Link States (Area 34)
Routing Bit Set on this LSA
LS age: 1324
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 1.1.1.1 (summary Network Number)
Advertising Router: 3.3.3.3
LS Seq Number: 80000001
Checksum: 0xD344
Length: 28
Network Mask: /32
TOS: 0 Metric: 21
R4#sh ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "ospf 1", distance 110, metric 31, type inter area
Last update from 10.0.34.3 on FastEthernet0/0, 00:22:15 ago
Routing Descriptor Blocks:
* 10.0.34.3, from 3.3.3.3, 00:22:15 ago, via FastEthernet0/0
Route metric is 31, traffic share count is 1

OK let’s move to the LSA filtering to routing table on ABR router.

We have following options to filter out LSA from LSA database to routing table:

  • Distance with 255 administrative distance
  • Distribute list
  • Static route to null0 (route will appear in RT but effect will be the same like above – drop packets

First let’s take a look at R2 ABR and apply filtering option with distribute list to filter out the 1.1.1.1 subnet from the routing table.

R2(config)#access-list 2 deny 1.1.1.1
R2(config)#access-list 2 permit any
R2(config)#router ospf 1
R2(config-router)#distribute-list 2 in FastEthernet0/1

To confirm that 1.1.1.1 still appears as LSA3 in LSA DB on R2.

R2#show ip ospf database summary 1.1.1.1
OSPF Router with ID (2.2.2.2) (Process ID 1)
Summary Net Link States (Area 0)
LS age: 763
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 1.1.1.1 (summary Network Number)
Advertising Router: 2.2.2.2
LS Seq Number: 8000000C
Checksum: 0x77A3
Length: 28
Network Mask: /32
TOS: 0 Metric: 11

To confirm that 1.1.1.1 has been withdrawn from the routing table on the R2.

R2#sh ip route 1.1.1.1
% Network not in table

To confirm that 1.1.1.1 still appears as LSA3 in LSA DB on R3:

R3#show ip ospf database summary 1.1.1.1
OSPF Router with ID (3.3.3.3) (Process ID 1)
Summary Net Link States (Area 0)
Routing Bit Set on this LSA
LS age: 939
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 1.1.1.1 (summary Network Number)
Advertising Router: 2.2.2.2
LS Seq Number: 8000000C
Checksum: 0x77A3
Length: 28
Network Mask: /32
TOS: 0 Metric: 11
Summary Net Link States (Area 34)
LS age: 4
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 1.1.1.1 (summary Network Number)
Advertising Router: 3.3.3.3
LS Seq Number: 80000001
Checksum: 0xD344
Length: 28
Network Mask: /32
TOS: 0 Metric: 21

To confirm that 1.1.1.1 still appears in R3 and R4 routing table.

R3#sh ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "ospf 1", distance 110, metric 21, type inter area
Last update from 10.0.23.2 on FastEthernet0/1, 01:09:07 ago
Routing Descriptor Blocks:
* 10.0.23.2, from 2.2.2.2, 01:09:07 ago, via FastEthernet0/1
Route metric is 21, traffic share count is 1

R4#sh ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "ospf 1", distance 110, metric 31, type inter area
Last update from 10.0.34.3 on FastEthernet0/0, 01:08:45 ago
Routing Descriptor Blocks:
* 10.0.34.3, from 3.3.3.3, 01:08:45 ago, via FastEthernet0/0
Route metric is 31, traffic share count is 1

OK, all is working as expected. Let’s apply the same filtering rule on the R3 and see the diference.

R3(config)#access-list 2 deny 1.1.1.1
R3(config)#access-list 2 permit any
R3(config)#router ospf 1
R3(config-router)#distribute-list 2 in FastEthernet0/1

Routing table on R3 as expected, 1.1.1.1 has been withdrawn.

R3#sh ip route 1.1.1.1
% Network not in table

What about LSA database?

R3#show ip ospf database summary 1.1.1.1
OSPF Router with ID (3.3.3.3) (Process ID 1)
Summary Net Link States (Area 0)
Routing Bit Set on this LSA
LS age: 916
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 1.1.1.1 (summary Network Number)
Advertising Router: 2.2.2.2
LS Seq Number: 8000000C
Checksum: 0x77A3
Length: 28
Network Mask: /32
TOS: 0 Metric: 11

1.1.1.1 still appears for Area 0 as expected but what about Area34? Routes has been withdrawn from the Area34. What about R4, does it mean that R4 will not get this route anymore?

Let’s see the routing table and LSA database on R4.

R4#sh ip route 1.1.1.1
% Network not in table
R4#show ip ospf database summary 1.1.1.1
OSPF Router with ID (4.4.4.4) (Process ID 1)

Exactly, link has been withdrawn from LS database for area 34 on R4 once we applied LS filtering to the routing table on R3, good to know ;).

Let’s change the filtering option on R3 from distribute list to static route to null0.

R3(config)#router ospf 1
R3(config-router)#no distribute-list 2 in FastEthernet0/1
R3(config-router)#ip route 1.1.1.1 255.255.255.255 null 0

Let’s see what we have on R4 now:
R4#sh ip route 1.1.1.1
% Network not in table
R4#show ip ospf database summary 1.1.1.1
OSPF Router with ID (4.4.4.4) (Process ID 1)

OK so even if 1.1.1.1 exist in the routing table but is prefered by the non OSPF protocol (in this case by static) is not advertised by the ABR from area 0 to non-zero area.

Conclusion – OSPF ABR that doing LSAs propagation from the Area 0 to to non-zero area advertised to non-zero area only these LSAs that exist in the routing table and are marked as OSPF prefered routing protocol.

Let me know if you find about it in any OSPF RFC or Cisco documentation :).
Thanks to Narbik for mentoring.

, ,

The idea of this post is to show the LSA propagation manner depending on area type.

OSPF routing protocol has hierarchical network topology that use concept of area. OSPF area reduces the protocol’s impact on CPU and memory. Resources can be saved by blocking the propagation of some type of LSA to specific areas. Lets recall the LSA types to see how they are propagated between areas.

LSA Types

  • LSA 1 – O, Router LSA contains all Link IDs – network, generated by every router and is local to the area
  • LSA 2 – O, Network LSA contains all routers attached to the segment, generated by DR and is local to the area
  • LSA 3 – O IA, Network Summary LSA describes network from another area, generated by ABR and is propagated between areas
  • LSA 4 – O IA, Summary ABR Link States, describes the presence of an ASBR, generated by the ABR and is propagated between areas
  • LSA 5 – O E1, O E2, External Link States, generated by ASBR and is propagated between areas
  • LSA 7 – O N1, O N2, NSSA External Link States, generated by ASBR into NSSA area and is propagated into area 0 as E1 or E2

Knowing the LSA types we have to state one important OSPF protocol rule that allows devides entire OSPF domain to smaler areas. A OSPF router must share an identical link-state database only with the other routers in its area, not with the entire OSPF domain. Does it mean for example that internal router in area 2 does not need to know about LSA generated by the internal router in area 1 or by ASBR in area 3 that redistributes routes from another routing domain.

Basically OSPF area types can be devided into three types: Normal/Standard Area, Stub Area and Not-So-Stubby. The difference is that Standard gets all LSA types but Stub and Not-So-Stubby Areas have some LSA limitation. It’s worth to mention that OSPF have few variations of Stub and Not-So-Stubby. Below you can find OSPF domain diagram that shows which LSA type is or is not propagated into specific area type and explanation of each area type.

Here you are the basic keyword and rule that help you understand the concept:

Words “Totally Stubby” = “no-summary” keyword in the area type command definition = no LSA Type 3,4 and 5 propagation into area instead ABR produce default route as Intra Area LSA (O*IA 0.0.0.0/0) into Totally Stubby Area.

 

 

Stub Area – area <area> stub

Allows propagation of LSA type 1,2 and 3  additionally with default route as Intra Area LSA format (O*IA 0.0.0.0/0)

Blocks propagation of LSA type 4 and 5

  • Stub area can not be a transit area for Virtual link, but a GRE tunnel can be used instead
  • Stub area can not have an ASBR
  • The Backbone area can not be configured as a Stub area
  • No LSA type 4 and 5 (E1 or E2) is allowed in a Stub area, but the routers in the Stub Area can connect to the External routes via the default route that is injected into the area by the ABR
  • Every router and the ABR of that area should have “area <area> stub” command
  • By default, the cost of the default route is 1
  • The cost of the default route can be changed by “area <area> default-cost <cost>”

Totally Stubby – area <area> stub no-summary  

Allows propagation of LSA type 1 and 2 additionally with default route as Intra Area LSA format (O*IA 0.0.0.0/0)

Blocks propagation of LSA type 3,4 and 5

  • This area has the same features as standard Stub Area
  • Only ABR has to be configured with the “no-summary” keyword in area definition
  • Intra area routers in the Totally Stubby area should have “area <area> stub” command only

Not-So-Stubby – area <area> nssa

Allows propagation of LSA 1, 2, 3 and 7

Blocks propagation of LSA type 3,4 and 5, no default route

  • All Intra Area routers in the Not-So-Stubby area should have “area <area> nssa” configured
  • Not-So-Stubby area can not be a transit area for Virtual link, but a GRE tunnel can be used instead
  • No LSA type 3,4 and 5 (E1 or E2) is allowed in a Not-So-Stubby area, but external routes can be injected into area and appear as LSA type 7, then translated on the ABR to LSA type 5
  • Not-So-Stubby area can have an ASBR
  • The backbone area can not be configured as a Not-So-Stubby area

Totally Stubby Not-So-Stubby – area <area> nssa no-summary

Allows propagation of LSA 1 and 2 additionally with default route as Intra Area LSA format (O*IA 0.0.0.0/0)

Blocks propagation of LSA type 3,4 and 5

  • This area has the same features as standard Not-So-Stubby the only one difference is that default route as Intra Area LSA format (O*IA 0.0.0.0/0) is produced

Not-So-Stubby – area <area> nssa default-information-originate

Allows propagation of LSA type 1, 2, 3 and 7 additionally with default route as LSA type 7 Eternal 2  LSA format (O*N2 0.0.0.0/0)

Blocks propagation of LSA type 4 and 5

  • This area has the same features as standard Not-So-Stubby the only one difference is that default route as LSA type 7 Eternal 2  LSA format (O*N2 0.0.0.0/0) is produced

Totally Stubby Not-So-Stubby – area <area> nssa no-summary no-redistribution

Allows propagation of LSA 1 and 2 additionally with default route as Intra Area LSA format (O*IA 0.0.0.0/0)

Blocks propagation of LSA type 3,4 and 5

  • This area has the same features as standard Not-So-Stubby the only one difference is that prefixes that have been redistributed on the ABR will not be propagated into area
,