Page MenuHomeFreeBSD

arp: bring back reject/discard functionalify for arp entries.

Authored by melifaro on Sep 30 2021, 9:37 PM.


Group Reviewers

arp(8) has the following properties of specifying arp entries:

     -s hostname ether_addr
             Create an ARP entry for the host called hostname with the
             Ethernet address ether_addr.  The Ethernet address is given as
             If the reject keyword is specified the entry will be marked so
             that traffic to the host will be discarded and the sender will be
             notified the host is unreachable.  The blackhole keyword is
             similar in that traffic is discarded but the sender is not
             notified.  These can be used to block external traffic to a host
             without using a firewall.

Bring back the support of this behaviour in the kernel.

Test Plan
21:58 [0] m@devel2 s arp -s 00:00:00:00:00:00 reject
21:58 [0] m@devel2 arp -an | grep
? ( at (incomplete) on vtnet0 permanent rejected [ethernet]

21:59 [0] m@devel2 ping
PING ( 56 data bytes
ping: sendto: No route to host
22:00 [0] m@devel2 ping -c1
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=64 time=0.480 ms

--- ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.480/0.480/0.480/0.000 ms
22:00 [0] m@devel2 s arp -s 00:00:00:00:00:00 blackhole
22:00 [0] m@devel2 arp -an | grep
? ( at (incomplete) on vtnet0 permanent discarded [ethernet]

Diff Detail

rS FreeBSD src repository - subversion
Lint OK
No Unit Test Coverage
Build Status
Buildable 41901
Build 38789: arc lint + arc unit

Event Timeline

melifaro edited the test plan for this revision. (Show Details)
melifaro added a reviewer: network.
melifaro edited the summary of this revision. (Show Details)

update terminology.

melifaro retitled this revision from arp: bring back reject/blackhole functionalify for arp entries. to arp: bring back reject/discard functionalify for arp entries..Sep 30 2021, 11:01 PM
melifaro edited the test plan for this revision. (Show Details)
glebius added inline comments.

Is it possible first unlock then m_freem?

Reflect glebius@ comments.

Thank you for reimplementing this really valuable feature.
Is anything that prevents committing it ? I am eagerly waiting to cherry-pick it to stable/13 to kill some L2 traffic on the border router.

This revision is now accepted and ready to land.Nov 2 2021, 7:03 PM

Thanks for this patch. I had the opportunity to test it a bit on two routers running the most recent stable/13 and looks like there is a problem with forwarded packets, so the solution is fine for the host but not for the router. While the entry is being added on the router, then it disappears and normal arp resolution begins which after a few seconds results in acquiring the correct arp. Steps to reproduce:

[rtr] ~# arp -S x.x.221.128 00:00:00:00:00:00 reject
x.x.221.128 (x.x.221.128) deleted
[rtr] ~# arp -n x.x.221.128
? (x.x.221.128) at (incomplete) on vlan2 permanent rejected [vlan]

Now the traffic is rather blocked than discarded or rejected (no difference between reject and blackhole keywords) . Some incoming traffic to the host x.x.221.128 received on another interface of the router will begin arp resolution on vlan2 and after a couple of seconds we get:

[rtr] ~# arp -n x.x.x.128
? (x.x.x.128) at 0x:5x:0x:33:f5:10 on vlan2 permanent rejected [vlan]

Since then normal forwarding or maybe rather fast-forwarding of the traffic to this host is performed.