cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10404
Views
0
Helpful
6
Replies

GRE Tunnel up/up Cannot ping tunnel interface

stephenpetrock
Level 1
Level 1

I setup a GRE tunnel between two cisco 2621 routers.  They are both

running IOS c2600-advsecurityk9-mz.123-6c.bin.  When I do a show ip int

brief they both show up/up.   I can ping the tunnel address that the router

resides on but not the distant end.  This is true for both routers.  I can also

ping both the source and destination of the tunnel from both routers.  So I

know that there shouldn't be any recurvise routing problems. My configs are listed below.

My Router:

interface Tunnel65

ip address 10.15.65.1 255.255.255.0

tunnel source FastEthernet0/0

tunnel destination 200.62.203.198

interface FastEthernet0/0

ip address 60.197.140.33 255.255.255.248

no ip mroute-cache

duplex auto

speed auto

ip route 200.62.203.198 255.255.255.255 60.197.140.34

Distant Router:

interface Tunnel65

ip address 10.15.65.65 255.255.255.0

tunnel source Dialer2

tunnel destination 60.197.140.33

interface Dialer2

ip address negotiated

no ip redirects

no ip unreachables

ip mtu 1492

ip nat outside

ip inspect to_internet out

encapsulation ppp

dialer pool 2

dialer-group 2

no cdp enable

ppp authentication chap pap callin

ppp pap sent-username XXXXXXXX

ip route 60.197.140.33 255.255.255.255 dialer2

Thank You!!

6 Replies 6

Talha Ansari
Level 1
Level 1

Hi,

The fastethernet port of the router at your end has a public ip address and is connected to Internet(possibly). While the tunnel ip addresses are private ip addresses. Hence when you ping the tunnel ip address at the other end the packet won't be routed by your ISP. I don't see any Natting configuration on the fastethernet port of your router. I think if you do Natting on fastethernet port to NAT the tunnel interface ip address this should resolve or either you may configure IPSEC tunnel with ESP option between the WAN interfaces at both ends.

Regards,

Talha

cadet alain
VIP Alumni
VIP Alumni

Hi,

A GRE Tunnel will always be up but you can configure a keepalive to verify if it is a routing problem.

Could you do this on the side where you initiate the ping:

debug ip icmp

debug ip pack 199

access-list 199 permit icmp any any

logging buff 7

logging buff 100000

no logging  con 7

then do your ping and issue following:  sh log  and post output here.

Regards.

Alain.

Don't forget to rate helpful posts.

Don't forget to rate helpful posts.

Alain,

I came upon your POST last night and was hoping to try out your suggestions.

I keyed in debug ip icmp.

As soon as I keyed in debug ip pack 199, my C1921 router was unavailable from SSH.  I'm assuming this debug pegged the CPU.  I had to visit client onsite this morning to reboot the router.

I'm still having similar issues, but just wanted you to know.

Michael West 

I have similar problem. Primary GRE tunnel with Zscaler id down however secondary tunnel is up.

Not able to ping tunnels destination end private IP but i can ping tunnels public destination IP.

I have shared requested debug logs for working and non working tunnel.

 

#show run interface tunnel101
Building configuration...

Current configuration : 299 bytes
!
interface Tunnel101
description **PRIMARY TUNNEL TO ZSCALAR**
bandwidth 20000
ip address 172.18.163.73 255.255.255.252
no ip redirects
ip mtu 1400
ip tcp adjust-mss 1360
load-interval 30
qos pre-classify
tunnel source Loopback8
tunnel destination 165.225.76.34
tunnel vrf INTERNET
end

#show run int tunnel102
Building configuration...

Current configuration : 314 bytes
!
interface Tunnel102
description **BACKUP TUNNEL TO ZSCALAR**
bandwidth 20000
ip address 172.18.163.77 255.255.255.252
no ip redirects
ip mtu 1430
ip tcp adjust-mss 1400
load-interval 30
qos pre-classify
keepalive 10 3
tunnel source Loopback8
tunnel destination 185.46.214.34
tunnel vrf INTERNET
end

#show run interface Loopback8
Building configuration...

Current configuration : 118 bytes
!
interface Loopback8
description [NON IZO]
ip vrf forwarding INTERNET
ip address 80.231.9.44 255.255.255.255
end

 

#ping vrf INTERNET 165.225.76.34 source Loopback8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 165.225.76.34, timeout is 2 seconds:
Packet sent with a source address of 80.231.9.44
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/7 ms
#show clo
07:22:52.359 UTC Tue Jan 28 2020
#ping vrf INTERNET 185.46.214.34 source Loopback8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 185.46.214.34, timeout is 2 seconds:
Packet sent with a source address of 80.231.9.44
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 23/24/26 ms

 

Jan 28 07:11:14.790 UTC: IP: s=172.18.163.77 (local), d=172.18.163.78, len 100, local feature, feature skipped, Auth Proxy(16), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Jan 28 07:11:14.790 UTC: IP: tableid=0, s=172.18.163.77 (local), d=172.18.163.78 (Tunnel102), routed via FIB
Jan 28 07:11:14.790 UTC: IP: s=172.18.163.77 (local), d=172.18.163.78 (Tunnel102), len 100, sending
Jan 28 07:11:14.790 UTC: IP: s=172.18.163.77 (local), d=172.18.163.78 (Tunnel102), len 100, output feature, feature skipped, TCP Adjust MSS(58), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Jan 28 07:11:14.790 UTC: IP: s=172.18.163.77 (local), d=172.18.163.78 (Tunnel102), len 100, output feature, feature skipped, QoS Preclassification(79), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Jan 28 07:11:14.814 UTC: IP: s=172.18.163.78 (Tunnel102), d=172.18.163.77, len 100, enqueue feature, TCP Adjust MSS(5), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Jan 28 07:11:14.815 UTC: ICMP: echo reply rcvd, src 172.18.163.78, dst 172.18.163.77, topology BASE, dscp 0 topoid 0


Jan 28 07:09:32.991 UTC: IP: s=172.18.163.73 (local), d=172.18.163.74, len 100, local feature, feature skipped, Auth Proxy(16), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Jan 28 07:09:32.992 UTC: IP: tableid=0, s=172.18.163.73 (local), d=172.18.163.74 (Tunnel101), routed via FIB
Jan 28 07:09:32.992 UTC: IP: s=172.18.163.73 (local), d=172.18.163.74 (Tunnel101), len 100, sending
Jan 28 07:09:32.992 UTC: IP: s=172.18.163.73 (local), d=172.18.163.74 (Tunnel101), len 100, output feature, feature skipped, TCP Adjust MSS(58), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Jan 28 07:09:32.992 UTC: IP: s=172.18.163.73 (local), d=172.18.163.74 (Tunnel101), len 100, output feature, feature skipped, QoS Preclassification(79), rtype 1, forus FALSE, sendself FALSE,

 

 

 

Hello

The GRE tunnel interface shouild come up without any configration applied to it unlees its in a vrf then that vrf needs applied to it, so it doesnt matter at that time if your tunnel addressing isnt reachable ot not as long as the vrf is appened.

 

Can you post the output of a traceroute please:
traceroute 165.225.76.34 source loopback 8 numeric
traceroute 185.46.214.34 source loopback 8 numeric


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Deepak Kumar
VIP Alumni
VIP Alumni

Hi,

One question, It may my mistake in understanding the port

1. Do you have a static IP on the dialer? If not then How did you got the fixed IP "tunnel destination 200.62.203.198"?

 

Regards,
Deepak Kumar,
Don't forget to vote and accept the solution if this comment will help you!
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: