Strange issue pinging a remote device

Hi can any one explain this?

I have set up a remote wireless access point that I am trying to manage via its WLAN interface. (this works for other similar devices)

So I cant ping it from my desk top so I tried from the core switch (router for the two networks in question)

ASH_6506#ping 172.20.255.110
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.20.255.110, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
ASH_6506#
ASH_6506#

ASH_6506#
ASH_6506#ping 172.20.255.110 source 172.20.230.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.20.255.110, timeout is 2 seconds:
Packet sent with a source address of 172.20.230.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
ASH_6506#

So device is in the 172.20.255.0 / 24 and my desktop is in 172.20.230.0 / 24

All is fine and the device responds to both

My PC has the ip address of 172.20.230.11 but if i try the Ping from my desk top it times out?

Tracing route to 172.20.255.110 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 172.20.230.1
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.

So hits the same core switch and in the same subnet as which I tested from, but then goes bye bye.

So why can I hit the device from the core switch, but not the PC, all end devices just have a default gateway that points back to the gateway address ip that is held on the core switch?

Cheers

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

Deathmage

Do you have routes setup? - it seems that the one side of the router can ping the other side so I would presume the route is setup; but what about going the other way?

Also I've found that manually adding the routes to your PC sometimes helps too.

Maybe doing a "route add 172.20.230.0 255.255.255.0 172.20.255.0"?

EdTheLad

You sure you don't have some kind of access restriction on your l3 switch? From what you've shown it looks like the forwarding between switch ports is an issue. Just to rule out the access-point, disconnect the pc, config an svi on the switch with 170.20.230.11 and try sourcing the ping from the svi. This will rule out the access point and you can then focus on your switch.

DevilWAH

OK

VLAN 666 = 172.20.255.0 / 24

vlan 310 = 172.20.230.0 /24

Core 6505 switch has SVI of 172.20.255.1 and 172.20.230.1 for vlans 666 and 310.

A bunch of network devices have ip address assigned in the 172.20.255.0 /24 range and my PC can manage them all with out issue

So my PC can happily talk to all devices on the 4172.20.255.0 / 24 range.

If I patch this devices LAN port in to an access switch in vlan 666 I can see it, its only via its WLAN port I cant manage it?

However as you can see from above the core switch can mange it if its connected by wired or wireless.

EdTheLad

No idea what your setup is, you need to provide a diagram. If 203.1 is an svi on your core switch why are you getting a response from that if you are pinging the wireless? Is your DG on your pc setup for the core switch rather than the AP interface?

DevilWAH

The digram below is when it works (core 6506 is the defualt gate way for both networks), with the Rocket connected directly to the physical port and the nano station across the link. In this configuration I can manage both from My PC.

how ever if I swap it over so that the nano station is hard wired and the rocket is across the link then I cant get to the 172.20.255.110 address.

What I see see the below, I have logged on from the core switch via ssh to the rocket (across the wireless link. Imagen the link form the 2960 goes to the nano station not the rocket)

I can ping from to a ip in another subnet but the packet does not get returned, it works when I ping the 172.20.230.50 address because the switch also has a interface in the 172.20.255.0 / 24 range (packets taking different paths for each direction),. But if i remove the SVI in the vlan 666 from the access switch or try from my PC it fails.

the only change I make it which of the wireless devices is hard wired to the switch, but both devices have identical configuration?

XM.v5.5.8# ping 172.20.230.50
PING 172.20.230.50 (172.20.230.50): 56 data bytes
64 bytes from 172.20.230.50: seq=0 ttl=255 time=3.867 ms
64 bytes from 172.20.230.50: seq=1 ttl=255 time=19.108 ms
64 bytes from 172.20.230.50: seq=2 ttl=255 time=8.983 ms
64 bytes from 172.20.230.50: seq=3 ttl=255 time=10.818 ms
64 bytes from 172.20.230.50: seq=4 ttl=255 time=12.066 ms
64 bytes from 172.20.230.50: seq=5 ttl=255 time=3.872 ms
64 bytes from 172.20.230.50: seq=6 ttl=255 time=8.366 ms
64 bytes from 172.20.230.50: seq=7 ttl=255 time=9.293 ms
64 bytes from 172.20.230.50: seq=8 ttl=255 time=6.558 ms
64 bytes from 172.20.230.50: seq=9 ttl=255 time=2.047 ms
^C
--- 172.20.230.50 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 2.047/8.497/19.108 ms
XM.v5.5.8#
XM.v5.5.8#
XM.v5.5.8#
XM.v5.5.8#
XM.v5.5.8#
XM.v5.5.8#
XM.v5.5.8#
XM.v5.5.8#
XM.v5.5.8#
XM.v5.5.8#
XM.v5.5.8#
XM.v5.5.8# ping 172.20.230.11
PING 172.20.230.11 (172.20.230.11): 56 data bytes
^C
--- 172.20.230.11 ping statistics ---
179 packets transmitted, 0 packets received, 100% packet loss
XM.v5.5.8#

ptp issue.jpg

DevilWAH

OK hope you can see that bigger

But this is the issue it seems, with one device patched in then you can see the reply both try to use the CISCO routers MAc address as the next hope for the DFGW.

But plugged in the other way around, and the far end station tries to use the Mac address of my which it can't possible reach? So its basically sending the packet back on vlan 666, but to a mac address the cisco router only knows about on vlan 500.

ptp4 issue.jpg

EdTheLad

So the question is how is Rocket learning that mac address? Look at the arp cache on rocket, try and clear it. No idea where vlan 500 has come from, nowhere in your description.Do you have allow lists on your trunks?

DevilWAH

EdTheLad wrote: »

So the question is how is Rocket learning that mac address? Look at the arp cache on rocket, try and clear it. No idea where vlan 500 has come from, nowhere in your description.Do you have allow lists on your trunks?

opps sorry meant to say vlan 310. Sorry some of the IP and vlans have been changed for the purpose of posting online

so its learning the mac address of the PC, but not sure how. it seems the tagging on the Nano is the issue, it seems to rewrite the mac address of the DFGW as the packet comes back from the rocket?

Some one from unbiquiti is looking at it to see if they can tell me what is happening.

EdTheLad

Ah ok 310 makes more sense. So i bet the 2950 has vlan 310 configured?, i've no idea how Rocket is setup, but its not routing, its seeing the pc on vlan 310. When you move it to the farside of the wireless its arp cache still has an entry for the pc.

Your design is kinda screwed, vlan 310 should stop at the core switch, vlan 666 should only be between the core and the AP, the pc shouldn't see this. You need to configure vlan allow lists on your switch trunks. The problem seems to be Rocket has access to the pc via vlan 310, when you move Rocket it still believes it has a good arp cache entry. Disconnecting the physical on Rocket doesn't cause an arp cache flush, you could look at if this can be configurable on Rocket or a bug?
If you cleaned up your design you wouldn't see these issues, but good to find out whats happening with Rockets arp cache.

DevilWAH

VLAN 310 does stop at the core switch, the trunk to the AP only allows vlan 666 and 1 at the moment. And rebooting the rocket does not help.

VLAN 310 is a site wide vlan as its for desktops (well not strictly site wide but its a user vlan so on a number of access switches). Trunked back to the core that hold the DFGW on a SVI.

If what you say was correct then you would expect the rocket to try to get to the PC direct always, but this is not the case. When the rocket is connected directly you can see its using the CISCO as a DFGW, When it is remote it is trying to get to the PC MAC directly.

Network rules say that the rocket only has an IP address of 172.20.255.110, and its trying to get to 172.20.230.11, there for it should use the default gateway MAC, the Destination IP is on a separate network, it should not even try to ARP for its MAC, it should simple arp the gateway.

EdTheLad

DevilWAH wrote: »

If what you say was correct then you would expect the rocket to try to get to the PC direct always, but this is not the case.

True, i presumed the dell address was when Rocket was directly connected as you never said what setup the macs correlated to. You really need to work on your logging and descriptions, very hard to understand whats going on. Don't think i can troubleshoot it without access to the devices, for sure something is a miss here. Maybe two vlans are leaking into each other, are there two access vlan ports physically connected on one of the switches? Anyway i'll leave you to it.