I don't want to mislead anyone, so let me clarify. We are an ASP, not an ISP or NSP. So, I would suspect our traffic loads are not as high as yours. We typically run up to 40 mbps. We don't run service provider code, just the IP only software. On IronCore, prior to version 7.6, ACLs were software-based only, so they were processed through the CPU. A few years back, we had much higher traffic rates, up to 200 mbps. At that time, we were also in the streaming business. I don't recall ever seeing any latency stability issues. CPU on the NetIrons remain at a steady 2 percent, unless a BGP peer is re-established or an SSH key exchange is occurring, then CPU goes up to 90 something percent. You might want to look into whether you were running ACLs in software-based mode.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Erik Haagsman Sent: Wednesday, November 23, 2005 1:34 PM To: foundry-nsp at puck.nether.net Subject: RE: [f-nsp] BGP Sanity check please... Hi Peter, On Wed, 2005-11-23 at 11:53 -0700, Peter Clark wrote: > I somewhat disagree. I would also go with JetCore, as IronCore is EoL > and has less memory. However, I've been using two IronCore NetIron > 800's for almost six years, with full BGP route tables with two tier > one providers, as well as IBGP, ACLs and OSPF, multiple OC3s, and have > not had any performance issues. Even during sustained DDoS attacks with high packet rates...? I found the platform to be rock-solid as a peering/BGP router under normal circumstances until a big DoS hit and it just sort of melted down, which was the main reason we switched to separate layer2 / layer3 devices in the first place. Also latency seemed to be very instable and irratic under higher traffic loads, which in our case as an NSP with quite a bit of gamehosting customers, was a big problem. > ACLs are not processed entirely in CPU unless software-based ACLs are > enabled, or it is an outbound ACL. If you use hardware-based, packets > are not sent to the CPU, unless... > > The packet does not have any Layer 2 or Layer 3 forwarding information. > The ACL entry is using the log option. > The ACL entry matches on the ICMP type. > The outbound interface (if other than an NPA POS 0C-48 port) has an > outbound ACL. In this case, the device changes the ACL mode on the > interface to flow-based ACLs. Do you know if this has changed over software versions as well, or is this the case for all full layer3 and service provider images...? Last time I remember putting an ACL without logging on a public IP on one of our NetIrons, portscans and other malicious traffic pulled the CPU up to 50%, on a pretty recent sw image (I believe a 7.6.05 or 7.7.xx image). Cheers, -- Erik Haagsman Network Architect We Dare BV tel: +31.10.7507008 fax: +31.10.7507005 http://www.we-dare.nl _______________________________________________ foundry-nsp mailing list foundry-nsp at puck.nether.net http://puck.nether.net/mailman/listinfo/foundry-nsp
