Category Archives: Fundamentals

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.

Next-Hop IP. What does it actually mean?

I’ve seen far too much confusion about the fundamentals of IP routing that I thought it would be good to write something like this.

 

If packets are getting sent to a default gateway, or next-hop, whatever – is that packet actually addressed to that next-hop? Well, it depends on what layer we are talking about. From a layer 3 perspective it’s never actually addressed to that next-hop. i.e. the source and destination IP address NEVER changes, unless you have some sort of device doing NAT.

 

The next-hop address is merely an address that you are hoping that this packet goes towards. If the next-hop is on the same subnet as the source address, than an ARP resolution will take place and that packet will get sent to the gateway’s MAC address. The destination IP has not changed at all.

 

If the next-hop is NOT on the same subnet, that packet will travel to the local gateway and then onwards. That gateway might have another idea where that packet should go to as, again, the packet is not actually addresses to that next-hop via layer3.

This also means that a next-hop address could even be an address that doesn’t exist. As long as the packet travels in the right direction you are good to go.

 

Let’s take the following diagram as an example:

next hop1 Next Hop IP. What does it actually mean?

R2 and R3 are running OSPF with each other. R3 has a loopback of 3.3.3.3 advertised into OSPF so R2 knows how to get there. R1 and R2 are not running OSPF. R2 is advertising the R1 and R2 link into OSPF as a stub network.

The actual subnets used are 10.12.12.0/24 and 10.23.23.0/24
R1:

interface FastEthernet0/0
 ip address 10.12.12.1 255.255.255.0

R2:

interface FastEthernet0/0
 ip address 10.12.12.2 255.255.255.0
 ip ospf 1 area 0
!
interface FastEthernet0/1
 ip address 10.23.23.2 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0
!
router ospf 1
 passive-interface FastEthernet0/0

R3:

interface Loopback0
 ip address 3.3.3.3 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 10.23.23.3 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0

On R3 I now set an IP route to 3.3.3.3/32 with a next-hop of 192.168.1.1, which does not exist anywhere. I then create another route to 192.168.1.1/32 with a next-hop of 10.12.12.2

ip route 3.3.3.3 255.255.255.255 192.168.1.1
ip route 192.168.1.1 255.255.255.255 10.12.12.2

Let’s have a look at the route table on R1:

R1#sh ip route 3.3.3.3
Routing entry for 3.3.3.3/32
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 192.168.1.1
      Route metric is 0, traffic share count is 1

R1#sh ip route 192.168.1.1
Routing entry for 192.168.1.1/32
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 10.12.12.2
      Route metric is 0, traffic share count is 1

As expected everything works fine:

R1#ping 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 13/23/29 ms

However the above example is probably not the best example as CEF would already have worked out all the recursive routing needed:

R1#sh ip cef 3.3.3.3
3.3.3.3/32, version 7, epoch 0, cached adjacency 10.12.12.2
0 packets, 0 bytes
  via 192.168.1.1, 0 dependencies, recursive
    next hop 10.12.12.2, FastEthernet0/0 via 192.168.1.1/32
    valid cached adjacency

But it does prove that the packet is able to get to 3.3.3.3 even with a next-hop that does not actually exist anywhere.

Let’s now make a more complicated scenario:
next hop2 Next Hop IP. What does it actually mean?

My subnet addressing is similar to before. This time R5 is advertising it’s loopback interface into OSPF. R1 is NOT running OSPF.

R1 has a static route that says to get to 5.5.5.5 it needs to send it to R3. It then has a route to R3 via R2.

R1#sh ip route 5.5.5.5
Routing entry for 5.5.5.5/32
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 10.23.23.3
      Route metric is 0, traffic share count is 1

But what happens when I traceroute from R1?

R1#traceroute 5.5.5.5
Type escape sequence to abort.
Tracing the route to 5.5.5.5
  1 10.12.12.2 52 msec 76 msec 4 msec
  2 10.24.24.4 80 msec 72 msec 68 msec
  3 10.45.45.5 188 msec *  84 msec

The traffic gets to my destination, but it did not ever get near R3. Why is that?
Have a look at R2:

R2#sh ip route 5.5.5.5
Routing entry for 5.5.5.5/32
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 10.24.24.4
      Route metric is 0, traffic share count is 1

I put a static route on R2 to send traffic for 5.5.5.5 via R4, not R3.

So all in all really simple. What I’m merely trying to show is that in regular routing, each and every hop along the way will make their own independent decision on how to get to the destination. When that packet gets to R2, it has no idea that R1 wanted to actually go via R3, because that next-hop is not encoded anywhere. All R1 is doing is sending traffic ‘towards’ the next-hop. R2 will makes it’s own decision as it only sees the destination address of 5.5.5.5

This behaviour fully explains routing-loops and the problem of traffic getting dropped inside an AS running BGP

Restricting users to only view parts of the SNMP tree – Cisco

It’s well known that you can give your customer read-only access to the SNMP tree, but are you sure you want to give them that much information? Even though they can’t change anything, they are able to extract the full configuration, the full routing table and much much more.

As a test I set up SNMP read-only access to a Cisco box I have and ran a full snmpwalk on it. I extracted over 8Mb worth of text data, including full routing tables; ARP tables; OSPF tables etc…

Not only that, but while I was running the walk my device CPU was sitting pretty high:

Router#sh proc cpu sorted
CPU utilization for five seconds: 33%/3%; one minute: 76%; five minutes: 54%
PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process
210      121148      106996       1132 15.11% 44.65% 25.56%   0 SNMP ENGINE
107       70240      213991        328  7.35% 12.99% 11.51%   0 IP SNMP

Walking the entire SNMP tree also took almost 5 minutes.

So do you really want your customer to know that much? And secondly do you really want your customers monitoring system polling your devices for everything while your device sits with high CPU all the time?

I was testing with a few views this morning and came up with the following:

snmp-server view RESTRICT iso included
snmp-server view RESTRICT at.* excluded
snmp-server view RESTRICT ip.* excluded
snmp-server view RESTRICT ospf.* excluded
snmp-server community [community] view RESTRICT RO [acl]

When I polled using this community it took less than 5 seconds and gave me pretty much all the information I would want to give the customer. Be sure to restrict the protocol you’re actually using. I have restricted OSPF above.

Out of interest, an snmpwalk on my edge BGP router gives me a text file of 0.5GB!

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.

Demystifying the OSPF database

A lot of people troubleshoot OSPF, without ever once looking at the OSPF database and understanding the LSA types. I think this has more to do with the fact that they do not understand it properly and how to actually get information from it.

I hope to demystify it and show what a powerful troubleshooting tool it can be.

OSPFv2 for IPv4 has 7 main LSA types. You’ll probably only have experience with 6 of them as LSA type 6 was for Multicast Extensions which isn’t supported in IOS and a number of other vendors implementations.

I’ll attempt to show database output for Cisco IOS, Juniper JUNOS as well as Brocade/Foundry’s code. I can’t show all the types with Brocade as I don’t have a Brocade lab handy to create them all.

Let’s first have a look at what each OS gives as as viewable database options. Note that I’ve changed my public IPs and DNS names as appropriate.

Cisco:

CISCO#sh ip ospf database ?
adv-router        Advertising Router link states
asbr-summary      ASBR summary link states
database-summary  Summary of database
external          External link states
internal          Internal LSA information
multicast         Multicast Topology
network           Network link states
nssa-external     NSSA External link states
opaque-area       Opaque Area link states
opaque-as         Opaque AS link states
opaque-link       Opaque Link-Local link states
router            Router link states
self-originate    Self-originated link states
summary           Network summary link states
topology          Unicast Topology

Juniper:

darren@JUNOS> show ospf database ?
Possible completions:
<[Enter]>            Execute this command
advertising-router   Router ID of advertising router
area                 OSPF area ID
asbrsummary          Summary AS boundary router link-state advertisements
brief                Display brief output (default)
detail               Display detailed output
extensive            Display extensive output
external             External link-state advertisements
instance             Name of OSPF instance
link-local           Link local link-state advertisements
logical-system       Name of logical system, or 'all'
lsa-id               Link-state advertisement ID
netsummary           Summary network link-state advertisements
network              Network link-state advertisements
nssa                 Not-so-stubby area link-state advertisements
opaque-area          Opaque area-scope link-state advertisements
router               Router link-state advertisements
summary              Display summary output

Brocade:

SSH@BROCADE#show ip ospf database link-state ?
  advertise         Display link state by advertisement
  asbr              Display link state by asbr link
  extensive         Display detailed info of entries in OSPF database
  link-state-id     Display link state by link-state ID
  network           Display link state by network link
  nssa              Display link state by NSSA
  opaque-area       Display link state by opaque area
  router            Display link state by router link
  router-id         Display link state by router ID
  self-originate    Display self-originated links-states
  sequence-number   Display link state by sequence number
  summary           Display link state by summary link

The database allows us to see information in all of the needed LSAs. Hence it is important to also know what each LSA actually does, and what information it’s supposed to contain. We’ll go through each of them and extract the required information from the database itself. Each time you look at the database itself and specify a type, you need to give an argument. That argument will depend on the lsa type.

Type 1 – Router LSA:
The router LSA is the lsa that each router originates. It contains information about the local router, it’s attached links and associated costs of those links, and routers it is adjacent to. This LSA is kept within the local area in which it is originated from. The argument is the router ID (RID) of each router
Cisco:

CISCO#sh ip ospf database router 10.100.0.33

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

                Router Link States (Area 0)

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 1611
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 10.100.0.33
  Advertising Router: 10.100.0.33
  LS Seq Number: 80001FEB
  Checksum: 0x6B0C
  Length: 48
  Area Border Router
  AS Boundary Router
  Number of Links: 2

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 196.196.196.196
     (Link Data) Router Interface address: 10.100.0.33
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.100.0.32
     (Link Data) Network Mask: 255.255.255.252
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

Juniper:

darren@JUNOS> show ospf database router advertising-router 10.100.0.33 extensive

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router   10.100.0.33      10.100.0.33      0x80001feb  1778  0x22 0x6b0c  48
  bits 0x3, link count 2
  id 196.196.196.196, data 10.100.0.33, Type PointToPoint (1)
    Topology count: 0, Default metric: 1
  id 10.100.0.32, data 255.255.255.252, Type Stub (3)
    Topology count: 0, Default metric: 1
  Topology default (ID 0)
    Type: PointToPoint, Node ID: 196.196.196.196
      Metric: 1, Bidirectional
  Aging timer 00:30:22
  Installed 00:29:35 ago, expires in 00:30:22, sent 00:29:33 ago
  Last changed 10w5d 20:28:57 ago, Change count: 3

Brocade:

SSH@BROCADE#show ip ospf database link-state router 10.100.0.33
Area ID         Type LS ID           Adv Rtr         Seq(Hex) Age  Cksum  SyncState
0               Rtr  10.100.0.33     10.100.0.33     80001feb 1829 0x6b0c Done
  LSA Header:  options: 0x22, seq-nbr: 0x80001feb, length: 48, flags:0x0300
  link id = 196.196.196.196, link data = 10.100.0.33, type = point-to-point(1)
  tos count = 0, tos0_metric = 1
  link id = 10.100.0.32, link data = 255.255.255.252, type = stub(3)
  tos count = 0, tos0_metric = 1

All of the above pretty much tell us the same thing. The router with the RID of 10.100.0.33 has 2 links in OSPF. 1 is a point-to-point link and the other is a stub link. Pretty simple stuff.

Type 2 – Network LSA:
A network LSA is originated by the DR on the segment. DRs are only required on segment in which there are more than 2 OSPF speakers. OSPF treats ethernet segments as non point-to-point by default, so even if there are only 2 routers on there, there will still be a DR. You can change this behaviour by configuring the links as point-to-point. Type 2′s are local to the area in which they originate. The argument is the IP address of the physical interface on the segment of the DR
Cisco:

CISCO#sh ip ospf database network 10.0.10.6

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

                Net Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 1196
  Options: (No TOS-capability, No DC)
  LS Type: Network Links
  Link State ID: 10.0.10.6 (address of Designated Router)
  Advertising Router: r1.company.com
  LS Seq Number: 8000706A
  Checksum: 0xDCE8
  Length: 32
  Network Mask: /30
        Attached Router: 196.196.196.196
        Attached Router: 248.248.248.248

Juniper:

darren@JUNOS> show ospf database network lsa-id 10.0.10.6 extensive

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Network  10.0.10.6        196.196.196.196   0x8000706a  1374  0x2  0xdce8  32
  mask 255.255.255.252
  attached router 196.196.196.196
  attached router 248.248.248.248
  Topology default (ID 0)
    Type: Transit, Node ID: 248.248.248.248
      Metric: 0, Bidirectional
    Type: Transit, Node ID: 196.196.196.196
      Metric: 0, Bidirectional
  Aging timer 00:37:06
  Installed 00:22:50 ago, expires in 00:37:06, sent 00:22:49 ago
  Last changed 10w5d 18:09:57 ago, Change count: 1

Brocade:

SSH@BROCADE#show ip ospf database link-state network 10.0.10.6
Area ID         Type LS ID           Adv Rtr         Seq(Hex) Age  Cksum  SyncState
0               Net  10.0.10.6       196.196.196.196  8000706a 1411 0xdce8 Done
  LSA Header:  options: 0x02, seq-nbr: 0x8000706a, length: 32
  NetworkMask: 255.255.255.252
  attached router: 196.196.196.196
  attached router: 248.248.248.248

All 3 of the above outputs tell us that 10.0.10.6 is originating a type 2 lsa which says on that particular segment there are 2 routers attached.

Type 3 – Network Summary LSA:
Type 3′s are originated by ABRs. The Type3 tells OSPF speakers in 1 area how to reach prefixes in another area, through the advertising ABR. The argument is the network prefix itself.
Cisco:

CISCO#sh ip ospf database summary 1.1.1.0

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

                Summary Net Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 258
  Options: (No TOS-capability, No DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 1.1.1.0 (summary Network Number)
  Advertising Router: r2.company.com
  LS Seq Number: 80000001
  Checksum: 0x9D57
  Length: 28
  Network Mask: /31
        TOS: 0  Metric: 1000

Juniper:

darren@JUNOS> show ospf database netsummary lsa-id 1.1.1.0 extensive

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Summary  1.1.1.0          196.196.196.196  0x80000001   314  0x2  0x9d57  28
  mask 255.255.255.254
  Topology default (ID 0) -> Metric: 1000
  Aging timer 00:54:46
  Installed 00:05:09 ago, expires in 00:54:46, sent 00:05:09 ago
  Last changed 00:05:09 ago, Change count: 1

Brocade:

SSH@BROCADE#show ip ospf database link-state summary 1.1.1.0
Area ID         Type LS ID           Adv Rtr         Seq(Hex) Age  Cksum  SyncState
0               Summ 1.1.1.0         196.196.196.196 80000001 341  0x9d57 Done
  LSA Header:  options: 0x02, seq-nbr: 0x80000001, length: 28
  NetworkMask: 255.255.255.254
  TOS 0:  metric: 1000

All 3 of the above show me the network address and subnet mask of the network, the ABR who originated the LSA as well as the ABRs cost to the network. Note that a Typ3 LSA can only contain a single network. A new type 3 lsa needs to be generated for each and every network that an ABR is advertising. i.e. not very efficient. A type 3 is flooded to all areas.

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 attatched 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. Take a quick look at the image below that I used for the Type7 example. Both R3 and R2 originate Type4′s that R1 and R6 will be able to see:

Cisco:

R6#sh ip ospf database asbr-summary 10.34.34.3

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

                Summary ASB Link States (Area 2)

  Routing Bit Set on this LSA
  LS age: 415
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(AS Boundary Router)
  Link State ID: 10.34.34.3 (AS Boundary Router address)
  Advertising Router: 10.13.13.1
  LS Seq Number: 80000001
  Checksum: 0xAB1
  Length: 28
  Network Mask: /0
        TOS: 0  Metric: 10

Type 5 – External LSA:
Type5 LSA’s are originated by ASBRs. Each LSA contains information about the external prefix. The argument needed is the prefix itself. Like Type3s, ASBRs need to originate a separate LSA for each and every prefix it needs to advertise.
Cisco:

CISCO#sh ip ospf database external 10.0.2.112

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 1382
  Options: (No TOS-capability, No DC)
  LS Type: AS External Link
  Link State ID: 10.0.2.112 (External Network Number )
  Advertising Router: r3.company.com
  LS Seq Number: 80004DCD
  Checksum: 0x6065
  Length: 36
  Network Mask: /29
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 1
        Forward Address: 0.0.0.0
        External Route Tag: 0

Juniper:

darren@JUNOS> show ospf database external lsa-id 10.0.2.112 extensive
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Extern   10.0.2.112       196.196.196.196  0x80004dcd  1546  0x2  0x6065  36
  mask 255.255.255.248
  Topology default (ID 0)
    Type: 2, Metric: 1, Fwd addr: 0.0.0.0, Tag: 0.0.0.0
  Aging timer 00:34:13
  Installed 00:22:43 ago, expires in 00:34:14, sent 00:22:41 ago
  Last changed 19w1d 19:03:40 ago, Change count: 1

Brocade:

SSH@BROCADE#show ip ospf database external-link-state link-state-id 10.0.2.112
Ospf ext link-state by link-state ID 10.0.2.112 are in the following:

Type-5 AS External Link States

Index Age  LS ID           Router          Netmask  Metric   Flag Fwd Address   SyncState
587   1500 10.0.2.112      196.196.196.196 fffffff8 00000001 0000 0.0.0.0        Done
  LSA Header:  age: 1500, options: 0x02, seq-nbr: 0x80004dcd, length: 36
  NetworkMask: 255.255.255.248
  TOS 0:  metric_type: 2, metric: 1
          forwarding_address: 0.0.0.0
          external_route_tag: 0

Type 7 – NSSA External LSA:
Type7′s can also be a bit confusing. A Type7 is originated by an ASBR into it’s local areas. It tell other routers in the area about how to get to external prefixes. Like the Type3 and Type5, a separate LSA is needed for each prefix. The argument is the prefix. When a Type7 LSA reaches an ABR, the ABR will convert that Type7 into a Type5 LSA. It’ll also change the forwarding address. But what happens if the ASBR is also the ABR itself? Does it convert itself? Well, let’s lab it up to see. I can only do this on the Cisco as I have that lab. I’ll add Junos output sometime in the future.

Let’s use the following topology:

OSPF Type7 Type4 Demystifying the OSPF database
Area 1 is an NSSA area. Router 4 is redistributing it’s loopback interface (4.4.4.4/32) into area 1.
Cisco:

R2#sh ip ospf database nssa-external 4.4.4.4

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

                Type-7 AS External Link States (Area 1)

  LS age: 726
  Options: (No TOS-capability, Type 7/5 translation, DC)
  LS Type: AS External Link
  Link State ID: 4.4.4.4 (External Network Number )
  Advertising Router: 10.34.34.4
  LS Seq Number: 80000001
  Checksum: 0x29CC
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 10.24.24.4
        External Route Tag: 0

The contents of the LSA show us the prefix and mask. It also tells us where to send the packets to. In this case 10.24.24.4.

what about R1 though?

R1#sh ip ospf database nssa-external 4.4.4.4

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

There is no Type7 for it to see. This is because the ABRs converted that Type7 into a Type5. Let’s check this:

R1#sh ip ospf database nssa-external 4.4.4.4

            OSPF Router with ID (10.13.13.1) (Process ID 1)
R1#sh ip ospf database external 4.4.4.4

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

                Type-5 AS External Link States

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

R1 sees this information as a Type5 LSA. But there is a very important change here. Notice the forward address. This is R4′s address. If you look at the Type5 example in the post above, you’ll see that the forward address is 0.0.0.0 – This tells the router that the next-hop will be the ABR that advertised the LSA. This LSA is coming from R3, but it keeps the next-hop to 10.24.24.4 – You can actually change this behaviour if you somehow require it:

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

R1#sh ip ospf database external 4.4.4.4

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

                Type-5 AS External Link States

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

Not only that, but surely both R2 and R3 converting and advertising into the same area is a waste of resource? It certainly is! There is an election that takes place that tells the ABRs which one will actually be doing the translations. Maybe I’ll do a blog post in future detailing this.