Refer to the exhibit. The Los Angeles and New York routers are receiving routers from Chicago but not from each other.
Which configuration fixes the issue?
Refer to the exhibit. The Los Angeles and New York routers are receiving routers from Chicago but not from each other.
Which configuration fixes the issue?
In the given network topology, the Chicago router is acting as the hub in a DMVPN (Dynamic Multipoint Virtual Private Network) setup with Los Angeles and New York routers as spokes. The issue arises because the routers at the Los Angeles and New York spokes are not receiving route advertisements from each other, only from the hub. In EIGRP, split horizon is a rule that prevents a router from advertising a route back out the interface on which it was learned. This rule is blocking the Chicago router from advertising routes it learned from Los Angeles to New York and vice versa. To resolve this issue, split horizon must be disabled on the hub router's tunnel interface. Thus, the correct configuration to fix this problem is to use the 'no ip split-horizon eigrp' command on the Tunnel1 interface of the Chicago router. This will allow route advertisements to be sent back out the same interface they were received on, enabling the spokes to learn routes from each other through the hub.
The given answer is correct - A Its important here to work out that Chicago is the Hub router in a DMVWN network. If Chicago was a spoke it would need a mapping to the hub - and that is not in the output - ie "ip nhrp map" command with relevant tunnel and WAN ip addresses ip addresses for the hub. The hub over its tunnel1 interface learns the routes from LA - it wants to advertise the LA routes to New York - but those advertisements would be back out Tunnel1 - split horizon will not allow this. Split horizon does not allow advertising routes back out the interface a router received them on. So the fix is to disable split horizon - a valid fix in certain scenarios. Note this is a phase 2 DMVPN solution In Phase 2, the Hub is still the “hub” for the control plane. All routes are learned through the hub. Spokes cannot exchange routes with each other directly. A phase 3 DMVPN solution does not have this split horizon issue.
great explanation
I checked phase 3 eigrp in gns3. Even in phase 3 no ip split-horizon rule is required on hub
Suggested Answer A is correct. @Surfside92: Hi I checked DMVPN-Ph3 topology in gns3, even here "no ip split-horizon eigrp <as>" config is required on the HUB site tunnel interface.
A is correct
A is correct
As Surfside92 is saying Chicago is the HUB spoke, cause of the split horizon rule of eigrp you cannot advertise a prefix that you received in the same interface, so for disabling that we need to disable the split horizon rule
Can anybody give an explanation why A is the answer?
n this topology, Chicago router (Hub) will receive advertisements from Los Angeles (Spoke1) router on its tunnel interface. The problem here is that it also has a connection with New York (Spoke2) on that same tunnel interface. If we don’t disable EIGRP split-horizon, then the Hub will not relay routes from Spoke1 to Spoke2 and the other way around. That is because it received those routes on interface Tunnel1 and therefore it cannot advertise back out that same interface (splithorizon rule). Therefore we must disable split-horizon on the Hub router to make sure the Spokes know about each other.