# EIGRP Part 3: Variance lab and Wildcard Mask Lab

Unequal-Cost Load Balancing Lab (Variance Lab 1)

One simple magic word enables unequal-cost load balancing in EIGRP, and that is variance. Typing this word is the easy part – it’s the number that follows the word that we have to be careful with.

The variance command is simply a multiplier and has a default value of 1. The router will multiply the Feasible Distance of the successor by this value. Any feasible successor with a metric less than that new value will be entered into the routing table.

What we want to do is keep it to the minimum value to get what we want.

We’re going to concentrate on the loop back over on R2. We got one successor. The feasible distance (the metric) for that particular path is 2297856.(red)

We also have a feasible successor going through R3, and the metric for that one is 2300416(green). So What number when multiplied by 2297856 will give us a value greater than 2300416?  Answer: 2

So we want to set the variance to 2 :

We have the variance command here and you could see the description we get there at the bottom is control load balancing variance.

Our values are here are 1 through 128.

You really should go with the lowest number here that you can get away with, and frankly the exam might demand that you do that (instead of just saying OK variance 128!)

So we’re going to go with variance 2.

Thing is here that this is all you’re gonna see. Your adjacencies are not going to reset. You’re not going to get a message that says hey your variance has been changed! You’re just going to get a little console by console message like we do with everything.

But what we want to do of course is make sure we change it correctly (with ‘show IP protocols’)

and in the middle here is variance 2. So let me go check my routing tables.

I now have two routes to R2’s loopback on my routing table. Now please note that the metrics of the paths themselves are not changing. So when we see 2297856, we know this was our successor (red).  Here’s the feasible successor that is now in the routing table (blue) thanks to variance.

If we go into the typology table right now:

you’ll notice that for R2’s loopback, we still just have one successor.

Again we’re not changing any distances and we’re not changing any metrics. We’re actually not even changing how many successors we have. What we’re doing with variance is making it acceptable for EIGRP to put a feasible successor (one or more) into the routing table.

What side effect do we have here? The side effect we had here is that all of a sudden we have two paths to R3’s loopback as well. (previous pic)

That’s for the exact same reason. Because now we’re taking this value 2297856(yellow),

multiplying it by 2, and any feasible successor for that route that has a metric of less than the resulting value, is going to be put in the table(pink)

So considering this is going to be about 460xxxx to begin with, then we know this one(pink) obviously has a lower metric and it’s been put into the routing table.

The reason I point this out is to bring to your attention the variance is all or nothing.

You can’t just say variance 2 for a particular network! It’s all or nothing! So what you always want to do with the variance in the real world networking, is check your routing table when you’re done. DON’T just look at the one route that you’re putting variance in for! Look at the entire EIGRP table, because you might be doing some unequal cost load balancing that maybe you don’t want to do.

NOTE: We have absolutely no issue with having equal cost and unequal cost of load balancing in EIGRP running at the same time. Because that’s exactly what we have now! We have equal cost load balancing down here for 23.0/27 (green) and we have unequal cost load balancing going on for both the loopbacks(the other two). It’s a good practice exam question to maybe even a real one.

Note: in the apology table you notice that every route we’ve seen in every entry, has the letter P next to it (P for passive).

Doesn’t Active sound better than Passive? Well actually we want these entries to be passive! Hopefully you won’t see the letter A next to an entry for very long, because that means that it is actively being calculated by DUAL.  And it can’t be used to transport package and it can’t be used for routing.

Now back to the variance command, you want to be careful with that number you put in with variance because in this particular case it really didn’t bother anything if we put 128. We only had one feasible successor for each route that we were looking at. But if you have more than one feasible successor, you might bring in a path that you don’t mean to bring in.

Variance Lab 2 (Too Big)

I have added what I generously have called a “slow backup path” between R1 and R3. This one is running over the Fast Ethernet interfaces (0/1 on R3 and 0/0 on R1. But I’ve used the bandwidth command to slow it down to a slow backup path. Because we would love to say that every single link in our network is running at top speed, but it doesn’t work that way in the real world. When you need that backup path, you’re happy to have it. But you don’t necessarily want to use it first or load balance over it.

If we look at things from R1’s point of view right now, it has three different ways to get to R2’s loopback. It could go through the serial link and straight to R2, or it could go through the serial link to R3 and then through the Fast ethernet segment between R2 & R3, or it could go over our slow backup path and go down to R3 and then through the Fast Ethernet segment connecting R2 & R3.

So let’s verify that here with a look at R1 and the first thing we’ll do is look at the topology table

and you can see now that we have three entries for each loopback. we have three entries for 172.12.23.0/27 and the newcomer here is the ethernet segment between router 1 and 3 via 172.12.13.3 (red).

And you can see that the metric here is just slightly higher than the metric of both the successor and then the feasible successor. (green and yellow)

Should the serial link go down, we’re happy to have this backup path(red). It’s just that we might not want to do an unequal cost load balancing over that backup path. So that’s why we want to do just a touch of math before we enter our variance value.

Now I set the variance to 25 after we have a look at the routing table

And so what kind of load balancing are we doing here overall? Answer:  we’re doing both kinds. We’re doing equal cost with 23.0/27 and we’re doing unequal to both of the loopbacks. But you’ll also note that the new link is not in the routing table, because we set the variance to 2, and instead if we really wanted to bring that backup link in, we have to set it to at least 20. So this is why you might not want to do that.

And this is a relatively new message. We didn’t use to get though.

So if you haven’t seen it before, Forwarding Information Base message about unequal. (So we’re talking an unequal cost load balancing) and the message says “range of unequal path weightings too large for this particular prefix, some available paths may not be used.”

When you see a message like that, it’s probably telling you you’ve set variance too high, and unequal costs load balancing is not going to work as we would like it.

But let’s go ahead and run ‘show ip route EIGRP’

and you’ll note that those entries are in the table now, because we set variance so high.

But again this is why you don’t just sit down every single time and put in variance 25 because you’ll have your successor (red) and then you bring in your feasible successor(blue) and that’s great but you’re also going to bring in a route that perhaps you don’t want to bring in to load balancing.(yellow)

So if I see that message about the forwarding information base (the FIB) there, I would say let’s just take variance 25 out and let’s go back down to 2

and it’s already taken effect. And that backup path is gone.

So again we’d be happy to have that backup path if the serial link went down. But we really don’t want it to be used in this case except as a backup because it’s so much slower than the other links according to EIGRP.

The question you probably had with unequal costs load balancing is “well how is the load balance? if it’s unequal cost you can’t send about half of the data over each one.

Well it’s again going to depend on your metrics.  Here these metrics are so close that it would be pretty close to 50/50. What would happen is your successor would take a little more of the load because as the lowest metric. But again it would be very close to 50 50.  If  you had a feasible successor where the metric was twice what the successor’s was, that means the successor route would handle about two thirds of the load and the feasible successor would handle about one third.

In our topology, I have removed all previous EIGRP related configs and you can see that routers 1, 2, and 3 are all still on the 172.12.123.0/24 network. That’s in the cloud as usual.

We also have that Ethernet segment (the broadcast segment) connecting routers 2 & 3 over the 172.12.23.0/27 network.

What’s different here, is that each router has two loopbacks and you can see the numbering 1.1 & 11.1, 2.2. & 22.2, and then 3.3 & 33.3.

And what we want in this lab though is to not advertise the loopbacks. Sometimes you have networks you don’t want to advertise and that’s what using subnets and wildcard masks and EIGRP is all about, but on one of our routers we’re just going to use the network command and we’re going to leave the wildcard mask off and see what the effect is. We discussed it earlier but I really want you to see this.(we’re starting the entire config from scratch)

We’ve got our adjacency between R1 & R3 already so that’s good. That’s a good sign.

That’s interesting.

We have two adjacencies already up. So not only has R2 already gotten an adjacency with R1 which is what we were going for 123.1, the first entry (172.12.23.3) that adjacencies already up even though we did not put in network 172.12.23.0. Why did that happen?

Answer:  Anytime we leave the wildcard mask out, the ios is going to shorten your network entry and it’s going to put in the classful network for what we put in. So this is 172.12.123.0 that we just put in. It’s a Class B network. And what’s the mask there? 255.255.0.0. So what the Router is assuming that we just put in (or act like we just put in): “hey it’s network 172.12.0.0 0.0.255.255. That’s not what we put in. But that’s what the router is assuming. And I can verify by doing a quick ‘show run’, take a look at our running config, and at the bottom we’ll see this:

Check that out. We didn’t put network 172.12.0.0 in, but we left the wildcard mask off.

So the router is just going to take it as a classful entry, and put the classful network in.

You may think that wasn’t so bad that we got our adjacency with R1 and R3 with one simple entry. Well that’s true but what’s the other result going to be?

We do have our adjacencies but where else is EIGRP are going to be enabled on R2?

Well there are only two other interfaces. But since the entry is network 172.12.0.0  as far as the router is concerned, those loopbacks match that.

So they’re going to be EIGRP enabled, and now when we go to R1 & R3, I bet we see entries for those loop backs. Let’s have a look.

And there they are! Exactly what we didn’t want, because we said at the very beginning we don’t want the loopback advertised. Now you’ll notice here R1 does not see R3’s Loopbacks because we use wildcard masks on R3, and we specify the network that we did want EIGRP to be enabled on, and we did not put anything in for the loopbacks. If we go now on R3:

We’re going to see the two loo backs over on R2 (the ones we didn’t want to have advertised), but what we don’t see here on R3 is R1’s loop backs.

We don’t see those because they were not EIGRP enabled on R1, and we used wildcard mask so there was no worry about a classful entry.

So what we’re going to do to fix that, (the easiest way to do) is just take EIGRP off.

And now I’m going to put 172.12.123.0 0.0.0.255 in

One adjacency comes up… That’s what we expect to see… and then:

and we expect to see one adjacency come up. That’s exactly what we wanted and now we’ll go over to R1 and R3 and see if those loopbacks are still there

and they are gone.

The only EIGRP derived route that R1 has in its table, is the broadcast segment. That’s what we expect. We don’t want to see any loopbacks. And now that we’re using wildcard masks we don’t have our loopbacks and they’re getting cut with that classful entry.