Multicast time out over GRE Tunnel

Unanswered Question
Oct 14th, 2008
User Badges:

Is there any specific reason or something I can check to see why I do not receive a Hello message reply from a multicast neighbor that is on the other side of a GRE tunnel? I get the following error when I debug ip pim:


PIM(0): Neighbor x.x.x.x (Tunnel0) timed out

Oct 14 12:07:34.417 CDT: %PIM-5-NBRCHG: neighbor x.x.x.x DOWN on interface Tunnel0 non DR


Just trying to verify that this issue is not on my side? Any help would be appreciated. TIA.


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Giuseppe Larosa Tue, 10/14/2008 - 10:26
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Daniel,

this can be a sign the GRE tunnel is no longer operational on the remote side = is not correctly routed from the remote site to your router and the PIM neighbor has timed out.


OR

the other side has just removed the ip pim sparse-mode (or other variant) command on its tunnel interface and so it doesn't answer anymore.


I usually see this error message when an IGP routing protocol adjacency has gone down making the GRE tunnel not operational (in my case IS-IS but can be any routing protocol including BGP)


Hope to help

Giuseppe


ds5879.cisco Tue, 10/14/2008 - 10:49
User Badges:

is there a way to verify the last time the tunnel got bounced? We just static route to the other side so I am not worried about the adjacency issue. TIA

Giuseppe Larosa Tue, 10/14/2008 - 10:59
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

hello Daniel,

I was meaning the external routing protocol that allows the GRE packets to be routed


if you want to know how many times the tunnel interface went down:


look at the log buffer on the device on in the syslog server.

filter for lines with the following pattern:


Line protocol on Interface TunnelX, changed state to down

X is tunnel number


or if you want to know if GRE tunnel is working you could try to use an extended ping to tunnel destination with source= tunnel source (if this is not blocked by any FW in the middle)


You could think to enable GRE keepalive so that an in-band health test is performed and you can be sure that if GRE packets cannot travel in both directions the tunnel state will change to up/down.



Hope to help

Giuseppe



Actions

This Discussion