EIGRP fails and shows RTO 5000 after switching on a p2p wireless link

[#1]

Hello guys,

This is a bit confusing but let me see if I can get some help here, probably its worth it.

I have two remote sites that are currently connected through iNET 900 radio links and end devices are Cisco IE-3000-8TC-E switches, EIGRP is running all over the network and no issues at all, problem arise when I switch the WAN link between both sites and direct traffic through a routed port via point 2 point cambium wireless radio. No issues with the communication between these two sites but another site that is connected to ASA with a IPsec VPN tunnel stops pinging to one of the neighbor site of one of these two sites. It doesn't make sense why it stops pinging as all the other items of the network can see one another. We have multiple VPN sites with same config on FW rules that pretty much allow them to see each other with no issues as the FW is wide opened.

One thing I noticed that after switching to p2p cambium wireless the the Show IP EIGRP Neighbour shows (on one of the two sites) that neighbour's RTO is 5000 and Q is more than 0. seems it becomes unidirectional but why we dont know. both site can ping each other with no issues at all and network can reach both sites. I can further share the diagrams of that region if its worth it.

[cofee]

You mentioned that neighbor's RTO is 5000, RTO is typically 6 times the SRTT. Has this neighbor been reset or dropped? Also the possibility is that after the reconfiguration of link that this neighbor can receive multicast packets only intermittently.

[#3]

Resolved-

Hi Cofee,

As I mentioned it was a new link to the neighbors so yes they were up and running before switching to the new wireless link.

Anyway it is resolved, issue found that the ASA did not have route to this subnet that was being used on the new link, it has routes for other subnets to the device so once switched to the new p2p link  ASA had issues to resolve the subnet. Why ASA was not learning it still not sure. Had to add static route to next hop from ASA and beyond to fix it.

Thanks for the comments...