cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1804
Views
5
Helpful
18
Replies
Highlighted
Beginner

EIRGP Hellos queueing and not sending on GRE Tunnel

I have just installed a new 887 in a branch office. Two GRE tunnels are configured back to our two head office routers. Only one of the tunnels is able to send EIGRP hellos successfully and hence, one tunnel adjacency is flapping after the RTO is maxed.

Ive tried a few things but Im totally at a loss now.

I can see from debug eigrp packets that the hello is enqueued and that Hellos are received from the tunnel endpoint, but the ACK is generated and queued also. There are no access lists or nat enabled on the tunnel interface and no outbound acls in place. General NAT/PAT is set for the Dialer int.

Ive removed all crypto and any QOS although I dont think these would affect this anyway.

Bear in mind that both tunnels originate at the Dialer and one is working fine.

The SH ip eigrp neigh is shown here

EIGRP-IPv4 Neighbors for AS(****)

H   Address                 Interface       Hold Uptime     SRTT    RTO   Q  Seq

                                                              (sec)         (ms)            Cnt Num

1   172.20.80.1             Tu0               10   00:00:13    83      5000    1  1784719

0   172.21.80.1             Tu1               13   2d21h        79      474      0  1437249

Any thoughts for tshooting would be greatly appreciated.

At this point Im starting to think it could be an ISP issue?

18 REPLIES 18
Highlighted
Hall of Fame Cisco Employee

Hello Paul,

Can you actually successfully ping both ends of the tunnel? Is the EIGRP the only IP application running over that tunnel that exhibit problems, or are there also other applications/services that do not work properly over the tunnel?

Are the EIGRP neighbors specified using the neighbor command on any end of the tunnel? If you use the neighbor command then it must be used on both ends of the tunnel. I would even suggest trying to use the neighbor command on both sides of the tunnel to make EIGRP use the unicast communication over the tunnel.

Are these just point-to-point VPN tunnels, or are you using multipoint GRE and DMVPN?

Also, would it actually be possible to post the relevant parts of the configuration of both routers, particularly regarding the tunnel configuration and the EIGRP.

Best regards,

Peter

Highlighted
Beginner

Hi Paul,

can you try configuring "ip mtu <>" on tunnel interface and check, if end to end ping for tunnel interface works fine?

thanks

Highlighted
Beginner

Hi,

  Please post the configuration

Highlighted

Hi guys,

Ive not specified the neighbour command. That is something I will try. It is odd that the other tunnel sends ok.

Both tunnels transmit and receive both voice and data traffic fine. And we weight EIGRP to favour one tunnel. It is this primary tunnel that is flapping. As soon as the RTO is reached, a Hello is received from the other end bringing the tunnel back up. FYI the far end has 14 other tunnels connected just fine.

Here is the relevant portions of config. Many thanks for your time

interface Tunnel0
bandwidth 350
ip address 172.20.80.2 255.255.255.0
ip mtu 1420
qos pre-classify
tunnel source Dialer0
tunnel destination X.X.X.X
tunnel path-mtu-discovery

(notice no crypto applied here currently)
service-policy output tunnel0
!
interface Tunnel1
bandwidth 350
ip address 172.21.80.2 255.255.255.0
ip mtu 1420
delay 10000
qos pre-classify
tunnel source Dialer0
tunnel destination Z.Z.Z.Z
tunnel path-mtu-discovery
crypto map CMAP1
service-policy output tunnel0

!

interface ATM0
no ip address
no atm ilmi-keepalive
!
interface ATM0.1 point-to-point
pvc 0/38
  encapsulation aal5mux ppp dialer
  dialer pool-member 1

!

interface Dialer0
bandwidth 400
ip address negotiated
ip access-group 101 in
ip nat outside
ip inspect firewall out
ip virtual-reassembly
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap pap callin
ppp chap hostname A@B.COM
ppp chap password 0 ABC123
ppp pap sent-username USER PASSWORD
no cdp enable
crypto map CMAP1

!

router eigrp xxxx
network 172.20.80.0 0.0.0.255
network 172.21.80.0 0.0.0.255
network 192.168.80.0
network 192.168.82.0

!

ip route 0.0.0.0 0.0.0.0 Dialer0

Highlighted

Possible recursive routing,

try to  specify your tunnel destinations through the physical interface, It could be the tunnel interfce is learning the best path via eigrp to the tunnel dest throught the tunnel itself.

res Paul



kind regards
Paul

Please rate and mark posts accordingly if you have found any of the information provided useful.
It will hopefully assist others with similar issues in the future
Highlighted
Hall of Fame Cisco Employee

Paul,

The idea with the possible recursive routing is certainly very plausible. Thank you for bringing that to our attention. To rephrase the idea, the network in which a tunnel endpoint resides must not be advertised in a routing protocol running over the tunnel. Otherwise, recursive routing (a tunnel learning its endpoint via itself) may occur. Has the tunnel flapped, or is it only the EIGRP that exhibits problems?

It is difficult to say with certainty if this is the case, however. The IP address of the tunnel is bound to the Di0 interface whose IP address is dynamic. If it does not fall into the range of 172.20.80.0/24, 172.21.80.0/24, 192.168.80.0/24 or 192.168.82.0/24 networks, it is probably not the true reason of the problems.

According to your configuration, it seems that the automatic summarization is active. Would you mind deactivating it? Use the no auto-summary in the EIGRP configuration.

Best regards,

Peter

Highlighted
Beginner

Is multicast allowed on the tunnel. Hellos are multicast, so if multicast traffic is not allowed the neighbor will not see the traffic. Therefore the neighbor will not come up.

Bill

Sent from Cisco Technical Support iPad App

Highlighted
Hall of Fame Cisco Employee

Bill,

I am not aware of any particular command to allow the multicast over a GRE point-to-point tunnel. For link-local multicasts used by routing protocols, there is no need to activate PIM or any other kind of multicast routing. What exactly did you have in mind?

Best regards,

Peter

Highlighted

HI all, thanks for all the input.

Ok so the adjacency is flapping not the tunnel. The EIGRP adjacency goes down because the Hello and ACK are not received at the opposite end. But comes straight back up because Hello's are received from the other end.

Ive added the no auto-summary command. I wasnt aware that there was anything specific I should do to allow multicasts across the link. And there isnt any ACL blocking any traffic out.

If I was to use the neighbour command, do I specify the Tunnel or the Dialer ie neighbour 172.20.80.1 tunnel0 OR neighbour 172.20.80.1 dialer0.

And I'm getting confused; am I completely wrong in including 172.20.80. and 172.21.80 in the EIGRP Network statements as these are the tunnel networks as it shows in the configs I posted higher up? Or is it just the Dialer IP which should never be included?

Are there any Debugs which could show details of why packets are queued and not sent? Especially since all the network traffic flows over the link fine.

Highlighted

Hello Paul,

if the destination addresses are different this should be a feasible setup.

>> There are no access lists or nat enabled on the tunnel interface and no outbound acls in place.

But there are ACLs and CBAC on the dialer interface.

can you show us how the access-list 101 present in dialer0 interface is configured?

you also have ip inspect firewall out on dialer 0

what happens if both features are removed?

if dialer0 ip address that is received on PPPoA and the destination addresses of the GRE tunnels are not covered by network commands in the router eigrp process you are fine and recursive routing should not happen.

Usually when recursive routing is occurring you see the state of the tunnel going up and down as the state of the IGP running on it.

the neighbor command under router eigrp should be equal to the internal destination address on the other side.

Hope to help

Giuseppe

Highlighted
Hall of Fame Guru

One point I am wondering about is the fact that the crypto map is applied on the dialed and one tunnel interface. If both tunnels are sourced from the dialer then both are affected by the crypto map on the dialer. I would like to see both tunnels treated the same. Either both with a crypto map or neither with a crypto map.

And depending on the version of code running I have seen some odd behavior when crypto tunnels are applied on both the outbound interface and the tunnel interface.

The other thing that occurs to me is that we are seeing information about only one end. What is happening at the other end of the tunnel? And what is the configuration of the other end?

HTH

Rick

Sent from Cisco Technical Support iPhone App

HTH

Rick
Highlighted

No change with both CBAC and ACL removed. I have replaced the Crypto on Tunnel0. This is how it was originally configured.

I have run the router with no security settings and just tunnels configured for 5 minutes and observed no change.

Progress!

I have made something of a breakthrough - but dont know what it means!!


I deleted Tunnel 1. This instantly allowed the packets to flow up tunnel0 and the Q CNT remained 0 from then on.

The adjacency has been stable since.

I noticed that the adjacency packets seemed to be originating at alternate tunnel IPs in the Debugs. So I removed the 2nd tunnel and bam!

Text                                                                                    From

Neighbor 172.20.80.1 (Tunnel0) is down: retry limit exceeded  172.21.80.2
Neighbor 172.20.80.1 (Tunnel0) is up: new adjacency             172.21.80.2
Neighbor 172.20.80.1 (Tunnel0) is down: retry limit exceeded  172.21.80.2
Neighbor 172.20.80.1 (Tunnel0) is up: new adjacency             172.21.80.2
Neighbor 172.20.80.1 (Tunnel0) is down: retry limit exceeded  172.20.80.2
Neighbor 172.20.80.1 (Tunnel0) is up: new adjacency             172.20.80.2
Neighbor 172.20.80.1 (Tunnel0) is down: retry limit exceeded  172.20.80.2
Neighbor 172.20.80.1 (Tunnel0) is up: new adjacency             172.20.80.2

So what does this mean? Routing issue?

Bringing the 2nd tunnel back up allows both adjacencies to form but clearing the adjacency from tunnel0 or bouncing the tunnel0 interface moves things back to square one with Hellos not sending again.

Highlighted

Hello Paul,

>>

I deleted Tunnel 1. This instantly allowed the packets to flow up tunnel0 and the Q CNT remained 0 from then on.

The adjacency has been stable since.

well this leads to think that if the two tunnels might have a different source address they would be both up and operational.

However, this kind of limitation should not happen on a SW based router like yours, but it is present on some high end platforms VPN modules for C7600 for example.

I would suggest to use distribute list in order to avoid to advertise internal IP subnet of tunnel x out of tunnel y.

something like

access-list 11 deny 172.20.80.0

access-list 11 permit any

access-list 12 deny 172.21.80.0

access-list 12 permit any

router eigrp xx

distribute-list 12 out tunnel 0

distribute-list 11 out tunnel 1

on both ends

this is a sort of paranoic route control

you should not receive messages about one internal network from the neighbor on the other internal network.

This is something it shouldn't happen

messages like

Neighbor 172.20.80.1 (Tunnel0) is down: retry limit exceeded  172.21.80.2

shouldn't be seen as you noted

Hope to help

Giuseppe

Highlighted

Its worth noting that this new 887 is our first to come with the new 15.1 IOS.

I will add the distribute lists and see if it corrects the problem.

Many thanks.

Paul