[141895] in North American Network Operators' Group
Re: The stupidity of trying to "fix" DHCPv6
daemon@ATHENA.MIT.EDU (Joel Jaeggli)
Mon Jun 13 16:57:48 2011
From: Joel Jaeggli <joelja@bogus.com>
In-Reply-To: <op.vw05dvlhtfhldh@rbeam.xactional.com>
Date: Mon, 13 Jun 2011 13:57:32 -0700
To: Ricky Beam <jfbeam@gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jun 13, 2011, at 12:50 PM, Ricky Beam wrote:
> On Sun, 12 Jun 2011 09:45:01 -0400, Leo Bicknell <bicknell@ufp.org> =
wrote:
>> In a message written on Sun, Jun 12, 2011 at 01:04:41PM +0200, =
Iljitsch van Beijnum wrote:
>>> Like I said before, that would pollute the network with many =
multicasts which can seriously degrade wifi performance.
>>=20
>> Huh? This is no worse than IPv4 where a host comes up and sends a
>> subnet-broadcast to get DHCP.
>=20
> Broadcast !=3D Multicast. esp. when talking about wireless chipsets. =
I've yet to find a wifi chipset that didn't completely fuck-up when =
presented with even a low pps of multicast traffic. Broadcast traffic =
doesn't seem to bother them -- it doesn't attempt to filter them in any =
way, or really pay them any attention. If I had to guess, the chip =
firmware is individually transmitting multicast packets to each peer; a =
broadcast packet is sent once to all peers.
>=20
> I've not had any wireless networks disrupted by broadcast traffic -- =
and with Radware load balancers in the network, there are *plenty* of =
broadcasts (ARP). Just a few 100pps of multicast and the AP fails. =
(linksys, netgear, even cisco... all broadcom crap radios.)
by default the multicast rate is at the lowest supported rate on the ap =
which negatively impacts the performance of everything else.
> --Ricky
>=20
