How we did it

How we tested he Juniper Secure Services Gateway 520.

We tested the Juniper Secure Services Gateway 520 by putting it into production in our Tucson, Ariz., lab on an Internet DS3 connection supplied through MCI. We brought up the SSG 520 on the DS3 and then started up a BGP session with the MCI network.

Because the SSG family can’t handle a full Internet feed, we asked MCI to limit our BGP session to a subset of the full routing table, about 1,000 entries.  Then we attached the SSG to our external network and brought it into the OSPF routing fabric with our other LAN and WAN routers. We tested route redistribution by sending the BGP entries into the OSPF side and verifying that our Cisco, Lucent, Nokia, and Extreme routers could all successfully peer with the SSG 520.

We then added the SSG 520 to Juniper’s management system, NetScreen Security Manager, running on a Linux server in our network. Although we accomplished the initial configuration with a combination of the Juniper CLI and Web-based GUI, we used NetScreen Security Manager for all our other configuration tasks.

To test the firewall side of the SSG 520, we moved our security policy upstream from internal routers and pushed it all to the SSG 520. Then we let the SSG 520 act as the firewall for our entire network. Because the SSG 520 uses the well-tested ScreenOS v5.1 for its firewall, we didn’t do any specific firewall-security tests. However, we tuned up our IDS sensor inside the firewall to make sure that nothing got through that shouldn’t have.

After a week of testing in production, we pulled the SSG 520 out of service and put it to the Spirent torture test. Using four Spirent Avalanche/Reflector appliances, we stress-tested the SSG 520 with HTTP traffic across four gigabit copper interfaces.

We ran three main sets of tests, designed to measure TCP connection rate, steady-state HTTP throughput with short connections, and LAN-to-LAN throughput with long-lived connections.

In each case, we ran the tests twice, once with a firewall policy and then again including Juniper’s intrusion-prevention system, which they call “Deep Inspection.” For the IPS part of the test, we used HTTP streams and enabled all of the HTTP critical and major signature and protocol anomaly rules.

Return to Juniper Clear Choice Test