mailing list archives
Re: IPV6 in enterprise best practices/white papaers
From: Karl Auer <kauer () biplane com au>
Date: Wed, 30 Jan 2013 17:43:38 +1100
On Wed, 2013-01-30 at 06:41 +0200, Jussi Peltola wrote:
On Tue, Jan 29, 2013 at 09:07:57PM +1100, Karl Auer wrote:
Also, if a switch does not do MLD snooping, it will flood multicast to
all ports. You lose one of the major benefits of IPv6 multicast - less
NDP multicast has scaling issues, and I'd not be surprised if switches
will soon stop learning it and flood all NDP multicasts to save space
for the users' higher-traffic multicast groups.
Can you be more specific about these scaling issues? Seems to me that
each node is in relatively few multicast groups - one per interface (all
link-local hosts), plus one per address (solicited node multicast), less
if SLAAC is being used, because one SNMA is used for both the link local
address and the SLAAC address. Some nodes may be participating in other
groups - routers, for example, will also be in the all link-local
routers group, and maybe things like the DHCPv6 all servers and relays
group. If the node is doing temporary addressing, there will be an
additional solicited node multicast address in play during the
changeover. So a typical node in a subnet will be in three, maybe four
groups. I'm guessing that's NOT the scalability problem you are talking
if it is interesting. NDP multicast addresses, on the other hand, allow
for the device to program only the multicast MACs it is interested about
in the ethernet chipset, so the CPU will never see the useless packets.
Yep - belt and braces. But that multicast packet still went over the
wire as far as the NIC, and while it was doing that, other traffic was
not able to use the wire. So getting that multicast traffic off the wire
altogether is a Good Thing, and the place for that filtering to happen
is in the switch.
unduly burdened. You will also not need to burden your network with
multicast groups (=state) to save hauling a few useless packets around.
As long as it's a few, true. But one of the aims of moving to multicast
was to enable larger subnets. That "few useless packets" can turn into a
LOT of useless packets when there are a few hundred or a few thousand
nodes on the subnet.
If the WLAN implements MLD snooping, an NDP broadcast is unlikely to be
listened to by more than one host; a smart AP could deliver it like a
unicast frame at a high rate to said single client.
How does the behaviour of this AP differ in principle from the behaviour
of a switch doing MLD snooping and delivering multicast packets only to
listeners in the particular group (and for the same reason)?
than have the whole wired switch network learn a large amount of
multicast groups that churn each time the client roams to a new AP.
Why is it a large amount? See above - it's probably three or four per
host. And they only churn when a client moves into or away from a
connection point (AP or switch port). Most things connected to switch
ports won't churn that much.
Karl Auer (kauer () biplane com au)
GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Re: IPV6 in enterprise best practices/white papaers Eugeniu Patrascu (Jan 28)
Re: IPV6 in enterprise best practices/white papaers Harald Koch (Jan 30)
Re: IPV6 in enterprise best practices/white papaers joel jaeggli (Jan 30)
Re: IPV6 in enterprise best practices/white papaers Owen DeLong (Jan 30)
Re: IPV6 in enterprise best practices/white papaers Eugeniu Patrascu (Jan 29)
Re: IPV6 in enterprise best practices/white papaers Joe Maimon (Jan 28)