Tag Archives: type5

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.