Archive
EIGRP named configuration
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 12.12.12.0 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 12.12.12.0 0.0.0.255
The session comes up.
%DUAL-5-NBRCHANGE: EIGRP-IPv4 12: Neighbor 12.12.12.2 (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
2.0.0.0/32 is subnetted, 1 subnets
D 2.2.2.2 [90/2662400] via 12.12.12.2, 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 12.12.12.2 (FastEthernet1/0) is down: authentication mode changed %DUAL-5-NBRCHANGE: EIGRP-IPv4 12: Neighbor 12.12.12.2 (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 13.13.13.1 255.255.255.0 R1(config-router)#address-family ipv4 vrf 13 autonomous-system 13 R1(config-router-af)#net 13.13.13.0 0.0.0.255 %DUAL-5-NBRCHANGE: EIGRP-IPv4 13: Neighbor 13.13.13.3 (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
3.0.0.0/32 is subnetted, 1 subnets
D 3.3.3.3 [90/2662400] via 13.13.13.3, 00:00:31, FastEthernet1/1
13.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 13.13.13.0/24 is directly connected, FastEthernet1/1
L 13.13.13.1/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).
EIGRP draft released
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.
Route redistribution – Route-maps and tagging
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
redistribution.
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
route.
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
routes.
Filtering routes in EIGRP
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 4.4.4.0/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 2.2.2.0/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 22.22.22.0/24 is an internal route but 222.222.222.0 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 4.4.4.0/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
protocols.
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!
EIGRP on secondary interfaces – quiz
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:
R1:
Primary IP: 163.19.1.1/24
Secondary IP: 163.19.11.1/24
R2:
Primary IP: 163.19.1.2/24
Secondary IP: 163.19.22.2/24
Then you enable EIGRP and run network 163.19.11.1 0.0.0.0 and 163.19.22.2 0.0.0.0 respectively on each router. Will they be able to form an adjacency? Post your answer in the comments section.
Enhanced Interior Gateway Protocol (EIGRP) – notes
- Cisco proprietary
- Uses IP protocol 88 as transport
- Support for MD5 authentication (no clear text)
- Sends updates to 224.0.0.10
- Distance vector but has some link state like features
Timers
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.
Sending updates
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.
Metric
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.
EIGRP algorithm
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.
Load balancing
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.
Authentication
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.
Summarization
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.
Split horizon
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.
Filtering
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.
