[f-nsp] Multicast causing high CPU

Alexey Kouznetsov foundry-list at kouznetsov.com
Tue Mar 10 10:41:24 EDT 2009


Something like 70 Mbit untill visible on TV losts coming (at this point we
have > 95% CPU load). as long as packet size here ~1300 bytes, then it less
then 10K PPS.

Here are some VE interfaces assigned to user's vlans. Each VE interface have
only 1 IP address assigned

like

-----
interface ve 1
 ip address 10.10.31.2/24
 ip pim-sparse
-----

and
-----
interface ve 11
 ip address a.b.c.110/30
 ip pim-sparse
 ip pim border
 management-ip-disable
-----
for interfase where Mcast come from.


/Alexey
2009/3/10 Dimitar Kosadinov <kgb at bginfo.net>

> On Tue, 10 Mar 2009 13:33:08 +030
> How many multicast traffic and do You have secondary ip address on ve
> interface ?
>
>
> Alexey Kouznetsov <foundry-list at kouznetsov.com> wrote:
>
> > Hello!
> >
> > Yes, it is IronCore, not Jet
> >
> > /Alexey
> >
> > 2009/3/7 Peter Olsen <Peter.Olsen at globalconnect.dk>
> >
> > >  Is it IronCore mgmt module ?
> > >
> > > If yes, it is properly even worse.
> > >
> > > We discussed this in legth with foundry. To my opinion it is a design
> bug:
> > > stating wire speed packet forward performance and then having
> limitations
> > > like this.
> > > I don't know if there is a fix for you. But we gave up in the end, and
> as
> > > we for other reasons as well needed bigger boxes we have replaced
> nearly all
> > > JetCore with XMR/MLX
> > >
> > >
> > > *Med venlig hilsen/Best regards
> > >
> > > **Peter Olsen
> > > **CTO
> > > **D: +45 7730 3122
> > > **M: +45 2726 3122
> > > *
> > >
> > >
> > >  ------------------------------
> > > *From:* Alexey Kouznetsov [mailto:foundry-list at kouznetsov.com]
> > > *Sent:* 7. marts 2009 14:58
> > > *To:* Peter Olsen
> > > *Subject:* Re: [f-nsp] Multicast causing high CPU
> > >
> > >   Thank you, for your replay Peter!
> > >
> > > This is no Jet core... AFAIK Jet core will be J-BxGMR4 and CPU
> protection
> > > is not available in our version. As far as I can see it takes 100%CPU
> at
> > > less 10kpps, not 200k
> > > Active management module:
> > >   466 MHz Power PC processor 750 (version 8/8302) 66 MHz bus
> > >   512 KB boot flash memory
> > >  8192 KB code flash memory
> > >   256 KB SRAM
> > >   256 MB DRAM
> > > So, As far as I  can see only hardware upgrade is the possible solution
> ?
> > >
> > > /Alexey
> > >
> > > 2009/3/7 Peter Olsen <Peter.Olsen at globalconnect.dk>
> > >
> > >>  JetCore FPGA can handle around 200.000pps broadcast/multicast before
> you
> > >> have ~80-100% CPU load as far as L2 is concerned
> > >> All packets is handled by CPU by default.
> > >> You can play around with the CPU protection features but to my
> experience
> > >> it have limited impact (and limited success as far as CPU load is
> concerned)
> > >> I guess this is kind of architecture limitation in JetCore.
> > >>
> > >> It is even worse if you have the same mac adress arriving from two
> > >> different directions, e.g. hitting two port at the same time. (will
> happen
> > >> if you have a L2 loop), then 99% CPU load will happen at very load
> pps. In
> > >> this case it is caused by the mac learning process eating all CPU
> > >> resources. This behaviour makes JetCore L2 very sensitive to layer2
> loops.
> > >>
> > >> For us it was first efficiently fixed going to MLX/XMR where
> > >> CPU-protection feature is very efficient and you can force all
> > >> braodcast/multicast packets to stay in hardware for forwarding.
> XMR/MLX can
> > >> also handle much more than 200.000pps in CPU
> > >>
> > >> br,
> > >> Peter
> > >>
> > >>
> > >
> >
>
>
> --
>  <kgb at bginfo.net>
> _______________________________________________
> 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/20090310/debf3ab5/attachment.html>


More information about the foundry-nsp mailing list