[f-nsp] ANY IDEAS - IP6 multicast traffic causing severe CPU load issue (on ICX)

[Justin Keery]

*Suggestion from Ronald and Rajesh THANKS- more comments below*

*From Ronald:* Take a look at these:
http://www.brocade.com/downloads/documents/product_manuals/B_FastIron/FastIron_08000a_MulticastGuide.pdf


*That's definitely better documentation than I've found before, thanks a
lot.We did put in commands to disable multicast IGMP (v4) and MLD (v6)
snooping.*
*It seems not to have worked - Is there something else we're missing?*

vlan 682 by port
 tagged ethe 1/2/1 to 1/2/3
 multicast disable-igmp-snoop <- did not help
 multicast6 disable-mld-snoop <- did not help


*Rajesh:  *"If you have genuine multicast traffic in your network then you
can apply  Broadcast and multicast limit on the up links. Else stop the
cast by ACL."

The granularity seems to be that we can't set a limit of less than
64Mbit/sec (traffic is less than that). We tried to block IP6 altogether
via ACL - no effect.

*Is it possible that we need to remove/rebuild the VLAN or disable/enable
the interface before the Multicast or ACL settings will take effect?*

*Is there some way to simply forward the multicast traffic as layer 2 and
force the CPU to ignore it, which is what we want!*


On 19 November 2014 12:31, Ronald Esveld <ronald.esveld at qi.nl> wrote:

>   Hi Justin,
>
>
>
> Take a look at these:
> http://www.brocade.com/downloads/documents/product_manuals/B_FastIron/FastIron_08000a_MulticastGuide.pdf
>
>
>
> This one helps out.
>
> Ronald
>
>
>
> *Van:* foundry-nsp [mailto:foundry-nsp-bounces at puck.nether.net] *Namens *Justin
> Keery
> *Verzonden:* woensdag 19 november 2014 11:04
> *Aan:* foundry-nsp at puck.nether.net
> *Onderwerp:* [f-nsp] ANY IDEAS - IP6 multicast traffic causing severe CPU
> load issue (on ICX)
>
>
>
>
> Hi folks, any ideas about this?
>
> The switches affected by this include ICX6540, 6610 and 6650 all of which
> were involved in transporting the VLAN described below.
>
> IP6 multcast traffic (less than 20Mbit/sec, discovered with wireshark on a
> mirror port) on VLAN682 was causing >40% CPU load on all switches where
> this VLAN was configured, even though there is no IP virtual interface in
> this VLAN. At one point there was a brief but serious OSPF failure whilst
> this condition was present.
>
> With the ingress port shut down the CPU load returned to 1%.
>
> We tried to disable IP4 and IP6 igmp / mld snooping, this had no effect.
> We then added a router-interface so we could add an IP6 ACL to filter *all*
> IP6 traffic - again no effect
>
> vlan 682 name KARMARAMA_L2_ONEA809159_682 by port
>  tagged ethe 1/2/1 to 1/2/3
>  router-interface ve 682 <- added later so we could implement an ACL
>  multicast disable-igmp-snoop <- did not help
>  multicast6 disable-mld-snoop <- did not help
>
>
>
> *We need a way to make sure that IP6 multicasts on a VLAN won't overload
> the CPU on any switch with that VLAN present - ideally filter that VLAN
> from the CPU altogether!*
>
>
>
> Any ideas?
>
>
>
> Thanks
>
>
>
> Justin
>
>
>
>
>
> Met vriendelijke groet, With kind regards,
>
> [image: http://www.qi.nl]
>
> Ronald Esveld
> senior network engineer
>
> *Qi ict*
> Delftechpark 35-37
> Postbus 402, 2600 AK Delft
>
>   T : +31 15 888 0 444  F : +31 15 888 0 445  E : ronald.esveld at qi.nl  I :
> http://www.qi.nl
>
> Qi ict neemt strategisch belang in INOVATIV
> <https://www.qi.nl/actueel/qi-ict-neemt-strategisch-belang-in-inovativ>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20141119/b3d7e544/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image897cd8.JPG
Type: image/jpeg
Size: 14702 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20141119/b3d7e544/attachment.jpe>