nanog 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 routing.)

--Ricky


Current thread: