A customer appears to have drastically misunderstood our instructions for connecting to our WAN. He set his PC IP address to the same as one of the bridges. :wall: This caused much confusion on the network, to put it mildly. He called to complain about the poor performance of the network he ruined, then made himself unavailable for phone calls so it couldn't be fixed.
Even blocking his MAC address didn't help. The bridging problem happens in midair, nowhere the server can control. If I could at least get into the bridge, I could reconfigure it to a different IP and allow traffic again...
This succeeded in forcing the server to talk to the bridge, not to him. I was then able to get into the bridge's web interface and change its IP from there. From there it was easy.
You can do neat things with arp. You can set a host to be arp server and have it direct packets to a host that actually knows how to get to the IP, sort of like a local routing table addition for the collision domain.
Modifying the arp cache was a clever trick. I wouldn't have thought of that.
(Now, of course, should this problem arise, i will gladly pull it out of my memory with a grin and a bored "well, that was obvious, wasn't it" to my colleagues ...)
There's absolutely nothing on my network that answers a ping broadcast -- perhaps because of the wireless bridge -- and increasingly many things these days never bother answering ping at all. Engineers seem to be forgetting why ICMP exists. I don't like it, but if the equipment isn't my own, I have to live with it.
Equipment can't block or ignore ARP and still function on a local network though, so I've got the arping tool installed standard everywhere. That's how I tracked down the dup. arping2 -d -i lan 192.168.6.101 Note that without the -d, it won't show dups.
As I recall from my old network engineering days a ping to a broadcast address should be done on the same subnet as the broadcast address, as a general rule. In this case, all the IP addresses on the network will respond for all interfaces configured and operational (and not blocking).
Theoretically yes, broadcast ping should work, but many common operating systems and hardware bridges block or ignore broadcast ping -- or any ping -- as a matter of course now.
I can see how it could get the pinger's MAC into other people's ARP tables, but can't see see how broadcast ping gets other MAC's into my ARP table when they don't reply.
They may reply with some nasty packet type other than echo response ICMP, like source quench!
If they have ever swapped any sort of IP packet with you, I would think it will be in your arp cache. Does ARP cache hold everything that arrives on your stack, or just arp responses for arp you initiated? Is there an arp cache poisoning attack?
Swapped, sure, but that assumes a reply. No reply? No ARP entry.
I think it tracks all ARP, since it's asynchronous, and it's useful to know things you didn't necessarily ask for anyway. ARP poisoning attacks are possible.
I believe ARP entries are good for about 5 minutes (which fouls up IP failover strategies on very high uptime systems), so the list does not usualy get very long. I suppose a NIC with a promiscuous arp algorythm could collect ARP from packets not for you, if you are not segregated by a switch from all such traffic. Network is a very competitive arena.
True - still, this works only if network (the department, not the device) hasn't decided that every network connection, even one on the same subnet, has to go over a switch with firewall capabilities enabled (that is: each and every port blocked per default).
In my last project i had such a network, which is truly a PITA: you won't even get a ping from your default gateway back - but should manage HA-networks over that crap. Usually it took us 2-3 weeks to set up a cluster - 1 hour for installing and configuring it, the rest for filling out the forms required to get the various necessary ports opened in the firewall (which never worked right the first time).
:wall: This caused much confusion on the network, to put it mildly. He called to complain about the poor performance of the network he ruined, then made himself unavailable for phone calls so it couldn't be fixed.
Engineers seem to be forgetting why ICMP exists. I don't like it, but if the equipment isn't my own, I have to live with it.