|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
To: nanog@nanog.org Date: Wed, 05 Jun 2013 18:25:52 -0400 From: "Ricky Beam" <jfbeam@gmail.com> In-Reply-To: <CAP-guGV_VihKzm1b6u29nkT0WL6=QE8=hLOKz4k1pg6UNbrK5g@mail.gmail.com> Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org 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
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |