[j-nsp] Negative ARP caching, on an MX router (again)

Saku Ytti saku at ytti.fi
Tue Apr 4 07:15:20 EDT 2017


Hey Clarke,


> (a) Get a request from an incoming packet that would trigger an ARP request
> to go out.

This is packet hitting route of 'rslv' type. Packets hitting this
route are punted to software.

> (b) If the router does not get a response back after X number of tries in Y
> number of seconds, put some type of dummy MAC address in the ARP cache that
> can be easily sinkholed.

After 'rslv' type route has been hit, ARP will be generated and FIB is
updated, changing the route's type from 'rslv' to 'hold'.
Packets hitting 'hold' are dropped in hardware, not punted.

> (c) Stay in this state for Z number of seconds, before flushing that dummy
> MAC address out of the cache, and then re-enabling ARP for that particular
> address.

Route stays in 'hold' in my research is just shy of 4s.

So it looks like the mechanism you want, is the mechanism that exist,
but you probably want 4s to be longer, it is not configurable to my
knowledge.

> (d) In addition, the router would passively listen for packets coming into
> the L3 interface that would overwrite the dummy MAC address in the ARP cache
> with a (hopefully) legitimate MAC address, which would allow the process to
> exit out of the above state, without waiting for the above "Z" timer to
> expire.

The packets above are not from the host not having ARP cache entry,
they are someone trying to send that host packets. The packets coming
from the host itself, wouldn't be going 'rslv' FIB entry, they
wouldn't be going to itself. It would be some normal adjacency going
to google or what not in hardware. So that would already work just
fine. The response packet, of course would trigger the resolution.

Usually this is not a problem, because usually you'll learn the hosts
MAC before it sends you packets, because it'll first need to know your
MAC, and it discovering your MAC, you'll discover its.
So usually host=>net, is not your concern, net=>host is your concern,
and the mechanism you described, seems to already exist.

-- 
  ++ytti


More information about the juniper-nsp mailing list