EIGRP Add Path Support

This topic is to discuss the following lesson:

Hi Rene,

Hub(config-router-af-interface)#add-paths <1-4> "Number of add paths to be advertised"
Can you explain more about when we use the number of 1, 2, 3, or 4?
Even though I tested with add-paths of 1-2-3-4, the result’s nothing change.

Spoke1#sho ip route eigrp 
D     192.168.34.0/24 [90/102405120] via 172.16.123.4, 00:01:42, Tunnel0
                      [90/102405120] via 172.16.123.3, 00:01:42, Tunnel0

Hello Dawn

The add-paths is used when you have multiple paths from the hub to a specific network that can be reached via multiple spokes. EIGRP however advertises only one path as the best path to connected spokes. The add-paths command allows EIGRP to advertise up to an additional four. This will only be seen if multiple paths are present to the same network.

For the topology in question:
image
As can be seen, there are two routes to the 192.168.12.0/24 network, via Spoke1 and Spoke2. The hub will have only one route to this network by default. The add-paths command will allow both the Spoke1 and Spoke2 route be added in the routing table.

More information on the add-paths command can also be found at this Cisco documentation.


I hope this has been helpful!

Laz

1 Like

Hi Laz,

Thanks for your kind explanation.
I understood.

IN EIGRP with DMVPN how to change the next hop on SPOKE router for all learned routes from HUB. The end result is all received routes from HUB will need to change its next hop to different IP which is behind the HUB,and when spoke tries to reach other spoke it goes to IP Behind the HUB for next hop and that IP will reroute the traffic back to HUB.As HUB already has the destination path it will forward it out to SPOKE 2.

Hello Kaza

Note that the configuration in this lesson is using DMVPN Phase 2. This means that the routing information found in each spoke contains the IP address of the spoke as the next-hop IP. This is because Phase 2 allows for spoke-to-spoke GRE tunnels.

The hub will never change its next hop to an IP that is “behind” the hub, but it will inform the spokes of the topology of the IP addresses of the other spokes, using NHRP. You can find out more about this in the following lessons:

As for the add path support feature, the only thing the hub will do is to ensure that multiple spoke IP addresses appear as the next hop for particular destinations behind specific spokes. Remember once again, that we have direct spoke to spoke communication, so there is no scenario where traffic will go “behind” the hub router only to be routed back into the DMVPN infrastructure.

I hope this has been helpful!

Laz

If I implement DMVPN PHASE1 with EIGRP, and I need to send traffic VIA HUB but need to send the initial request to device behind the HUB from spoke router and then the request comes back to HUB via static route or some other protocol, then HUB need to send it back to SPOKE2. Is there any concept for this? With BGP I can achieve this, but any way with EIGRP?

Hello Kaza

Even with Phase 1, if Spoke1 wants to send a packet to Spoke2, it would send it to the Hub. The Hub, under normal circumstances, should send it to Spoke2, based on its routing table. Now if you want to route it to some device behind the hub first, then I’m not sure if you could do it using EIGRP. The router, when it receives the packet will use the best path to route it, which would be straight back to Spoke2. In order to obligate the router to send it to some device behind the hub first, you would probably have to use policy-based routing or even VRFs within the hub router, but I’m not sure how that would be affected by the DMVPN configuration.

Can you tell us a little more about what it is you want to achieve and why so that we can further help you in determining the best solution?

I hope this has been helpful!

Laz

I have configured route-map with set statement (NEXT-HOP IP) and applied the policy under the tunnel interface on HUB. Now all traffic between spoke 1 & 2 is forwarded to the uplink device at HUB and will send back to HUB.

The uplink device is a firewall, pushing the traffic from HUB to the firewall and back to HUB for monitoring.

Hello Kaza

Placing a single firewall behind the hub to secure traffic between spokes is indeed one solution. And it is efficient because you’re only using a single firewall for all of your traffic. However, is it the best topology? There are a couple of concerns here:

  1. You are loading the link between the hub and the firewall with double the traffic
  2. Only spoke to spoke traffic is secured. Any traffic from the spoke to other locations (outside the DMVPN realm) is not secured.
  3. If you secure your DMVPN tunnels with IPSec some of the security concerns you may have can be alleviated.

You may want to consider placing a firewall at each spoke (wherever needed) so that the full communication from that location can be filtered. You can place a firewall running NAT at a DMVPN spoke with no problems. You can find out more about that here:

An alternative is also to use a zone-based firewall in the spoke and hub devices, as described here:

I hope this has been helpful!

Laz