Default routing is very important feature and can be find in each network as last resort mechanism to route packets out of organization to unknow destination. Default origination has few configuration dependency on routing protocol and these will be presented in this post.

OSPF

Let’s start from the most popular IGP protocol. In OSPF default prefix (0/0) can be propagated in two different ways:

  • Explicitly with default-information originate
  • Stub Area Border Router (ABR)

To originated 0/0 explicitly we have to issue following command under OSPF process:

R1(config-router)#default-information originate

Once above command has been issued OSPF router will act as Autonomous System Boundary Router (ASBR). Default prefix will not appear in ASBR’s LS database and will not be originated to peers until 0/0 prefix exist in routing table.

To get default network in the routing table we have two options:

    Redistribute 0/0 from the another routing protocol (RIP, EIGRP, BGP)
    Add static route for 0/0

Default-information originate command has optional keyword – “always” which means originate 0/0 even if no default prefix in routing table exist.

By default network will be propagated as E2 type with metric 1, of course it can be adjusted using metric or metric-type command option.

The second way to originate default is to configure stub area, then ABR will generate 0/0. Please look at OSPF Area Types and LSA Propagation post for details here. Keep in mind that ABR router does not originated 0/0 to standard Not-So-Stubby (NSSA) area, default-information originate or no-summary keyword is needed then.

EIGRP

With EIGRP protocol we have 4 options to generate default route, via:

    network 0.0.0.0
    redistribution
    summarization
    ip default-network

First option is similar to OSPF. Default route needs to exist in routing table and then will be propagated once network 0.0.0.0 command is added under EIGRP process.

R1(config)#router eigrp 1
R1(config-router)# network 0.0.0.0
R1(config-router)#ip route 0.0.0.0 0.0.0.0 null 0

 

R2#sh ip route
Gateway of last resort is 10.0.12.1 to network 0.0.0.0
1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/409600] via 10.0.12.1, 00:06:32, FastEthernet0/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.12.0 is directly connected, FastEthernet0/0
D* 0.0.0.0/0 [90/281600] via 10.0.12.1, 00:05:51, FastEthernet0/0

R2 sees default route as EIGRP internal (AD=90) route with star. Star means default – last resort route will be used if no specific route exist to the specific destination.

Second option is to use redistribute command and take default based on static route or from another routing protocol.

R2#show ip route
Gateway of last resort is 10.0.12.1 to network 0.0.0.0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.12.0 is directly connected, FastEthernet0/0
D*EX 0.0.0.0/0 [170/281600] via 10.0.12.1, 00:00:07, FastEthernet0/0

In this case peers will see default as EIGRP external (AD=170) route with star.

Third option of default route generation is based on the summarization. In EIGRP routes’ summarization is done per interface. It’s very handy option and can be find just in EIGRP.

R1(config)#int fa0/0
R1(config-if)#ip summary-address eigrp 1 0.0.0.0 0.0.0.0

Peers will see default route as EIGRP internal (AD=90).

R2#sh ip route
Gateway of last resort is 10.0.12.1 to network 0.0.0.0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.12.0 is directly connected, FastEthernet0/0
D* 0.0.0.0/0 [90/307200] via 10.0.12.1, 00:00:15, FastEthernet0/0

The last option is using ip default-network command in global configuration mode; additionally prefix needs to be added under EIGRP process. Prefix needs to be classfull network. Of course local interface on router needs to exist and be in up state.

R1(config-if)#int lo1
R1(config-if)#ip add 1.0.0.1 255.0.0.0
R1(config-if)#router eigrp 1
R1(config-router)#network 1.0.0.0

R2#sh ip route
Gateway of last resort is not set
D* 1.0.0.0/8 [90/156160] via 10.0.12.1, 00:00:02, FastEthernet0/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.12.0 is directly connected, FastEthernet0/0

R2 sees 1.0.0.0 subnet as candidate default route and 10.0.12.1 peer will be used as default gateway.

RIP

With RIP protocol we have 4 options to generate default route, via:

  • network 0.0.0.0
  • default-information originate
  • redistribution
  • ip default-network

First option propagates default route without need to exist in routing table.

R1(config)#router rip
R1(config-router)#no auto
R1(config-router)#network 0.0.0.0

R2#sh ip route
Gateway of last resort is 10.0.12.1 to network 0.0.0.0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.12.0 is directly connected, FastEthernet0/0
R* 0.0.0.0/0 [120/1] via 10.0.12.1, 00:00:02, FastEthernet0/0

Second option is propagates default route the same like default-information originate always in OSPF – prefix does not need to exist in routing table.

R1(config)#router rip

R1(config-router)#version 2
R1(config-router)#no auto
R1(config-router)#network 10.0.0.0
R1(config-router)#default-information originate

R2#sh ip route>
Gateway of last resort is 10.0.12.1 to network 0.0.0.0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.12.0 is directly connected, FastEthernet0/0
R* 0.0.0.0/0 [120/1] via 10.0.12.1, 00:00:02, FastEthernet0/0

Third option is simply redistribution.

R1(config)#ip route 0.0.0.0 0.0.0.0 Null0
R1(config)#router rip
R1(config-router)# redistribute static metric 5

R2#sh ip route
Gateway of last resort is 10.0.12.1 to network 0.0.0.0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.12.0 is directly connected, FastEthernet0/0
R* 0.0.0.0/0 [120/5] via 10.0.12.1, 00:00:01, FastEthernet0/0

The last option is similar to ip default-network in EIGRP but interesting thing – does not need add classfull network under RIP configuration process.

R1(config)#int lo1
R1(config-if)# ip add 1.0.0.1 255.0.0.0
R1(config-if)# ip default-network 1.0.0.0

The output of show ip route command is also different – instead of classful network with star showing pure 0.0.0.0/0

R2#*Mar 10 23:39:27.912: RIP-DB: redist 0.0.0.0/0(metric 1, last interface FastEthernet0/0) to RIP
*Mar 10 23:39:27.912: RIP-DB: network_update with 0.0.0.0/0 succeeds
*Mar 10 23:39:27.912: RIP-DB: adding 0.0.0.0/0 (metric 1) via 10.0.12.1 on FastEthernet0/0 to RIP database
*Mar 10 23:39:27.912: RIP-DB: add 0.0.0.0/0 (metric 1) via 10.0.12.1 on FastEthernet0/0
*Mar 10 23:39:27.916: RIP-DB: Adding new rndb entry 0.0.0.0/0
*Mar 10 23:39:27.916: RIP-DB: Created rip ndb summary entry for 0.0.0.0/0
*Mar 10 23:39:27.916: RIP-DB: Adding new rndb entry 0.0.0.0/0
*Mar 10 23:39:31.113: RIP-DB: network_update with 0.0.0.0/0 succeeds
*Mar 10 23:39:31.113: RIP-DB: adding 0.0.0.0/0 (metric 1) via 10.0.12.1 on FastEthernet0/0 to RIP database

R2#sh ip route
Gateway of last resort is 10.0.12.1 to network 0.0.0.0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.12.0 is directly connected, FastEthernet0/0
R* 0.0.0.0/0 [120/1] via 10.0.12.1, 00:00:06, FastEthernet0/0

BGP

We have covered all IGP protocols. Let’s take a closer look at BGP.

With BGP protocol we have 3 options to generate default route, via:

    default-information originate
    network 0.0.0.0
    default-originate to specific neighbor

First option is similar to OSPF and EIGRP but with one difference. Besides 0/0 needs to exist in routing table additionally has to be redistributed to BGP routing from static or any other dynamic routing protocol. Just one important note – 0/0 prefix is not visible in BGP table until default-information originate command will be issued, strange but true. Let’s test it.

R1(config)#ip route 0.0.0.0 0.0.0.0 Null0
R1(config)#ip route 2.2.2.2 255.255.255.255 Null0
R1(config)#router bgp 1
R1(config-router)# redistribute static
R1(config-router)#exit
R1#sh ip route
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
2.0.0.0/32 is subnetted, 1 subnets
S 2.2.2.2 is directly connected, Null0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.12.0 is directly connected, FastEthernet0/0
S* 0.0.0.0/0 is directly connected, Null0

R1#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 0.0.0.0 0 32768 ?

As you can see no 0/0 prefix in BGP table, let’s add key command.

R1(config)#router bgp 1

R1(config-router)#default-information originate

R1(config-router)#do sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 0.0.0.0 0 32768 ?
*> 2.2.2.2/32 0.0.0.0 0 32768 ?

Here we are! Confirmed that R2 is getting route.

R2#sh ip route
Gateway of last resort is 10.0.12.1 to network 0.0.0.0
2.0.0.0/32 is subnetted, 1 subnets
B 2.2.2.2 [200/0] via 10.0.12.1, 00:00:19
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.12.0 is directly connected, FastEthernet0/0
B* 0.0.0.0/0 [200/0] via 10.0.12.1, 00:00:05

Second option, use of network 0.0.0.0 under BGP requires 0/0 prefix in routing table too – the same like with first one but network command assure existence default network in the BGP table and propagation to all neighbors, so no need to redistribute into BGP table.

R1(config)#router bgp 1
R1(config-router)#network 0.0.0.0
R1(config-router)#ip route 0.0.0.0 0.0.0.0 null 0

R2#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i0.0.0.0 10.0.12.1 0 100 0 i
R2#sh ip route
Gateway of last resort is 10.0.12.1 to network 0.0.0.0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.12.0 is directly connected, FastEthernet0/0
B* 0.0.0.0/0 [200/0] via 10.0.12.1, 00:01:08

Third option is usfull and allows to select to which neighbors to send 0/0 prefix without need of filtering. This option does not need to have 0/0 in routing table to originate default.

R1(config)#router bgp 1
R1(config-router)# neighbor 10.0.12.2 default-originate
R2#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i0.0.0.0 10.0.12.1 0 100 0 i

As you see there is some dependency in default route generation. It’s good to know it.

, , , ,

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
,

Attributes that have to match to successful establish FULL neighbor adjacency

  1. Area ID
  2. Authentication
  3. Subnet/Subnet Mask
  4. Hello/Dead Interval
  5. Stub area flag

 Note: FULL neighbor adjacency state doesn’t mean that LS exchange will take place. There is one additional condition that needs to be met. You can mix network types until they will match DR/BDR election process. So you can mix broadcast and non-broadcast because both network types require DR/BDR election but once you mix broadcast with p2p adjacency will come up but LS exchange will not take place.

Network Type DR H/D Hello Next Hop
broadcast + 10/40 224.0.0.5 ADV R = Originator
non-broadcast + 30/120 unicast ADV R = Originator
point-to-point 10/40 224.0.0.5 connected neighbor
point-to-multipoint 30/120 224.0.0.5 connected neighbor
point-to-multipoint non-broadcast 30/120 unicast connected neighbor

 Multicast IPs

AllSPFRouters – 224.0.0.5 (0100.5e00.0005)

AllDRouters – 224.0.0.6 (0100.5e00.0006)

Router ID Election

  1. Router-id command
  2. Highest IP address on loopback interface
  3. Highest IP address on other interfaces

 DR, BDR Election

  1. The highest priority (255 highest, 0 doesn’t take part in election process)
  2. If tie, highest Router ID

DRothers – established adjacency only with DR, BDR, between DRothers<>DRothers is 2WAY/DRothers

 Interface State Machine

  • Down
  • P2P
  • Waiting
  • DR
  • Backup
  • DRothers
  • Loopback

 Neighbor State Machine

  • Down
  • Attempt (only on NBMA where neighbors are manually configured)
  • Init – Hello has been received but router does not see its own RID in the hello yet
  • 2-Way – router has seen its own RID in the neighbor’s field hello packet (bidirectional)
  • ExStart – neighbor establish master/slave relationship and determine the initial DBD seq number, router with highest RID is master
  • Exchange – router sends DBD packets describing its entire LSDB (LSA Headers), may sends LS Request, requesting more recent LSAs to neighbors
  • Loading – router sends LS Request, requesting more recent LSAs that have been discovered in the Exchange state but have not been received
  • Full – neighbors are fully adjacent

 Building an Adjacency

  • Hello (type 1)
  • DBD (type 2)
    • Just description of LSAs (header is sent)
      • receiving router decides whether it has the latest copy of the LSA in its own DB
    • Flag is sent
      • I bit – first DBD packet sent
      • M bit (more bit) – not last DBD packet, will be more
      • MS bit (Master/Slave bit) – set in DBD packet originated by the Master
      • LS Request (type 3)
      • LS Update (type 4)

 Exstart and Exchange process

  1. Both neighbors claim to me the master
    • sending DD with MS bit set to 1
    • own random strange DB sequence number
  2. Router with lower RID will be slave and replay with DD
    • MS bit = 0
    • DD sequence number set to master’s sequence number
    • Its first (I bit) packet with LSA summaries
  3. Exstart process completed
  4. Exchange process starts
  5. If neighbor (router A) receives LSA that
    • Is not in its own database
    • Or remote neighbor has a more recent copy of known LS
    • The router A place the LSA on the Link State Request List
  6. Router A sends LS Request packet asking for complete copy of the LSA from the List
  7. Remote B router sends LSA Update and adds LSA on Link State Retransmission list
  8. Router A sends back LS ACK acknowledged LSA that received
  9. Router B removes acknowledged LSA from the Link State Retransmission list
  10. Next state
    • If A or B have still entries in Link State Request List > Loading state (Master sends M bit set to zero, Slave ACK with the same sync number and M bit zero)
  11. If A or B have no entries in Link State Request List > Full state

Master controls synchronization process and ensure that only one DD packet is outstanding at a time.

When slave receives DD packet, acknowledges the packet by sending a DD packet with the same sequence number.

If master does not receive acknowledgement within Retransmission Interval, then sends new copy.

Sequence Number – all routers must have an identical sequence number

Age

  • Starts from 1
  • MaxAgeDiff – Maximum Age Difference (15 minutes)
  • Router receives multiple copies of the same LSA with identical Sequence Number but with different age
  • If difference in the age < MaxAgeDiff – original LSA is retained (no flooding)
  • If difference in the age > MaxAgeDiff – new LSA recorded and flooded
  • MaxAge – (60 minutes/3600 sec) – after this time LSA is flushed out from LSD
  • LSARefreshTime (30 minutes/1800 sec) – flooding all LSA to reset MaxAge

Area notation example

Area 271 = Area 0.0.1.15  = 00000000.00000000.00000001.00001111=100001111=271

LSA Types

LSA 1 – O, Router LSA (contain all Link IDs – network),

  • Generated by every router and is local to the area
  • Describes all router interfaces + cost
  • “Routing bit set on this LSA” means that the route to this destination is in RIB
  • show ip ospf database router <router-id>

LSA 2 – O, Network LSA (contain all routers attached to the segment)

  • Generated by DR and is local to the area
  • Lists all attached routers (router ID) including DR
  • show ip ospf database network <IP address of DR>

LSA 3 – O IA, Network Summary LSA (describes network from another Area)

  • Generated by ABR and is propagated between areas
  • Include cost from ABR to network
  • show ip ospf database summary <network_IP>

 LSA 4 – O IA, Summary ASB Link States

  • Generated by the ABR and is propagated between areas
  • Describes RID of the ASBR
  • show ip ospf database asbr-summary

 LSA 5 – O E1, O E2, External Link States

  • Generated by ASBR and is propagated between areas
  • Describes links that are external to the AS
  • show ip ospf database external
  • E1 cost consist of:
    • External metric > show ip ospf database external <Link state ID>
    • Metric to ASBR (Advertising Router=RID) > show ip ospf border-routers
  • E2 cost = External metric > show ip ospf database external <Link state ID>

LSA 7 – O N1, O N2, NSSA External Link States

  • Generated by ASBR into Not-So-Stubby (NSSA) area
  • Describes links that are external to the AS in the NSSA area
  • ABR swap the LSA type 7 to LSA type 5 when sends from NSSA into Area 0
  • show ip ospf database nssa-external
  • N1 cost consist of:
    • External metric show ip ospf database nssa-external <Link state ID>
    • Metric to ASBR (Advertising Router=RID) > show ip ospf border-routers
  • N2 cost = External metric > show ip ospf database nssa-external <Link state ID>

Route selection proces based on the LSA type

O>O IA>O E1>O E2>O N1>O N2