BSCI: EIGRP Configuration (cont.)
Posted by Aragoen Celtdra on July 21st, 2008
EIGRP Load Balancing
- With load balancing a router is able to route traffic over its multiple ports that have the same metric from the destination address.
- The default setting allows a maximum of 4 equal paths for balancing. Up to 16 is supported. To set the maximum path, use the router configuration command:
- maximum-paths maximum-path, where maximum-oath is the number of paths from 1-16.
- A maximum-path of 1 means load balancing is disabled
- When a packet is process-switched, load balancing over equal-cost paths occurs on a per-packet basis.
- When packets are fast-switched, load balancing over equal-cost paths is on a per-destination basis.
- Load balancing is performed only on traffic that passes through the router, and not traffic generated by the router.
Unequal-cost load balancing
- EIGRP can also balance traffic across multiple paths that have different metrics.
- IOS uses the concept of EIGRP variance to allow unequal-cost metrics to load balance.
- Use the variance multiplier router configuration command to configure.
- The multiplier value is used for load balancing. It can be any value between 1 and 128. The default value is 1, meaning equal-cost load balancing. The multiplier will define the range of metric values that are accepted for load balancing.
- Feasible Route with Variance
- A route is feasible if the next router in the path is closer to the destination than the current router and if the metric for the entire alternate path is within the variance.
- This is not always intuitive as one might think. For example, in the figure below, look at Router D. The metric (AD) to get to router A is 25. The current FD of RouterE via Router C is 20. Although Router D is only one hop away from Router A, while E->C->A are two hops, the route to Router A via Router C is still closer (20<25). Therefore, RouterD can’t be a feasible route.
- If a path is not a feasible successor, the path is not used in load balancing.
- Two feasibility conditions must be met:
- The current FD must be greater than the AD learned from the next router. In other words, the next router in the path must be closer to the destination than the current router; this prevents routing loops.
- The variance multiplied by the current FD must be greater than the metric through the next router (the alternative FD).
- To illustrate the point, consider the figure below:
- A route is feasible if the next router in the path is closer to the destination than the current router and if the metric for the entire alternate path is within the variance.
- In the figure above, router E has 3 paths to Net X:
- E->B->A: metric of 30
- E->C->A: metric of 20
- E->D->A: metric of 45
- Because the path through Router C has the best metric (FD of 20), it is chosen as the successor.
- By applying variance 2 command on RouterE, the path through router B meets the feasibility conditions.
- To revisit the criteria:
- The current FD must be greater than the AD learned from the next router. In other words, the other route must be a feasible successor to be considered for load balancing.
- In this case, RouterB is a feasible successor because the current FD of 20 is greater than the AD of router B, which is 10.
- Router D is not even considered possible option for load balancing because it doesn’t qualify as a feasible successor.
- The variance multiplied by the local best metric (the current FD) must be greater than the metric through the next router (the alternative FD).
- The FD through RouterB (30) is less than twice the FD of the successor (Router C), which is 40 (2 X 20), which meets the second criteria to be considered for load balancing.
- The FD through RouterD is 45 which is greater than twice the FD of the successor C. It doesn’t pass the the second criteria to be considered for load balancing. In fact, even if the variance is 3, which meets the second criteria for Router D (45 < 3 times the successor of 60), Router D still cannot be considered for load balancing because it still doesn’t meet the first criteria - that is, RouterD still is not a feasible successor.
- The current FD must be greater than the AD learned from the next router. In other words, the other route must be a feasible successor to be considered for load balancing.
EIGRP WAN Links
- By Default, EIGRP uses up to 50 percent of the bandwidth declared on an interface or subinterface.
- The different scenarios on which EIGRP can be implemented on NBMA links are:
- Pure Multipoint Configuration (no subinterfaces)
- Pure Point-to-Point Configuration (each VC on a separate subinterface)
- Hybrid Configuration (point-to-point and multipoint subinterfaces)
Configuring EIGRP Authentication
Router Authentication
- By default, there is no authentication required for routing protocol packets.
- Authentication can be applied for neighbor routers to limit what routers can participate in routing based on predefined passwords.
- When you configure a neighbor router authentication on a router, the router authenticates the source of each routing update packets that it receives.
- This is accomplished by the exchange of an authentication key (password) known to both the routers involved.
- EIGRP supports two forms of authentication:
- Simple Password (or Plain-text authentication) - these are not secure and totally vulnerable to attacks. The passwords are sent in plain text over the wire and anyone that know how to use a simple protocol analyzer can easily capture the data.
- MD5 Authentication - this form of authentication is more secure because it doesn’t actually send the key or password over the wire. Instead, it sends hashed keys, or message digest instead of the authenticating key itself.
- MD5 authentication is a cryptographic authentication. To set it up, a router needs a key (password) and a key ID configured. An algorithm is run on the routing protocol using the key and the key ID to generate a message digest (called a hash). The message digest is sent on the wire instead of the key. When the hash is received on the other side, a similar algorithm is run and compares the result to the received message digest. If it’s a match, then it is authenticated.
EIGRP MD5 Authentication
- To configure EIGRP MD5 authentication, you must configure an authenticating key and a key ID on both the sending and receiving routers.
- Each key has its own key ID stored locally on the router.
- Key chains allow you to manage several keys. But only one key is used at a time (whichever is activated at the time).
- If the keys are not activated they cannot be use.
- If there’s a point in time when no key is activated, neighbor authentication cannot occur and routing updates will fail.
- The software examines the key numbers from lowest to highest and uses the first valid key it sees.
Configuring MD5 Authentication
| Task |
Command |
| Step 1 EnableMD5 authentication in IP Enhanced IGRP packets. |
ip authentication mode eigrp autonomous-system md5 |
| Step 2 Enable authentication of IP Enhanced IGRP packets. | ip authentication key-chain eigrp autonomous-system key-chain |
| Step 3 Exit to global configuration mode. | exit |
| Step 4 Identify a key chain. (Match the name configured in Step 1). | key chain name-of-chain |
| Step 5 In key chain configuration mode, identify the key number. This is the key ID. | key key-id |
| Step 6 In key chain key configuration mode, identify the key string (password). | key-string text |
| Step 7 Optionally specify the time period during which the key can be received. | accept-lifetime start-time {infinite | end-time | duration seconds} |
| Step 8 Optionally specify the time period during which the key can be sent | send-lifetime start-time {infinite | end-time | duration seconds} |
- The autonomous-system is the EIGRP autonomous system number in which authentication is to be used.
- The key-chain is the name of the authentication key chain from which a key is to be obtained for that interface.
- The key key-id configures the key ID number of an authentication key on a key chain. You can use any number from 0 to 2147483647 and it does not have to be configured in order.
- The key-string command configures the alphanumeric password used to authenticate sent and received EIGRP packets. The key string can contain from 1 to 80 uppercase to lowercase alphanumeric characters, except that the first character cannot be a number.
Configuration Example

Refer to the figure above where the configuration is applied:
R1#show running-config
<output omitted>
key chain R1chain
key 1
key-string Key1Pass
accept-lifetime 04:00:00 Jan 1 2006 infinite
send-lifetime 04:00:00 Jan 1 2006 04:01:00 Jan 1 2006
key 2
key-string Key2Pass
accept-lifetime 04:00:00 Jan 1 2006 infinite
send-lifetime 04:00:00 Jan 1 2006 infinite
<output omitted>
interface FastEthernet0/0
ip address 172.16.1.1 255.255.255.0
!
interface Serial0/0/1
bandwidth 64
ip address 192.168.1.101 255.255.255.224
ip authentication mode eigrp 100 md5
ip authentication key-chain eigrp 100 R1chain
!
router eigrp 100
network 172.16.1.0 0.0.0.255
network 192.168.1.0
auto-summary
- The ip authentication mode eigrp 100 md5 enables md5 authentication on S0/0/1 interface
- The ip authentication key-chain eigrp 100 R1chain command tells the router to use the R1chain key chain
- To configure the key chains themselves:
- Enter the configuration mode for the R1 key chain by using the command key chin R1 chain.
- Identify the key number by entering the Key 1 command.
- Give the Key 1 its password using the command key-string Key1Pass, with Key1Pass as the password.
- accept-lifetime 04:00:00 Jan 1 2006 infinite
- tells the router to accept the key for use on packets received by R1 from Jan 1, 2006 starting at 4am.
- send-lifetime 04:00:00 Jan 1 2006 04:01:00 Jan 1 2006
- tells the router that sending packets is only valid for 1 minute from 4am on Jan 1, 2006 to 4:01am on the same day.
- You can specify more than one key on a key chain. In the example configuration above, Key 2 is defined with a password key2Pass using the command: key-string Key2Pass.
- accept-lifetime 04:00:00 Jan 1 2006 infinite
- tells the router that the key is acceptable for use on packets received by R1 from January 1, 2006 onward.
- send-lifetime 04:00:00 Jan 1 2006 infinite
- tells the router that it can start sending packets from 4am on Jan 1, 2006 onward.
- With the configuration above, the router will accept and attempt to verify the MD5 digest of any EIGRP packets with a key ID equal to 1 or 2. All other packets will be dropped.
- R1 will send all EIGRP packets using key 2, because key 1 is no longer valid for use when sending (remember it was configured to be valid for only 1 minute.)
MD5 Verification
Helpful commands for verifying MD5 authentication:
- show eigrp neighbors
- make sure that the neighbor table show that two router have successfully formed an EIGRP adjacency
- show ip route
- verify that network on the neighboring router has been learned via EIGRP over the right serial connection.
Troubleshooting MD5 Authentication
- Here’s an example of a successful authentication using the debug eigrp packets command:
- The sample below shows that R1 is receiving EIGRP packets with MD5 authentication (with key ID equal to 1) from R2.
R1#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
*Apr 21 16:38:51.745: EIGRP: received packet with MD5 authentication, key id = 1
*Apr 21 16:38:51.745: EIGRP: Received HELLO on Serial0/0/1 nbr 192.168.1.102
*Apr 21 16:38:51.745: AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
- The next example shows a failed MD5 authentication:
- to start off the example, Router1’s key is modified to simulate a failure. The key string (password) will be changed as follows:
- R1(config-if)#key chain R1chain
R1(config-keychain)#key 2
R1(config-keychain-key)#key-string wrongkey - Notice the results from R2 when the command debug eigrp packets is issued. Key 2 on R2 is expecting a different password from R1 that it received.
- show ip eigrp neighbors command also shows that R2 does not have any EIGRP neighbors because the adjacency with R1 is down due to mismatched authentication.
R2#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
R2#
*Apr 21 16:50:18.749: EIGRP: pkt key id = 2, authentication mismatch
*Apr 21 16:50:18.749: EIGRP: Serial0/0/1: ignored packet from 192.168.1.101, opcode = 5
(invalid authentication)
*Apr 21 16:50:18.749: EIGRP: Dropping peer, invalid authentication
*Apr 21 16:50:18.749: EIGRP: Sending HELLO on Serial0/0/1
*Apr 21 16:50:18.749: AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Apr 21 16:50:18.753: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.101
(Serial0/0/1) is down: Auth failure
R2#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
R2#
Resources:
- How Does Unequal Cost Path Load Balancing (Variance) Work in IGRP and EIGRP?
- How Does Load Balancing Work?
- Configuration Notes for the Implementation of EIGRP over Frame Relay and Low Speed Links
- Configuring EIGRP Route Authentication- Cisco IOS IP Routing Protocols Configuration Guide, Release 12.4
- IP Enhanced IGRP Route Authentication
- EIGRP Message Authentication Configuration Example
This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet, as well as following the links on the resources section of this entry.

July 22nd, 2008 at 11:07 am
Great post, perfect for reviewing. I think there’s a small typo though in the variance section:
By applying variance 2 command on RouterE, the path through router E meets the feasibility conditions.
I think you meant “router B meets the feasibility conditions.”
July 22nd, 2008 at 3:56 pm
Cool.. I’m glad you caught that. And I’m glad you can find it useful for review - exactly what I intended (i.e. for my own review and for whomever it may apply).
September 11th, 2008 at 4:53 am
[...] BSCI: EIGRP Configuration (cont.) [...]