Enhanced Interior Gateway Routing Protocol (EIGRP) is a routing protocol developed by
Cisco based on the DUAL algorithm. EIGRP was previously proprietary but has recently
been opened up by Cisco with an IETF draft. EIGRP has been accused of having no hierarchy.
This post will show that it’s a false claim and highlight important design factors to
make EIGRP behave and scale in the best way. Future posts will look at OSPF and ISIS.
EIGRP has no areas like OSPF does. So how can hierarchy be achieved with EIGRP? First,
let’s remember that EIGRP is distance vector so there is no Link State DataBase (LSDB)
which contains the topology. EIGRP only knows routes and next-hops. It’s still possible
to achieve hierarchy with EIGRP and this is done through summarization and/or filtering.
This means that it’s up to the administrator how much hierarchy is desired and in that
way EIGRP can have more “levels” than OSPF or ISIS.
EIGRP Scaling Considerations
Which factors are important to consider when designing a scalable EIGRP network? The
most important things to consider are IP addressing, bounding the query scope and
cutting down on the number of peers. The most critical part is to not have a too large
EIGRP uses the DUAL algorithm. When the network is in its normal state the routes are
considered to be passive. The best known route by EIGRP is called the successor. If
there are loop free alternate paths, these are called feasible successors.
When an EIGRP router loses its successor and there is no feasible successor available it
will send out a query to all peers looking for an alternate path. The router then expects
to receive a reply back in, either with an alternate route or with a reply saying that
there were no alternate paths available. This query could potentially travel across the
entire network unless consideration has been taken to bound the query scope.
IP addressing is always an important part of a network design but with EIGRP it is especially
important. This is because EIGRP relies on summarization to achieve hierarchy and to bound
the query scope. This means that when addressing remote sites it should be done in such a
manner that it’s easy to summarize from the distribution layer towards the core.
With the addressing in the diagram it’s easy to summarize and the core has fewer routes
which is always a good thing. Right now the core has 2 routes instead of 16 if the
addressing was chosen poorly.
How should the addressing be chosen? This will always depend a lot on the network but
some general guidelines should be to look at which access routers connect to which
distribution routers. The access routers should have networks so that the distribution
router can summarize these routes. Generally this would depend on the geography so
a good practice could be to assign x number of networks for each region to use. Assign
these on “binary boundaries” so instead of adding a network at a time, add 4 or 8 or
something that makes it easy to summarize.
Bounding EIGRP Queries
EIGRP queries are bounded by the following parameters:
- Local knowledge of a loop free alternate path not learned through the peer sending the query
- No local knowledge of route due to filtering
- No local knowledge of route due to summarization
- No peers to query
This can be seen in the following diagram:
When A loses the 10.0.0.0/24 network it will query all peers. It’s important to note
that queries will travel one step further than the place where filtering/summary is
Where to Apply Filtering/Summarization
Where should the filtering/summarization be applied? It depends on the network topology.
The most common design is to have two or three layers. If two layers are used, generally
they are called Core and Aggregation. When three layers are used they are called Access,
Distribution and Core.
When using only two layers summarize from the Aggregation layer towards the Core.
This is important to minimize the number of routes in the Core. Routes can also be
summarized from the Core towards the Aggregation layer. The Aggregation layer does not
need to know all the routes, it might even be enough with a default route. It is not
necessary to summarize within the Core. If it’s not possible to summarize outbound
on the Aggregation router then filter on the Core edge routers.
When using a three layer design the natural point to do summarization is at the
Distribution layer. Both towards the Core and towards the Access layer. The goal is
to minimize routes within the Core and also towards the Access layer. This will help
both with bounding queries and speeding up convergence.
Dangers of Summarization
Although summarization is generally good there are some dangers that need to be
avoided. Summarization can cause black holes and routing loops if care is not taken.
Look at the following diagram:
Distribution routers A and B are sending the same summary towards the core. B has a
failure towards the router with the network 10.0.0.0/24. Because one component route is
still available in the summary, the summary is still advertised towards the core.
If traffic arrives at B destined for 10.0.0.0/24, the traffic will be black holed.
Potentially it could be even worse if B follows a default route back towards the
core, causing a routing loop.
To prevent against this scenario, put a link between the distribution routers that
does not do summarization. Summarization should be done up and down layers, not
EIGRP has a concept of stub routers, this is not the same as stub routing in OSPF.
What the stub feature does is to define that this is the end of the network, I am
a leaf on the tree. This means that queries will not be sent to stub routers, why
send a query if it’s not possible to get a reply with an alternate path? This is
a great feature for bounding queries. This should be deployed on all Access layer
routers if possible.
When a router is configured as stub, by default it will only announce connected
and summary routes meaning that it will not be transit for any networks. If not
configured as a stub, situations like this could occur:
As shown by the arrows, the Access layer routers may become transit which is
generally not desirable. These devices may not be capable of carrying the traffic
load that was between the Distribution layer devices. Queries will also have to be
sent out when the link between A and B fails.
Minimizing the Number of Peers
Sometimes there may be dual routers attached to the same LAN as in the following diagram.
If EIGRP is configured for all networks, which could be hundreds of VLANs in a big
network, then EIGRP will peer over all networks. This leads to lots of unnecessary
adjacencies which will slow down convergence and lead to a more unstable network.
Also a lot of queries will have to be generated if a route has to go active. Avoid
this situation by using passive-interface default and choose one interface to be
This post showed that EIGRP as a protocol does have hierarchy. This hierarchy is
imposed by doing summarization and/or filtering. To design a scalable EIGRP network,
care must be taken when designing the IP plan. Summarization, filtering and the
EIGRP stub feature is important to build a scalable network. EIGRP queries have to
be bounded and this is done through summarization/filtering and the stub feature.
You might think that EIGRP being around for so long is not getting any attention from
Cisco, not true. EIGRP is still being developed and in later releases you can run what
is called named configuration. Doing this you can put all EIGRP config under one named
instance, even v6 which is different from the old syntax. If you are on Twitter you should
follow Donnie Savage @diivious. He works for Cisco and is usually present at Cisco Live
presenting on the development of EIGRP.
We start out with the following topology.
So we start out by defining our instance and calling it corp
R2#conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#router eigrp corp
From there we have the following options:
R2(config-router)#? Router configuration commands: address-family Enter Address Family command mode default Set a command to its defaults exit Exit from routing protocol configuration mode no Negate a command or set its defaults service-family Enter Service Family command mode shutdown Shutdown this instance of EIGRP
From here we can shutdown the process or configure different address families.
We start by setting up IPv4 in the global table.
R2(config-router)#address-family ipv4 autonomous-system 12 R2(config-router-af)#? Address Family configuration commands: af-interface Enter Address Family interface configuration default Set a command to its defaults eigrp EIGRP Address Family specific commands exit-address-family Exit Address Family configuration mode help Description of the interactive help system maximum-prefix Maximum number of prefixes acceptable in aggregate metric Modify metrics and parameters for address advertisement neighbor Specify an IPv4 neighbor router network Enable routing on an IP network no Negate a command or set its defaults shutdown Shutdown address family timers Adjust peering based timers topology Topology configuration mode R2(config-router-af)#network 188.8.131.52 255.255.255.0
From here we define networks, setup static neighbors and configure EIGRP parameters.
We will use regular syntax on R2 for setting up EIGRP.
R2(config-if)#router eigrp 12 R2(config-router)#no auto R2(config-router)#net 184.108.40.206 0.0.0.255
The session comes up.
%DUAL-5-NBRCHANGE: EIGRP-IPv4 12: Neighbor 220.127.116.11 (FastEthernet1/0) is up: new adjacency
R2 is announcing it’s loopback. Lets see if we receive that.
R1#sh ip route eigrp | be Gateway Gateway of last resort is not set 18.104.22.168/32 is subnetted, 1 subnets D 22.214.171.124 [90/2662400] via 126.96.36.199, 00:00:23, FastEthernet1/0
What more can we configure under the address-family?
R1(config-router-af)#af-interface f1/0 R1(config-router-af-interface)#? Address Family Interfaces configuration commands: authentication authentication subcommands bandwidth-percent Set percentage of bandwidth percentage limit bfd Enable Bidirectional Forwarding Detection dampening-change Percent interface metric must change to cause update dampening-interval Time in seconds to check interface metrics default Set a command to its defaults exit-af-interface Exit from Address Family Interface configuration mode hello-interval Configures hello interval hold-time Configures hold time next-hop-self Configures EIGRP next-hop-self no Negate a command or set its defaults passive-interface Suppress address updates on an interface shutdown Disable Address-Family on interface split-horizon Perform split horizon summary-address Perform address summarization
We configure all EIGRP interface commands under the af-interface. We can setup
authentication of the peering.
R1(config-router-af)#af-interface f1/0 R1(config-router-af-interface)#authentication mode ? hmac-sha-256 HMAC-SHA-256 Authentication md5 Keyed message digest R1(config-router-af-interface)#authentication mode md5 R1(config-router-af-interface)#authentication key-chain EIGRP %DUAL-5-NBRCHANGE: EIGRP-IPv4 12: Neighbor 188.8.131.52 (FastEthernet1/0) is down: authentication mode changed %DUAL-5-NBRCHANGE: EIGRP-IPv4 12: Neighbor 184.108.40.206 (FastEthernet1/0) is up: new adjacency
What’s new here is that sha-256 is now also supported. From this af-interface mode
we can configure timers and BFD as well.
Now we will configure IPv4 in a VRF called 13.
R1(config)#vrf definition 13 R1(config-vrf)#rd 13:13 R1(config-vrf)#int f1/1 R1(config-if)#no sh R1(config-if)#vrf forwarding 13 R1(config-if)#ip add 220.127.116.11 255.255.255.0 R1(config-router)#address-family ipv4 vrf 13 autonomous-system 13 R1(config-router-af)#net 18.104.22.168 0.0.0.255 %DUAL-5-NBRCHANGE: EIGRP-IPv4 13: Neighbor 22.214.171.124 (FastEthernet1/1) is up: new adjacency
Do we receive any prefixes?
R1#sh ip route vrf 13 | be Gate Gateway of last resort is not set 126.96.36.199/32 is subnetted, 1 subnets D 188.8.131.52 [90/2662400] via 184.108.40.206, 00:00:31, FastEthernet1/1 220.127.116.11/8 is variably subnetted, 2 subnets, 2 masks C 18.104.22.168/24 is directly connected, FastEthernet1/1 L 22.214.171.124/32 is directly connected, FastEthernet1/1
Which we do. Nothing strange here, just a new syntax for defining VRFs compared
to the old ip vrf syntax.
Finally we will configure IPv6 peering as well. Because EIGRP sends packets from
link local address we don’t even need to configure a global IPv6 address.
R1(config-router)#int f2/0 R1(config-if)#ipv6 enable R1(config-if)#no sh R1(config-if)#router eigrp corp R1(config-router)#address-family ipv6 autonomous-system 14 R1(config-router-af)#af-interface default R1(config-router-af-interface)#no shut
Only difference here is that instead of defining network we use the interface command
instead to enable it on all active IPv6 interfaces.
R1#sh ipv6 route eigrp IPv6 Routing Table - default - 2 entries Codes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, R - RIP, H - NHRP, I1 - ISIS L1 I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP D 2001::/64 [90/2662400] via FE80::C803:82FF:FE80:1C, FastEthernet2/0
And that’s about it. Named configuration is made to unify configuration under
one instance and remove the commands that we used to type under the interface
like authentication and such. It’s now all done under the address-family.
In future posts I will look at Multi Topology Routing (MTR).
Donnie Savage, Russ White, Don Slice, J. NG and Steven Moore all from Cisco have
published the IETF draft for EIGRP.
You can find it here.
Why would you want to read this draft? If you are a CCIE candidate it should be
obvious why you want to know EIGRP very well. And what better way to confirm your
findings then straight from the horses mouth?
Even if you just want to have a basic look at EIGRP they do a good job of describing
the acronyms used in EIGRP which should be useful for anyone.
I just skimmed through the draft and I wish this had been around when I was studying.
Hopefully this leads to people discussing features when talking about OSPF vs EIGRP
and not just openness.
Earlier I have done some posts on route redistribution and on
route filtering in different protocols. I wanted to expand on this
by showing different ways we can tag and do filtering with route-maps
when doing route redistribution.
We start out with this topology where two different OSPF segments are
separated by an EIGRP segment.
R2 will redistribute between OSPF and EIGRP mutually. R1 is redistributing
its loopback so it will be an external OSPF route. R4 and R5 will mutually
redistribute between EIGRP and OSPF. One interesting aspect about EIGRP is
that in the EIGRP packet we can see which protocol that originated the
route from the beginning. Take a look at this output showing the R1 loopback
in the EIGRP domain.
R4#sh ip eigrp topo 10.10.1.0/24 IP-EIGRP (AS 100): Topology entry for 10.10.1.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2560002816 Routing Descriptor Blocks: 10.10.24.2 (FastEthernet0/0), from 10.10.24.2, Send flag is 0x0 Composite metric is (2560002816/2560000256), Route is External Vector metric: Minimum bandwidth is 1 Kbit Total delay is 110 microseconds Reliability is 1/255 Load is 1/255 Minimum MTU is 1 Hop count is 1 External data: Originating router is 10.10.24.2 AS number of route is 1 External protocol is OSPF, external metric is 20 Administrator tag is 0 (0x00000000)
We can see that it came from OSPF 1 and that the ASBR is 10.10.24.2.
We also see that it had a metric of 20 and no tag applied to it. Where
is this information carried? Take a look at this packet capture.
We can see that a lot of information is carried for external routes.
This gives us options when doing tagging and filtering.
We configure distribution on R2 and then look at our options for doing
tagging and filtering.
R2#sh run | s router router eigrp 100 redistribute ospf 1 metric 1 1 1 1 1
If we look at R4 we should have two external routes with AD 170 going towards
the OSPF domain.
R4#sh ip route eigrp | i EX D EX 10.10.1.0 [170/2560002816] via 10.10.24.2, 00:07:22, FastEthernet0/0 D EX 10.10.12.0 [170/2560002816] via 10.10.24.2, 00:07:22, FastEthernet0/0
If we traceroute this traffic will go straight to R2.
R4#traceroute 10.10.1.1 num Type escape sequence to abort. Tracing the route to 10.10.1.1 1 10.10.24.2 32 msec 40 msec 28 msec 2 10.10.12.1 60 msec * 64 msec
What if we want external routes to go through R5 instead? We can
match on the route-type and incoming interface to block R2 routes.
This is a pretty blunt tool but can be good for some scenarios.
R4(config)#route-map RM_DENY_EXT_FA0/0 deny 10 R4(config-route-map)#match route-type external R4(config-route-map)#route-map RM_DENY_EXT_FA0/0 permit 100 R4(config-route-map)#router eigrp 100 R4(config-router)#distribute-list route-map RM_DENY_EXT_FA0/0 in fa0/0
So what we just did is filter all external routes coming in on Fa0/0.
Did we achieve the wanted result?
R4#sh ip route eigrp | i EX D EX 10.10.1.0 [170/2560030976] via 10.10.45.5, 00:00:21, FastEthernet0/1 D EX 10.10.12.0 [170/2560030976] via 10.10.45.5, 00:00:21, FastEthernet0/1 R4#traceroute 10.10.1.1 num Type escape sequence to abort. Tracing the route to 10.10.1.1 1 10.10.45.5 40 msec 36 msec 16 msec 2 10.10.35.3 56 msec 40 msec 40 msec 3 10.10.23.2 48 msec 28 msec 44 msec 4 10.10.12.1 68 msec * 68 msec
Now all external routes will go through R5 instead.
Currently we are not doing redistribution on R4 and R5. What will
happen with the EIGRP external routes when we do redistribution?
First we remove the previous configuration and then we configure
R4(config)#router eigrp 100 R4(config-router)#no distribute-list route-map RM_DENY_EXT_FA0/0 in FastEthernet0/0 R4(config-router)#redistribute ospf 1 metric 1 1 1 1 1 R4(config-router)#router ospf 10 R4(config-router)#redistribute eigrp 100 sub R5(config)#router eigrp 100 R5(config-router)#redistribute ospf 10 metric 1 1 1 1 1 R5(config-router)#router ospf 10 R5(config-router)#redistribute eigrp 100 sub
From R4 we now look at how it reaches 10.10.1.0/24.
R4#sh ip route 10.10.1.0 Routing entry for 10.10.1.0/24 Known via "eigrp 100", distance 170, metric 2560002816, type external Redistributing via eigrp 100, ospf 10 Advertised by ospf 10 subnets Last update from 10.10.45.5 on FastEthernet0/1, 00:00:52 ago Routing Descriptor Blocks: 10.10.45.5, from 10.10.45.5, 00:00:52 ago, via FastEthernet0/1 Route metric is 2560002816, traffic share count is 1 Total delay is 110 microseconds, minimum bandwidth is 1 Kbit Reliability 1/255, minimum MTU 1 bytes Loading 1/255, Hops 1 * 10.10.24.2, from 10.10.24.2, 00:00:52 ago, via FastEthernet0/0 Route metric is 2560002816, traffic share count is 1 Total delay is 110 microseconds, minimum bandwidth is 1 Kbit Reliability 1/255, minimum MTU 1 bytes Loading 1/255, Hops 1
Why does it have two entries for 10.10.1.0/24? Take a look in the
EIGRP topology table.
R4#sh ip eigrp topo 10.10.1.0/24 IP-EIGRP (AS 100): Topology entry for 10.10.1.0/24 State is Passive, Query origin flag is 1, 2 Successor(s), FD is 2560002816 Routing Descriptor Blocks: 10.10.24.2 (FastEthernet0/0), from 10.10.24.2, Send flag is 0x0 Composite metric is (2560002816/2560000256), Route is External Vector metric: Minimum bandwidth is 1 Kbit Total delay is 110 microseconds Reliability is 1/255 Load is 1/255 Minimum MTU is 1 Hop count is 1 External data: Originating router is 10.10.24.2 AS number of route is 1 External protocol is OSPF, external metric is 20 Administrator tag is 0 (0x00000000) 10.10.45.5 (FastEthernet0/1), from 10.10.45.5, Send flag is 0x0 Composite metric is (2560002816/2560000256), Route is External Vector metric: Minimum bandwidth is 1 Kbit Total delay is 110 microseconds Reliability is 1/255 Load is 1/255 Minimum MTU is 1 Hop count is 1 External data: Originating router is 10.10.56.5 AS number of route is 10 External protocol is OSPF, external metric is 20 Administrator tag is 0 (0x00000000)
We can see that one route is originating from OSPF 1, which is the true
source of the route and one is originating via OSPF 10. R5 is learning
this route via OSPF and then redistributing it into EIGRP and R4 is
learning that via EIGRP. Let us confirm that R5 sees this as an OSPF
R5#sh ip route 10.10.1.0 Routing entry for 10.10.1.0/24 Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 2 Redistributing via eigrp 100 Advertised by eigrp 100 metric 1 1 1 1 1 Last update from 10.10.56.6 on FastEthernet1/0, 00:08:12 ago Routing Descriptor Blocks: * 10.10.56.6, from 10.10.46.4, 00:08:12 ago, via FastEthernet1/0 Route metric is 20, traffic share count is 1
Which it does. What would happen if R5 was redistributing with a
better metric than R2 is doing? First we enable debugging of ip
routing on R4. Remember that in a stable topology where everything
is converged there should be no changes.
R4#debug ip routing IP routing debugging is on
Then we change the metric on R5.
R5(config)#router eigrp 100 R5(config-router)#redistribute ospf 10 metric 100000 10 255 1 1500
RT: eigrp's 10.10.1.0/24 (via 10.10.45.5) metric changed from distance/metric [170/2560002816] to [170/30720] RT: del 10.10.1.0/24 via 10.10.24.2, eigrp metric [170/2560002816] RT: NET-RED 10.10.1.0/24 RT: NET-RED 10.10.1.0/24 RT: eigrp's 10.10.12.0/24 (via 10.10.45.5) metric changed from distance/metric [170/2560002816] to [170/30720] RT: del 10.10.12.0/24 via 10.10.24.2, eigrp metric [170/2560002816] RT: NET-RED 10.10.12.0/24 RT: NET-RED 10.10.12.0/24
We can see that the metric change but at least we have no flapping.
R4#sh ip route 10.10.1.0 Routing entry for 10.10.1.0/24 Known via "eigrp 100", distance 170, metric 30720, type external Redistributing via eigrp 100, ospf 10 Advertised by ospf 10 subnets Last update from 10.10.45.5 on FastEthernet0/1, 00:02:33 ago Routing Descriptor Blocks: * 10.10.45.5, from 10.10.45.5, 00:02:33 ago, via FastEthernet0/1 Route metric is 30720, traffic share count is 1 Total delay is 200 microseconds, minimum bandwidth is 100000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1
Do we still have reachability?
R4#traceroute 10.10.1.1 num Type escape sequence to abort. Tracing the route to 10.10.1.1 1 10.10.45.5 40 msec 16 msec 28 msec 2 10.10.56.6 48 msec 32 msec 28 msec 3 10.10.46.4 24 msec 44 msec 28 msec 4 10.10.45.5 52 msec 48 msec 52 msec 5 10.10.56.6 60 msec 60 msec 64 msec 6 10.10.46.4 64 msec 60 msec 60 msec 7 10.10.45.5 84 msec 108 msec 100 msec
Now we have a routing loop. What is happening here is that R4
is learning the route first via EIGRP and redistributes it into
OSPF. R5 learns this route via OSPF and then redistributes it
back into EIGRP and then R4 learns this route. They are now
both pointing at each other which means we have a loop.
What are our options of solving this? One way of solving it is
to increase the OSPF external AD on R5. That way R5 should not
redistribute it back to R4.
R5(config-router)#distance ospf external 180 R4#sh ip route 10.10.1.1 Routing entry for 10.10.1.0/24 Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 2 Last update from 10.10.46.6 on FastEthernet1/0, 00:00:38 ago Routing Descriptor Blocks: * 10.10.46.6, from 10.10.56.5, 00:00:38 ago, via FastEthernet1/0 Route metric is 20, traffic share count is 1 R4#traceroute 10.10.1.1 num Type escape sequence to abort. Tracing the route to 10.10.1.1 1 10.10.46.6 56 msec 36 msec 16 msec 2 10.10.56.5 48 msec 40 msec 40 msec 3 10.10.35.3 52 msec 52 msec 52 msec 4 10.10.23.2 112 msec 76 msec 72 msec 5 10.10.12.1 96 msec * 120 msec
That solved the loop changing the distance is a bit of a hack unless
we incorporate the same policy on all devices. At least all devices
involved in redistribution should have the same policy.
R4(config)#router ospf 10 R4(config-router)#distance ospf external 180 R4#traceroute 10.10.1.1 num Type escape sequence to abort. Tracing the route to 10.10.1.1 1 10.10.24.2 28 msec 32 msec 12 msec 2 10.10.12.1 44 msec * 60 msec
Yes, that solved it. A more elegant way is to use tagging and
filtering. We remove the previous distance commands.
What we can do now is to tag all external routes coming from OSPF 1
and then deny those routes from coming in if they have a tag set.
On R4 we tag routes with tag 444 and on R5 we will tag with 555.
First we confirm that the loop is back. You should note that with
redistribution you may see different results than I due to order of
operation. If that happens you could shutdown R5 link to R3 and
the loop should be back.
R4#traceroute 10.10.1.1 num Type escape sequence to abort. Tracing the route to 10.10.1.1 1 10.10.45.5 16 msec 44 msec 24 msec 2 10.10.56.6 36 msec 28 msec 36 msec 3 10.10.46.4 32 msec 40 msec 32 msec 4 10.10.45.5 48 msec 56 msec 48 msec 5 10.10.56.6 64 msec 56 msec 68 msec 6 10.10.46.4 48 msec 64 msec 60 msec
It is still there. Time for some route-maps.
R4(config)#route-map RM_DENY_EXT_FROM_R5 deny 10 R4(config-route-map)#match tag 444 R4(config-route-map)#route-map RM_DENY_EXT_FROM_R5 permit 100 R4(config-route-map)#route-map RM_SET_TAG_444 permit 10 R4(config-route-map)#match source-protocol ospf 1 R4(config-route-map)#match route-type external R4(config-route-map)#set tag 444 R4(config-route-map)#route-map RM_SET_TAG_444 permit 100 R4(config-route-map)#router eigrp 100 R4(config-router)#distribute-list route-map RM_DENY_EXT_FROM_R5 in R4(config-router)#router ospf 10 R4(config-router)#redistribute eigrp 100 route-map RM_SET_TAG_444 sub
First we will confirm on R5 that we now see a tag.
R5#sh ip route 10.10.1.0 Routing entry for 10.10.1.0/24 Known via "ospf 10", distance 110, metric 20 Tag 444, type extern 2, forward metric 2 Redistributing via eigrp 100 Advertised by eigrp 100 metric 100000 10 255 1 1500 Last update from 10.10.56.6 on FastEthernet1/0, 00:00:48 ago Routing Descriptor Blocks: * 10.10.56.6, from 10.10.46.4, 00:00:48 ago, via FastEthernet1/0 Route metric is 20, traffic share count is 1 Route tag 444
We now see the tag. There should be no tag on EIGRP internal routes.
We can confirm this on R6.
R6#sh ip route 10.10.24.0 Routing entry for 10.10.24.0/24 Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 1 Last update from 10.10.56.5 on FastEthernet0/1, 08:28:39 ago Routing Descriptor Blocks: 10.10.56.5, from 10.10.56.5, 08:28:39 ago, via FastEthernet0/1 Route metric is 20, traffic share count is 1 * 10.10.46.4, from 10.10.46.4, 08:30:34 ago, via FastEthernet0/0 Route metric is 20, traffic share count is 1
There should be no loop on R4 now. We will test with a traceroute.
R4#traceroute 10.10.1.1 num Type escape sequence to abort. Tracing the route to 10.10.1.1 1 10.10.24.2 28 msec 44 msec 12 msec 2 10.10.12.1 36 msec * 48 msec
The loop is gone. We should implement the same policy on R5 so if
R4 sends routes back to R5 it should stop it from learning them.
R5(config)#route-map RM_DENY_EXT_FROM_R4 deny 10 R5(config-route-map)#match tag 555 R5(config-route-map)#route-map RM_DENY_EXT_FROM_R4 permit 100 R5(config-route-map)#route-map RM_SET_TAG_555 permit 10 R5(config-route-map)#match source-protocol ospf 1 R5(config-route-map)#match route-type external R5(config-route-map)#set tag 555 R5(config-route-map)#router eigrp 100 R5(config-router)#distribute-list route-map RM_DENY_EXT_FROM_R4 in R5(config-router)#router ospf 10 R5(config-router)#redistribute eigrp 100 route-map RM_SET_TAG_555 sub
And that concludes this lesson. Route redistribution is always fun
You can look at some of my older posts for more ideas about filtering
EIGRP is often called a hybrid because it has some similar features to link state protocols and
also has distance vector features but the truth is that it is a distance vector protocol.
Even though it is distance vector it does have some nice features and today I will show a
couple of different ways of filtering in EIGRP.
We start out with this topology of four routers. You can download the topology and initial
configs from here.
Routers R1-R3 are running EIGRP in AS1 and routers R2-R4 are running RIP. R4 is announcing
a loopback in RIP. We configure R2 and R3 to redistribute from RIP to EIGRP and then
I will show how to filter the route.
R3 is configured exactly the same. Let’s see if we can see the prefix.
Indeed we can. Now let’s look at our filtering options.
We will start out with a regular distribute-list, everyone knows how to do this. We create
a standard access-list matching our prefix 126.96.36.199/24.
The prefix is now filtered. What if we want to block the prefix but only from R2 and allow
it in from R3? Either we could reuse the ACL and apply it to the interface in our distribute-list
but that might not be possible if R1-R2-R3 were connected on a common Ethernet segment.
We will use an extended access-list instead, the source will match on the gateway
announcing the prefix and the destination will be the prefix we want to filter.
So let’s block the prefix from R2. In this case we must use a numbered ACL, named ACL’s
don’t work for some reason.
That worked as expected. We now only see the route from R3.
The downside of using ACL’s is that we can’t match on prefix length. We need to use
a prefix-list for this. Lets try that. We will announce a /25 subnet from R4 and filter
any prefixes that are longer than /24.
Let’s check that it is reachable from R1.
Indeed it is. Now let’s filter this with a prefix-list.
Hey! Where did all my routes go?! We forgot to permit everything else with 0.0.0.0/0 le 32.
Now we have filtered the /25 but allowed everything else. If we want to be more
specific we can tie this distribute-list to the neighbors and even interfaces.
We can also filter using the distance command. How does that work? Remember that
the lower the AD the more trustworthy a route is. What happens if we set it to 255?
255 is the worst and routes with 255 won’t even be considered for installing into
the routing table. Let’s try that. We start by adding some prefixes on R2.
We add 188.8.131.52/24 on a loopback and then we create two static routes, one that is
redistributed via the network command and one that is redistributed via static.
Let’s look at the routing table of R1.
First notice that 184.108.40.206/24 is an internal route but 220.127.116.11 is an external.
If we redistribute static they will be external, that is well known. No as well known
is the possibility to create a static route and redistribute it via the network command.
If we do this we must route to an interface instead of a next-hop. The advantage is that we
can make the route look internal. Now let’s try some filtering. Unfortunately we can’t
change the AD for specific external routes, it’s all or nothing. Let’s say that we don’t
want to install any external paths. This is the current state of R1 and external routes.
We will set the AD to 255 for all external routes.
Now the routes are gone. What if we want to filter a specific internal route?
We set to distance to 255, we don’t care about the route source and we match ACL 1
which is the route that we want to filter.
There is one more type of filtering I would like to show and it is the route-map.
We will configure a route tag on R3 and match this tag on R1.
First we look at the route to 18.104.22.168/24 on R1, it is installed via R3.
Then we configure tagging on R3.
Now we configure a route-map that matches the tag and denies the prefix.
The route is now installed via R2 instead. The great thing with EIGRP is that we
can use the route-map with the distribute-list which we can’t with other
We can even do more advanced things like matching on source-protocol or metric.
Now look at the routing table.
Only the routes that were not source from RIP are still in the routing table.
This post should give you a good understanding of what filtering is available
in EIGRP. The possibilities are endless!
When we configure EIGRP on interfaces that are not on the same subnet we will get a message from EIGRP telling us this. What happens if we configure EIGRP on secondary interfaces? Try this setup with two routers:
Primary IP: 22.214.171.124/24
Secondary IP: 126.96.36.199/24
Primary IP: 188.8.131.52/24
Secondary IP: 184.108.40.206/24
Then you enable EIGRP and run network 220.127.116.11 0.0.0.0 and 18.104.22.168 0.0.0.0 respectively on each router. Will they be able to form an adjacency? Post your answer in the comments section.
- Cisco proprietary
- Uses IP protocol 88 as transport
- Support for MD5 authentication (no clear text)
- Sends updates to 22.214.171.124
- Distance vector but has some link state like features
Uses a hello and a hold timer. Neighbors discovered via hello protocol. Hold timer used for declaring when a neighbor is dead. EIGRP doesn’t use it own timers for keeping track of the neighbor, it uses the timers that the neighbor supplied in the hello packet. Retransmission TimeOut (RTO) timer used for knowing if to resend an update to a neighbor. Smoothed Round Trip Time (SRTT) keeps track of latency between neighbors and the RTO is derived from the SRTT timer. SRTT is the average time in ms between sending a packet to a neighbor and receiving an ACK. The default timer for hello is 5 seconds for most interfaces and a hold time of 15. NBMA interfaces with T1 or lower speeds use a 60 second hello timer and a 180 second hold time. Changing the hello timer does not automatically adjust the hold time.
Updates are sent as multicasts but resends are unicast to neighbors who didn’t ACK the update before the RTO timer expired. 16 resends using unicast will be used before declaring a neighbor dead. The multicast flow timer is used for knowing when to switch to unicast packets instead of multicast for a neighbor.
Based on cumulative delay and constraining bandwidth. Can factor in load, reliability and MTU if needed but not recommended by Cisco. To change what K values are used (constants) set them with the metric weights command. To calculate the metric use: 256*(10^7/bandwidth)+256(delay).
EIGRP measures delay in tens of microseconds, this needs to be considered when calculating the metric.
EIGRP uses Reported Distance (RD) and Feasible Distance (FD) for the metric. Reported distance is what the neighbor sending the update has calculated the metric to be. Feasible distance is the distance of the route with the lowest metric, it is the RD + the distance between the neighbor announcing the route and the local router. The route with the lowest metric that is entered into the routing table is called a successor route. A feasible successor route is a route that doesn’t have the lowest metric but meets the feasibility condition meaning it has a RD lower than what the current FD is.
Input events and local computation
When an input event occurs EIGRP needs to react, this could be an interface failing, a neighbor failing or an update for a new prefix. When the input event has occured EIGRP performs a local computation, EIGRP looks for a Feasible Successor (FS) route in its topology table and if it cannot find one it will actively query its neighbors for a route.
Uses the Diffusing Update ALgorithm (DUAL). Functioning routes are in a passive mode. Routes that no longer have a successor is in active mode since the route has to query its neighbors for a FS. The term Stuck In Active (SIA) means that an route has been active for too long, the active timer has expired. The active timer is set to 180 seconds by default, the active timer can also be disabled if needed.
EIGRP allows for up to 16 equal-metric routes to be installed in the routing table, the default is four. EIGRP also has something called variance. Variance allows for non equal-metric load balancing. The route still has to meet the feasibility condition to be considered for load balancing. The variance command is a multiplier, if the FD is 10000 for the current succcessor and there is a FS with a RD of 5000 and FD of 200000, variance 2 would make the router load balance between these two routes, variance 2 means the FD of the second best route can be twice as high as the best.
The load balancing can be done in a few different ways, traffic-share balanced means that the traffic will be distributed according to the metric, routes with lower metrics will see more traffic on them. Traffic-share min, install multiple routes but send only traffic on the one with the lowest metric. Traffic-share min across-interfaces, if more than one route has the same metric choose different outgoing interfaces for a better load balancing. The no traffic-share command will balance evenly across routes no matter what the metric is.
EIGRP has support for MD5 authentication, clear text is not supported. The keys are entered into a key-chain. A key can have a lifetime specified or use a lifetime that is always valid. Authentication is configured per interface.
Uses auto-summary by default, turned off with no auto-summary. EIGRP has support for summarizing on every EIGRP interface compared to OSPF which can only summarize at area borders.
EIGRP is a distance vector protocol which means it uses split horizon. Split horizon means the router doesn’t send updates back out on the interface it received them. This can cause issues in non P2P networks. Split horizon can be turned off on an interface basis with the command no ip split-horizon eigrp asn command where asn is the AS-number specified.
Has support for distribute lists and offset lists. Distribute lists are used for filtering inbound or outbound routing updates and what is allowed to enter the routing table. Offset lists are used to change the metric, only adding to the metric is supported, not removing from it.