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