[j-nsp] MX960 ARP issues

John Neiberger jneiberger at gmail.com
Wed Jan 29 11:26:34 EST 2014


On Wed, Jan 29, 2014 at 9: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.

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.


More information about the juniper-nsp mailing list