Tag Archives: type 1

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.
Screen Shot 2012 12 28 at 10.25.06 OSPF external prefixes and the Type4 LSA deep dive   part 1 of 2

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

The dangers of ignoring OSPF MTU

Quite often I see ip ospf mtu-ignore configured when two router’s MTU have a mismatch. This is bad. To demonstrate why I’ll use the following simple topology:
ospf MTU The dangers of ignoring OSPF MTU

Let’s create a simple area 0 point-to-point adjacency between the two routers and make R1′s MTU slightly larger. Then ignore OSPF MTU otherwise the adjacency will not come up:

R1
interface GigabitEthernet1/0
 mtu 2000
 ip address 10.0.0.1 255.255.255.0
 ip ospf network point-to-point
 ip ospf mtu-ignore
 ip ospf 1 area 0

The adjacency is fine as far as we can see:

R1#sh ip ospf neighbor | beg Nei
Neighbor ID     Pri   State           Dead Time   Address         Interface
1.2.3.255         0   FULL/  -        00:00:30    10.0.0.1        GigabitEthernet1/0

Now I’ve added 256 loopback interfaces onto R1 and put them all into OSPF by using network 0.0.0.0 0.0.0.0 area 0. This means all those loopback interfaces will be part of the type1 LSA originated by R1. What happens though?

interface Loopback1
 ip address 1.2.3.1 255.255.255.255
!
interface Loopback2
 ip address 1.2.3.2 255.255.255.255
!
interface Loopback3
!
[etc etc etc]
!
router ospf 1
 network 0.0.0.0 0.0.0.0 area 0

At first, nothing seems wrong. But take a look at the database from R1 and R2′s perspective. Remember the database should be identical.

R1#sh ip ospf database

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

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.2.3.255       1.2.3.255       33          0x80000005 0x00767B 257
10.0.0.2        10.0.0.2        100         0x80000011 0x00C816 2
R2#sh ip ospf database

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

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.2.3.255       1.2.3.255       130         0x80000004 0x00856D 2
10.0.0.2        10.0.0.2        128         0x80000011 0x00C816 2

R1 sees a link count of 257 for R1s router LSA, while R2 only sees 2. This can be confimred by seeing that R2 doesn’t have any OSPF routers to R1′s loopback:

R2#sh ip route ospf | beg Gate
Gateway of last resort is not set

If you wait a while you’ll see LOADING on the adjacency too. And eventually the adjacency resets and tries again:

R2#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.2.3.255         0   LOADING/  -     00:00:32    10.0.0.1        GigabitEthernet1/0
R2#
*Feb  6 19:11:26.958: %OSPF-5-ADJCHG: Process 1, Nbr 1.2.3.255 on GigabitEthernet1/0 
from LOADING to DOWN, Neighbor Down: Too many retransmissions

So what exactly is happening? If you check Wireshark you’ll see the issue straight away
ospfmtu1 The dangers of ignoring OSPF MTU
ospfmtu2 The dangers of ignoring OSPF MTU
OSPF does not do any sort of path MTU discovery. R1 is attempting to send a type1 LSA and it’s using an MTU size of 2000. R2 cannot receive that large a frame and so those fragments get dropped. R2 never acknowledges the LSA as it’s not receiving anything, and eventually that causes the adjacency to reset. This then continues over and over.

This could be hidden though. Let’s stop R1 advertising all those addresses via it’s type1 LSA and instead redistribute the links into OSPF:

R1(config)#router ospf 1
R1(config-router)#no network 0.0.0.0 0.0.0.0 area 0
R1(config-router)#redistribute connected subnet
R1(config-router)#end

R2#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.2.3.255         0   FULL/  -        00:00:38    10.0.0.1        GigabitEthernet1/0
R2#sh ip route ospf | beg Gate
Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 255 subnets
O E2     1.2.3.1 [110/20] via 10.0.0.1, 00:01:14, GigabitEthernet1/0
O E2     1.2.3.2 [110/20] via 10.0.0.1, 00:01:14, GigabitEthernet1/0
O E2     1.2.3.3 [110/20] via 10.0.0.1, 00:01:14, GigabitEthernet1/0
O E2     1.2.3.4 [110/20] via 10.0.0.1, 00:01:14, GigabitEthernet1/0
O E2     1.2.3.5 [110/20] via 10.0.0.1, 00:01:14, GigabitEthernet1/0
O E2     1.2.3.6 [110/20] via 10.0.0.1, 00:01:14, GigabitEthernet1/0
O E2     1.2.3.7 [110/20] via 10.0.0.1, 00:01:14, GigabitEthernet1/0
O E2     1.2.3.8 [110/20] via 10.0.0.1, 00:01:14, GigabitEthernet1/0
O E2     1.2.3.9 [110/20] via 10.0.0.1, 00:01:14, GigabitEthernet1/0
[etc]

This time it works, even with a mismatched MTU. Why? A type 5 LSA only has space for a single address. This means that R1 originates 255 type 5 LSAs and each of those LSA are much much smaller than 2000 bytes. This means that the LSA updates are not bigger than 1500 bytes and so we never have R2 dropping any of those packets.

A router only originates a single router LSA, and that single LSA has to contain all the interface addresses for that router that is enabled for OSPF in the area. If a router has 1000 interfaces, well that’s a large type1.

You can see the individual type5s in the database itself:

R2#sh ip ospf database | beg External
                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
1.2.3.1         1.2.3.255       390         0x80000001 0x00692A 0
1.2.3.2         1.2.3.255       390         0x80000001 0x005F33 0
1.2.3.3         1.2.3.255       390         0x80000001 0x00553C 0
1.2.3.4         1.2.3.255       390         0x80000001 0x004B45 0
1.2.3.5         1.2.3.255       390         0x80000001 0x00414E 0
1.2.3.6         1.2.3.255       390         0x80000001 0x003757 0
1.2.3.7         1.2.3.255       390         0x80000001 0x002D60 0
1.2.3.8         1.2.3.255       390         0x80000001 0x002369 0
1.2.3.9         1.2.3.255       390         0x80000001 0x001972 0
1.2.3.10        1.2.3.255       390         0x80000001 0x000F7B 0
[etc etc]

Out of interest, type3, type4, type5, and type7 LSAs all follow the ‘single address per LSA’ model and as such should never be that big. A type2 LSA will expand to reflect the amount of routers on the layer 2 segment, but I find it hard to believe that there would be over 100 routers on a single segment (though not impossible)

By the way, I wrote a separate post explaining a few more in-depth spf considerations when it comes to type1s and type5s over here: OSPF – Type 1 LSA vs Type 5 LSA (passive vs redistribute)

So there you have it. Ignore the MTU at your own peril. Rather fix the MTU issue than just ignoring it. It’s something that might not be an issue ‘now’ but as your router LSA grows in size you suddenly run into a problem.

OSPF – Type 1 LSA vs Type 5 LSA (passive vs redistribute)

In my OSPF database blog entry here: http://mellowd.co.uk/ccie/?p=1999 – I mentioned that Type3, Type5 and Type7 LSAs are not very memory efficient. Each and every prefix needs a separate LSA, while with a Type1, multiple prefixes can be advertised.

So it stands to reason that perhaps Type1 are always better? Anything that reduces memory load in large topologies is good right? While not always…

Consider the following topology:

type1 type5 OSPF   Type 1 LSA vs Type 5 LSA (passive vs redistribute)

Granted, this is not a ‘large topology’, but the fundamentals are still the same. R1 and R2 are both OSPF speakers in Area 0 (yellow) – Both are linked to switches. Let’s pretend that each of these routers actually have 5 connections to each switch. Now there is 2 ways we can get these 5 subnets each into OSPF. If we put them in Area 0, but make them passive, they’ll also be part of the Type1 LSA that each router originates. We can also reditribute them into OSPF which will create a seperate Type5 for each subnet. What behaviour can we see for each?

Let’s start by creating 5 subinterfaces on each router, and then running OSPF passive on all of them.

This is the config on R1:

interface FastEthernet0/1
 no ip address
interface FastEthernet0/1.10
 encapsulation dot1Q 10
 ip address 10.10.10.10 255.255.255.0
 ip ospf 1 area 0
interface FastEthernet0/1.20
 encapsulation dot1Q 20
 ip address 20.20.20.20 255.255.255.0
 ip ospf 1 area 0
interface FastEthernet0/1.30
 encapsulation dot1Q 30
 ip address 30.30.30.30 255.255.255.0
 ip ospf 1 area 0
interface FastEthernet0/1.40
 encapsulation dot1Q 40
 ip address 40.40.40.40 255.255.255.0
 ip ospf 1 area 0
interface FastEthernet0/1.50
 encapsulation dot1Q 50
 ip address 50.50.50.50 255.255.255.0
 ip ospf 1 area 0
!
router ospf 1
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/0

R2:

interface FastEthernet0/1
 no ip address
interface FastEthernet0/1.10
 encapsulation dot1Q 10
 ip address 11.11.11.11 255.255.255.0
 ip ospf 1 area 0
interface FastEthernet0/1.20
 encapsulation dot1Q 20
 ip address 21.21.21.21 255.255.255.0
 ip ospf 1 area 0
interface FastEthernet0/1.30
 encapsulation dot1Q 30
 ip address 31.31.31.31 255.255.255.0
 ip ospf 1 area 0
interface FastEthernet0/1.40
 encapsulation dot1Q 40
 ip address 41.41.41.41 255.255.255.0
 ip ospf 1 area 0
interface FastEthernet0/1.50
 encapsulation dot1Q 50
 ip address 51.51.51.51 255.255.255.0
 ip ospf 1 area 0
!
router ospf 1
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/0

Let’s have a look at the database on R1:

R1#sh ip ospf database

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

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
10.12.12.1      10.12.12.1      0           0x8000000B 0x0029E7 7
10.12.12.2      10.12.12.2      154         0x8000000B 0x00FE01 7
R1#

Nice and neat. Only 2 Type1 LSAs as expected. If we dig into R2′s Type1 we can see:

R1#sh ip ospf database router 10.12.12.2

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

                Router Link States (Area 0)

  LS age: 222
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 10.12.12.2
  Advertising Router: 10.12.12.2
  LS Seq Number: 8000000B
  Checksum: 0xFE01
  Length: 108
  Number of Links: 7

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 10.12.12.1
     (Link Data) Router Interface address: 10.12.12.2
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.12.12.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 51.51.51.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 41.41.41.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 31.31.31.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 21.21.21.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 11.11.11.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

All of R2′s networks are advertised in this single LSA. Nice and simple.

Let’s remove the interface OSPF config and instead redistribute the fa0/1 subinterfaces into OSPF and see what we get. Let’s first look at the OSPF database:

R1#sh ip ospf database

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

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
10.12.12.1      10.12.12.1      65          0x8000000E 0x00CE83 2
10.12.12.2      10.12.12.2      38          0x8000000E 0x00C28D 2

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
10.10.10.0      10.12.12.1      64          0x80000001 0x0069F5 0
11.11.11.0      10.12.12.2      37          0x80000001 0x003F1C 0
20.20.20.0      10.12.12.1      64          0x80000001 0x00FF41 0
21.21.21.0      10.12.12.2      37          0x80000001 0x00D567 0
30.30.30.0      10.12.12.1      64          0x80000001 0x00968C 0
31.31.31.0      10.12.12.2      37          0x80000001 0x006CB2 0
40.40.40.0      10.12.12.1      64          0x80000001 0x002DD7 0
41.41.41.0      10.12.12.2      38          0x80000001 0x0003FD 0
50.50.50.0      10.12.12.1      66          0x80000001 0x00C323 0
51.51.51.0      10.12.12.2      38          0x80000001 0x009949 0

A lot more than we had last time. Let’s have a look at the Router LSA and 1 External LSA:

R1#sh ip ospf database router 10.12.12.2

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

                Router Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 84
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 10.12.12.2
  Advertising Router: 10.12.12.2
  LS Seq Number: 8000000E
  Checksum: 0xC28D
  Length: 48
  AS Boundary Router
  Number of Links: 2

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 10.12.12.1
     (Link Data) Router Interface address: 10.12.12.2
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.12.12.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

R1#sh ip ospf database external 51.51.51.0

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 107
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 51.51.51.0 (External Network Number )
  Advertising Router: 10.12.12.2
  LS Seq Number: 80000001
  Checksum: 0x9949
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 0

We are seeing exactly what we expected, but it’s just bloated everything a bit. So perhaps it’s better to put external interfaces into OSPF and run them as passive? Well, let’s take a closer look at something else. Let’s keep the Type5 LSA and check the SPF statistics on R2:

R2#sh ip ospf statistics

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

  Area 0: SPF algorithm executed 23 times

At this very moment the SPF algorithm has excecuted 23 times. Let’s shut 2 of R1′s subinterfaces and see what happens in R2.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int fa0/1.10
R1(config-subif)#shut
R1(config-subif)#int fa0/1.20
R1(config-subif)#shut
R2#sh ip ospf statistics

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

  Area 0: SPF algorithm executed 23 times

No change in the SPF calculation. Let’s now move everything back into Type1s again and do the same.

Everything has been changed back, so let’s take a before on R2:

R2#sh ip ospf statistics

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

  Area 0: SPF algorithm executed 31 times
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int fa0/1.10
R1(config-subif)#shut
R1(config-subif)#int fa0/1.20
R1(config-subif)#shut

What do we now see on R2?

R2#sh ip ospf statistics

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

  Area 0: SPF algorithm executed 33 times

I removed the same 2 interfaces from OSPF, and this time SPF was run twice, once for each removal. What’s going on here?

If a router originates a Type1 LSA for all of it’s connected interfaces, each time 1 of those interfaces flap, it needs to originate the entire Type1 LSA again showing the removal of the prefix on that interface. Each time a Type1 LSA (and Type2 for that matter) is flooded into an area, all routers in the area need to run their SPF algorithm. A Type5 is inherently external to the OSPF domain, and so OSPF speakers in the area will believe whatever the ABRs and ASBRs tell them. The next-hop to these external routes will be to the ABR and ASBR in the area, of which the SPF algorithm has already been run to find a route to. This is part of OSPF’s DV behaviour when it gets outside the local area.

So now we see advantages and disadvantages to both methods. Type1′s keep the database small and clean, while Type5′s allow SPF to run far less when externally facing interfaces go up and down.

You can tweak OSPF with Incremental OSPF. This allows the OSPF process to only recalculate certain portions of the SPF tree when a Type1 or Type2 is flooded into the area. SPF still needs to be run, but at least in a much more optimised state.