VPN: DEEP Dive into GRE Tunnel configuration over OSPF, explanation of behaviors and how to overcome them!

OSPF_GRE_Over_IPSec

Now I’ve spent hours and hours trying to figure GRE out, this was not included in my CCNP ROUTE material except for some DMVPN using mGRE, however I did want to know for practical purposes how to encapsulate broadcast / multicast traffic over an IPSec tunnel which in turn needs a GRE tunnel as there is none.

Now GRE is not a LAN-to-LAN (L2L) tunnel as I had expected it to be, so I spent hours trying to figure out why it showed as Up / Up and debugs showed packet encapsulation and decapsulation, but my traceroutes would NOT take the tunnel interface!

After mentioned hours of researching, I found that GRE is actually a router to router tunnel, and IPSec is a L2L tunnel type. I was wondering this because, when I did a traceroute from SW1 to R3 with a default route pointed at R2 (To route it around the NBMA), it was replying back with router addresses and not the tunnels address.

So first let me get to the configuration, its so easy, I cannot believe how hard it was to configure properly:

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int tu0
*Mar 31 20:44:11.041: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R3(config-if)#ip add 10.1.1.3 255.255.255.0
R3(config-if)#tunnel source 172.12.123.3
R3(config-if)#tunnel dest 172.12.123.2
R3(config-if)#
*Mar 31 20:45:39.374: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R3(config-if)#
R3(config)#router ospf 1
R3(config-router)#network 10.1.1.0 0.0.0.255 area 0
ASR#2
[Resuming connection 2 to r2 … ]

R2(config)#
R2(config)#router ospf 1
R2(config-router)#network 10.1.1.0 0.0.0.255 area 0
R2(config-router)#int tu0
*Mar 30 23:52:58.962: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R2(config-if)#ip add 10.1.1.2 255.255.255.0
R2(config-if)#tunnel source 172.12.123.2
R2(config-if)#tunnel dest 172.12.123.3
R2(config-if)#
*Mar 30 23:53:36.644: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R2(config-if)#do sh ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            172.12.23.2     YES manual up                    up
Serial0/0                  172.12.123.2    YES manual up                    up
FastEthernet0/1            unassigned      YES unset  administratively down down
Serial0/1                  unassigned      YES unset  administratively down down
Loopback2                  2.2.2.2         YES manual up                    up
Tunnel0                    10.1.1.2        YES manual up                    up

What I was really, reaaaally struggling with is the “recursive lookup” which essentially is a route lookup loop on the local router, which is an issue when running dynamic routing protocols, because your router will take the best path it knows how to get there and that dynamic protocol might provide it – This is why looking at GRE you see a lot of talk about default and static routing.

For example, consider this IP route table and traceroute:

R2#traceroute 172.12.34.3

Type escape sequence to abort.
Tracing the route to 172.12.34.3

  1 172.12.123.1 32 msec 32 msec 32 msec
  2 172.12.123.3 92 msec *  72 msec

If we look at the route table, there is already actually two entries that would route traffic to its destination:
R2#sh ip route

Gateway of last resort is 172.12.123.1 to network 0.0.0.0

     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/65] via 172.12.123.1, 00:40:50, Serial0/0
     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback2
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/65] via 172.12.123.3, 00:40:50, Serial0/0
     172.12.0.0/24 is subnetted, 4 subnets
O IA    172.12.34.0 [110/65] via 172.12.123.3, 00:32:09, Serial0/0
O IA    172.12.15.0 [110/65] via 172.12.123.1, 00:40:50, Serial0/0
C       172.12.23.0 is directly connected, FastEthernet0/0
C       172.12.123.0 is directly connected, Serial0/0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, Tunnel0
O*E2 0.0.0.0/0 [110/1] via 172.12.123.1, 00:32:14, Serial0/0

Because instead of just making a static route I used “default-information originate always” on R1, so it is a Type 5 LSA (External), which of course has the same AD as any OSPF route, so both routes essentially said take OSPF and not the tunnel.

So I added a static route to get thing moving along:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#ip route 172.12.34.0 255.255.255.0 tu0
R2(config)#exit
R2#traceroute 172.12.34.3

Type escape sequence to abort.
Tracing the route to 172.12.34.3

  1 10.1.1.3 104 msec *  92 msec
R2#

ASR#3
[Resuming connection 3 to r3 … ]

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#ip route 2.2.2.2 255.255.255.255 tu0
R3(config)#exit
R3#traceroute
*Mar 31 21:29:59.414: %SYS-5-CONFIG_I: Configured from console by console
R3#traceroute 2.2.2.2

Type escape sequence to abort.
Tracing the route to 2.2.2.2

  1 10.1.1.2 100 msec *  100 msec
R3#

So essentially it just needed a static route so the AD would be lower than 110 from the OSPF learned routes.

How IPSec you actually create an ACL to define interesting traffic, with GRE you simply have to tell the router to route traffic to the remote destination over your tunnel interface, and make sure you have connectivity between your source ad dest IP’s.

Now that I have a thorough understanding of this, and have spent hours / days researching this topic and different approaches to GRE despite it being the oldest pile of dirt VPN there is, this is how it is not only configured but how routes are created to take the tunnel to the destination network when dynamic routing is running.

This has really cost me some DEEP Diving time so up next will be IPSec configuration, and then integrating GRE with it to encapsulate GRE traffic, but for now it is nap time to let my brain cool off!

  • Note that Cisco recommends you use a logical loopback interface as your source address, in case of a link failure, however I’ve spent so much time on this already I am just using the outside interfaces.

VPN: DEEP Dive into different VPN Packet Types, Packet Headers, and the differences between VPN Packets and their Modes!

VPN_Headers

This first image is a break down of the different types of VPN Packet Type by the headers / trailers (or lack thereof), and the following of your typical IPSec VPN Packet Type:

packet_segments_ipsec

The VPN generic representation of the IPSec VPN Packet above works for a general review, but there are details in the headers that are begging for exam questions and must be broken down and committed to memory if asked about them.

  • AH (Authentication Header) = Security, Data Origin Authentication (also offers anti-reply protection)
  • ESP (Encapsulating Security Payload) = Method of authentication / securing / encrypting the Data payload
  • IKE (Internet Key Exchange) – The protocol to negotiate security parameters and authentications keys to form an SA (Security Association)

Going from top to bottom, lets review each Packet type going down the list above from the top of the page:

  • Generic Frame = Ethernet Header | IP Header | Protocol Header | Payload
  • 1. Ethernet Header = Encapsulates Ethernet Frame
  • 2. IP Header = Source IP Address
  • 3. TCP/UDP Header = Port information, for a quick read on  TCP vs UDP Headers that link is gold for a brief but concise comparison
  • 4. Data / Payload = “Blah blah blah”

Used by GRE, which is mostly mentioned regarding mGRE for DMVPN Functionality, it can also be configured to be encapsulated INSIDE IPSec VPN tunnels because it does not have limitations that IPSec VPN’s have which is as follows:

  • 1. IPSec tunnels can Secure and Encrypt Unicast Information, but not Multicast or Broadcast traffic, which may be needed between sites
  • 2. GRE tunnels send Unicast Packets that can encapsulate Multicast and Broadcast traffic, which can than be placed into a new IPSec packet as a unicast packet so Multicast and Broadcast traffic can traverse VPN tunnels!

There will be a separate lab for GRE / IPSec that will demonstrate this concept as it is important to know both for the lab and real world as we always want more tools to get the job done!

Tunnel modes for VPN types explained in detail

First to be discussed will be the two Transport Modes, as they are hiding a field switcheroo in the packet fields you’d overlook at first glance:

  • 1. Tunnel mode will encrypt the packet, and place that packet into a new packet, which will then route on agreed IP addresses between the Tunnel Endpoints
  • 2. Transport mode will encrypt the IP packets payload, but the IPSec Header is inserted behind the IP Header, exposing the source address of the data, and only truly secures data from the Transport Layer up as the Source IP is used

So if you are not looking again at that top illustration and saying “Oh, I didn’t see that, good to know” you either already know it or did not understand what you just read 🙂

AH Tunnel / Transport Mode explained in detail

First we will review the 2 different flavors of AH Packets, explained from most protect to least, with details about each segments purpose:

  • AH Tunnel Mode = Ethernet Header | New IP Header | AH Header| IP Header | TCP/UDP Header | Payload
  • 1. Ethernet Header = Encapsulates Ethernet Frame
  • 2. New IP Header = Usually IP of the Security Gateway / Peer IP
  • 3. AH Header = Security, Data Origin Authentication, optional Anti-Replay Protection (No Data Confidentiality / Encryption)
  • 4. IP Header = Source IP Address
  • 5. TCP/UDP Header = Port information, for a quick read on  TCP vs UDP Headers that link is gold for a brief but concise comparison
  • 6. Data / Payload = “Blah blah blah”

 

  • AH Transport Mode = Ethernet Header | IP Header | AH Header | TCP/UDP Header | Payload
  • 1. Ethernet Header = Encapsulates Ethernet Frame
  • 2. AH Header = Security, Data Origin Authentication, optional Anti-Replay Protection (No Data Confidentiality / Encryption)
  • 3. IP Header = Source IP Address
  • 4. TCP/UDP Header = Port information, for a quick read on  TCP vs UDP Headers that link is gold for a brief but concise comparison
  • 5. Data / Payload = “Blah blah blah”

It is a viable VPN solution to use, as it will protect the IP Packets payload, however the Authentication it provides is not complete. As some of the IP Header fields may be changed in transmission,  the receiver cannot accurately predict the IP fields, thus making it complete but it still offers all attributes mentioned in the AH Header.

The one big strike against AH is that although it does protect the data Payload and is considered secure, the Payload is NOT encrypted so AH is considered non-Confidential.

The IP Header:

ipv4_header

The Authentication Header:

AH_Header

Next is the two more secured options of ESP, offering an ESP Header / Trailer, as well as ESP Authentication – Lets review both again, most secure to least:

  • ESP Tunnel Mode = Ethernet Header | New IP Header | ESP Header| IP Header | TCP/UDP Header | Payload | ESP Trailer | ESP Authentication
  • 1. Ethernet Header = Encapsulates Ethernet Frame
  • 2. New IP Header = Usually IP of the Security Gateway / Peer IP
  • 3. IPSec / ESP Header = Encapsulates data / Encryption, Data Confidentiality
  • 4. IP Header = Source IP Address
  • 5. TCP/UDP Header = Port information, for a quick read on  TCP vs UDP Headers that link is gold for a brief but concise comparison
  • 6. Data / Payload = “Blah blah blah”
  • 7. ESP Trailer = Encapsulates Data / Padding
  • 8. ESP Authentication =  Authentication Data / Hash Checksum

 

  • ESP Transport Mode = Ethernet Header | IP Header | ESP Header | TCP/UDP Header | Payload | ESP Trailer | ESP Authentication
  • 1. Ethernet Header = Encapsulates Ethernet Frame
  • 2. IP Header = Source IP Address
  • 3. IPSec / ESP Header = Encapsulates data / Encryption, Data Confidentiality
  • 4. TCP/UDP Header = Port information, for a quick read on  TCP vs UDP Headers that link is gold for a brief but concise comparison
  • 5. Data / Payload = “Blah blah blah”
  • 6. ESP Trailer = Encapsulates Data / Padding / Pad Length / Next Header
  • 7. ESP Authentication =  Authentication Data / Hash Checksum

Now I want to post the image at the top right here for quick comparison among all of these different methods of VPN / Modes:

VPN_Headers

So as can be seen, ESP is highly preferred over AH if you have the resources to run it, and that “Tunnel” mode is preferred over “Transport” mode because it keeps the Source IP Address secure.

Here is an image that I thought was very visual and helpful to seeing the difference in ESP Tunnel vs Transport mode:

IP_Security_IPSec_ESP_01

I am completely fried so that will be it for thd packet details, next DEEP Dive will be GRE over IPSec lab to see if we can brainwash the configuration just like all of this information – I can’t wait 🙂

 

OSPF: DEEP Dive – Distribute-List vs Filter-List, and reviewing Prefix-Lists as Filter-Lists use Prefixes to filter!

OSPF_Distribute_vs_Filter

One thing that was lacking from Chris Bryants training that I found in the INE series is explanations between when to use OSPF Filter-list vs a Distribute-list. I have modified the network as reflected in the Topology so Area 34 will no longer be a stub, and Area 15 will only be an NSSA Area.

Fun right? Great! 🙂

I’m going to mark down bullet point style information about distribute-lists and filter-lists for OSPF and how they work / what they effect:

  • An inbound Distribute-List DOES NOT prevent a router from learning about an incoming Prefix via LSA, the LSA will stay in the LS Database, however it will prevent it from generating a route for that Prefix on the router

^This is a very important to know, as if you are tasked for a router to have NO knowledge of a certain route, this approach will still allow the router to have knowledge of the route via the LSA but will prevent it from converting that LSA to a route – So the router still learns of the Prefix.

In fact lets put Keith Borgarts money where his mouth is right off the bat, and test this theory of his out, by preventing R3 from learning of network 2.2.2.2/32 from R2:

R4(config-router)#do sh ip route

Gateway of last resort is 172.12.34.3 to network 0.0.0.0

O*E2  0.0.0.0/0 [110/1] via 172.12.34.3, 00:00:03, FastEthernet0/1

      1.0.0.0/32 is subnetted, 1 subnets

One thing I forgot about in the previous lab, was the “default-information originate always” configured on R1, and this is a perfect example of it not just Advertising that default route within its Area 0, but ABR’s flood that default route into all Areas that allow type 5 LSA’s to be flooded – So you will not be seeing that in our NSSA.

I will spare you the “before” output from R3, 2.2.2.2/32 is both in the LS DB and Route Table, but after configuring the ACL and applying it to an inbound Distribute-List:

R3(config)#access-list 2 deny 2.2.2.2
R3(config)#access-list 2 permit any
R3(config)#router ospf 1
R3(config-router)#distribute-list ?
  <1-199>      IP access list number
  <1300-2699>  IP expanded access list number
  WORD         Access-list name
  gateway      Filtering incoming updates based on gateway
  prefix       Filter prefixes in routing updates
  route-map    Filter prefixes based on the route-map

R3(config-router)#distribute-list 2 ?
  in   Filter incoming routing updates
  out  Filter outgoing routing updates

R3(config-router)#distribute-list 2 in ?
  Async              Async interface
  BVI                Bridge-Group Virtual Interface
  CDMA-Ix            CDMA Ix interface
  CTunnel            CTunnel interface
  Dialer             Dialer interface
  FastEthernet       FastEthernet IEEE 802.3
  Lex                Lex interface
  Loopback           Loopback interface
  MFR                Multilink Frame Relay bundle interface
  Multilink          Multilink-group interface
  Null               Null interface
  Port-channel       Ethernet Channel of interfaces
  Serial             Serial
  Tunnel             Tunnel interface
  Vif                PGM Multicast Host interface
  Virtual-PPP        Virtual PPP interface
  Virtual-Template   Virtual Template interface
  Virtual-TokenRing  Virtual TokenRing
  <cr>

I wanted to leave the ending in there, to show that you can actually assign the Distribute-List at certain interfaces, that being said lets see if it worked:

R3(config-router)#distribute-list 2 in
R3(config-router)#do sh ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/65] via 172.12.123.1, 00:00:20, Serial0/2
     100.0.0.0/13 is subnetted, 1 subnets
O IA    100.0.0.0 [110/65] via 172.12.123.1, 00:00:20, Serial0/2
     4.0.0.0/32 is subnetted, 1 subnets
O       4.4.4.4 [110/2] via 172.12.34.4, 00:00:20, FastEthernet0/1
     55.0.0.0/24 is subnetted, 1 subnets
O E1    55.5.5.0 [110/85] via 172.12.123.1, 00:00:20, Serial0/2
     5.0.0.0/32 is subnetted, 1 subnets
O E1    5.5.5.5 [110/85] via 172.12.123.1, 00:00:20, Serial0/2
     172.12.0.0/24 is subnetted, 4 subnets
O IA    172.12.15.0 [110/65] via 172.12.123.1, 00:00:20, Serial0/2
     172.16.0.0/22 is subnetted, 1 subnets
O E1    172.16.8.0 [110/85] via 172.12.123.1, 00:00:20, Serial0/2
     22.0.0.0/32 is subnetted, 1 subnets
O       22.2.2.2 [110/65] via 172.12.123.2, 00:00:20, Serial0/2
     11.0.0.0/32 is subnetted, 1 subnets
O       11.1.1.1 [110/65] via 172.12.123.1, 00:00:20, Serial0/2
O*E2 0.0.0.0/0 [110/1] via 172.12.123.1, 00:00:20, Serial0/2
R3(config-router)#

No route to 2.2.2.2/32, however the LS DB:

R3#sh ip ospf data

            OSPF Router with ID (33.3.3.3) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
22.2.2.2        22.2.2.2        1239        0x80000004 0x009686 2
33.3.3.3        33.3.3.3        773         0x80000002 0x008A6B 2
100.7.0.1       100.7.0.1       1308        0x80000003 0x00CDBE 2

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.123.1    100.7.0.1       1308        0x80000002 0x00FEE1

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         100.7.0.1       1563        0x80000002 0x009D2D
2.2.2.2         22.2.2.2        1239        0x80000002 0x0044D2

3.3.3.3         33.3.3.3        796         0x80000001 0x009F66
4.4.4.4         33.3.3.3        786         0x80000001 0x007B85
100.0.0.0       100.7.0.1       1563        0x80000002 0x0096DA
172.12.15.0     100.7.0.1       1308        0x80000005 0x00CA39
172.12.34.0     33.3.3.3        800         0x80000001 0x005DD9

So that is absolutely correct, the router will learn about it, it just won’t make a route entry for it. Also an important note, checking on R4, there is no route or LS DB entry for 2.2.2.2, so it will not flood 2.2.2.2 in it’s LSA to any downstream routers as well.

So back to not wanting a router to know ANYTHING about 2.2.2.2/32, lets give it another try using the “filter-list” option in OSPF and see if that works!

We will use a filter-list to prevent R5 from seeing 2.2.2.2 this time, only with a filter-list, and there are a couple different approaches to it and an important note that it is not done on the router itself we are preventing from learning about the network like on R3.

So we will have to configure this one of two different ways:

  • We will need to do configurations on R1 instead of R5 to block the LSA from getting to R5
  • We will need to configure a Prefix-List rather than an Access-List as Filter-List’s use Prefix’s instead of Access-Lists
  • You can either configure it as Area 0 going outbound, or Area 15 coming inbound

So to that last point, you want to configure either the Area with “in” that it is coming in on, or the Area # that it is going “out” to.

So about that Prefix-List:

R1(config)#ip prefix-list ?
  WORD             Name of a prefix list
  sequence-number  Include/exclude sequence numbers in NVGEN

R1(config)#ip prefix-list FilterList ?
  deny         Specify packets to reject
  description  Prefix-list specific description
  permit       Specify packets to forward
  seq          sequence number of an entry

R1(config)#ip prefix-list FilterList deny ?
  A.B.C.D/nn  IP prefix <network>/<length>, e.g., 35.0.0.0/8

R1(config)#ip prefix-list FilterList deny 2.2.2.2/32 ?
  ge  Minimum prefix length to be matched
  le  Maximum prefix length to be matched
  <cr>

R1(config)#ip prefix-list FilterList deny 2.2.2.2/32
R1(config)#ip prefix-list FilterList permit 0.0.0.0/32 le 32

% Invalid prefix range for 0.0.0.0/32, make sure: len < ge-value <= le-value

R1(config)#ip prefix-list FilterList permit 0.0.0.0/32 ?
  ge  Minimum prefix length to be matched
  le  Maximum prefix length to be matched
  <cr>

R1(config)#ip prefix-list FilterList permit 0.0.0.0/32
R1(config)#

I am a bit confused by the highlighted portion, I do not remember that when using Prefix-Lists in BGP, I will have to re-visit that in another DEEP Dive – However I believe we have our Prefix-List built correctly so time to apply it!

A quick note on Prefix-Lists, note that when creating ACL’s you “permit” the network 2.2.2.2 and the Distribute-List does the dirty work, but with Prefix-Lists you need to deny it on the list and like with an ACL make a catch-all permit line for all other traffic to flow.

So because we want this to filter the route / LSA to R5, we will specify Area 15, and use the “in” command at the end as you will see worded in the command modifiers here:

R1(config)#router ospf 1
R1(config-router)#area 15 filter-list ?
  prefix  Filter prefixes between OSPF areas

R1(config-router)#area 15 filter-list prefix ?
  WORD  Name of an IP prefix-list

R1(config-router)#area 0 filter-list prefix FilterList ?
  in   Filter networks sent to this area
  out  Filter networks sent from this area

R1(config-router)#area 15 filter-list prefix FilterList in ?
  <cr>

R1(config-router)#area 15 filter-list prefix FilterList in
R1(config-router)#

It is so weird to think of it this way, but you are filtering networks from going “in”to Area 15, whereas on R1 we would configure “out” for Area 0 to block a route Advertisement.

Note that you need to ID the filter list, which to get it run the following command:

R1#sh ip prefix-list
ip prefix-list FilterList: 2 entries
   seq 5 deny 2.2.2.2/32
   seq 10 permit 0.0.0.0/32
R1#

So finally, lets take a look at R1 for the Route / LS DB entry, then R5 (I will remove any unnecessary output for clarity:

Yeeeah.

So I must have goofed that Prefix-List, and I know it has to do with the part highlighted, as Area 15 has almost no LSA Type 3 entries on R1, and R5 itself has no outside OSPF routes. So now to re-visit what the deal is with my Prefix-List.

After a quick googling, I found that in my haste, I forgot we are using a Wild Card mask for Prefix lists, so this is how I correct that:

R1(config)#no ip prefix-list FilterList seq 10 permit 0.0.0.0/32
R1(config)#ip prefix-list FilterList seq 10 permit 0.0.0.0/0 le 32
R1(config)#do sh ip ospf data

            OSPF Router with ID (100.7.0.1) (Process ID 1)

                Summary Net Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         100.7.0.1       14          0x80000001 0x004580
3.3.3.3         100.7.0.1       14          0x80000001 0x006B12
4.4.4.4         100.7.0.1       14          0x80000001 0x004731
11.1.1.1        100.7.0.1       14          0x80000001 0x00C2F8
22.2.2.2        100.7.0.1       14          0x80000001 0x0094D8
33.3.3.3        100.7.0.1       14          0x80000001 0x00E37B
100.0.0.0       100.7.0.1       14          0x80000001 0x003E2E
172.12.34.0     100.7.0.1       14          0x80000001 0x002985
172.12.123.0    100.7.0.1       14          0x80000001 0x00480E

Whoop there it is 🙂

To finish this topic off, lastly I will finish the ‘out’ portion, and first I want to see if it can be applied to not directly connected to the router:

R1(config)#ip prefix-list Filtering2 deny 5.5.5.5/32
R1(config)#ip prefix-list Filtering2 permit 0.0.0.0/0 le 32
R1(config)#router ospf 1
R1(config-router)#area 34 filter-list ?
  prefix  Filter prefixes between OSPF areas

R1(config-router)#area 34 filter-list prefix ?
  WORD  Name of an IP prefix-list

R1(config-router)#area 34 filter-list prefix Filtering2 ?
  in   Filter networks sent to this area
  out  Filter networks sent from this area

R1(config-router)#area 15 filter-list prefix Filtering2 out

I’ll spare the output, but after checking R3 and R4, Area 34 still see’s both the route and LSA for 5.5.5.5/32, so that is what we call in the business (of studying) as a no go.

So let’s see if we can block it from entering our summary route Area 100:

R1(config-router)#no area 34 filter-list prefix Filtering2 out
R1(config-router)#area 100 filter-list prefix Filtering2 out
R1(config-router)#do sh ip ospf data

            OSPF Router with ID (100.7.0.1) (Process ID 1)

                Summary Net Link States (Area 100)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         100.7.0.1       1456        0x80000001 0x009F2C
2.2.2.2         100.7.0.1       981         0x80000001 0x00F393
3.3.3.3         100.7.0.1       1104        0x80000001 0x00C5BD
4.4.4.4         100.7.0.1       1104        0x80000001 0x00A1DC
11.1.1.1        100.7.0.1       1456        0x80000001 0x001DA4
22.2.2.2        100.7.0.1       981         0x80000001 0x00EE84
33.3.3.3        100.7.0.1       1104        0x80000001 0x003E27
172.12.15.0     100.7.0.1       1114        0x80000005 0x00CA39
172.12.34.0     100.7.0.1       1104        0x80000001 0x008331
172.12.123.0    100.7.0.1       1456        0x80000001 0x00A2B9

Success! So when you use “out” with your filter-list you must specify the Area # the route is broadcast “out” to, while “in” means where the route is being sent into.

It’s weird, but you really need to remember that difference, but exam points may depend on it, so review this topic and configure it yourself a few times if you don’t get it initially.

So to summarize this DEEP Dive into Filter vs Distribute Lists (and Prefix-Lists):

  • A Distribute-list uses an ACL, whereas a filter-list uses an “ip prefix-list”
  • “ip prefix-list (word) permit 0.0.0.0/0 le 32” is equivalent to an ACL “permit any”
  • Distribute-Lists will store the route in its LS DB for the Area it was received in, but it will not create a route, and it will not flood that network into other Areas
  • A filter-list will prevent the LS DB from holding the route for the defined Area, but flood it to all other Areas
  • With filter-lists, think of defining traffic going “in”to a specified area, or “out” to a specific Area
  • Both Distribute-Lists and Filter-Lists affect only Area’s local to them, so these would be configured on ABR’s and ASBR’s when filtering route Redistribution

 

OSPF: DEEP Dives into Summarization methods, Authentication, Default-Information Originate (Always)!

OSPF_LSA_Deep_Dive_Ver2

Since I already have the lab configured with different OSPF Area’s, and we had a riveting exploration into the world of LSA’s and the LS DB of each router, I wanted to hit some other topics again thoroughly before I switch up protocols for more DEEP Dives into all things CCNP ROUTE related!

Without further ado!

 

OSPF Route Summarization

 

We have two options when it comes to route summarization when it comes to OSPF, as it does not auto-summarize at classful boarders like RIP or EIGRP, and those are:

  • “area x range (summary network) (summary mask)” – This is only to be used on ABR routers!
  • “summary-address (summary network) (summary mask)” – This is only to be used on ASBR’s doing redistribution for the networks being summarized!

The “… range …” command is used to summarize route in Area x, where x is the Area containing the routes, which it will then flood out as Type 3 LSA’s throughout the network where they are allowed – Requires networks be entered into OSPF configuration via the “network” statement

The “summary-address …” command is used for routes being redistributed into OSPF, so all routes of the summary need to be configured on the ASBR via the “network …” command – Does not require routes to be entered into OSPF configuration (because we are summarizing redistributed routes!)

Both of these are configured in OSPF router configuration mode, not an interface!

First I’ll start with the Range method on the ABR R1:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#interface Loopback101
R1(config-if)# ip address 100.1.0.1 255.255.0.0
R1(config-if)#interface Loopback102
R1(config-if)# ip address 100.2.0.1 255.255.0.0
R1(config-if)#interface Loopback103
R1(config-if)# ip address 100.3.0.1 255.255.0.0
R1(config-if)#interface Loopback104
R1(config-if)# ip address 100.4.0.1 255.255.0.0
R1(config-if)#interface Loopback105
R1(config-if)# ip address 100.5.0.1 255.255.0.0
R1(config-if)#interface Loopback106
R1(config-if)# ip address 100.6.0.1 255.255.0.0
R1(config-if)#interface Loopback107
R1(config-if)# ip address 100.7.0.1 255.255.0.0
*Apr 26 20:08:20.743: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback101, changed state to up
*Apr 26 20:08:20.815: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback102, changed state to up
*Apr 26 20:08:20.959: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback103, changed state to up
*Apr 26 20:08:21.031: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback104, changed state to up
*Apr 26 20:08:21.107: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback105, changed state to up
*Apr 26 20:08:21.183: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback106, changed state to up
R1(config-if)# ip address 100.7.0.1 255.255.0.0
*Apr 26 20:08:21.223: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback107, changed state to up
R1(config-if)#exit
R1(config)#router ospf 1
R1(config-router)#network 100.1.0.0 0.0.255.255 area 100
R1(config-router)#network 100.2.0.0 0.0.255.255 area 100
R1(config-router)#network 100.3.0.0 0.0.255.255 area 100
R1(config-router)#network 100.4.0.0 0.0.255.255 area 100
R1(config-router)#network 100.5.0.0 0.0.255.255 area 100
R1(config-router)#network 100.6.0.0 0.0.255.255 area 100
R1(config-router)#network 100.7.0.0 0.0.255.255 area 100
R1(config-router)#area 100 range 100.0.0.0 255.248.0.0
R1(config-router)#^Z
R1#wr
Building configuration…

So that is it for this command, however a couple bullet points on it:

  • The routes must be directly connected to the router to perform summarization
  • The routes must be entered into OSPF via “network …” statements individually first
  • This must be performed on an ABR (Area Boarder Router)
  • The Area specified in the range command must be that containing the routes to be summarized

So let’s verify the summary route is propagating and get moving on our other summarization method:

R3#sh ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/65] via 172.12.123.1, 00:34:02, Serial0/2
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/65] via 172.12.123.2, 00:34:02, Serial0/2
     100.0.0.0/13 is subnetted, 1 subnets
O IA    100.0.0.0 [110/65] via 172.12.123.1, 00:08:26, Serial0/2
     4.0.0.0/32 is subnetted, 1 subnets
O       4.4.4.4 [110/2] via 172.12.34.4, 00:36:57, FastEthernet0/1
     55.0.0.0/24 is subnetted, 1 subnets
O E1    55.5.5.0 [110/85] via 172.12.123.1, 00:08:21, Serial0/2
     5.0.0.0/32 is subnetted, 1 subnets
O E1    5.5.5.5 [110/85] via 172.12.123.1, 00:08:21, Serial0/2
     172.12.0.0/24 is subnetted, 4 subnets
O IA    172.12.15.0 [110/65] via 172.12.123.1, 00:34:02, Serial0/2
     22.0.0.0/32 is subnetted, 1 subnets
O       22.2.2.2 [110/65] via 172.12.123.2, 00:34:02, Serial0/2
     11.0.0.0/32 is subnetted, 1 subnets
O       11.1.1.1 [110/65] via 172.12.123.1, 00:34:02, Serial0/2
R3#

And to show its LSA Type 3:

R3#sh ip ospf data

            OSPF Router with ID (33.3.3.3) (Process ID 1)

         
                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         11.1.1.1        864         0x80000002 0x00EA3E
2.2.2.2         22.2.2.2        471         0x80000002 0x0044D2
3.3.3.3         33.3.3.3        567         0x80000002 0x009D67
4.4.4.4         33.3.3.3        567         0x80000002 0x007986
100.0.0.0       11.1.1.1        840         0x80000001 0x00E5EA
172.12.15.0     11.1.1.1        604         0x80000004 0x001A49
172.12.34.0     33.3.3.3        571         0x80000002 0x005BDA

So there it is, we’ll hop into our Total-Stub NSSA to configure our Summary-Address command, as that is already Redistributing connected routes:

R5#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R5(config)#int lo8
R5(config-if)#ip add 172.16.8.1 255.255.255.0
R5(config-if)#int lo9
R5(config-if)#ip add 172.16.9.1 255.255.255.0
R5(config-if)#int lo10
R5(config-if)#ip add 172.16.10.1 255.255.255.0
R5(config-if)#int lo11
R5(config-if)#ip add 172.16.11.1 255.255.255.0
R5(config-if)#
R5(config-if)#
*Mar 31 20:29:11.031: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback8, changed state to up
*Mar 31 20:29:11.176: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback9, changed state to up
*Mar 31 20:29:11.216: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback10, changed state to up
*Mar 31 20:29:11.252: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback11, changed state to up
R5(config-if)#router ospf 1
R5(config-router)#summary-address 172.16.8.0 255.255.252.0
R5(config-router)#^Z
R5#wr
Building configuration…

That should be it for that, this time lets see how R2 see’s both of these summary routes:

R2#sh ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/65] via 172.12.123.1, 00:48:59, Serial0/0
     100.0.0.0/13 is subnetted, 1 subnets
O IA    100.0.0.0 [110/65] via 172.12.123.1, 00:23:33, Serial0/0
     33.0.0.0/32 is subnetted, 1 subnets
O       33.3.3.3 [110/65] via 172.12.123.3, 00:48:59, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/65] via 172.12.123.3, 00:48:59, Serial0/0
     4.0.0.0/32 is subnetted, 1 subnets
O IA    4.4.4.4 [110/66] via 172.12.123.3, 00:48:59, Serial0/0
     55.0.0.0/24 is subnetted, 1 subnets
O E1    55.5.5.0 [110/85] via 172.12.123.1, 00:23:28, Serial0/0
     5.0.0.0/32 is subnetted, 1 subnets
O E1    5.5.5.5 [110/85] via 172.12.123.1, 00:23:28, Serial0/0
     172.12.0.0/24 is subnetted, 4 subnets
O IA    172.12.34.0 [110/65] via 172.12.123.3, 00:48:59, Serial0/0
O IA    172.12.15.0 [110/65] via 172.12.123.1, 00:48:59, Serial0/0
     172.16.0.0/22 is subnetted, 1 subnets
O E1    172.16.8.0 [110/85] via 172.12.123.1, 00:01:47, Serial0/0
     11.0.0.0/32 is subnetted, 1 subnets
O       11.1.1.1 [110/65] via 172.12.123.1, 00:49:00, Serial0/0
R2#

There is our “range” made summary on ABR R1, and there is our “summary-address” summary configured on our ASBR, working exactly as they should.

One more important note before moving on about either method, you will use a subnet mask instead of a wildcard mask, so watch that as OSPF is all about Wildcard Masks in a majority of its configurations!

 

OSPF Area Authentication

 

To start off a couple of notes bullet point style for commands and details:

  • OSPF Authentication can use either Clear Text or MD5 encryption
  • Turning on Authentication for an Area can be done on the interface in that Area, or in router configuration mode using the area 0 authentication …” command
  • Any Virtual-Links must use the same Authentication method as Area 0 if in use in Area 0, as a Virtual-Link is considered an extension of Area 0

I’ll set this up between R1 / R2 / R3 all at interface level for now, using clear-text style on R2, and MD5 on R1 and R3 with different key numbers to see what impact it has:

R2(config)#int s0/0
R2(config-if)#ip ospf authentication
R2(config-if)#ip ospf authentication-key CCNP
R2(config-if)#^Z
R2#

ASR#1
[Resuming connection 1 to r1 … ]

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int s0/0/0
R1(config-if)#ip ospf authentication message-digest
R1(config-if)#ip ospf message-digest-key 1 md5 CCNP
R1(config-if)#^Z
R1#
*Apr 26 20:53:25.751: %SYS-5-CONFIG_I: Configured from console by console
R1#
ASR#3
[Resuming connection 3 to r3 … ]

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int s0/2
R3(config-if)#ip ospf authentication message-digest
R3(config-if)#ip ospf message-digest-key 2 md5 CCNP
R3(config-if)#
ASR#1
[Resuming connection 1 to r1 … ]

R1#
R1#
*Apr 26 20:54:10.083: %OSPF-5-ADJCHG: Process 1, Nbr 22.2.2.2 on Serial0/0/0 from FULL to DOWN, Neighbor Down: Dead timer expired
R1#
*Apr 26 20:54:45.211: %OSPF-5-ADJCHG: Process 1, Nbr 33.3.3.3 on Serial0/0/0 from FULL to DOWN, Neighbor Down: Dead timer expired
R1#

So we have officially dropped both our adjacencies by mixing clear-text authentication with md5, and by using different key numbers on the interface.

To fix this mess, I am going to configure R2’s authentication in router configuration, and add the correct key on the interface, and fix R3’s key number to see if that will make them three amigos once again:

*Mar 30 23:22:31.240: %OSPF-5-ADJCHG: Process 1, Nbr 11.1.1.1 on Serial0/0 from FULL to DOWN, Neighbor Down: Dead timer expired
R2#
R2#
R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int s0/0
R2(config-if)#no ip ospf authentication
R2(config-if)#no ip ospf authentication-key CCNP
R2(config-if)#ip ospf message-digest-key 1 md5 CCNP
R2(config-if)#router ospf 1
R2(config-router)#area 0 authentication message-digest
R2(config-router)#
ASR#3
[Resuming connection 3 to r3 … ]

*Mar 31 20:15:58.784: %OSPF-5-ADJCHG: Process 1, Nbr 11.1.1.1 on Serial0/2 from FULL to DOWN, Neighbor Down: Dead timer expired
R3(config-if)#
R3(config-if)#no ip ospf message-digest-key 2 md5 CCNP
R3(config-if)#ip ospf message-digest-key 1 md5 CCNP
R3(config-if)#
ASR#1
[Resuming connection 1 to r1 … ]

R1(config-router)#
*Apr 26 21:06:10.631: %OSPF-5-ADJCHG: Process 1, Nbr 22.2.2.2 on Serial0/0/0 from LOADING to FULL, Loading Done
R1(config-router)#
*Apr 26 21:06:45.755: %OSPF-5-ADJCHG: Process 1, Nbr 33.3.3.3 on Serial0/0/0 from LOADING to FULL, Loading Done
R1(config-router)#

I highlighted in red the commands for router configuration for clarity sake, however we see that configuring the authentication doesn’t matter if it’s on the interface or router configuration as long as either is the correct Area, however the key configuration does need to be on the interface – there is no options in OSPF router configuration for keys.

Now for verification, this is very important to close this out with, so listen up!

Depending on where Authentication is configured (router config or interface) there are two different ways to verify if an Area is running Authentication that you need to know about for exam day.

First lets look at the first example of R1 using “sh ip ospf” :

R1#sh ip ospf
 Routing Process “ospf 1” with ID 11.1.1.1
(Output Removed for clarity)
    Area BACKBONE(0)
        Number of interfaces in this area is 2 (1 loopback)
        Area has no authentication
        SPF algorithm last executed 00:20:26.612 ago
        SPF algorithm executed 12 times

If authentication was configured (not the key itself but turning on authentication) on the physical interface, it will show up in “sh ip ospf” that it has no Authentication when it in fact does!

To verify authentication in this case, you would need to use the “sh ip ospf int (int)” command to verify as seen here:

R1#sh ip ospf int s0/0/0
Serial0/0/0 is up, line protocol is up
  Internet Address 172.12.123.1/24, Area 0
  Process ID 1, Router ID 11.1.1.1, Network Type NON_BROADCAST, Cost: 64
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           64        no          no            Base
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 11.1.1.1, Interface address 172.12.123.1
  No backup designated router on this network
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
    oob-resync timeout 120
    Hello due in 00:00:13
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 2/4, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 7
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 2, Adjacent neighbor count is 2
    Adjacent with neighbor 22.2.2.2
    Adjacent with neighbor 33.3.3.3
  Suppress hello for 0 neighbor(s)
  Message digest authentication enabled
    Youngest key id is 1
R1#

I know that’s a lot of output, but I wanted to clarify it’s allllll the way at the bottom. So for R2 we can do a “sh ip ospf” and have no problem seeing it there:

R2#sh ip ospf
 Routing Process “ospf 1” with ID 22.2.2.2
 (Output Removed for clarity)
    Area BACKBONE(0)
        Number of interfaces in this area is 2 (1 loopback)
        Area has message digest authentication
        SPF algorithm last executed 00:26:48.292 ago
        SPF algorithm executed 9 times

So to summarize:

  • Authentication can be set on either the interface or router config as long as the Areas and authentication type (clear / md5) both match with neighbors
  • The key always needs to be configured on the physical interface connected to the Area doing Authentication
  • Virtual-Links require the same Authentication as Area 0 to work as they are considered an extension of Area 0
  • “sh ip ospf” will not show Authentication for an Area if it is configured directly on the interface, use “sh ip ospf int (int)” to verify Authentication is set

That was a lot to get out, but I think we have all bases covered for Authentication.

 

Default-Information Originate (Always) Command

 

This command is pretty straight forward so I won’t spend too much time on it, however there are two approaches to propagating a default route in OSPF:

  • The first option: Configure a static default route to the next hop router you want traffic to flow to, and configure “default-information originate” in OSPF router configuration mode as such:

R1(config)#ip route 0.0.0.0 0.0.0.0 172.12.123.1
%Invalid next hop address (it’s this router)
R1(config)#ip route 0.0.0.0 0.0.0.0 172.12.15.5
R1(config)#router ospf 1
R1(config-router)#default-information originate
R1(config-router)#
ASR#2
[Resuming connection 2 to r2 … ]

R2#sh ip route

Gateway of last resort is 172.12.123.1 to network 0.0.0.0

So we had to configure an upstream router as the default gateway for R1 as well, however R2 immediately got the default route, and one thing I found extremely interesting from our LSA brainwashing:

R2#sh ip ospf data

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
0.0.0.0         11.1.1.1        235         0x80000001 0x00C80F 1

The static route shows up in the route table as this:

O*E2 0.0.0.0/0 [110/1] via 172.12.123.1, 00:06:25, Serial0/0

So if you’re ever asked by a stranger walking down the street what LSA type a static route used for default-information originate is, it is a Type 5 External Route LSA.

However I don’t want R1 with a default route pointing towards R5, I just want routers to send their traffic to R1 to handle, to make Area 0 like a Stub (because you cannot actually make Area 0 a Stub).

  • The Second Option: Use the command “Default-Information Originate Always” and the Router will send out default routes pointing at itself, without any default route being required to be configured on it pointing at another router:

R1(config)#no ip route 0.0.0.0 0.0.0.0 172.12.15.5
R1(config)#router ospf 1
R1(config-router)#no default-information originate
R1(config-router)#default-information originate always

I’ll spare the output from R2 as it is the exact same either way you configure it, however with “always” tacked onto the end, I no longer have a default route on R1.

That is it for this deep dive, not sure what will be up next, but they will keep coming!

Part 3: OSPF LSA DEEP Dive LSA Type 7, DEEP Dive into OSPF Stub and NSSA Areas, and how they impacts LSA traffic!

OSPF_LSA_Deep_Dive_Ver2

To lead off where we left, we made Area 15 an NSSA Area which stopped the Type 4 and 5 LSA’s from entering the Area, now we are going to do some Redistribution the other way and turn R5 in the NSSA Area into an ASBR.

I’ve created networks (loopbacks) 5.5.5.5 /32 and 55.5.5.0 /24, and will redistribute them into OSPF, again using the metric-type modifier as I believe the N1 and N2 routes function the same as E1 and E2 route types (though I could be wrong on that!):

R5#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R5(config)#router ospf 1
R5(config-router)#redistribute connected subnets metric-type 1
R5(config-router)#^Z
R5#

I will admit, again I did “sh ip route ospf” completely forgetting it will not show directly connected interfaces as an OSPF external route unless I give them an AD lower than 0.

However, let us take a look at the LS DB to see if anything has changed in there:

R5#sh ip ospf database

            OSPF Router with ID (5.5.5.5) (Process ID 1)

                Router Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum Link count
5.5.5.5         5.5.5.5         161         0x8000000B 0x00B6AC 1
11.1.1.1        11.1.1.1        532         0x8000000C 0x00D39D 1

                Net Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.15.1     11.1.1.1        532         0x80000008 0x001D17

                Summary Net Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         11.1.1.1        532         0x80000007 0x008697
2.2.2.2         11.1.1.1        532         0x80000007 0x00DAFE
3.3.3.3         11.1.1.1        532         0x80000007 0x00AC29
11.1.1.1        11.1.1.1        532         0x80000007 0x000410
22.2.2.2        11.1.1.1        532         0x80000007 0x00D5EF
33.3.3.3        11.1.1.1        532         0x80000007 0x002592
172.12.34.0     11.1.1.1        532         0x80000007 0x006A9C
172.12.123.0    11.1.1.1        535         0x80000007 0x008925

                Type-7 AS External Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum Tag
5.5.5.5         5.5.5.5         164         0x80000001 0x0058C9 0
55.5.5.0        5.5.5.5         164         0x80000001 0x00FDF6 0
R5#

*Queue the Angels singing* JUST as expected, there are the networks under Link ID, the Advertising Routers RID, Age, …. some other stuff but then I see Tag in there.

Being the curious person I am, I will create a quick route map for the redistribute command and see if that populates in the LS DB:

R5(config)#
R5(config)#access-list 7 permit 5.5.5.5
R5(config)#access-list 7 permit 55.5.5.0 0.0.0.255
R5(config)#
R5(config)#route-map Tagging permit 10
R5(config-route-map)#match ip add 7
R5(config-route-map)#set tag 100
R5(config-route-map)#route-map Tagging permit 20
R5(config-route-map)#exit
R5(config)#
R5(config)#router ospf 1
R5(config-router)#no redistribute connected subnets metric-type 1
R5(config-router)#redistribute connected subnets metric-type 1 ?
metric     Metric for redistributed routes
route-map  Route map reference
tag        Set tag for routes redistributed into OSPF
<cr>

R5(config-router)#$e connected subnets metric-type 1 route-map Tagging
R5(config-router)#

I’ve never noticed in Route-Maps that you have a <cr> after match ip add, I am wondering if that is equivalent to the catch all “let other traffic flow normal” clause I put on sequence 20 by entering nothing. Hmm.

Anyways, lets see those tags in the LS DB! :

R5#sh ip ospf database

(Removed unnecessary output)

                Type-7 AS External Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum Tag
5.5.5.5         5.5.5.5         306         0x80000001 0x006756 100
55.5.5.0        5.5.5.5         306         0x80000001 0x000D83 100
R5#

Cool, so that is a very handy trick to know for exam day if you are asked to answer a tagging question, but “sh route” and “sh run” is disabled, you can run “sh ip ospf database” and see if Route-Maps are indeed tagging them and what they are tagging them with. Very good knowledge for exam day!

That knowledge aside, lets see how R1 is now seeing the network through it’s LS DB:

R1#sh ip ospf data

            OSPF Router with ID (11.1.1.1) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
11.1.1.1        11.1.1.1        1431        0x80000008 0x00D76C 2
22.2.2.2        22.2.2.2        453         0x80000008 0x008E8A 2
33.3.3.3        33.3.3.3        489         0x80000008 0x007E71 2

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.123.1    11.1.1.1        423         0x80000007 0x00A9EE

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         11.1.1.1        683         0x80000007 0x00E043
2.2.2.2         22.2.2.2        453         0x80000007 0x003AD7
3.3.3.3         33.3.3.3        489         0x80000007 0x00936C
172.12.15.0     11.1.1.1        423         0x80000009 0x00104E
172.12.34.0     33.3.3.3        489         0x80000007 0x0051DF

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
11.1.1.1        11.1.1.1        1431        0x80000007 0x00F018 1

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
2.2.2.2         11.1.1.1        423         0x80000007 0x0035AA
3.3.3.3         11.1.1.1        423         0x80000007 0x0007D4
11.1.1.1        11.1.1.1        683         0x80000007 0x005EBB
22.2.2.2        11.1.1.1        423         0x80000007 0x00309B
33.3.3.3        11.1.1.1        423         0x80000007 0x007F3E
172.12.15.0     11.1.1.1        423         0x80000009 0x00104E
172.12.34.0     11.1.1.1        423         0x80000007 0x00C448
172.12.123.0    11.1.1.1        683         0x80000007 0x00E3D0

                Summary ASB Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
22.2.2.2        11.1.1.1        423         0x80000007 0x0018B3

                Router Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum Link count
5.5.5.5         5.5.5.5         1061        0x8000000B 0x00B6AC 1
11.1.1.1        11.1.1.1        1431        0x8000000C 0x00D39D 1

                Net Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.15.1     11.1.1.1        1431        0x80000008 0x001D17

                Summary Net Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         11.1.1.1        1431        0x80000007 0x008697
2.2.2.2         11.1.1.1        1431        0x80000007 0x00DAFE
3.3.3.3         11.1.1.1        1431        0x80000007 0x00AC29
11.1.1.1        11.1.1.1        1431        0x80000007 0x000410
22.2.2.2        11.1.1.1        1431        0x80000007 0x00D5EF
33.3.3.3        11.1.1.1        1431        0x80000007 0x002592
172.12.34.0     11.1.1.1        1431        0x80000007 0x006A9C
172.12.123.0    11.1.1.1        1431        0x80000007 0x008925

                Type-7 AS External Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum Tag
5.5.5.5         5.5.5.5         548         0x80000001 0x006756 100
55.5.5.0        5.5.5.5         548         0x80000001 0x000D83 100

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
5.5.5.5         11.1.1.1        547         0x80000001 0x001AB3 100
55.5.5.0        11.1.1.1        547         0x80000001 0x00BFE0 100
172.12.23.0     22.2.2.2        453         0x80000007 0x00141B 0
R1#

Wooooooah NELLY!!! That is a lot of output, but it perfectly demonstrates that Type 7 LSA’s (Routes Redistributed in NSSA’s) are defined by their network # in the LS DB but not ASBR’s outside of NSSA area – Another very good to know piece of information.

All sorts of good information as we piece LSA’s as a whole together!

So I am curious if R2 will not see the networks, as we know LSA Type 5’s will not enter an NSSA Area, will NSSA Redistributed routes not leave NSSA Areas? :

R2#sh ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/65] via 172.12.123.1, 03:15:10, Serial0/0
     33.0.0.0/32 is subnetted, 1 subnets
O       33.3.3.3 [110/65] via 172.12.123.3, 03:15:10, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/65] via 172.12.123.3, 03:15:10, Serial0/0
     55.0.0.0/24 is subnetted, 1 subnets
O E1    55.5.5.0 [110/85] via 172.12.123.1, 00:14:34, Serial0/0
     5.0.0.0/32 is subnetted, 1 subnets
O E1    5.5.5.5 [110/85] via 172.12.123.1, 00:14:34, Serial0/0
     172.12.0.0/24 is subnetted, 4 subnets
O IA    172.12.34.0 [110/65] via 172.12.123.3, 03:15:10, Serial0/0
O IA    172.12.15.0 [110/65] via 172.12.123.1, 03:15:10, Serial0/0
     11.0.0.0/32 is subnetted, 1 subnets
O       11.1.1.1 [110/65] via 172.12.123.1, 03:15:10, Serial0/0
R2#

So an ASBR outside of an NSSA will create only Type 5 LSA’s that are not allowed inside the NSSA Area, however an ASBR inside the NSSA creates both Type 7 LSA’s for routers inside the NSSA Area, and also creates Type 5 LSA’s to be flooded outside of the NSSA.

^ That is the information you need to know to pass this beast of an exam. Moving on.

Next lets first look at R4’s current Route table, and then we will configure it as a Stub Area, as the ultimate goal is to keep routing tables complete and concise which this Area only has one way out so it’s the perfect candidate!

However, first we’ll start with a look at it’s current “sh ip route” and “sh ip ospf data” as we turn it first into a Stub Area, and then a Total Stub Area:

R4#sh ip ospf data

            OSPF Router with ID (4.4.4.4) (Process ID 1)

                Router Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum Link count
4.4.4.4         4.4.4.4         1019        0x80000005 0x000D45 1
33.3.3.3        33.3.3.3        1020        0x80000003 0x00BB64 1

                Net Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.34.3     33.3.3.3        1020        0x80000001 0x004DAA

                Summary Net Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         33.3.3.3        975         0x80000001 0x007E4F
2.2.2.2         33.3.3.3        855         0x80000001 0x005079
3.3.3.3         33.3.3.3        1059        0x80000001 0x009F66
11.1.1.1        33.3.3.3        975         0x80000001 0x00FBC7
22.2.2.2        33.3.3.3        855         0x80000001 0x004B6A
33.3.3.3        33.3.3.3        1059        0x80000001 0x0018CF
172.12.15.0     33.3.3.3        975         0x80000001 0x00B158
172.12.123.0    33.3.3.3        980         0x80000003 0x00FAA1

                Summary ASB Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum
11.1.1.1        33.3.3.3        975         0x80000001 0x00E3DF
22.2.2.2        33.3.3.3        855         0x80000001 0x003382

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
5.5.5.5         11.1.1.1        965         0x80000001 0x001AB3 100
55.5.5.0        11.1.1.1        965         0x80000001 0x00BFE0 100
172.12.23.0     22.2.2.2        1007        0x80000001 0x002015 0
R4#
R4#
R4#sh ip route ospf

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
O IA     1.1.1.1 [110/66] via 172.12.34.3, 00:16:43, FastEthernet0/1
      2.0.0.0/32 is subnetted, 1 subnets
O IA     2.2.2.2 [110/66] via 172.12.34.3, 00:14:43, FastEthernet0/1
      3.0.0.0/32 is subnetted, 1 subnets
O IA     3.3.3.3 [110/2] via 172.12.34.3, 00:17:24, FastEthernet0/1
      5.0.0.0/32 is subnetted, 1 subnets
O E1     5.5.5.5 [110/86] via 172.12.34.3, 00:16:32, FastEthernet0/1
      11.0.0.0/32 is subnetted, 1 subnets
O IA     11.1.1.1 [110/66] via 172.12.34.3, 00:16:43, FastEthernet0/1
      22.0.0.0/32 is subnetted, 1 subnets
O IA     22.2.2.2 [110/66] via 172.12.34.3, 00:14:43, FastEthernet0/1
      33.0.0.0/32 is subnetted, 1 subnets
O IA     33.3.3.3 [110/2] via 172.12.34.3, 00:17:24, FastEthernet0/1
      55.0.0.0/24 is subnetted, 1 subnets
O E1     55.5.5.0 [110/86] via 172.12.34.3, 00:16:32, FastEthernet0/1
      172.12.0.0/16 is variably subnetted, 5 subnets, 2 masks
O IA     172.12.15.0/24 [110/66] via 172.12.34.3, 00:16:43, FastEthernet0/1
O E1     172.12.23.0/24 [110/85] via 172.12.34.3, 00:14:38, FastEthernet0/1
O IA     172.12.123.0/24 [110/65] via 172.12.34.3, 00:16:48, FastEthernet0/1
R4#

You should be able to read right down that list and say “This router has a Type 1, 2, 3, 4, and 5 LSA’s coming to it” at this point without thinking twice.

I wanted to show the route table as well, as that will shrink along with the Stubbing of this network, which the purpose of stubbing is really breaking it down to a single default route out of the network since it only has one path it can take – However we must know how it impacts the flow of LSA’s.

That being said, I hope the LSA Database is starting to burn into your memory, and lets make are 34 a Stub Area:

R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#router ospf 1
R4(config-router)#area 34 stub
R4(config-router)#
*Apr 26 00:28:13.639: %OSPF-5-ADJCHG: Process 1, Nbr 33.3.3.3 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
R4(config-router)#
ASR#3
[Resuming connection 3 to r3 … ]

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#router ospf 1
R3(config-router)#area 34 stub
R3(config-router)#
*Mar 31 19:28:58.966: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
*Mar 31 19:28:59.174: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on FastEthernet0/1 from LOADING to FULL, Loading Done
R3(config-router)#

As I mentioned, creating a Stub network will take the Adjacency down just as long as it takes you to configure both sides, along with NSSA Area configuration!

So let’s see what is happening on R4 now:

R4#sh ip ospf data

            OSPF Router with ID (4.4.4.4) (Process ID 1)

                Router Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum Link count
4.4.4.4         4.4.4.4         112         0x80000007 0x00272B 1
33.3.3.3        33.3.3.3        1673        0x80000003 0x00BB64 1

                Net Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.34.3     33.3.3.3        113         0x80000002 0x00698F

                Summary Net Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         33.3.3.3        113         0x80000001 0x0048CB
1.1.1.1         33.3.3.3        113         0x80000002 0x009A34
2.2.2.2         33.3.3.3        113         0x80000002 0x006C5E
3.3.3.3         33.3.3.3        113         0x80000002 0x00BB4B
11.1.1.1        33.3.3.3        113         0x80000002 0x0018AC
22.2.2.2        33.3.3.3        113         0x80000002 0x00674F
33.3.3.3        33.3.3.3        113         0x80000002 0x0034B4
172.12.15.0     33.3.3.3        113         0x80000002 0x00CD3D
172.12.123.0    33.3.3.3        113         0x80000004 0x001786
R4#

So we have lost our Type 4 and Type 5 LSA’s, but still have Types 1, 2, and 3 in the LS DB, and if you look carefully you can see it’s added a default route with the Advertising Router being R3 in our Type 3 LSA’s portion of the table “Summary Net Link States” (more on this soon). Lets look at the route table to see what exactly has happened there:

R4#sh ip route ospf

Gateway of last resort is 172.12.34.3 to network 0.0.0.0

O*IA  0.0.0.0/0 [110/2] via 172.12.34.3, 00:04:18, FastEthernet0/1
      1.0.0.0/32 is subnetted, 1 subnets
O IA     1.1.1.1 [110/66] via 172.12.34.3, 00:04:18, FastEthernet0/1
      2.0.0.0/32 is subnetted, 1 subnets
O IA     2.2.2.2 [110/66] via 172.12.34.3, 00:04:18, FastEthernet0/1
      3.0.0.0/32 is subnetted, 1 subnets
O IA     3.3.3.3 [110/2] via 172.12.34.3, 00:04:18, FastEthernet0/1
      11.0.0.0/32 is subnetted, 1 subnets
O IA     11.1.1.1 [110/66] via 172.12.34.3, 00:04:18, FastEthernet0/1
      22.0.0.0/32 is subnetted, 1 subnets
O IA     22.2.2.2 [110/66] via 172.12.34.3, 00:04:18, FastEthernet0/1
      33.0.0.0/32 is subnetted, 1 subnets
O IA     33.3.3.3 [110/2] via 172.12.34.3, 00:04:18, FastEthernet0/1
      172.12.0.0/16 is variably subnetted, 4 subnets, 2 masks
O IA     172.12.15.0/24 [110/66] via 172.12.34.3, 00:04:18, FastEthernet0/1
O IA     172.12.123.0/24 [110/65] via 172.12.34.3, 00:04:18, FastEthernet0/1
R4#

So making the network a Stub Area has accomplished is stopping LSA Type 4’s and 5’s into the Area, so it won’t have External Routes from the Type 5’s as is doesn’t even know a path back to the ASBR provided by the Type 4 LSA, and it made a Default route to it’s only next hop out into the network.

So now we’ll take this that one step further, and make this Area a Total Stub, Stub Area:

R3(config-router)#no area 34 stub
*Mar 31 19:41:07.027: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
R3(config-router)#area 34 stub no-summary
R3(config-router)#
*Mar 31 19:41:20.341: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on FastEthernet0/1 from DOWN to DOWN, Neighbor Down: Adjacency forced to reset
R3(config-router)#

It does only need to be issued on the edge router, but it can be issued on both, so lets see how the LS DB likes THAT on R4:

R4#sh ip ospf data

            OSPF Router with ID (4.4.4.4) (Process ID 1)

                Router Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum Link count
4.4.4.4         4.4.4.4         100         0x8000000A 0x00212E 1
33.3.3.3        33.3.3.3        101         0x80000006 0x00D34B 1

                Net Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.34.3     33.3.3.3        97          0x80000005 0x006392

                Summary Net Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         33.3.3.3        851         0x80000001 0x0048CB
R4#

Note the Type 3 LSA in the LS DB is the default route in the OSPF table, as seen here:

R4#sh ip route ospf

Gateway of last resort is 172.12.34.3 to network 0.0.0.0

O*IA  0.0.0.0/0 [110/2] via 172.12.34.3, 00:03:01, FastEthernet0/1
R4#

Two points here, the default route has not changed from Stub to Total-Stub Stub Area as can be seen when comparing the two, and the only thing that making it a Total Stub was disallowing LSA Type 3 “Summary” LSA’s into the area (hence the command no-summary to make it a Total Stub) with one exception explained shortly.

So making an Area a Stub will Stop LSA 4 and 5 types from entering, and a Total Stub stops Type 3 LSA’s as well, leaving only Type 1’s and Type 2’s left inside of it.

Speaking of which, we can still gets Type 1’s and type 2’s inside of this area, lets try to make a couple of loopbacks to confirm this:

R4(config)#router ospf 1
R4(config-router)#network 4.4.4.4 0.0.0.0 area 34
R4(config-router)#^Z
R4#

I did a “sh ip route ospf” once again on R4 expecting to see it, and facepalmed as I did not see it there, and realized I was looking for a directly connected route in the ospf route table again – I think at this point I’m on the brink of mental exhaustion.

I actually was like “Where the diddly do is my route?” when it wasn’t there, and this is the phases of confirming the route is within the Area:

R4#sh ip route ospf

Gateway of last resort is 172.12.34.3 to network 0.0.0.0

O*IA  0.0.0.0/0 [110/2] via 172.12.34.3, 00:24:47, FastEthernet0/1

What the diddly do!?!?!

R4#sh ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES NVRAM  administratively down down
FastEthernet0/1            172.12.34.4     YES NVRAM  up                    up
Loopback4                  4.4.4.4         YES NVRAM  up                    up

Yep the interface is configured as usual, is OSPF even seeing it??

R4#sh ip ospf data

            OSPF Router with ID (4.4.4.4) (Process ID 1)

                Router Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum Link count
4.4.4.4         4.4.4.4         267         0x8000000B 0x00022B 2
33.3.3.3        33.3.3.3        1537        0x80000006 0x00D34B 1

                Net Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.34.3     33.3.3.3        1533        0x80000005 0x006392

                Summary Net Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         33.3.3.3        2287        0x80000001 0x0048CB

Omg, I fell for the connected route thing again!!!

However it highlights one important aspect of all this LSA / Router Type brainwashing, and that is this real world or even lab world use for knowing the LS DB, I can verify that 4.4.4.4 is part of Area 34 even if I don’t see it on R4’s OSPF Specific route table – But I bet I can on R3! :

R3#sh ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/65] via 172.12.123.1, 00:15:23, Serial0/2
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/65] via 172.12.123.2, 00:15:23, Serial0/2
     4.0.0.0/32 is subnetted, 1 subnets
O       4.4.4.4 [110/2] via 172.12.34.4, 00:15:23, FastEthernet0/1
     55.0.0.0/24 is subnetted, 1 subnets
O E1    55.5.5.0 [110/85] via 172.12.123.1, 00:15:23, Serial0/2
     5.0.0.0/32 is subnetted, 1 subnets
O E1    5.5.5.5 [110/85] via 172.12.123.1, 00:15:23, Serial0/2
     172.12.0.0/24 is subnetted, 4 subnets
O IA    172.12.15.0 [110/65] via 172.12.123.1, 00:15:23, Serial0/2
     22.0.0.0/32 is subnetted, 1 subnets
O       22.2.2.2 [110/65] via 172.12.123.2, 00:36:45, Serial0/2
     11.0.0.0/32 is subnetted, 1 subnets
O       11.1.1.1 [110/65] via 172.12.123.1, 00:36:45, Serial0/2
R3#

In fact while on R3, let us gander upon its LS DB, because there are a few things to point out in it’s LS DB that are worth noting:

R3#sh ip ospf data

            OSPF Router with ID (33.3.3.3) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
11.1.1.1        11.1.1.1        787         0x80000004 0x00DF68 2
22.2.2.2        22.2.2.2        729         0x80000004 0x009686 2
33.3.3.3        33.3.3.3        708         0x80000004 0x00866D 2

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.123.1    11.1.1.1        531         0x80000004 0x00AFEB

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         11.1.1.1        1041        0x80000003 0x00E83F
2.2.2.2         22.2.2.2        729         0x80000003 0x0042D3
3.3.3.3         33.3.3.3        708         0x80000003 0x009B68
4.4.4.4         33.3.3.3        1150        0x80000001 0x007B85
172.12.15.0     11.1.1.1        787         0x80000007 0x00144C
172.12.34.0     33.3.3.3        449         0x80000002 0x005BDA

                Router Link States (Area 3)

Link ID         ADV Router      Age         Seq#       Checksum Link count
33.3.3.3        33.3.3.3        711         0x80000003 0x00E4E9 1

                Summary Net Link States (Area 3)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         33.3.3.3        711         0x80000003 0x007A51
2.2.2.2         33.3.3.3        711         0x80000003 0x004C7B
4.4.4.4         33.3.3.3        1153        0x80000001 0x007B85
11.1.1.1        33.3.3.3        711         0x80000003 0x00F7C9
22.2.2.2        33.3.3.3        711         0x80000003 0x00476C
33.3.3.3        33.3.3.3        711         0x80000003 0x0014D1
172.12.15.0     33.3.3.3        711         0x80000003 0x00AD5A
172.12.34.0     33.3.3.3        452         0x80000002 0x005BDA
172.12.123.0    33.3.3.3        711         0x80000005 0x00F6A3

                Summary ASB Link States (Area 3)

Link ID         ADV Router      Age         Seq#       Checksum
11.1.1.1        33.3.3.3        711         0x80000003 0x00DFE1
22.2.2.2        33.3.3.3        714         0x80000003 0x002F84

                Router Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum Link count
4.4.4.4         4.4.4.4         455         0x8000000C 0x00FF2C 2
33.3.3.3        33.3.3.3        454         0x80000007 0x00D14C 1

                Net Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.34.3     33.3.3.3        454         0x80000006 0x006193

                Summary Net Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         33.3.3.3        454         0x80000002 0x0046CC

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
5.5.5.5         11.1.1.1        792         0x80000003 0x0016B5 100
55.5.5.0        11.1.1.1        792         0x80000003 0x00BBE2 100
172.12.23.0     22.2.2.2        741         0x80000003 0x001C17 0
R3#

R3 is flooding Type 3 LSA’s into all other areas despite Area 34 being closed shut to incoming Type 3, 4, and 5 LSA’s, but also that R3 is actually flooding the default route in R4’s OSPF table is a Type 3 LSA, so this is something of a curiosity.

This Type 3 LSA default network was created by making a Stub Area which filters LSA Type 4 and 5’s from entering it, but when I made it a Total-Stub Stub Area, R3 is still flooding the single LSA Type 3 default route into Area 34.

So in as can be seen in the output the Area does allow the flooding of a Type 3 LSA for Total-Stub Stub’s, but only as a default route to its upstream Stub neighbor.

If on exam day I were asked “Do Total-Stub Stub Areas get Type 3 LSA’s injected into them?” there really is no black and white answer to that unless the question mentions something about R3’s default route Advertisement.

Food for thought.

Now onto the final looksy at LSA traffic before I face down on my keyboard, I want to demonstrate what happens in our NSSA when we make that an NSSA Total-Stub Area:

R1(config-router)#no area 15 nssa
R1(config-router)#area
*Apr 26 03:00:33.647: %OSPF-5-ADJCHG: Process 1, Nbr 55.5.5.5 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
R1(config-router)#area 15 nssa no-summary
R1(config-router)#
*Apr 26 03:00:50.031: %OSPF-5-ADJCHG: Process 1, Nbr 55.5.5.5 on FastEthernet0/1 from DOWN to DOWN, Neighbor Down: Adjacency forced to reset
*Apr 26 03:00:50.955: %OSPF-5-ADJCHG: Process 1, Nbr 55.5.5.5 on FastEthernet0/1 from LOADING to FULL, Loading Done
R1(config-router)#

So we’ve made this a “Total-Stub Not-So-Stubby-Area” which is clear as mud when you read it, right? So first lets take another look at R5’s “before” LS DB and OSPF route table:

R5#sh ip ospf database

            OSPF Router with ID (5.5.5.5) (Process ID 1)

                Router Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum Link count
5.5.5.5         5.5.5.5         150         0x80000005 0x00BCAE 1
11.1.1.1        11.1.1.1        147         0x80000007 0x00DD98 1

                Net Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.15.1     11.1.1.1        147         0x80000003 0x002712

                Summary Net Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         11.1.1.1        152         0x80000002 0x009092
2.2.2.2         11.1.1.1        152         0x80000002 0x00E4F9
3.3.3.3         11.1.1.1        152         0x80000002 0x00B624
11.1.1.1        11.1.1.1        152         0x80000002 0x000E0B
22.2.2.2        11.1.1.1        152         0x80000002 0x00DFEA
33.3.3.3        11.1.1.1        152         0x80000002 0x002F8D
172.12.34.0     11.1.1.1        152         0x80000002 0x007497
172.12.123.0    11.1.1.1        160         0x80000002 0x009320

R5#sh ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/2] via 172.12.15.1, 00:02:46, FastEthernet0/1
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/66] via 172.12.15.1, 00:02:46, FastEthernet0/1
     33.0.0.0/32 is subnetted, 1 subnets
O IA    33.3.3.3 [110/66] via 172.12.15.1, 00:02:46, FastEthernet0/1
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/66] via 172.12.15.1, 00:02:46, FastEthernet0/1
     172.12.0.0/24 is subnetted, 3 subnets
O IA    172.12.34.0 [110/66] via 172.12.15.1, 00:02:46, FastEthernet0/1
O IA    172.12.123.0 [110/65] via 172.12.15.1, 00:02:46, FastEthernet0/1
     22.0.0.0/32 is subnetted, 1 subnets
O IA    22.2.2.2 [110/66] via 172.12.15.1, 00:02:46, FastEthernet0/1
     11.0.0.0/32 is subnetted, 1 subnets
O IA    11.1.1.1 [110/2] via 172.12.15.1, 00:02:46, FastEthernet0/1
R5#

And after making the NSSA an NSSA Total-Stub:

R5#sh ip ospf data

            OSPF Router with ID (55.5.5.5) (Process ID 1)

                Router Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum Link count
11.1.1.1        11.1.1.1        345         0x8000000D 0x00F972 1
55.5.5.5        55.5.5.5        934         0x80000006 0x009867 1

                Net Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.15.5     55.5.5.5        934         0x80000004 0x006267

                Summary Net Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         11.1.1.1        350         0x80000001 0x00C067

                Type-7 AS External Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum Tag
5.5.5.5         55.5.5.5        934         0x80000005 0x009BEB 100
55.5.5.0        55.5.5.5        934         0x80000005 0x004119 100
R5#

So by my quackulations, this will only contain the same type of default route R4 had in its routing table:

R5#sh ip route ospf
O*IA 0.0.0.0/0 [110/2] via 172.12.15.1, 00:08:57, FastEthernet0/1
R5#

So it turns out whether you add “… no-summary” to a Stub or NSSA network type, it will filter any Type 3 LSA’s, except the default route flooded into the Total-Stub network by its upstream Stub neighbor!

A quick look at R1’s new LS DB entries for Area 15 and its routes:

R5#sh ip ospf data

                Router Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum Link count
11.1.1.1        11.1.1.1        903         0x8000000D 0x00F972 1
55.5.5.5        55.5.5.5        1493        0x80000006 0x009867 1

                Net Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.15.5     55.5.5.5        1493        0x80000004 0x006267

                Summary Net Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         11.1.1.1        908         0x80000001 0x00C067

                Type-7 AS External Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum Tag
5.5.5.5         55.5.5.5        1492        0x80000005 0x009BEB 100
55.5.5.0        55.5.5.5        1492        0x80000005 0x004119 100

Generating Type 1 LSA’s, reciving Type 2 LSA from the DR, as well as a Type 3 LSA with the default route from the Total-Stub configuration, and still generating Type 7 LSA’s from Redistributing connected routes.

One last look at R1’s “sh ip route ospf” :

R1# sh ip route ospf

Gateway of last resort is not set

      2.0.0.0/32 is subnetted, 1 subnets
O IA     2.2.2.2 [110/65] via 172.12.123.2, 00:16:31, Serial0/0/0
      3.0.0.0/32 is subnetted, 1 subnets
O IA     3.3.3.3 [110/65] via 172.12.123.3, 00:16:31, Serial0/0/0
      4.0.0.0/32 is subnetted, 1 subnets
O IA     4.4.4.4 [110/66] via 172.12.123.3, 00:16:31, Serial0/0/0
      5.0.0.0/32 is subnetted, 1 subnets
O N1     5.5.5.5 [110/21] via 172.12.15.5, 00:16:21, FastEthernet0/1
      22.0.0.0/32 is subnetted, 1 subnets
O        22.2.2.2 [110/65] via 172.12.123.2, 00:16:31, Serial0/0/0
      33.0.0.0/32 is subnetted, 1 subnets
O        33.3.3.3 [110/65] via 172.12.123.3, 00:16:31, Serial0/0/0
      55.0.0.0/24 is subnetted, 1 subnets
O N1     55.5.5.0 [110/21] via 172.12.15.5, 00:16:21, FastEthernet0/1
      172.12.0.0/16 is variably subnetted, 6 subnets, 2 masks
O E1     172.12.23.0/24 [110/84] via 172.12.123.2, 00:16:31, Serial0/0/0
O IA     172.12.34.0/24 [110/65] via 172.12.123.3, 00:16:31, Serial0/0/0
R1#

Note that it receives those routes as N1 routes, but any other router will see them as E1, and that about wraps up my deep dive into LSA and OSPF router types as I am going brain dead staring at the CLI (hurts so good).

You can extract some about the entire network from the local router with the Link State Database, so I really hope if you didn’t read it here, you read about it elsewhere as the topic of LSA’s across different network types is so broad its prime ground for exam questions for the ROUTE exam.

Not sure what is next yet, but I will stop rambling about LSA’s now, and move onto another DEEP dive before exam day!

I am now officially fried, and doing something other than studying now 🙂

Part 2: OSPF LSA DEEP Dive, LSA Types 4 / 5, and turn Area 15 to an NSSA to see what happens with the LS Database!

OSPF_LSA_Deep_Dive

I will start this off by stating that we will start redistribution on the ASBR specified R2 to examine LSA types 4 and 5 (and where we can spot them), and R1 will eventually also be turned into an ASBR when we redistribute some loopback routes into the NSSA Area so we can review type 7 (So the Topology above may not stay 100% accurate as we move along).

Now the Type 4 LSA “ASBR Summary LSA” is created ONLY on ABR’s, so they can build the Shortest Path Tree (SPT) to the ASBR, which is triggered by a router becoming an ASBR in the first place. Being that R2 is technically an ABR (has interface in Area 0 and Area 2), I am curious to see how it will announce itself in “sh ip ospf” output and in the LSA DB.

Before getting into output, let us clarify that Type 5 LSA’s are created only on ASBR’s outside of NSSA OSPF network types, contained the external route information. These LSA’s advertise the O E2 routes with the seed / default metric of 20, supposedly the metric back to the ASBR, which can be changed (which I will) to be O E1 routes which give a true metric / cost from the local router to the destination network.

This is completely uncharted waters for me, so lets get our feet wet:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router ospf 1
R2(config-router)#redistribute rip ?
  metric       Metric for redistributed routes
  metric-type  OSPF/IS-IS exterior metric type for redistributed routes
  route-map    Route map reference
  subnets      Consider subnets for redistribution into OSPF
  tag          Set tag for routes redistributed into OSPF
  <cr>

R2(config-router)#redistribute rip metric-type 1 subnets

We now have R2 as our ASBR flooding type 5 LSA’s into all non-stub, non-total stub, and non-NSSA area’s. As to my confusion as to whether it would hold its rank as an ABR as well as ASBR:

R2#sh ip ospf
 Routing Process “ospf 1” with ID 22.2.2.2
 Start time: 00:01:37.095, Time elapsed: 00:48:12.161
 Supports only single TOS(TOS0) routes
 Supports opaque LSA
 Supports Link-local Signaling (LLS)
 Supports area transit capability
 It is an area border and autonomous system boundary router

 Redistributing External Routes from,
    rip, includes subnets in redistribution

It does show R2 as both an ABR and ASBR, and I cut off a lot of good Area information with this command (“sh ip ospf”), however you can also see right away what type of network types are being redistributed directly under the highlighted line of router type.

So lets see what this added to R2’s LS DB, if anything:

R2#sh ip ospf database

            OSPF Router with ID (22.2.2.2) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
11.1.1.1        11.1.1.1        386         0x80000004 0x00D970 2
22.2.2.2        22.2.2.2        1572        0x80000004 0x009686 2
33.3.3.3        33.3.3.3        341         0x80000004 0x00866D 2

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.123.1    11.1.1.1        386         0x80000003 0x00B1EA

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         11.1.1.1        639         0x80000003 0x00E83F
2.2.2.2         22.2.2.2        363         0x80000003 0x0042D3
3.3.3.3         33.3.3.3        341         0x80000003 0x009B68
172.12.15.0     11.1.1.1        386         0x80000005 0x00184A
172.12.34.0     33.3.3.3        341         0x80000003 0x0059DB

                Router Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum Link count
22.2.2.2        22.2.2.2        1572        0x80000003 0x00F1FA 1

                Summary Net Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         22.2.2.2        372         0x80000003 0x00F2E6
3.3.3.3         22.2.2.2        372         0x80000003 0x00963B
11.1.1.1        22.2.2.2        372         0x80000003 0x00705F
22.2.2.2        22.2.2.2        372         0x80000003 0x003DC4
33.3.3.3        22.2.2.2        372         0x80000003 0x000FA4
172.12.15.0     22.2.2.2        372         0x80000003 0x0026EF
172.12.34.0     22.2.2.2        372         0x80000003 0x0054AE
172.12.123.0    22.2.2.2        372         0x80000005 0x006F39

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag

172.12.23.0     22.2.2.2        1580        0x80000001 0x002015 0

R2#

So R2 is now showing a Type-5 External Link States section in the LS DB, that includes the network being redistributed, and the RID of the router (this router) as the Advertising Router.

So I felt like an idiot afterward, but I went to verify the routes on R3 and show some output from there, however I forgot R3 is directly connected to that network so it isn’t going to show up in the OSPF route table!

However, lets take a look at the OSPF LS DB on R3 to make sure it is seeing the Type 5 LSA’s and possibly spot a Type 4 somewhere in the output:

R3#sh ip ospf database

            OSPF Router with ID (33.3.3.3) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
11.1.1.1        11.1.1.1        1692        0x80000004 0x00D970 2
22.2.2.2        22.2.2.2        911         0x80000005 0x009487 2
33.3.3.3        33.3.3.3        1645        0x80000004 0x00866D 2

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.123.1    11.1.1.1        1692        0x80000003 0x00B1EA

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         11.1.1.1        1945        0x80000003 0x00E83F
2.2.2.2         22.2.2.2        1671        0x80000003 0x0042D3
3.3.3.3         33.3.3.3        1645        0x80000003 0x009B68
172.12.15.0     11.1.1.1        1692        0x80000005 0x00184A
172.12.34.0     33.3.3.3        1645        0x80000003 0x0059DB

                Router Link States (Area 3)

Link ID         ADV Router      Age         Seq#       Checksum Link count
33.3.3.3        33.3.3.3        1645        0x80000003 0x00E4E9 1

                Summary Net Link States (Area 3)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         33.3.3.3        1652        0x80000003 0x007A51
2.2.2.2         33.3.3.3        1652        0x80000003 0x004C7B
11.1.1.1        33.3.3.3        1652        0x80000003 0x00F7C9
22.2.2.2        33.3.3.3        1652        0x80000003 0x00476C
33.3.3.3        33.3.3.3        1652        0x80000003 0x0014D1
172.12.15.0     33.3.3.3        1652        0x80000003 0x00AD5A
172.12.34.0     33.3.3.3        1652        0x80000003 0x0059DB
172.12.123.0    33.3.3.3        1652        0x80000005 0x00F6A3

                Summary ASB Link States (Area 3)

Link ID         ADV Router      Age         Seq#       Checksum

22.2.2.2        33.3.3.3        902         0x80000002 0x003183

                Router Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum Link count
4.4.4.4         4.4.4.4         1607        0x80000005 0x00173A 1
33.3.3.3        33.3.3.3        1665        0x80000005 0x00C15B 1

                Net Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.34.4     4.4.4.4         1620        0x80000003 0x009876

                Summary Net Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         33.3.3.3        1665        0x80000003 0x007A51
2.2.2.2         33.3.3.3        1665        0x80000003 0x004C7B
3.3.3.3         33.3.3.3        1665        0x80000003 0x009B68
11.1.1.1        33.3.3.3        1665        0x80000003 0x00F7C9
22.2.2.2        33.3.3.3        1665        0x80000003 0x00476C
33.3.3.3        33.3.3.3        1665        0x80000003 0x0014D1
172.12.15.0     33.3.3.3        1665        0x80000003 0x00AD5A
172.12.123.0    33.3.3.3        1665        0x80000005 0x00F6A3

                Summary ASB Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum

22.2.2.2        33.3.3.3        916         0x80000002 0x003183

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag

172.12.23.0     22.2.2.2        937         0x80000002 0x001E16 0

R3#

So as can be seen highlighted in blue we have our LSA Type 4 “Summary ASB Link States” LSA’s coming from ADV(ertising) Router 2 from it’s RID 22.2.2.2, which is seen being flooded into every Area except for the common Area (o) with the ASBR on R3, and highlighted in red is the Type 5 LSA advertising the redistributed network under Link ID along with R2’s RID.

What I found interesting is that the Type 5 LSA has no Area attached to it as can be seen in the output, it is for all Area’s on the Routers LS DB, and I verified this to be the case on all other routers….

… Including R5 BEFORE I may it an NSSA Area:

R5#sh ip ospf database

            OSPF Router with ID (5.5.5.5) (Process ID 1)

                Router Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum Link count
5.5.5.5         5.5.5.5         336         0x80000003 0x001B58 1
11.1.1.1        11.1.1.1        340         0x80000005 0x00364A 1

                Net Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.15.1     11.1.1.1        341         0x80000001 0x0085BB

                Summary Net Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         11.1.1.1        675         0x80000001 0x00EC3D
2.2.2.2         11.1.1.1        321         0x80000001 0x0041A4
3.3.3.3         11.1.1.1        321         0x80000001 0x0013CE
11.1.1.1        11.1.1.1        675         0x80000001 0x006AB5
22.2.2.2        11.1.1.1        321         0x80000001 0x003C95
33.3.3.3        11.1.1.1        321         0x80000001 0x008B38
172.12.34.0     11.1.1.1        321         0x80000001 0x00D042
172.12.123.0    11.1.1.1        682         0x80000001 0x00EFCA

                Summary ASB Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum

22.2.2.2        11.1.1.1        327         0x80000001 0x0024AD

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag

172.12.23.0     22.2.2.2        350         0x80000001 0x002015 0

R5#sh ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/2] via 172.12.15.1, 00:07:09, FastEthernet0/1
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/66] via 172.12.15.1, 00:06:58, FastEthernet0/1
     33.0.0.0/32 is subnetted, 1 subnets
O IA    33.3.3.3 [110/66] via 172.12.15.1, 00:06:58, FastEthernet0/1
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/66] via 172.12.15.1, 00:06:58, FastEthernet0/1
     172.12.0.0/24 is subnetted, 4 subnets
O IA    172.12.34.0 [110/66] via 172.12.15.1, 00:06:58, FastEthernet0/1
O E1    172.12.23.0 [110/85] via 172.12.15.1, 00:06:53, FastEthernet0/1

O IA    172.12.123.0 [110/65] via 172.12.15.1, 00:07:09, FastEthernet0/1
     22.0.0.0/32 is subnetted, 1 subnets
O IA    22.2.2.2 [110/66] via 172.12.15.1, 00:06:58, FastEthernet0/1
     11.0.0.0/32 is subnetted, 1 subnets
O IA    11.1.1.1 [110/2] via 172.12.15.1, 00:07:09, FastEthernet0/1
R5#

So the Type 4’s and Type 5 look as they should, and we also see a Type 2 in the output, because R5 is directly connected via FastEthernet, so it is on a non-point-to-point connection (broadcast connection).

So now that it is working, let’s turn it into an NSSA Area, and see what happens to R5’s LS DB and ospf route table:

R5#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R5(config)#router ospf 1
R5(config-router)#area 15 nssa
R5(config-router)#
*Mar 31 20:00:19.008: %OSPF-5-ADJCHG: Process 1, Nbr 11.1.1.1 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
R5(config-router)#
ASR#1
[Resuming connection 1 to r1 … ]

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#router ospf 1
R1(config-router)#area 15 nssa
R1(config-router)#
*Apr 25 20:28:28.519: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
*Apr 25 20:28:29.455: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on FastEthernet0/1 from LOADING to FULL, Loading Done
R1(config-router)#
ASR#5
[Resuming connection 5 to r5 … ]

*Mar 31 20:00:39.642: %OSPF-5-ADJCHG: Process 1, Nbr 11.1.1.1 on FastEthernet0/1 from LOADING to FULL, Loading Done
R5(config-router)#

Note that your Adjacencies drop when you reconfigure any kind of stub or NSSA Area 🙂

So lets see what’s new:

R5#sh ip ospf database

            OSPF Router with ID (5.5.5.5) (Process ID 1)

                Router Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum Link count
5.5.5.5         5.5.5.5         150         0x80000005 0x00BCAE 1
11.1.1.1        11.1.1.1        147         0x80000007 0x00DD98 1

                Net Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.15.1     11.1.1.1        147         0x80000003 0x002712

                Summary Net Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         11.1.1.1        152         0x80000002 0x009092
2.2.2.2         11.1.1.1        152         0x80000002 0x00E4F9
3.3.3.3         11.1.1.1        152         0x80000002 0x00B624
11.1.1.1        11.1.1.1        152         0x80000002 0x000E0B
22.2.2.2        11.1.1.1        152         0x80000002 0x00DFEA
33.3.3.3        11.1.1.1        152         0x80000002 0x002F8D
172.12.34.0     11.1.1.1        152         0x80000002 0x007497
172.12.123.0    11.1.1.1        160         0x80000002 0x009320

So as we can see Type 4 and Type 5 LSA’s are no longer reaching R5, which is exactly what we expect to see, and I will stop this post here as creating Type 7 LSA’s will be a gentle segway into the next topic put under a microscope – OSPF Stub Areas!

Part 1: OSPF LSA DEEP dive, starting with LSA Types 1 / 2 / 3, and an Intro to all LSA Types and OSPF Routers types!

OSPF_LSA_Deep_Dive

So we are back to OSPF, as I never really went into a deep dive with LSA types, or the LSA DataBase from different routers to show their perspective of the OSPF network caused by these Link State Advertisements.

I’ve only configured base OSPF and RIP configurations in this lab so far, the above Topology does NOT have NSSA / Stub / Redistribution configred at this point (though we will get there and examine some different routers LSA DB’s).

So first, I will start with a description of each LSA type of the 7 of them:

  • LSA Type 1 “Router” – “Router Link States” will be its header in the LSA DB, and the name is self explanatory, these LSA’s are generated by each router with updates on its local Link States, all router types generate and flood this LSA Type.
  • LSA Type 2 “Network” – “Net Link States” are only generated and sent by DR’s and BDR’s to routers in the Same Area, that are also on the same multi-access network type, LSA type stays within its own Area, only seen in NON-Point-to-Point network types
  • LSA Type 3 “Summary” – “Summary Net Link States” has nothing to do with summarization, but floods its summary of networks from one Area into others except for the Area it is part of – Not flooded into Total-Stub’d Areas (Stub or NSSA)
  • LSA Type 4 “Summary ASB” – “Summary ASB Link States” LSA type is only created by ABR’s back to the ASBR, so when redistribution is configured on the ASBR Router it flips a bit in its “Router LSA” (Type 1!), and the ABR(s) then create LSA type 4’s to pass along throughout the network giving OSPF neighbors the path back to the ASBR – Not flooded into Stub Areas.
  • LSA Type 5 “Autonomous System External Link State” – or “AS External Link States” in the OSPF LSA DB, these are your “O E1” and “O E2”  Redistributed routes, generated from the ASBR itself OUTSIDE an NSSA Area – Not flooded into Stub Areas.
  • LSA Type 6 – Not needed for the CCNP ROUTE, but it is for Multicast Extensions of OSPF (MOSPF), but again is not referenced in the the ROUTE exam, just wanted to mention for the sake of thoroughness
  • LSA Type 7 “NSSA LSA’s” – This type of LSA is generated by the ASBR INSIDE an NSSA Area does Redistribution, as Type 5 Redistribution LSA’s cannot enter an NSSA Area

Phew. So to cover what type of routers create which type of LSA’s ONE MORE TIME:

  • Type 1 – All Routers
  • Type 2 – All DR’s
  • Type 3, 4 – All ABR’s
  • Type 5 – ASBR’s OUTSIDE the NSSA Areas (NSSA’s don’t allow LSA type 5)
  • Type 6 – Reserved for MOSPF
  • Type 7 – ASBR’s INSIDE the NSSA Areas (Type 7 LSA’s [N1, N2 in route table])

It is VERY important to know which routers create what types of LSA’s, as this is such a heavy topic (up there with BGP), there is a high chance to see these topics on exam day!

The thing to watch for, is not necessarily in the question, but also in the answer, as the exam may present what seems like a correct answer but the behavior is incorrect, example:

You are looking at a topology above and the question asks “Which of the following commands will allow you to create an OSPF Summary Route for R1 that contain the links connected to R5?”

Then it will give you the correct configurations to summarize a route, but you cannot summarize OSPF routes on a router that is not directly connected to them, so all answers are wrong in that case – This is one example of Cisco’s “gotchas” that requires this deeper dive into understanding the behaviors so we don’t get got homie 🙂

So to kick this party off, lets take a look at R2’s LSA Database since it is smallest:

R2#sh ip ospf database

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         350         0x80000002 0x00DCA2 1
2.2.2.2         2.2.2.2         350         0x80000007 0x00E65D 2
3.3.3.3         3.3.3.3         351         0x80000007 0x001D10 2

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.123.1    1.1.1.1         346         0x80000004 0x0023BE

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         1.1.1.1         351         0x80000004 0x0041EF
2.2.2.2         2.2.2.2         1406        0x80000003 0x00F633
3.3.3.3         3.3.3.3         1373        0x80000003 0x00AA77
172.12.15.0     1.1.1.1         351         0x80000005 0x0072F9
172.12.34.0     3.3.3.3         1373        0x80000005 0x0064EC

                Router Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         1406        0x80000003 0x00A571 1

                Summary Net Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         2.2.2.2         340         0x80000001 0x00AB44
3.3.3.3         2.2.2.2         340         0x80000001 0x004F98
22.2.2.2        2.2.2.2         1164        0x80000002 0x00F323
33.3.3.3        2.2.2.2         340         0x80000001 0x00C702
172.12.15.0     2.2.2.2         340         0x80000001 0x00DE4D
172.12.34.0     2.2.2.2         340         0x80000001 0x000D0C
172.12.123.0    2.2.2.2         340         0x80000001 0x002C94
R2#

As can be seen it will show all connected OSPF Area’s LSA’s, and starting from the top:

  • Type 1: Router Link States, showing the “links” (RID’s) of all routers with an interface participating in Area 0, as can be see under Router Link States for Area 2 is only itself
  • Type 2: Network Link States, generated only on DR’s on non-point-to-point links, the DR finds these Multi-Access routers links and provides the DR physical interface IP along with the RID
  • Type 3: Summary Net Link States – These are our “O IA” routes, this LSA type is created by the BDR and flooded into Areas that is not its own, and given this confused me for quite awhile here so I want to explain Area 0’s and Area 2’s output in two different pieces

Area 0’s Summary Net Link States will only advertise routes to Areas it is not participating in, that is why you DON’T see 172.12.123.0 or any of the 11.x.x.x / 22.x.x.x / etc in the Database for Area 0.

Area 2’s Summary Net Link appears to contain all the routes so far, except for one, and that would be it’s own routes of 2.2.2.2 because it will not include routes from the Area that it is part of, however it will show every other route (including the main NBMA 172.12.123.0 route) within this Area of the OSPF DB.

So to this point, OSPF works in harmony with each other as LSA 1’s monitor all their connected links states and share them across to other OSPF neighbors, LSA 2’s generated by the DR make sure all Multi-Access routers are included and get updates, and our ABR’s as can be seen are flooding routes / networks not in their own Area into other Area’s.

That is about as thorough as I can get tonight, as the next post will be covering the rest of them, that just took an extremely long time to get absolutely accurate information regarding these!

I will continue on to clearly demonstrate and understand the upcoming Redistribution, and NSSA LSA types, I am hoping to get that into one post on my next write up!