Multiarea OSPF and LSA Types

0:00[AUDIO LOGO] Welcome to multi-area OSPF and LSA types. In this skill, we're going to jump in and look at some of the advantages and, well, a couple of the disadvantages to running OSPF using multiple areas rather than just a single area. We're also going to take a look at the LSA types that operate within the area, between the areas, some of our extras.

0:33So we're going to talk about all the different LSAT types and their role in our OSPF environment. So we have a lot of stuff here we need to cover. Let's go ahead and jump in and get started. I'll see you in the next video.

0:00[AUDIO LOGO] In this video, we're going to start off by looking at single area OSPF. We'll take a look at what the database looks like, as well as what happens if there's a failure in single area OSPF. We'll also, of course, talk about some of the advantages and disadvantages of running OSPF in a single area. So let's go ahead and jump in and get started by talking about some of the attributes of single area OSPF.

0:36So the first thing we want to consider when talking about using, particularly single area OSPF is it's main issues come into play with scalability. The real issue here is when our network starts getting very large, single area just really doesn't cover it. There are, of course, a few reasons for this. The first is that the Dijkstra algorithm really can cause high CPU utilization.

1:07Remember, it has to run against the entire database for the area. And because of that, it actually makes the running of OSPF proportional to the square of the number of routers. So the more routers there are in an area, that means the database is going to be larger. And overall, it means that Dijkstra is going to take a lot more horsepower to run on our devices.

1:37And going along with that, since each router must hold the complete link state database for that area, it means that it can also cause high memory use. Now, just as a note on this topic, when we say high memory use on today's devices, honestly this is probably not going to be an issue. But it is something to keep in mind, particularly if you have a very large environment or if maybe you have some dated routers that are still in your environment.

2:11But overall, really neither one of these two issues is really going to be a huge concern on today's routers until our network starts getting very large. But these are some things we need to keep an eye on as our OSPF environment gets larger. So we're going to jump over to the command line and take a look at what the database looks like and what failures look like in an OSPF single area. To do that, we're going to be using this topology.

2:42As we can see, this is all of our routers, router 1 through router 10, all being in a single area zero. So this is not an exceedingly large environment. Again, it's just 10 routers. However, we'll still see how every single one of these devices is going to be receiving all of the LSAs from all of the other routers. So every single router is going to have every other routers LSA information in its database.

3:12So we'll see this as we look at some of our different routers. Let's jump over to the command line and take a look. So let's start off here on router 10, and let's just start with a show IP route OSPF. And what we see here is that we have all OSPF intra area routes. We can tell because our key here is just an O where it would be followed by something else like an IA or an E1 or any E2, if this was external and so on.

3:46So we can see by the fact that there's nothing after the O, that these are all routes from within the same area. And this applies to all the routes. If we do a show IP OSPF database, we can see that all we have are type 1 and type 2 LSAs. These are known as router links states and network link states. We don't have any LSAs that would be coming from other areas. This is, of course, because everything's in this area.

4:18We will talk more about these link state types in an upcoming video. So now let's take a look at what happens if we trigger SPF to actually run. Let's start with a show ip ospf. And what we want to note here is that for area zero, currently SPF has executed 17 times. And this is simply how many times it executed while this particular lab environment was being built. So let's take a look at what happens when a change occurs in OSPF.

4:53Let's turn on a debug ip ospf spf. So we have this on. Let's now switch over to router 5. Here we'll go into configuration mode. And we'll simply go in to say it's loopback and shut that interface down. We'll switch back over to router 10, we'll scroll up a little bit here. And what we see as we start going down through the database, obviously a lot is going on. There are several pages here. We're not going to look at every detail of this.

5:23But what we want to see is that SPF is definitely executing, and it's checking every single route in the database. So we can see here, as we scroll down through this, this is covering the entire OSPF domain because it's all in one area. So we're forcing SPF to run against the entire database here. And as you can see, this is quite a bit of work. There's quite a bit going on here in the debug.

5:54And if we look at the very end, we can see that this actually took on this equipment 17 milliseconds. Now, that's of course not a whole lot. But let's see how that stands up when we get to multi-area OSPF next, and we'll see if it's any faster when it's converging on a much smaller area. Now, it might not be much faster, again, this is a relatively small lab environment. But let's see if we get any performance increase when we go multi-area.

6:24The main thing, of course, however, regardless of how long it actually took, is if we do our show ip ospf again, notice that now, SPF algorithm has executed 18 times, which means it did in fact run again in response to this change. And of course, if we bring that interface back up, so back over here on router 5, we'll simply do a no shut. Back over on router 10, we can see that it once again executed SPF.

6:54We don't have to scroll through the whole thing again. I think you get the idea. This time it only took 14 milliseconds, so it was a little bit faster. And again, if we look at our show ip ospf, we see that it's now executed 19 times. So this is definitely executing SPF any time anything changes in the area. And this is part of what leads to that scalability problem. In this video, we talked about, well, mostly the disadvantages of running a single area in OSPF, mostly focused around that scalability issue.

7:34But keep in mind, like most things, there are advantages to running single area OSPF as well. First, it's definitely easier to configure. And it's certainly easier to design, since it's literally just a single area. And it also has some advantages because certain technologies such as MPLS traffic engineering actually function better in a single area environment. And when you go multi-area, it gets a bit more complicated.

8:06So like most things, it certainly has advantages and disadvantages. And we'll talk about this a little bit more in our next video as we jump into multi-area OSPF. I hope this has been informative for you. And I'd like to thank you for viewing.

0:00[AUDIO LOGO] So now, let's jump in and talk about multi-area OSPF. This is going to be used two address our scalability issues with OSPF. Now understand, this still won't scale as large as something like BGP. It still can't carry hundreds of thousands or millions of routes. However, it will let us scale it up to a much larger environment than we could with just a single area.

0:35It also brings to the table the ability to do route summarization. Keep in mind as we talked about in the previous video, all of the routers in an area have to have the same exact link-state database. And, of course, a side effect of that is I can't have one router have a /16 for a network while another router has a /24. So since they have to have identical databases, we cannot summarize within an area.

1:07So we have to have multi-area OSPF in order to do proper summarization. That also implies that our summarization points in our network also have to fall on area boundaries. So let's go ahead and take a look at some of these things. We'll start by taking a look at some of the attributes of multi-area OSPF. And then, of course, we'll jump in and take a look at what our databases look like with multiple areas. Let's get started. So as we said during the introduction, the biggest thing that multi-area OSPF brings to OSPF is really that scalability.

1:46And again, the reason this helps is because remember, that all of the routers in a given area have to have identical link-state databases. And by having multiple areas, that means that SPF is only run for database changes within that area. So the way that it works in between areas is we only carry prefix information between those areas. We do not carry the full database information.

2:22Now, we'll talk a lot more about these LSAs, the different types of LSAs within the area and between the areas in an upcoming video. But for now, just realize that the LSAs sent between areas carry less information. And we don't actually run Dijkstra against those LSAs. And we'll see this in action in just a few moments. Now, one of our requirements when using multiple areas is we do have to follow a very strict hierarchy.

2:58The reason for this is as we mentioned during the introduction, the only place we can summarize in OSPF is at these area borders. And because of that, this has to follow our IP structure as well. So that where our areas cross, this is also the place that we can actually do our network summarization. So this does require a very specific design. Now, not only does this have to follow our IP addressing scheme, but this hierarchy does have some rules of its own.

3:34The first, of course, is that there must be a backbone area. This is an area that all of the other areas have to connect to. This has a few guidelines. First, it must be area zero. This is not an option in OSPF. As soon as you have more than one area, one of them has to be area zero. It also must be contiguous. In other words, you cannot have two separate area zeros.

4:04So you cannot have, for example, an area zero here, have a net router between them, have this connected to, say, area 21 with another router. And then over here, do another area zero. This would be a split area zero. This is not allowed. Now, there are ways we can make this work, which we will talk about in future skills. But in making it work, what we're really doing is fixing the fact that it's split and making it so that it's not split.

4:37That's the actual fix for it. And the last point here is not so much a rule as a guideline. We don't generally put end user devices or resource networks, such as servers, or printers, or things like that in the backbone area. It certainly can be done. Area zero is a full blown OSPF area. So you can do this. But area zero is very often reserved to just be a backbone and, therefore, not actually have any resources in it.

5:10All of the other areas are then non-backbone areas. Now this, of course, can use any 32-bit number. They all, as we said earlier, must be connected to area zero. And this is usually where we provide those connections for the end users. And those resource networks that we spoke of up above. So quite commonly, what you would have, you would have an area zero, connect it out to some other area, say, 21 again. And this is where we would actually connect in our resources.

5:44Let's take a look at this in a little bit more of a structure diagram. So here, we have a typical multi-area OSPF design where, of course, we have our backbone area, area zero, as well as two other areas, area 100 and area 200. So the main thing we want to look at here are the different roles of the routers when we start getting into a multi-area topology. So the first thing we have is something called a backbone router. That would be this router here, which is a router that has all of its interfaces in the backbone area.

6:21Other routers would be things like internal routers, which are routers such as these that have all of their interfaces in an area other than area zero. And in case you're wondering here, yes, a backbone router is also an internal router. We just give it a more specific name because all of its interfaces happen to be in the backbone area, area zero. But yes, it is still an internal router. Now, the other routers here are a little more specialized.

6:53The first thing we have is an ABR or an Area Border Router. And that would be this router and this router. These are routers that have one interface at least in area zero and one interface in some other area, possibly more than one. But nonetheless, these are then performing the job of an ABR or an area border router. This, by the way, is where we can actually do our network summarization.

7:23So the ABR is where we can summarize internal routes. Now, we have another type of router here bringing in routes from the outside. So maybe, for example, this would be something like BGP. Maybe this would be something like EIGRP or something like IS-IS. The router performing these functions is called an ASBR or an Autonomous System Boundary Router. This is a router that's doing some form of redistribution from these external protocols into OSPF bringing external routes into our network.

8:05This is where we can actually summarize external routes. So technically, we can summarize at the ABR or at the ASBR, depending on which type of route we're talking about. The ABR, again, is for internal routes going between areas. The ASBR can only summarize the external routes as they're being brought into OSPF during the redistribution. So now, let's wrap up with a look at some advantages and disadvantages of multi-area versus single-area OSPF.

8:42So let's begin with the advantages. First, we have that it allows for filtering and summarization between the areas. Now, we've been talking a bit about the summarization as we go here. We haven't mentioned a whole lot of filtering. But for the exact same reason that we can only summarize between areas, the ABR is also the only place we can filter. So again, with multi-area we can do route filtering between the areas as well as summarization.

9:15It also localizes the impact of any topology changes. So if an interface goes up, an interface goes down, or more importantly, if an interface is flapping, it won't affect the entire OSPF domain. It would be localized just to the single area where the problem is occurring. Part of that also relates to the containing of the flooded detailed LSAs. But we're really talking about containing the flooding of those detailed LSAs regardless of whether it's because of a topology change, but just in general.

9:51This is what causes that larger database and for the longer execution of Dijkstra's algorithm. Now, these are really good advantages. Very, very important that we keep these in mind. And quite frankly, these are most of the reasons that we're going to go with multi-area OSPF. Now, of course, scalability is also a huge advantage. But I was trying to go for some more specifics here. Now, there are some concerns, however, with running multi-area OSPF as well. You could also refer to these as advantages to running single area, however you want to look at this.

10:24But the first one is that the routers no longer have full visibility of the network. Now, we'll get into this more as we go through future skills. But since the routers no longer have full visibility, this can actually lead to routing loops. Link-state routing protocols are immune to routing loops. Because they have that full visibility. But without that full visibility, you lose that immunity.

10:56So as we start digging into more detail with multi-area and how our ABRs work and such, we'll get more into how this actually has to do loop prevention and implement some rules on our ABRs. And further talking about those ABRs, we need to make sure that they don't become a single point of failure, which means we have to worry about redundancy with those ABRs. Meaning, we should have at least two ABRs between our areas in most cases. And finally, there are some technologies that just don't work as well without having a single area.

11:34One of those as an example would be MPLS traffic engineering. Can we get it to work between areas? Yes. Is it much more difficult to configure and set up? A bit. So it's certainly more preferred to have a single area for things like traffic engineering, if it can be accomplished. In this video, we jumped in. And we took a look at some of the advantages and a few of the disadvantages of running multi-area OSPF.

12:07Keep in mind its main advantage is scalability. Because at a certain point, we simply can't run Dijkstra against a really large database and still have an efficient network. I hope this has been informative for you. And I'd like to thank you for viewing.

0:00[AUDIO LOGO] So now that we've taken a closer look at Multiarea OSPF, let's jump into the command line and take a look at some of our database commands to see what this actually looks like in the OSPF database. So we'll start off by looking at our topology, how our areas are currently set up. Then we'll jump in, we'll take a look at the databases, as well as watching how Dijkstra's algorithm actually runs now that we have different areas in our OSPF environment.

0:38So let's start off by looking at that topology. So for this demonstration, we will be using OSPF topology 2. And what we see here is now do we not only have area zero, but we also have area 100 and we have area 200. The way things are configured we have router 6 is acting as an ABR. So is router 1 and router 3. We also have router 2 over here, which is an ASBR bringing in external routes from EIGRP.

1:12Now in this demonstration, we're simply going to be focusing on what's happening inside of OSPF with our different areas. So we won't really be looking at the external routes coming from router 9 at this point, we'll be using that later. But for now we're going to focus on what happens when failures occur in these different areas now that we're not in one big area. So let's jump into the command line, and we're going to start by looking at area 200 since this is a very small area and let's see what happens when a failure occurs there.

1:52So let's start here on router 6. And let's turn on a debug of IP OSPF SPF and we'll go over to router 10, and let's shut down one of its interfaces. Specifically, we'll just shut down its loopback 0 interface. Now let's go back over to router 6, we'll turn off our debugging. And what we want to notice here that SPF ran and notice that it only took 8 milliseconds for this to occur, which is significantly faster than what happened when we ran this earlier when everything was one big area.

2:30So even in an environment as small as this, we're definitely getting a performance increase by having multiple areas. So let's bring that interface back up on router 10. So now let's take a look at what happens when a failure occurs between areas. For this demonstration, let's keep an eye on what happens on router 7 when we create a failure on router 5.

3:04So we'll start by doing our observations on router 7. Let's start with the show IP route OSPF. Notice that we do have an entire area route for 10.5.5.5 which is router 5's loopback. If we do a show IP OSPF database, notice that we also have numerous type III LAs here, which are the summary net link states. And notice that we in fact, have one for 10.5.5.5.

3:37In fact, we have two, one coming from each of our ABRs. And finally, let's do a show IP OSPF. And when we want to look at specifically is for area zero how many times SPF has actually executed. At the moment it's 129 times. So let's take a look at what happens now if we shut down that interface on router 5. Let's turn on our debug. So we'll debug SPF here on router 7 then we'll go over to router, 5 and we'll shut down that interface.

4:13Let's go back over to router 7. We notice here that it definitely did calculations. We can see where the network is being removed, and we see that it processes things. But what's not here is any calculation for how long it took to run SPF because it didn't. If we say show IP OSPF again, notice that the execution of the SPF algorithm is still at 129 times even though we recognize the failure.

4:46And if we do a show IP route OSPF, we'll see that the 10.5.5.5 is now in fact missing, and we don't have it in our database either. So we've removed it from our database, we've removed it from our routing table but we did not execute SPF. This is the big advantage of having multiple areas in OSPF. When a change or a failure or anything happens in another area, yes we learn about it.

5:17Of course we do, this wouldn't be much of a routing protocol if we didn't, but we're not running SPF. We still remove it from the database, we still remove it from the routing table, but we don't have to run SPF every time something changes in another area, that would even include the route coming back up. Let's go back over to router 5 and bring that interface back online. So we'll pop over here, we'll do a no shut to bring the interface back up, back over to router 7. Notice once again, we're adding the routes back into the routing table.

5:52We do a show IP route OSPF, there's the 10.5.5.5 back in our table again. We do a show IP OSPF database, the 10.5.5.5 is again here in the database. However, if we look at our show IP OSPF, notice still the SPF algorithm has only executed 129 times. We're not running SPF because the changes are not occurring in this area.

6:24In this video, we took a look at how the database reacts and how the execution of SPF reacts when changes occur both within our smaller areas, as well as what happens between areas when we have a failure that's not in our directly connected area. So we saw that within the area things happen faster because it's a smaller area. And we saw that between areas although we of course lose the database entry and therefore the route, we don't run SPF when something changes in a different area when we're doing Multiarea OSPF.

7:05And this is what adds to the scalability of doing Multiarea OSPF. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] So now that we've gotten some more detail on multiarea OSPF, now let's jump in and look at our different LSA types and the role that they play in our multiarea SPF topology. So we're going to start off, of course, by looking at type 1 and type 2 LSAs that work within the area. Then we'll look at our type 3 LSAs between the areas.

0:31We'll look at our external LSAs, our LSAs for our ASBR-- so our summary ASBR entries. And then we'll finally wrap up by taking a look at LSAs that we use in a not so stubby area or an NSSA. So we'll take a look at each of these. And then in our next video, we'll actually jump in and see these in action on the routers. So for now, let's jump in and take a look at the role of each LSA in the multiarea OSPF topology.

1:05So our first LSA type is of course going to be LSA type 1, otherwise known as the router LSA. So the type 1 LSA is generated by all routers in OSPF. And as such, this serves as the fundamental building block for our OSPF database. This is what contains all the information about the router and its links. So this is going to include things like the router ID to identify the router, as well as the current status of all of its interfaces.

1:41Now, since this is the detailed information for the database, this is going to be contained within an area. So if we were to, for example, pick on router 7 here, it's type 1 LSA will be sent over here to router 8. It would be sent up to router 6, to router 1, and over to router 3. However, it won't go any further than that. Router 6 would not flood it into area 200.

2:11Router 1 and router 3 would not flood it into area 100. Type 1 LSAs are completely confined within the area. And again, they're used to define the routers themselves. Next is the type 2, or the network LSA. Now, this is generated by the DR, or the Designated Router, on a broadcast network type. In our example, we actually have two broadcast network types.

2:45So let's take a look at the one in area 0. We have three routers connected to this-- router 6, router 7, and router 1. These are all connected to this common subnet 50.0.167.0/24. One of these routers will be elected as the DR. Keep in mind that the default for this election is to go with the router with the highest priority.

3:16All routers, by default, have a priority of one. So if we as administrators don't take control over this, it will then go to the router with the highest router ID. The router ID is generally based on its loopback interface. So therefore, it would probably go to the router with the highest loopback address. In our example, that would, in fact, be router 7 here. So let's go ahead and label that as our DR, assuming that that's the router that would have won. So if router 7 becomes the DR, that means that router 7 is going to be the one to generate this LSA.

3:53This would get sent to router 3, to router 6, to router 1, and of course, over here to router 8. Once again, it gets flooded through the whole area. This contains information about that multiaccess network segment. So this contains information about this 50.0.167.0/24 network. Now, just like the type 1 LSAs, these are also going to be contained within the area, which means, once again, router 6 will not send this into area 200.

4:30And router 1 and router 3 will not send this into area 100. The main purpose of doing this is so that all of the routers connected to this multiaccess segment don't have to generate the type 1 LSAs for that link individually. So the idea is we send this information out. The DR tells everybody else which routers are connected to this multiaccess segment. We'll see this in the next video when we look at these in a little more detail.

5:05Keep in mind, as well, in our example, this same thing would happen for this segment over here in area 100, which is also a multiaccess segment. In other words, it's network type broadcast. Next up is the type 3 LSA, or the summary LSA. This is the LSA that's actually generated by ABRs to represent the prefixes in this area. So say, for example, router 7 has a loopback interface.

5:40That interface will get sent with a type 1 LSA to router 6. Since router 6 is in fact an ABR, it will then generate a type 3 LSA into area 200, representing router 7's loopback. At the same time, router 7 is also going to send this to router 1 and router 3 with type 1 LSAs. And both router 1 and router 3 will generate a type 3 LSA into area 100, again, representing router 7's loopback.

6:19This happens, of course, for every prefix in every area. We're just picking on router 7's loopback. But we would have the exact same thing going the other direction. So if we were talking about router 4's loopback, for example, once again, it would go as a type 1 over here to router 3. And router 3, of course, would generate that type 3 into area 0. So again, this is going to be for all prefixes in all directions between all the areas.

6:50And that's what this point is that it's used to advertise the prefixes from one area into another area. As we just demonstrated, this is going to be flooded both into the backbone and into other areas. Now, remember what we learned in our previous video that when we get these type 3 LSAs in another area, yes, we have to update our database, either adding or removing the prefix.

7:22And of course, that causes us to update our routing table, either adding or removing the route. But we do not run SPF, Shortest Path First, or Dijkstra's algorithm in response to receiving these type 3 LSAs. Also keep in mind that although these are called summary LSAs, it's referring to the fact that it's a database summary. Don't look at this as a network summarization. This is where we can create a network summarization, but we have to do that manually as administrators.

7:56Now, we can do that to help reduce or control the flooding of these type 3 LSAs into other areas. And we'll look at that in a future skill when we get to summarization and filtering between areas. But keep in mind that that's going to be talking about controlling these type 3 LSAs. By default, all prefixes are sent into all other areas with a type 3 LSA. Next is the type 5 LSA, or the external.

8:29Maybe you're thinking to yourself, wait a minute, what happened to the type 4? We're going to get to the type 4. But since the type 4 is to support the type 5, it actually sort of makes sense to talk about the type 5 first, even though, numerically, that's not exactly in order. So let's talk about the type 5 first. This is going to be generated by the ASBR That's doing redistribution into OSPF. In our example, that would be R2.

9:00This is our ASBR. And what it's doing is taking the EIGRP prefixes and redistributing them into OSPF. This is going to come in as a type 5. So again, this is going to be advertising those prefixes from an external protocol in this example, such as EIGRP, into the OSPF domain. This is then going to be flooded through the OSPF domain. Well, what that means is when R2 sends this in, it's going to go to R4.

9:35It's going to go to R5. It's going to go to R1. 4 is going to send it over here to 3. Router 1 is going to send it into 6. 6 is going to send it to 10. 1's going to send it to 7, and so on. Of course, 7 sends it to 8. 3 sends it to 7. You get the idea. It's going to be flooded everywhere. Now, the reason this is important to understand that we're flooding the type 5 LSA unaltered through our network is this helps us understand why we need the type 4.

10:10For example, in this case, this being flooded from router 2, it's going to have an advertising router ID of router 2's loopback, which, in our example, would be 10.2.2.2. That's all fine when it gets to router 1 and router 3 and router 4, router 5 even, because they're in the same area as router 2. And they would have a type 1 LSA for router 2. But what happens when that information goes into another area, such as, in our case, area 0?

10:44It gets to say router 7. Router 7 has no idea where router 2 is. And that is what we need the type 4 LSA for. Let's take a look. So again, our next type is the LSA type 4. This is called an ASBR summary. Now, this is going to be generated by the ABRs for the area, much like a type 3, actually. However, instead of advertising prefixes from one area to another, it's instead advertising the router ID of the ASBR.

11:23Remember what we said when we were talking about the type 5's. When this type 5, again, reaches, say, router 7, it's going to have on it the router ID of 10.2.2.2. The problem is router 7 literally has no idea where 10.2.2.2 is. So how could I possibly use this type 5 LSA if I don't know where the advertising router is? Because it's in a different area.

11:54And this is where the type 4 comes in. The type 4's are going to be generated by the ABRs and sent out into the area, advertising the router ID of the ASBR. This will get forwarded through the whole network. Once I receive this type 4 LSA-- and again, everybody will get it because it is flooded, just like the type 3's into the backbone and the other areas. Now, all of a sudden, router 7 knows exactly where 10.2.2.2 is.

12:28It's no longer a question. And now router 7 can use the type 5 LSA. Our next LSA type is the LSA type 7. This is NSSA external. Now, this one is going to be generated by an ASBR but specifically in a not so stubby area. So for example, let's say that area 200 up here is an NSSA. Router 10 has a loopback interface on it that it is redistributing into OSPF.

13:03This will be sent as a type 7 to get it through the NSSA. Now, once it gets to router 6, which is acting as the ABR-- remember, router 10 is acting as the ASBR in this case-- router 6, being the ABR, will then translate this and send it into the rest of the network as a typical type 5 LSA. So again, this is to advertise the prefixes from that external protocol into the NSSA itself.

13:38And this one is contained within the NSSA because it's translated to a type 5 at the first ABR. Now, I realize we haven't really gotten into OSPF area types yet. And you may not fully understand what an NSSA is at this point. And that's OK. I only bring it up here so that we've at least seen that there's something called a type 7 LSA and that we use it in an NSSA.

14:08NSSA will be covered in a future skill. And we will be jumping into it in much more detail. Now, you might have noticed as we were going through our discussion there that we actually skipped quite a few LSAs. For example, we skipped right over type 6. And that's because type 6 is used for multicast. Quite frankly, it's not a very popular implementation. And Cisco has actually never supported multicast with OSPF.

14:41We're not talking about OSPF using multicast. We're talking about multicast using OSPF. Type 8 is used for BGP interaction in the case of OSPF version 2. And in the case of OSPF version 3, these are used for link LSAs. Remember that OSPF version 3 is specifically for IPv6. As such, it has to deal with link-local addresses.

15:12Type 8's are used to carry link-local information just between directly connected neighbors. Type 9's, in the case of OSPF version 2, these are just referred to as opaque LSAs. Opaque LSA is really just a way of saying that it has no specific or specified function in the RFCs. Now, it can be used for other things. And we'll see some uses for these opaque LSAs as we move through this entire course.

15:45Now, the type 9's in the case of OSPF version 3, these are your interarea prefixes. The type 9 LSA in IPv6 actually carries information that's usually carried in a type 1 in OSPF version 2. One of the big changes that they made in OSPF between version 2 and version 3 is they actually separated the advertising of the topology from the advertising of the prefixes.

16:18So in OSPF version 2, the prefixes are advertised, of course, in a type 1, where in OSPF version 3 for IPv6, we actually separate that out into these type 9's. So the type 1's advertise the topology. The type 9's advertise the prefixes for that topology. Now, you might notice that type 10 and type 11 for both OSPF version 2 and OSPF version 3, they're all listed as opaque just because, again, they don't have a specific use according to the OSPF RFCs.

17:01In this video, we went through and we talked about all of the different OSPF LSA types, their general function on our network, and where they get flooded as far as whether they cross area boundaries, what routers generate them, and so on. So hopefully, we now have a clearer understanding of how these LSAs and the different types operate in our OSPF network. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] So now that we've looked at the different type of LSAs in more detail, now it's time to jump onto the command line, take a look at these LSAs in the database so we can see what they actually contain, and take a look at the different fields, and what they represent in our OSPF environment. So let's start by looking at our diagram. So remember what our topology looks like and what our different area types are.

0:31And then we'll jump in to the command line and take a look at that database. So for this demonstration, we'll again, be using OSPF topology 2. And just some things to keep in mind as we're going through this, area 200 is configured as an NSSA. We have router 6 acting as the ABR between area 0 and area 200. We have router 1 acting as an ABR, as well as router 3 for area 100 going into area 0.

1:03And we have router 2 who's an ASBR, redistributing the EIGRP routes into area 100. Also as a note, router 10 has a loopback interface that is also being redistributed into OSPF in the NSSA. This topology is going to allow us to look at all of our LSA types. We'll see 1 and 2 looking in area 0. We'll see type 3 LSAs coming from areas 200 and 100.

1:37We'll also see some type 5 LSAs, along with type 4 LSAs coming for the routes from router 9 and from Router 10. Then we'll take a look at our type 7 LSA in our NSSA area, area 200. So let's jump in and start looking at the different LSAs. And we'll be looking primarily at router 7. But, of course, we'll have to jump up to router 6 to look at our type 7. But let's begin on router 7.

2:08So let's start by just looking at the routing table. Just do a show ip route ospf. And what we see here is we do, in fact, have a combination of inter-area routes, intra-area routes, and external routes. Another good command to keep an eye on is show ip ospf route. This actually shows the OSPF routing table. These are the routes that OSPF has chosen as best, and is trying to put into the routing table.

2:40We can actually see here the routes that have been chosen as best, and it's trying to put into the routing table. Let's talk just for a moment about where these different components fall into the OSPF decision process. The first thing is the link state database with its entries. This, of course, is what we're going to be looking at mostly in this demonstration. The best routes from the link state database are then put into the OSPF RIB.

3:11This is the O-S-P-F RIB. And that's what this command we just looked at showed us. This is what we see with the show ip ospf route. The routes that are actually marked for entry into the routing table then get put into the global RIB. This, of course, is what we see with the show ip route. And not that it's incredibly important to this discussion. But just to wrap this up, of course, all of the entries in the global RIB then get installed into the FIB, or the Forwarding Information Base for CEF or Cisco Express Forwarding.

3:51So ultimately, this is the table used for the actual packet forwarding. So again, just as a review. If we do a show ip route, we see this table. If we do a show ip ospf route, that's when we see this table. That's the last command we just did. And, of course, for the rest of this discussion, we're going to be looking at the database. So when we do a show ip ospf database, we'll be looking at the link state database. And just for completeness, if you want to look at the FIB, on most platforms, it would just be show ip cef.

4:24But let's go ahead and take a look now in more detail at the actual database. So let's just start with the show ip ospf database. This just gives us a summary of all of the different LSA types that are currently in our database. We'll be looking at these in more detail. But this is just like a summarization. And if you actually just want a count, there's also other options here for filtering this. One of them is database summary.

4:54So it's sort of funny because the command can actually be show ip ospf database database. And what this does is just show us a counter of literally how many of each type are in the OSPF database. What we're going to do, though, is focus more on the individual types. So let's start by taking a look at the type LSA or the router LSAs. So we'll take database off of here, and we will say router. Now this first entry happens to be the entry coming from router 1.

5:27The first thing we see is the LS age. The LS age here is how long this has been in the database. We also have some options. We have no TOS capability. TOS is type of service. This is simply not supported on Cisco routers. So this will pretty much always just say no TOS capability. And then we also see DC here, which is demand circuit. It just means that this router is capable of doing demand circuits.

5:57We see the LS type is router links. That make sense, because that's what we asked to look at. We see the link state ID, which is the router ID. And the advertising router is also the router ID. These are going to be the same on type 1 LSAs. They'll be different on other types of LSAs. We also see the sequence number, which we use to ensure that the database is up to date. The checksum, of course, for error correction, the length in bytes. And we also see that router 1 is announcing itself as an ABR into the environment.

6:32Then we see that it has four links. And then it starts breaking them down for us. So we have one link that's connected to a stub network. That stub network is 10.1.1.1 with a mask of a /32. Now just based on our topology and our knowledge, we happen to know that that's its loopback interface. Our second link here is connected to another router. It's a point-to-point link. And that's connected to router 3. We also see its IP address on that interface.

7:04If we scroll down, we see that it has another connection to a stub network. Notice that it's also listing that as the link 2 router 3. These point-to-point links are listed both with a topology entry, as well as a network advertisement being a stub network. Then we have the transit network, which is the multi-access network between routers 1, 6, and 7. This is listed as the transit network. We see who the DR is. In this case, the DR is actually .7, which makes sense because it's the highest IP address.

7:39And our interface on that is .1. Now as we can see, we have other entries here from other routers, here starting with router 3. But we're not here to look at the whole database. We just want to look at the different LSAs. So next, since we know we have this transit network, let's take a look at our type 2's. So we'll take off router, and we'll put in network. So here's that type 2 LSA. Notice that it's coming from the DR. Notice the link state ID is the address of the DR, and it even tells us that.

8:13Also we see that the advertising router is in fact router 7's router ID, which make sense since he's the DR. And then notice down here it lists the subnet mask in use on that network. So the network mask, along with the link state ID would actually tell us what the network is, 50.0.167.0/24. Those two pieces of information together define the network.

8:44And then, of course, here at the very bottom, it lists all of the router IDs attached to that segment. Notice that the other fields that we didn't mention are just the same as they are in a type 1. Next up would be the type 3's. These are called summary LSAs, of course. The first thing to notice here is that the type 3 LSA has this new option on it that says upward. This is referred to as the OSPF downward bit.

9:14And I know that seems odd since it says upward. But the thing is the option being set to upward simply as a way of saying that the downward bit is not set. So we generally call this the downward bit. And we'll talk about this more when we get into MPLS. This is for MPLS loop prevention when we're dealing with duplicate PES and things like that. So we'll get more into this later. But just for now, be aware that this is where it's carried in the type 3 LSA.

9:46And if we're not dealing with MPLS and VRFs, then this is going to be set to upward, meaning again the downward bit flag is not set. So next, we see the link state ID, which in these first two examples here, notice that they're both 10.2.2.2. That's actually router 2's loopback interface, which is over in area 100. Notice that we're learning this from two different advertising routers because we have two different ABRs-- 10.1.1.1 and 10.3.3.3.

10:24The only other thing to note here is the network mask is carried down here at the bottom. So again, if we apply the network mask with the link state ID, which is the actual network being advertised, this tells us the actual network. If we scroll down to something that's a network rather than a loopback address. So for example, these entries. We have an entry here for the network 50.2.61.0. Now we can see that that's a /24. So this is telling us that, that network is available through router 6, which of course, is also an ABR.

11:01Next up, let's take a look at our type 5's. So these are going to be external. And for now, we're just going to focus here on router 9's loopback. It happens to be our first entry. So first thing to note is it again, has that upward bit or the downward bit that's not set. So listing it as upward. And then notice that once again, just like a type 3, the link state ID is the actual network being advertised. So it's 10.9.9.9. But here's the important part.

11:32The advertising router is 10.2.2.2. That is a router not in our area. We would have no idea how to get to 10.2.2.2, because we do not have a type 1 LSA for it. We'll demonstrate that in just a moment. But notice we also have the network mask here. And external type 5 LSAs do carry some extra information here. They have the metric type, which can either be a type 1 or a type 2. We'll cover that in more detail in a future skill.

12:05We also have a metric listed here, the forwarding address, which we will also cover in more detail, as well as any external route tag that may be set on this route. Now again, the problem with getting to 10.2.2.2 is if we do our show ip ospf database again, and this time we say router 10.2.2.2, notice that there's no entry. Again, 10.2.2.2 is in a different area. It's over in area 100. And we're currently in area 0. This router, router 7 would have no idea how to get to this advertising router.

12:39And this is exactly what the type 4's are going to give us. Let's take a look. It's actually ASBR summary. I usually just type ASBR. But there's the whole command for you. And notice exactly what this is telling me. Notice what the link state ID is. And we don't have to go into a whole lot of detail on these. Notice that they're almost identical to type 3's that we just talked about a moment ago. The only thing that makes these different from a type 3 is what's being advertised.

13:12The link state ID. And it even tells you in parentheses afterwards what it is. It's the AS boundary router address. Specifically, it is the router ID of the ASBR. And notice that just like with the type 3's, we're getting this information from both of our ABRs-- 10.1.1.1 and 10.3.3.3. So finally, let's look at type 7's. But as I mentioned before, we can't exactly look at them here because if we say NSSA here, we're going to have no entries.

13:47Remember that the type 7 only lives inside of the NSSA. Router 7 here is not in the NSSA. So we're going to have to jump over to a router that is in there. We'll just use router 6. So on router 6, we'll do our show ip ospf database. And we'll do the NSSA here. And we'll see that now we have a type 7 for that loopback interface on router 10, which happens to be 100.10.10.0. And as we can see by the network mask here, it's a /24.

14:21The advertising router, of course, is router 10's router ID. Notice that this is almost identical to a type 5 LSA. And it doesn't really need to be any different, because we're just using the type 7 to get this through the NSSA. We'll be covering this in more detail in a future skill when we cover OSPF area types in greater detail. But all we really need to see for right now is the fundamental difference on this LSA from a type 5, is this option here that says type 7/5 translation.

14:57It's basically the originator, in this case router 10, asking our ABR, in this case, router 6, to translate this into a type 5 LSA. And in fact, if we say show ip ospf external and filter it by self originated, notice we are, in fact, translating it. There it is. This is us generating the type 5 on behalf of the type 7.

15:27We are doing the translation. If we do a show ip ospf, and if we look at our information for area 200, notice it even says perform type 7 to 5 LSA translation. And we can see that router 6 is. Again, we'll be covering this in more detail in a future skill. But I at least wanted you to see the type 7's for now. So you can get an idea of how these work. In this video, we jumped into the command line, and really got a detailed look at each of these LSA types, what they look like, what information they contain.

16:05We even got to see how our ABR between an NSSA and a normal area, in our case, area 0, how that ABR is translating the LSA from a type 7 to a type 5. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] Congratulations on completing another skill. Now it's time for a review in the form of a quiz. Let's jump in with our first question. Which OSPF network design works best with MPLS traffic engineering?

0:32So as we look over our answers, really only two of these are sort of valid. Multi-tier sort of isn't even a thing, and never used OSPF for traffic engineering. That's certainly not correct. It's actually one of the few protocols that actually supports it. So that certainly wouldn't be correct. So which of the two multi-area or single area is going to be better? And the fact of the matter is when you do multi-area, you break the traffic engineering path, and you have to go through other methods to get it to work.

1:06So the best answer here is going to be single area, therefore making three our correct answer. Next question. Which two LSA types carry external routes in OSPF? So once again, let's go down our list. Type 1 and type 2 would both be clearly incorrect, since not only are these not external, these are LSAs for internal routes within an area.

1:42Type 3 is for internal routes between areas. So again, none of those would be correct. That would leave us with type 5's and type 7s. Remember that type 5s are external for a normal area, and type 7s are specifically for an NSSA or the not so stubby area. But both of them are for external routes, just in different area types. Therefore, our answers are number 4 and number 5 type 5 and type 7.

2:19Final question, which LSA type lists all the routers connected to a multi-access LAN segment? Now the type 1 LAS, remember, is information about the router itself, and its directly connected links. So type 1 is not about a list of routers connected to a multi access LAN segment. Type 2 sounds like a good answer, but let's just make sure we're clear on the other ones first.

2:52Type 3, this, of course, is for prefixes between areas. So that's not correct. The type 4, remember, is for ASBRs from other areas. So that's not right. And type 5 LSAs are, of course, for external routes, also not correct. So that, of course, makes type 2 our correct answer. Remember specifically that these are created by the DR on that multiaccess LAN segment. So this makes answer 2, the type 2 our correct answer.

3:27So that concludes this quiz. If you find that you were unable to answer any of these questions and want to review the information, please see the reference sources at the bottom of each question. Otherwise, congratulations on completing multi-area OSPF and LSA types. I hope this has been informative for you, and I'd like to thank you for viewing.