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.
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.
This static route is redistributed into EIGRP.
It shows up in R2’s EIGRP topology table.
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.
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.
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.
The new metric component values are reflected accordingly.
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.