For my tests, I used a Brick Model 300 with seven 10/100 Fast Ethernet interfaces. I assigned three interfaces to the public and private zones and I configured the zones with IP addresses in separate subnets, which forced the Brick to route traffic. To generate HTTP traffic, I used Caw Networks' WebAvalanche 1800 (see sneak preview, "Caw Networks' WebAvalanche Screams and Streams",
for more on WebAvalanche) and WebReflector to simulate Web users and Web servers. I created a transaction using an HTTP 1.1 connection to grab a 5,800-byte file. I ran each test for more than an hour to generate 20 million sessions, and, though I didn't run exhaustive performance testing, the system generated more than 8,000 transactions per second before overrunning the 300 Mbps offered by the three private Fast Ethernet interfaces.
Although I'm reluctant to use the cliché that Lucent eats its own dog food, I do have it on good authority that at least one Lucent SE does eat his own cat food. That said, Greg Shipley and the crew at security consultancy Neohapsis discovered a few problems with how the Bricks running 6.0 code handled TCP state inspection in our last firewall review (see feature, "Cisco Cures the Chicago Blues"). Lucent has addressed those issues and has added other TCP-level features, including sequence-number randomization, which strengthens the servers with predictable initial sequence-number generation. LSMS 7.0 also brings support for T/TCP and allows experimental TCP options.
TCP state checking and TCP ISN randomization.
Highly configurable QoS and bandwidth management.
CLI on both LSMS 7.0 and Brick.
No way to get to a CLI other than through LSMS or serial/modem connections.
Application-filtering configuration is limited.
HTTP application filtering doesn't check syntax.