OSPF Stub Areas

---

Hello, I headed over to this video to get a better handle on LSAs and stub areas.: https://www.youtube.com/watch?v=yhPcpssMx7w
( OSPF LSA Types Simplified... Seriously! )

Kevin is a great resource, Thanks Anthony for pointing me there.

I had a question about Stub Areas.. Is it a requirement in a Stub Area to have a zero route (Default Route) pointed at the ABR ?

For example, let's say you have 4 routers all with their own internet connection. Technically that means they are all ASBRs, I realize. But in this case none of them are advertising the default route with the exception of R2.

So your stub area router (Not ABR) has an independent internet connection and a separate point-to-point circuit for the enterprise internal network. If you wanted the point-to-point used for corporate routing, but the local internet circuit used for everything else.... The zero route (static) would have to be pointed at the internet connection in this case.

The Type 3 LSAs from R2 into the stub area would at least tell the stub area how to get to Area 0 internal corporate networks, that's good.. What about other areas ? What about this default route Type 3 LSA from the R2 ABR, we wouldn't want this to override the local internet default route. however we still want to get to other area networks (non-Area 0)

Is the only option to run a Normal OSPF area and forget stub or is there a solution?

Regards,
Adam Tyler

Hi Adam! So glad to hear you are finding Kevin Wallace helpful. He is awesome (as you now know).

So there are a bunch of different designs and techniques that could ultimately work for you, but, I wanted to point out this document for you. This emphasizes that the default route is not automatically generated in the NSSA area. So this sounds like it would be an ideal solution for use in your scenario.

https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/47870-ospfdb11.html

@Anthony-Sequeira Hi Anthony, thanks for your reply. I was taking Kevin's video on LSAs as the authority on the subject of stub areas and NSSA. In that video, he points out that the difference between a stub area and a NSSA is the presence of Type 7 LSAs. At least from his video Type 3 LSAs for internal networks and Type 3 LSAs for the default route are both still present in each area type.

The only reason I am digging into this is because I am a CCNA (route/switch), so only a basic knowledge of OSPF. That exam didn't really test or cover stub/nssa areas in detail. I used my CCNA studies to begin a dynamic route migration from all static in my organization. Currently we have about 30 routers in the environment (SonicWALL, not Cisco, so OSPF standards only apply). I've established our 4 core routers (beefier devices all with redundant circuits) as the area 0 backbone. The rest of the firewalls are smaller devices that may have 2 or 3 networks, but otherwise connect to area 0 to get everywhere else (except internet). The design basically looks like this...

I've converted probably 10 sites now and things are going well. One hiccup I ran into was an asymetric route problem with equal link costs, that got solved by manually adjusting costs so the paths were a bit more predictable. The SonicWALL firewall also has the ability to support asymetric routing, it was just something that had to be enabled on the interface. So covered on both fronts now.

I am just investigating sub areas to make sure that I am deploying this in the most efficient means possible. If I can reduce drag on the 4 core routers in Area 0 by using a stub area AND still accomplish my routing needs, I didn't want to find out about it after the project was completed. By the time this is all done, I am going to end up having about 25 or so OSPF areas for all of our tiny remote sites.

I am deploying these smaller sites into their own areas to prevent the Dijkstra convergence calculation across all routers in the org whenever there is a tunnel-interface failure to a remote site.. Which occurs frequently. I guess aside from the LSA differences described in Kevin's video, I don't really understand the benefit of the stub area. Especially if I can't use a default route to the ABR.

Thanks for your time.
Regards,
Adam Tyler

Yeah - I am betting he just neglected to point out that the default route is NOT automatically generated into the NSSA, but that you can configure it to be advertised.

The OSPF special area types are always looked on fondly for a couple of big reasons:

1 - we love smaller LSDBs (Link State Databases) whenever possible
2- we love reducing the size of convergence domains whenever possible

Remember, the convergence domain is all those routers a local router must update when there is a prefix status change.

The "classic" example would be a very stable internal OSPF backbone and normal area design, and then we introduce an ASBR and we need to take in thousands of prefixes. We would love to shield areas from needing convergence on changes with these Type 5 LSAs that are expected to occur. The machines in the Stub area get to enjoy the stability of the OSPF internal network in peace and not be bothered with the "chaos" that happens with the Type 5s.

BUT - this can come with a cost, and your original post certainly hit on one of the challenges. The ABR in the case of Stub will automatically send a default route into the area. This can present a challenge if you do not want to use that route for the Internet in that local area - as you correctly identified.

I think this is the MAIN reason that the default route is not automatically generated with the NSSA configuration. In fact, since your NSSA area is taking in external prefixes, it is quite clear that you might have a WAN circuit to the Internet in the NSSA area.

So the benefit would be pretty case specific with the NSSA. You have Type 5 LSAs elsewhere in the OSPF domain that you do not need in the NSSA. So you let them be filtered dynamically by the feature, and you configure the default gateway for the NSSA to point to its own Internet connection with static routes on your NSSA members.

By the way, Cisco always recommends monitoring the devices to see if you are even going to significantly benefit from some of these design decisions. I can only image the number of elaborate and overly complex OSPF designs out there where the network and LSDBs were not even large enough or unstable enough to warrant any of the design to being with. Like so much in life - Keep It Simple when you can.

@Anthony-Sequeira Thanks Anthony, If I understand you correctly, you are saying that an NSSA in my deployment case is probably not the direction I want to go as I don't have an ASBR redistributing Type 5 LSAs anywhere in the environment.

I have been monitoring core router CPU utilization as I convert new sites over to OSPF and so far so good.

When you say "the convergence domain is all those routers a local router must update when there is a prefix status change", I am not sure I follow. In our case a "prefix" change most often occurs when a site goes offline and the "prefix" or "prefixes" for that site are no longer present.

I assumed that for the smaller sites that go offline more frequently, a separate area would reduce drag a bit on the overall OSPF environment. When I read your statement about convergence though, I'm thinking all routers have all routes in all areas.... When a prefix goes away, they all get updated.... What good is a separate area? Convergence still occurs, the only benefit is a type 3 LSA? Which less data than other LSA types? Kevin explained a Type 3 LSA as a summary LSA, it was more efficient in some way, it didn't contain the detailed data in Type 1 or 2 perhaps?

Regards,
Adam Tyler

I am not referring to your deployment case at all with any of my comments - I am just trying to make sure you understand OSPF special areas.

So here is a scenario to illustrate the point of smaller convergence domains.

You have a backbone area connected to 4 totally stubby areas. The following are examples of convergence for this design:

• A prefix is removed from the backbone - this change is constrained to the backbone; no need for convergence to the 4 totally stubby areas
• A prefix is removed from a totally stubby area - there is no need need for convergence to take place against the other 3 totally stubby areas.

Now - if you have a backbone area and four normal areas - you still achieve scalability benefits, but you will have convergence events that are no longer scoped to the special areas. The scalability benefit is that an internal router to an area is going to have a smaller LSDB. This is great.

When a prefix is lost in a normal area in this design - a Type 3 is used to convey the change to all areas.

@Anthony-Sequeira Thanks Anthony. When you say an "Internal Router", you are referring to a router that is NOT an ABR? In other words, all interfaces need to be within the same OSPF area for it to be considered an "internal router" and receive the scalability benefits of using multiple areas?

If you can hang with me for a few more questions, I'm still not clear on when someone would use a stub area, totally subby area, NSSA, and Totally NSSA.. Especially when it comes to more modern network topologies. Well aside from the convergence benefit you just outlined. For example, let's consider the following network.. (Apologies for the quality, I realize it looks like a 1st grader made it, going fast.)

Requirements and info..

1. Each site has it's own independent link to the internet. The default route should not be redistributed from any router.
2. All sites should be able to route to all networks in the event of a Link A or B failure between backbone area 0 and Area 1/2
3. Each site link is a point-to-point OSPF connection. Ie.. No DR/BDR election.

Questions...

1. Because every router has an internet connection, does that make every router an ASBR? Even though they technically are only running a single routing protocol for internal routing only?

2. Does it make sense in this network topology to use a stub area, totally subby area, NSSA, or Totally NSSA for area 1 or 2? Why or why not?

3. If the site links were not point-to-point and went through DR/BDR, would that change the response to question 2 ? Why or why not?

Regards,
Adam Tyler

Yes - you should study and know the following OSPF terms:

• Internal
• ABR
• ASBR
• Backbone

As you correctly stated, an internal router has all of its interfaces in a single area. Note that may be the backbone, making the router both an internal router and a backbone router at the same time.

Questions:
1 - Just because a router has an Internet connection, it is not considered an ASBR. An ASBR, by definition, redistributes external routes into OSPF. If you are taking a default route from your ISP and redistributing that into OSPF, then your Internet connected router is technically an ASBR. Also, of course, if you were taking in some Internet prefixes from your ISP, you would also have an ASBR. But remember, just because you have a WAN circuit to an ISP does not mean you have an ASBR.

2 and 3 - Because your areas 1 and 2 have Internet connections, it will be overly complex to start messing with special area types as you will have issues with default routing as you pointed out. Also, your OSPF topology is not nearly large enough to worry about these scalability mechanisms.

@Anthony-Sequeira Thanks Anthony, I haven't gone through a test prep cycle since my CCNA renewal in November, thanks for confirming details around Internal and ASBR for me. The term "Backbone" router in regard to OSPF I don't think I recall covering at all.. I know that area 0 is the backbone area and all traffic must traverse area 0, but what about a router in area 0 makes it a "backbone" router? Aren't they all?

What about an OSPF topology makes it "large enough" to require you to begin looking into special area types? It's good to know that in this particular topology a special area type doesn't make sense. you're the first person to comment really one way or the other.

All of the documentation I run across regarding special area types seem to be specific to traditional networks that zero route traffic to a central datacenter or set of datacenters from the stub area. I am sure larger enterprise environments still do this, but I've never seen it.

Regards,
Adam Tyler

A router that has ANY interface in Area 0 is considered a backbone router. Therefore, an example of a non-backbone router is an internal router in a normal area.

For OSPF, you would monitor resource utilization and database sizes in order to determine:

• Number of routers per area
• Number of areas
• Special area types

Keep in mind that many small to medium-sized environments never need anything beyond the backbone.

@Anthony-Sequeira Thanks again Anthony. Marking this thread as a conversation rather than a question. I appreciate your input.

I recall the point being made in my original CCNA studies with Don that area 0 alone is appropriate for most SMB networks. I don't know if you mention that point in regard to my production deployment or not, but here I go with my justification for multiple areas. Please pick it apart, sort of fun to bat this around with a CCIE.

In the case of my migration to OSPF in production, the focus was to narrow "area 0" routers to those with redundant links. These links are also more stable and faster compared to the rest of our environment. Usually fiber and at least 100Mbps. I didn't ever want to find myself in a situation where area 0 was "split brained" and isolated from other portions of area 0.

Additionally I didn't ever want a branch office router to be selected as an interim hop. Just in case there was a cost calculation error on my part. All costs are hard coded due to all adjacencies being formed over tunnel-interfaces (virtual interface tied to IPSEC VPN policy). These tunnel interfaces natively don't correctly represent the internet circuit link speed. This also simplifies firewall configurations at the branch because I can assume no interim traffic.

So, our four core area 0 routers have redundant internet circuits from different providers and VPN policies with tunnel-interfaces making up redundant /30 networks for OSPF adjacencies between them all.

I work for an air EMS agency and we deploy small "branch" offices all over the place (Pilot, Medic, RN, Mechanic), we have about 30 sites today. Sometimes we are lucky to get a point to point radio based internet circuit or DSL. These things are slow and go down frequently.

So the branch routers get a connection (tunnel-interface) to each core router circuit. 8 different /30's with costs hard coded so that failover is predictable. Many times there is a temporary internet based routing problem that will kill a particular VPN to one of the core routers and the branch will automatically route around the problem. This is really nice in cases where the internet circuit still is partially up, but some* destinations are unreachable. It happens more often than you'd expect when managing an enterprise network over multiple ISPs across different states.

Regards,
Adam Tyler

Yes - you are crushing it! You have reasons behind your design that make sense! Awesome!

We never want to be designing complexity into the network just because those options exist - and you are NOT doing that. Awesome.