OSPF Type 4 LSA

Books dont worth much about Type 4 LSA in OSPF.

Is type 4 LSA present in stub area, totally stubby area, nssa and totally nssa?

The only thing I know about Type 4 lsa is that it describes ASBR and is propagated by ABR.

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

Scorp6

From what I know type 3 and above lsa do not go into stubby areas or nssas at all. Someone please correct me if I'm wrong. The exception is type 7 for nssas so they can get through as a type 5.

OfWolfAndMan

Type 4 and type 5 LSAs are not flooded into any type of stub area. Because of this, the ABR connected to the stub area advertises a default route to any other router in the stub area. NSSA and TNSSA use type 7 LSAs for external route advertisement. Once the type 7 leaves the NSSA area, it is converted to a type 5 by the ABR connecting the two areas.

powmia

The fact that a Type-4 LSA provides reachability information about an ASBR (which is a device advertising external routes) means that a Type 4 would be found in areas containing external routes.

Which areas are allowed to contain external routes?

Normal
NSSA
Totally NSSA

But... Type-4s are generated by ABRs to tell one area about an ASBR in another area. If NSSA and Totally NSSA means that no external routes traverse the ABR and is only NSSA so that routers within that area can bring in their own external routes... there is no ABR generating Type-4 LSAs within (obviously) that area or to that area, only for an ASBR in the NSSA area towards the backbone area. So...

Type-4 LSAs would be found in Normal areas only.

fredrikjj

The only somewhat complicated situation is when a non-backbone area has an ASBR, and another non-backbone area wants to reach an external destination advertised by that ASBR.

Area 2's ABR (router C) will need to generated a new type 4 LSA by combining the metric found in the type 4 advertised by router B and its own intra-area cost to reach B.

type4lsa.jpg

hitmen

stub T3 Y T5 N T7 N ASBR N
totally stubby T3 N T5 N T7 N ASBR N
nssa T3 Y T5 N T7 Y ASBR Y
totally nssa T3 N T5 N T7 Y ASBR Y

OfWolfAndMan

fredrikjj wrote: »

The only somewhat complicated situation is when a non-backbone area has an ASBR, and another non-backbone area wants to reach an external destination advertised by that ASBR.

Area 2's ABR (router C) will need to generated a new type 4 LSA by combining the metric found in the type 4 advertised by router B and its own intra-area cost to reach B.

Forgot to mention that as well. The primary reason for implementing an NSSA/TNSSA area!

fredrikjj

OfWolfAndMan wrote: »

Forgot to mention that as well. The primary reason for implementing an NSSA/TNSSA area!

Uhm, not really.

Of the four stub areas that exist (stub, totally stub, nssa, totally nssa) only the plain stub originally existed. As you know it removes external prefixes. This is kind of curious at first glance because you probably shouldn't have a huge amount of external prefixes in your database anyway, right? That's what BGP is for. To understand why you need to understand that OSPF was conceived of in an era where it seemed plausible to redistribute all or some of your external routing protocol into OSPF. The problem with that is/was that the external prefixes have a domain wide flooding scope so you would be memory constrained by your weakest router. Note that we're talking about the 90s here when your weakest router was pathetic by today's standards. So if you had a crappy router you could isolate it and protect it from too many type 5 LSAs.

This memory problem also influenced the creation of the type 4 LSA. If we look at what the type 4 LSA is doing, it's informing us about the optimal to an ASBR if we're in another area than the ASBR. An alternate solution would have been to simply make it so that the entire path cost, except intra-area, was reflected in the type 5 LSA itself. However, this would require you to readvertise the type 5 by ABRs, and you would end up with multiple copies of the same prefix, one for each ABR. The routers would then pick between these and forward to the ABR that advertised the cheapest type 5 (including its own cost to reach the ABRs). It's at least conceptually simpler, but it would require more memory.

The NSSA was added later and wasn't a part of the original specification. The problem that it's trying to solve is pretty obvious. We have a router that must be in a stub area because it can't handle all the type 5 LSAs, but we also want the ability to introduce external routing information. Its behaviour is kind of weird though with the forwarding address, the type 7 to type 5 translation and all that. What's the deal? It's a result of requiring backwards compatibility between the original OSPFv2 specification and implementations that have added the NSSA feature. We must translate the type 7 LSA into type 5 because otherwise every single router in the network must be able to handle type 7 (remember, domain wide flooding scope). We must maintain the forwarding address because if we didn't, we would need to translate from type 7 to type 5 on all the NSSA areas's ABRs to get optimal routing, and that would create unnecessary duplicate external LSAs in every router. If we didn't need this backwards compatibility we could just flood the type 7 everywhere without translation, and then use a type 4 LSA to advertise the distance to the NSSA ASBR.

OfWolfAndMan

I just read into the RFC Fredrik. I do see what you were saying. If the routes were not extensively filtered, it'd reduce a lot of load on the backbone routers, assuming that the other areas are configured as a stub. I assume you've seen this more often when OSPF is acting as more of a transit rather than as an endpoint.

fredrikjj

There is one thing I haven't managed to figure out though. It's why you can't just use a forwarding address in the type 5 LSA instead of having a specific type 4 LSA to accomplish the same thing. There are a few (one?) scenario(s) where one is added to avoid an extra hop, but as a general rule it's zero in type 5s. The idea would basically be to have every ASBR advertise a loopback address and set the forwarding address to this loopback. In other areas, routers would use the inter-area cost to reach this loopback instead of looking at a type 4. Like the FA in NSSA. Maybe I'm missing something,.

powmia

Routers install routes to destinations based on the SPF tree. An ASBR is not in the tree of a router in another area. ABRs advertise Type-4 LSAs as leaf nodes so that a router does actually have a way of reaching the ASBR via it's own tree, which is limited to the area it resides in.

Danielh22185

Don't let Cisco confuse you too where Type 4 LSAs are generated from. I always used to think of them being generated from the ASBR because of the relationship they have with external routes. The Type 4 LSA does represent the external routes (in a matter of speaking) but it's representing the path to the ASBR only that contains the external routes (Type 7). So if thinking in terms of the OSPF backbone the ABR is the responsible one that ONLY generates TYPE 4 LSAs.

EdTheLad

Danielh22185 wrote: »

The Type 4 LSA does represent the external routes (in a matter of speaking) but it's representing the path to the ASBR only that contains the external routes (Type 7). So if thinking in terms of the OSPF backbone the ABR is the responsible one that ONLY generates TYPE 4 LSAs.

The NSSA ABR does not advertise a type 4 lsa into the backbone. If it's the elected translator for the NSSA it translate type 7 lsa's that have their P bit set into type 5 lsa's. It then adds the forwarding address, which is usually the next-hop ip of the asbr that advertised the type 7 lsa. The next-hop(forwarding) address is advertised into the backbone as a type 3 lsa summary by the nssa abr. Therefore in order for backbone routers to reach the external routes, they will be routed to the originating asbr's next-hop address.
If the actual nssa abr is redistributing the ext routes, the forwarding address is 0.0.0.0, the backbone is already aware of this nssa abr via type 1 lsa's so again no type 4 lsa is required to be generated from the nssa abr.
You have to be careful when filtering on a nssa abr, if you filter the type 3 lsa describing the forwarding address, you will break routing to the associated nssa asbr. There is a option you can configure on the nssa abr to suppress the forwarding address, this will eliminate the need for the type 3 summary into the backbone.

cjsaves

also remember "totally" are all Cisco proprietary.