OSPF external prefixes and the Type4 LSA deep dive – part 1 of 2

In my Demystifying the OSPF database post over here, I mentioned the following:

Type 4 – ASBR Summary LSA:
Type4′s can be a little bit confusing. When an ASBR advertises an external prefix, the next-hop will be the ASBR’s IP address. OSPF speakers in other areas need to know how to get to this ASBR. A Type4 will be originated by an ABR attached to the same area an an ASBR, and will have information of how to get to the ASBR. An ABR will also advertise a Type4 from another ABR if the ASBR is 2 areas away and so on.

This is not 100% correct though. Rather a type4 is originated by an ABR of other areas. This actually makes sense in the long run. Let’s lab it up to see.

R1 is redistributing it’s lo100 interface

From my previous post above, you would assume then that R2 would originate a Type4 LSA for R1 as soon as R1 becomes an ASBR. Let’s test this

R1(config)#int lo100
R1(config-if)#ip add
R1(config-if)#ip address 100.100.100.100 255.255.255.255
R1(config-if)#router ospf 1
R1(config-router)#redistribute connected subnets

R1 now considers itself an ASBR. This can be verified by checking the OSPF database:

R2#sh ip ospf database router 1.1.1.1 | include AS
  AS Boundary Router

So does R2 actually create a type 4? Let’s check that on a router in area 0:

R7#sh ip ospf database asbr-summary 

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

		Summary ASB Link States (Area 0)

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 1541
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(AS Boundary Router)
  Link State ID: 1.1.1.1 (AS Boundary Router address)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000007
  Checksum: 0xF1A
  Length: 28
  Network Mask: /0
	MTID: 0 	Metric: 1

Yes it does. So one could assume therefore that my previous statement was correct? No, because the story doesn’t end there…

Let’s first see WHY the type4 is needed in the first place. Marko from ipexpert already has a good explanation here: http://blog.ipexpert.com/2010/09/22/quick-look-into-ospf-database-external-and-asbr-summary-lsa/, but I wanted to explain it myself.

This all has to do with giving your routers enough information in order that they all know how to reach all networks in your topology. Let’s start with R1 redistributing it’s lo100 interface. In the database of area 12, R1 has originated a type5 LSA which can be seen as so:

R1#show ip ospf database external 100.100.100.100

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

		Type-5 AS External Link States

  LS age: 1880
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 100.100.100.100 (External Network Number )
  Advertising Router: 1.1.1.1
  LS Seq Number: 8000000A
  Checksum: 0xAD54
  Length: 36
  Network Mask: /32
	Metric Type: 2 (Larger than any link state path)
	MTID: 0 
	Metric: 20 
	Forward Address: 0.0.0.0
	External Route Tag: 0

This LSA states that the advertising router is 1.1.1.1. The forward address is 0.0.0.0 – 2 very important things to note here. When the forward address is 0.0.0.0, essentially it tells other routers that in order to forward traffic to this destination, forward it to the router that advertised the LSA. The second important thing to note is that the advertising routers’ address is not an address. It’s the router ID. Think of it as a name that looks like an IP address but is not. I have not placed the 1.1.1.1 address into OSPF, yet R2 can still reach 100.100.100.100, because 1.1.1.1 is just the RID.

OSPF works like so on R2. First what is the prefix I need to get to? 100.100.100.100:

R2#sh ip ospf database external 100.100.100.100

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

		Type-5 AS External Link States

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 135
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 100.100.100.100 (External Network Number )
  Advertising Router: 1.1.1.1
  LS Seq Number: 8000000B
  Checksum: 0xAB55
  Length: 36
  Network Mask: /32
	Metric Type: 2 (Larger than any link state path)
	MTID: 0 
	Metric: 20 
	Forward Address: 0.0.0.0
	External Route Tag: 0

The forward address is 0.0.0.0,  so I need to forward traffic to the router who’s ID is 1.1.1.1 – how do I find that out?

R2#sh ip ospf database router 1.1.1.1

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

		Router Link States (Area 12)

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 190
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 1.1.1.1
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000011
  Checksum: 0x6584
  Length: 36
  AS Boundary Router
  Number of Links: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.0.12.2
     (Link Data) Router Interface address: 10.0.12.1
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

R2 knows about 1.1.1.1 as it has a type 1 LSA in it’s database from R1 which notes that it’s RID is 1.1.1.1 – So all is good in area 12.

But what about area 0? type 1 LSAs do not pass through areas. So how would R7 get to 100.100.100.100? Let’s take a look as the LSAs from R7’s perspective:

R7#sh ip ospf database external 100.100.100.100

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

		Type-5 AS External Link States

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 318
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 100.100.100.100 (External Network Number )
  Advertising Router: 1.1.1.1
  LS Seq Number: 8000000B
  Checksum: 0xAB55
  Length: 36
  Network Mask: /32
	Metric Type: 2 (Larger than any link state path)
	MTID: 0 
	Metric: 20 
	Forward Address: 0.0.0.0
	External Route Tag: 0

You’ll notice that it’s exactly the same LSA as the one in area 12. The LSA states that the router 1.1.1.1 has originated this LSA, and any traffic going to 100.100.100.100 must be sent to the router who’s RID is 1.1.1.1 – However R7 has no idea who 1.1.1.1 is:

R7#show ip ospf database router 1.1.1.1

            OSPF Router with ID (7.7.7.7) (Process ID 1)
R7#

If things where left like this, R7 would never be able to send traffic to 100.100.100.100 as it has no idea where to send traffic to.

But here comes the type 4 to the rescue!

R7#sh ip ospf database asbr-summary 1.1.1.1

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

		Summary ASB Link States (Area 0)

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 426
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(AS Boundary Router)
  Link State ID: 1.1.1.1 (AS Boundary Router address)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000008
  Checksum: 0xD1B
  Length: 28
  Network Mask: /0
	MTID: 0 	Metric: 1

R7 has a type4 LSA that is originated by R2, the ABR. R2 says that to get to 1.1.1.1, send it to the router that has a RID of 2.2.2.2 – As R2 is in both areas, R7 should have a type 1 LSA for 2.2.2.2:

R7#sh ip ospf database router 2.2.2.2

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

		Router Link States (Area 0)

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 1121
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 2.2.2.2
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000014
  Checksum: 0xD22E
  Length: 48
  Area Border Router
  Number of Links: 2

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 2.2.2.2
     (Link Data) Network Mask: 255.255.255.255

It does. So R7 knows that to get to 100.100.100.100, send it to the router with a RID of 1.1.1.1. To get to this router, send it to the router with a RID of 2.2.2.2 as that routers says it knows how to find 1.1.1.1 – We know this works by a traceroute:

R7#traceroute 100.100.100.100
Type escape sequence to abort.
Tracing the route to 100.100.100.100
VRF info: (vrf in name/id, vrf out name/id)
  1 10.0.237.2 24 msec 20 msec 24 msec
  2 10.0.12.1 40 msec *  44 msec

So, it’s stands to reason that the sole reason for the type 4 is to explain to routers how to get to the RID of the router that originated the LSA. Note that I said the router that originated the LSA. The router that originated the LSA is not always the router that originated the prefix to begin with.

A type 5 LSA has domain wide scope. This means that when a router originates an type 5, that LSA remains unchanged throughout the domain. ABRs do not change anything on that LSA. As we showed above, in order for routers in other areas to get to the RID of the originating router, a type 4 LSA is used.

What happens then, when the ABR changes the external LSA and re-originates it? How can we make this happen? Well we can change area 12 to an NSSA. In an NSSA area, the ASBR (R1) originates a Type 7 LSA for external prefixes, not a type 5. A type 7 LSA has area-wide flooding scope, not domain-wide. This means that the type 7 LSA originated by R1 will not go further than R2. R2 will convert that type 7 LSA to a type 5 LSA. This type 5 LSA is therefore originated by R2, not by R1. This should mean that area 0 no longer needs a type 4 as the originator of the type 5 will be R2. So let’s convert area 12 to an NSSA and test this all out.

R2#sh ip ospf database nssa-external 100.100.100.100

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

		Type-7 AS External Link States (Area 12)

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 63
  Options: (No TOS-capability, Type 7/5 translation, DC)
  LS Type: AS External Link
  Link State ID: 100.100.100.100 (External Network Number )
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000001
  Checksum: 0x44A5
  Length: 36
  Network Mask: /32
	Metric Type: 2 (Larger than any link state path)
	MTID: 0 
	Metric: 20 
	Forward Address: 10.0.12.1
	External Route Tag: 0

A few things to note about this LSA. First, from R2’s perspective, this LSA states that R1 has originated this LSA. Note that the forward address is not 0.0.0.0 – rather it is 10.0.12.1. How this address is chosen is covered by Daniel’s post over here: OSPF – Use of forwarding address – Also how this can be used will be covered in another blog post otherwise I’ll never get this one finished.

This type 7 is unique to area 12. When that type 7 gets to the ABR (R2), it will convert that type 7 and re-originate a NEW type 5 LSA. Note that this type 5 has domain-wide flooding scope again. This means no need for a type 4 LSA in any area in which R2 is a part of (area 0 in this case). Let’s confirm this:

R7#sh ip ospf database asbr-summary 

            OSPF Router with ID (7.7.7.7) (Process ID 1)
R7#

No type 4 there. Let’s check the type 5 on R7 as well:

R7#sh ip ospf database external 100.100.100.100

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

		Type-5 AS External Link States

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 501
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 100.100.100.100 (External Network Number )
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000001
  Checksum: 0xBA35
  Length: 36
  Network Mask: /32
	Metric Type: 2 (Larger than any link state path)
	MTID: 0 
	Metric: 20 
	Forward Address: 10.0.12.1
	External Route Tag: 0

The originator of this LSA is the router with a RID of 2.2.2.2 (R2) – R2 is in area 0 and so all the routers in area 0 already know how to get to this RID. Therefore there is no need for anyone to even know about 1.1.1.1, and no type 4 to explain how to get to that RID. Notice again that the actual forwarding address is still R1’s interface address.

As mentioned before, this type 5 has domain-wide flooding scope. So let’s see this type 5 from R5’s perspective in area 35:

R5#sh ip ospf database external 100.100.100.100

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

		Type-5 AS External Link States

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 716
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 100.100.100.100 (External Network Number )
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000001
  Checksum: 0xBA35
  Length: 36
  Network Mask: /32
	Metric Type: 2 (Larger than any link state path)
	MTID: 0 
	Metric: 20 
	Forward Address: 10.0.12.1
	External Route Tag: 0

It’s exactly the same as the type 5 on R7 as it has just been flooded domain-wide, not changed by any ABR. But this is where things get a little confusing. R5 knows that a router with the RID of 2.2.2.2 has originated this LSA, but it has no idea how to get to this router. But does it really need to know how to get to that router? The forwarding address 10.0.12.1, not 0.0.0.0. R5 has an OSPF route to that network. Only if the forwarding address is 0.0.0.0 does the router need to send traffic towards the router RID.

If you check on R5, the ABR for that area (R3) has originated a type 4 LSA explaining how to get to the RId of 2.2.2.2:

R5# sh ip ospf database asbr-summary 

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

		Summary ASB Link States (Area 35)

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 1013
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(AS Boundary Router)
  Link State ID: 2.2.2.2 (AS Boundary Router address)
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000001
  Checksum: 0xCE58
  Length: 28
  Network Mask: /0
	MTID: 0 	Metric: 1

But R5 doesn’t really need to know about 2.2.2.2, at least in this state. The only reason I can think of is that Cisco IOS allows you to configure the ABR that does the type 7 to type 5 translation to change the forwarding address. Let’s do this on R2:

R2(config)#router ospf 1
R2(config-router)#area 12 nssa translate type7 suppress-fa

Now check the type 5 on R5 again. You’ll notice this time that the forwarding address is 0.0.0.0 with a RID of 2.2.2.2 – Now it makes complete sense that a type 4 is originated by R3 into area 35.

Conclusions:

  • A type 4 LSA is needed to show routers how to get to the RID of a router
  • A type 4 LSA will be originated into an area by an ABR if the RID of the originator of the type 5 is not in the local area
  • Know the difference between an ASBR originating a type 7, a type 5, and an ABR converting a type 7 to a type 5

© 2009-2019 Darren O'Connor All Rights Reserved -- Copyright notice by Blog Copyright