ping problem

Unanswered Question
May 13th, 2010

Q:

cannot ping direct connection interface. "show cdp" can see the nei up. What steps  can be taken to troubleshoot the issue.

configuration on interface:

!
interface GigabitEthernet0/0
  ip address 1.1.1.1 255.255.255.252
no ip redirects
no ip directed-broadcast
no ip proxy-arp
load-interval 30
no snmp trap link-status
end

thanks.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
johnlloyd_13 Thu, 05/13/2010 - 19:36

kindly post your show cdp neighbor and ping results. either IP address on the remote end is incorrect or there's an ACL on it.

stonnet72 Thu, 05/13/2010 - 21:28

have you tried doing a tracert to the IP of that interface? Perhaps there is some time of GW issue that is overlooked. Please post trace route log.

Thank you

amychen2008 Fri, 05/14/2010 - 06:15

configuration of other end;

xxx#show run int g2/0
Building configuration...

Current configuration : 237 bytes
!
interface GigabitEthernet2/0
mtu 4470
ip address 1.1.1.2 255.255.255.252
no ip redirects
no ip directed-broadcast
no ip proxy-arp
load-interval 30
no snmp trap link-status
end

#ping 1.1.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

#traceroute 1.1.1.2

Type escape sequence to abort.
Tracing the route to 1.1.1.2

  1  *  *  *
  2  *  *  *
  3  *  *  *
...

#show arp 
Protocol  Address          Age (min)  Hardware Addr   Type        Interface
Internet  1.1.1.1                 -   0005.dd32.6000  ARPA        GigabitEthernet0/0
Internet  1.1.1.2                45   0005.5f1e.68cc  ARPA        GigabitEthernet0/0

#show cdp nei
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater

Device ID            Local Intrfce         Holdtme   Capability    Platform   Port ID
xxxxxx                    Gig 0/0               147            R        12410/PRP Gig 2/0

#show int g0/0
GigabitEthernet0/0 is up, line protocol is up
  Hardware is GigMac 1 Port 10 GigabitEthernet Plus, address is 0005.dd32.6000 (bia 0005.dd32.6000)
  Internet address is 1.1.1.1/30
  MTU 4470 bytes, BW 10000000 Kbit, DLY 10 usec, rely 255/255, load 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full Duplex, 10000Mbps, link type is force-up, media type is LR 1310nm
  ......
  30 second input rate 0 bits/sec, 0 packets/sec
  30 second output rate 0 bits/sec, 0 packets/sec
     29 packets input, 11339 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 29 multicast, 0 pause input
     233 packets output, 34595 bytes, 0 underruns
     Transmitted 0 broadcasts
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

Hitesh Vinzoda Fri, 05/14/2010 - 07:39

Hi,

debug ip packet details 101

access-list 101 permit icmp host 1.1.1.1 host 1.1.1.2

Check debug output... by the way just curious to know whether both interfaces are 10G ?

Regards

Hitesh Vinzoda

smitesh kharecha Sat, 05/15/2010 - 00:58

HI Amy,

Looking at the config and other output, we can see that we are learning arp of the IP address which you are trying to ping.

Which forces me to belive that their might be ACL on the remote end (which you are trying to ping).

Another thing which i have noticed is there is no traffic following though your Gi0/0.

I would suggest debug icmp on both sides and see whats it comes..

-Regards,

Smitesh

amychen2008 Sat, 05/15/2010 - 22:39

May 16 01:15:24 EDT: IP: tableid=0, s=1.1.1.2 (local), d=1.1.1.1 (GigabitEthernet2/0), routed via FIB

May 16 01:15:24 EDT: IP: s=1.1.1.2 (local), d=1.1.1.1 (GigabitEthernet2/0), len 100, sending

May 16 01:15:24 EDT: ICMP type=8, code=0.

May 16 01:15:54 EDT: IP: tableid=0, s=1.1.1.2 (local), d=1.1.1.1 (GigabitEthernet2/0), routed via FIB

May 16 01:15:54 EDT: IP: s=1.1.1.2 (local), d=1.1.1.1 (GigabitEthernet2/0), len 100, sending

May 16 01:15:54 EDT: ICMP type=8, code=0.

May 16 01:16:24 EDT: IP: tableid=0, s=1.1.1.2 (local), d=1.1.1.1 (GigabitEthernet2/0), routed via FIB

May 16 01:16:24 EDT: IP: s=1.1.1.2 (local), d=1.1.1.1 (GigabitEthernet2/0), len 100, sending

May 16 01:16:24 EDT: ICMP type=8, code=0.

May 16 01:16:54 EDT: IP: tableid=0, s=1.1.1.2 (local), d=1.1.1.1 (GigabitEthernet2/0), routed via FIB

May 16 01:16:54 EDT: IP: s=1.1.1.2 (local), d=1.1.1.1 (GigabitEthernet2/0), len 100, sending

May 16 01:16:54 EDT: ICMP type=8, code=0.

May 16 01:17:24 EDT: IP: tableid=0, s=1.1.1.2 (local), d=1.1.1.1 (GigabitEthernet2/0), routed via FIB

May 16 01:17:24 EDT: IP: s=1.1.1.2 (local), d=1.1.1.1 (GigabitEthernet2/0), len 100, sending

May 16 01:17:24 EDT: ICMP type=8, code=0

===remote end====

May 16 01:21:20 EDT: IP: tableid=0, s=1.1.1.1 (local), d=1.1.1.2 (GigabitEthernet0/0), routed via FIB

May 16 01:21:20 EDT: IP: s=1.1.1.1 (local), d=1.1.1.2 (GigabitEthernet0/0), len 100, sending

May 16 01:21:20 EDT: ICMP type=8, code=0.

May 16 01:21:22 EDT: IP: tableid=0, s=1.1.1.1 (local), d=1.1.1.2 (GigabitEthernet0/0), routed via FIB

May 16 01:21:22 EDT: IP: s=1.1.1.1 (local), d=1.1.1.2 (GigabitEthernet0/0), len 100, sending

May 16 01:21:22 EDT: ICMP type=8, code=0.

May 16 01:21:24 EDT: IP: tableid=0, s=1.1.1.1 (local), d=1.1.1.2 (GigabitEthernet0/0), routed via FIB

May 16 01:21:24 EDT: IP: s=1.1.1.1 (local), d=1.1.1.2 (GigabitEthernet0/0), len 100, sending

May 16 01:21:24 EDT: ICMP type=8, code=0.

May 16 01:21:26 EDT: IP: tableid=0, s=1.1.1.1 (local), d=1.1.1.2 (GigabitEthernet0/0), routed via FIB

May 16 01:21:26 EDT: IP: s=1.1.1.1 (local), d=1.1.1.2 (GigabitEthernet0/0), len 100, sending

May 16 01:21:26 EDT: ICMP type=8, code=0.

May 16 01:21:28 EDT: IP: tableid=0, s=1.1.1.1 (local), d=1.1.1.2 (GigabitEthernet0/0), routed via FIB

May 16 01:21:28 EDT: IP: s=1.1.1.1 (local), d=1.1.1.2 (GigabitEthernet0/0), len 100, sending

May 16 01:21:28 EDT: ICMP type=8, code=0.

From debugging on both ends, I saw sending packets, but not receiving any echo. Are you able to see anything usual from above icmp debug?

I don't see any ACL. It's new link. There is no traffic flowing through.

Really appreciate your kind help.

Amy

kenny1978 Sun, 05/16/2010 - 06:32

Hi Amy,

Is this a new Wan link? And how do the both routers connecting to each other?

Any ways to setup only the IP addresses on another Gigabit Ethernet for the router and the remote router?

Thanks,

KA

kenlee1978 Sun, 05/16/2010 - 06:44

Other than knowing what link both routers connected to, Can you change your IP addresses to other than 1.1.1.1 and .2 /30 for the Routers WAN IP addresses?

Thanks,

amychen2008 Mon, 05/17/2010 - 10:25

I 've changed ip address to other private 10.x , also try public address. Not work.

Both ends are 10g.

Btw, I 've opend a cisco tac case for assistance.

I am really appreciate your kind help.

Regards,

John Blakley Mon, 05/17/2010 - 11:28

Amy,

Try to take off the mtu config on g2/0. Also, what happens if you ping the other side by sourcing manually?

ping 1.1.1.1 sour GigabitEthernet2/0

HTH,

John

stonnet72 Tue, 05/18/2010 - 12:13

Two things I would suggest here, hopefully this will help:

- try doing a shut and no shut on both the interfaces. Don't no if you did that during the configuration process of the interfaces

- try setting the interfaces to auto-negotation on both sides of the interfaces (not saying this is a duplex issues because it probably would have displayed that in the output of the sho int, but may be worth try

Ultimately would be great to see both sides of the configuration for the interfaces.

stonnet72 Tue, 05/18/2010 - 12:32

configuration on interface:

!
interface GigabitEthernet0/0
  ip address 1.1.1.1 255.255.255.252
no ip redirects
no ip directed-broadcast
no ip proxy-arp
load-interval 30
no snmp trap link-status
end


interface GigabitEthernet2/0

MTU 4470  <-- Noticed there is MTU set here but not set on the above interface (I would try setting the MTU to 1500 on both sides in addition, if the other interface has a lower or no MTU set then the packet will get dropped)
ip address 1.1.1.2 255.255.255.252
no ip redirects
no ip directed-broadcast
no ip proxy-arp
load-interval 30
no snmp trap link-status
end

tiredofnetworks Fri, 06/24/2011 - 15:34

Use something like PingMaster so that you can adjust the ping variables in real-time and see where you start to get drops due to MTU. There are alot of programs with this name, but the free one at flagshipsoft.com is what I'm talking about.

Actions

This Discussion