Mailing List Archive

Depending on how much traffic you'll be pushing I'd seriously consider
going with a JetCore set-up, since 3 full views and a number of smaller
peers makes this a rather important little edge box. Depending on
traffic levels you might get a reasonably long way, but in case of DDoS
traffic or other unusual amounts of traffic hitting the ACLs or CPU in
another way, you're gone when using the IronCore set-up.
All ACL processing is handled in software through the CPU, on top of
things like ICMP generation/processing, and it's able to very
effectively bring a box down to it's knees in no-time when under attack
or abnormal circumstances. I'd consider either JetCore or a dedicated
Layer 3 router with the NI as a simpler pure Layer2/basic Layer3 device
behind that.

Cheers,

--
---
Erik Haagsman
Network Architect
We Dare BV
Tel: +31(0)10-7507008
Fax: +31(0)10-7507005
http://www.we-dare.nl


On Wed, 2005-11-23 at 17:18 +0000, Howard Jones wrote:
> Hi,
>
> We're considering aquiring a pair NetIron 400 routers to use for
> Internet transit. It will be for 2-3 full views per router, plus private
> peering, all on Gig-E. I just wanted to ask the collective voice of
> experience if this type of setup is a good idea. Has anyone else already
> suffered from putting these devices in this situation?
>
> The provisional spec is NI400, NI4GMR (2), BxG and B24E in each box.
>
> Thanks in advance for any warnings, or advice, you could offer...
>
> Cheers,
>
> Howie
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp

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. 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.
ACL accounting is enabled. In this case, the device changes the ACL mode
on all interfaces to flow-based ACLs. ACL accounting is disabled by
default on JetCore devices and IronCore devices. The enable-acl-counter
command at the global CONFIG level enables ACL accounting.
Also see info on how fragmented packets are handled


http://www.foundrynet.com/services/documentation/ecmg/ACL-rule-based.htm
l


Peter Clark
Senior Network Engineer

Raindance
Louisville, Colorado
303.928.2443
www.raindance.com


-----Original Message-----
From: foundry-nsp-bounces@puck.nether.net
[mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Erik Haagsman
Sent: Wednesday, November 23, 2005 10:12 AM
To: foundry-nsp at puck.nether.net
Subject: Re: [f-nsp] BGP Sanity check please...

Depending on how much traffic you'll be pushing I'd seriously consider
going with a JetCore set-up, since 3 full views and a number of smaller
peers makes this a rather important little edge box. Depending on
traffic levels you might get a reasonably long way, but in case of DDoS
traffic or other unusual amounts of traffic hitting the ACLs or CPU in
another way, you're gone when using the IronCore set-up.
All ACL processing is handled in software through the CPU, on top of
things like ICMP generation/processing, and it's able to very
effectively bring a box down to it's knees in no-time when under attack
or abnormal circumstances. I'd consider either JetCore or a dedicated
Layer 3 router with the NI as a simpler pure Layer2/basic Layer3 device
behind that.

Cheers,

--
---
Erik Haagsman
Network Architect
We Dare BV
Tel: +31(0)10-7507008
Fax: +31(0)10-7507005
http://www.we-dare.nl


On Wed, 2005-11-23 at 17:18 +0000, Howard Jones wrote:
> Hi,
>
> We're considering aquiring a pair NetIron 400 routers to use for
> Internet transit. It will be for 2-3 full views per router, plus
private
> peering, all on Gig-E. I just wanted to ask the collective voice of
> experience if this type of setup is a good idea. Has anyone else
already
> suffered from putting these devices in this situation?
>
> The provisional spec is NI400, NI4GMR (2), BxG and B24E in each box.
>
> Thanks in advance for any warnings, or advice, you could offer...
>
> Cheers,
>
> Howie
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp


_______________________________________________
foundry-nsp mailing list
foundry-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

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

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@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