Open Shortest Path First, or OSPF, and we're really talking OSPF version 2, doesn't say that anywhere here, but it's OSPFv2. Later we'll see OSPF version 3, or OSPFv3, which is for Internet Protocol version 6, or IPv6. So OSPFv2 developed not by Cisco but by the Internet Engineering Task Force, or IETF. Sounds pretty cool, I'll kind of show you it's not as cool as it sounds. But anyway, we form neighborships with hello packets.
Distance vector routing protocols don't do this, they keep a track of interfaces, you know, up/up and up/down, down/down. Well here's what the router does. It's got these up/up interfaces and it looks at them assuming that OSPF is running on them, it looks at those interfaces and it keeps a watchful eye, is this up/up? Good, but the moment it changes from being up/up to anything else, it's going to send a link-state advertisement, or LSA, link being the router interface, state being up or down. If it were to come back up, it would also trigger an LSA. These would flood to the area, they would flood to the area, and the devices that sit in the middle between separate areas are called area border routers, or ABRs, more on that deeper in a different discussion. The area border routers can filter those and they can also simplify the routing information that can be learned from them. Inside of our area, we piece together all of those LSAs and it runs Dijkstra's shortest path first, or SPF, algorithm to figure out the best ways of getting around our topology.
The most fundamental component of OSPF is the neighbor adjacency. If we want to learn about other destination networks utilizing OSPF, we have to form adjacencies with neighboring routers. How do we accomplish that? We accomplish it by exchanging what is known as a hello packet. How do we exchange this hello packet? Well we use a special multicast address to accomplish that. What is that multicast address we utilize?
Well when we say multicast, we've encountered this twice in the course before. Once when we were discussing Ethernet and the three different modalities for communication on Ethernet: unicast, broadcast, and multicast. Multicast is sending to a group. We saw it again when we looked at the different classes of addresses A, B, C, those are for unicast destinations. D is a multicast class, Class D for Internet Protocol version 4, or IPv4, and so where does this fall? It's the Class D range, 224 through 239 is the first octet for Class D, and 224.0.0 says this is a subnet local multicast, it's a nonroutable multicast, so it doesn't pass a router. 188.8.131.52 is one of the two multicast addresses that OSPF uses. It uses 5 and 6. You are responsible for being able to pick out of a lineup the proper address from OSPF communication of hellos, that's .5. .6 is for designated routers, or DRs. There's a hint of them on this page, but we'll see them deeper later on. Okay, so, I'm trying to form this adjacency, I'm trying to form this peering. Now wait a minute, we're using a lot of terms interchangeably. Peering, adjacency, and neighborship are three and the same, they are the same, okay.
- OSPF adjacencies
- Router ID
- Hello and dead intervals*
- Area ID*
- Router priority
- DR IP address
- BDR IP address
- Stub area flag*
So, I want to form adjacency, I speak my hellos, it's based on a periodicity determined by the media type of the interface and hopefully that adjacency works. But what's deep inside of this hello packet, if we were to get out our scalpel and dissect it with a protocol analyzer, what would be in it? Now by the way, if you're getting certified, this is a pretty important page. Knowing all the minutia here is going to help. So, what is this minutia?
Well let's rip open this hello packet and let's see the specific information we'll find inside of it. First of all, a router unique identifier, or ID. It's a 32-bit value written in dotted decimal and it is by default extrapolated from an interface IP address on the chassis, more on that later. Ultimately though it must be unique and it must be staple, and it is how we identify ourselves in the topology. Then we already have mentioned a little bit about hellos and the fact that there's a periodicity here. So there's a hello timer, and then there's a dead timer. Well that's kind of an extreme dead. It's basically, if you're thinking about it this way. How do you tell if your neighbor in your actual neighborhood, your physical neighborhood, you walk out of your door, you see your neighbors, how do you tell that they're not there anymore, and they haven't been there for a while?
Well one of the things might be to look in the driveway, are the vehicles still there, has the grass been unmowed for X amount of weeks during the summertime, in the wintertime is the driveway even being shoveled or cleared of snow? Now there is different ways to tell whether your neighbor is there or not. So you start to see that indication and there's a certain amount of time that you might pass and go, "Okay, there are on vacation" and then you would think, "They're never coming back, they're never coming back" that's really the dead interval. But I want you to read the fine print here. What's the fine print? If you were to read your credit card bill or something like that there are asterisks all over the place, they use this cross symbols too and multiple crosses okay. We have an asterisk here. What is the asterisk?
The asterisk states that it must match on neighbor. So we have to have matching intervals here. The hello interval has to match between the neighbors. So if R1 and R2 are going to form a neighbor adjacency, they have to have the exact same hello interval. By default that's ten seconds. We'll send a hello packet every ten seconds but that has to match. So if R1 is configured with ten and R2 is configured with 11, is that the same? Does that match? Not according to the math classes I attended when I was younger, so no, that doesn't match, so it has to be perfect.
The dead interval is four times the hello. So if our hello is set to 10 seconds and the dead interval will be 40 seconds by default, and if these values aren't perfect match, forget it, the neighborship will not form. The neighbors field just advertising who the neighbor's are. So R2 will notify R1 who its neighbor's are. Why? It's just the friendly way things work, but the way it works deep down in the core here is that if I see myself listed in that neighbor's field, then I know that other router considers me a neighbor, and then I can make that other router a neighbor of mine. So it's the way for us to ensure that we have that bidirectional neighborship formed between ourselves and the other router. I expect to see myself listed and they expect to see themselves listed in the neighbor field of the received hello packets. Area ID, really our focus here is on single area OSPF, meaning only one area is what we'll be focusing on. What area is that going to be?
Do you folks know? I want you thinking about that. We saw a topology earlier when we were introducing the link state routing protocol behavior. All things being equal, this is the area that we would start with. So we do not want to get creative and begin with area 51, we want to begin with area zero. It is in fact a 32-bit value, so you could even input it as a dotted decimal value but as regular human beings put it in as like a zero and that would have to match.
Now let's be clear about something. The area ID is a link by link identifier, or a subnet by subnet identifier, they are design constraints but R1 and R2, they would have to agree about the area that is common between them. R2 and R4 they would have to agree about the area that is common between them and we would have what is called an area mismatch, if one router were programmed for one area and a different router were programmed for separate area. So when we take the time to configure this we will have to specify what each interface goes to in terms of area.
Now there are three things that are all tied together here, there are three things that tie together: priority, DR and back up designated router, or BDR. So let's talk about them together, and let's talk about the challenge that they help us address. In the olden days over a decade ago, we had large layer two shared networks. We didn't have a lot of routers separating out things, so the IETF who designed OSPFv2 was really worried about too many routers peering with one another across one of these LANs, and it gets into a scalability challenge that is described by an equation N parenthetical N-1 divided by 2. That equation indicates that we grow geometrically in complexity the more devices that have to peer across a common network. So how does this come into play?
Well on an Ethernet LAN, on any multi-access network we have a designated router in control of communication, the central point of contact if you will. It's called the Designated Router, or DR. There is a backup so that if the DR goes down we go to the backup. The priority is the control mechanism that indicates who wins. By default and in fact is the highest router ID because we share the same priority value, priority value defaults to one, higher indicates that we're going to be a DR or more prioritized in terms of DR election which happens when the Ethernet LAN and neighborship forms, okay. So that's a topic for a deeper discussion on another day. Mind you, that 184.108.40.206 multicast address, the .6, just one more than this one is for the communication to the DR and the BDR okay, and then we have authentication. If we are going to protect ourselves, we've already talked about a lot of protection mechanisms, we've worried about securing administrative access. Well here, we are securing what is called the control plane. The protocols that control the device live in the control plane. Forwarding happens in the data plane. Well if someone can tell my router how to route and that's a malicious advertisement, they can steer traffic towards themselves or into the garbage can and they can do whatever that they want. So we authenticate or at least we can authenticate our routing protocol neighborships to make sure that we don't have a rogue router attached to us, join the autonomous system AS and give us malicious data, and of course if we're authenticating we would make or break neighborship based on successful authentication, which is why we have the asterisk okay.
Now we began this discussion saying how important this discussion was, and let's not lose sight of that if you're looking to move deeper into Cisco certification.
So this was an in-depth look of that hello packet, but here is a question and that question is related to IP addressing. Do we have to be on the same subnet in order to form a neighbor adjacency? So for example R2 and R4, do they have to be on the same subnet on that link before we even can do anything with this hello packet?
Oh yeah, oh yeah. Now that's how OSPF v2 works for IPv4. We say these things because we know what's coming also, we know what's down the road. It's down the road as when we get into OSPF v3 for IPv6, that determine that requirement, that dependency goes away, and IPv6's version of OSPF, they can be on different subnets which is weird and wacky. I prefer it to work like this where we're going to get a syslog message indicating, hey, OSPF can't form a neighborship because we are not on a common sub network. So that is definitely another one that would have an asterisk where it listed on this page.