Adjacency

EIGRP is a simple distance vector protocol. To become neighbors only a few parameters of the Hello packet must match:

• K-values
• AS
• Must be on the same subnet

As soon as you see a Hello packet from a neighbor and the Hello parameters match, you’re adjacent and can start exchanging updates.

EIGRP uses the link local multicast address 224.0.0.10 to discover and establish neighbors. IANA defines a list of the reserved addresses.

Let’s have a look at an EIGRP Hello packet:

This router is in AS 100 and uses default K-values where K1 (BW) and K3 (DLY) is turned on (1).

Note the Hold Time does not need to match between neighbors! You should, however, ensure that the Hello interval configured on the neighbor is lower than the Hold Time advertised in the Hello packet.

Unequal Cost Load Sharing

Using the variance we can instruct EIGRP to do unequal cost load sharing. The variance command tells how many times a path can be worse than the successor. The alternate path still must be a FS, though (RD<FD). But what if you’re asked to do some sort of ratio of load sharing? Let’s have a look at a very simple three router topology:

Without jumping to the CLI, we see that R1 will do ECMP for 10.0.23.0/24. What if we wanted to do a ratio of 1:3 where the one part is through R3? Now let’s see the metric that R1 is currently using as a baseline for our calculation.

! R1 EIGRP topology table:
R1#show ip eigrp topology 10.0.23.0/24
EIGRP-IPv4 Topology Entry for AS(100)/ID(10.0.13.1) for 10.0.23.0/24
  State is Passive, Query origin flag is 1, 2 Successor(s), FD is 3072
  Descriptor Blocks:
  10.0.12.2 (GigabitEthernet1.12), from 10.0.12.2, Send flag is 0x0
      Composite metric is (3072/2816), route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 20 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
        Originating router is 10.0.23.2
  10.0.13.3 (GigabitEthernet1.13), from 10.0.13.3, Send flag is 0x0
      Composite metric is (3072/2816), route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 20 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
        Originating router is 10.0.23.3
R1#

EIGRP only uses BW and DLY for its composite metric calculation. The formula is this with default K-values:

metric = 256 * (10^7/minBW[Kbps]+sumDLY)

DLY is in tens of microseconds. Using the above information from the topology table, we can verify the formula:

metric = 256 * (10^7/1000000+2)
metric = 3072

So the formula is correct! Now the path through R3 had to be three times worse for R1 to do a 1:3 ratio. To affect the formula we’re really left with just the DLY part, because changing the BW can affect other routing protocols as well as QoS. So we need to find this DLY value needed for the metric that has to be 3 times worse. This brings the following into the formula:

3072 * 3 = 256 * (10^7/1000000+2+DLY)
9216 = 256 * (12+DLY)
DLY = 9216/256 - 12
DLY = 24

This is the DLY value we need to add to R1’s Gi1.13 interface. It has a DLY value of 10 usec by default. Since the DLY value configured on an interface and also used by the formula is in tens of microseconds, we must divide by 10. Therefore the DLY value of 24 must have added 1 to it, which equals 25. Let’s test:

! R1 Configuration:
interface gi1.13
delay 25
!
router eigrp 100
variance 3

Remember that we must also configure the variance to make EIGRP use a path x times worse than the FD. Now what did R1 do after this change? Let’s have a look:

! R1 verification:
R1#sh ip route 10.0.23.0
Routing entry for 10.0.23.0/24
  Known via "eigrp 100", distance 90, metric 3072, type internal
  Redistributing via eigrp 100
  Last update from 10.0.13.3 on GigabitEthernet1.13, 00:09:26 ago
  Routing Descriptor Blocks:
    10.0.13.3, from 10.0.13.3, 00:09:26 ago, via GigabitEthernet1.13
      Route metric is 9216, traffic share count is 1
      Total delay is 260 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
  * 10.0.12.2, from 10.0.12.2, 00:09:26 ago, via GigabitEthernet1.12
      Route metric is 3072, traffic share count is 3
      Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
R1#

The reason why offset-list is not useful is that this adds to the RD (Reported Distance) and not the CD (Calculated Distance) as we’d like.

There is a shortcut, if you’re allowed, to do this. EIGRP is able to attach a route-map to a distribute-list. And a route-map can add to a metric. Let’s see how we can go about the 1:3 ratio a bit easier and quicker:

The current ECMP metric was 3072. We need to add two times this value to the existing one to reach a total of 9216, which is tree times worse.

! R1 - Fix ratio with a route-map:
ip prefix-list NETR2R3 perm 10.0.23.0/24
!
route-map ratio permit 10
 match ip address prefix NETR2R3
 set metric +6144
route-map ratio permit 20
!
router eigrp 100
 distribute-list ratio in gi1.13

To to verify:

! R1 verification:
R1#sh ip route 10.0.23.0
Routing entry for 10.0.23.0/24
  Known via "eigrp 100", distance 90, metric 3072, type internal
  Redistributing via eigrp 100
  Last update from 10.0.13.3 on GigabitEthernet1.13, 00:09:26 ago
  Routing Descriptor Blocks:
    10.0.13.3, from 10.0.13.3, 00:09:26 ago, via GigabitEthernet1.13
      Route metric is 9216, traffic share count is 1
      Total delay is 260 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
  * 10.0.12.2, from 10.0.12.2, 00:09:26 ago, via GigabitEthernet1.12
      Route metric is 3072, traffic share count is 3
      Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
R1#

Same result as changing the DLY on Gi1.13.

Filtering

EIGRP offers a variety of filtering methods. I’ll try to go through them here.

We’ll be looking at these techniques:

• Distribute List
• Distance
• Hop count

Distribute List

With EIGRP you can use the distribute list using these options:

• ACL
• Prefix List
  • Gateway
• Route Map

It looks like this in the CLI:

! R1 Distribute List options:
R1(config-router-af-topology)#distribute-list ?
  <1-199> IP access list number
  <1300-2699> IP expanded access list number
  WORD Access-list name
  gateway Filtering incoming address updates based on gateway
  prefix Filter prefixes in address updates
  route-map Filter prefixes based on the route-map

R1(config-router-af-topology)#

Whenever filtering using an ACL or a prefix list with a distribute list, the prefixes you deny are filtered and what ever you permit is allowed.

EIGRP can filter the prefix either at the source (originating router) in the outbound direction, or at any other router in the inbound direction.

ACL

We have the choice of both named and numbered ACLs of either standard or extended type. R4 is redistributing its Loopback0 interface with address 4.4.4.4/32 into EIGRP.

! R1's view of R4's prefix:
R1#sh ip route 4.4.4.4
Routing entry for 4.4.4.4/32
  Known via "eigrp 100", distance 170, metric 16000, type external
  Redistributing via eigrp 100
  Last update from 10.0.123.2 on GigabitEthernet1.123, 00:11:25 ago
  Routing Descriptor Blocks:
  * 10.0.123.3, from 10.0.123.3, 00:11:25 ago, via GigabitEthernet1.123
      Route metric is 16000, traffic share count is 1
      Total delay is 21 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2
    10.0.123.2, from 10.0.123.2, 00:11:25 ago, via GigabitEthernet1.123
      Route metric is 16000, traffic share count is 1
      Total delay is 21 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2
R1#

Standard ACL

To filter 4.4.4.4/32 on R1 using a Standard ACL:

! R1 filter using Standard ACL:
R1(config)#access-list 1 deny 4.4.4.4
R1(config)#access-list 1 permit any
R1(config)#router eigrp ccie
R1(config-router)#address-family ipv4 unicast as 100
R1(config-router-af)#topology base
R1(config-router-af-topology)#distribute-list 1 in gi1.123
R1(config-router-af-topology)#

Now let’s see the routing table of R1:

! R1's view of R4's prefix:
R1#sh ip route 4.4.4.4
% Network not in table
R1#

We also do not see the prefix in R1’s topology table:

! R1's EIGRP Topology table for 4.4.4.4/32:
R1#sh ip eigrp topology 4.4.4.4/32
EIGRP-IPv4 VR(ccie) Topology Entry for AS(100)/ID(10.0.123.1)
%Entry 4.4.4.4/32 not in topology table
R1#

So we’ve successfully filtered 4.4.4.4/32 using a standard ACL inbound on Gi1.123 on R1.

Note! It is optional to specify the interface on which you receive the update.

Extended ACL

Here we have the ability to specify from which update source we want to filter the prefix. This is specified in the source portion of the ACE (Access List Entry). Let’s say we only want to receive the 4.4.4.4/32 prefix from R2 on R1 using an extended ACL. Here’s what we can do:

! R1 filter using Extended ACL:
R1(config)#access-list 100 deny ip host 10.0.123.3 host 4.4.4.4
R1(config)#access-list 100 permit ip any any
R1(config)#router eigrp ccie
R1(config-router)#address-family ipv4 unicast as 100
R1(config-router-af)#topology base
R1(config-router-af-topology)#distribute-list 100 in
R1(config-router-af-topology)#

Let’s verify R1’s path to 4.4.4.4/32:

! R1's path to 4.4.4.4/32:
R1#sh ip route 4.4.4.4
  Routing entry for 4.4.4.4/32
  Known via "eigrp 100", distance 170, metric 16000, type external
  Redistributing via eigrp 100
  Last update from 10.0.123.2 on GigabitEthernet1.123, 00:02:01 ago
  Routing Descriptor Blocks:
  * 10.0.123.2, from 10.0.123.2, 00:02:01 ago, via GigabitEthernet1.123
      Route metric is 16000, traffic share count is 1
      Total delay is 21 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2
R1#

Just to be sure, let’s also look at the topology table:

! R1's topology table:
R1#sh ip eigrp topology 4.4.4.4/32
EIGRP-IPv4 VR(ccie) Topology Entry for AS(100)/ID(10.0.123.1) for 4.4.4.4/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2048000, RIB is 16000
  Descriptor Blocks:
  10.0.123.2 (GigabitEthernet1.123), from 10.0.123.2, Send flag is 0x0
      Composite metric is (2048000/1392640), route is External
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 21250000 picoseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
        Originating router is 10.0.34.4
      External data:
        AS number of route is 0
        External protocol is Connected, external metric is 0
        Administrator tag is 0 (0x00000000)
R1#

Prefix List

Prefix lists give the ability to not only match on the prefix, but also the mask of the prefix. This an ACL cannot do with IGPs. You can even specify ranges of masks you want to match on using the ge/le (greater than, equal to/less that, equal to) operators. Very powerful and efficient.

! R1 filtering using Prefix List:
R1(config)#ip prefix-list pfxfilter deny 4.0.0.0/8 ge 32
R1(config)#ip prefix-list pfxfilter permit 0.0.0.0/0 le 32
R1(config)#router eigrp ccie
R1(config-router)#address-family ipv4 unicast as 100
R1(config-router-af)#topology base
R1(config-router-af-topology)#distribute-list prefix pfxfilter in gi1.123
R1(config-router-af-topology)#

We can verify the routing table of R1:

! R1's view of R4's prefix:
R1#sh ip route 4.4.4.4
% Network not in table
R1#

In R1’s topology table the prefix is also gone:

! R1's EIGRP Topology table for 4.4.4.4/32:
R1#sh ip eigrp topology 4.4.4.4/32
EIGRP-IPv4 VR(ccie) Topology Entry for AS(100)/ID(10.0.123.1)
%Entry 4.4.4.4/32 not in topology table
R1#

Gateway

I put the gateway option under the Prefix List section, because it requires a prefix list. The gateway option allows you to specify the update source (gateway) from which you receive prefixes. It can be used by itself, or you can also specify a prefix list to limit which  prefixes you want to consider from the gateway list. Let’s have a look assuming we now do not want to receive 4.4.4.4/32 at all and we also do not want to receive anything from R2:

! R1 filter using gateway option:
R1(config)#ip prefix-list R3 permit 10.0.123.3/32
R1(config)#ip prefix-list R4Lo0 deny 4.4.4.4/32
R1(config)#ip prefix-list R4Lo0 permit 0.0.0.0/0 le 32
R1(config)#router eigrp ccie
R1(config-router)# address-family ipv4 unicast autonomous-system 100
R1(config-router-af)# topology base
R1(config-router-af-topology)#distribute-list prefix R4Lo0 gateway R3 in
R1(config-router-af-topology)#

In short we permit anything but 4.4.4.4/32 to be received only from 10.0.123.3/32 (R3). We can look at the routing table before and after the change:

! R1's routing table before change:

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/10880] via 10.0.123.2, 00:00:07, GigabitEthernet1.123
      3.0.0.0/32 is subnetted, 1 subnets
D        3.3.3.3 [90/10880] via 10.0.123.3, 00:00:17, GigabitEthernet1.123
      4.0.0.0/32 is subnetted, 1 subnets
D EX     4.4.4.4 [170/16000] via 10.0.123.3, 00:00:07, GigabitEthernet1.123
                 [170/16000] via 10.0.123.2, 00:00:07, GigabitEthernet1.123
      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
D        10.0.24.0/24 [90/15360] via 10.0.123.2, 00:00:07, GigabitEthernet1.123
D        10.0.34.0/24 [90/15360] via 10.0.123.3, 00:00:17, GigabitEthernet1.123
R1#

And after the change:

! R1's routing table after the change:

R1#sh ip route eigrp | be Gateway
Gateway of last resort is not set

      3.0.0.0/32 is subnetted, 1 subnets
D        3.3.3.3 [90/10880] via 10.0.123.3, 00:01:02, GigabitEthernet1.123
      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
D        10.0.34.0/24 [90/15360] via 10.0.123.3, 00:01:02, GigabitEthernet1.123
R1#

Route Map

Besides filtering using a Route Map matching a prefix list or an ACL, you can also match on metric values (and ranges) and tags. Remember that with Route Maps the ACL or prefix list is just used for matching prefixes, not determine what to do with them. This is up to the Route Map [deny|permit] operators to decide.

Some literature states that once a Route Map has a match, it will not continue evaluating other sequences of the Route Map. I have not been able to see this functionality with the labs I have done. Let’s look at an example with multiple Route Map sequences that are all matched and used. We’re denying 10.0.24.0/24 and 10.0.34/0.24 on R1:

! R1 filter using Route Map and Multiple Sequences:
R1(config)#ip prefix-list net24 permit 10.0.24.0/24
R1(config)#ip prefix-list net34 permit 10.0.34.0/24
R1(config)#route-map manyseq deny 10
R1(config-route-map)#match ip address prefix net24
R1(config-route-map)#route-map manyseq deny 20
R1(config-route-map)#match ip address prefix net34
R1(config-route-map)#route-map manyseq perm 30
R1(config-route-map)#router eigrp ccie
R1(config-router)#address-family ipv4 u as 100
R1(config-router-af)#topology base
R1(config-router-af-topology)#distribute-list route-map manyseq in

Let’s see the result:

! R1's routing table after Route Map filtering:
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/10880] via 10.0.123.2, 00:19:16, GigabitEthernet1.123
      3.0.0.0/32 is subnetted, 1 subnets
D        3.3.3.3 [90/10880] via 10.0.123.3, 00:18:58, GigabitEthernet1.123
      4.0.0.0/32 is subnetted, 1 subnets
D EX     4.4.4.4 [170/16000] via 10.0.123.3, 00:20:03, GigabitEthernet1.123
                 [170/16000] via 10.0.123.2, 00:20:03, GigabitEthernet1.123
R1#

Sure enough, we’ve managed to filter out net24 and net34 using a Route Map with multiple sequences. If you should experience that a Route Map does not continue evaluating the sequences, you can use the keyword ‘continue’ like this:

! Route Map continue:
route-map manyseq deny 10
 match ip address prefix-list net24
 continue 20
route-map manyseq deny 20
 match ip address prefix-list net34
 continue 30
route-map manyseq permit 30

But like I demonstrated above, I did not need the continue configuration.

Distance

EIGRP has the concept of internal and external prefixes – like OSPF. Using the distance command under topology base for EIGRP NM (Named Mode), we have the ability to change the distance – either for all EIGRP prefixes (internal and external) or for a select set of prefixes (internal only!) received from all or some neighbors. We would do this to either prefer using another routing protocol for the same prefix or as a filtering technique for either policies or TE (Traffic Engineering).

If we were to filter all external prefixes on R1 using distance:

! R1 filter all external prefixes:
1(config)#router eigrp ccie
R1(config-router)# address-family ipv4 unicast autonomous-system 100
R1(config-router-af)# topology base
R1(config-router-af-topology)#distance eigrp 90 255

Here the first value is the distance for EIGRP internal prefixes. The second value is for EIGRP external prefixes. An AD (Administrative Distance) of 255 means Unknown (the router does not believe the source of the prefix and will not install it in the routing table).

R1 before the change:

! R1 before changing distance:
R1#sh ip route eigrp | in D_EX
D EX 4.4.4.4 [170/16000] via 10.0.123.2, 00:00:00, GigabitEthernet1.123
R1#

And after the change:

! R1 after distance change:
R1#sh ip route eigrp | in D_EX
R1#

No external prefixes are installed in the routing table, as expected.

What if we wanted to filter 4.4.4.4/32 from R3 using distance? We have the ability to do per neighbor distance by omitting the keyword eigrp when configuring the distance:

! R1 per neighbor distance:
R1(config)#access-list 1 permit 4.4.4.4
R1(config)#router eigrp ccie
R1(config-router)#address-family ipv4 u as 100
R1(config-router-af)#topology base
R1(config-router-af-topology)#distance 255 10.0.123.3 0.0.0.0 1

First we define an ACL that matches the prefix we want to change the distance for. Next under topology base we set the distance to 255 when the prefix is received from a neighbor using a WC (Wild Card) mask if it matches access list 1.

Let’s verify:

! R1 distance verification:
R1#sh ip route | in 4.4.4.4
D EX 4.4.4.4 [170/16000] via 10.0.123.3, 00:00:00, GigabitEthernet1.123
R1#

Why did it not work? Like I said, you can ONLY change distance on prefixes that are internal – NOT external! Let’s inject 4.4.4.4/32 as an internal prefix on R4:

! R4 change to internal prefix:
R4(config)#router eigrp ccie
R4(config-router)#address-family ipv4 u as 100
R4(config-router-af)#network 4.0.0.0

Note! If you have both redistribute connected and a network statement, the latter takes precedence, meaning that now 4.4.4.4/32 is advertised as an internal prefix. Now let’s see if the prefix is still there on R1:

! R1 after change to internal prefix on R4:
Routing entry for 4.4.4.4/32
  Known via "eigrp 100", distance 90, metric 16000, type internal
  Redistributing via eigrp 100
  Last update from 10.0.123.2 on GigabitEthernet1.123, 00:00:16 ago
  Routing Descriptor Blocks:
  * 10.0.123.2, from 10.0.123.2, 00:00:16 ago, via GigabitEthernet1.123
      Route metric is 16000, traffic share count is 1
      Total delay is 21 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2
R1#

Now we only have 4.4.4.4/32 from R2 as we wanted! Excellent.

Hop Count

EIGRP has a built in diameter that works a bit like RIP’s infinite metric which essentially is a hop count of 16. The default maximum hop count with EIGRP is 100, meaning that if a prefix has been advertised through more than 100 routers, it must be discarded. You can use this feature to narrow down your network diameter or use it for filtering.

First we can see the default value like this:

! R1 Default Hop Count:
R1#sh ip protocols | be EIGRP
Routing Protocol is "eigrp 100"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP-IPv4 VR(ccie) Address-Family Protocol for AS(100)
    Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0
    Metric rib-scale 128
    Metric version 64bit
    Soft SIA disabled
    NSF-aware route hold timer is 240
  EIGRP NSF disabled
    NSF signal timer is 20s
    NSF converge timer is 120s
   Router-ID: 10.0.123.1
   Topology : 0 (base)
    Active Timer: 3 min
    Distance: internal 90 external 170
    Maximum path: 4
    Maximum hopcount 100
    Maximum metric variance 1
    Total Prefix Count: 5
    Total Redist Count: 0

  Automatic Summarization: disabled
  Maximum path: 4
  Routing for Networks:
    1.0.0.0
    10.0.123.0/24
  Routing Information Sources:
    Gateway Distance Last Update
    10.0.123.3 90 00:06:22
    10.0.123.2 90 00:06:22
  Distance: internal 90 external 170

R1#

Here we see the “Maximum hopcount 100”. You can tell the hop count for each prefix by looking at the routing table or the topology table:

! R1 routing table for 4.4.4.4/32:
R1#sh ip route 4.4.4.4
Routing entry for 4.4.4.4/32
  Known via "eigrp 100", distance 170, metric 16000, type external
  Redistributing via eigrp 100
  Last update from 10.0.123.3 on GigabitEthernet1.123, 00:16:34 ago
  Routing Descriptor Blocks:
    10.0.123.3, from 10.0.123.3, 00:16:34 ago, via GigabitEthernet1.123
      Route metric is 16000, traffic share count is 1
      Total delay is 21 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2
  * 10.0.123.2, from 10.0.123.2, 00:16:34 ago, via GigabitEthernet1.123
      Route metric is 16000, traffic share count is 1
      Total delay is 21 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2
R1#

And the topology table:

! R1 topology table for 4.4.4.4/32:
R1#sh ip eigrp topology 4.4.4.4/32
EIGRP-IPv4 VR(ccie) Topology Entry for AS(100)/ID(10.0.123.1) for 4.4.4.4/32
  State is Passive, Query origin flag is 1, 2 Successor(s), FD is 2048000, RIB is 16000
  Descriptor Blocks:
  10.0.123.2 (GigabitEthernet1.123), from 10.0.123.2, Send flag is 0x0
      Composite metric is (2048000/1392640), route is External
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 21250000 picoseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
        Originating router is 10.0.34.4
      External data:
        AS number of route is 0
        External protocol is Connected, external metric is 0
        Administrator tag is 0 (0x00000000)
  10.0.123.3 (GigabitEthernet1.123), from 10.0.123.3, Send flag is 0x0
      Composite metric is (2048000/1392640), route is External
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 21250000 picoseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
        Originating router is 10.0.34.4
      External data:
        AS number of route is 0
        External protocol is Connected, external metric is 0
        Administrator tag is 0 (0x00000000)
R1#

Let’s say we want to filter all updates from R4 on R1 using hop count. This should be fairly easy with the topology we have:

! R1 Hop Count:
R1(config)#router eigrp ccie
R1(config-router)#address-family ipv4 u as 100
R1(config-router)#topology base
R1(config-router-af-topology)#metric maximum-hops 1

Note! This will tear down all neighbors!

! R1 Neighbors go down:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.123.3 (GigabitEthernet1.123) is down: Max hopcount changed
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.123.2 (GigabitEthernet1.123) is down: Max hopcount changed
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.123.3 (GigabitEthernet1.123) is up: new adjacency
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.123.2 (GigabitEthernet1.123) is up: new adjacency

Although the hop count is not part of the metric calculation, it is configured in topology base using the metric command, because it is a way of measuring the number of hops.

After the change, we do not see 4.4.4.4/32 in the routing table:

! R1 routing table:
R1#sh ip route 4.4.4.4
% Network not in table
R1#

#