mailing list archives
Re: IP4 address conservation method
From: "Ricky Beam" <jfbeam () gmail com>
Date: Wed, 05 Jun 2013 18:25:52 -0400
On Wed, 05 Jun 2013 12:06:49 -0400, William Herrin <bill () 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
RE: IP4 address conservation method Christopher Papandreou (Jun 05)