Cisco did a major overhaul of EIGRP in recent IOS. These can be loosely looked at as new features in "EIGRP Named Mode". In reality, I suspect that the EIGRP teams were working on a series of new features, and they opted to renovate the interface at the same time, hence creating named mode.
We'll start with the new interface and then delve into all the new features one at a time.
Named EIGRP mode replaces the tradition EIGRP interfaces we're familiar with, and puts all the various commands into one configuration section.
The major distinguishing factor is the router process has a
name instead of a
number.
Old method:
router eigrp 100
network 192.168.0.0 0.0.255.255
New equivalent method:
router eigrp SOMENAME
!
address-family ipv4 unicast autonomous-system 100
!
topology base
exit-af-topology
network 192.168.0.0 0.0.255.255
exit-address-family
The name is completely arbitrary and is a local value.
Interface settings that were previously configured on the interface, such as hello interval, authentication, etc, are now configured as part of the EIGRP named process:
router eigrp SOMENAME
!
address-family ipv4 unicast autonomous-system 100
!
af-interface GigabitEthernet1
authentication mode md5
authentication key-chain FOO
no split-horizon
exit-af-interface
!
topology base
exit-af-topology
network 192.168.0.0 0.0.255.255
exit-address-family
A traditional EIGRP process can be upgraded to named mode on newer IOS with this command:
Router(config)#router eigrp 101
Router(config-router)#eigrp upgrade-cli SOMENAME
The process also doesn't interrupt traffic flow.
That's the guts of the configuration reformatting, let's move on to features.
Wide Metrics
First and foremost, the metric has been reworked.
EIGRP named mode automatically uses wide metrics when speaking to another EIGRP named mode process. No additional configuration is necessary, this is automatic. So if it's speaking to a traditional EIGRP process, it uses the old calculations.
The new metric is designed to be able to differentiate paths above 10GB. The new metric essentially changes four things:
- Delay is now measured in picoseconds instead of microseconds. 10ms was the minimum previously.
- Bandwidth's scaling factor is made much larger, the calculation is now 10^7 * 65536 / Interface Bandwidth, as opposed to the original 10^7 * 256 / Interface Bandwidth.
- The overall metric is now 64 bit.
- The K6 value has been added "for future use", but Cisco has indicated this will be used for accumulated energy or accumulated jitter. Jitter is reasonsably obvious. Energy is the actual electric power it takes to use an interface, so that you could literally do "least cost" routing based on how inexpensively the packet can be sent from the various interface types in a path.
One important note here is that with wide metrics, the EIGRP calculated metric no longer fits into the RIB. For example:
Router#sh ip eigrp top 10.10.10.10/32 | i Composite metric
Composite metric is (330301440/329646080), route is Internal
Router#sh ip route 10.10.10.10 | i Route metric
Route metric is 2580480, traffic share count is 1
The EIGRP topology table indicates 330301440, the RIB says 2580480.
The RIB's metric can't exceed 32-bits, and there are circumstances with the new, more granular metrics won't fit into the RIB. So all metrics, regardless of if the value would fit into 32-bits, are divided by the rib-scale value. The rib-scale is 128 by default:
330301440/128 = 2580480
You can reassign it to any value 1 to 255:
router eigrp SOMENAME
address-family ipv4 unicast autonomous-system 100
metric rib-scale [1-255]
Here's a catch - I've gotten in the habit of using this command for redistributing into EIGRP when labbing:
redistribute <some other protocol> metric 1 1 1 1 1
Why? It's quick and easy to type if you're not trying to do traffic engineering.
Router#sh ip eigrp top 13.13.13.13/32 | i Composite metric
Composite metric is (655361310720/655360655360), route is External
655361310720/128 = 5120005120
The largest number that can be represented in a 32-bit unsigned integer is 4,294,967,296.
5120005120 > 4294967296, therefore it cannot be represented in the RIB:
Router#sh ip route 13.13.13.13
% Network not in table
You read that right: This is a valid, routable prefix that simply can't make it into the RIB because of compatibility between the EIGRP topology table and the RIB. You need to adjust the rib-scale to make this work:
Router(config-router-af)#metric rib-scale 153
Router(config-router-af)#do sh ip route 13.13.13.13 | i Route metric
Route metric is 4283407259, traffic share count is 1
I imagine that would make for a really good troubleshooting problem. "A route is being redistributed on R1 with a specific metric, but is not being installed in the RIB on R3. Do not change the metric on R1, or adjust with a route-map".
There are a few concerns with interoperability between the traditional EIGRP metric and the wide metrics, but not many. As I mentioned above, routers unable to understand wide metrics are auto-detected and sent the old metric, however, there are circumstances where a route might get depreffed after having passed through an older EIGRP process. For example, if two paths exist to a destination, one of them running entirely wide metrics and a different one running one router with traditional metrics, the traditional metric may make the entire path look worse and it may impact load share, or the ability to ECMP.
SHA Authentication
Now supporting more than just MD5:
R1(config-subif)#router eigrp TEST1
R1(config-router)#address-family ipv4 unicast autonomous-system 100
R1(config-router-af)#af-interface gig1.123
R1(config-router-af-interface)#authentication mode hmac-sha-256 CCIE
I think authentication would also make a great TS question - the authentication could be placed on the interface still, which named mode silently ignores. You'd need to know to look at the EIGRP named process to fix it:
interface GigabitEthernet1.123
ip authentication key-chain eigrp 100 BOB ! this does nothing when named mode is enabled.
Route Tag Enhancements
To be fair, the route tag enhancements aren't limited to EIGRP named mode - it works with OSPF, BGP, RIP, etc. It even works in the traditional (non-named) eigrp syntax. However, I didn't think I needed a write a separate blog just to show it in every context, they all basically work the same.
In short, the route tag enhancements allow the route tag to be formatted as a dotted decimal tag (looks like an IPv4 address) that can me matched either directly (in the traditional route tag method in route-map) or via a route-tag list. The route-tag list is where things get interesting.
R1:
interface Loopback1
ip address 1.1.1.1 255.255.255.255
interface Loopback2
ip address 2.2.2.2 255.255.255.255
interface Loopback3
ip address 3.3.3.3 255.255.255.255
interface Loopback4
ip address 4.4.4.4 255.255.255.255
interface Loopback5
ip address 5.5.5.5 255.255.255.255
interface Loopback6
ip address 6.6.6.6 255.255.255.255
interface Loopback7
ip address 7.7.7.7 255.255.255.255
route-tag notation dotted-decimal
router eigrp TEST1
!
address-family ipv4 unicast autonomous-system 100
!
topology base
redistribute connected route-map tag-routes
route-map tag-routes permit 10
match interface Loopback1 Loopback2 Loopback3
set tag 100.100.100.1
route-map tag-routes permit 20
match interface Loopback4 Loopback5
set tag 100.100.200.1
route-map tag-routes permit 30
match interface Loopback6 Loopback7
set tag 100.100.101.1
So we've set some dotted-decimal tags on R1, now let's filter on R2.
R2:
route-tag notation dotted-decimal
route-tag list binary-match seq 5 permit 100.100.0.0 0.0.254.255
route-map filter permit 10
match tag list binary-match
set metric 100 100 255 1 1500
route-map filter permit 20
router eigrp TEST2
!
address-family ipv4 unicast autonomous-system 100
!
topology base
distribute-list route-map filter in GigabitEthernet1.123
Anyone who's done any amount of CCIE-level route filtering should catch what I just did. The route-tag list is looking for any routes that begin with 100.100 and have an even 3rd octet - if you need an explanation of filtering with wildcard masks there are many available on the Internet.
So now tags can be matched based on what bits are set in them -- very cool.
R2(config)#do sh ip eigrp top 1.1.1.1/32 | i Composite metric
Composite metric is (6619136000/163840), route is External
R2(config)#do sh ip eigrp top 4.4.4.4/32 | i Composite metric
Composite metric is (6619136000/163840), route is External
R2(config)#do sh ip eigrp top 6.6.6.6/32 | i Composite metric
Composite metric is (1392640/163840), route is External
1.1.1.1 and 4.4.4.4 were tagged with 100.100.100.1 and 100.100.200.1 respectively, both even 3rd octets, and had their metric successfully recreated. 6.6.6.6, tagged with 100.100.101.1, was not matched, and retained its original metric.
I immediately tried this in IPv6... however...
R2(config-router)#address-family ipv6 unicast autonomous-system 200
R2(config-router-af)#topology base
R2(config-router-af-topology)#distribute-list ?
prefix-list Filter connections based on an IPv6 prefix-list
R2(config-router-af-topology)#distribute-list route-map ?
% Unrecognized command
IPv6 can't be filtered ingress with route-maps yet. I didn't expect that. For anyone curious I'm on:
R2(config-router-af-topology)#do sh ver | i IOS Software
Cisco IOS Software, CSR1000V Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 15.4(1)S1, RELEASE SOFTWARE (fc2)
There's open more option for settings tags:
router eigrp TEST1
address-family ipv4 unicast autonomous-system 100
eigrp default-route-tag 9.9.9.9
default-route-tag is fairly picky what it will tag. From some tinkering, it will tag all routes except:
- Locally redistributed routes
- Routes that were already set a tag in some other fashion
- Routes it learned from another router
So in short, unless you learned the routes with the "network" statement, this tag won't take effect.
IPv6 VRF Lite
The traditional EIGRP process doesn't support IPv6 in a VRF.
You also must use the new format - multiprotocol VRF - for creating VRFs.
Old format:
R2(config)#ip vrf FOO
R2(config-vrf)#rd 1:1
R2(config)#int gig1.10
R2(config-subif)#ip vrf forwarding FOO
Multiprotocol VRF:
R2(config-vrf)#vrf definition FOO
R2(config-vrf)#rd 1:1
R2(config-vrf)#address-family ipv6 unicast
R2(config-vrf-af)#address-family ipv4 unicast
R2(config-vrf)#int gig1.10
R2(config-subif)#vrf forwarding FOO
router eigrp SAMPLE
!
address-family ipv6 unicast vrf FOO autonomous-system 200
!
topology base
exit-af-topology
eigrp router-id 2.2.2.2
exit-address-family
Note the bolded line - eigrp router-id 2.2.2.2. Unless you have an IPv4 address in the routing table of the same VRF, you must specify the router ID manually. There is no parser error, it just doesn't work. Once again, this would make a great TS problem.
With IPv6, things work differently than IPv4 in named EIGRP mode. This process is already up:
*Sep 2 23:39:52.815: %DUAL-5-NBRCHANGE: EIGRP-IPv6 200: Neighbor FE80::20C:29FF:FEF7:FE11 (GigabitEthernet1.10) is up: new adjacency
However, note I haven't told it what interfaces to use. In our case, it automatically includes any interface that's in the appropriate VRF and has an IPv6 address on it. If you don't want to run EIGRP on an interface, you have to manually specify:
R2(config)#router eigrp SAMPLE
R2(config-router-af)#address-family ipv6 unicast vrf FOO autonomous-system 200
R2(config-router-af)#af-interface gig1.10
R2(config-router-af-interface)#shut
*Sep 2 23:47:10.304: %DUAL-5-NBRCHANGE: EIGRP-IPv6 200: Neighbor FE80::20C:29FF:FED7:2458 (GigabitEthernet1.10) is down: interface down
3rd party Next-Hop
While also not a feature specific to named mode, EIGRP has recently started supporting 3rd party next hop. The concept of 3rd party next-hop is fairly simple. The easiest way I can explain it is if you have three routers on a single segment, R1, R2, and R3. They all share the 192.168.123.0/24 space between them. However, R1 and R2 speak EIGRP, and R2 and R3 speak OSPF. R1 doesn't speak OSPF, and R3 doesn't speak EIGRP. Assume there are extra routers behind R1 and R3 on different segments that are advertised in their respective routing protocols.
R2 is mutually redistributing between EIGRP and OSPF.
Without 3rd party next-hop, R1 would have to send traffic destined for the OSPF segments to R2, then R2 would have to forward it to R3. Inefficient and messy.
With 3rd party next-hop, R2 is permitted to use R3's address, even though it doesn't exist in the EIGRP process, when advertising routes to R1.
This is an automatic feature and requires only that R2 doesn't re-write the next-hop to itself (rewriting the next hop is default EIGRP behavior):
router eigrp TEST2
!
address-family ipv4 unicast autonomous-system 100
!
af-interface GigabitEthernet1.123
no next-hop-self
EIGRP Fast ReRoute (FRR)
The point of FRR is to generate Loop Free Alternates, or LFAs. What's an LFA?
An LFA is a back-up route that can be pre-programmed into the FIB as a repair route. If you're familiar with EIGRP, you might think "but EIGRP already has feasible successors". True, but it doesn't program those into the forwarding linecards.
I wrote a rather lengthy article regarding BGP PIC and Add-Path two weeks ago, and I covered the problem that PIC was trying to solve, which is not necessarily easy to comprehend unless you've spent a great deal of time in a large service provider environment. PIC and FRR are trying to solve the same issue with different protocols. Rather than pasting the multi-page explanation I've already typed into this document as well, please reference that one to understand the issue:
The good news is that EIGRP doesn't require as complex an environment to explain FRR as it took to explain BGP PIC.
We already know EIGRP makes feasible successors, and can rely on those during reconvergence. But if we want the FIB to be able to swap over to a feasible successor as soon as the successor route is lost, we need to pre-program it.
In a nutshell, FRR simply picks the "best" feasible successor and sticks it in the FIB as a backup route.
There are two types of FRR, per-link and per-prefix. Per-link is only supported on IOS-XR at the time of this writing, so we'll be looking only at per-prefix.
First and foremost, we must ensure we have a feasible successor. If we have multiple successors (no feasibles), then we have ECMP - equal cost multi-path - and there's no need for FRR.
R1 has two paths to prefix 4.4.4.4 on R4, one via R2 and another via R3. I've deliberately de-prefed the route through R3. Note, if you're attempting to lab along with this, you'll want to create the depref on R1. If you're ECMP up until you create the depref on R1, you're guaranteed to have a feasible successor!
R1(config-subif)#int gig1.13
R1(config-subif)#delay 5000
R1#sh ip eigrp topo 4.4.4.4/32
EIGRP-IPv4 VR(TEST) Topology Entry for AS(100)/ID(192.168.12.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:
192.168.12.2 (GigabitEthernet1.12), from 192.168.12.2, Send flag is 0x0
Composite metric is (2048000/1392640), route is Internal
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 192.168.24.4
192.168.13.3 (GigabitEthernet1.13), from 192.168.13.3, Send flag is 0x0
Composite metric is (3278192640/1392640), route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 50011250000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Originating router is 192.168.24.4
Since the route via 192.168.13.3 (from R3) has an advertised distance less than the feasible distance to 192.168.12.2 (from R2), we now have a feasible successor.
R1(config)#router eigrp TEST
R1(config-router)# address-family ipv4 unicast autonomous-system 100
R1(config-router-af)# topology base
R1(config-router-af-topology)#fast-reroute per-prefix all
R1#sh ip route 4.4.4.4 | i Repair
Repair Path: 192.168.13.3, via GigabitEthernet1.13
R1#sh ip cef 4.4.4.4
4.4.4.4/32
nexthop 192.168.12.2 GigabitEthernet1.12
repair: attached-nexthop 192.168.13.3 GigabitEthernet1.13
It's very simple if we only have two paths, but what if there are 3 or more? Cisco uses what it calls "tie breakers", but I really dislike the name, we're not really tie-breaking necessarily because the criteria for selection isn't comparing apples to apples. It's a bit more like "2nd bestpath decision maker".
Before I list off the tie-breakers, let's look at what the problems might be if we had numerous paths to choose from.
Let's say we have multiple neighbors on a shared segment, with varying metrics to the destination we're trying to protect. Your bestpath is on that segment, as is your "second best" feasible successor, all hanging off the same interface on your router. If you're choosing the LFA purely based on metric, the same interface will get chosen for the backup path as is the primary route. That doesn't help us if that WAN link fails, or if the interface goes down, etc.
Take that one step further and say your best-path and best feasible successor are both on the same linecard. That might also be a poor decision.
What I'm getting at is there's more to consider than just the metric in this scenario.
The four tie-breakers are:
- srlg-disjoint, priority 10
- interface-disjoint, priority 20
- lowest-backup-path-metric, priority 30
- linecard-disjoint, priority 40
Lower priority is better.
srlg-disjoint favors a backup-path/interface that isn't in the same Shared Risk Link Group (more below).
interface-disjoint favors a backup route that doesn't share the same interface for its next-hop. BEWARE, sub-interfaces are considered disjointed interfaces by the FRR process on my version of IOS-XE!
lowest-backup-path-metric favors a backup route with the lowest metric.
linecard-disjoint favors a backup route that doesn't share the same linecard.
So to clarify, by default, SRLG gets priority unless not set, then interface-disjoint gets priority unless the two paths are already on different interfaces (or subinterfaces), then the lowest metric is picked. If the metric is the same, it looks for a port on a different linecard.
So to start, what the heck is SRLG?
There's very little information on this feature that I can find, but the idea, as best I can tell, is that if you happen to know to physical links share some dependency (perhaps passing through the same L2 switch upstream, for example), you can tell IOS which ones have dependencies.
For example, if Gig1 and Gig2 on my router both passed through a single point of failure upstream, my config might look something like this:
R1(config)#int gig1
R1(config-if)#srlg gid 1
R1(config-if)#int gig2
R1(config-if)#srlg gid 1
R1(config-if)#int gig3
R1(config-if)#srlg gid 2
Note gig3 didn't necessarily need to get assigned to an srlg, but I included it for clarity.
I'm going to introduce a new path from R1 to R4 via R5. R1, R2 and R5 are all going to share a common link, meaning R1 routes to R2 and R5 on the same interface. I'm increasing delay slightly more on the path to R5. Furthermore, I'm going to prevent R2 and R5 from peering with one another, otherwise R5 would end up only advertising it's bestpath from R2, and my topology breaks.
R1#sh ip eigrp top 4.4.4.4/32 | i Composite metric
Composite metric is (78725120/13189120), route is Internal
Composite metric is (3289989120/13189120), route is Internal
Composite metric is (79380480/13844480), route is Internal
We see we've got three paths, let's look at those again with my comments:
R1#sh ip eigrp top 4.4.4.4/32 | i Composite metric
Composite metric is (78725120/13189120), route is Internal = Path through gig1.12 via R2
Composite metric is (3289989120/13189120), route is Internal = Path through gig1.12 via R5
Composite metric is (79380480/13844480), route is Internal = Path through gig1.13 via R3
R1#sh ip cef 4.4.4.4
4.4.4.4/32
nexthop 192.168.12.2 GigabitEthernet1.12
repair: attached-nexthop 192.168.13.3 GigabitEthernet1.13
We can see IOS made a very smart move here, and it's in line with the priorities we discussed above. The backup path is not the best feasible successor from a metric standpoint, it's the less risky separate "interface" (again, IOS considers a subinterface a separate interface).
If we instead wanted it to choose based on metric:
R1(config)#router eigrp TEST
R1(config-router)# address-family ipv4 unicast autonomous-system 100
R1(config-router-af)# topology base
R1(config-router-af-topology)#fast-reroute tie-break lowest-backup-path-metric 5
<<note I normally clear the eigrp neighbors here, these commands don't always seem to react quickly after the change>>
R1(config-router-af-topology)#do sh ip cef 4.4.4.4
4.4.4.4/32
nexthop 192.168.12.2 GigabitEthernet1.12
repair: attached-nexthop 192.168.12.5 GigabitEthernet1.12
Now we're preferring the backup path through the same interface, that has the better metric.
I'm not going to show the output from srlg disjoint here, but I have labbed it previously and it does work - just set the srlg guid on the appropriate interfaces. Also, I have no way of labbing linecard disjoint because I'm on a virtual router.
EIGRP Over The Top (OTP)
Does anyone besides me use the OTP abbreviation to mean "on the phone"? I wish they could've gone with OTT instead.
It is a really neat feature though - I know a lot of people will bash EIGRP as obsolete, proprietary, distance vector ... say what you will, amongst enterprise Cisco enterprise networks, it's the most popular IGP on the Cisco-powered market by a landslide. As a consultant, I would say 80% of the networks I come across run it.
Furthermore, finding enterprise network support personnel that are BGP experts is somewhat rare.
So what is one to do when MPLS separates all your sites, and your carrier (wisely) uses BGP as a PE->CE protocol? You hire a consultant to come in and make changes to the redistribution strategy periodically.
Or... you run EIGRP OTP, and toss the BGP work out the window.
OTP allows remote EIGRP peerings over any underlying IP protocol. All you need is reachability to the other EIGRP host. That means all your carrier needs to do is advertise the PE->CE link itself (probably a /30 between you and the carrier) in their MPBGP and
the CE doesnt even need to run BGP (topology dependent). All the CE needs is a static default pointing at the PE router.
If you have more than a few CEs, you'll probably want an EIGRP Route Reflector, which isn't nearly as complicated as it sounds. An EIGRP RR listens for dynamic connections (optionally), and then disables split horizon and next-hop-self.
LISP provides the tunneling mechanism for the neighbors to reach one another. Fortunately, no LISP knowledge is required, the config is automatic.
Here, R2 - R5 represent the provider network, R1 and R7 represent isolated customer sites, and R6 and R8 represent a dual-homed customer site.
R7 will be our EIGRP route reflector.
Assume the provider is advertising the links between the CE and PE.
Here are the rest of the relevant configs:
R1:
router eigrp OTP-TEST
!
address-family ipv4 unicast autonomous-system 100
!
topology base
exit-af-topology
neighbor 192.168.37.7 GigabitEthernet1.12 remote 10 lisp-encap
network 1.1.1.1 0.0.0.0
network 192.168.12.0
exit-address-family
ip route 0.0.0.0 0.0.0.0 192.168.12.2
just to prove there's no BGP involved here:
R1#sh ip protocol sum
Index Process Name
0 connected
1 static
2 application
4 eigrp 100
*** IP Routing is NSF aware ***
R6:
router eigrp OTP-TEST
!
address-family ipv4 unicast autonomous-system 100
!
topology base
exit-af-topology
neighbor 192.168.37.7 GigabitEthernet1.46 remote 10 lisp-encap
network 6.6.6.6 0.0.0.0
network 192.168.46.0
network 192.168.68.0
exit-address-family
R8:
router eigrp OTP-TEST
!
address-family ipv4 unicast autonomous-system 100
!
topology base
exit-af-topology
neighbor 192.168.37.7 GigabitEthernet1.58 remote 10 lisp-encap
network 8.8.8.8 0.0.0.0
network 192.168.58.0
network 192.168.68.0
exit-address-family
R7 (route reflector):
router eigrp OTP-TEST
!
address-family ipv4 unicast autonomous-system 100
!
af-interface GigabitEthernet1.37
no next-hop-self
no split-horizon
exit-af-interface
!
topology base
exit-af-topology
remote-neighbors source GigabitEthernet1.37 unicast-listen lisp-encap
network 7.7.7.7 0.0.0.0
network 192.168.37.0
exit-address-family
The route reflector is also running BGP. Route reflectors can have a topology problem requiring this if you have backdoor links. In my case, if I only ran a default on the route reflector, I'd learn the link to R8 via EIGRP from R6, as opposed to using my default route. And vice-versa, R8 would advertise connectivity to R6, and my routes would do a continual up/down because they'd learn next-hops via the LISP interface. It's a typical tunnel recursion loop issue. Running BGP puts the prefixes to reach R6 and R8 in R7's table at a lower AD and solves the problem
Also note that the link between PE and CE must be advertised into EIGRP in order for LISP to come up.
Now we have full reachability to the EIGRP prefixes without the majority of the CEs running BGP, and none of the CEs advertising their EIGRP routes into it.
R1#sh ip route eigrp | b Gateway
Gateway of last resort is 192.168.12.2 to network 0.0.0.0
6.0.0.0/32 is subnetted, 1 subnets
D 6.6.6.6 [90/93994331] via 192.168.46.6, 00:06:34, LISP0
7.0.0.0/32 is subnetted, 1 subnets
D 7.7.7.7 [90/93994331] via 192.168.37.7, 00:06:35, LISP0
8.0.0.0/32 is subnetted, 1 subnets
D 8.8.8.8 [90/93994331] via 192.168.58.8, 00:06:34, LISP0
D 192.168.68.0/24 [90/93998811] via 192.168.46.6, 00:06:34, LISP0
R1#sh ip cef 6.6.6.6
6.6.6.6/32
nexthop 192.168.46.6 LISP0
R1#ping 6.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
Add-Path
Add-Path is the capability to advertise more than one bestpath to a neighbor. I've done a large write-up on the BGP implementation of it:
The Cisco documentation indicates a use case of DMVPN for EIGRP Add-Path, but that seems a pretty narrow use to me, as summarization with DMVPN phase 3 would make it useless. However, our scenario for OTP above is perfect!
R1#sh ip route eigrp | b Gateway
Gateway of last resort is 192.168.12.2 to network 0.0.0.0
6.0.0.0/32 is subnetted, 1 subnets
D 6.6.6.6 [90/93994331] via 192.168.46.6, 00:06:34, LISP0
7.0.0.0/32 is subnetted, 1 subnets
D 7.7.7.7 [90/93994331] via 192.168.37.7, 00:06:35, LISP0
8.0.0.0/32 is subnetted, 1 subnets
D 8.8.8.8 [90/93994331] via 192.168.58.8, 00:06:34, LISP0
D 192.168.68.0/24 [90/93998811] via 192.168.46.6, 00:06:34, LISP0
R1 only learns one path to 192.168.68.0/24. Two are available, why can't we install both? Same problem with BGP, the EIGRP route reflector only sends its one best-path.
R7(config)#router eigrp OTP-TEST
R7(config-router)# address-family ipv4 unicast autonomous-system 100
R7(config-router-af)# af-interface GigabitEthernet1.37
R7(config-router-af-interface)#add-paths 2
R1#sh ip route eigrp | b Gateway
Gateway of last resort is 192.168.12.2 to network 0.0.0.0
6.0.0.0/32 is subnetted, 1 subnets
D 6.6.6.6 [90/93994331] via 192.168.46.6, 00:12:51, LISP0
7.0.0.0/32 is subnetted, 1 subnets
D 7.7.7.7 [90/93994331] via 192.168.37.7, 00:12:52, LISP0
8.0.0.0/32 is subnetted, 1 subnets
D 8.8.8.8 [90/93994331] via 192.168.58.8, 00:12:51, LISP0
D 192.168.68.0/24 [90/93998811] via 192.168.58.8, 00:00:26, LISP0
[90/93998811] via 192.168.46.6, 00:00:26, LISP0
And we've got multiple redundant paths to 192.168.68.0/24 now!
Note, EIGRP add-path is incompatible with variance.
Hope you enjoyed,
Jeff
