On Wed, Jan 29, 2014 at 9:08 AM, Chris Adams <[email protected]> wrote: > Once upon a time, John Neiberger <[email protected]> said: >> Passive learning is an interesting thought, but I'd still like to find >> the root cause of the problem: why don't the IP addresses respond to >> ARP requests from only this router? I'm nearly certain it's a server >> issue but I haven't encountered anything quite like this before. > > On Linux, packet capture is handled in the network stack before any > filter/firewall (so tcpdump will show things that iptables blocks). So, > if packet capture on the server never shows the ARP request, the problem > is upstream from the server. > > If you also see the packet leaving the router, that only leaves the > switch(es) in between as the culprit.
That's very helpful information. I'll have the server owner do a capture again just to verify. The switch doesn't seem to have any problem forwarding broadcasts. We get responses to ARP requests from the other devices on the subnet (other router and the switch itself), just not from these interfaces. Also, the other router has no problem getting responses to ARP requests. If the switch had stopped forwarding broadcasts, all sorts of stuff would break including ARP requests from RouterA. It's very unusual. > > This is a case where it is handy to have a Linux notebook with multiple > network interfaces (I have a Thinkpad with a built-in gigE and an > ExpressCard gigE added). You can bridge them, and then plug in between > two arbitrary ethernet devices and see for sure what is on the wire. > > If the packets go through for a short time after a reboot, I'd suspect > the switch is resetting something after a link state change and then > forgetting about it after a timer runs out. I'm not sure. Even if the switch has forgotten everything, it should still be forwarding broadcast messages from the router. I think you're right that we may just have to get a sniffer out there to see for certain what's going on. _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
