Only part of EIGRP routing table received

Answered Question
Sep 25th, 2008

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!!

Attachment: 
I have this problem too.
0 votes
Correct Answer by Giuseppe Larosa about 8 years 2 months ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Giuseppe Larosa Thu, 09/25/2008 - 22:42

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

BrianMitchellTX Fri, 09/26/2008 - 13:04

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!!

Giuseppe Larosa Fri, 09/26/2008 - 13:22

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

BrianMitchellTX Fri, 09/26/2008 - 13:40

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

Attachment: 
Giuseppe Larosa Sat, 09/27/2008 - 02:03

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

BrianMitchellTX Sun, 09/28/2008 - 08:51

"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!!!

Correct Answer
Giuseppe Larosa Sun, 09/28/2008 - 11:35

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

Bekzod Fakhriddinov Wed, 05/20/2015 - 11:23

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 ?

Actions

This Discussion