Can ping .1 but not .2 switch in the same VLAN

[AS-1]

I have SW1 with IP address .1 and SW2 with .2, under same VLAN.

Those are connected through Port-channel

Configured as following-

interface Vlan##
no ip redirects
no ip proxy-arp

I can ping .1 from another site, but not .2

Same for ssh. It does allow ssh to .2 from SW1.

Any suggestion?

[Matt Delony]

Hello AS-1,

A divide and conquer strategy for troubleshooting could help here. A good start would be to check if SW2 is receiving echo request. Perhaps an ICMP debug on SW2 would help, if there's not a lot of ICMP traffic already going to it (debug ip icmp). The debug would only show echo reply being sent by SW2, but if you see that log being printed, then you can infer that echo request was received by SW2.

There's not much info to go on, but it sounds like maybe some sort of routing problem or the traffic is getting blocked.

In summary, I would check if SW2 is receiving echo request or not, which will help determine next things to check.

[AS-1]

configured the following in both SW1 and 2. 

access-list 101 permit icmp any any
debug ip packet detail 101

Pinged .2 from Desktop which failed. Pinged from SW1 and got icmp reply.

However, in SW2, didn't get any icmp debug update.

Allow ssh to .2 from SW1 but not from Desktop.

[Matt Delony]

Hello AS-1,

Can you clarify, did you get no debug output both times? If so, make sure that logging level is set properly to see debugs.

[AS-1]

configured logging level and was able to get icmp debug updates.

Please see attached.

[Matt Delony]

Hello AS-1,

Thanks for the outputs. I can see that SW2 is indeed seeing ICMP echo request coming in (type 8). And it is generating reply (type 0).

This means that echo reply is likely getting lost somewhere on the way back towards desktop. I would recommend checking routing table and ARP table on SW2 next, to see where it sent the echo reply. Then going hop-by-hop checking for any issues.

From the debugs it looks like 10.11.11.50 might have been used as L3 next hop towards desktop. This can be verified with "show ip route <desktop IP address>". It would show next hop that is used for the routing entry. Or if it matches a default route, then use the next hop specified there. Check the ARP table for next-hop IP address entry, which will show destination MAC address that switch 2 will use to send echo request towards next hop L3 interface. Make sure all this info looks good.

You can follow the same process hop by hop to check for any routing issues. Also make sure to check if the traffic is being blocked by ACL or firewall.

Maybe a traceroute from SW2 towards desktop would help isolate issue, if the network allows it (i.e. not blocked by firewall or something).