[c-nsp] MLD snooping

Multicast maillist multicast.query at gmail.com
Tue Nov 9 00:03:53 EST 2010


>
>
> I agree that after learning the group details once, there should not be any
> issues unless there are bugs from host side.  But probability of having
> problems for a query period (Default 125 seconds) immediately after enabling
> MLD snooping can not be ruled out, even if there are no bugs in the
> implementation.
> Else everyswitch should send a general query with 0:0 address as soon as
> MLD snooping is enabled to learn the groups immediately.
>
>
>
> On Mon, Nov 8, 2010 at 3:25 PM, Phil Mayers <p.mayers at imperial.ac.uk>wrote:
>
>> On 11/08/2010 07:27 AM, Multicast maillist wrote:
>>
>>> As per RFC 4541 (Considerations for Internet Group Management Protocol
>>> (IGMP)and Multicast Listener Discovery (MLD) Snooping Switches), it is
>>> inferred that forwarding criteria for all multicast IPv6 address (except
>>> ff02::1) is always based on group database as MLD is mandated for all the
>>> multicast v6 address.
>>>
>>> As per this, there is no special consideration for solicited multicast
>>> addresses or multicast addresses used for protocol control traffic.
>>>
>>> I feel this could cause issues in protocol adjacency maintenance or DAD
>>> process.
>>>
>>
>> Not in the absence of bugs. You are REQUIRED to join the relevant group
>> for the address you are performing DAD on; see RFC 2461 section 7.2.1
>>
>> The post you link to is talking about a virtual IP on a BigIP; if I had to
>> guess I'd say the BigIP is (was, since the post is two years old) buggy.
>>
>> At a quick glance I'm not sure how IOS handles OSPFv3, but it doesn't
>> appear to be a problem.
>>
>> Shouldn’t the MLD snooping enabled switch forward the traffic for
>> solicited
>> multicast address and protocol control packets to all the ports of VLAN?
>>
>>
>> IPv6 subnets can potentially be huge - millions of hosts. Flooding ND and
>> DAD requests to all ports may simply not work under those circumstances -
>> there may be hundreds of packets/second of such traffic.
>>
>> The expired draft you link to seemed primarily concerned with soft-state
>> size in MLD-snooping switches, although it does mention robustness. Frankly
>> from a forward-looking point of view, I think "RAM is cheap" is a better
>> argument than "bandwidth is cheap".
>>
>> Personally I've never seen MLD snooping as a failure mode; perhaps others
>> can comment.
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>
>


More information about the cisco-nsp mailing list