[f-nsp] BigIron 4000 and Full Internet Table

[Brent Van Dussen]

We just got our first batch of XMR's installed based on the very 
limitations noted below for our Bigiron platform.  Too early to tell but we 
are excited to have them in operation now.  No more CPU-switching the first 
packet in a flow!! Yay!

-Brent



At 09:58 PM 11/14/2006, Jayabalan Subramanian wrote:
>Hello Gunther,
>
>Your opinion and inputs went a long way in influencing our decision to go
>with MLX. We thank you for that. Will keep you updated on how it performs as
>soon as I get my hands on the MLX.
>
>Regards,
>
>JB
>
>-----Original Message-----
>From: foundry-nsp-bounces at puck.nether.net
>[mailto:foundry-nsp-bounces at puck.nether.net]On Behalf Of Gunther
>Stammwitz
>Sent: Thursday, October 12, 2006 9:59 PM
>To: 'Gerald Krause'; 'Brendan Mannella'
>Cc: foundry-nsp at puck.nether.net
>Subject: Re: [f-nsp] BigIron 4000 and Full Internet Table
>
>
>Hello Gerald,
>
>Why it is true that those system will most probably melt down during a dos
>there are no problems during normal operations:
>
>On a B8GMR3 (so this really is an old M3 and not even a M4) three full bgp
>views and about 30 ebgp-peers are no problem at all: show memory
>Total DRAM: 268378112 bytes
>   Dynamic memory: 243212284 bytes total, 60750176 bytes free, 75% used
>       BGP memory: 83671000 bytes (34%) used from dynamic memory
>
>The cam is a little bit low during peak hours as you can see below:
>show cam ip 1/1 stat
>CAM IP statistics:      free entries    total entries
>            level1:      654             8192
>            level2:      1644            2048
>            level3:      2010            2047
>The use ip net-aggregate and a shorter interval like 5 can resolve this
>problem.
>
>Okay.. During a dos from inside your network that targets many many
>different destinations on the internet the cam will most probably get
>exhausted and if that happens the cpu is being utilized. This is not
>necessarily bad but as soon as there too much load packets will get dropped
>and the bgp-scheduler might be unabl to respond to keepalive requests and so
>on which is not a good thing (tm).
>
>Gunther
>
> > > am hearing issues regarding the flows causing CPU to increase.
> >
> > Ok, that's a complete different thing and where discussed
> > here more than one time before: such systems will melt down
> > when flows growing up (e.g.(d)DOS's) because of the lack of
> > enough CAM space.
> >
> > --
> > Gerald    (ax/tc)
>
>_______________________________________________
>foundry-nsp mailing list
>foundry-nsp at puck.nether.net
>http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
>
>
>
>
>--
>**************** CAUTION - Disclaimer *****************
>This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
>for the use of the addressee(s). If you are not the intended recipient, please
>notify the sender by e-mail and delete the original message. Further, you are
>not to copy, disclose, or distribute this e-mail or its contents to any other
>person and any such actions are unlawful. This e-mail may contain viruses.
>NetMagic Solutions Pvt. Ltd. has taken every reasonable precaution to minimize
>this risk, but is not liable for any damage you may sustain as a result of any
>virus in this e-mail. You should carry out your own virus checks before
>opening the e-mail or attachment. NetMagic Solutions Pvt. Ltd. reserves the
>right to monitor and review the content of all messages sent to or from this
>e-mail address.
>
>Messages sent to or from this e-mail address may be stored on the NetMagic
>Solutions Pvt. Ltd.'s e-mail system.
>***************** End of Disclaimer *******************
>
>_______________________________________________
>foundry-nsp mailing list
>foundry-nsp at puck.nether.net
>http://puck.nether.net/mailman/listinfo/foundry-nsp