I have listened to their seminar about this... As the simple L5 firewall
it's not bad, through it realise the fixed set of ruls and defends your
from the simple SMTP attacks only. But anyway, IOS FW is just what 90% of
the customers need...
How would IOS FW perform on Cisco 7x00-class equipment with 100M-to-Gigabit
traffic ?
Rubens Kuhl Jr.
Hmm, you need to perform UPSTREAM traffic, not your internal traffic.
Hope CISCO people answer exact performance (through I can look for it
myself), but really you does need the performance to develop all
incoming/outgoing traffic, this means - if you have E3 upstream, you need
E3 performance.
And it hardly depends of the traffic itself. ACL's does not use much CPU,
but _protocol inspection_ (sorry, there is some other word in IOS for it,
I do not remember exactly) does use a lot of CPU.
Hello All, Sorry for the off topic . But I can't seem
to find anything (that I can get to) about conflicts
between 11.x & 12.x PPP implementations . I have a
customer running ios 11.1 sync serial encaps ppp & his
provider that is running 12.04(?) with proper config
on his end & his end of the link shows (supposedly)UP
My end on the other hand show all signals UP but protocol
down :-{ . actually afaik the provider changed IOS
version down one minor level (12.04 I beleive) & rebooted
the system & the encaps just won't sync . Tia, JimL
Hello All, Thanks a bunch for all the responses .
all have been a help . Tnx, JimL
PS: Even the scolding(s) 
> > I have listened to their seminar about this... As the simple L5 firewall
> > it's not bad, through it realise the fixed set of ruls and defends your
> > from the simple SMTP attacks only. But anyway, IOS FW is just what 90% of
> > the customers need...
>
> How would IOS FW perform on Cisco 7x00-class equipment with 100M-to-Gigabit
> traffic ?
Umm... Very poorly.
At the low end it's acceptable. Gigabit traffic sucks on 7500 series
routers even without any kind of filtering.
The 7000-series routers, if they have an SSE, will do standard and
extended access lists in the switch engine. Now, given the
limitations of CX-FEIP-2TX boards (the only faste boards that will
work in a non-RSP 7000), you are lucky to get 70 mbit/sec through
that. If you have fddi, you can get most of the way to 100 mbit/sec
one way (the CX-FIP cards, which are the only FDDIs that work in a
7000, won't do full-duplex).
The 7500-series routers, you really want to get a VIP2-50 rather than
a 2-40 or lower if you're going to be doing filtering on the linecard.
You can load the fast ethernets up just fine there.
400 mbit/sec seems to be the upper limit of the currently shipping
generation of gigE cards for the 7500 series.
Hope this helps (and standing by for corrections from the #cisco IRC mafia...)
---Rob
<scratching head>
400 mbit != 1 gigabit
I guess the marketing department wins again....
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Patrick Greenwell
"This is our time. It will not come again."
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Robert E. Seastrom wrote:
400 mbit/sec seems to be the upper limit of the currently shipping
generation of gigE cards for the 7500 series.
<scratching head>
400 mbit != 1 gigabit
I guess the marketing department wins again....
Calculate the VIP2 PCI bus bandwidth on a 7500. All this means in this
context is that this implementation is interoperable with other GIG-E
implementations (for some definition of implementation, see CLNS large MTU
and jumbo frame issues).
The card is limited by the PCI bus. It is still a gig-E board, it just
can't go wirespeed.
/vijay
Folks, why all you are saying about the Gigabit traffic for the firewall?
Usially, firewall stand between intranet and internet, and it should
proceed your upstream traffic, not more... And than, it's important to
measure the throughput in packets/per_second, not in the gigabits...
Everything other is true - I suggess no one good firewall can proceed
gigabit traffic at all, and only a few specially designed boxes can
proceed 100Mbit traffic. But just again - it's a rare case when you does
have 100Mbit upstream link.
Alex.
Alex Rudnev observed,
Folks, why all you are saying about the Gigabit traffic for the firewall?
Usially, firewall stand between intranet and internet, and it should
proceed your upstream traffic, not more... And than, it's important to
measure the throughput in packets/per_second, not in the gigabits...
Everything other is true - I suggess no one good firewall can proceed
gigabit traffic at all, and only a few specially designed boxes can
proceed 100Mbit traffic. But just again - it's a rare case when you does
have 100Mbit upstream link.
All good points. Something else to consider: with increasing cryptographic
security requirements, the "firewall" (ambiguous term as it is, but let's
think of it as a stateful packet screen -- the major approach at high
speed) is not the only device between you and the outside. It's worth
thinking of:
Bastion hosts -- not trusted with crypto keys
Security gateways -- trusted to do encryption
IPsec gateways
SSL/TLS proxies
Conduits with access lists -- for host-to-host encryption, where
the firewall wouldn't add value
There is also the very murky area where logging and intrusion detection
mix, and whether they can operate at these speeds/
Perfectly...
Date: Mon, 27 Sep 1999 08:27:27 -0400
From: Howard C. Berkowitz <hcb@clark.net>
To: nanog@merit.edu
Subject: "firewalls" at high speed -- was Re: FW: your mail
...
All good points. Something else to consider: with increasing cryptographic
security requirements, the "firewall" (ambiguous term as it is, but let's
think of it as a stateful packet screen -- the major approach at high
speed) is not the only device between you and the outside. It's worth
thinking of:
Bastion hosts -- not trusted with crypto keys
Security gateways -- trusted to do encryption
IPsec gateways
SSL/TLS proxies
Conduits with access lists -- for host-to-host encryption, where
the firewall wouldn't add value
There is also the very murky area where logging and intrusion detection
mix, and whether they can operate at these speeds/
Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)