Case Study: Static Route to EIGRP Redistribution

NOTE: Selected command output has been removed for brevity.

I ran into a curious case while testing static route to EIGRP redistribution. Let’s explore what happened.

First things first, R1 and R2 are directly connected over the 10.10.12.0/24 network and EIGRP is enabled between them. 

router eigrp 1  network 10.10.12.0 0.0.0.255

R1#show ip eigrp neighbor EIGRP-IPv4 Neighbors for AS(1) H   Address          Interface      Hold Uptime   SRTT   RTO  Q  Seq                                     (sec)         (ms)       Cnt Num 0   10.10.12.2       Gi0/0            12 00:00:39    2   100  0  1 R2#show ip eigrp neighbor EIGRP-IPv4 Neighbors for AS(1) H   Address          Interface      Hold Uptime   SRTT   RTO  Q  Seq                                     (sec)         (ms)       Cnt Num 0   10.10.12.1       Gi0/1            13 00:00:55    3   100  0  1

Next, let’s create a bogus network on R2 and advertise it to R1. A fake static route 192.168.12.0/24 pointing to the Null0 interface will do.

ip route 192.168.12.0 255.255.255.0 Null0

R2#show ip route static Gateway of last resort is not set S     192.168.12.0/24 is directly connected, Null0

This static route is redistributed into EIGRP.

router eigrp 1  redistribute static

It shows up in R2’s EIGRP topology table.

R2#show ip eigrp topology EIGRP-IPv4 Topology Table for AS(1)/ID(2.2.2.2) P 10.10.12.0/24, 1 successors, FD is 2816         via Connected, GigabitEthernet0/1 P 192.168.12.0/24, 1 successors, FD is 256         via Rstatic (256/0)

There are a couple of things to note here.

First, why was the static route redistributed into EIGRP? This may sound like an odd question, but a metric should have been defined for route redistribution to work. It was not done.

“When you redistribute one protocol into another, remember that the metrics of each protocol play an important role in redistribution. Each protocol uses different metrics. 

When routes are redistributed, you must define a metric that is understandable to the receiving protocol. There are two methods to define metrics when redistributing routes. 

You can define the metric for that specific redistribution only or you can use the same metric as a default for all redistribution.”

Source: Redistributing Routing Protocols

Second, how did the router assign the metric and what values did it use for the EIGRP metric components? My wild guess is that EIGRP has a default metric in newer IOS code versions or this behavior is something specific to static routes/Null0 interface. But honestly, I have no clue.

Upon closer inspection, the following values can be observed for the metric components.

R2#show ip eigrp topology 192.168.12.0/24 EIGRP-IPv4 Topology Entry for AS(1)/ID(2.2.2.2) for 192.168.12.0/24   State is Passive, Query origin flag is 1, 1 Successor(s), FD is 256   Descriptor Blocks:   0.0.0.0, from Rstatic, Send flag is 0x0       Composite metric is (256/0), route is External       Vector metric:         Minimum bandwidth is 10000000 Kbit         Total delay is 0 microseconds         Reliability is 0/255         Load is 0/255         Minimum MTU is 1500         Hop count is 0         Originating router is 2.2.2.2       External data:         AS number of route is 0         External protocol is Static, external metric is 0         Administrator tag is 0 (0x00000000)

As per RFC 7868: 

“The composite metric is based on bandwidth, delay, load, and reliability. MTU is not an attribute for calculating the composite metric, but carried in the vector metrics.

Bandwidth is the lowest interface bandwidth along the path, and delay is the sum of all outbound interface delays along the path. Load and reliability values are expressed percentages with a value of 1 to 255.

Implementation note: Cisco IOS routers display reliability as a fraction of 255.  That is, 255/255 is 100% reliability or a perfectly stable link. Load is a value between 1 and 255. A load of 255/255 indicates a completely saturated link.

Bandwidth is the inverse minimum bandwidth (in kbps) of the path in bits per second scaled by a factor of 10^7.

The delay is the sum of the outgoing interface delay (in tens of microseconds) to the destination. A delay set to its maximum value (hexadecimal 0xFFFFFFFF) indicates that the network is unreachable.”

With this information in mind, pay close attention to load in the previous command output: Load is 0/255. By all logic, zero should not be a valid value.

In fact, if a load of zero is assigned by specifying the metric with the redistribution, the command will not go through. Let’s try to duplicate the original (default) values in the metric command.

R2(config)#router eigrp 1 R2(config-router)#redistribute static metric ?   <1-4294967295>  Bandwidth metric in Kbits per second R2(config-router)#redistribute static metric 10000000 ?   <0-4294967295>  EIGRP delay metric, in 10 microsecond units R2(config-router)#redistribute static metric 10000000 0 ?   <0-255>  EIGRP reliability metric where 255 is 100% reliable R2(config-router)#redistribute static metric 10000000 0 0 ?   <1-255>  EIGRP Effective bandwidth metric (Loading) where 255 is 100% loaded R2(config-router)#redistribute static metric 10000000 0 0 0 ? % Unrecognized command

As you can see, IOS produces an “% Unrecognized command” error message when an invalid value is entered for load. 

Another curious thing to note from the command output is that reliability accepts a value of 0. According to RFC 7868, both load and reliability are expressed percentages with a value of 1 to 255.

If correct values are used, the command goes through.

redistribute static metric 1000 10 1 1 1500

The new metric component values are reflected accordingly.

R2#show ip eigrp topology 192.168.12.0/24 EIGRP-IPv4 Topology Entry for AS(1)/ID(2.2.2.2) for 192.168.12.0/24   State is Passive, Query origin flag is 1, 1 Successor(s), FD is 256   Descriptor Blocks:   0.0.0.0, from Rstatic, Send flag is 0x0       Composite metric is (2562560/0), route is External       Vector metric:         Minimum bandwidth is 1000 Kbit         Total delay is 100 microseconds         Reliability is 1/255         Load is 1/255         Minimum MTU is 1500         Hop count is 0         Originating router is 2.2.2.2       External data:         AS number of route is 0         External protocol is Static, external metric is 0         Administrator tag is 0 (0x00000000)

 

One more interesting point to pay attention to is that the metric command accepts delay as tens of microseconds but the output shows it as microseconds.

If you want more information on the topic, I have discussed static route to EIGRP (and OSPF) redistribution at length in my latest video.