The premiere source of truth powering network automation. Open and extensible, trusted by thousands.
NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.
Where are type 4 LSAs generated?
By stretch | Monday, April 21, 2008 at 1:34 a.m. UTC
An interesting question was recently brought up by sirsamon over at networking-forum.com: where are OSPF type 4 LSAs generated? Recall that type 4 LSAs serve to advertise the presence of an autonomous system boundary router (ASBR). It would seem natural to assume type 4 LSAs are generated by a border router (ABR) for the area in which the ASBR is located, but that's not the case. Assume the following scenario:
Area 1 (a stub area) and area 2 (a standard area) are separated by area 0 (the backbone). Router A has a link to the 10.0.0.0/8 network, which is not participating in OSPF. Examining the OSPF database from router D yields expected results; we can see type 1, 2, and 3 LSAs for our network:
RouterD# show ip ospf database OSPF Router with ID (172.16.0.4) (Process ID 1) Router Link States (Area 2) Link ID ADV Router Age Seq# Checksum Link count 172.16.0.3 172.16.0.3 187 0x80000002 0x00507E 1 172.16.0.4 172.16.0.4 186 0x80000002 0x004B81 1 Net Link States (Area 2) Link ID ADV Router Age Seq# Checksum 192.168.2.2 172.16.0.4 186 0x80000001 0x00D0BA Summary Net Link States (Area 2) Link ID ADV Router Age Seq# Checksum 192.168.0.0 172.16.0.3 203 0x80000003 0x009374 192.168.1.0 172.16.0.3 42 0x80000005 0x00E812
Now assume we want to redistribute the 10.0.0.0/8 network from router A into OSPF. First, let's convert area 1 to a not-so-stubby area (NSSA), which will allow it to contain an ASBR but still retain its stubbiness.
RouterA(config)# router ospf 1 RouterA(config-router)# no area 1 stub RouterA(config-router)# area 1 nssa
RouterB(config)# router ospf 1 RouterB(config-router)# no area 1 stub RouterB(config-router)# area 1 nssa
Even though we haven't configured router A for redistribution yet, a type 4 LSA has just been advertised by router C into area 2. Why? When we configured area 1 to be an NSSA, this change was communicated to router C, which now assumes an ASBR is present in area 1. After all, why else would it be an NSSA?
We can verify this by again examining the OSPF database on router D:
RouterD# show ip ospf database OSPF Router with ID (172.16.0.4) (Process ID 1) ! -- Type 1, 2, and 3 LSAs omitted -- Summary ASB Link States (Area 2) Link ID ADV Router Age Seq# Checksum 172.16.0.2 172.16.0.3 59 0x80000001 0x00A112
Router C (172.16.0.3) is advertising a Summary ASB (type 4) LSA to router D, indicating it expects an ASBR to reside in area 1. Well, we don't want to be accused of false advertising (pun!), so let's turn router A into an ASBR. Below a static route is defined for 10.0.0.0/8, which is then redistributed into OSPF.
RouterA(config)# ip route 10.0.0.0 255.0.0.0 FastEthernet0/0 RouterA(config)# router ospf 1 RouterA(config-router)# redistribute static % Only classful networks will be redistributed
The notification concerning classful redistribution can be ignored in this instance, since it is our intention to redistribute at the classful boundary (to redistribute classless subnets, use redistribute static subnets). Remember, any sort of redistribution will designate router A as an ASBR; I chose to redistribute a static route because it's the simplest example for our lab.
At this point, our configuration is complete. We can verify that router A is advertising the 10.0.0.0/8 network with a type 7 LSA to area 1, and router B (the ABR) is dutifully converting that LSA to type 5 before propagating it to the rest of the OSPF domain:
RouterB# show ip ospf database OSPF Router with ID (172.16.0.2) (Process ID 1) ! -- Type 1, 2, and 3 LSAs omitted -- Type-7 AS External Link States (Area 1) Link ID ADV Router Age Seq# Checksum Tag 10.0.0.0 172.16.0.1 8 0x80000001 0x0091D0 0 Type-5 AS External Link States Link ID ADV Router Age Seq# Checksum Tag 10.0.0.0 172.16.0.2 2 0x80000001 0x00204B 0
Posted in Routing
Comments
July 27, 2010 at 7:25 p.m. UTC
Hi Jeremy! I was surfing your old post and met this one. Just want to add something. You wrote: "Router C (172.16.0.3) is advertising a Summary ASB (type 4) LSA to router D, indicating it expects an ASBR to reside in area 1." Actualy router C gets LSA type 1 from router B with flag E (AS boundary router) set. In my understanding that means Router B tells to area 0: "Hi everybody, I'm going to be ASBR for you!".
The similar behavior is observed if Router B has 'redistribute xxx' command but doesn't redistribute anything (for example redistribute rip, but rip is not configured there).
August 18, 2010 at 7:25 p.m. UTC
abulanov is correct. whenever an abr receives a LSA type 1 with the E bit set and receives an LSA type 5, it will originate both LSA type 3 and type 4 into the adjacent area, becoming a psuedo asbr.
you won't be able to verify this behavior in ios - it would require packet inspection with wireshark or a similar tool.
October 28, 2010 at 8:17 a.m. UTC
Wireshark is great for confirming this. It should be clear that the ABR which is in the same area as the ASBR will originate the Type 4 LSA ( In this case router B ).
January 12, 2011 at 3:58 p.m. UTC
Hi Stretch,
I like your site, however everyone on here is correct. I also labbed this scenario "who creates lsa type 4" about two years ago and posted it on the peerix project irc channel. The only information that i could find at the time was by Russ White Optimize Edge Routing. The LSA Type 4 is created by the ABR with an LSA type 1 with the E-bit set by the ASBR.
Please let me know if you would like the cap files and the document with all my notes.
January 13, 2011 at 8:26 p.m. UTC
There seems to be a bit of confusion here. The (assumed) presence of an ASBR is communicated from its immediate ABR (router B in this example) via a type 1 LSA with the E flag set (which does not constitute a type 4 LSA) sent into the backbone area 0. The only type 4 LSA generated in this example is sent from router C into area 2, which was the focus of the article.
March 8, 2011 at 5:08 a.m. UTC
hi stretch, thanks for this nice post, I really like the idea about observing the Type-4 LSA generation in NSSA environment. :-) BTW, I found that it is pretty hard to define the ASBR in various setups/situations. :-) I have did a quick documentation about this too. http://www.itcertnotes.com/2011/03/ospf-type-4-asbr-summary-lsa-generation.html
March 28, 2011 at 8:26 p.m. UTC
Is the "Routing bit set" indicative of the E bit being set on the Type 1 LSA? I cannot see evidence of a specific notification about the E bit using the show commands I know.
May 10, 2011 at 9:23 p.m. UTC
So I happened to be studying this topic today and thought I'd chime in.
Regarding this statement from the blog post: "It would seem natural to assume type 4 LSAs are generated by a border router (ABR) for the area in which the ASBR is located, but that's not the case"
It seems to me that in fact that is exactly what is happening, it's just that Router B is actually now both an ABR and an ASBR once you convert to NSSA. The output of 'show ip ospf' on Router B indicates it.
It is an area border and autonomous system boundary router
If that's the case then what we have is an ABR (RtrC) creating a Type-4 LSA to reach an ASBR (RtrB) in its area (Area 0).
Maybe we're all just saying the same thing a different way.
November 3, 2011 at 4:04 p.m. UTC
Hi Jeremy
As i see it both B and C will create the type 4 LSA . B will do this when injecting 10/8 into area 0 and C when injecting 10/8 into area 2 in your example.
June 10, 2014 at 6:51 a.m. UTC
Hi,
The routers inside the area can see the router-id for the ASBR via a summary LSA generated by ABR. Why do we need a special type-4 LSA again? Apart from letting the routers know who is the ASBR, any special purpose for this?
Thanks.
December 25, 2015 at 11:40 a.m. UTC
good read. refreshing for ccnp studies
January 20, 2016 at 11:20 p.m. UTC
How does router D know, which router is true ASBR (router A)? Isn't this information lost, when router B sets flag E in its update toward C, thus acting as ASBR for C?