rity context is written to the peer unit. You must enter the command in the security context on the unit where the security context appears in the active state. You should rarely, if ever, need to use the write standby command. The command should only be necessary if you've issued commands on the secondary ASA causing them to be out of sync. The firewalls will sync themselves under normal operation. If, upon reading this, you're wondering "What's the point?" I'm with you. In addition to these limitations, active/active scenarios must be carefully managed SO that the com- bined throughput of both firewalls does not exceed the capacity of one physical unit. If one unit were to fail, all traffic would traverse the other. If you've got more than half capacity running on both, you'll oversubscribe the single unit when failover occurs. I don't recommend active/active scenarios using ASAs, because I'm not a fan of splitting traffic for the sake of keeping devices inline. Since no capacity is gained (when properly configured), and throughput does not increase, I rarely recommend active/active fail- over. That said, there could be situations where you put all your latency-sensitive traffic on one side and your heavy slow traffic on the other, but usually you'll end up recom- bining this traffic on the other side of the firewalls anyway. I do like having options, though. If you're hell-bent on using active/active, here's how to go about it. Active/active mode is created by configuring contexts into one of two groups, which you do with the failover group group# command: ASA-5540 b(config)# failover group ? configure mode commands/options: <1-2> group number There can only be two groups-one for each physical ASA in the failover pair: -5540(config)# failover group 1 40(config-fover-group): ? Failover Failover User Group configuration mode: Help for user Failover Group configuration commands interface-policy Set the policy for failover due to interface failures Specify the virtual mac address for a physical interface Remove us