EIGRP Neighbor Establishment and Load Balancing
Posted by jrensink78 on October 20, 2008
EIGRP is Cisco’s own proprietary routing protocol. That being said, it’s pretty much a guarantee that you’ll see it in any certification test that deals with routing. Fortunately, it’s a pretty simple protocol to set up for the most part. This article will talk about some of the topics that are more unique to EIGRP.
Neighbor Establishment
Like most modern routing protocols, EIGRP requires neighbor establishment in order for routes to be exchanged. EIGRP has its own rules for two routers to following in order to establish a neighborship. These rules are…
- Authentication process must pass
- AS numbers have to match.
- K values need to match.
- The source IP of the other router’s packets needs to be in the receiving router’s interface primary subnet.
There are a few things that don’t have to match that people sometimes think are requirements. Some of these things are…
- Hello and hold timers
- Neighboring interface subnets
Some routing protocols do require timers to match. EIGRP is not one of them. Also, in terms of timers, here is something to keep in mind. Hello timers for neighbors are locally set. Hold timers are set by the neighboring router for that neighborship.
Also, the subnets not having to match is a common detail that people don’t always know. The requirement says that the source IP of the neighbor’s packets are in the local router interface’s primary subnet. So let’s say router A’s interface has a primary IP and mask of 10.1.1.1/24 and router B’s interface has a primary IP and mask of 10.1.1.10/28. Since 10.1.1.1 is in router B’s 10.1.1.0/28 network, and 10.1.1.10 is in Router A’s 10.1.1.0/24 network, everything is good. But if we changed router B’s IP to 10.1.1.35/28, then router A’s IP of 10.1.1.1 would not be in Router B’s primary 10.1.1.32/28 subnet. So a full neighbor relationship would not be established. The other item of note here is that secondary IPs cannot be used to establish neighborships.
Load Balancing
One of the unique aspects of EIGRP over other common IGPs is unequal cost load balancing. So that will probably be a topic of note on certifications (as well as in production networks). Just to review, EIGRP does equal cost load balancing by default. Using the variance command under the EIGRP routing configuration, you can configure unequal cost load balancing. The biggest requirement here is that only the primary route and other feasible successors can participate in load balancing (to prevent the possibility of routing loops).
So what are some of the methods that can be used to manipulate load balancing? Well, the biggest ones will be controlling route metrics and how many paths will participate.
I terms of controlling route metrics, the best options are controlling the interface bandwidth, delay, and also controlling route offsets. Now controlling interface bandwidth and delay will work just fine. But it’s a little tricky. First, if you are looking to get a route metric to a specific value, it can be tough using this method. Also, changing the bandwidth of the interface can have collateral implications to other things (such as QoS).
Probably the safest method (and arguably easiest) would be to use route offsets. An offset will add a specific number to the metric of a route (or multiple routes). This will allow you to easily get a metric to a certain value. With offsets, you can add metrics on the way in or the way out. You can apply them to everything, or just specific routes using an access list, or by specifying a certain interface. Really, your only limitation is that offsets can only add to the metric, never subtract from it. So if your only option is decreasing the metric, you will need to use the bandwidth/delay manipulations.
The other aspect of load balancing that you may want to be aware of is manipulating how many paths take part in load balancing. Let’s use an example with simple metrics. Say a router has 4 paths to a given network with values of 100, 200, 250, and 300. With the default settings EIGRP will use only a single path, since it only does equal cost load balancing by default. Say you want to load balance over 2 paths. Well, that’s an easy one. Just use the “variance 2” command under the routing configuration, and you’re good to go. Now let’s say that you want to balance over 3 paths. A variance of 2 will include 2 paths, and a variance of 3 would include 4 paths. There are a couple of options here. One would be to increase the metric of the 300 path to something larger. But what if you were prohibited from doing that? Well, then you would want to use the maximum-paths command under the routing configuration. Set a “maximum-paths 3” command, and EIGRP will use the 3 lowest metric paths for load balancing. So even though the variance command includes 4 paths, maximum-paths limits it to using 3.
Richard @ Configureterminal.com said
Hi Jeff,
When using an offset list with EIGRP it actually adds to the Delay value that is inputted into the composite metric calculation. Therefore for each 1 that an offset-list adds, an extra 256 is actually added to the output of the calculation and therefore the metric. Please see http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a008012dac4.shtml#offset
Nice blog by the way, good luck with your studies.
Richard
Richard @ Configureterminal.com said
Although I have labbed this and it doesn’t seem to match-up against Cisco’s documentation – maybe something to raise as a bug?
jrensink78 said
Hi Richard,
Thanks for your comment. I checked out the document that you referenced, and thought that I should lab it up and see what happens.
I setup a simple network with 2 routers connected by a Fast Ethernet link and also setup loopbacks on each router. I added all of the interfaces into EIGRP and here is what was learned for the metrics on the loopback networks.
D 192.168.1.0/24 [90/156160] via 10.1.1.2, 00:00:05, FastEthernet0/0
Next I entered the following command under the eigrp routing config
“offset-list 0 in 1″
That will set an offset value of 1 on all routes coming in on all interfaces. Shortly after that, the router gives a notice that neighbor route config resynched. Now let’s look at the route again.
D 192.168.1.0/24 [90/156161] via 10.1.1.2, 00:01:30, FastEthernet0/0
So the route metric did only increment by 1. When the delay changes, it should get multiplied by 256 based on the EIGRP formula. Let’s check that out. I go to the Fa0/0 interface and look at it’s current delay.
FastEthernet0/0 is up, line protocol is up
Hardware is AmdFE, address is cc00.0f2c.0000 (bia cc00.0f2c.0000)
Internet address is 10.1.1.1/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
So we have a current delay of 100 usec. Since we can only set this in increments of 10usec, I’ll change it to 110 usec with the interface command “delay 11″. After the command has applied, I double-check the delay value on the interface.
MTU 1500 bytes, BW 100000 Kbit, DLY 110 usec,
OK, last thing to do is check the route metric again. Previously it was 156161.
D 192.168.1.0/24 [90/156417] via 10.1.1.2, 00:00:57, FastEthernet0/0
The metric did jump 256 (156417 – 156161 = 256). Just to be complete, I did verify the same behavior on outbound offset lists. So I guess here we have an issue where Cisco documentation doesn’t exactly jive with the reality of IOS operations. Or at least, the documentation isn’t quite clear on what it’s trying to say.
jrensink78 said
Looks like you are faster with your reply than I am =). Not sure if it’s a bug or just bad/unclear info. I think the way that it currently operates is the preferred way. It makes it much easier to manipulate the metric, since we don’t have to worry about multiplying our offsets to get the value that we want.
I haven’t seen that description in other EIGRP documentation. For instance, the Configuring EIGRP guide doesn’t talk about it modifying the delay.
Richard @ Configureterminal.com said
Yes I was probably a bit quick to call it a bug. Although my original source of information was the command reference guide:
“In the following example, the router applies an offset of 10 to the delay component of the router only to
access list 21:
offset-list 21 out 10″
You’re correct in that it’s easier to have the value added to the metric value and not a component of the formula. What worries me is if a question about this pops up in the exam – do I go for what the docs tell me or what happens in real life? I doubt it will be a problem though…