Review of OSPF fundamentals

- [Instructor] In this video, we want to talk about some fundamental concepts surrounding OSPF. First, OSPF is an open standard. Now, we could argue that today, EIGRP is also an open standard after Cisco started opening it up to the industry back around 2010 is when they started doing that, but OSPF, it's always been an open standard and therefore it seems to be the most popular interior gateway protocol we're going to run into, especially in mixed vendor environments. And while EIGRP was a distance-vector, specifically, an advanced distance-vector routing protocol, OSPF has a link state routing protocol. Here's the difference? Think about what a vector is. A vector gives you magnitude and direction. You know how far away something is and you know in which direction you need to go to get there. So with EIGRP, we know the metric to get to a destination network, we know the next hop IP address to get to that destination network, but that's about it. We don't know how all the routers in our network are interconnected and all the link speeds between each of those routers. We don't have a map of the network. OSPF does, OSPF being link state routing protocol has a map of the network. And that map is stored in what's called a link state database. And then the OSPF router is going to run the Dijkstra algorithm on that link state database to calculate the shortest path to get to this destination network. That's exactly what's happening with your car's navigation system, or your smartphones navigation system. Those navigation systems run the Dijkstra algorithm on a map. You've got different roadways you could take to get to your destination address, what's going to assign a cost to those different roadways? The interstate might have a lower cost than a back road, that's what OSPF can do. OSPF can calculate the cost using these different paths. Now, let's consider some terminology we need to understand when we're talking about OSPF. Much like EIGRP used Hello messages to establish neighborships and to make sure the neighbor was still there, so does OSPF. OSPF also has its Hello protocol that it can use to establish neighborships and make sure the neighbor is still there. And coming up in a few moments, we're going to discuss the concept of a Designated Router and we'll talk about how the Designated Router is elected. Well, Hello messages carry information that will be used to elect that Designated Router. And when I think of OSPF, I think of working a jigsaw puzzle and when you work a jigsaw puzzle, maybe you're doing that with a couple of other people, you have pieces of the puzzle, they have pieces of the puzzle, but you can collaborate with them, and each of you provide information, you provide your puzzle pieces and you put them all together, and when you're done, you've got to a complete picture, you've got the complete puzzle. It's really very similar with OSPF. With OSPF, the puzzle pieces in this analogy are LSAs, Link State Advertisements. An LSA is a piece of information about this overall map of the topology, the link state database. And once all the routers communicate what they know and you put all that information together, then we can construct a full link state database on which we can run that Dijkstra algorithm. But here's a common mistake people make with the terminology. They think of sending an LSA packet. That's not correct. Think of an LSA, simply as information. The packet that carries that information, that's an LSU, a Link State Update. So the LSA, that's the information itself, but it's carried in an LSU packet. And sometimes you're working a puzzle and you get close to the end and you seem to be missing a piece, does anybody have this piece? And you look around and you look on the floor, maybe somebody dropped it and hopefully somebody is going to say, "Oh yeah, I found it", and they'll give you the missing piece, you plug it in and then you've got the full puzzle worked. With OSPF, we might have a router that has a missing piece to its link state database. If it does, it can request that missing piece by sending out an LSR, a Link State Request. And hopefully, one of its neighbors, it has that missing piece of information and it will be able to provide it using an LSU, a Link State Update. And we want to make sure that the sender of the LSU knows that we got it, so we will respond to the receipt of a Link State Update by sending a Link State Acknowledgement. And much like the IGRP could form a neighborship, OSPF conform neighborships, but in addition to just forming a neighborship, we can take it a step further and we can form an adjacency. And there's a distinction between a neighborship and an adjacency. First of all, if we're a neighbor, then we're on the same network link, we're on the same network segment as our neighbor, and we're going to send Hello messages back and forth to the multicast group address of 224.0.0.5. And if we're in adjacency, we take that a step further. If we're an adjacency, we are neighbors, that's where it starts. We begin as neighbors, but we go a step further. I compare this to the neighbors that I live next to. Where I live, it's in a fairly rural area and there are only two houses anywhere near our house and I've got these two neighbors. Now, one neighbor we don't know very much honestly, I probably would not recognize their face if I saw them in public, but I know what car they drive, and I can wave at them as they go by and they wave at me, we say hello, just like OSPF neighbors say hello, and that's all we do. Our other neighbor, we've exchanged information. We've been to their house, they've been to our house, we've worked on projects together, we call, we text, we've got a much tighter relationship. So we are neighbors, but beyond just being neighbors, we've exchanged the information. That's like an OSPF adjacency. An OSPF adjacency is a neighborship, but it goes beyond that and we exchange the information that's going to be used to build this link state database. But there are some requirements for two routers to become OSPF neighbors. First, they have to be in the same area. Now let's define that term. An OSPF area is a chunk of the network that we've defined. We might have 500 routers in our entire corporate network, but maybe we've grouped 100 routers into areas zero, and we've grouped another 100 routers into area one and so on. And each of those areas, they're going to have their own link state database and we're going to run the Dijkstra algorithm on that link state database for that area. And in the early days of OSPF, that was one of the reasons you would create multiple areas is to reduce the impact that the Dijkstra algorithm would have on your router's processor, if it were trying to run on a really, really large link state database. We're going to talk in a few moments about how that's not a big concern any longer, but you might see an OSPF network that is broken up into different areas. Well, to be a neighbor with another router, you've got to be in the same area. You have to have interfaces in the same area. As we're going to see, a router can have different interfaces in different areas. And if we have OSPF authentication configured, and we're going to talk about that later in this section, then obviously we've got to have matching authentication parameters. And we mentioned that you had to be on the same subnet, the same network link to establish a neighborship and your timers have to match. We're going to have hello and dead timers that we'll talk about later in this section. And even though with EIGRP, it was a good idea, it was a best practice to have matching timers, they didn't have to match. They worked a little bit differently than they do with OSPF. With OSPF, they have to match. And we're going to define some different types of areas later in this section. We're going to have beyond just a regular area. We're going to have a stub area, we'll have a totally stubby area, a not-so-stubby area, and a totally not-so-stubby area. Well, all of the router interfaces in an area, they've got to have matching stub flags, in other words, they have to agree on what kind of area they're participating in. And to be a neighbor, you've got to have a matching maximum transmission unit, a matching MTU, which defaults 1500 bytes. If you've got mismatched MTUs, you'll probably find yourself in the EXSTART/EXCHANGE state. That's a telltale sign that this neighborship that you're trying to establish and failing to do so, that neighborship has a mismatched MTU. And if we think about this difference once again, of neighbors and adjacencies, we might wonder why not just make everybody adjacencies, after all we're exchanging more information, why would I just say hello to another router when I could exchange information with that router? And the answer is scalability. In this example, we've only got six routers and they each have an interface on this subnet. If we formed an adjacency between every router, we would have a lot of adjacencies. Here's the formula. It would be n, where n is the number of routers, X n - 1, and we take that product and we divide by two. So here we just have six routers. 6 X 6 - 1, that's 6 X 5, that's 30, divide by 2, that's 15. We've got 15 adjacencies that we would have to establish. And that's only with six routers. What if I had 10 routers? That will be 10 X 9, 90 divide by 2, that's 45 adjacencies. You see how this doesn't scale well? So to address that scalability issue, what we can do is we can designate a router in this subnet as a Designated Router or a DR. And if it goes down, we want to have a backup, so we have a backup Designated Router within this subnet. And then the other routers, they only have to form adjacencies with the DR and the BDR. That's going to dramatically reduce the number of adjacencies that we have to have, especially when we have lots of routers that have interfaces on the same subnet. And we mentioned earlier that when we send Hello messages, those Hello messages are going to go to 224.0.0.5, that was for IPv4. With IPv6, we would go to the multicast group of FF02::5, and that will go to all OSPF speaking routers. However, what if I just want to communicate with the DR and the BDR? Then I would use a different multicast group. For IPv4, I would use multicast group 224.0.0.0.6, and with IPv4, I would use multicast group FF02::6 Now let's discuss, how does a DR become a DR? How does it get elected as a DR? Let's discuss the election process. The first thing to understand is we can have different OSPF router priorities and the higher router priority wins. How do we communicate our router priority with a neighbor? We send that inside of a Hello packet, and by default all of our routers have an OSPF priority of one. So it's a tie to begin with. If we want to cause a router to be elected, we can inflate its priority value. In interface configuration mode, we can say ip ospf priority, and then we give a priority value. We might do that if we have a router that's got some extra process or power available, we think it would make a good DR, and then maybe we give a slightly lower priority, but still greater than one to the router we want to be the BDR. If there's a router, though, that's really taxed as it is, you don't want it handling the responsibilities of a Dr or BDR, you don't want it to participate in the this election, then what you can do is use this command to say, I don't want to participate. You can set the priority to zero, and that will prevent the router from participating in this DR election. What if we have a tie though? We said by default, we do have a tie, everybody has a priority of one. Well, the tiebreaker is the highest OSPF router ID wins. And we can configure that router ID in OSPF router configuration mode with the command router-id and then we specify the ID, which looks like an IPv4 address, like the router ID might be 1.1.1.1 for R1 and 2.2.2.2 for R2 and so on. But if we didn't take the time to do that if we did not configure a router ID, then we take a look at the loopback interfaces on a router and the loopback interface that has the highest IP address, well, that IP address, that becomes the router ID. What if we don't have any loopback interfaces though, what happens then? Then we look at all of our interfaces that are in the upstate, in whichever interface has the highest IP address and is up, we say that that is our router ID. And that's the way we elect a DR into BDR. And we mentioned earlier that we had this concept of an area and an area was going to contain the link state database and we could take a large enterprise network and we could break that up into different areas, and then when we're running this Dijkstra algorithm, that calculation only has to be done within an area. And one of the original intents for this, as we mentioned, was to reduce the router process or burden that we might experience by running the Dijkstra algorithm on a really, really large area. So Cisco used to have a design guideline that said, if your network exceeds 50 routers, that's when you need to create another area. So if you had 60 routers, Cisco would recommend that you have two areas. However, that recommendation, that many people still look to today, that recommendation was made way back in the 1990s and it was based on the really old Cisco 2500 series router. That's a really old router with a really low powered processor by today's standards. Now we've got second and third generation ISR routers, where orders of magnitude more powerful than those older 2500 series routers. By the way, I still use the 2500 series router as an access server, that's the way I can get to the console port on my switches and routers, but I would not want to run OSPF on it in a really large network, but if you've got really powerful routers, yeah, you don't really need to stop at 50 routers. When I worked at Disney World, we had over 500 routers, we were running EIGRP, but I wouldn't have any hesitation on the modern routers of having all 500 plus routers be in the same OSPF area. Is there ever a time you want to break things up into different areas? I think so. One reason is for simplicity of troubleshooting. For example, you might have a data center and in this data center, you've got lots of different networks, so you've got lots of different rack servers and they're on lots and lots of different subnets, you might run out of VLANs, so you have to use VXLAN identifiers, there's a lot of networks that you're trying to keep track of. And while the doctor algorithm could probably handle that for a large data center combined with your enterprise network, for simplicity, I probably don't want all those data center networks showing up in my enterprise topology because I'm trying to filter out, okay, I don't pay attention to those because they're in the data center, I want to focus on these enterprise networks. By having them in different areas, it can make it easier to troubleshoot the portion of the network that you need to troubleshoot. So I might break things up if I had a data center or if I had some third party device that natively ran OSPF that I might not trust, honestly, I might have concerns that it could corrupt our OSPF link state database, I might put those third party devices that aren't really proven, I might put them in their own areas, just for safety, just for link state database stability. And here we've got three areas. We've got areas zero and if we have more than one area, we must have an area zero, and this is called a backbone area. And this backbone area must be directly adjacent to all of our other areas. Notice that area two and area one, they're connected directly to areas zero. And the routers that sit at the border of these areas, notice R3 and R7, they each have one or more interfaces in areas zero and one or more interfaces in some other area. There's a special name for routers like that, they're called ABRs, area border routers. And they have a couple of link state databases. If they're connected to two areas, there's a link state database for each area. Now that's a look at some of the fundamentals of OSPF. In our next video, let's take a closer look at the OSPF timers.