09-25-2008 07:03 PM - edited 03-03-2019 11:42 PM
I have a spoke router which is behind a NAT connected via VPN tunnel to a hub router (which is working fine) and I am running EIGRP across the tunnel interface. My problem is that I am only receiveing little more than a hundred routes on the spoke router when I should have about 500.
I think this is a NAT issue since the other spoke routers that are not behind NAT are working normally.
Can someone take a look and point me in the right direction?
Thanks!!
Solved! Go to Solution.
09-28-2008 11:35 AM
Hello Brian,
an MTU problem : I too was thinking of different possible reasons.
Nice news that you solved the issue, it has been an interesting case.
I've given you good remarks.
providing the solution of an issue is a service for everyone that can read the forum and see a complete case with its happy end.
I tried to look in the command reference to find a command to tell EIGRP how many routes to place in a single update.
Actually changing the MTU is a an indirect way to do this.
Best Regards
Giuseppe
09-25-2008 09:18 PM
PLease share ur diagram and config
09-25-2008 10:42 PM
Hello Brian,
be aware that EIGRP allows interface per interface route summarization:
verify on the hub router if there are commands like
ip summary-address eigrp
on the tunnel interface to the spoke
multiple commands are supported and they allow to reduce the number of routes in the spoke.
It is unlikely that NAT of FW can block only some updates.
Besides this updates are acknowledged so they will be retransmitted if not received by spoke.
Another possible source of what you see is the presence of distribute-list in the router eigrp in the hub router with reference to the tunnel interface
look for
distribute-list xx out tunnel to_spoke
Edit:
I see something I don't like
ip access-list extended NAT
permit ip 10.30.2.0 0.0.0.255 any
!
I would deny in the ACL traffic between the spoke and the head quarter you need to NAT only when going to the internet
ip access-list extended NAT
deny ip 10.30.2.0 0.0.0.255 10.0.0.0 0.255.255.255
permit ip 10.30.2.0 0.0.0.255 any
Hope to help
Giuseppe
09-26-2008 01:04 PM
Thank you for your reply. Here is the EIGRP setup on the hub router; it's pretty plain and straight forward.
router eigrp 16855
redistribute eigrp 10
passive-interface default
no passive-interface GigabitEthernet0/1.100
network 172.27.0.2 0.0.0.0
no auto-summary
!
router eigrp 10
redistribute eigrp 16855
passive-interface default
no passive-interface Tunnel0
network 172.25.254.2 0.0.0.0
no auto-summary
I did notice that if I change my transform-set back to tunnel mode (rather than transport mode) the routing works fine and I get all my updates.
Here is the tunnel configuration on the hub router.
interface Tunnel0
bandwidth 1500
ip address 172.25.254.2 255.255.255.0
no ip redirects
ip mtu 1440
no ip next-hop-self eigrp 10
ip nhrp authentication ABS_NET
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip nhrp shortcut
no ip split-horizon eigrp 10
tunnel source GigabitEthernet0/3
tunnel mode gre multipoint
tunnel key 0
tunnel protection ipsec profile ABS
I am definitly confused on what's happening here but I hope it doesn't have anything to do with the bandwidth, metric, reliability, load...etc because I when I was digging deeper I discovered the routes I'm missing all have a BW of 100000 in the topology table and all the ones I have on the spoke are 10000 or less.
I understand what you're saying about the nat but I am trying to get away from specifying explicit networks as much as possible because if, for instance, I add a new network such as 172.32.10.0 I will have to revisit each of my site routers to add the explicit deny.
I was worried that the NAT was going to cause problems like it does with static crypto maps but it appears that the order of operations doesn't come into play here because the traffic destined for the internal network never directly sees the interface with IP NAT OUTSIDE configured.
Your help is appreciated!!
09-26-2008 01:22 PM
Hello Brian,
I've just made some basic considerations
>> I did notice that if I change my transform-set back to tunnel mode (rather than transport mode) the routing works fine and I get all my updates.
Nice point.
When we deal with NAT we should remember that NAT inspects the whole packet in search of embedded ip address information.
Packets containing huge ip addresses information like some SNMP messages or routing updates can be a problem for NAT.
Using tunnel mode makes the NAT job simpler as your tests show.
So I changed my idea and I agree with you, the only aspect that I don't understand is the following:
each EIGRP update requires an acknowledge so I would expect the hub router to complain to be not able to send all the updates to the spoke for the missing Acknowledgements.
what you see in
sh ip eigrp 10 neighbors when not using tunnel mode ?
is the spoke listed here as a valid neighbor ?
It shouldn't be there because the update process is not successful towards it.
Or at least you should see some numbers of packets waiting in the unicast queue to be transmitted to the spoke.
Hope to help
Giuseppe
09-26-2008 01:40 PM
Here is the information you asked for. Also, I have attached a debug of the EIGRP.
Thanks again!!
>>> HUB - mode TUNNEL <<<
HOU7206-02#sho ip eig nei 10
IP-EIGRP neighbors for process 10
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.25.254.11 Tu0 12 00:01:06 130 780 0 7129
>>> Spoke - mode TUNNEL <<<
BRIVPN02#sho ip eig nei 10
IP-EIGRP neighbors for process 10
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.25.254.2 Tu0 13 00:01:53 20 5000 0 14346
>>> HUB - mode TRANSPORT <<<
HOU7206-02#sho ip eig nei 10
IP-EIGRP neighbors for process 10
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.25.254.11 Tu0 14 00:00:37 38 5000 1 7142
>>> Spoke - mode TRANSPORT <<<
BRIVPN02#sho ip eig nei
IP-EIGRP neighbors for process 10
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.25.254.2 Tu0 12 00:00:20 90 5000 0 14362
09-27-2008 02:03 AM
Hello Brian,
we can see that when using IPSec transport mode at least one update is always waiting to be transmitted:
HOU7206-02#sho ip eig nei 10
IP-EIGRP neighbors for process 10
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.25.254.11 Tu0 14 00:00:37 38 5000 1 7142
and the debug eigrp 10 packets shows clearly that the hub is trying to send an update multiple times :
13:21:23.926: EIGRP: Sending UPDATE on Tunnel0 nbr 172.25.254.11, retry 6, RTO 2593
13:21:26.522: EIGRP: Sending UPDATE on Tunnel0 nbr 172.25.254.11, retry 7, RTO 3889
13:21:30.414: EIGRP: Sending UPDATE on Tunnel0 nbr 172.25.254.11, retry 8, RTO 5000
13:21:35.414: EIGRP: Sending UPDATE on Tunnel0 nbr 172.25.254.11, retry 9, RTO 5000
Before some updates have been successfully sent and the ACK has been received:
13:21:19.102: EIGRP: Received ACK on Tunnel0 nbr 172.25.254.11
13:21:19.174: EIGRP: Received ACK on Tunnel0 nbr 172.25.254.11
If we could say to EIGRP to send only few routes in each update the process could have an end.
Here we see the difference between EIGRP neighbor state machine and OSPF neighbor state machine: two OSPF routers not reaching the full state would restart the neighborship.
Hope to help
Giuseppe
09-28-2008 08:51 AM
"If we could say to EIGRP to send only few routes in each update the process could have an end. "
I never found an answer to this question but it did occur to me that since I was dealing with a NAT as well as payload encryption (rather than whole packet encryption) that I could be dealing with a MTU problem like sometimes happens when static crypto maps. So I decided to lower my MTUs down to 1300 and my spokes immediately came up and my queue counts when to 0.
I guess the solution was staring me in the face the whole time but like always I went digging for the most complicated answers I could find.
If you do know a way to adjust the number of routes in an EIGRP update I appreciate the info, it might help me in future projects.
Thanks again for the help!!!
09-28-2008 11:35 AM
Hello Brian,
an MTU problem : I too was thinking of different possible reasons.
Nice news that you solved the issue, it has been an interesting case.
I've given you good remarks.
providing the solution of an issue is a service for everyone that can read the forum and see a complete case with its happy end.
I tried to look in the command reference to find a command to tell EIGRP how many routes to place in a single update.
Actually changing the MTU is a an indirect way to do this.
Best Regards
Giuseppe
05-20-2015 11:23 AM
Hi I have dmvpn with more than 100 sites and only 1 site is flapping , I have tried to increase eigrp hello/hold timers on tunnel int , increase bandwith on it but still flapping cause of holding time expired and retry limit exceeding . I wanted to lower mtu size on spoke tunnel from 1400 to 1300 or lover , i thing too much prefixes in eigrp updates make packet bigger . Should I lower mtu size on both spoke and hub ? if yes , should i then change mtu size on all of my spokes ?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide