Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up
Security
F E A T U R E  
Cisco Cures the Chicago Blues

  November 12, 2001
  By Brian Eirich and Greg Shipley

Online Only: Lessons Learned

Spending three months banging our heads on these products did bring some positive results. For instance, we learned a lot about high-availability firewall design.

Here are some of our other observations:

  • NAT is expensive. While the debate rages on about whether to use reserved RFC 1918 addresses, one thing is clear -- NAT (Network Address Translation) stresses the firewalls more than using nonreserved, routable address blocks. The specifics vary from firewall to firewall, but most of the details we were able to receive put NAT overhead at approximately 50 percent. That is, some firewalls can handle twice as many non-NAT connections as NAT ones.

  • Interface autonegotiation can cause big problems. Some firewalls seemed to handle interface speed autonegotiation without problems; others did not. We ran into huge problems, for example, with the Cisco PIX 535 units and autonegotiation. Unless you absolutely need your firewalls to adjust interface speeds dynamically, you should hard set interface speed specifications in your configuration.

  • Use "port-fast" mode on Cisco switches. Putting the Spanning Tree Protocol into port-fast mode on a per-interface level is highly recommended for firewall-attached ports on Cisco switches. We ran headfirst into a number of problems that could have been easily avoided if we had done this to begin with.

  • Be aware of RAM and tuning issues. While the Cisco PIX and the NetScreen-1000 had no problems with 200,000-session tests out of the box, solutions from many other vendors, including Check Point, required some manual tweaking. The average environment probably isn't going to allocate RAM for state-table use. However, if you have an incredibly busy Web environment, surpassing hard-set session counts of 25,000 sessions (the Check Point default limit) is a real possibility. Not having enough RAM built into your firewall could be a real showstopper when that day comes. Organizations should have some idea of their operating ceilings, and potential RAM consumption, before putting HA solutions into production.

  • Gigabit is good. Gigabit solutions might prove beneficial even if your organization doesn't have a gig's worth of traffic. For example, we ran our series of session tests past PIX 535s with 100-Mbps interfaces and then ran the same tests on the same PIX units using Gigabit Ethernet interfaces. The only difference between the two tests were the interface types used on the firewall -- Caw Networks' devices, the switches and every other component remained unchanged. Using the gig interfaces we saw TCP error levels and orphaned session counts drop. While the 100-Mbps to 1000-Mbps media change did not affect the results of the tests massively, the fact that we had "cleaner" gigabit runs is worth noting.

    -- Brian Eirich and Greg Shipley


  •    Page: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | Next Page

    Research and Reports

    Hypervisor Derby
    August 2011

    Network Computing: August 2011

    TechWeb Careers