Table A-1 lists the physical attributes of the FWSM.
Table A-1 Physical Attributes
CEF256 line card with a 6-Gbps path to the Switch Fabric Module (if present) or the 32-Gbps shared bus. With 64-byte Ethernet frames, the FWSM supports 2.84 Mpps throughput; with 1500-byte frames, the FWSM supports 5.456 Gbps throughput.
•1 GB RAM.
•128-MB Flash memory.
Modules per switch
Maximum four modules per switch.
If you are using failover, you can still only have four modules per switch even if two of them are in standby mode.
4Because Port Address Translation (PAT) requires a separate translation for each connection, the effective limit of connections using PAT is the translation limit (256K), not the higher connection limit. To use the connection limit, you need to use NAT, which allows multiple connections using the same translation session.
Fixed System Resources
Table A-4 lists the fixed system resources of the FWSM.
3PDM uses two HTTPS connections: one for monitoring that is always present, and one for making configuration changes that is used only when you make changes. If all users are making configuration changes at the same time, then the effective number of PDM users is half the available HTTPS connections.
4This limit includes the following inspection engines that are enabled by default, making the total number of configurable inspection engines 27: TFTP, Sun RPC over UDP, NetBIOS NameServer, XDMCP, and CUSeeMe. The OraServ and RealAudio inspection engines, which are also enabled by default, do not affect this limit.
5In FWSM Version 1.1, the number of TFTP sessions was limited to 1024 sessions.
The FWSM supports approximately 80K rules for the entire system in single mode, and 142K rules for multiple mode.
In multiple context mode, each context supports at most 12,130 rules, but the actual number of rules supported in a context might be less, depending on how many contexts you have. A context belongs to one of 12 pools that offers a maximum of 12,130 rules. The FWSM assigns contexts to the pools in the order they are loaded at startup. For example, if you have 12 contexts, each context is assigned to its own pool, and can use 12,130 rules. If you add one more context, then context number 1 and the new context number 13 are both assigned to pool 1, and can use 12,130 rules divided between them; the other 11 contexts continue to use 12,130 rules each. If you delete contexts, the pool membership does not shift, so you might have some unequal distribution until you reboot, at which time the contexts are evenly distributed.