JNCIP-SP: OSPF stub and totally stubby area.

This part is about the configuration and verification of a stub area in OSPF. Before the actual configuration, I will briefly touch the theory behind a stub area, the configure and verify one. I will finish things up with the configuration and verification of a totally stubby area.



Stub areas.

A stub area is an OSPF area that is void of any External LSAs. The ABR connected to the stub area will not advertise and distribute this LSA type into the stub area. As a result, the LSDB inside a stub area can be reduced. This will lead to a reduced memory requirement for routers in that area as well as OSPF calculations taking up less processing by routers in the stub area.



scenario


The example above shows the backbone area on the left. All the External, ASBR-Summary and Summary LSAs area flooded through this area (together of course with that area’s Router-LSAs). R11, which is the ABR to the stub area shown on the right, will not flood all the LSAs into the stub area. External LSAs will not be send into the stub area. Because the area will not contain any External LSAs, knowing the location of an ASBR is not necessary anymore. Consequently, type 4 ASBR Summary LSAs are not send into the stub area either.

As an alternative to knowing all the External LSAs, you can have the ABR connected to the stub area advertise a default route into the stub. By injecting a default route into the stub area, you can make sure that the stub routers have reachability to all prefixes contained in the External LSAs. By default, Junos does not inject a default route into a stub area. This has to be configured on the ABR.

Stub areas come with several rules:
    • the backbone cannot be a stub area (for obvious reasons)
    • stub areas cannot inject External LSAs. This means there can be no ASBR’s located in a stub area
    • a virtual-link cannot traverse a stub area
    • a stub area cannot be a not-so-stubby area at the same time
    • the stub area will only contain type 1, 2 and 3 LSAs



The stub area configuration.

I will expand the lab with R8. R8 will be situated in area 250 and R11 will be the ABR for this stub area;



scenario


The configuration necessary to expand the lab with this additional area is as follows;

R8:
 
set interfaces xe-0/0/3 unit 30 description R11
set interfaces xe-0/0/3 unit 30 vlan-id 30
set interfaces xe-0/0/3 unit 30 family inet address 18.0.0.1/30

set protocols ospf area 0.0.0.250 stub
set protocols ospf area 0.0.0.250 interface lo0.8 interface-type p2p
set protocols ospf area 0.0.0.250 interface lo0.8 passive
set protocols ospf area 0.0.0.250 interface xe-0/0/3.30 interface-type p2p
set protocols ospf area 0.0.0.250 interface xe-0/0/3.30 authentication md5 111 key "$9$ZAjH.Qzn69t1Rv8X-sY"
                
R11:
 
set interfaces xe-0/3/1 unit 30 description R8
set interfaces xe-0/3/1 unit 30 vlan-id 30
set interfaces xe-0/3/1 unit 30 family inet address 18.0.0.2/30

set protocols ospf area 0.0.0.250 stub
set protocols ospf area 0.0.0.250 interface xe-0/3/1.30 interface-type p2p
set protocols ospf area 0.0.0.250 interface xe-0/3/1.30 authentication md5 111 key "$9$ZAjH.Qzn69t1Rv8X-sY"
                

To verify the configuration, there are a number of places you could decide to look. For instance:

 
play@MX80:R8> show ospf interface detail
Interface           State   Area            DR ID           BDR ID          Nbrs
lo0.8               PtToPt  0.0.0.250       0.0.0.0         0.0.0.0            0
  Type: P2P, Address: 1.1.1.8, Mask: 255.255.255.255, MTU: 65535, Cost: 0
  Adj count: 0, Passive
  Hello: 10, Dead: 40, ReXmit: 5, Stub
  Auth type: None
  Protection type: None
  Topology default (ID 0) -> Passive, Cost: 0
xe-0/0/3.30         PtToPt  0.0.0.250       0.0.0.0         0.0.0.0            1
  Type: P2P, Address: 18.0.0.1, Mask: 255.255.255.252, MTU: 8978, Cost: 1
  Adj count: 1
  Hello: 10, Dead: 40, ReXmit: 5, Stub
  Auth type: MD5, Active key ID: 111, Start time: 1970 Jan  1 00:00:00 UTC
  Protection type: None
  Topology default (ID 0) -> Cost: 1
                

The ‘show ospf interface’ will show the type of area the interface is active is. The output above tells us that both R8 interfaces area active in the stub area, and that we have a neighbor on xe-0/0/3.30. Another place to verify the ospf area types a router is active in is the following;

 
play@MX480-TEST:R11> show ospf overview
Instance: master
  Router ID: 1.1.1.11
  Route table index: 5
  Area border router, AS boundary router
  LSA refresh time: 50 minutes
  DoNotAge uncapable
    AS scope LSAs received with no DC bit: 1
    Area scope LSAs received with no DC bit: 17
  Area: 0.0.0.0
    Stub type: Not Stub
    Authentication Type: None
    Area border routers: 3, AS boundary routers: 3
    Neighbors
      Up (in full state): 3
    DoNotAge uncapable
      Area scope LSAs received with no DC bit: 17
  Area: 0.0.0.50
    Stub type: Not Stub, Virtual transit
    Authentication Type: None
    Area border routers: 1, AS boundary routers: 1
    Neighbors
      Up (in full state): 1
    DoNotAge uncapable
      Self Indication
  Area: 0.0.0.250
    Stub type: Stub
    Authentication Type: None
    Area border routers: 0, AS boundary routers: 0
    Neighbors
      Up (in full state): 1
  Topology: default (ID 0)
    Prefix export count: 1
    Full SPF runs: 324
    SPF delay: 0.200000 sec, SPF holddown: 5 sec, SPF rapid runs: 3
    Backup SPF: Not Needed

                

The above output show us, in 1 overview, the area’s in which R11 is active. Here we can also see that area 250 is a stub and that R11 has a neighbor in the area.

Let’s have a look at the OSPF database on R8;

 
play@MX80:R8> show ospf database

    OSPF database, Area 0.0.0.250
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router  *1.1.1.8          1.1.1.8          0x80000003  2535  0x20 0x6a57  60
Router   1.1.1.11         1.1.1.11         0x80000004  2540  0x20 0xece9  48
Summary  1.1.1.3          1.1.1.11         0x80000003  1012  0x20 0x2501  28
Summary  1.1.1.4          1.1.1.11         0x80000003   972  0x20 0x1115  28
Summary  1.1.1.6          1.1.1.11         0x80000003   932  0x20 0x1111  28
Summary  1.1.1.11         1.1.1.11         0x80000003   892  0x20 0xb66a  28
Summary  1.1.1.12         1.1.1.11         0x80000003   852  0x20 0xc05d  28
..
…
..
Summary  190.0.0.1        1.1.1.11         0x80000002  2814  0x20 0xa5c8  28
Summary  190.0.0.2        1.1.1.11         0x80000002  2774  0x20 0x9bd1  28
                

I removed some output since the database is growing quite large, but the effects of the stub area are clearly visible.

Observe the following output:

 
play@MX480-TEST:R11> show ospf database external lsa-id 201.0.0.0 extensive
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Extern   201.0.0.0        1.1.1.3          0x8000016a   811  0x22 0xb2c8  36
  mask 255.255.252.0
  Topology default (ID 0)
    Type: 2, Metric: 0, Fwd addr: 0.0.0.0, Tag: 0.0.0.0
  Aging timer 00:46:29
  Installed 00:13:22 ago, expires in 00:46:29, sent 00:13:20 ago
  Last changed 3d 01:33:28 ago, Change count: 3

play@MX480-TEST:R11> ping 201.0.1.1
PING 201.0.1.1 (201.0.1.1): 56 data bytes
64 bytes from 201.0.1.1: icmp_seq=0 ttl=61 time=0.632 ms
64 bytes from 201.0.1.1: icmp_seq=1 ttl=61 time=0.657 ms
^C
--- 201.0.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.632/0.645/0.657/0.012 ms

play@MX480-TEST:R11>
                

The output from R11 is showing one of the External LSAs and the fact that we can ping to and fro an IP address that is within this range. Let’s see what happened on R8 when we issue a ping towards the same address;

 
play@MX80:R8> ping 201.0.1.1
PING 201.0.1.1 (201.0.1.1): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
^C
--- 201.0.1.1 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss

play@MX80:R8> show route 201.0.1.1

play@MX80:R8>
                

As explained earlier, there is no known route towards the destination because the External LSAs are not flooded into the area. Let fix the connectivity between R8 and this prefix by having R11, the ABR to this stub area, generate a default route;

 
play@MX480-TEST:R11> show route 0.0.0.0

play@MX480-TEST:R11> show ospf database advertising-router self area 0.0.0.250 lsa-id 0.0.0.0 extensive

play@MX480-TEST:R11> configure
Entering configuration mode

[edit]
play@MX480-TEST:R11# set protocols ospf area 0.0.0.250 stub default-metric 20

[edit]
play@MX480-TEST:R11# commit and-quit
commit complete
Exiting configuration mode

play@MX480-TEST:R11> show ospf database advertising-router self area 0.0.0.250 lsa-id 0.0.0.0 extensive

    OSPF database, Area 0.0.0.250
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Summary *0.0.0.0          1.1.1.11         0x80000001     8  0x20 0x1607  28
  mask 0.0.0.0
  Topology default (ID 0) -> Metric: 20
  Gen timer 00:49:51
  Aging timer 00:59:51
  Installed 00:00:08 ago, expires in 00:59:52, sent 00:00:08 ago
  Last changed 00:00:08 ago, Change count: 1, Ours

play@MX480-TEST:R11>
                

The above output is showing that R11 does not have any default route, nor is it advertising any default route towards area 0.0.0.250. To distribute a default route into area 0.0.0.250, the command 'set protocols ospf area 0.0.0.250 stub default-metric 20' was used. The last command verifies that R11, without having a default route itself, is now advertising one into area 0.0.0.250.

On R8 we can now observe the following:

 
play@MX80:R8> show ospf database lsa-id 0.0.0.0 extensive

    OSPF database, Area 0.0.0.250
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Summary  0.0.0.0          1.1.1.11         0x80000001   267  0x20 0x1607  28
  mask 0.0.0.0
  Topology default (ID 0) -> Metric: 20
  Aging timer 00:55:32
  Installed 00:04:26 ago, expires in 00:55:33
  Last changed 00:04:26 ago, Change count: 1

play@MX80:R8> show route 0.0.0.0

inet.0: 46 destinations, 47 routes (46 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[OSPF/10] 00:04:29, metric 21
                    > to 18.0.0.2 via xe-0/0/3.30

play@MX80:R8> ping 201.0.1.1
PING 201.0.1.1 (201.0.1.1): 56 data bytes
64 bytes from 201.0.1.1: icmp_seq=0 ttl=60 time=1.032 ms
64 bytes from 201.0.1.1: icmp_seq=1 ttl=60 time=0.636 ms
^C
--- 201.0.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.636/0.834/1.032/0.198 ms

play@MX80:R8>
                

R8 received a default route and can now ping to and fro 201.0.1.1 using the default route.



Totally stubby area.

To further reduce the size of the LSDB, we can turn area 0.0.0.250 into a totally stubby area. The following picture explains the concept:



scenario


The difference between a stub and a totally stubby area is that only 1 Summary LSAs is allowed into the area. Instead of finding all the Summary LSAs in the LSDB, the only Summary LSA permitted is one that contains a default route.

We can turn area 0.0.0.250 into a totally stubby area by issuing the following configuration command on R11:

 
set protocols ospf area 0.0.0.250 stub no-summaries
                

Moving over to R8, we can now see that OSPF database has shrunk significantly:

 
play@MX80:R8> show ospf database

    OSPF database, Area 0.0.0.250
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router  *1.1.1.8          1.1.1.8          0x8000000f   205  0x20 0x5263  60
Router   1.1.1.11         1.1.1.11         0x8000000c   201  0x20 0xdcf1  48
Summary  0.0.0.0          1.1.1.11         0x80000001   206  0x20 0x1607  28

play@MX80:R8>

                

Hopefully this clarifies things.

9-10-2014