Foundry ServerIron: Layer 4-7 Switch and Load Balancer Family

01 /What ServerIron was

Foundry Networks introduced ServerIron around 1998 and marketed it as a "web switch": a Layer 2/3 Ethernet switch with a Layer 4 through 7 traffic management engine on top. The core job was server load balancing, one virtual IP in front of a pool of real servers with health checks removing failed members. Around that Foundry layered global server load balancing, firewall load balancing, transparent cache switching and, on later models, SSL acceleration.

The pitch against the server-based appliances of the dot-com build-out was that switching and load balancing happened in one box at wire speed. ServerIron became the best known Foundry product outside campus switching, and its SLB configuration guide was among the most linked documents on this domain. Corporate context is on the company history page.

02 /Generations, 1998 to the ADX

Model naming changed several times and datasheets from different years describe overlapping products. The table is a careful summary. Port counts and throughput figures are omitted on purpose because they varied by hardware revision and software release.

03 /Roles in the network

A ServerIron sat between the routed edge and the server farm. In the basic role it owned the VIPs and forwarded to real servers, either rewriting addresses (NAT mode) or using direct server return. As a GSLB device it acted as a DNS proxy in front of the authoritative servers and reordered answers by site health and proximity. In firewall load balancing two units formed a sandwich around a group of firewalls so that both directions of a flow crossed the same firewall. Transparent cache switching redirected port 80 traffic to a cache farm without client configuration. Persistence and Layer 7 switching applied to all of these.

04 /Configuration model: real, virtual, port, bind

The CLI came from IronWare and looked like the FastIron and BigIron CLI, with an SLB vocabulary added. Four objects carried almost every configuration: server real for a backend, server virtual for a VIP, port under either to open a service, and bind to tie a virtual port to real ports. Health checks were attached per port, and a predictor keyword chose the balancing method.

server real web1 10.1.1.11
 port http
server real web2 10.1.1.12
 port http
server virtual www 192.0.2.10
 port http
 bind http web1 http web2 http
show server real
show server virtual
show server bind
show server session

05 /SwitchBack and direct server return

Foundry marketed its direct server return mode as SwitchBack. The ServerIron rewrote only the destination MAC address of inbound packets; the real server carried the VIP on a loopback and answered the client directly, so return traffic never crossed the switch. The term appears in press material from the early 2000s. It was a marketing name for a standard technique, not a proprietary protocol, and it disabled Layer 7 features that needed both directions of the flow.

06 /Where the documentation lived

The ServerIron SLB guide, the switch and router command references and per-release datasheets sat under the products and services documentation trees of the old site, and forum posts still point at those paths. Those URLs now resolve to this archive. The CLI command reference page collects the show and configuration commands that still matter, and password recovery covers a locked second-hand unit.

07 /Running one today

A chassis ServerIron draws several hundred watts and its fans are loud enough to rule out a living room. Fixed units are quieter but still office-grade. Software updates ended with the ADX end of life, so no security fixes exist and the SSL stack on any unit is limited to ciphers that browsers now reject. The realistic uses are a lab for learning SLB concepts, a Layer 4 balancer for internal test traffic, or a museum piece. Do not place one on the public internet; see the security advisories page.