[j-nsp] MX960 ARP issues
Michael Loftis
mloftis at wgops.com
Wed Jan 29 11:28:48 EST 2014
On Wed, Jan 29, 2014 at 8:08 AM, Chris Adams <cma at cmadams.net> wrote:
> Once upon a time, John Neiberger <jneiberger at gmail.com> 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.
Or in the NIC on the server. I've seen everything from VLAN tags
getting stripped and/or mangled to specific TCP src+dst port
combinations get clobbered by NICs these days, even when in
"promiscuous" mode. I'd try turning off all hardware offload as one
of the troubleshooting steps. Usually this can be done with ethtool.
There's quite a few offload options to turn off. Might even be a bug
in f/ex the HW checksum computation.
>
> 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.
I'll +1 on that too.
More information about the juniper-nsp
mailing list