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 yet 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, we can see that its 0.0.0.0 and 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#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 (Between R2 and R3) 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 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 Area 1 as R2. Let’s move to R4 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)The above output should not really be surprising, we already 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 lists 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 confirm:
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#sh ip ospf database self-originate
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 1016 0x80000004 0x00B41E 1
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.12.12.0 0.0.0.1 1016 0x80000003 0x004CC1
10.23.23.0 0.0.0.1 1156 0x80000001 0x00B639
Summary ASB Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
0.0.0.3 0.0.0.1 1083 0x80000001 0x002004
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
0.0.0.1 0.0.0.1 1016 0x80000004 0x00429B 1
Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.12.12.1 0.0.0.1 1016 0x80000003 0x001AF6
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.14.14.0 0.0.0.1 1016 0x80000003 0x001EEB
10.45.45.0 0.0.0.1 1016 0x80000003 0x00B60B
So basically, due to the fact that ‘Forward Address’ was 0.0.0.0, and there is not enough information in the database (LSA1/2), R4 needed another way to achieve connectivity so R1 generated LSA4 to fix this issue which says, if you want to reach 192.168.30.0/24, go through me, R4.
Does LSA Type 4 always exist alongside LSA Type 5?
No, not always. You see, there are many resources that makes this absolute statement that LSA4 always goes hand in hand with LSA5. Let me explain 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: 0It sure does! Since Area 1 is NSSA, R1 has translated LSA Type 7 generated by R3 (received in Area 1) to LSA Type 5 (sent into Area 0):
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
Does R4 still have 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)It does not! let’s see if it has reachability 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 msIt 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: 0Can you spot the difference? check the ‘Forward Address’, it’s no longer showing 0.0.0.0. Instead, it has now 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 1Interesting…..so there you have it. LSA5 and LSA4 DO NOT have to exist together at 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: 0Let’s discuss what we are seeing above. The Forward Address was set back to 0.0.0.0. So are we somewhat back to the same situation where we need LSA4?
Well, not exactly . 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 5 which effectively means, originating a brand new LSA type 5!
Extra Bonus thought
If you think about it, if we go all the way to the very first output of R4 in this post
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: 0If only instead of passing LSA5 as is, from Area 1 to Area 0 by R1, it generates a new LSA5 with it being the Advertising Router instead of R3 ( Advertising Router: 0.0.0.1). That way, we would not need LSA type 4 in the first place.
I think the rationale here is to address having multiple ABRs, knowing the original RID that is originating that external route will make it more efficient to route through the closest ABR. But still, I think at least you should have the option to have the ABR re-inject a modified LSA5 and reduce the database by eliminating LSA4 if you know that your network has only single ABR anyway.
Enter the text or HTML code here
