[f-nsp] BGP Sanity check please...

Peter Clark pclark at raindance.com
Wed Nov 23 16:01:22 EST 2005


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: foundry-nsp-bounces at puck.nether.net
[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




More information about the foundry-nsp mailing list