You are here
Home > Topics > Routing >

The curious case of OSPF LSA Type 4

I’ve always been fascinated by OSPF. I remember back in the day when I felt that I really know OSPF inside out until I went for a job interview where several interviewers grilled me on OSPF and I was like you know what? I really have to go back and dig as deep as possible into OSPF (and no, I did not get that job…).

OSPF has many features and quirks, its flexible but also has many limitations, it’s scalable but also can cause major headaches in large scale networks.

In this post, I will be focusing on LSA Type 4 just because this a really interesting LSA. It is often misunderstood, misrepresented and as I will show towards the end, in some cases it’s not even needed!

Looking at the diagram below, we have R1, R4 and R5 in Area 0 and R1, R2 and R3 are in Area 1. R3 has an external network (192.168.30.0/24) that has not been redistributed in OSPF. 

Let’s examine R2 neighbors and R1 OSPF database at this point:

R2#sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
0.0.0.3           1   FULL/BDR        00:00:32    10.23.23.3      Ethernet0/0
0.0.0.1          10   FULL/DR         00:00:39    10.12.12.1      Ethernet0/1
R1#sh ip ospf data

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

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
0.0.0.1         0.0.0.1         453         0x800000FD 0x00C018 1
0.0.0.4         0.0.0.4         661         0x800000FD 0x00974E 2
0.0.0.5         0.0.0.5         406         0x800000FB 0x00DE73 1

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.14.14.4      0.0.0.4         661         0x800000F8 0x00DF2F
10.45.45.5      0.0.0.5         406         0x800000F8 0x003892

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.12.12.0      0.0.0.1         424         0x80000001 0x0050BF
10.23.23.0      0.0.0.1         424         0x80000001 0x00B639

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
0.0.0.1         0.0.0.1         440         0x800000FD 0x00588A 1
0.0.0.2         0.0.0.2         437         0x800000FF 0x00EC63 2
0.0.0.3         0.0.0.3         413         0x80000100 0x002489 1

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.12.12.2      0.0.0.2         436         0x800000F9 0x0018FF
10.23.23.3      0.0.0.3         437         0x800000F9 0x0022DB

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.14.14.0      0.0.0.1         454         0x800000F9 0x0030E2
10.45.45.0      0.0.0.1         454         0x800000F9 0x00C802

As you’d expect, R1 knows about LSA type 1 (Router Link), LSA type 2 (Net Link) and LSA type 3 (Summary Net Link) only. Now, let’s redistribute the external network attached to R3 into its OSPF process and examine R2’s OSPF database:

R2#sh ip ospf data

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

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
0.0.0.1         0.0.0.1         797         0x800000FD 0x00588A 1
0.0.0.2         0.0.0.2         792         0x800000FF 0x00EC63 2
0.0.0.3         0.0.0.3         7           0x80000102 0x002683 1

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.12.12.2      0.0.0.2         792         0x800000F9 0x0018FF
10.23.23.3      0.0.0.3         328         0x800000FA 0x0020DC

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.14.14.0      0.0.0.1         811         0x800000F9 0x0030E2
10.45.45.0      0.0.0.1         811         0x800000F9 0x00C802

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
192.168.30.0    0.0.0.3         6           0x80000001 0x00D83D 0

Now we can see LSA type 5 (Type-5 AS External Link) is showing in the database as a result of R3 injecting the external network (192.168.30.0/24) into OSPF. Let’s look deeper into this LSA type 5:

R2#sh ip ospf data external

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

                Type-5 AS External Link States

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

Two very important sections in the above output:

  • Advertising Router: 0.0.0.3
  • Forward Address: 0.0.0.0

I will discuss the Forward Address later in this post but for now, since its 0.0.0.0, it is not showing a usable value. What about the Advertising Router? Can R2 check its LSA Type 2 and 1 to see how it can reach this external network?

R2#show ip ospf data net adv-router 0.0.0.3

            OSPF Router with ID (0.0.0.2) (Process ID 1)
R2#
R2#show ip ospf data rout adv-router 0.0.0.3

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

                Router Link States (Area 1)

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

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.23.23.2
     (Link Data) Router Interface address: 10.23.23.3
      Number of MTID metrics: 0
       TOS 0 Metrics: 10

R2#sh ip route 10.23.23.3
Routing entry for 10.23.23.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Ethernet0/0
      Route metric is 0, traffic share count is 1

From the output above, R2 did not show any LSA Type 2 learned from R3 (Remember that R2 is the Designated Router for this segment as shown above). However, it did show output for LSA Type 1 and it knows which interface to use to get to this external network.

So, since R2 was able to rely on its LSA type 1 to know how to route to the external network, is it accurate to say that R2 did not need LSA type 4? is it even in its database? let’s find out:

R2#show ip ospf database asbr-summary

            OSPF Router with ID (0.0.0.2) (Process ID 1)
R2#

R2 does not have LSA type 4 as the output above shows.

R1 should have the exact copy of the database since it has an interface in the same area1 as R2. Let’s move to R3 and see what its database is showing for the external network:

R4#sh ip ospf data ex

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 1603
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 192.168.30.0 (External Network Number )
  Advertising Router: 0.0.0.3
  LS Seq Number: 80000003
  Checksum: 0xD43F
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 0

As you noticed R4’s LSA type 5 is very similar to R2’s, with Forward Address 0.0.0.0 and Advertising Router 0.0.0.3. And as discussed above since the forwarding address has no value, let’s see how R4 can reach R3:

R4#show ip ospf data net adv 0.0.0.3

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

R4#show ip ospf data route adv 0.0.0.3

            OSPF Router with ID (0.0.0.4) (Process ID 1)
R4#

We should not really be surprised here, we know that LSA type 1 and 2 remain local in their areas. So the question here is, how can R4 possibly know how to route to 192.168.30.0/24 without knowing where is the next hop? Here where LSA type 4 comes in play:

R4#show ip ospf data asbr-summary

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

                Summary ASB Link States (Area 0)

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 55
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(AS Boundary Router)
  Link State ID: 0.0.0.3 (AS Boundary Router address)
  Advertising Router: 0.0.0.1
  LS Seq Number: 80000003
  Checksum: 0x1C06
  Length: 28
  Network Mask: /0
        MTID: 0         Metric: 20

R4#show ip ospf data route adv 0.0.0.1

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

                Router Link States (Area 0)

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 69
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 0.0.0.1
  Advertising Router: 0.0.0.1
  LS Seq Number: 80000101
  Checksum: 0xB71D
  Length: 36
  Area Border Router
  Number of Links: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.14.14.4
     (Link Data) Router Interface address: 10.14.14.1
      Number of MTID metrics: 0
       TOS 0 Metrics: 10


R4#sh ip route 10.14.14.1
Routing entry for 10.14.14.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Ethernet0/2
      Route metric is 0, traffic share count is 1

R4 has an LSA type 4 that list 0.0.0.3 as the ASBR and 0.0.0.1 as the Advertising Router (of this LSA) which can reached via LSA type1. So did R4 generate this LSA? Let’s check:

R1#show ip ospf data asbr

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

                Summary ASB Link States (Area 0)

  LS age: 227
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(AS Boundary Router)
  Link State ID: 0.0.0.3 (AS Boundary Router address)
  Advertising Router: 0.0.0.1
  LS Seq Number: 80000003
  Checksum: 0x1C06
  Length: 28
  Network Mask: /0
        MTID: 0         Metric: 20

R1#

So basically, due to the fact that Forward Address was 0.0.0.0, and there is not enough information in the database (LSA2/3), R4 needed another way to fix this problem. R1 generated LSA4 to fix this issue which says, if you want to reach 192.168.30.0/24, go through R4.

 

LSA Type 4’s always exist alongside LSA Type 5?

Not 100% accurate. You see, there are many resources that makes this absolute statement that LSA4 always goes hand in hand with LSA5. So, let’s see why is this incorrect. I’m going to change Area1 type to NSSA.

Now, let’s see if R4 still has the external route:

R4#show ip ospf data ex

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

                Type-5 AS External Link States

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

R4#

It sure does! Since Area1 is NSSA, R1 has translated LSA Type 7 generated by R3 (received in Area1) to LSA Type 5 (sent into Area0):

R1#show ip ospf data ex

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

                Type-5 AS External Link States

  LS age: 167
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 192.168.30.0 (External Network Number )
  Advertising Router: 0.0.0.1
  LS Seq Number: 80000001
  Checksum: 0xBE1E
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 20
        Forward Address: 10.23.23.3
        External Route Tag: 0

R1#show ip ospf database nssa-external

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

                Type-7 AS External Link States (Area 1)

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

Okay, so really nothing changes so far. Does R4 still has LSA Type 4 to use to reach to that external network? let’s check

R4#show ip ospf data asbr-summary

            OSPF Router with ID (0.0.0.4) (Process ID 1)
R4#

I does not! let’s see if it has connectivity to that network

R4#ping 192.168.30.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.30.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
R4#

It does have reachability. So how did R4 know how to route to 192.168.30.0/24 without LSA type 4? Let’s examine that LSA type 5 again:

R4#show ip ospf data ex

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

                Type-5 AS External Link States

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

R4#

Can you spot the difference? check the Forward Address, it’s no longer 0.0.0.0 and now it has a usable value of 10.23.23.3 which clearly tells R4 how to find the external network:

R4#show ip ospf dat sum

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

                Summary Net Link States (Area 0)

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 321
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 10.12.12.0 (summary Network Number)
  Advertising Router: 0.0.0.1
  LS Seq Number: 80000005
  Checksum: 0x48C3
  Length: 28
  Network Mask: /24
        MTID: 0         Metric: 10

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 321
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 10.23.23.0 (summary Network Number)
  Advertising Router: 0.0.0.1
  LS Seq Number: 80000005
  Checksum: 0xAE3D
  Length: 28
  Network Mask: /24
        MTID: 0         Metric: 20

R4#sh ip route 10.23.23.3
Routing entry for 10.23.23.0/24
  Known via "ospf 1", distance 110, metric 30, type inter area
  Last update from 10.14.14.1 on Ethernet0/2, 02:18:55 ago
  Routing Descriptor Blocks:
  * 10.14.14.1, from 0.0.0.1, 02:18:55 ago, via Ethernet0/2
      Route metric is 30, traffic share count is 1
R4#

Interesting…..so there you have it. LSA5 and LSA4 DO NOT have to exist together in the same area as we clearly demonstrated above.

 

Bonus thought

Here is an interesting idea, seeing how we were able to route when the Forward Address showed an actual value and without even needing LSA4 at all.  What happens if we suppress the forwarding address? I’m going to use the following command on R1:

R1(config-router)#area 1 nssa translate type7 suppress-fa
R4#show ip ospf data ex

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 66
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 192.168.30.0 (External Network Number )
  Advertising Router: 0.0.0.1
  LS Seq Number: 80000003
  Checksum: 0xE035
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 0

R4#

Let’s discuss what we are seeing above. The Forward Address was set to 0.0.0.0 so we are somewhat back to the same situation where we need LSA4?

Well, not really. Check the Advertising Router here is 0.0.0.1 which is the Router ID of R1. R4 knows how to reach to that router using LSA type 1/2. This is different from the original case above where the Advertising Router was 0.0.0.3 (the originator of LSA5), while here the originator of the external route was actually R1 since it did the translation from LSA type 7 to LSA type which effectively means, originating a brand new LSA type 5!

Leave a Reply

Top