Enhanced Interior Gateway Routing Protocol (EIGRP)

Here is the next installment of my CCIE studies, the Cisco proprietary EIGRP. I know a fair bit about EIGRP but there are still bits I tend to forget so here goes at trying to condense EIGRP into a single blog posting!

For detailed information please refer to the Cisco documentation on EIGRP here

Key Points

Uses IP protocol 88
Uses Reliable Transport Protocol (RTP) for reliable exchanging of data (does not use UDP or TCP)
Default metric is bandwidth and delay
Normally multicasts hellos and updates to 224.0.0.10
Uses Diffusing Update Algorithm (DUAL) in order to find best routes
Best routes are called Successors
Supports Feasible Successors which are back-up routes to a Successor route
Sends full updates with new neighbours and partial updates thereafter
Supports MD5 authentication only
Auto-summarisation on by default
Supports VLSM by turning off auto-summarisation
Manual summarisation supported anywhere in the EIGRP network
Routes redistributed into EIGRP can be tagged
Different next-hop router can be defined
Multiprotocol - it can support IPX and AppleTalk by use of PDMs

Timers

Hello Timer - The Hello interval is the rate at which EIGRP sends hello packets. The command ip hello-interval eigrp can be used to set the Hello interval time manually. The Hello interval defaults to 5 seconds for high-speed networks and 60 seconds for low-speed networks (i.e. less than 1.544Mbps).

Hold Timer - This is the amount of time that a router will consider a neighbor alive without receiving hello packets. The hold time is typically three times the hello interval. You can adjust the hold time with the ip hold-time eigrp command.

Unlike OSPF changing the hello timer does not automatically adjust the hold down timer.

Active Timer - This timer controls the time the router waits after sending a query before declaring the route stuck in active (SIA) and resetting the neighbor relationship. To avoid this neighbor resetting you can temporary increase the active timer until you solve the problem by eliminating the cause. The timers active-time [time-in-minutes] command under the EIGRP process can be used to adjust the active timer or be completely disabled by issuing the timers active-time disabled command. The default is 3 minutes.

There are some interesting points to be aware of with EIGRP timers:

1. The Hello mechanism works independently in each direction. Hellos from router R1 to router R2 do not necessarily have to use the same parameters as Hellos from R2 to R1.

2. The Hold timer is transmitted to the neighbor in the hello packet. R2 does not use its locally configured hold-time, but uses the value that R1 tells it to use.

This second point warrants an explanation. Let's say R1 has a Hello timer of 3 seconds and Hold timer of 10 seconds and R2 has a Hello timer of 20 seconds and a Hold Timer of 90 seconds (these figures are completely arbitrary and in no way would I recommend you use these figures).

Instinct would tell us that R1 may see R2 up initially but as R2's Hellos are longer than R1's Hold timer (20 seconds versus 10 seconds), R1 would believe that R2 is down. However, what point 2 says is that R1 will ignore its locally configured timers and use those advertised by R2 for the neighbour relationship with R2. Hence, R2 would only appear down to R1 if R1 does not receive a Hello from R2 within 90 seconds.

This leads us nicely on to how EIGRP neighbours are formed.

Forming a neighbour relationship

There are 4 things that potential EIGRP neighbours must agree on before they can be confirmed as neighbours:

1. Authentication password must match assuming authentication is used
2. The autonomous system (AS) number must match
3. K values must match
4. Source IP address of a received Hello must be in the same subnet as the primary IP address configured on the interface that received the Hello.

Note that timers do not need to match like other protocols!

Point 4 may need explaining but it is pretty straightforward. What is says is that EIGRP neighbours will not form on secondary IP addresses. Let's take a look at an example:

R1 and R2 are connected on their fa0/0 interfaces. R1 has the following configuration on its fa0/0 interface:

#R1
int fa0/0
 ip address 192.168.1.1 255.255.255.0

R1 will expect the source address of a received Hello on fa0/0 to be in the 192.168.1.0/24 subnet. Let's say R2 is figured like this:

#R2
int fa0/0
 ip address 192.168.2.1 255.255.255.0
 ip address 192.168.1.2 255.255.255.0 secondary

The neighbour relationship will not form as R2 will source its Hellos from its primary IP address and that is not in the same subnet as R1's primary subnet on fa0/0.

Another thing to bear in mind is that the subnet masks do not have to match in order for the neighbour relationship to be formed. Taking the same example as above with R1 and R2 let's configure them with different subnet masks:

#R1
int fa0/0
 ip address 192.168.1.1 255.255.255.0

#R2
int fa0/0
 ip address 192.168.1.2 255.255.255.128

R1 will be expecting a received Hello to be sourced from an IP address in its primary subnet configured on fa0/0. Therefore it will expect an address in the range of 192.168.1.2 to 192.168.1.254. On R2 the IP address is indeed within that range and hence the neighbour relationship forms.

The other 3 factors that must pass in order for a neighbour relationship to be formed are covered in more detail in other sections within this post.

Metrics - K values

EIGRP uses a composite metric in order to calculate the cost to reach a subnet. By default it uses Path Bandwidth Value and Cumulative Interface Delay to give it its fancy name. They are more generally referred to as Bandwidth and Delay. There are five options in all with the other three being Reliability, Load, and Maximum Transmission Unit (MTU).

To set the EIGRP metrics you issue the metric weights tos k1 k2 k3 k4 k5 command under the EIGRP process. It's worth noting what each K value refers to:

k1 = Bandwidth (measured in kbps. Smallest/slowest bandwidth between the source and destination)
k2 = Load
k3 = Delay (Cumulative. Measured in 10s of microseconds AND DON'T YOU FORGET IT!)
k4 = Reliability
k5 = MTU

Each value is either switched on (binary 1) or off (binary 0). Therefore the K values usually look like 10100. How I remember this is by saying that 10100 has a value of 20 in binary.

Let's say I just want to use bandwidth as my metric. I would have to issue the following (assuming EIGRP uses AS 100).

router eigrp 100
 metric weights 0 1 0 0 0 0

Assuming we go back to the default settings of using bandwidth and delay the calculation of a metric is achieved by using the following formula:

Metric = 256(10⁷/bandwidth) + 256(delay)

Let's use an example to show how this works by assuming routers R1 and R2 are connected together using a T1 connection. R1 also has a LAN connection at 100Mbps.

R1:

LAN interface delay = 100. As this is in 10s of microseconds a delay of 100 is 1000 microseconds which is 1 millisecond (1ms).
LAN interface bandwidth = 10000. Bandwidth is in kbps so 100Mbps is 10000kbps

Putting those values in the above formula gives us a metric of 281600.

256(10⁷/10000) + 256(100)

R2 will therefore receive this metric. R2 now has to calculate its metric based on the received metric. R2 receives the metric on its T1 interface hence the bandwidth used in the calculation will be 1544kbps. Now comes the bit that most people tend to miss. remember that fancy name given to Delay? That's right, Cumulative Interface Delay. Let's say R2 has a delay of 1000 (i.e. 10ms). The Delay used in R2s metric calculation will be the 1000 local delay PLUS the delay upstream which in this case is the delay of 100 on R1. Hence, the delay on R2 will be 1100.

The metric on R2 would therefore be:

256(10⁷/1544) + 256(1100) = 1939631

The word "cumulative" in Cumulative Interface Delay just refers to the addition of the upstream delay to the local delay.

EIGRP Packets

Hello - Identifies neighbours, exchanges parameters, and is sent periodically as akeepalive function (every 5 seconds on interfaces above 1544kbps, every 60 seconds for speeds of 1544kbps and below). Sent to multicast address 224.0.0.10.

Update - Sent as a multicast initially. If no acknowledgement received from specific neighbour then sent as unicast to that neighbour. Initially, full updates are sent, including all routes except those omitted due to split horizon. Once all routes have been exchanged, updates cease. Future partial updates occur when one or more routes change. If neighbours fail and recover, or new neighbour adjacencies are formed, full updates are sent.

Ack - Acknowledges Update, Query, and Response packets.

Query - Asks neighbouring routers to verify their route to a particular subnet. Reliable multicast.

Reply - Sent by neighbours in reply to a Query packet. Reliable unicast.

Goodbye - Used by a router to notify its neighbours when the router is gracefully shutting down due to removal of EIGRP process or the removal of a network statement under the routing process (e.g. no network 10.0.0.0). This is actually sent in a Hello packet with all K values set to 255.

EIGRP Updates

Once routers are adjacent, they can exchange routes using EIGRP Update messages. The process follows this general sequence:

1. Initially, full updates are sent, including all routes except those omitted due to split horizon.
2. Once all routes have been exchanged, updates cease.
3. Future partial updates occur when one or more routes change.
4. If neighbours fail and recover, or new neighbour adjacencies are formed, full updates are sent.

EIGRP uses the Reliable Transport Protocol (RTP - not to be confused with Real Time Protocol) to send the multicast EIGRP updates. EIGRP sends updates, waiting on a unicast ACK message from each recipient. RTP allows the Update packet to be sent as a multicast. If any neighbours fail to acknowledge receipt of the Update packet, RTP sends a unicast Update to those neighbours.

Let's look at an example where R1 sends an update and R2 fails to respond:

1. R1 starts a Retransmission Timout (RTO) timer for each neighbour when it sends a reliable messgae like an Update packet. Cisco IOS actually calculates a Smoothed Round-Trip Time (SRTT) to each neighbour from which the RTO is derived. These values can vary over time.
2. R1 sends a multicast Update packet
3. R1 notes which neighbour it receives an ACK packet from
4. RTO expires before R2 responds with an ACK packet
5. R1 resends the Update packet, this time as a unicast, to R2.

EIGRP and RTP use a simple acknowledgement process with a window size of one message. Each Update packet has a sequence number, with the returned ACK packet confirming receipt of the Update by listing the same sequence number.

RTO, SRTT, and Sequence Number can all be viewed using the show ip eigrp neighbor command.

Basic Configuration
EIGRP uses a concept of an autonomous system (AS) which defines an area covered by a routing protocol and if you want to form a neighbour relationship with another router you have to be in the same AS. Back in the days of yore you had to advertise the classful network so if you wanted to advertise 10.1.2.0 you only needed to specify 10.0.0.0 in the network command.

conf t
router eigrp 100
 network 10.0.0.0
 no auto-summary <--turn off automatic summarisation (I do this as a matter of course)

What does the network command tell the router to do? In EIGRP it tells the router to do two things:

1. Advertise all networks that form part of the subnet specified
2. It tells the router to try and form an EIGRP neighbour relationship on the interfaces with IP addresses in that configured subnet.

What happens if we only want one interface in the 10.0.0.0 network to try and form a relationship? We could certainly use the passive-interface command (covered in more detail later) but even better we can now specify a wildcard mask in our network statement to match particular interfaces. Let's say I have two interfaces in the 10.0.0.0/8 network and only want to form a neighbour relationship on fa0/0:

int fa0/0
 ip address 10.1.0.1 255.255.255.0
int fa0/1
 ip address 10.1.1.1 255.255.255.0

With the original behaviour of EIGRP we would have to do the following:

router eigrp 100
 network 10.0.0.0
 passive-interface fa0/1

Instead, just like OSPF, we can specify a wildcard mask:

router eigrp 100
 network 10.1.0.0 0.0.0.255

Or if we really want to just exactly that interface's IP address only:

router eigrp 100
 network 10.1.0.1 0.0.0.0

Choosing the best route

There are a few terms that one should know when it comes to calculating the best route to a particular subnet.

Reported Distance (RD) - The metric received from a neighbour about a particular subnet
Advertised Distance (AD) - The metric advertised by a router about a particular subnet
Feasible Distance (FD) - The metric used by a router to reach a particular subnet
Successor Route - The route with the lowest FD to a particular subnet. This is promoted to the routing table.
Feasible Successor Route - A backup route to a Successor Route. For a route to considered a Feasible Successor it must have an AD less than the FD.

Let's say R1 has a Successor Route to 192.168.1.0/24 with an FD of 100 via R2 (assume R2 has an AD of 85 and our RD to R2 is 15). R3 also tells R1 that it can get to 192.168.1.0/24 with an AD of 150 and R4 can also get to 192.168.1.0/24 with an AD of 90. Do we have a Feasible Successor route? The answer is Yes. R4s AD is less than the FD of the Successor Route (i.e. 100) so it will be considered a Feasible Successor route. Note that R3's AD is 150 which is greater than the FD of 100 so it will not be considered a Feasible Successor route.

If, for example, R2 was to fail, R1 can simply promote the Feasible Successor route via R4 to the routing table thereby drastically reducing any network convergence time.

How do we view feasible successors? We simply use the show ip eigrp topology to view EIGRP's Topology table (this will show Successor and Feasible Successor routes only. If you want to view all routes use the show ip eigrp topology all-links command). I will now show a snippet of an entry to show how we identify a Feasible Successor.

R1# show ip eigrp topology
[output omitted]
P 172.31.24.0/30, 1 successors, FD is 768
       via 172.31.11.2 (768/512), FastEthernet0/0
       via 172.31.14.2 (1024/512), Serial0/0.4

That snippet shows that the route to 172.31.24.0/30 has one successor route which is always the first route underneath (in this case via FastEthernet0/0). Note the second entry via Serial0/0.4 and the contents of the brackets (1024/512). The 1024 denotes this router's Feasible Distance to reach the 172.31.24.0/30 subnet via Serial0/0.4. The Feasible Distance via FastEthernet0/0 is 768 which makes it better than 1024 and hence become the successor route. The second figure in the brackets is 512 which is the Reported Distance to the 172.31.24.0/30 subnet on Serial0/0.4. If this figure is less than the Feasible Distance of the Successor Route then it can be considered a Feasible Successor. In this case 512 is less than 768 so it can be considered a Feasible Successor. Let's bolden the text in the snippet above to help illustrate that point:

R1# show ip eigrp topology
[output omitted]
P 172.31.24.0/30, 1 successors, FD is 768 - FEASIBLE DISTANCE OF SUCCESSOR ROUTE
       via 172.31.11.2 (768/512), FastEthernet0/0
       via 172.31.14.2 (1024/512 - MUST BE LESS THAN FD OF SUCCESSOR ROUTE), Serial0/0.4

EIGRP can now support up to 16 equal-cost paths to a destination (not 6 as most books would have you know). This simply means that R1 could have 16 Successor Routes to a destination and would load balance across all 16 routes.

Load Balancing and Unequal Cost Load Balancing

I've already alluded to the fact that EIGRP can now support up to 16 equal-cost paths to a destination (not 6 as most books would have you know). Remember that this simply means that R1 could have 16 Successor Routes to a destination and would be able to load balance across all 16 routes.

You can configure this using the maximum-paths command under the EIGRP process. For example:

router eigrp 100
 maximum-paths 6 <--sets the maximum number of Successor Routes to 6

A neat feature of EIGRP is to be able to load balance across paths that have different costs. In fact I was asked to configure this just the other day. It uses the concept of a multiplier called variance. This multiplies the FD of a route by the configured figure (let's call this value FDnew). Any Feasible Successor routes that have a value less than FDnew are considered to be equal to the original Successor Route and are promoted to the routing table.

To configure the variance we simply use the variance command under the EIGRP process:

router eigrp 100
 variance 2 <--would multiply the FD of all Successor Routes by 2

Let's look at an example. R1 has a Successor Route to 192.168.1.0/24 via R2 with a FD of 100. R1 also has a Feasible Successor route via R3 with an AD of 90 and a total FD of 190. R1 also has a Feasible Successor route via R4 with an AD of 95 and a total FD of 205. R1 has variance 2 configured under its EIGRP process. The FD of the Successor Route is now 100 * 2 = 200. We now look at the FD of each Feasible Successor to see if it is less than 200. In the case of R3 this is true, and with R4 it is false. Therefore the routing table would contain two routes to 192.168.1.0/24 - the original route via R2 and the route via R3.

You can configure how EIGRP shares traffic across links. By default it will balance evenly across routes, ignoring EIGRP metrics. The folliwng can be configured under the EIGRP process:

traffic-share balanced - The router balances across the routes, giving more packets to lower-metric routes

traffic-share min - Although multiple routes are installed in the routing table, the router sends traffic using only the lowest-metric route

traffic-share balanced across-interfaces - If more routes exist than are allowed with the maximum-paths setting, the router chooses routes with different outgoing interfaces, for better balancing.

Going active on a route

There will inevitably be occasions when a route to a particular subnet goes down for some reason. If there is no feasible successor for that route the router will go active on that route. Conversely, if the route is up it is said to be passive.

So what does going active actually mean? Basically the router will query (remember that EIGRP Query packets are sent as a reliable multicast and will expect an Ack to be sent back) all of its neighbours asking them if they know of a route to the subnet in question. The router will then expect all of its neighbours to reply, using a reliable unicast EIGRP Reply packet, before calculating a new route and sending an Ack back.

Neighbours that are queried can do one of three things:

1. Send a Reply packet back stating that they do not have a route
2. Send a Reply packet back with details of their route
3. Go Active themselves if 1 or 2 are not satisfied and withholds its response until it has received all of its replies from the neighbours it is querying.

Hopefully you can see a pitfall here. If R1 went active on a route causing R2 to go active, it may mean R3 goes active too, etc. If a router stays active on a route for too long (default is 3 minutes) it is said to be stuck-in-active on that route and brings down the neighbour relationship to the router it has not received a reply from as it thinks that that router is having some problems. However, that router may be fine and it is downstream where the issue lies. This is clearly an undesirable state.

You can turn off the active timer by issuing the timers active-timer disabled command under the EIGRP process in order to combat a route from being stuck-in-active, however, there are more elegant solutions which revolve around limiting the query scope which we will discuss in the next section.

Limiting the Query Scope

Two methods can be used to limit the query scope in an EIGRP network. The first method that can be used is summarisation. When a Query reaches a router that has a summarised route, but not the specific route in the Query, the router immediately replies that it does not have that route. Put simply, if my router had a summarised route of 192.168.1.0/24 and it received a Query about network 192.168.1.16/28, it will send a Reply saying that it doesn't have a route to 192.168.1.16/28.

The second method for limiting the query scope involves the use of stub routers. Stub routers should not be used as transit routers and non-stub routers do not query stub routers. An ideal candidate for being configured as a stub router is a spoke site router in a hub-and-spoke topology. EIGRP stub routers are very easy to configure:

router eigrp 100
 eigrp stub <-- makes this an EIGRP stub router

By default, the eigrp stub command will cause the router that it is issued on to advertise connected and summary routes only and indeed when you issue a show run you will see the following:

router eigrp 100
 eigrp stub connected summary

There are other options that can be specified, some of which are not compatible with others. The following describes these options:

eigrp stub connected - Advertise connected routes, but only for interfaces matched with a network command.
eigrp stub summary - Advertise auto-summarised or statically configured summary routes.
eigrp stub static - Advertise static routes, assuming the redistribute static command is configured.
eigrp stub redistributed - Advertise redistributed routes, assuming redistribution is configured.
eigrp stub receive-only - Does not advertise any routes. This option cannot be used with any other option.

Authentication

As I mentioned earlier in this piece, EIGRP can have authentication configured so that EIGRP communication can be secured. Unlike other routing protocols EIGRP supports MD5 authentication only. If authentication is configured a pair of routers must be able to pass the authentication procedure if they are to successfully become neighbours. As you would expect, the passwords on both sides must match in order for the EIGRP neighbour relationship and subsequent updates to be successful.

You configure the passwords in global configuration mode using key-chains which are made up of keys which in turn have the password configured on them with optional send and receive lifetimes. Let's configure a basic key-chain (more advanced configuration can be seen here):

key-chain MyKeyChain
 key 1
 key MyPassword

To turn EIGRP authentication on you must configure it under the interface which will be sending the updates:

int fa0/0
 ip authentication mode eigrp autonomous-system-number md5
 ip authentication key-chain eigrp autonomous-system-number key-chain-name

So if I was to use AS 100 my configuration would look like:

int fa0/0
 ip authentication mode eigrp 100 md5
 ip authentication key-chain eigrp 100 MyKeyChain

EIGRP Summarisation
EIGRP supports classless routing but is classful in nature by default. What this means in very simple terms is that EIGRP can be configured to send subnet masks supports Variable Length Subnet Masks. If a router running EIGRP has a different class of address on two interfaces (e.g. a Class A address on one interface and a Class B address on another interface) an update going out of the Class B interface will automatically summarise the Class A networks in that update to the default mask of /8. For example, the router may have learned about 10.1.2.0/24 on one interface but because it is advertising that network out of an interface with a different class of address it would advertise it as 10.0.0.0/8. This doesn't happen if you issue the no auto-summary command under the EIGRP routing process and the router will advertise 10.128.1.0/24. This is especially important when it comes to discontiguous networks which is a fancy name for a class of network that has another class of network in between, for example:

(Class A)R1(Class B)-->(Class B)R2(Class B)-->(Class B)R3(Class A)

Here R2 could learn a route to 10.0.0.0/8 from both R1 and R3 as both R1 and R3 would have automatically summarised the Class A address to a /8.

EIGRP also supports summarisation anywhere in the network by configuring a summary address on an interface:

int fa0/0
 ip summary-address eigrp as-number ip-address mask [admin-distance] [leak-map name]

The ip summary-address eigrp command is used to configure interface-level address summarization. EIGRP summary routes are given an administrative distance value of 5. The administrative distance metric is used to advertise a summary without installing it in the routing table.

By default, EIGRP summarizes subnet routes to the network level. The no auto-summary command can be entered to configure subnet level summarization.

EIGRP Support for Leaking Routes - Configuring the leak-map keyword allows the advertisement of a component route that would otherwise be suppressed by the manual summary. Any component subset of the summary can be leaked. A route map and access list must be defined to source the leaked route.

The following is default behavior if an incomplete configuration is entered:

If the leak-map keyword is configured to reference a nonexistent route map, the configuration of this keyword has no effect. The summary address is advertised but all component routes are suppressed.

If the leak-map keyword is configured but the access-list does not exist or the route map does not reference the access list, the summary address and all component routes are sent.

Let's have a look at some examples:

The following example configures an administrative distance of 95 on interface FastEthernet0/0 for the 192.168.0.0/16 summary address:

router eigrp 100
 no auto-summary

interface fa0/0
 ip summary-address eigrp 100 192.168.0.0 255.255.0.0 95

The following example configures the 10.1.1.0/24 subnet to be leaked through the 10.0.0.0 summary address:

router eigrp 100

access-list 1 permit 10.1.1.0 0.0.0.255
route-map LEAK-10-1-1 permit 10
 match ip address 1

interface fa0/0
 ip summary-address eigrp 1 10.0.0.0 255.0.0.0 leak-map LEAK-10-1-1

Split Horizon

Split Horizon stops a network being advertised out of an interface in which it has been learned. For example, if a router learned about network 192.168.1.0/24 on fa0/0 an EIGRP routing update out of fa0/0 would not contain 192.168.1.0/24. This is to prevent routing loops from occurring. Split Horizon is enabled by default on all interfaces except Frame Relay interfaces where the IP address is configured on the physical interface. You can turn off Split Horizon on an interface by issuing the no ip split-horizon eigrp autonomous-system-number command under an interface:

interface FastEthernet0/0
 no ip split-horizon eigrp 100

Passive Interface

Unlike RIP where the passive-interface command tells a router's interface to stop sending updates out of that interface, that same command under the EIGRP process actually prevents a neighbour relationship from forming.

router eigrp 100
 network 10.0.0.0
 no auto-summary
 passive-interface FastEthernet0/0 <--stops EIGRP forming neighbour relationship on fa0/0

Be aware that you can make all interfaces passive by issuing the passive-interface default command. This might be desirable when you want all interfaces except one from forming a neighbour relationship. For example, you may only want a router connected to fa0/0 to form a neighbour relationship with your router so you make every interface passive by default and then issue the no passive-interface [interface] command:

router eigrp 100
 network 10.0.0.0
 no auto-summary
 passive-interface default <--stops EIGRP forming neighbour relationships on all interfaces
 no passive-interface FastEthernet0/0 <--allows EIGRP to form a neighbour relationship on fa0/0

Route Filtering

In order to prevent updates about certain networks from being received or sent you should use something called a distribute-list. A distribute-list filters out routes from entering the routing table or being sent by referencing a pre-configured access-list or prefix-list.

For example, let's create an access-list:

access-list 1 permit 192.168.1.0 0.0.0.255

The syntax of a distribute-list when using an access-list is as follows and is configured under the routing process:

distribute-list [access-list-number_or_access-list-name] [in | out] [interface]

If there is a match in the access-list then that route is filtered out of the routing update. If you look at my access-list you will see that I am filtering out the 192.168.1.0/24 network.

In the following example I will use a distribute-list to stop updates being received on fa0/0 about 192.168.1.0/24

access-list 1 permit 192.168.1.0 0.0.0.255

router eigrp 100
 network 192.168.1.0
 no auto-summary
 distribute-list 1 in FastEthernet0/0 <--filter incoming updates on fa0/0 as specified by ACL 1

The next example shows you how to stop routes being advertised by changing the direction in the distribute-list command.

access-list 1 permit 192.168.1.0 0.0.0.255

router eigrp 100
 network 192.168.1.0
 no auto-summary
 distribute-list 1 out FastEthernet0/0 <--prevents updates out of fa0/0 as specified by ACL 1

Using Offset Lists to change EIGRP's metric for a particular route

You change the metric received or advertised in EIGRP by using an offset-list. This is very similar in configuration to distribute-lists where you reference an access-list. The access-list will be checked against sent or received updates and the specified offset added to the metric. The basic syntax is:

offset-list [access-list-number_or_access-list-name] [in | out] [specified-offset] [interface]

Let's look at an example:

R1 has a route for 192.168.1.0/24 with a metric of 1544. We want to advertise that route to R2 with a metric of 1600. Let's configure our offset-list:

access-list 1 permit 192.168.1.0 0.0.0.255

router eigrp 100
 offset-list 1 out 56 FastEthernet0/0

Here offset-list 1 specifies ACL 1 which will match 192.168.1.0/24. This is applied outbound as specified by out. We add 56 to the metric of all routes matched by our access-list as specified by the 1 after the out keyword. Finally we specify the interface out of which our offset-list is applied.

Offset lists are more applicable to RIPv1 and RIPv2 than EIGRP has RIP has such a limited metric range. With EIGRPs complex metric it is very doubtful that you would want to change the metric in this way.

Clearing EIGRP routes from the routing table

The clear ip route * command from privileged mode will not affect EIGRP routes as the routers are in the topology table and will simply go straight back in to the routing table. In the case of EIGRP you have to tear down the neighbour adjacency:

clear ip eigrp neighbor - clears all neighbour adjacencies
clear ip eigrp neighbor ip-address - clears specified neighbour adjacency
clear ip eigrp neighbor interface - clears neighbour adjacencies on specified interface

Conclusion

If you're at ICND2 and above you need to know the majority of what I've written but as with my RIP posting I've tried to be as brief as possible as I don't see the point of reinventing the wheel as there are so many quality papers on EIGRP. I hope I've got enough detail in here for you to understand the basic operation of EIGRP and some of the extras that can be configured.

As always, if you have any questions about this topic please feel free to leave a comment and/or email me using the Contact Me tab at the top of the screen.

Good luck with your studies!