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

[Justin Keery]

The platform is ICX - the traffic in fact passed through three models and
all have the same symptoms (over 40% CPU load and occasional OSPF issues as
a result)

ICX6450, ICX6610 and ICX6650

The ICX platform does not offer granular CPU info - it just describes all
activity as "application".

Frustratingly therefore there is no good info about what the CPU is doing -
all we know is that there's IP6 multicast traffic, and when we shut the
port down the CPU load goes back to normal :-(

*All we want to do is pass through and not process the traffic. No
snooping, no CPU processing at all.*

The continued suggestions are much appreciated!

Thanks!


On 19 November 2014 13:34, Jethro R Binks <jethro.binks at strath.ac.uk> wrote:

> Can you get more details on what in particular in cpu it is doing?  "sh
> cpu detail" or "sh proc cpu" for example (can't remember which are
> supported on whic platform)?
>
> Jethro.
>
>
>
> On Wed, 19 Nov 2014, Justin Keery wrote:
>
> > *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
> >
> > >
> > >
> > >
> >
>
> .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
> Jethro R Binks, Network Manager,
> Information Services Directorate, University Of Strathclyde, Glasgow, UK
>
> The University of Strathclyde is a charitable body, registered in
> Scotland, number SC015263.
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20141119/2bdf8a3b/attachment.html>