Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Multicast time out over GRE Tunnel

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.

Hall of Fame Super Silver

Re: Multicast time out over GRE Tunnel

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.


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


New Member

Re: Multicast time out over GRE Tunnel

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

Hall of Fame Super Silver

Re: Multicast time out over GRE Tunnel

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


CreatePlease to create content