At this point, we should already know this. We configured OSPF in ICND1. I'm looking at the commands below and they all look very familiar because we saw them in ICND1. Let's go to interface configuration mode right now in R1.
ip ospf cost - what's the purpose of that? To explicitly set the cost of that particular interface. So instead of the interface cost being based on reference bandwidth divided by interface bandwidth, we explicitly set it to 10 here. Is that necessary? No. Should we really be doing that in the real world? No. Our interface has a certain speed, we have a reference bandwidth set, let's let OSPF do its job and figure out what is the most appropriate path based on that bandwidth to take. But that's just a reminder. We can do that.
R1(config-if)#ip address 10.64.0.1 255.255.255.0
R1(config-if)#ip ospf cost 10
R1(config)#router ospf 1
R1(config-router)#network 10.64.0.0 0.0.0.255 area 0
And then under router OSPF configuration mode we see a 1. Is that an autonomous system number? Is that an area number? Is that a process ID? What is that? That number is called a process ID and that number is locally significant. I want you to remember the "hello" packet. Was that included in the hello packet? No. That means it's locally significant. It's not included in anything outside that. That means it does allow me to run multiple instances of OSPF, like when you run Internet Explorer and you want to open up another tab. It's really another instance of a web browser. This is done outside of what we're doing here in this curriculum. Service providers could have multiple OSPF processes for their different customers and MPLS providers do in fact to do that.
We're not at that point. We're in a very different paradigm, one OSPF process and we want to keep it consistent. Because the chassis can support multiple processes. We don't want to accidentally get an additional one added because we set it to 100 before and now we do one. Well now, we have two and in fact they don't talk to one another unless you perform redistribution. And that is a big old mess on your hands. So keep it consistent, keep it consistent. And if you don't know this, do commands like show ip protocols to see what your existing environment is using and match that. Be consistent, don't accidentally put in another process. Now that's not the autonomous system number. That gets us into router configuration mode for OSPF and there are few commands we need to know. And this is the most important one, it's making sure that OSPF has the proper network statements.
What does the network command do for us? Everybody remembers what it does? We really drilled into this in ICND1. Let us remind you if you don't remember. The network command enables the OSPF process on an interface. How does it know which interface? Based on the address and wildcard mask we provide. So in this case, if I just read this, it says, "network 10.64.0.0 0.0.0.255." That says, "Enable OSPF on any interface that has an IP address from 10.64.0.0 through 10.64.0.255." So you enable the OSPF process on that interface and lastly, we have to put it in a specific area. And that's where the area parameter comes in. So we're putting in an area 0. Now I want you to remember that network command applies OSPF to interfaces basically. That doesn't say, "Please advertise 10.64.0 with the /24 mask." It doesn't. It says, "Let's look at some interfaces, turn it on for those, then happen to advertise whatever networks live on those as well, and also speak OSPF hello packets out of these interfaces that are enabled for it.
Now what kind of router is R1 here? Well R1 is an Area 0 therefore it's a backbone router. But it's also an internal router because it's not sitting on the edge or the border or the boundary of anything. It's completely in Area 0. So, this really is a review. Let's get to the really important discussion for multiarea OSPF.
Focus on the router OSPF configuration mode, right at the bottom.
R2(config-if)#ip address 10.64.0.2 255.255.255.0
R2(config-if)#ip address 10.2.1.2 255.255.255.0
R2(config-if)#router ospf 1
R2(config-router)#network 10.64.0.0 0.0.0.255 area 0
R2(config-router)#network 10.2.1.2 0.0.0.0 area 1
Do you see anything different from what we discussed in ICND1 or what we did on R1? Notice, we have area 0 listed as well as area 1. So I want you really looking at those last few parameters of the network statements. And I don't want you to get messed up by the wildcard mask for the second network entry. You see that 10.2.1.2 0.0.0.0, that's the wildcard mask, all zeros. What does that mean? I don't want to get messed up by that. What does that mean? Well, wildcard mask is simply a range operator. So it's specifying now that we're going to enable OSPF on any interface that has an IP address from 10.2.1.2 all the way to 10.2.1.2, so just that address. Look for an interface with that address and turn on OSPF. If I'm looking properly here, it looks like R2 has an interface with that IP address - it's Gigabit Ethernet 0/1. So let's turn OSPF on that interface and let's put that interface in Area 1 whereas the network statement right above that said, "Turn on OSPF on Gigabit Ethernet 0/0 and put it in Area 0." Two interfaces enabled for OSPF, one in Area 0 and one in Area 1. So now you can see a new kind of router. How would we classify R2? Is it an internal router? No. Is it a backbone router? Well, the configuration here has one interface in Area 0. Yes, it's a backbone router.
It's going to be generating Type 3 LSAs as a result of it also being an area border router. So you can see it, this is like straddling the fence between multiple areas you're seeing right here. I want you to remember what we did to R2. We put R2 or gave R2 an Area 1 designation for its interface going into Area 1, now specifically Gi0/1. And we had set a network statement, "Network 10.2.1.2 all zeros, area 1."
What does R3 need to do to reciprocate and agree with that? It also needs Area 1. But, do we need to match the wildcard mask also? It looks like we're getting used to matching wildcard masks. R1 matched R2's wildcard mask for their common network. Now R2 and R3 are matching their wildcard mask for their common network. Do we need to match wildcard masks? No. Wildcard masks, as we mentioned, is a range operator. It's just giving our router the ability to identify which interfaces it's going to enable OSPF on.
So no, the wildcard mask does not have to match at all. It is that network statement which is local to that device and it's telling that device which interfaces to turn OSPF on. The only thing that has to match is that area value: Area 1. To put that interface in Area 1, Gigabit 0/1, to make sure that it matches with R2's interface. Or else those "hello packets" don't agree, no neighborship.
Now we've mentioned something in here that we certainly want you to know. Are any other interfaces enabled for OSPF v2, v2 is for Internet Protocol version 4, or IPv4? Yeah, looks like we're turning it ON on Gigabit 1/0, but we did not do it with a network command. We did it at interface configuration level. IP, OSPF, process ID of one still, and we place that interface in Area 1 as well. And that would be good.
And let me ask you, could we put in area 2 on that 1/0 interface? Look at the topology - Gigabit 1/0 on R3. Could we put that in area 2 or area 51? Well, we could, but would it be proper design practices? Would communication work properly? No. None of that. So it's just because you can do it, doesn't mean it's right, doesn't mean it will work. So there is no mechanism on your router that will say well, "Wow, wow, wait, wait. I'm an internal router. I'm already in area 1. You have no choice but to make sure I'm in the same area." So just be mindful of that. But Gigabit 1/0, is it going to send "hellos" out of its interface? Is it going to try and form a neighbor adjacency, if there is another router out there in area 1?
Yeah, if you're enabled for OSPF from the interface perspective, whether that be with the network command or the ip ospf process area command at interface level, you are fully expecting to form adjacencies, you're ready, willing, that's what you're going to do. So yes. R3 would be communicating "hellos" and this seems like a security problem.
R3(config-if)#ip address 10.2.1.1 255.255.255.0
R3(config-if)#ip addre 192.168.1.1 255.255.255.0
R3(config-if)#ip ospf 1 area 1
R3(config-if)#router ospf 1
R3(config-router)#network 10.2.1.1 0.0.0.0 area 1
The best way to solve that is with the passive-interface feature that we see here in router OSPF configuration mode. passive-interface GigabitEthernet 1/0, that interface is still enabled for OSPF. But we're suppressing the ability to use that multicast address of 184.108.40.206. So now we won't form any neighbor adjacencies with anyone at that particular interface. Now that will ensure that we have enhanced security. Why? Because if I can't form a neighbor adjacency, I won't learn routes from a rogue OSPF device that was attached to the network of that particular interface. I want to make sure you guys got something here. Say you have to troubleshoot OSPF. If passive-interface had been done, let's say if somewhere on R2, the adjacent router would not be able to appear with it. passive-interface breaks neighborship. Don't let multiarea OSPF scare you. Troubleshooting it is no different than troubleshooting single area OSPF.
What are we looking for here? To make sure that we have the correct area specified, let's look at R2.
R2#show ip ospf interfaceGigabitEthernet0/0 is up, line protocol is upInternet Address 10.64.0.2/24, Area 0, Attached via Network StatementProcess ID 1, Router ID 10.64.0.2, Network Type BROADCAST, Cost: 10...GigabitEthernet0/1 is up, line protocol is upInternet Address 10.2.1.2/24, Area 1, Attached via Network StatementProcess ID 1, Router ID 10.64.0.2, Network Type BROADCAST, Cost: 10
R2#sh ip ospf neighborNeighbor ID Pri State Dead Time Address Interface10.64.0.1 1 FULL/DR 00:00:36 10.64.0.1 Ethernet0/0192.168.1.1 1 FULL/BDR 00:00:35 10.2.1.1 Ethernet0/1
Do we have the appropriate neighbors? As we mentioned before, when I'm looking at a neighbor table, what am I looking for? At first, I just want to make sure I have the correct number of lines. What do I mean? Well R2 is supposed to have two neighbors. So I should have two lines with neighbor information. R1 is a neighbor as well as R3 and I have that here. We can see the neighbor ID, that's the router ID. The priority is one by default for a multiaccess environment. And although these are point-to-point Gigabit Ethernet links, we're still going to have to have a designated router, backup designated router election. Does anybody remember what LSA type is generated by a designated router? Do you remember? That's right, Type 2 LSA. So when I'm looking at this output right now, I can see that 10.64.0.1, which is R1, is the designated router. We can see the designated router, or DR, under that state. And 10.2.1.1, well that's R3's router ID, there is the designated router for that multiaccess link. So both R1 and R3 are going to be generating Type 2 LSA.
Full, state is full. Is full good? Do we want to be full? Well, in the world of OSPF, full is "don't troubleshoot it" because it's not broken. Are there other states? Do you remember them? Down, Init, Two-way, Exstart, Exchange, Loading, Full. Two-way, you might see it again that's the two DR routers seeing each other and they're not going to make that extra effort to get to the full state.
People get confused when the address and the neighbor ID are not the same. It looks like we've simplified that for you. Almost never ever happens, because the neighbor ID is the router ID. The address happens to be the IP address of the device that you're communicating with, their IP address on that common segment. They generally don't match this consistently. Do you see any information in that neighbor table pertaining to areas? Take a good look. I don't see anything at all. So if we want to verify area information, we're going to have to look elsewhere. But here is something to realize. Will we form a neighbor adjacency if we messed up on our area configuration? No, not unless we messed up both routers' area configuration and they ended up being the exact same value. Then yeah, we'd end up forming a neighbor adjacency. But in this particular example, R2 has its neighbor adjacency with R1 and R3. So our neighbor, our area IDs, had to match in those packets. But if we want to verify at this specific interface level, what area does this interface belong to, let's look at the output of show ip ospf interface. And here we see that, we're in AVR. You can interpret that based on one interface in area 0 and another interface in area 1.
They're also identifying process ID, which is kind of a head scratcher for me, to be frank. If I do show ip protocols though, and I see multiple OSPF processes, I'm going to be pretty freaked out. So let's just say, you know wild and crazy scenario that it can't necessarily rule out. If you did see multiple processes, not good, that's a guaranteed. You're not ready for that can of worms, you don't want to be in that situation. I will say there's another thing you want to know here, that we're omitting. And that is, this is a great place to look at the hello and dead interval timers, okay? If you are looking for hello and dead interval timers which we know has to match, you would come here, you would look at that. You can also see configured statements configured commands at interface level that modify the hello and dead interval timers, but this is a more elegant place to go. And remember we talked about things like multiaccess networks, the network type broadcast is that of a multiaccess network, whereas it could be point-to-point on HDLC and PPP, and then we wouldn't have a DR. And then, in fact, the neighbor command would have a hyphen instead of the DR or BDR, or DR other, which can also be there in that place.
Multiarea OSPF verification
How can we verify which networks we're routing for? 'show ip protocol', there is a lot of information there. And in ICND1, we go through show ip protocols step-by-step but here they're just showing us, we can go here to verify which networks we're actually routing for. And when I look at the output, it looks very familiar.
R2#show ip protocols
Routing for Networks:
10.2.1.2 0.0.0.0 area 1
10.64.0.0 0.0.0.255 area 0
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 110)
They seem to just be missing the word "network" in front of them. Yes those are the network commands. And by the way if you do the interface level command, ip ospf, and then you say area, they'll also show up here because they realize those are equivalent. So even though it seems a little weird for an interface local command to show up there, that's what happens. Make sure that the values look good. If you're troubleshooting this, I would do a show ip interface brief, make sure that the ranges of the wildcard masks include the local interfaces that I'm expecting. I want to make sure that my areas match, fits Area 1 here. Does the other side match Area 1? Those are the things I'm looking for.
I usually don't troubleshoot based on routing information sources. Frankly, I don't. That's going to have other routers that we've spoken of in this protocol of OSPF with the administrative distance of 110 and when we got an update. But for me routing for networks is important.
Do you remember which LSA type will provide us with an "O IA" route? You need to. Well let's look at the codes.
R1#show ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O IA 10.2.1.0/24 [110/11] via 10.64.0.2, 00:10:30, GigabitEthernet0/0
O, all by itself is just OSPF. But OSPF what? Intra-area routes. Which LSA types generate intra-area routes? I want you folks to think about this first. Intra, within. It's going to be a Type 1 or a Type 2. It's really a conglomeration of both to get us that information. And you can't know unless you happen to know if it's a DR and we don't care about that.
Okay, so we have inter-area routes. What LSA type gave you that one? That's going to be a Type 3 generated by the ABRs right? So here's a question that I would want you to know, okay? So don't look at the topology, just look at the routing output. It is R1, is 10.2.1 inside of your area? Is this network 10.2.1.0/24 inside of your area? Don't look at the topology. Look at the line of output in the routing table. We are in R1 and O IA... That represents a network outside of our area. So 10.2.1.0, that's outside of our area. Now look at the topology. Is that true or is the routing table lying to us? I know it's true. We can see that. 10.2.1.0 is that network between R2 and R3. Then how do we get there? Next hop being R2, we use Gig0/0 on R1 to get there.
Will R2 see any OIA routes if we were to have looked at router 2? No, because it's plugged into both areas. So it's a member. A tricky question. So in regards to cost I'm seeing a cost of 11 here. Wait a second. We said, our reference bandwidth divided by our interface R1 Gig0/0. We did the math, cost of 1. We never changed the reference bandwidth and then R2's interface, never changed it. But did we change anything, earlier folks, on R1? Yeah we did, didn't we? What do we type in for GigabitEthernet0/0? Typing the command that changes the cost. We explicitly set the cost to 10. So 10 of that interface to go to R2, and then 1 of the interface of R2. So that's 11. That would be a bad thing to do in the real world. Giving gigabit the cost of 10 megabit, wouldn't be appropriate, which is what we're doing. But it's a good thing that we can see it, I suppose. Definitely we'll be able to interpret that stuff in brackets. 110 administrative distance, metric that follows is the cost. And then next hop, how long it's been in the table and the exit interface that we leave to get there.