It's time for the exciting part of our Enhanced Interior Gateway Routing Protocol, or EIGRP, discussion, configuration. Let's setup EIGRP on our branch router and our HQ router. And let's ensure that HQ has the ability to route to the 10.1.1.0/24 network and branch, and send traffic over to 172.16.1.0/24.
So, in global configuration mode, we use the good old router command and then we specify our Dynamic Routing Protocol that we want to enable. So you may recall how you did this for OSPF. We do router OSPF and then we choose a process ID. So for EIGRP, is it exactly the same? No. It's very similar, but there are some differences. We choose EIGRP as the routing protocol name, but then the number that follows does matter. It matters to more than just the local router. If you remember OSPF, our process ID was locally significant. This does work out and is sometimes called the process ID for EIGRP. But you want to think about it as the autonomous system number, which is what it is. First and foremost, autonomous system number. Does this have to match between adjacent routers so that our "Hellos" can help us form a neighborship? So does it have to be the same?
This is a requirement to form a neighbor adjacency. When our "hello" packets are exchanged between our two routers, speaking EIGRP, they will look at that autonomous system number. It has to be a perfect match. So here, branch is going to be configured with 100 as the autonomous system number, which means HQ, when we do the configuration there, it has to be 100 or we won't form a neighbor adjacency.
We then put in the all-important network commands. And this is really one of the key things you have to know. Now I also want you to rewind back to your OSPF knowledge. OSPF, we used a network command there as well. Slightly different, had more parameters required of us including the area number. But we don't have areas for EIGRP. We don't want to think areas for EIGRP. But what did the network command do for OSPF? Because ultimately, it does the same thing for EIGRP and what is that thing that the network command does for us? It's going to enable the routing process on an interface.
Branch(config)#router eigrp 100
So the value we specify, for example 10.0.0.0, with that network command states, enable the routing process on an interface with an IP address in the 10 network.
I remember how OSPF worked. They gave us a wildcard mask and we can see a hint of that operation for EIGRP. But we can also see that we can do this without a mask of any kind. We really need a deep understanding of how this behavior works when we don't put a mask on network command. This is the tricky part. Yes, the network command behaves in two different ways depending on whether you include a wildcard mask or not. Without a wildcard mask, it's classful in nature. With a wildcard mask, it's classless in nature. Ok, we told you that EIGRP was classless. Now we're telling you that the network command is classful...?!
Yes. It goes back to the roots of when it was originally introduced. Way back in the day, it was classful, it was introduced with RIP. And as a result, it still has those roots tied to it. But for my classful perspective, when it comes to this network command, it's simply indicating that it's looking for a classful network number if we do not include a wildcard mask. So what does that really translate to? It means that you want to zero out any octets that are more than the classful space. So think class A, B, and C, you have to be thinking that way. This is not something you can avoid.
All right, so our interface on our Branch, 10.1.1.1/24 as an example. So we're saying classful, what class of address are we dealing with if that interface has an IP address of 10.1.1.1/24? I want you folks thinking about that question. What class of address is it? And the only thing you should be looking at here is the IP address. The IP address tells you the class, not the mask. The mask tells us our treatment of it, which is not what we're saying. So if you said class C, you will probably be looking at the mask. But it is the 10 aspect of that, the first octet that tells us the class every single time. So because it's a class A, we only want to put in the class A classful octets, which is just one.
So we only care about the first octets in this case, so 10, and so zero out the rest of it. So 10.0.0.0, that would be a perfect network command without a wildcard mask. What about the next one? 192.168.1.0, what class of address is that? It's class C. So how many octets do we care about when it's a class C?
Three octets. So we know that A requires one octet specified, zero out the rest. B would be two octets specified. So if we were to have some B networks like 172.16, we would put in two octets and zero out. This is something that you have to know. Here's why. If any exam asks you to configure a network command – as a boy, I would expect – you put in the wrong octets, you're not going to get scored right. This is a classic, classic type of test question. So we're stating that if we type in the real world, for example network 10.1.1.0, my router will automatically convert that to 10.0.0.0 for me, it'll do that. But on the exam, they might score me based on the fact that I typed in 10.1.1.0 and I truly don't understand the classful behavior then.
Any Cisco instructor will tell you that! Any Cisco instructor will tell you, you better get the network command entered properly as it would be amended to the running config. Because they want you to prove that you know how this works. And I think that, that's reasonable. Okay, now I want you to think about this again. Let's not lose sight of what we're doing. We are enabling the routing protocol on interfaces with this network command, which is hyper accurate. That's the way to think of it. So it looks at the local interfaces, looks at the network space you indicated, says, which interfaces locally do I have in this space? And I just scan them, turn the routing protocol on for each of those interfaces, might be just one, might be a multitude of interfaces, depends on your topology.
For the wildcard mask, what does it give us the ability to do? Simply, be creative. Just like OSPF, it's a range operator, so when you look at the bottom examples, that wildcard mask simply is telling us that enable EIGRP on those interfaces with an address from 172.16.1.0 through 172.16.1.255. So we're just shrinking down that range now. So it's not one big classful network, we're going to turn EIGRP on for those interfaces. We have shrunken it down now to specific smaller ranges in these examples.
HQ(config)#router eigrp 100
HQ(config-router)#network 172.16.1.0 0.0.0.255
HQ(config-router)#network 192.168.1.0 0.0.0.255
I want you to think about a situation where you have got a subinterface on a router that goes to a VLAN. And the subinterface in the router is routing between subnets in the router on a trunk or router on a stick configuration. Well you want to advertise that network into the rest of the autonomous system. And so, the way that you do that is you make sure to include with a network statement that subinterface. And so, you want EIGRP on that subinterface, you do a network command to make that happen. Now do we want to form neighborships of that interface? Probably not. Why is that? Well if it is going down to an end user subnet, we don't expect end users to be plugging into routers into our network, joining our autonomous system, that is in fact vulnerability. And I also don't necessarily even want the protocol to send or receive traffic for the protocol. I don't want to send "Hellos" to waste my time. I mean I am really just wasting my time. Is it a big amount of time? No. But it is still wasteful. So what if I have an interface where I want the protocol on, but I want to make sure that I disallow all neighborship and I silence the protocol on that interface. What is the command to make that happen?
Well first and foremost, we will make sure that, that interface is enabled for EIGRP utilizing the correct network command. But then, we will specify the passive-interface command. In the example above, passive-interface GigabitEthernet 0/0.
Branch(config)#router eigrp 100
Branch(config-router)#passive-interface GigabitEthernet 0/0
This ensures that the interface suppresses the ability to form neighbor adjacencies on that interface. So we are no longer sending Hello packets out that interface. As a result we have one, saving bandwidth. All right, that is not the best reason why we do this. The best reason is security. Now I won't form a rogue adjacency of Gigabit Ethernet 0/0 with a router that I am not supposed to be forming adjacency with.
Let me ask you this, if we got an update, let us say, someone was really attacking us, and they wanted to advertise through this interface so it's passive. Would they be able to advertise into a routing domain through a passive interface for that routing protocol? Would they be able to say, hey, I got this network, I got a properly formed EIGRP advertisement, would a router take it?
So my router receives that on Gigabit 0/0 right now. Hm, just think about our tables. Think about our tables, folks, the routing table. It is going to be populated from information from the topology table. The topology table gets populated because our neighbors tell us about the networks they know about. Am I forming a neighbor adjacency? What is the device outside of Gigabit 0/0 right now? That device that is telling me about that bad information, I don't have a neighbor adjacency with it. I am going to ignore whatever it is telling me, I am going to ignore it. It is not my neighbor. And I am not accepting anything in on this interface. No Hello packets. Therefore, no adjacencies. Therefore, no updates from that router.