2 devices respond to one network but not another...
Strange problem...at least I think it is. Here is the setup:
One in the U.S.(A) and two in Brazil. (B & C)
The fingerprint devices are a new install.
Two (new) fingerprint reading devices in facility C
(New) Fingerprint backend server in facility B
I'm in facility A
MPLS between A, B, & C
P2P between B & C
Now, suffice to say that everything has been working normally for as long as I know between these three facilities.
The problem is that the two fingerprint devices in facility C will not respond to a PING from the backend server in facility B. The backend server will take the P2P link to get to the fingerprint devices.
--> They *will* respond to a PING from my machine, which is in facility A. (Which would take the MPLS link to get to facility C)
--> If I PING from the MPLS router in B it takes the MPLS route into C and the devices respond.
--> Across the P2P I can PING devices all around these two devices. One fingerprint device is @ .78...I can hit .77 & .79 (Which are not similar devices)
--> The P2P routers have no ACL's at all.
-->The fingerprint device IP configs (as well as the backend server) have been checked and verified.
I've enabled icmp, and ARP debugs on the two P2P routers and I from the P2P router in B I can see responses when I PING a known good device in C, but when I try to PING the fingerprint device I see nothing in the debug.
I know this is not a simple setup but I really believe I'm overlooking something simple. Any suggestions as to where I might look would be helpful.
There may be something on that network sending out proxy arp requests thus causing your finger print devices to respond to the wrong mac-address.
If you can get a sniffer capture from the finger print devices, (span port on the switch) and then ping from your computer and then from the server. See if the mac address for the gateway IP changes in the decode between the two ping captures. If so then you have a proxy arp issue. Identify the bad mac address and ensure that device is configured not to perform proxy arp.
Of course this is just a suggestion but I have run into so many problems like this and it is almost always a proxy arp issue.
This is the sign you have been waiting for. It's the year you apply to become a Cisco Champion. As a Cisco Champion, you’ll:
Get early insights into new Cisco products and solutions
Receive access to Cisco’s engineering rock stars
Expand your ...
Discover how your network can power hybrid work with no compromise in security, agility, or experience.
Join us on Wednesday, February 23 at 10:00 AM PT / 1:00 PM ET for insights on innovations in Wi-Fi 6E, private 5G and more.
Hear from our panel of cus...
Listen: https://smarturl.it/CCRS9E3Follow us: https://twitter.com/CiscoChampion
Esports is booming and Cisco is taking a front seat in the future of Esports in a big way. Game publishers, professional teams, tournament organizers and venue owners ar...
Cisco recently announced the availability of the IOS-XE train – IOS-XE Cupertino 17.7.1. This is a standard maintenance release supporting switching, wireless, SP-Access, Routing as well as IoT (Internet of things) platforms with a sustaining support life...