IP4 address conservation method

Wed Jun 5 22:25:52 UTC 2013

On Wed, 05 Jun 2013 12:06:49 -0400, William Herrin <bill at herrin.us> wrote:
> ... Since the Linux kernel already mishandles arp by
> default, you're probably begging for unexpected behavior. Double down
> on that if the customer controls the server image.

I won't argue against calling Linux "wrong".  However, the linux way of  
dealing with ARP is well tuned for "host" and not "router" duty.  It's  
just not designed for the kernel to maintain huge arp tables for extended  
periods.  Generally, a host speaks to very few L2 neighbors.  Even a  
"server" tends to speak to few of it's L2 neighbors -- esp. for an  
internet service (www, ftp, irc, etc.).  However, a ROUTER speaks to  
everything on most of it's links.  As such, out-of-the-box, linux makes  
for a very BAD router... it's neighbor cache goes "stale" in 30s (avg),  
and entries are dropped on a scale of minutes.  Real Routers(tm) hold on  
to arp's for *hours* -- because broadcast traffic requires CPU attention.

That said, I do use a stripped debian box as an inter-vlan router.  You  
don't want to see the pages of tweaks it's taken to stop it being a  
broadcast storm generator. (and no, "arpd" is stupid hack.)  It's a  
beautiful thing to run "tcpdump ... broadcast" and see no packets!

(And I'm not too happy with the BS 32 interface limit for multicast  
routing.)

--Ricky