itches connects the firewalls. One switch connects to each PIX, and the switches are connected to each other, usually with trunks. An example of such a design is shown in Figure 26-3. The link that connects the two PIX firewalls directly is the stateful failover link, which should not be switched if possible. (In the case of the FWSM, this is not possible, as all interfaces are virtual.) Primary Secondary Figure 26-3. Common PIX failover design Cisco recommends that the switch ports used to connect the PIX firewalls be set to spanning-tree portfast. With normal spanning-tree timers, hellos will not be received during the initial spanning-tree states. This might cause a PIX firewall to decide that the remote PIX is not responding, and to initiate a failover. PIX os v7.0 introduces the idea of transparent mode (the normal PIX behavior is called routed mode). In transparent mode, the PIX firewall acts as a bridge. When it's used in this manner, the spanning-tree requirements are different. Consult the Cisco documentation for more information on transparent mode. When a failover occurs, the standby PIX assumes the IP and MAC addresses of all interfaces configured for failover on the active PIX. This is transparent to the network: PIX(config)# sho int e1 I include Hardware Hardware is i82559 ethernet, address is 0050.54ff.1312 PIX(config)# failover active PIX(config)# sho int e1 I include Hardware Hardware is i82559 ethernet, address is 0050.54ff.33c5 Failover PIX failover works SO well that PIX device failures can go unnoticed. When using this feature, it is imperative that the firewalls be managed in some way SO that failures can be resolved. I have seen occasions where a primary PIX failed, and the secondary ran for months, until it, too, failed. When the secondary failed without another PIX to back it up, a complete outage occurred. If you're not monitoring your fire- walls, your network is not as secure as you might think. Using SNMP with network management software such as CiscoWorks or Open- View will keep you 