Post-exhaustion system state (M_RTABLE held at its 390M type limit by
~3.05M permanent rtmask nodes; nothing can free them short of reboot):

$ route add -host 192.0.2.123 127.0.0.1
route: getifaddrs: Cannot allocate memory
route: writing to routing socket: No buffer space available
add host 192.0.2.123: gateway 127.0.0.1: routing table overflow
ROUTEADD_RC=1
$ route add -net 198.51.100.0/24 127.0.0.1
route: writing to routing socket: No buffer space available
add net 198.51.100.0: gateway 127.0.0.1: routing table overflow
ROUTEADD2_RC=1
$ ping -c 1 127.0.0.1        # cached/needing-no-new-route traffic still OK
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.026 ms   PING_RC=0
$ ping -c 1 8.8.8.8          # works via already-cloned gw route
64 bytes from 8.8.8.8: icmp_seq=0 ttl=255 time=5.475 ms    PINGEXT_RC=0
$ vmstat -m | grep routetbl
           routetbl   3.05M    390M       0    390M    3.67M
$ tail -5 /var/log/messages
Sep 11 09:01:53 dfbsd kernel: arpresolve: can't allocate llinfo for 10.0.2.3 rt
Sep 11 09:02:08 dfbsd kernel: arplookup 10.0.2.3 failed: could not allocate llinfo
Sep 11 09:02:08 dfbsd kernel: arpresolve: can't allocate llinfo for 10.0.2.3 rt
Sep 11 09:02:15 dfbsd kernel: arplookup 10.0.2.3 failed: could not allocate llinfo
Sep 11 09:02:15 dfbsd kernel: arpresolve: can't allocate llinfo for 10.0.2.3 rt

=> root can no longer add routes; on-demand llinfo/ARP for new
   neighbors fails; route(8)/getifaddrs degrade.  Recovery: reboot only.