CCNP BCMSN Exam Certification Guide (3rd Edition)

1.

Identify the primary and secondary firewall units. Failover communication depends on each firewall having a distinct role. The primary unit must have an "Unrestricted" license, and the secondary unit can have an "Unrestricted," "Failover Only," or "Active-Active Failover Only" license.

If both units have an "Unrestricted" license, the roles can be chosen arbitrarily.

You need to assign the primary and secondary roles in one of two ways:

- By connecting labeled ends of a failover cable (see Step 2)

- By configuring the roles in LAN-based failover (see Step 3a)

2.

(Optional) Connect the firewalls with the serial failover cable.

By default, the serial failover cable is expected to connect the two firewalls before failover can be used. If you intend to use this method of failover communication, connect the cable connector labeled "Primary" to the nine-pin failover connector on the primary unit. Then connect the "Secondary" end to the secondary unit.

From this point on, the two units communicate failover "hello," configuration changes, and stateful update messages over the serial cable.

TIP

To bring up failover mode, you must use either the serial failover cable described here or LAN-based failover, configured in the next step.

3.

(Optional) Connect the firewalls over a LAN for LAN-based failover.

A LAN connection can be used to carry failover communication much more efficiently than the serial failover cable. It can also be used if the two firewalls must be geographically separated.

You should use a Fast Ethernet or Gigabit Ethernet connection that is dedicated to failover traffic. The connection between firewalls should be on an isolated VLAN, configured for full duplex and fast convergence so that the connection is highly available.

TIP

Don't use a crossover Ethernet cable or a fiber-optic patch cable to connect the two failover LAN interfaces if the firewalls are located close to each other. Instead, each interface should connect to a switch port so that the link status is always up to one firewall interface if the other firewall interface fails. Otherwise, both units sense a link-down condition and assume that their own interfaces have a failure.

Switch# configure terminal Switch(config)# interface type mod/num ! Enable PortFast for immediate traffic forwarding Switch(config-if)# spanning-tree portfast ! Disable trunking by making it an access switch port Switch(config-if)# switchport mode access ! Disable EtherChannel negotiation Switch(config-if)# no channel-group Configuration Steps 3a through 3e should be used to configure the primary unit. Be sure to use the failover lan unit primary command described in Step 3a.

Then, connect to the secondary unit and repeat the same commands to configure LAN-based failover on it. The commands should be identical, except for the failover lan unit secondary command described in Step 3a. Otherwise, don't try to exchange the IP addresses between primary and secondary units in the other commands. The failover pair sorts out the IP addresses according to their roles.

a. Identify the primary and secondary units:

FWSM 2.x	Firewall(config)# failover lan unit {primary | secondary}
PIX 6.x	Firewall(config)# failover lan unit {primary | secondary}
PIX 7.x	Firewall(config)# failover lan unit {primary | secondary}

Each unit must be configured with its own failover identity, because no physical failover cable connection exists to differentiate them.

NOTE

Normally, you make configuration changes to only one firewall unit (the active one), and the changes are replicated automatically. In this step, each firewall must have a different keyword (primary or secondary) in its configuration to differentiate its firewall identity. Therefore, you must add this command to the primary and secondary firewalls independently.

b. Configure the LAN interface to be used:

FWSM 2.x	[View full width] Firewall(config)# failover interface ip if_name ip_address mask standby ip_address
PIX 6.x	[View full width] Firewall(config)# interface phy_if phy_speed Firewall(config)# nameif phy_if if_name securitylevel Firewall(config)# ip address if_name ip_address netmask Firewall(config)# failover ip address if_name ip_address
PIX 7.x	[View full width] Firewall(config)# interface phy_if Firewall(config-if)# speed speed Firewall(config-if)# duplex duplex Firewall(config-if)# no shutdown Firewall(config-if)# exit Firewall(config)# failover interface ip if_name ip_address mask standby ip_address

You need to configure the LAN interface for its name, speed, duplex, and security level on PIX 6.x and 7.x platforms. On any platform, you need to provide an IP address for the active unit and the standby unit.

In PIX 7.x, the physical interface phy_if (ethernetn or gigabitethernetn) can be configured for only speed and duplex, which are both optional. The failover interface ip command assigns an IP address for the active and standby units according to an arbitrary interface name if_name. At this point, the interface name is not bound to a physical interface for LAN-based failover. This is done in Step 3c.

NOTE

Failover interfaces in PIX 7.x are not assigned IP addresses as part of interface configuration mode. This is because the active-active failover commands must be configured in the system execution space, which doesn't participate in IP communication.

In PIX 6.x, interface phy_if is of the form ethernetn (10/100) or gb-ethernetn (Gigabit Ethernet). The hardware_speed can be one of the following: 10baset (10 Mbps half duplex), 10full (10 Mbps full duplex), 100basetx (100 Mbps half duplex), 100full (100 Mbps full duplex), 1000auto (Gigabit autonegotiation), 1000full (Gigabit autonegotiation to use full duplex only), or 1000full nonegotiate (Gigabit full duplex). Assign an arbitrary interface named if_name ("lan-fo" or "failover," for example) and a security level as securitylevel (0 to 100).

c. Identify the LAN interface used for failover communication:

FWSM 2.x	Firewall(config)# failover lan interface if_name vlan vlan
PIX 6.x	Firewall(config)# failover lan interface if_name
PIX 7.x	Firewall(config)# failover lan interface if_name phy_if

All failover communication is sent and received over the interface named if_name. In PIX 7.x, you must also bind the failover LAN interface name to a physical interface phy_if (ethernetn or gigabitethernetn). On an FWSM, you must bind the failover LAN interface name to a VLAN number vlan.

TIP

With two FWSMs, the failover LAN interface is also a specific VLAN. If the two FWSMs are located in a single Catalyst 6500 chassis, the VLAN is used only internally within the chassis. If the two FWSMs are located in two separate switches, you must define this VLAN on and pass it between both switches. You can do this with a single VLAN link or over a trunk link.

Before you can use the failover LAN interface VLAN, you must define it on the switch supervisor and then make it available to the FWSM by including it in the firewall vlan-group group-name vlan-list and firewall module module vlan-group group-name commands.

d. (Optional) Encrypt failover messages:

FWSM 2.x
PIX 6.x	Firewall(config)# failover lan key key-string
PIX 7.x	Firewall(config)# failover key key-string

Because other stations could be accidentally connected to the failover LAN, you can define a preshared key key-string (an arbitrary text string up to 63 characters) to make the failover traffic more secure. The key is used to authenticate the failover pair of firewalls, as well as to encrypt the failover information.

The key-string is not displayed in the firewall configuration after it is configured. Obviously, the same key-string must be configured on both primary and secondary firewalls so that the failover traffic can be encrypted and unencrypted correctly. If not all of the keys are identical, you see the following message on the firewall console:

WARNING: Failover message decryption failure. Please make sure both units have the same failover shared key and crypto license

e. Enable LAN-based failover:

FWSM 2.x
PIX 6.x	Firewall(config)# failover lan enable
PIX 7.x	Firewall(config)# failover lan enable

By default, the failover pair expects to use the serial failover cable. You must start LAN-based failover explicitly with this command. From that point on, a connected serial cable is no longer used and can be removed.

On an FWSM, LAN-based failover is the only method for failover communication. Therefore, it is enabled by default.

4.

(Active-active only) Define failover groups.

Failover groups must be configured from the system execution space on the primary firewall only.

a. Choose a failover group:

Firewall(config)# failover group {1 | 2} Only two failover groups are supported. Because the failover mechanism in each group is independent, each group has its own active and standby roles. Contexts are assigned membership in one of the two groups listed in Step 9.

b. Prefer a firewall unit to have the active role:

Firewall(config-fover-group)# {primary | secondary}

In an initial condition, where the firewalls have booted up or failover has just been enabled, and both firewalls are functioning properly, one of them must be "elected" to take on the active failover role. By default, the primary unit has a higher priority to become active in each failover group.

You can designate a higher priority for the primary or secondary firewall unit with this command for the failover group being configured. Naturally, if that unit fails, the other unit still can take over the active role.

c. (Optional) Allow the higher-priority unit to assume immediate control:

Firewall(config-fover-group)# preempt

Normally, if an active unit fails, the standby unit assumes the active role indefinitely. The firewall units do not automatically revert to their original roles after a failure is resolved. Instead, they keep their roles until another failure occurs or there is manual intervention.

You can use the preempt command to allow the higher-priority unit in a failover group to always preempt the other unit for active control.

For example, suppose you have configured failover group 1 to give higher priority for the active role to the secondary unit. Normally, if the secondary unit fails, the primary unit assumes the active role and keeps it even after the secondary unit is restored. With preempt, the secondary unit can take over the active role as soon as it is restored to service. You would use the following commands to accomplish this:

Firewall(config)# failover group 1 Firewall(config-fover-group)# secondary Firewall(config-fover-group)# preempt

5.

(Optional) Use virtual MAC addresses for an interface:

This command allows both units to have stable information about what the active (active_mac) and standby (standby_mac) MAC addresses should be on an interface. In PIX 6.x, the interface name interface-name (outside, for example) is used, whereas PIX 7.x uses the physical interface name (gigabit0, for example). Both addresses are given in dotted-triplet format, such as 0006.5b02.a841.

In PIX 7.x, the MAC addresses are defined as global values in single-context mode, where only active-standby failover applies. If the firewalls are operating in multiple-context mode, where active-active failover is used, the MAC addresses are configured within the failover group on the system execution space because two different failover groups of contexts are maintained.

TIP

To use the failover mac address command, you must be able to give unique MAC addresses to both the active and standby unit interfaces. Finding unique values isn't always straightforward. An easy method is to display the burned-in addresses (BIAs) of all interfaces on the primary and secondary firewall units with the show interface command.

The addresses of the primary unit can always be assigned to the active firewall, and those of the secondary unit can be assigned to the standby firewall. After all, that is how the IP addresses are handled. Then, for each interface, use the command failover mac address interface primary_mac secondary_mac. At that point, it is usually a good idea to save the configurations and reboot both firewall units to make sure that the new MAC addresses are being used correctly.

If you are using LAN-based failover, the MAC addresses of that interface cannot be changed or defined using this command. Instead, the default BIAs of that interface are used. This is because even though the active and standby roles change during a failover, the primary and secondary roles do not. Therefore, the primary and secondary units must have consistent identities and interface addresses.

6.

(Optional) Define a health monitoring policy.

a. Evaluate the health of the failover peer:

FWSM 2.x	[View full width] Firewall(config)# failover polltime [unit] [msec] time [holdtime holdtime]
PIX 6.x	Firewall(config)# failover poll time
PIX 7.x	[View full width] Firewall(config)# failover polltime [unit] [msec] time [holdtime holdtime]

Each failover unit sends periodic hello messages to its peer over the serial failover cable or the LAN-based failover interface. This is offered as evidence that the unit is still alive.

In PIX 6.x, you can adjust the hello message interval to time (3 to 15 seconds; the default is 15). In FWSM or PIX 7.x, you can use time (1 to 15 seconds; the default is 15) to give the interval in whole-second increments. You can also use msec time (500 to 999 milliseconds; the default is 500) to set the interval more granularly.

The unit keyword can be used to denote hello timing between units or failover peers. However, if unit is not given, it is assumed anyway.

One unit expects to receive hellos from its peer at regular intervals, although it doesn't know what that interval should be. If no hello messages are received before a holdtime timer expires, the other peer is considered to have failed. In PIX 7.x and FWSM, you can set that timer by adding holdtime holdtime (3 to 45 seconds; the default is 45). PIX 6.x uses a fixed holdtime that is always 3 times the hello interval. (The default is 3 times 15, or 45 seconds.)

The holdtime timer must always be set to a minimum of 3 times the unit hello interval. This is because the firewalls always check for the loss of at least three consecutive hellos from a peer before taking action. If the holdtime keyword is not given, the firewall adjusts the holdtime automatically. The only exception to this behavior is if the unit hello interval is set to 5 seconds or less, where the default holdtime is automatically set to 15 seconds. This is done to prevent very aggressive failure detection with very short hello intervals.

TIP

In PIX 7.x, the most aggressive peer monitoring policy has a unit interval of 500 milliseconds and a minimum holdtime of 3 seconds. This allows a standby unit to detect a failure with the active unit and take over its role within 3 seconds. In comparison, PIX 6.x allows a minimum hello interval of 3 seconds, but with a minimum holdtime of 15 seconds.

Be careful if you decide to tighten up the unit and holdtime intervals for a more aggressive failure detection policy. Delayed or lost hellos on a congested LAN-based failover interface could be misinterpreted as a failure. If your LAN-based failover traffic is carried over switches that separate the two firewall units, make sure the switches are configured to use the most efficient spanning-tree and link-negotiation features possible. Otherwise, a Layer 2 topology change (a link or switch failure) could block the failover messages for up to 50 seconds!

b. Evaluate the health of interfaces:

FWSM 2.x	Firewall(config)# failover polltime interface time
PIX 6.x
PIX 7.x single context	Firewall(config)# failover polltime interface time
PIX 7.x multiple context	Firewall(config)# failover group {1 | 2} Firewall(config-fover-group)# polltime interface time

Failover hello messages are sent out firewall interfaces at time (3 to 15 seconds; the default is 15) intervals. There is no corresponding holdtime timer for interface monitoring; if five consecutive interface hello messages are missed on a monitored interface, the firewall moves that interface into testing state.

In PIX 7.x, the interface polltime is a global value in single-context mode, where only active-standby failover applies. If the firewalls are operating in multiple-context mode, where active-active failover is used, polltime is configured within the failover group on the system execution space because two different failover groups of contexts are maintained.

With PIX 6.x, hello messages are sent out all connected interfaces at the same interval as failover unit hello messages. This interval is set with the failover poll command.

c. Define an interface failure policy:

FWSM 2.x	Firewall(config)# failover interface-policy num[%]
PIX 6.x
PIX 7.x single context	Firewall(config)# failover interface-policy num[%]
PIX 7.x multiple context	Firewall/context(config)# failover interface-policy num[%]

By default, if a firewall tests and finds that at least one of its monitored interfaces has failed, it declares itself failed. In that case, if the firewall was in active mode, the other unit takes over the active role.

To set the self-declared failure threshold, you can specify the number of failed interfaces as num (1 to the maximum number of interfaces; the default is 1) or a percentage of failed interfaces as num% (1% to 100%).

Notice that the interface failure policy is set on a per-context basis. On a single-context firewall, this is configured in global configuration mode. If multiple-context mode is running, you must connect to the appropriate security context and enter the command there.

7.

(Optional) Use stateful failover for maximum availability.

Stateful failover can be used to synchronize the standby failover unit with connection information from the active unit. In this way, as connections are built or torn down, the standby unit can always keep its inspection tables up to date. If a failover occurs, the standby unit can take over the active role and maintain all the open connections without interruption.

Stateful failover requires a LAN connection between firewalls. This is to support the high bandwidth needed to carry updates about connections that are being inspected. Be aware that no stateful information is carried over the serial failover cable if one is being used to connect the firewalls.

a. Configure an interface to use for stateful update traffic:

FWSM 2.x	[View full width] Firewall(config)# failover interface ip if_name ip_address mask standby ip_address
PIX 6.x	[View full width] Firewall(config)# interface phy_if phy_speed Firewall(config)# nameif phy_if if_name securitylevel Firewall(config)# ip address if_name ip_address netmask Firewall(config)# failover ip address if_name ip_address
PIX 7.x	[View full width] Firewall(config)# interface phy_if Firewall(config-if)# speed speed Firewall(config-if)# duplex duplex Firewall(config-if)# no shutdown Firewall(config-if)# exit Firewall(config)# failover interface ip if_name ip_address mask standby ip_address

The stateful interface needs to be configured for its name, speed, duplex, and security level. It also needs an IP address for the active unit and the standby unit.

In PIX 7.x, the physical interface phy_if (ethernetn or gigabitethernetn) can be configured only for speed and duplex, which are both optional. The failover interface ip command assigns an IP address for the active and standby units according to an arbitrary interface name if_name. At this point, the interface name is not bound to a physical interface for stateful failover. This is done in Step 7c.

In PIX 6.x, interface phy_if is of the form ethernetn (10/100) or gb-ethernetn (Gigabit Ethernet). The hardware_speed can be one of the following: 10baset (10 Mbps half duplex), 10full (10 Mbps full duplex), 100basetx (100 Mbps half duplex), 100full (100 Mbps full duplex), 1000auto (Gigabit autonegotiation), 1000full (Gigabit autonegotiation to use full duplex only), or 1000full nonegotiate (Gigabit full duplex). Assign an arbitrary interface name if_name ("stateful," for example) and a security level as securitylevel (0 to 100).

The two firewalls should have a dedicated link for this purpose, because stateful updates occur in real time as connections form or go away.

TIP

You can use one dedicated LAN interface (10/100 or Gigabit Ethernet) to carry both LAN-based failover and stateful failover information. The interface bandwidth must be large enough to carry the aggregate failover load.

However, it is always best to keep the LAN-based failover and stateful failover data streams on separate interfaces. The stateful failover data stream is usually much larger than the LAN-based failover because of the usually large number of connections that come and go. Therefore, you should set aside the fastest firewall interface that is available for stateful failover.

In addition, LAN-based failover messages must be able to travel between the two units without being lost or delayed. Otherwise, the loss of LAN-based failover messages indicates that one or both units have failed.

You can link the two stateful failover interfaces directly with a fiber-optic or crossover patch cord without connecting them to intermediate switches. However, neither firewall unit can determine which unit has had an interface failure, because the link status is lost on both units simultaneously.

The best-practice recommendations stress the need for an active device such as a switch to connect the stateful failover interfaces. If one unit loses an interface, a switch would keep the link status up for the other firewall unit.

In the case of FWSMs, they each have a 6-Gbps internal trunk link to the switch backplane. With their high performance, stateful failover information can easily burst up to the link bandwidth. Therefore, if two FWSMs are located in separate chassis, you should provide a stateful failover VLAN link of at least 6 Gbps. You can do this by aggregating Gigabit Ethernet links into a Gigabit EtherChannel.

b. Identify the interface used for stateful failover communication:

FWSM 2.x	Firewall(config)# failover link if_name [vlan vlan]
PIX 6.x	Firewall(config)# failover link if_name
PIX 7.x	Firewall(config)# failover link if_name [phy_if]

All stateful failover updates are sent and received over the interface named if_name (stateful, for example). Stateful failover can share the same interface as LAN-based failover if needed. However, you should always try to keep stateful and LAN-based failover isolated on two separate interfaces set aside for these purposes. In PIX 7.x, you must also bind the interface name if_name (stateful, for example) to the physical interface name phy_if (gigabit0, for example). On an FWSM, you must bind the interface name if_name to a VLAN number vlan. If LAN-based and stateful failover share the same interface, the LAN-based failover lan interface command already configures this binding. In that case, the physical interface phy_if or VLAN vlan can be omitted from this command.

c. Keep stateful information about HTTP sessions:

FWSM 2.x	Firewall(config)# failover replication http
PIX 6.x	Firewall(config)# failover replicate http
PIX 7.x single context	Firewall(config)# failover replication http
PIX 7.x multiple context	Firewall(config)# failover group {1 | 2} Firewall(config-fover-group)# replication http

By default, connection state information is replicated to the standby unit for all TCP protocols except HTTP. The HTTP connections are unique because they are short-lived, usually lasting only as long as it takes to load a web page. If a firewall failover occurs, chances are that any active HTTP requests will be retried or new ones will be generated without any connection state information. However, if it is important that all HTTP connections be preserved across an actual firewall failover, use this command.

In PIX 7.x, HTTP state replication is a global value in single-context mode, where only active-standby failover applies. If the firewalls are operating in multiple-context mode, where active-active failover is used, HTTP state replication is configured within the failover group on the system execution space because two different failover groups of contexts are maintained.

8.

Enable the failover process:

As well, each of the configuration commands entered from this point on is automatically replicated from the active unit to the standby unit.

9.

(Active-active only) Assign contexts to failover groups.

By default, all configured contexts belong to failover group 1. To assign the admin or a user context to a failover group, use the following commands in the system execution space:

10.

Give each firewall interface an active and a standby IP address:

On the interface if_name, the active unit uses an IP address given by the ip address command. The standby unit uses a different address given by the failover ip address command or the standby keyword. After a failover occurs, the two units swap IP addresses so that the active unit always uses a consistent address. Although the standby interface is not active, it can respond to pings from other hosts to show that the unit is alive.

In PIX 7.x or FWSM 2.x multiple-context mode, most of the failover configuration must be done in the system execution space. However, to assign IP addresses to the various context interfaces, you need to connect to each context and configure them there. This applies to the admin context as well as any configured user contexts.

NOTE

Identical interfaces on the active and standby firewalls or contexts must have IP addresses that belong to the same network subnet. For example, if interface gigabit0 on the active unit is given 192.168.1.1 255.255.255.0 as its address, the standby unit's gigabit0 interface must also belong to the 192.168.1.0/24 subnet.

11.

(Optional) Identify interfaces to be monitored:

You can enable monitoring on an interface by giving its name as if_name (outside, for example). If you want to disable monitoring on an interface, begin this command with the no keyword. This command can be repeated to identify more than one interface.

For active-active failover, interfaces are marked for monitoring in each of the configured admin and user contexts.

TIP

You can display a list of interfaces and their monitoring status with the show failover command. For example, the following output shows that the outside interface of the admin context and the inside and outside interfaces of the CustomerA context are being monitored. The interfaces of the CustomerB context are not:

Firewall# show failover Failover On Cable status: N/A - LAN-based failover enabled Failover unit Primary Failover LAN Interface: Failover Ethernet0 (up) Unit Poll frequency 3 seconds, holdtime 9 seconds Interface Poll frequency 15 seconds Interface Policy 1 Monitored Interfaces 4 of 250 maximum Group 1 last failover at: 15:33:52 EST Dec 1 2004 Group 2 last failover at: 12:33:40 EST Nov 30 2004 This host: Primary Group 1 State: Standby Ready Active time: 233703 (sec) Group 2 State: Active Active time: 168885 (sec) admin Interface outside (192.168.93.141): Normal CustomerA Interface outside (192.168.93.142): Normal CustomerA Interface inside (192.168.200.11): Normal CustomerB Interface inside (192.168.220.10): Normal (Not-Monitored) CustomerB Interface outside (192.168.200.12): Normal (Not-Monitored) Other host: Secondary Group 1 State: Active Active time: 71814 (sec) Group 2 State: Standby Ready Active time: 136665 (sec) admin Interface outside (192.168.93.138): Normal CustomerA Interface outside (192.168.93.139): Normal CustomerA Interface inside (192.168.200.10): Normal CustomerB Interface inside (192.168.220.11): Normal (Not-Monitored) CustomerB Interface outside (192.168.200.13): Normal (Not-Monitored)