7. 11.6 EIGRP
In this video, we’re going to consider the EIGRP, a routing protocol where EIGRP stands for enhanced Interior Gateway routing protocol. And personally, I’m a huge fan of EIGRP because that is the only routing protocol we used within Walt Disney World when I was a network designer there. And in this video, we’re going to take a look at the theory behind EIGRP operation. But first, let’s consider some characteristics of EIGRP. It has very fast convergence, similar to OSPF. If we have a link failure and we need to reroute around that link failure, hopefully we can do that in maybe two or 3 seconds, much like OSPF. Rip, however, might take a while. It might take 90 seconds. It is scalable, meaning that we can have lots and lots of routers.
Rip had that 15 routerhop limit. Not so with EIGRP. We can have very large networks. In fact, I mentioned that we use this when I worked at Walt Disney World in Florida. We had over 500 routers in the Disney World network, all of them running EIGRP. So this is a very scalable protocol and a feature that’s somewhat unique to EIGRP that we don’t see with our other writing protocols. If we have two ways of getting to a network, we would normally choose the best way, the way with the least metric, or the least cost. However, EIGRP can be configured to load balance across multiple links, even though they have a different cost or a different metric. This is going to allow a link to be used somewhat instead of just standing by waiting for the main link to fail.
We can actually be using a lower speed link. And EIGRP is smart about the way it does that. It’s going to send proportionally a smaller amount of traffic over that slower link, but still, it’s getting some use rather than just sitting dormant waiting for the primary link to fail. And like OSPF, and even like Rip version two, EIGRP can support variable length subnet masks, so we don’t have to advertise just classful networks. That was the limitation of Rip version one, and we’re not going to broadcast like Rip version one did. We’re going to send out a multicast to communicate information between our routers. And for IP version four, that multicast address is 224 00:10, and for IPV six, it’s FF two A.
Remember an A in Hex, that’s a ten in decimal, so ending in an A for the IPV six multicast address, that’s because we’re ending in a ten for the IPV four multicast address. And for a long time, EIGRP was a Cisco proprietary protocol, meaning that you had to be running Cisco gear to use it. And at Walt Disney World, we were an old Cisco shop. However, around 2010, Cisco began to open up their EIGRP protocol, allowing some other vendors to use it, and they opened it up a bit more later on. But my view on that is that most of the other vendors didn’t really take Cisco up on that offer very much. It’s like they said, no, we’re good. Thanks anyway. There has been, from my experience, very little implementation of EI GRP on non Cisco routers.
Now, I know a few that have done EI GRP, but it’s sort of a subset of EIGRP. It’s just enough to help you migrate away from EIGRP to something like OSPF. And we know with OSPF, the cost is going to be calculated purely based on bandwidth. Let’s see how EIGRP determines its metric. Its metric does consider bandwidth by default, but it can consider lots of other things as well. It can consider not just bandwidth, and when we say bandwidth, we’re talking about the link speed that has the least bandwidth between the source and the destination. This is the weakest link that represents the bandwidth for this calculation. We also can consider delay, and delay is cumulative. There is a bit of delay added every time we exit a router interface.
And if we have to go through five router interfaces to get to our destination each time we exit an interface, that’s going to add a little bit of delay. How reliable is this link? Based on how many packets we’re dropping, this is typically written as a fraction over 255. If we’re 100% reliable, which is what we hope we are, the reliability is 255 because it’s that value over a denominator of 255. So 255 divided by 255. Yeah, that’s 100% reliable. We can also consider the load. That’s how saturated a link is. That’s also a fraction with 255 as the denominator. And if we have a minimally loaded link, the value is going to be a one one over 255. That’s a minimal load. And if we had a tie after doing all this, the original intent of the EIGRP designers was to look at the maximum transmission unit size or the MTU size and go with the path that had the highest MTU.
But the formula itself does not consider the MTU, and the formula is very convoluted as compared to something like OSPF. Here is that formula, Eigrp’s metric is determined by and I’m not going to read it off because it is so convoluted, but you’ll notice there are these constants as part of this formula, k values. And here are the default K values that we have, and most of them are zero. So if you go in and start plugging in these zeros for the K values, it comes down to just bandwidth and delay that we’re considering by default. And I mentioned that the bandwidth was going to consider the slowest link speed. The way you actually calculate that is you say ten to the power of seven divided by that link speed, and you might be looking at this formula and the default key values and think, if k five is zero, doesn’t that make everything zero? Yeah, this formula is not perfect.
There’s an exception that says if k five equals zero, then consider k five divided by k four plus reliability. Consider that just to be one don’t really make k 50. But other than that, this is how the formula works. And it’s only going to be using bandwidth and delay by default because everything else zeros out with these default key values. This reminds me of when I was interviewing down at Walt Disney World. They asked me what does EIGRP use in its metric calculation by default? And I missed the question. I thought I’ve got this because I knew a memory aid for bandwidth delay, reliability, load and MTU. I remember the Acrostic, Big dogs really like me. Where the BNB reminds me of the B and bandwidth, the D and Dogs reminds me of the D and delay and so on.
Big dogs really like me. So I rattled off bandwidth, delay, reliability, load, MTU and they said, no, you’re wrong. And the reason I was wrong is they asked me what was used by default. By default it’s only banned within delay. And now that we see how EIGRP calculates its metric, let’s dig into the path selection based on those metrics. Here router. R Three wants to get to the network on the left of ten one 100:24. There are two ways of getting there. It could go to an XTOP of R One, or it could go to a next top of R Two. And the metric for R One to get to this network, it’s directly attached.
But still that’s going to include a calculation that’s going to give us a metric. Its cost is 1000 and R One is going to report that cost up to R Three. R One says to R three I’m reporting that my distance from this network is 1000. That’s my Rd, that’s my reported distance. But it’s going to cost something for R Three to get back to R One. And in this case we’ve got a slower wand link and the cost is 10,000 just for that link. So R Three has to add that cost to get to R One to the cost that R One reported. R One reported a distance of 1000. But R Three needs to add on the cost to get to R One. That total of 10,000 plus 1000, that’s called the feasible distance or the FD. Let’s do the same thing for R Two. R Two is also 1000 away from our network and we’re going to put that in our table as the reported distance from R Two. But it’s going to take 5000 to get to R Two.
Let’s add 5001 thousand for a total of 6000. That’s our feasible distance. Well, R Three is going to compare these feasible distances and it’s going to say I’m going to go with the lowest one. That’s going to be what is called my successor route. The successor route is going to go to the neighbor for which I’ve calculated the lowest feasible distance. But one of the reasons that Eiger a peak can fail over so quickly in the event of a network failure is that it has this other route, VR One, on standby. It’s called a feasible successor. So if R Two were to go down in just a matter of about a couple of seconds, EIGRP could fail over to that feasible successor. However, just because there is another path to that network doesn’t necessarily mean that we’re going to be able to have a feasible successor using that path. Here’s what I mean. There is something in EIGRP called the feasibility condition.
It reads like this, and I’ll break it down for you after I give you the formal definition. But it reads like this an EIGRP route is a feasible successor route. And that means it’s a backup path that we can fail over to almost immediately. That’s a feasible successor route. It’s a feasible successor route if the reported distance from our neighbor in other words, our neighbor is saying I’m 5000 away from this network if it’s less than the feasible distance of the successor route. Let me show you what that’s all about. Here’s the condition that we’re trying to prevent. We want to prevent a condition where R One is trying to get to ten 1124 and it gets an advertisement from R Two and R Three and R four. And they all say, I can get you there. But what if R Three were to go down? Do you see that R Four is dependent on R three? If R Three goes down, R Four is not going to get you there.
So to make sure that we’re not pointing to a feasible successor that is dependent on our successor route, we implement this feasibility condition. It’s not a perfect solution, though. Let me give you an example here. We can see that R two, R three, R four, they are all perfectly legitimate ways of getting R One over to ten one 100:24. However, one of these, it’s going to fail the feasibility condition. First, let’s consider each neighbor one at a time. We’re trying to get to ten one dot one dot zero. R Five is a thousand away and R Two is 5000 away from R five. So 5000 plus 1000, that’s 6000. R Two is going to report to R One. I’m 6000 away. It’s going to cost me 10,000 to get to R Two. So 10,000 plus 6000, that’s our feasible distance of 16,000.
Let’s take a look at our three. R Three is 10,000 plus 1000. It’s 11,000 away from our network. It costs me 7000 to get to R three. 7000 plus 11,000, that’s 18,000 as the feasible distance via R three. What about R? Four? R four? We’ve got a slow wand link there, don’t we? 17,000 as a cost between R Four and R five and then the thousand to get out of our five. So R Four is going to report to me that it is 18,000 away, and it’s going to cost me 4000 just to get there. So my feasible distance is going to be 18,000 plus 4000, for a grand total of 22,000. Who is my successor route? In other words, my preferred path. It’s going to be my neighbor with the lowest feasible distance, which is clearly R Two.
But is R Three and or R Four a feasible successor, a backup path that we could fail over to almost immediately? Well, remember, the feasibility condition says that the reported distance from that neighbor must be less than not equal to it must be less than the feasible distance of our successor route. What is the feasible distance of our successor route? In other words, the route via R Two, we see it here on the table. It’s 16,000. So the reported distance from a neighbor that can be a feasible successor, its reported distance has to be less than 16,000 is 11,000 that R Three is reporting, is that less than the feasible distance of 16,000 via R Two? Yeah, 11,000 is less than 16,000. So R three is a feasible successor. Here’s the issue, though. What about R Four? R Four’s reported distance is 18,000.
Is that less than 16,000? No, it’s not. So R Four, even though we can look at this topology and we can realize that it’s not dependent on R Three or R Two, it’s a valid path to get us to the destination network. But it fails the feasibility condition because unlike OSPF, which has a map of the network, EIGRP doesn’t see what we see. It doesn’t know how all of these routers are interconnected. So it’s going to say, I don’t trust R Four. Now, that’s not to say that we would never use R Four. We’re just not going to fail over to it within just a couple of seconds. If R two and R three did fail, we could still use R Four. Here’s what happens r One is going to say, I have no way to get to that network.
There is no feasible successor. Let me search out and see if I can find one. So R One is going to send out a query message throughout the network, and R Four is going to get that, and R Four is going to report back, yeah, I can get you there. So even in the current state of maybe R Two and R Three both being down, if R Four reports back with a query response saying, yeah, I’ll get you there, r One says, okay, get me there. But that was a route that was discovered after the fact. We didn’t have it on hot standby to take over as soon as R Two or R Three went down because it failed the feasibility condition. And that’s a look at Enhanced Interior Gateway Routing Protocol, or EIGRP.
8. 11.7 BGP
In this video, we’re going to discuss the theory of the Border Gateway protocol, or BGP. This is the protocol that runs the Internet. It’s not something that will typically run inside of an organization. It’s something that goes between different organizations. We say that a network under a single administrative control is an autonomous system. So your company might be an autonomous system. Maybe it connects out to a couple of Internet service providers. They’re each autonomous systems, and it’s BGP that can communicate between those autonomous systems. And because the BGP works between autonomous systems, it’s called an exterior gateway protocol as opposed to an interior gateway protocol such as OSPF or EIGRP.
However, to be thorough, there is a way to do BGP as an IGP, you can run internal BGP, but here we’re talking about EBGP external BGP that’s running between autonomous systems and routers running BGP between autonomous systems. They can form neighborships similar to OSPF and EIGRP. However, something that’s different BGP is typically not going to discover its neighbor. BGP needs to be statically configured with the IP address of its neighbor. We’re not just saying, hey, are there any other BGP speaking routers out there? No, we’re talking directly to an IP address that we know is a BGP speaking router, and we set up a TCP session between ourselves and that other router in that other autonomous system, and we’re going to be advertising networks much like any routing protocol would. However, the terminology is a bit different with BGP. Instead of saying we advertise networks, we advertise something called NLRI Network Layer Reachability Information, which is a network address made up of the address prefix and the prefix length, how many bits are in that address prefix. And unlike OSPF or EIGRP or Rip, BGP does not have a single metric that we look to to say, oh, the lowest value of this is what we’re going to use to determine the best path.
Instead, there is a collection of path attributes that BGP can use for path selection. And if one pair of path attributes are a tie, we can go to the next set of path attributes and on and on. And while Rip is a distance vector routing protocol and EIGRP is an advanced distance vector routing protocol and OSPF is a link state routing protocol, I put BGP in the category of a path vector routing protocol vector meaning we know which direction to go to get to this network. We know the next top address, but we don’t have a link state database, we don’t know how everything is interconnected.
And the path component of path vector means that when we look at our BGP table inside of our router, we can actually see the path, we can see the autonomous systems that we have to transit to get to our destination network. However, here’s a word of caution. Even though I contend that BGP is a path vector routing protocol, for some reason the network plus exam blueprint identifies BGP as a hybrid protocol. In my opinion, it’s not. Hybrid implies that we have characteristics of link state and distance vector. I see no characteristics of link state with BGP. But if you’re asked on the exam which of the following is a hybrid writing protocol, you should probably say it’s BGP. And I mentioned those path attributes in this theory video.
We’re not going to dive into all those. I just want to give you a sense for what I mean by path attributes. Here is a list of them and a memory aid that I often give my students when we get into the configuration of BGP is the Acrostic. We love oranges as oranges mean pure refreshment the W and we reminds me of the W in weight. That’s a path attribute that we can set to influence our routers outbound path selection. Maybe we’ve got a router at our site we connect out to two different ISPs. We can play with the weight to influence which path we take to get out to the Internet because BGP pays no attention at all to things like bandwidth or delay. And there’s something somewhat similar to Weight called local preference.
It can also be used for outbound path selection and in a lot of cases when we haven’t messed with the weight or the local preference or anything else, the tie breaker is the autonomous system path length the fewest number of autonomous systems in that path, that’s the path that’s going to be chosen. If that’s a tie, I often see the router ID acting as the tiebreaker. We’re the lowest router ID and that’s the router ID of our neighbor. That’s what’s chosen as the best path. And I mentioned that BGP is the protocol that runs the internet and the number of routes contained in a full BGP routing table that has grown dramatically over the years.
When I first started out with BGP back in the late 1990s, there were about 65,000 networks on the internet. But at the time of this recording, that is quickly approaching 900,000 networks on the internet. And that’s look at the theory of the Border Gateway Protocol or BGP.
9. 11.8 Subinterfaces
In this video we want to consider the concept of a subinterface. A subinterface is a logical interface that’s a part of a physical interface. Let me give you an example. When we talked about VLANs, you might remember the discussion that we could take the ports on a switch and logically divide them up into different VLANs virtual Lans, also known as a subnet or a broadcast domain. We’ve got a sales VLAN number ten and it contains the subnet of 170, 216, 100:24. We’ve got an engineering of VLAN VLAN 20. Its IP address space is 192 168. Let’s say that we’ve got laptops connecting to each of our VLANs and we want to talk from the laptop in the sales VLAN to the laptop over in the engineering VLAN. How do we do that? Well, if this is a layer to switch, that means it is not able to do routing.
We have to route to go from one subnet to another subnet. So we need to introduce a router to the mix and this router is going to connect into this layer to switch via a trunk. Now, recall that a trunk is a very unique kind of connection because it allows traffic for multiple VLANs to flow over that connection. In this case, VLANs ten and 20 can both flow over that trunk. So here’s the way the packet flow works. We’re going to send a packet from the laptop into sales VLAN up to the switch.
It goes down to the router and gets routed back to the laptop into engineering VLAN. So how did that happen? How did we go in on a single port on that router and come back out of that single port? What VLAN does it belong to? Well, it belongs to both VLANs. How do we assign IP addresses in both VLANs to a single interface? Well, we divide that interface up into sub interfaces. So let’s zoom in on that interface where our trunk is connected. That’s interface gigabit zero two. However, we can go into that interface and we can logically define some sub interfaces. For example, we could say I want to define gigabit zero two one and I’ll give it an IP address in VLAN ten.
We’ll say it’s 170 216 one one and I’ll create another subinterface gig zero two two. As an example, it’s going to have an IP address of 192 168 one one. And that’s the magic behind the scenes. Traffic is coming in over one of those logical subinterfaces and the router is then routing the traffic back out another one of those logical sub interfaces. The router is treating those like separate interfaces and separate IP address spaces and that allows us to, as an example, support this ROAS topology we’ve just seen, which stands for a router on a stick. We’ve got that router sort of connected with one connection into that layer two switch and it routes using subinterfaces.