EIGRP Offset-list is usually used to increase the metric of routes being advertised over a link, but can it be used to filter EIGRP prefixes?
I thought about using offset-list in RIP to filter specific routes and thought how about doing the same thing in EIGRP? I haven’t run into any examples or blog posts of using Offset-list in EIGRP to filter routes so I thought about labing it out to see if that’s possible.
To test it, I went to the handy GNS3 with the following topology.
Three routes R1, R2 and R3. R1 advertises a Loopback0 subnet 10.1.1.1/32 which I will use to test filtering using offset-list. As you can see in the diagram, I changed the Delay for each interface to 1 just to make things easier for metric calculation (including loop0 interface). I also set the EIGRP metric weight to only consider delay and not to look at bandwidth for metric calculation, again to make things easier.
My goal is to set an offset-list on R2 to filter routes to R3 using Delay and offset-list commands only. Theoretically, if I know the max metric of EIGRP routes and I apply an offset-list with max metric to select routes (in my case 10.1.1.1/32), I should be able to filter them. In RIP, if you set metric of 15 for the offset-list to specific routes, those routes will not be considered as valid on the next hop router.
First question is what is the EIGRP max metric? It appears that MAX metric is 4,294,967,295.
Next question, what is the max offset-list value we can apply to EIGRP routes? This is a quick easy way to check:
R2(config)#router eigrp 10 R2(config-router)#offset-list 10 out ? <0-2147483647> Offset
… and it’s 2,147,483,647. Looks like we can’t offset routes by max metric value but only by its half (4,294,967,295 – 2,147,483,647 = 2,147,483,648). Based on that calculation, we still need to somehow add 2,147,483,648 to those routes to invalidate them. One way to do that would be to modify the cost of R3.Fa0/0 link’s delay value. Before we do that, let’s look at the base config first.
R1 relevant configuration:
R1#sh run | s router eigrp router eigrp 10 network 0.0.0.0 metric weights 0 0 0 1 0 0 interface Loopback0 ip address 10.1.1.1 255.255.255.255 delay 1 interface FastEthernet0/0 ip address 10.1.12.1 255.255.255.0 delay 1
R2’s Relevant configuration:
R2#sh run | s router eigrp router eigrp 10 network 0.0.0.0 metric weights 0 0 0 1 0 0 no auto-summary interface FastEthernet0/0 ip address 10.1.12.2 255.255.255.0 delay 1 interface FastEthernet0/1 ip address 10.1.23.2 255.255.255.0 delay 1
R3’s Relevant configuration:
router eigrp 10 network 0.0.0.0 metric weights 0 0 0 1 0 0 no auto-summary interface FastEthernet0/0 ip address 10.1.23.3 255.255.255.0 delay 1
First, lets verify normal operation.
R2 gets the loopback network (10.1.1.1/32) with the metric of 512:
R2#sh ip eigrp topology 10.1.1.1/32 IP-EIGRP (AS 10): Topology entry for 10.1.1.1/32 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 512 Routing Descriptor Blocks: 10.1.12.1 (FastEthernet0/0), from 10.1.12.1, Send flag is 0x0 Composite metric is (512/256), Route is Internal Vector metric: Minimum bandwidth is 10000 Kbit Total delay is 20 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 1
R3 gets the loopback address with the metric of 768:
R3#sh ip eigrp topology 10.1.1.1/32 IP-EIGRP (AS 10): Topology entry for 10.1.1.1/32 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 768 Routing Descriptor Blocks: 10.1.23.2 (FastEthernet0/0), from 10.1.23.2, Send flag is 0x0 Composite metric is (768/512), Route is Internal <----768 Vector metric: Minimum bandwidth is 10000 Kbit Total delay is 30 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 2
R3#sh ip route Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks D 10.1.12.0/24 [90/512] via 10.1.23.2, 00:35:59, FastEthernet0/0 D 10.1.20.20/32 [90/128512] via 10.1.23.2, 00:35:59, FastEthernet0/0 D 10.1.1.1/32 [90/768] via 10.1.23.2, 00:35:59, FastEthernet0/0 C 10.1.23.0/24 is directly connected, FastEthernet0/0
Everything looks good. Let me apply the max offset-list value on R2.
R2(config)#access-list 10 permit 10.1.1.1 0.0.0.0 R2(config)#router eigrp 10 R2(config-router)#offset-list 10 out 2147483647 fa0/1
This is how the routing table looks now. You can see that the cost of the 10.1.1.1/32 route has increased significantly by 2,147,483,647, which is the value of the offset list, just as expected.
R3#sh ip route eigrp 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks D 10.1.12.0/24 [90/512] via 10.1.23.2, 2d00h, FastEthernet0/0 D 10.1.20.20/32 [90/128512] via 10.1.23.2, 2d00h, FastEthernet0/0 D 10.1.1.1/32 [90/2147484160] via 10.1.23.2, 1d23h, FastEthernet0/0
Now all we need to do is to figure out how to modify 10.1.1.1/32 route to get a metric of 4,294,967,295 (the invalid metric for EIGRP or infinity, as mentioned earlier). We can do so by modifying the delay of R3’s Fa0/0 interface. This number has to be large enough to invalidate the 10.1.1.1/32 route and but not too high to invalidate all other routes.
To calculate that delay, we’ll need to use a formula that sums the path to InfinityMetric to derive the DLY value on R3.
PreviousRouterMetric + OffsetMetric + (DLY * 256) = InfinityMetric
PreviousRouterMetric = R2's forwarding distance which is 512
OffsetMetric = 2,147,483,647 applied on R2
InfinityMetric = 4,294,967,295
(DLY * 256) = delay in 10s of microseconds
Therefore the calculation would look like:
512 + 2,147,483,647 + (DLY * 256) = 4,294,967,295
DLY = 8,388,606
The DLY on R3’s interface Fa0/0 should be set to 8,388,606, but things don’t always turn out so easily. If you use that DLY value, the prefix 10.1.1.1/32 will not be filtered and will still be considered valid. There seems to me some sort of rounding or calculation order difference where my answer is off by 10 microseconds. Therefore if you add +1 to the DLY (in my notation for DLY.int) things will work and EIGRP off-set lists are demonstrated to be used as a filtering mechanisms for EIGRP.
DLY.int = 8,388,606 + 1
R3#sh ip eigrp topology 10.1.1.1/32 EIGRP-IPv4 Topology Entry for AS(10)/ID(10.1.23.3) for 10.1.1.1/32 State is Passive, Query origin flag is 1, 0 Successor(s), FD is Infinity Descriptor Blocks: 10.1.23.2 (FastEthernet1/0), from 10.1.23.2, Send flag is 0x0 Composite metric is (4294967295/2147483904), route is Internal Vector metric: Minimum bandwidth is 100000 Kbit Total delay is 167772169 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 2 Originating router is 10.1.1.1
R3#sh ip route 10.1.1.1 % Subnet not in table
Notice that the new composite metric is now set to the infinity value, which is the highest 32 bit number. The prefix 10.1.1.1 is not present in the routing table, only EIGRP topology table.
One question you might ask is where would you use it? I don’t think you’ll use this in a production networks, but this might be a really slick solution for some difficult CCIE type scenario.