Cisco Network Security Troubleshooting Handbook

Step 1.

Ensure that you are running a supported version of code on your switch for FWSM. You can find this information in the Release note of the corresponding version. For example, for FWSM Version 2.3(2), you can find the "Chassis System Requirements" from the following link: http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/mod_icn/fwsm/fwsm_2_3/fwsm_rn/fwsmrns.htm#wp73044

Step 2.

Ensure that the FWSM can coexist with other blades in the same chassis. Refer to the Catalyst 6500 Release note in the following location:

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/relnotes/index.htm In addition, you can look at the Software Advisor for additional information (only available to registered customers):

http://www.cisco.com/pcgi-bin/Support/CompNav/Index.pl

Beginning with Native IOS Version 12.2(14)SY, FWSM, VPN, IDSM-2, and NAM modules can coexist in the same chassis. There is no CatOS available to support all these modules in the same chassis.

Step 3.

If you are running CatOS (Hybrid) code on your switch, reset the configuration for the slot that is occupied by the FWSM module. To do this, use the following commands:

1. Type set module power down mod to power down the FWSM.

2. Clear the switch's configuration associated with that slot and to power up the module.

Step 4.

For additional troubleshooting refer to Chapter 15, "Troubleshooting IDSM-2 Blade on Switch," and consult the following links:

For Hybrid Mode, refer to the following link: http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a0080134734.shtml

For Native IOS, refer to the following link: http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801751d7.shtml

First (cf:1)

16

Maintenance Partition

Second (cf:2)

7

Network Configuration

Third (cf:3)

1

Crash Dump Partition

Fourth (cf:4)

20

Application Partition1FWSM file systemimage, configuration, and PDM file

Fifth (cf:5)

20

Application Partition2FWSM file systemimage, configuration, and PDM file

Sixth (cf:6)

64

Reserved

Router# show boot device module 6 [mod:6 ]: cf:4 Router#

System> telnet 127.0.0.31 Maintenance image localhost.localdomain login: root Password: cisco Maintenance image version: 1.1(0.4) root@localhost.localdomain#

root/Cisco

Used for normal access. It provides a restricted shell and allows users to upgrade Application Partition images. It also allows users to display version/image information.

guest/cisco

Guest account is meant for Cisco Support team operations, such as retrieving the diagnostic results and upgrading the BIOS image. Guest account access can be enabled/disabled from the root account. However, guests cannot change the root password. So, a guest is a superset of root level commands.

The default password for root and guest accounts is Cisco, and this can be reset by the passwd command from the maintenance partition. This can also be reset on the Application partition.

ip

To set IP parameters (root and guest)

show

To show system parameters (root and guest)

passwd

To set the password for the current user (root and guest)

upgrade

To download and install new application image (root and guest)

clear ip

To clear network configuration for the interface (root and guest)

clear log upgrade

To clear the log file for upgrade operation (root and guest)

logout

To log out of the shell (root and guest)

passwd-guest

To set password for guest account (root)

enable-guest

To enable the guest account (root)

Disable-guest

To disable the guest account (root)

clear passwd

To clear the enable password for application (root and guest)

upgrade-bios

To install new BIOS image (guest)

debug

To use Network Processor (NP) debug utility (guest)

show ip

Shows network configuration for the interface (root and guest)

show images

Shows images on the application partition (root and guest)

show version

Shows system parameters (root and guest)

show log upgrade

Shows upgrade log file (root and guest)

show diaglog

Shows diagnostics log file (guest)

show ethif

Shows Ethernet interface info (guest)

show crashdump

Shows the contents of crashdump file (guest)

Cisco Maintenance image login: root Password: Maintenance image version: 1.1(0.3) root@localhost# ip address 10.1.1.1 255.255.255.0 root@localhost# ip broadcast 10.1.1.254 root@localhost# ip host FWSM root@localhost# ip gateway 10.1.1.100 root@localhost# ip domain cisco.com root@localhost# ip nameserver 10.1.1.150 root@localhost# show ip IP address: 10.1.1.1 Subnet mask: 255.255.255.0 IP Broadcast: 10.1.1.254 DNS Name: FWSM.cisco.com Default Gateway: 10.1.1.100 Nameserver(s): 10.1.1.150 root@localhost#

FWSM# upgrade-mp Address or name of remote host [10.1.1.150]? 10.1.1.150 Source file name []? mp-1.0.1-bin.gz copying tftp://192.168.253.79/mp-1.0.1-bin.gz to flash [yes|no|again]?y !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!! Received 7700916 bytes. Maintenance partition upgraded. FWSM#

Step 1.

Configure the VLAN, and the ports on the switch.

First, configure the interface and the VLAN on the switch. If you are running Native IOS, configure the interfaces and VLANs as shown Example 4-11.

Example 4-11. VLAN and Interfaces on the Native IOS Switch

Example 4-12. Showing VLAN and Interface Configuration on the CatOS

Note

Always create the firewall VLANs on the Supervisor first. Then session to the MSFC and bring up the VLAN interface between the MSFC and the FWSM. If you perform the operation in the reverse order, you might run into a situation in which the VLAN will fail to come up. If so, clear all firewall VLANs on the Supervisor, remove the VLAN interface on the MSFC, and create the firewall VLANs on the Supervisor again.

Step 2.

Map the VLANs on the switch to the FWSM.

Once the VLANs and interfaces are configured on the switch, configure the switch to map the VLANs to the FWSM blade. The syntax to map the VLANs is different in Native IOS and Hybrid modes on the switch.

If you are running Native IOS, use the following command to group VLANs with the first line and map the VLAN group to the FWSM that is seated on slot 3 of the FWSM:

CAT6509(config)# firewall vlan-group 1 10,30 CAT6509(config)# firewall module 3 vlan-group 1

If you are running the switch in Hybrid mode, use the following command:

cat6509> (enable) set vlan 10,30 firewall-vlan 3 Vlans 30,40 declared secure for firewall module 3 CAT6509> (enable)

Step 3.

Configure the interfaces on the FWSM.

By now, VLANs 10 and 30 should be downloaded to the FWSM. The download can be verified by using the following command:

FWSM# show vlan 10, 30 FWSM#

Map the downloaded VLANs on the FWSM to the corresponding interfaces of the FWSM with the following command:

FWSM(config)# nameif vlan_number if_name security_level

VLAN10 is mapped to inside interface, and the VLAN30 is mapped to the outside interface as follows:

FWSM(config)# nameif vlan10 inside security100 FWSM(config)# nameif vlan30 outside security0

After defining the interface, assign the IP address to the interfaces with the following command:

FWSM(config)# ip address if_name ip_address [netmask]

The following commands show the IP address configuration of the inside and outside interfaces:

FWSM(config)# ip address inside 10.1.1.1 255.255.255.0 FWSM(config)# ip address outside 30.1.1.1 255.255.255.0

Step 4.

Define routes on the FWSM. By default you can create a single Switched Virtual Interface (SVI) on the MSFC and point to that as the default gateway on the FWSM. The syntax for configuring the static route is as follows:

FWSM(config)# route if_name ip_address netmask gateway_ip metric

The following command shows a default route pointing to the SVI interface (VLAN interface 30):

FWSM(config)# route outside 0 0 30.1.1.2

Step 5.

Configure NAT/PAT/Static.

For outbound traffic (traffic from inside to outside, for instance), the source address translation is required by default. You may configure nat/ global or static NAT to translate the source address. Alternatively, you may bypass NAT checking with a nat zero ACL command. Nat/global is used for dynamic translation, but static NAT is used to create permanent mapping.

Static is used mainly for inbound connections to perform the destination address translation. Dual nat/alias is used to support bi-directional NAT.

The following commands are used to configure nat/global and static:

FWSM(config)# nat [(if_name)] nat_id local_ip [netmask [max_conns [em_limit]]] [norandomseq] FWSM(config)# global [(if_name)] nat_id {global_ip [-global_ip] [netmask global_mask]} | interface FWSM(config)# static [(internal_if_name, external_if_name)] global_ip local_ip [netmask network_mask] [max_conns [em_limit]] [norandomseq]

FWSM(config)# nat (inside) 1 10.1.1.0 255.255.255.0 FWSM(config)# global (outside) 1 interface

FWSM(config)# static (inside,outside) 30.1.1.110 10.1.1.110 netmask 255.255.255.255 0 2

Step 6.

Configure an access-list.

Unlike the PIX firewall, you must allow the outbound traffic with an access-list applied on the higher security interface (for example, inside interface). Otherwise, packets are denied in both directions (inbound and outbound). The syntax for an access-list configuration is as follows:

FWSM(config)# access-list acl_ID [deny | permit] protocol {source_addr | local_addr} {source_mask | local_mask} operator port {destination_addr | remote_addr} {destination_mask | remote_mask} operator port

Then, apply the ACL to the interface with the following command.

FWSM(config)# access-group acl_ID in interface interface_name

Example 4-13. ACL Configuration and How to Apply it on the Interface

Step 7.

Turn on fixups.

To turn on fixup for a specific protocol, you can use the fixup protocol command. For example, to turn on fixup for the ICMP, which is off by default, use the following command:

FWSM(config)# fixup protocol icmp

Step 1.

Be sure you can ping to the directly connected interface of the FWSM. If you cannot pass traffic across the FWSM, you must ensure that you can ping to the interface of the FWSM from a host in the same VLAN. For example, if you mapped the inside interface to VLAN 10, a host (10.1.1.10) on VLAN 10 must be able to ping to the FWSM inside interface (10.1.1.1). If you cannot ping, work through the following steps to correct the problem; otherwise proceed to the next step:

(a). Make sure the ICMP is allowed on the interface of FWSM by using the icmp command. You can execute the show icmp command to verify whether the icmp is allowed on the interface. To enable ICMP on the inside interface, use the following command:

FWSM(config)# icmp permit 0 0 inside

(b). If the ping is still unsuccessful, run the debug icmp trace command and see if FWSM displays any debug output. If there are no debug messages on ICMP on the FWSM, go to the next step.

(c). Ping to other devices in the same VLAN and subnet. If you are not successful, check the port that is connected to the device. If the ping is successful, move to the next step.

(d). Execute the show interface command and ensure that the interfaces are shown up/up. If they are shown in any other state, verify that the nameif command used the proper VLAN number with the commands that follow:

FWSM# show nameif nameif vlan10 inside security100 nameif vlan30 outside security0 FWSM#

(e). If you still have problems with the interface, execute the show vlan command and be sure the correct VLANs are downloaded properly on the FWSM.

FWSM# show vlan 10, 30 FWSM#

(f). If you have FWSM set up with Hybrid mode, be sure to configure the VLANS on the switch before defining the SVI on the MSFC. If you have configured an SVI interface on the MSFC before configuring the VLAN on the switch, you must remove the SVI from the MSFC and VLANs from the switch. Reconfigure VLANs on the switch first and then configure the SVI interface on the MSFC.

(g). If the packets still do not flow, change the Ether channel algorithm on the switch.

Step 2.

If you can successfully ping the inside and outside interface from the corresponding VLANs, the next step is to make sure that you can ping across the FWSM. If you cannot do so, follow the next step.

Step 3.

By default, FWSM denies all packets from higher to lower security, and lower to higher security networks. So you must configure the ACL to allow this traffic on both directions. You can execute show access-list in conjunction with show access-group commands to verify whether the ACL is configured, and applied to the correct interface. You must also allow the return packet from the opposite direction. For example, to ping the outside from the inside, you must allow the ICMP on the inside interface and on the outside interface. If you do not want to allow ICMP packets on the outside interface, you can configure fixup protocol icmp. If the packets are dropped by the ACL, this information will be logged in the syslog, if you turn on syslogging to level 4. If with the show access-list command packet, counters are incrementing, you know that the ACL is allowing the packets that the NAT may not be configuring or may be configuring incorrectly. So, go to the next step.

Step 4.

Check to see if the translation is not being built.

If the hit counters are incrementing on the ACL, make sure you are not running with a translation issue. As the NAT is taken care of by the NP3 processor, you can execute the show np3 nat|global|static|alias command to verify the configuration. You can execute show xlate detail command to see if the translation is being built up as follows:

FWSM(config)# show xlate detail Flags: D - DNS, d - dump, I - identity, i - inside, n - no random, o - outside, r - portmap, s - static 1 in use, 2 most used ICMP PAT from inside:10.1.1.10/45 to outside:30.1.1.1/1036 flags r FWSM(config)#

Step 5.

Verify that the route exists in the routing table for the destination network.

If the ACL and translation are fine, execute the show route command to verify that the routing table is in the firewall module. Example 4-14 is an example of a routing table.

Example 4-14. Showing a Routing Table on the FWSM

Step 6.

Verify whether the route exists on the outside router or MSFC for the return traffic.

The MSFC or the outside router must have the route pointing back to the outside interface of the FWSM. You can run the debug ip packet detail ACL on the MSFC or the router to make sure that a route is defined on the MSFC or router pointing back to the outside interface of the FWSM. Note that if you want the communication to take place between these VLANs and outside network, you must have a route for every VLAN defined on the FWSM. The following commands show how to run the debug ip packet detail ACL command. Assume that you want to verify the connection from the source address of 30.1.1.1, and destination address of 50.1.1.50 on the MSFC. You can configure the ACL as follows and turn on debug using this ACL.

MSFC(config)# access-list 101 permit ip host 30.1.1.1 host 50.1.1.50 MSFC(config)# access-list 101 permit ip host 50.1.1.50 host 30.1.1.1 MSFC(config)# exit MSFC# debug ip packet detail 101

Step 7.

Finally, verify the connection establishment with the following command:

FWSM(config)# show local 10.1.1.10 local host: <10.1.1.10>, tcp conn(s)/limit = 1/0, embryonic(s)/limit = 0/0 udp c onn(s)/limit = 0/0 Xlate(s): PAT Global 30.1.1.1(1042) Local 10.1.1.10(11003) FWSM(config)#

To determine the details of the connection, use the following commands:

FWSM(config)# show conn 1 in use, 2 most used Network Processor 1 connections TCP out 50.1.1.50:23 in 10.1.1.10:11003 idle 0:00:42 Bytes 4672 FLAGS - U Network Processor 2 connections

If you want more details, you can use the show conn long 3 command.

Step 1.

Take two "show processes" command outputs, about one minute apart. This will give you the difference in CPU utilization at intervals of one minute.

Step 2.

Calculate the difference in the number of processes taking the maximum amount of CPU in a one-minute interval. The values displayed are in milliseconds (ms). Be sure to exclude any polling thread.

Step 3.

Because the CPU shown is what is running on the CP (not the NPs), this limits the scope to:

- Traffic sourced from the FWSM (mgmt, routing protocols, AAA, websense, syslog, and so on)

- Traffic requiring L7 fixups (VoIP, PortMapper, ils, and so on)

Step 4.

Find out what and how many connections are on the CP by issuing the show pc conn command.

Step 5.

Typically high CPU utilization is caused by syslog, or the type of traffic hitting the CPU. Disable syslog or disable individual fixups until you uncover the utilization problem.

FWSM(config)# show np 1 ingress | include count ! The column for the following three lines should be zero bcb_fq_th_0_count 0x10080040 0x00000000 --> here bcb_fq_th_1_count 0x10080020 0x00000000 --> here bcb_fq_th_2_count 0x10080010 0x00000000 --> here bcb_fq_arr_count 0x10100400 0x000c0000 dmu_rx_counters 0x00000000 0x00000000 FWSM(config)#

1.

Fragmentation issues

By default, fragmented packets cannot traverse the FWSM if you are running a version earlier than FWSM 2.2. You can use the fragment command to configure this feature as described in this link:

http://cco/en/US/products/sw/secursw/ps2120/products_command_reference_chapter09186a00801727a8.html#wp1029667

http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_command_reference_chapter09186a00801727a8.html#wp1029667

This behavior differs from that of the PIX firewall. Common protocols that use fragmented packets are Open Shortest Path First (OSPF) and Network File System (NFS).

2.

If you are running IP URL filtering, be sure that the policy defined in the URL server is not denying the packet.

Step 1.

Be sure to fulfill the minimum requirements.

Before attempting to configure for Failover, you must fulfill the following minimum requirements for it to operate correctly:

1. Both FWSMs must be running the same version of FWSM software.

2. Both must have the same number of VLANS mapped from the switch. Also be sure to configure the same number of interfaces on both units.

3. Both units must be Layer 2 adjacent on all their interfaces. In other words, all interfaces must be capable of exchanging Layer 2 broadcast packets (Address Resolution Protocol [ARP] and so on) between each other, as the failover protocol packets cannot be routed.

4. When running multiple modes, both modules must have the same licensing characteristicsfor example, the number of contexts, and so on. (This is not applicable for FWSM 1.x.)

5. Both modules must run in the same mode; a single mode unit cannot be paired with a multiple mode unit. (This is not applicable for FWSM 1.x.)

6. Both firewalls must agree on operating either as routed or transparent. (This is not applicable for FWSM 1.x.)

Step 2.

Configure two additional VLANs on the switch and map them to FWSM for the failover interface and the stateful failover link.

You must create a VLAN on the switch and map this VLAN to the failover interface of both primary and secondary FWSMs. If your FWSMs are in different chassis, you must configure a trunk link to carry the VLAN to the other switch. If the FWSM modules are in the same chassis, be sure to map the VLANs that you have created to both of the FWSMs. The same thing applies for the stateful failover link. It is strongly recommended to create two separate VLANs for the failover interface and the stateful failover link. In the native IOS, you can create a layer 2 VLAN with the vlan command in configuration mode. In hybrid mode, you can do the same with the set vlan command.

The LU protocol can generate large (up to 700Mbps) amounts of traffic. If the LAN and link interfaces are not dissociated, providing guaranteed output queue servicing to the failover protocol can be difficult when there is congestion. For instance, VLAN 100 could be dedicated to carrying the LU traffic, while VLAN 101 takes care of the failover protocol. Both VLANs can be trunked using 801.Q between the two switches.

Step 3.

Configure the failover LAN interface and the failover link.

For failover to operate on the FWSM, a failover communication interface must be configured. This is the LAN interface over which failover protocol packets will travel. To configure stateful failover, use the same interface or a different one to carry LU traffic. With the previous steps, be sure to configure the VLANs for the failover interface and stateful failover link. Execute show vlan on both FWSMs to ensure that both VLANs (among other VLANs) are downloaded to the FWSM. Once the VLANs are downloaded, you can configure the failover interfaces with the following commands if you are running a FWSM version earlier than 2.x:

nameif VLAN_NUMBER interface_name security_level ip address interface_name IP_address netmask failover lan interface <if_name> failover link <if_name>

Example 4-16 shows the primary FWSM's configuration in single mode with the inside VLAN10, the outside VLAN30, and the failover VLAN 400 with FWSM version 1.x.

Example 4-16. Failover Configuration for the Primary FWSM

Example 4-17. Failover Configuration for the Secondary FWSM

failover lan interface <if_name> vlan <vlan> failover link <if_name> [vlan <vlan>]

If the firewall is operating in multiple mode, the failover interface and the stateful link interface are configured at the system execution space as shown in Example 4-18 (in single mode, the configuration is the same).

Example 4-18. Two VLANS for the LAN Interface and the LU Interface

Example 4-19. Failover Interface IP Address Configuration

Step 4.

Assign IP addresses for the failover interfaces.

You must assign standby IP addresses for each failover and Firewall interface. This is configured with the following command in FWSM Version 1.x:

FWSM(config)# failover ip address <if_name> <IP_Address>

Example 4-20. IP Address Configuration in Single Mode Running FWSM 1.x

If you are running FWSM 2.2, the same interface is configured with the following command:

failover interface ip <if_name> <ip_address> <mask> standby <ip_address>

The failover interface ip command now assigns an IP address to both the active and standby units, deprecating the 1.1(x) failover ip address syntax. Example 4-21 shows the interface configuration on the Primary unit.

Example 4-21. Primary Unit's Interface IP Address Configuration

ip address <if_name> <ip_address> <mask> [standby <ip_address>]

In multiple firewall mode, create contexts, assign interfaces to them, and associate VLANs to interfaces within those contexts. Use the new ip address CLI when assigning IP addresses to interfaces. These steps are only performed on the primary unit. Example 4-22 shows a single context configuration in multiple mode.

Example 4-22. Context Configuration on Multiple Mode

Step 5.

Designate primary and secondary units.

Unlike serial cable-based Failover on PIX Firewall, in LAN-based failover there is no physical cable to distinguish the Primary and Secondary units. This is determined through configuration. You can use the following command to elect which FWSM should become Primary and which one should be the Secondary unit:

FWSM(config)# failover lan unit {primary|secondary}

On the primary FWSM, execute the following command:

FWSM(config)# failover lan unit primary

FWSM(config)# failover lan unit secondary

The FWSM configured as primary will become Active, and the secondary will become Standby if both units are booted up at the same time. In a running system, there will be no preemption. In other words, if a secondary is currently the Active module and a primary has finished booting, the primary will become Standby, rather than forcing a failover and becoming Active.

Step 6.

Configure interface policy (optional).

Beginning with FWSM Version 2.x, the global interface policy can be specified either as a percentage or as an absolute number. When the number of monitored interfaces that have failed reaches or exceeds the interface policy, a module failover is triggered. The failover interface policy is configured within the system execution space using the following command:

failover interface-policy <n> [percent]

Assuming a failover interface policy of 1 interface, here is the sequence of events that occurs as soon as one monitored interface fails:

Switching to Standby 104002: (Primary) Switching to STNDBY - Interface check

Step 7.

Configure poll interval (optional).

A poll interval is the amount of time that elapses between each failure detection attempt. That interval is specified using the failover poll <interval> command. The poll interval is used for both unit and interface health monitoring:

failover polltime [unit|interface] [msec] <x> [holdtime [msec] <y>]

FWSM(config)# failover poll 15

Step 8.

Turn on stateful failover for http traffic (optional).

HTTP replication is not on by default. The Failover replication http command turns on HTTP replication. Enabling HTTP replication reduces performance dramatically. It is not recommended in FWSM. The failover LAN interface should be dedicated.

Step 9.

Turn on the failover.

You should turn on the failover on the primary unit first with the following command:

FWSM(config)# failover ! No Response from Mate FWSM(config)#

709003: (Primary) Beginning configuration replication: Send to mate. 709004: (Primary) End Configuration Replication (ACT)

A series of SYSLOG messages 105003 and 105004 should quickly follow on the primary unit:

105003: (Primary) Monitoring on interface 1 waiting 105004: (Primary) Monitoring on interface 1 normal

Example 4-23. Messages that Will Appear on the Secondary Unit After Turning FO on

FWSM(config)# logging on FWSM(config)# logging monitor 7 FWSM(config)# logging console 7 FWSM(config)# 111008: User 'enable_15' executed the 'logging con 7' command. Detected an Active mate. Switching to Standby Switching to Standby. FWSM(config)# Beginning configuration replication from mate. This unit is in syncing state. 'failover' command will not be effective at this time End configuration replication from mate. 709006: (Secondary) End Configuration Replication (STB) Access Rules Download Complete: Memory Utilization < 1% 105003: (Secondary) Monitoring on interface 2 waiting 105003: (Secondary) Monitoring on interface 1 waiting 105004: (Secondary) Monitoring on interface 2 normal 105004: (Secondary) Monitoring on interface 1 normal FWSM#

FWSM(config)# show failover Failover On Failover unit Primary Failover LAN Interface fover Reconnect timeout 0:00:00 Poll frequency 15 seconds This host: Primary - Active Active time: 29925 (sec) Interface outside (10.30.1.1): Normal Interface inside (10.1.1.1): Normal Other host: Secondary - Standby Active time: 285 (sec) Interface outside (10.30.1.2): Normal Interface inside (10.1.1.2): Normal Stateful Failover Logical Update Statistics Link : Unconfigured. FWMS#

FWSM(config)# show failover Failover On Failover unit Secondary Failover LAN Interface fover Reconnect timeout 0:00:00 Poll frequency 15 seconds This host: Secondary - Standby Active time: 285 (sec) Interface inside (10.1.1.2): Normal Interface outside (10.30.1.2): Normal Other host: Primary - Active Active time: 30750 (sec) Interface inside (10.1.1.1): Normal Interface outside (10.30.1.1): Normal Stateful Failover Logical Update Statistics Link : Unconfigured. FWSM(config)#

Step 1.

Level 1 syslog specifies a reason for failover. So always check the syslog to determine the root cause. For example, if the switch port failed on the inside interface of Active Firewall, you would see the following message on the Primary (Active) Firewall.

411002: Line protocol on Interface inside, changed state to down 105007: (Primary) Link status 'Down' on interface 1 104002: (Primary) Switching to STNDBYinterface check, mate is healthier

104001: (Secondary) Switching to ACTIVEmate want me Active

Step 2.

Issue the show failover history command to see the reasons for the past state changes, which will help narrow the possibilities for the failover.

FWSM# show fail history ====================================================================== >From State To State Reason ====================================================================== Init Disabled Set by the CI config cmd Disabled Listen Set by the CI config cmd Listen Active No Active unit found Active Active Other unit got stuck in learn state after sync =======================================================================

Step 3.

Execute show vlan on both FWSM units and make sure you have the same VLANs downloaded on both units.

Step 4.

Execute show interface on both FWSM units to make sure they are up. Map the VLANs to the right interfaces.

Step 5.

Test the connectivity by pinging to the Failover interface IP. Be sure to allow the ICMP for the interfaces.

Step 6.

Verify that the Failover interface VLAN is configured on the switch, and is not removed from the switch accidentally.

Step 7.

Make sure all VLANS are trunked between the switches.

Step 8.

Be sure to turn on dot1Q across the board on the switch.