Cisco 7600 Wireless Security Gateway Configuration Guide, Release 4.4

Single-Entity Configuration

WSG Release 1.2 and above supports a single point of configuration and a single OAM interface per service blade. These two features are intended to increase the configurability and manageability of applications using the SAMI hardware platform.

Single- entity configuration allows you to configure all CPUs using a single director CPU. Each CPU still requires its own configuration, but the single-entity configuration duplicates the configuration to all CPUs. The benefit is that a common configuration for each CPU can all be entered into a single CPU instead of having to configure each CPU separately.

You are presented with the standard single-PPC CLI mode upon opening a session (console or SUP session) to the director PPC (PPC3). From this session, you can enter the all mode by using the entity all command. By default, commands entered in entity all mode are executed on all PPCs. However, certain commands such as show clock or show version causes the same output on all processors and need not be repeated for each.

From the director PPC you can open a session to a specific subordinate PPC to execute commands only on that PPC. When you open the session, you will be placed in PCC-specific EXEC mode. Commands are entered as though you are connected to the PCC individually.

From PCC-specific EXEC mode, you can use the configure terminal command to enter config mode. This mode is also PPC-specific, which allows you to execute configuration commands that are applicable only to that PPC. As with the EXEC mode, some commands are not applicable in the PPC-specific EXEC mode. These commands will print an appropriate message and exit.

You can enter the config all mode from the exec all mode by entering the configure terminal command. Similar to the exec all mode, commands entered in this mode are executed on all PPCs, unless they are present in the lookup table described above.

Commands that display statistics and other counters need to be aggregated to provide you with meaningful data. Each application will have to register these commands as single-execution CLIs using the lookup table, and use IPC mechanisms to retrieve and aggregate data. For example, to display the total number of tunnels created, the callback function needs to get that information from all PPCs, and aggregate them before they are displayed.

Configuration Details

The following list provides important configuration information for the single-entity feature:

• PPC3 is designated as the director PPC.
• Entity all mode is available only on the director PPC. Use the entity all command to enter the mode; exit, or entity none will exit the entity all mode.
• Commands that are entered in the entity all mode are executed on all PPCs.
• If a command that is not applicable is entered in the all mode, it will only be executed only the director PPC.
• From the director PPC, you can switch to another PPC using the processor X command, where X is the specific processor number (4-8)
• All commands are supported in the entity-all mode. However, some commands cannot be (for example, interface vlan), or need not be (for example, show version) executed on all PPCs.

The following message is displayed when such commands are executed:

• If a config command fails on any of the subordinate PPCs, execution is aborted at that point (but not rolled back) with the following message:

• If an exec command fails on any of the subordinate PPCs, execution still continues on the remaining PPCs. The following message is printed:

Configuration Example

The following example shows the work flow that you can use to configure all processors from scratch using entity all mode. This example uses remote access crypto profile types. In remote-access configurations, the processors typically have common configuration parameters between them, including the names of the crypto profiles and address pools.

The following steps assume that a session is first opened from the SUP to the director PPC3 on the SAMI, using the command, session slot slot_num processor proc_num.

Configure Parameters That Must Be Unique To Each Processor

Step 1 Configure the hostname:

Step 2 Configure the VLAN interface:

Step 3 Configure the default gateway:

Step 4 Configure address pools:

Step 5 Repeat the above commands on each processor, modifying the configuration appropriately. Using the processor command, you can switch to the other processors without logging out of the director. For example:

Configure Parameters That are Common to all Processors or May Only Apply to the Director

Note If a command only executes on the director processor, you will receive a warning:
INFO : Command executed only on master processor. If required, execute the command on other processors.

Step 1 Configure the single-entity OAM interface and its associated static route on the master PPC:

Step 2 Enter entity all mode.

Step 3 Configure the DNS IP address:

Step 4 Configure the IP address for external logging host:

Step 5 Configure the SNMP host:

Step 6 Configure the SNMP community strings:

Step 7 Configure the SNMP traps:

Step 8 Configure the PKI certificates and trustpoints:

Step 9 Configure the crypto profile:

Step 10 Activate the crypto profile:

Step 11 Display the Running Configuration.

CPU 3

CPU 4

CPU 5

CPU 6

CPU 7

CPU 8

Step 12 Save the configuration:

CPU 4

CPU 5

CPU 6

CPU 7

CPU 8

SNMP Details

WSG Release 1.2 and above supports a single interface for SNMP management. In this instance, the director PPC acts as the target for all SNMP operations. All MIBs on the SAMI are accessible through the director PPC.

Since only the director PPC accepts SNMP protocol messages from external clients, only the director needs to be configured. All subordinate PPCs forward SNMP traps to the director, and the director will send them out.

To configure the single interface for SNMP, perform the following tasks in global configuration mode:

Table 2-1 lists the MIBs supported by the WSG:

Table 2-2 lists the trap table notifications on the WSG:

Note Use the SNMP Object Navigator (http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en) to obtain SNMP object information. For example, enter the object name ciscoEnhIpsecFlowCertExpiry.

Syslog Details

Additionally, WSG Release 1.2 and above supports a single interface for syslog collection. As part of the Memory Usage Monitoring feature, all PPCs send the syslogs to the director, and the director PPC sends them to an external server (if configured).

The external logging server can be configured only on the director PPC. Logs from any PPC can be viewed on the director (given the correct cpuid).

Understanding WSG Prerequisites

The WSG requires a Cisco 7600 system with these:

• SUP Engine 720, with a Multilayer Switch Feature Card (MSFC),
  running Cisco IOS Release 12.2(33)SRC3,

or

Cisco 7600 Series SUP 32, with a MSFC,
running Cisco IOS Release 12.2(33)SRC3.

For details on upgrading the Cisco IOS release running on the SUP, see the
“Upgrading to a New Software Release” section in the
Release Notes for Cisco IOS Release 12.2(33)SRC3.

• Any module with ports connected to the network.
• Cisco Service and Application Module for IP (Cisco Product Number: WS-SVC-SAMI-BB-K9) with the 2 GB memory option (Cisco Product Number: MEM-SAMI-6P-2GB[=]).
  Release 1.1 of the WSG application ships loaded on the SAMI.

Establishing a PPC Session

To set up VLAN support, establish a session with a PPC. Perform this procedure for each of the six PPCs on a SAMI with WSG.

Note Under conditions like low processor memory, a session to the SAMI may fail. If this occurs, use the physical front-panel console connections to access the SAMI (see the “Establishing a Console Connection on the SAMI” section of the Cisco Service and Application Module for IP User Guide).

To set up a PPC session from the SUP Console, enter:

Assigning a Hostname to a PPC

The default session prompt when you set up a session with a PPC is “switch.” To assign a hostname to a PPC other than switch, enter:

This example shows a session with PPC 3 on a SAMI in slot 6, the hostname is changed to PPC3:

PPC3(config)#

Setting Up VLAN Support

SAMI does not have outside physical interfaces to receive traffic from the network. Instead, the SAMI uses VLAN interfaces to the SUP. To set up VLAN support between the SUP and PPCs, complete tasks in these sections:

• Setting Up the SUP
• Setting Up the PPCs

Setting Up the SUP

For PPCs to receive traffic from the SUP, complete these tasks on the SUP:

• Set up a VLAN for each PPC.
• Assign the VLANs to a VLAN group.
• Assign the VLAN groups to the SAMIs.
• Set up a default gateway VLAN.

Setting Up VLANs for the PPCs

To set up the VLANs for each PPC on the SUP, enter:

To create VLANs 71 to 76 on the SUP Console plus an OAM Vlan 100, enter:

Assigning VLANs to the SAMI

SAMI PPC VLANs must be assigned to the same VLAN group. You cannot assign the same VLAN to many groups. However, you can assign a group to many SAMIs.

By default, one switched virtual interface (SVI) (required if the SUP participates in Layer-3 forwarding) can exist between an MSFC and a SAMI. Create and enable SVIs using the svclc multiple-vlan-interfaces command.

To assign VLANs to a SAMI, enter:

For example:

• To create a VLAN group, group 50, with a VLAN range of 71 to 76, and 100 enter:

• To assign VLAN group 50 to the SAMI in slot 5, enter:

• To enable many SVIs to be set up for SVCLC modules (the SAMIs), enter:

• To view the SAMI group configuration and associated VLANs, enter:

• To view VLAN group numbers for all modules, enter:

Setting Up the PPCs

To complete the configuration tasks for VLAN support do the following on each PPC:

1. Set up the default gateway.

2. Set up a VLAN interface.

3. Assign the interface to the corresponding VLAN on the SUP.

Note Sharing of the same VLAN ID with different PPC’s on SAMI WSG is not supported unless if it is for HA VLAN interface.

To set up the PPCs, enter the following commands from the SUP:

For example:

• To create a VLAN interface on PPC3 on a SAMI in slot 5, enter:

• To verify the interface configuration of VLAN71, enter:

• To define a default gateway, enter:

Single OAM Interface

As described in the previous sections, the WSG uses a single interface for SNMP and syslog messages from all PPCs through the director PPC.

The single OAM interface works with the single-entity mode, allowing all management traffic (such as DNS, CRL, and HTTP) to flow through the same interface on the director PPC. It is desirable to use a single interface per blade for management traffic when only a limited number of management IP addresses are available. Rather than using a separate interface on each PPC on the management network, you can configure the single OAM interface to allow all PPCs on the WSG to use the same interface on the director PPC. Configuring the single OAM interface is a two-step process. First, identify the interface used for OAM traffic. Second, configure oam-ip routes for the management subnets. Once configured, the WSG internally routes all the traffic to the connected OAM subnet (and all management networks configured through the oam-ip route) through the director PPC.

Note You should only use this feature should for protocols that generate minimal amount traffic (for example, CRL).

Note SNMP and SYSLOG are only run on the director PPC. Even though SNMP and Syslog can use the single OAM interface to reach the management network, they do not need to be routed through the director PPC (there is no need to configure the OAM interface and OAM routes for SNMP and SYSLOG purposes).

Configuring the Single OAM Interface

To configure the Single OAM interface feature on the WSG, perform the following tasks:

Here is an example:

Resource Monitoring

Resource monitoring notifies you (using SNMP traps) when utilization of one or more system resources such as CPU, memory, and storage of a system crosses certain predefined thresholds.

Monitoring CPU Usage

The CPU Threshold Notification feature notifies users by generating a SNMP trap message when a predefined threshold of CPU usage is crossed. Two types of CPU utilization threshold are supported: rising threshold and falling threshold. A rising CPU utilization threshold specifies the percentage of CPU resources that, when exceeded for a configured period of time, triggers the cpmCPURisingThreshold notification. Similarly, a falling CPU utilization threshold specifies the percentage of CPU resources that, when CPU usage falls below this level for a configured period of time, triggers cpmCPUFallingThreshold notification.

To configure the CPU Threshold Notification feature, perform the following tasks: use the process cpu threshold rising percentage interval seconds [falling percentage interval seconds] command.

The following example shows how to set a rising CPU threshold notification for total CPU utilization. When total CPU utilization exceeds 95 percent for a period of 5 seconds or longer, a rising threshold notification is sent.

Monitoring Memory Usage

The Memory usage monitoring feature allows syslogs to be generated to indicate that free memory has fallen below a configured threshold, or the system has recovered from a low memory situation.

To configure the Memory Usage Monitoring feature, perform the following tasks:

The following example specifies a threshold of 10000 KB of free processor memory before a low-memory syslog is generated:

Once the available free memory rises to above 5 percent of the threshold (1.05 x 10000 in the above example), another message is generated that indicates that the free memory has recovered.

Configuring WSG Global Parameters

Modifications to most of the global parameters will take effect only when the next activate command is issued for the profile.

Configuring IKE Retry Count

To set the number of IKE retry connection attempts, perform the following task:

Configuring Remote Secret

To set the remote shared secret, perform the following task:

Configuring a Local Address Pool

The WSG keeps a pool of private addresses from the protected network. When the WSG receives an endpoint SA with an internal IP address, it assigns an unused address from the address pool. The address does not expire as long as the SA is up. When the SA is removed, the address is released to the local pool.

When setting up an address pool, note:

• Set up address pools using the start-ip command.
• On the SUP, set up a static route to the PPC. This handles traffic sent to an address in the local address pool to be routed to the PPC.

Note This configuration is optional for site-to-site profiles.

For example, to set up an address pool from which to assign addresses on the SAMI, enter:

Adding the DNS Server to the Address Pool

To specify the DNS server that is passed to the access point (the remote end point) when there is a request for a DNS server during IKE negotiation, perfrom the following tasks:

Configuring Authentication Parameters

For secure communication, the WSG requests and sends X.509 digital certificates to authenticate IPSec endpoints.

Multiple CA Trust Anchors

A trust anchor is a third party the WSG trusts and to which it has a certification path. The trust anchor certifies the WSG. This certificate has information about prefixes that a WSG is allowed to use in router advertisements. Authorization delegation discovery enables a node to adopt a WSG as its default router.

CA Certificate Chaining

A certificate chain is a sequence of certificates with dependent trust relationships. The first certificate is self-signed by the CA. Each subsequent certificate creates an association between a certificate owners, or CAs in the chain. This process creates a trust chain from trusted peer to a CA. The CA endorses the identity of the peer certificate by signing it.

The WSG keeps a list of trusted CA certificates in its root certificate directory. If the CA certificate is not on this list, the WSG will refuse to authenticate the peer until a CA certificate is obtained and validated. If the CA certificate is on this list, the WSG trusts the signed peer certificate and will allow a security association in that peer.

Note This release supports manual certificate installation.

To enable digital certification, complete these tasks:

• Generating an RSA Key Pair and CSR
• Submitting the CSR to the CA
• Specifying Certificates and a Private Key on the WSG
• Configuring the WSG Profile

Generating an RSA Key Pair and CSR

RSA key pairs sign, encrypt, and decrypt. To get a Certificate Authority (CA) you first need a Certificate Signing Request (CSR).

1. The crypto rsa-keygen command makes a private key (wsg.prv file) and a CSR (wsg-pem.csr file) based on the CSR parameters you enter.

2. The private key file is copied to the SUP bootflash or bootdisk, depending on which is available.

3. The public key, the second key of the key pair, is embedded in the CSR.

Note If all WSG instances in a SAMI must share a certificate, use the crypto rsa-keygen command only once on one PPC in the SAMI. If the WSGs must use separate certificates, use the crypto rsa-keygen command on each PPC in the SAMI.

To generate an RSA key pair and CSR, enter the following on a PPC in the SAMI:

To generate an RSA key pair and CSR for a remote peer, enter:

Note RSA key-pairs can be generated outside the PPC. If the CSR and private key are generated outside of the WSG, copy the private key file to the SUP before defining the certificates on the WSG.

Submitting the CSR to the CA

After generating the RSA key pair and CSR:

1. Submit the CSR to a CA using FTP or a cut-and-paste from the console session.

2. The CA signs the CSR using its RSA private key.

3. The CSR becomes a WSG certificate.

4. Copy the certificate to the SUP.

5. Set up the PPCs to use the private key and certificates.

Specifying Certificates and a Private Key on the WSG

When you enter the crypto pki wsg-cert and crypto pki trustpoint commands, the certificates (and optionally, the private key) are copied from the SUP to the WSG, and the WSG configuration is updated.

Note Before you can issue the crypto pki wsg-cert and the crypto pki trustpoint commands, the certificates and a private key must exist on the SUP.

To set the certificates for the WSG to use during authentication, enter:

For example:

• To set up the WSG to use a certificate with the name cert1.crt and a private key file named wsg.prv contained on the SUP, enter:

• To set up the WSG to use a CA certificate with the name cert-ca1.crt on the SUP, enter:

Configuring the WSG Profile

As described in the earlier sections, part of the configuration for the WSG is entered globally. The rest of the configuration is entered by creating a crypto profile.

A profile is a combination of IKE and IPSec parameters that apply to all the tunnels that will get established on the WSG. A profile is created using the crypto profile command. The IKE and IPSec related parameters are entered in the isakmp and ipsec submodes of the crypto profile command mode. A profile must be activated using the activate command before the tunnels can be established.

The profile parameters can only be modified when the profile is in an deactivated state. The profile can be deactivated by issuing the no activate command under the crypto profile submode.

The global configuration for WSG is also effective only when the profile is active. If any global WSG configuration is modified while the crypto profile is in active state, the changes will not take effect till the profile is first deactivated, and then activated again.

The profile name should be unique; you cannot use the same name for two different profiles.

• Configuring the WSG Parameters
• Configuring IKE
• Configuring IPSec

Configuring the WSG Parameters

To set up an IKE identity for the WSG/PPC to use during authentication, enter:

	Command	Purpose
Step 1	WSG# config	Enters global configuration mode.
Step 2	WSG(config)# crypto profile WSG(config-crypto-profile)# profile-type ? remote-access Profile Type remote-access (default) site-to-site Profile Type site-to-site	Enters the crypto profile. A crypto profile can be either remote access type, or site-to-site type. The profile-type command is used to specify the type of each profile that you create. If the type is not specified the default is remote-access. Only one remote access profile can be active. Multiple site-to-site profiles can be active. Note You should take special care to configure the proper access-permit command that corresponds to the profile type used, as described in the access-permit command. Note The maximum number of possible site-to-site profiles supported is 25.
Step 3	WSG(config-crypto-profile)# isakmp	Enters ISAKMP submode.
Step 4	WSG(config-crypto-profile-isakmp)# self-identity id-type type id id	Defines the IKE identity of the local IPSec client, where: self-identity must match the certificate’s identity. Note The supported characters while configuring the self-identity are dash, dot, underscore, a-z, A-Z and 0-9. id-type configures the IKE identify of the local client. The IKE identity is the identity the client uses when authenticating to the gateway. Valid values are: – ip —IP address – dn —Distinguished name – fqdn —Fully-qualified domain name – email —E-mail address Note The maximum size supported for the id-types is 256 bytes. id sets the ID data of the remote IKE client (name, IP address, dn, FQDN, or e-mail address).
Step 5	WSG(config-crypto-profile-isakmp)# sequence-number [extended | short]	Specifies that a 32-bit (short) or 64-bit (extended) sequence number is used for a profile. 32-bit is the default value.
Step 6	WSG(config-crypto-profile-isakmp)# exit	Exits ISAKMP submode.

For example, to set up an id-type of “fqdn,” id “wsg.cisco.com,” on the PPC using the crypto profile “remote-access”:

Extended Sequence Number

WSG Release 1.2 and above adds Extended Sequence Number (ESN) support as longer lifetimes are expected in customer deployments. Additionally, more traffic is expected in site-to-site setups. Extended Sequence Number (64-bit sequence number) implementation is required in such cases. In this release, the sequence number length cannot be negotiated by the peer with the SAMI. The peer will have to match the setting on the SAMI (default is 32-bit sequence number). The 64-bit sequence number can be configured using the above CLI.

Configuring IKE

The goal of IKE negotiation is to find a compatible key exchange on both peers:

1. Peer A sends its allowed IKE policies to Peer B.

2. Peer B compares Peer A’s policies to its highest priority policy.

3. Peer B tries to find policies that have the same values for the following:

– Encryption

– Hash algorithm

– Authentication

– Diffie-Hellman parameters

– Lifetime

4. If Peer B cannot find a match, negotiation fails and IPSec is not established. If Peer B finds a match, negotiation completes and IPSec SAs are established.

To set up IKE values, perform the following tasks:

High Availability

In WSG Release 2.0 and above, inter-chassis stateful 1:1 redundancy is supported. Two redundancy modes are supported: active-standby and active-active (introduced in WSG Release 4.0). In the active-standby mode, redundancy works at the SAMI level. Only PPC3 or all 6 PPCs on the SAMI are in either active or standby state. The PPC of the active SAMI synchronizes its state to the corresponding PPC of the redundant, standby SAMI. In the active-active mode, redundancy works at the PPC level. Only PPC3 and PPC4 on the SAMI are used—one PPC is in active state while the other PPC is in standby state.

The WSG redundancy feature works with all IPSec supported features including IKEv1, IKEv2, ESN, anti-replay, DPD, and NAT-traversal. WSG redundancy is applicable to both remote access and site-to-site tunnels.

If a primary SAMI fails, traffic is switched to the newly active SAMI. The established tunnels stay up and continue to pass traffic after failover, and the IKE/IPSec internal state is synchronized between the active and redundant WSGs. The expected traffic loss during failover is less than one second after detection of the failure. The WSG responds to IKE packets (DPDs and SA INIT messages) and load balancer probes within one second.

There is no impact on the WSG routing for inner and outer addresses after a failover. The WSG maintains IP addresses that are assigned from the local address pool. The newly active SAMI allocates IP addresses from the local pool when a SA is created and releases IP addresses to the local pool when a SA is deleted.

Note WSG does not support the single OAM feature in the active-active redundancy mode.

Note WSG does not support single-entity configuration for application configuration commands.

Configuring High Availability

Follow these steps to configure high availability on redundant WSGs:

Step 1 Shutdown the standby WSG (WSG B) to ensure no IP address conflicts.

Step 2 Configure the node-specific configuration (interface, IP address, alias IP) on the active WSG (WSG A).

Step 3 Configure SVCLC in your SUP for this SAMI slot.

Note If SVCLC is already configured in your SUP, first remove the SVCLC configuration before performing Step 2. Then, reconfigure the SVCLC as in Step 3. These steps ensure that when you configure the alias IP, the ARP broadcast doesn’t reach the SUP.

Step 4 Verify the HA VLAN connectivity.

Caution Do not ping the alias IP to trigger an ARP broadcast.

---

Step 5 Save the configuration and reload WSG B. The redundant WSGs will pair up and the standby WSG will sync the remaining configuration from the active WSG.

Example of High Availability Active-Standby Redundant Pairs

The following example shows how to configure high availability active-standby redundant pairs:

On SAMI A (slot 3/PPC3):

Step 1 Under entity-all mode, configure HA VLAN interface.

Step 2 Configure HA redundancy mode as active-standby with preferred-role set to primary.

Step 3 Save the configuration.

On SAMI B (slot 4/PPC3):

Step 4 Under entity-all mode, configure HA VLAN interface.

Step 5 Configure HA redundancy mode as active-standby with preferred-role set to secondary.

Step 6 Save the configuration.

Step 7 Reload both SAMI A and B.

Example of High Availability Active-Active Redundant Pairs

The following example shows how to configure high availability active-active redundant pairs:

On SAMI A (slot 3/PPC3):

Step 1 Under the entity-all mode, configure the HA VLAN interface.

Step 2 Configure HA redundancy mode as active-active with preferred-role set to primary.

Step 3 Save the configuration.

On SAMI B (slot 4/PPC3):

Step 4 Under the entity-all mode, configure HA VLAN interface.

Step 5 Configure HA redundancy mode as active-active with preferred-role set to secondary.

Step 6 Save the configuration.

Step 7 Reload both SAMI A and B. Failure to do so results in incorrect HA configuration and deployment.

Step 8 When both SAMI A and B are reset at about the same time, the result is:

Step 9 If the reset didn’t happen at the same time, the result is:

Step 10 Slot 3/PPC 4 will then reset due to the revertive option, so the redundant pair will become:

Role Revert After Failover

Network topology ensures that the traffic is distributed across the two IPSec gateways in order to avoid a single point of failure. During a failover scenario, traffic is switched to only the secondary IPSec gateway. When the failed primary card comes back, traffic still flows to only the secondary IPSec gateway. The WSG allows you to restore traffic flow to the primary IPSec gateway so that traffic remains distributed.

The procedure to revert back after a failover is as follows:

1. After a failover, the secondary card comes up as active.

2. When the primary card comes back up as the standby, IKE/IPSec data is synced to the standby card (which is still configured as the primary).

3. The secondary card that is active is then reset.

4. The primary card becomes active again. After the reset, the secondary card becomes standby again.

Note In an active-active redundancy configuration, the revertive option is mandatory. In the case where an active PPC configured as primary revertive fails over, upon coming back up the PPC regains the active role from the redundant PPC.

Configuring Application VLAN/Alias IP Address

For each PPC processor on the SAMI, configure a VLAN with an IP address. This IP address is used by the IKE and ESP traffic from the endpoints. In case of redundancy, this is the same VLAN number configured on both the active and standby PPCs. The alias IP address is configured for a VLAN on both the active and standby PPCs. FAP/HNB uses the alias IP address instead of the active IP address. This alias IP address must be in the same subnet as the VLAN’s active IP address. When a failover occurs, the newly active node starts receiving traffic destined to this alias IP address.

Note Sharing of the same VLAN ID with different PPC’s on SAMI WSG is not supported unless if it is for HA VLAN interface.

In the following example, WSG A is configured with public IP address 88.88.23.33, WSG B is configured with public IP address 88.88.23.34, and the alias IP address is 88.88.23.35. In this case, traffic is sent to the alias IP address, 88.88.23.35. If the active WSG A fails, the standby WSG B takes over, and the newly active WSG B keeps the same tunnel state with the same alias IP address.

The following example shows how to configure the alias IP address on two WSGs:

WSG A, Slot 1/PPC3:

WSG B, Slot 3/PPC3:

Configuring High Availability on SAMI COSLI

In the SAMI COSLI HA infrastructure, a cluster contains a pair of PPCs from two SAMIs, which can be on the same (intra-chassis) or different (inter-chassis) Cisco 7600 router chassis. The PPCs with the same number on a redundant pair of SAMIs are paired together (e.g. SAMI A, Slot 1/PPC3 is paired with SAMI B, Slot 2/PPC3). To accomplish this, configure a unique subnet for these two PPCs.

In the active-standy redundancy mode, for a redundant pair of SAMIs, there are 6 different subnets configured for 6 pairs of PPCs. Even though 6 pairs of PPCs between the two SAMIs are paired independently, all 6 PPCs on the same SAMI are assigned the same role (either active or standby). Configure the same preferred role (either primary or secondary) for all 6 PPCs on each SAMI. A failure from any PPC triggers a switchover to the other SAMI.

In the active-active redundancy mode, only the PPC3 and PPC4 pairs between the SAMIs are used.

There are two kinds of CLIs on COSLI for configuring high availability: node specific CLIs (e.g. the IP address of the node) or non-node specific CLIs (e.g. SNMP). All node specific CLIs have to be entered on each PPC. Non-node specific CLIs are not available when a SAMI is in standby mode. The HA infrastructure filters these CLIs out when syncing between a pair of PPCs.

Configuring the VLAN/IP Address for HA Infrastructure

The HA VLAN and IP addresses are used internally by the HA infrastructure to communicate among the nodes in the same cluster (subnet). To configure VLAN and IP addresses, perform the following steps:

Note These CLI commands must be configured on each PPC. The two PPCs that are to be paired together must be configured to have the same VLAN ID. As a result, 6 different VLAN IDs are used for 6 pairs of PPCs. If you only need to configure site-to-site (S2S) tunnels, only PPC3 needs to be configured. The other PPCs are left unconfigured.

Note Starting in WSG Release 4.0, S2S is supported on PPC3 only (HA active-standby mode) or PPC3 and PPC4 (HA active-active mode).

Note You must also configure these VLANs on the SUP.

The following example shows how to configure the HA VLAN ID and IP addresses for PPC3:

On Slot 1/PPC3:

On Slot 3/PPC3:

Single Point Configuration of VLAN/IP Address for HA Infrastructure

To configure the VLAN and IP address using a single point configuration, perform the following steps:

These CLI commands are available in the entity-all mode on the director PPC (PPC3).

If you execute the following CLI commands on the PPC3:

The configurations of the 6 PPCs will be:

PPC3:

PPC4:

PPC5:

PPC6:

PPC7:

PPC8:

Configuring Redundancy-mode and Preferred-role

To configure the redundancy mode of the HA feature, perform the following steps:

The preferred-role is used to indicate which node should come up as active (primary) or standby (secondary) when both nodes are rebooted at about the same time.

The following example shows how to configure a redundant pair of PPCs in active-standby redundancy mode:

On Slot 3/PPC3:

On Slot 4/PPC3:

Note These CLI commands are available only on PPC3. If executed in the all mode, the command is applied to all 6 PPCs—the same role is assigned to all 6 PPCs. If the command is executed in the single mode, it is applied only to PPC3, and the remaining 5 PPCs will have no redundancy mode configured. The SAMI that is configured with the preferred-role of secondary needs to be reset before the redundant pairs can take effect.

The following example shows how to configure a redundant pair of PPCs in active-active redundancy mode:

On Slot 3/PPC3:

On Slot 4/PPC3:

Note In the active-active redundancy mode, only the PPC3 and PPC4 pairs are used.

Removing HA Redundancy Between a Pair of PPCs

The following example shows how to remove a redundant pair of PPCs in active-standby redundancy mode:

On Slot 3/PPC3:

On Slot 4/PPC3:

The following example shows how to remove a redundant pair of PPCs in active-active redundancy mode:

On Slot 3/PPC3:

On Slot 4/PPC3:

Note You must clean up the remaining (non-HA) configuration and bring the system back to operational state. The system will not be automatically rebooted as a result of removing the HA configuration.

Verifying the HA Configuration

Use the following commands to display information about the HA state at various levels:

The show ha info command shows the configuration, states, and statistics of the local node and its peer:

Redundancy mode (configured) : active-standby

Redundancy state : Redundant

My Node

Current State : Active

Preferred Role : Primary

IP Address : 51.51.51.43

Slot/PPC : 4/3

Peer Node

IP Address : 51.51.51.53

Slot/PPC : 5/3

Bulk Sync Status : Success

Bulk Sync done : Thu Sep 15 01:24:36 2011

HA Revertive : Disabled

S2P4# sh ha info

Redundancy mode (configured) : Active-Active

Redundancy state : Redundant

My Node

Current State : Active

Preferred Role : Primary

IP Address : 77.77.84.24

Slot/PPC : 2/4

Peer Node

IP Address : 77.77.84.34

Slot/PPC : 3/4

Bulk Sync Status : Success

Bulk Sync done : Tue Jun 19 06:54:38 2012

HA Revertive : Enabled

The show ha info brief command shows the configuration and the state of the local node:

The show ha info detail command includes extra information about the cluster and node names:

Redundancy mode (configured) : active-standby

Redundancy state : Redundant

My Node

nodename : node1

Current State : Active

Last State : Un-assigned

Preferred Role : Primary

IP Address : 51.51.51.43

Slot/PPC : 4/3

Peer Node

nodename : node2

IP Address : 51.51.51.53

Slot/PPC : 5/3

Bulk Sync Status : Success

Bulk Sync done : Thu Sep 15 01:24:36 2011

HA Revertive : Disabled

ISync Counters

Total Request Sent : 0

Total Response Rcvd : 0

Total Fail Count : 0

Total Request Rcvd : 0

Total Response Sent : 0

Cluster : cluster12

Active Mgr : node1

Standby Mgr : node2

S2P4# show ha info detail

Redundancy mode (configured) : Active-Active

Redundancy state : Redundant

My Node

nodename : node1

Current State : Active

Last State : Un-assigned

Preferred Role : Primary

IP Address : 77.77.84.24

Slot/PPC : 2/4

Peer Node

nodename : node2

IP Address : 77.77.84.34

Slot/PPC : 3/4

Bulk Sync Status : Success

Bulk Sync done : Tue Jun 19 06:54:38 2012

HA Revertive : Enabled

ISync Counters

Total Request Sent : 3

Total Response Rcvd : 3

Total Fail Count : 0

Total Request Rcvd : 0

Total Response Sent : 0

Cluster : cluster12

Active Mgr : node2

Standby Mgr : node1

Adding or Removing a Redundant Pair

The following sections describe how to configure, add, and remove redundant nodes:

• How to Configure Active-Standby Redundancy Before Both SAMIs are in Service
• How to Configure Active-Active Redundancy Before Both SAMIs are in Service
• How to Add Standby WSG to an Active WSG Already in Service (Active-Standby Mode)
• How to Remove Standby WSG from an Active WSG Already in Service (Active-Standby Mode)

How to Configure Active-Standby Redundancy Before Both SAMIs are in Service

Perform the following steps on the secondary SAMI:

Step 1 Before the secondary SAMI is inserted, please do the following on the SUP:

– Remove the startup-config files for the secondary SAMI on the bootflash or bootdisk:

– Remove the VLAN groups that are tied to the secondary SAMI:

– (Inter-chassis only) Ensure the time is synced between the two SUPs.

Step 2 Insert the secondary SAMI.

Step 3 Add HA VLAN interface for each PPC:

Step 4 Add redundancy-mode with preferred-role for each PPC using entity-all option from PPC3:

Step 5 Configure all node-specific commands for each PPC:

Step 6 Configure alias IP addresses for the WSG for each PPC:

Step 7 Save the configuration for each PPC:

Perform the following steps on the primary SAMI:

Step 1 Add HA VLAN interface for each PPC:

Step 2 Add redundancy-mode with preferred-role for each PPC using entity-all option from PPC3:

Step 3 Configure all node-specific commands for each PPC:

Step 4 Configure alias IP addresses and all other commands for the WSG for each PPC:

Step 5 Save the configuration for each PPC:

Step 6 Check HA status:

The primary SAMI is now ready for service. There is no need to reboot.

Perform the following steps on the secondary SAMI:

Step 1 Reload the secondary SAMI. While it is booting back up, configure its VLAN groups on the SUP:

Note If this command is not executed before the SAMI comes back up, the SAMI cannot come up as the standby. In this case, repeat Step 1.

Step 2 After the SAMI is back up and running, check HA status:

If the secondary SAMI is not in the standby state, check the following:

– Ensure VLAN groups for this SAMI are added to the SUP

– Ensure preferred roles are configured correctly on both cards

– Ensure the peer's HA IP address is reachable

Step 3 Check whether WSG CLIs are synced from the active card:

How to Configure Active-Active Redundancy Before Both SAMIs are in Service

Perform the following steps on the secondary SAMI:

Step 1 Before the secondary SAMI is inserted, please do the following on the SUP:

– Remove the startup-config files for the secondary SAMI on the bootflash or bootdisk:

– Remove the VLAN groups that are tied to the secondary SAMI:

– (Inter-chassis only) Ensure the time is synced between the two SUPs.

Step 2 Insert the secondary SAMI.

Step 3 Add HA VLAN interface for each PPC:

Step 4 Add redundancy-mode with preferred-role for each PPC using entity-all option from PPC3:

Step 5 Configure all node-specific commands for each PPC:

Step 6 Configure alias IP addresses for the WSG for each PPC:

Step 7 Save the configuration for each PPC:

Perform the following steps on the primary SAMI:

Step 1 Add HA VLAN interface for each PPC:

Step 2 Add redundancy-mode with preferred-role for each PPC using entity-all option from PPC3:

Step 3 Configure all node-specific commands for each PPC:

Step 4 Configure alias IP addresses and all other commands for the WSG for each PPC:

Step 5 Save the configuration for each PPC:

Step 6 Check HA status:

The primary SAMI is now ready for service. There is no need to reboot.

Perform the following steps on the secondary SAMI:

Step 1 Reload the secondary SAMI. While it is booting back up, configure its VLAN groups on the SUP:

Note If this command is not executed before the SAMI comes back up, the SAMI cannot come up as the standby. In this case, repeat Step 1.

Step 2 After the SAMI is back up and running, check HA status:

If the secondary SAMI is not in the standby state, check the following:

– Ensure VLAN groups for this SAMI are added to the SUP

– Ensure preferred roles are configured correctly on both cards

– Ensure the peer's HA IP address is reachable

Step 3 Check whether WSG CLIs are synced from the active card:

How to Add Standby WSG to an Active WSG Already in Service (Active-Standby Mode)

Perform the following step on the active SAMI:

Step 1 Ensure the active SAMI is not paired with another SAMI:

If it has a peer SAMI, follow the procedure in the section below to remove the standby WSG.

The preferred-role should be set to primary. If not, set it to primary using the ha redundancy-mode command (this will not impact service):

Perform the following steps on the secondary SAMI:

Step 1 Before the secondary SAMI is inserted, please do the following on the SUP:

– Remove the startup-config files for the secondary SAMI on the bootflash or bootdisk:

– Remove the VLAN groups that are tied to the secondary SAMI:

– (Inter-chassis only) Ensure the time is synced between the two SUPs.

Step 2 Insert the secondary SAMI.

Step 3 Add HA VLAN interface for each PPC:

Step 4 Add redundancy-mode with preferred-role for each PPC using entity-all option from PPC3:

Step 5 Configure all node-specific commands for each PPC:

Step 6 Configure alias IP addresses for the WSG for each PPC:

Step 7 Save the configuration for each PPC:

Step 8 Reload the secondary SAMI. While it is booting back up, configure its VLAN groups on the SUP:

Note If this command is not executed before the SAMI comes back up, the SAMI cannot come up as the standby. In this case, repeat Step 1.

Step 9 After the SAMI is back up and running, check HA status:

If the secondary SAMI is not in the standby state, check the following:

– Ensure VLAN groups for this SAMI are added to the SUP

– Ensure preferred roles are configured correctly on both cards

– Ensure the peer's HA IP address is reachable

Step 10 Check whether WSG CLIs are synced from the active card:

How to Remove Standby WSG from an Active WSG Already in Service (Active-Standby Mode)

Perform the following steps on the secondary SAMI:

Step 1 Ensure the secondary SAMI is in the standby state and paired with an active WSG:

Step 2 Remove the VLAN groups that are tied to this SAMI from the SUP:

Step 3 Remove the VLAN interfaces that have alias IP address configured for each PPC:

Step 4 Remove HA VLAN interface for each PPC:

Step 5 Remove redundancy-mode with preferred-role for each PPC using entity-all option from PPC3:

Step 6 Save the configuration for each PPC:

WSG Deployment Modes

Site-to-site or remote access tunnels can be established using active-active HA redundancy mode, but you must switch between WSG deployment modes. The two deployment modes are site-to-site and remote-access. Switch between the two modes by first deactivating all profiles and reloading the SAMIs. Once the SAMIs are back up, activate the particular profile. Depending on the profile type, only tunnels of that type can be established while being in that deployment mode. Verify the deployment mode using the show crypto deployment-mode CLI command.

Bulk Sync

Bulk sync procedure involves the configuration sync of the standby SAMI with the active SAMI, when a card running with the no redundancy scheme is configured for redundancy, and it subsequently receives a standby notification.

The configuration sync done on the standby card is a two part sync procedure; the first part involves syncing the running configuration from the active card, and the second part consists of syncing the startup configuration of the active card. These two config sync are autonamous in operation. The module that is responsible for carrying out this bulk sync procedure is the configuration controller.

Note In the active-active HA reundancy mode, bulk sync takes place between the PPC pairs and not the SAMI pairs.

Bulk Sync Procedure

When the config-controller is assigned the active role, it performs the following actions:

• If assigned the active role, it parses the startup-config file and applies all the commands except the HA-specific CLIs (HA-specific commands are applied during bootup before the role is assigned).

If the config-controller is assigned a standby role, it will perform the following actions:

• If it is assigned the standby role, it sends a bulk-sync request to the active peer PPC.
• Upon receiving the bulk-sync request, the config-controller on the active peer strips the node-specific CLIs from the running-configuriation, and transfers them to the standby card.
• The standby card applies those CLIs.
• After it completes the running-configuration, the config-controller performs the same procedure on the startup-configuration. The standby card merges it with its own node-specific commands in the startup-configuration, and saves it to the SUP.
• Notifies the HA manager that it is now Standby-Ready.

In active-active HA redundancy mode, bulk sync takes place between PPC pairs and not between SAMI pairs.

Incremental Sync

When a non-node-specific command is applied to the active card, the configuration needs to be sent to the standby peer, if it exists. A registered callback function for that command is invoked on the standby peer to apply it locally.

A message is sent to the standby peer when a copy running-config startup-config is applied on the active card. The startup-config file for the standby peer is saved on the SUP.

Failover

When a fatal error is detected on a node of the active card, the process is terminated due to the setting in the information model. Since the HA configuration for the system manager is set to reset for the restart option, it causes the SAMI to reboot. The standby card gets notification from the cluster manager to go active. The newly-active node configures the alias IP address and sends an ARP announcement for this alias IP address, if it is configured.

When a fatal error is detected on a node of the standby card, the standby card reboots.

In active-active HA redundancy mode, failover can occur between PPC pairs without affecting other PPC pairs on the SAMIs involved.

Configuring Revert Back After Failover

Reverting back after failover may not be required for all the deployment scenarios, so this functionality is configurable.

In WSG releases prior to 4.0, perform the following tasks to enable the revert-back feature:

Starting in WSG Release 4.0, the ha revertive functionality is replaced by a configurable option in the ha redundancy-mode command using the revertive keyword.

The failover revert-back configuration is displayed in the output of show ha info and show ha info brief commands. Follow these steps to revert back after a failover:

1. Failover occurs on SAMI 1 (preferred-role = primary, state = active).

2. SAMI 2 (preferred-role = secondary, state = standby) transitions to active state.

3. SAMI 1 comes up again, and COSLI bulk sync occurs with SAMI 2.

4. WSG also bulk syncs all of its data with SAMI 2. Once the bulk sync is complete, the WSG application on SAMI 2 indicates this to the configuration controller using a new MTS message.

5. The configuration controller FSM handles this new event from the WSG in its event handler of active state.

6. In this event handler, the configuration controller first checks if the ha revertive command is configured. If command is not configured, no action is taken. Otherwise, step 7 is performed.

7. In case the configured preferred-role of the node is secondary and the HA state is active, SAMI 2 reloads.

8. SAMI 1 transitions to active state, and SAMI 2 comes up in standby state.

IKE SA Handling

IKE SA Create

IKE SAs are created on the standby WSG when IKE SAs are created on the active WSG.

IKE SA Update

IKE SAs are updated on the standby when IKE SAs are updated on the active for following reasons:

• IKE SA window has been updated due to initiator or responder exchange
• Remote access attributes have been set
• NAT reboot has been detected and IKE SA remote address or port has changed

IKE SA Rekey

Rekeyed IKE SA is imported, and the old IKE is deleted on the standby WSG when the IKE SA is rekeyed on the active WSG.

IKE SA Delete

IKE SAs are deleted on the standby WSG when the IKE SAs are deleted on the active WSG.

IKE Message ID

The WSG synchronizes IKE Message IDs between the active and standby WSGs, otherwise IKE SAs are unusable. If an informational exchange like DPD is performed after the SA is imported on the standby, the SA needs to be updated.

The WSG maintains the DPD initiation/response successfully after failover. Additionally, the WSG maintains IKE parameters (like encryption and hashing Algorithms), and Diffie-Hellman groups after failover.

IKE SA Life Time

The WSG maintains the Phase 1 lifetime value instead of resetting on the newly active after failover.

IKE NAT Keepalives

The WSG maintains the different NAT states after failover. NAT keepalives are still successfully initiated and responded to after failover, and on time.

IPSec SA Handling

IPSec SA Create

IPSec SAs are created on the standby WSG when IPSec SAs are created on the active WSG.

IPSec SA Update

IPSec SAs are updated on the standby when IPSec SAs are updated on the active for following reason:

• NAT reboot is detected for the parent IKE SA, and the peer address or port has changed.

IPSec SA Rekey

Rekeyed IPSec SA are imported, and old IPSec is deleted on the standby WSG when the IPSec SA is rekeyed on the active WSG.

IPSec SA Delete

IPSec SAs are deleted on the standby WSG when the IPSec SAs are deleted on the active WSG.

IPSec SA Parameters

WSG maintains IPSec parameters protocol, encryption and authentication algorithms, PFS groups, anti-replay window size, and sequence numbers both 32 bit and 64 bit (ESN). It also maintains UDP encapsulation after failover.

IPSec SA Life Time

The WSG maintains the Phase 1 lifetime value instead of resetting on the new active after failover.

IPSec Outbound SA Sequence Numbers

The Sequence number is incremented for each data packet transmitted. 32 bit Sequence number is transmitted in the ESP header of each packet. In case of ESN, only the lower 32 bit sequence number is transmitted. The high-order 32 bits are maintained as part of the sequence number counter by both transmitter and receiver, and are included in the computation of the ICV. If the receiver receives a sequence number lower than the expected number, the packets may be dropped depending on Anti-replay parameters.

The WSG on standby updates the outbound sequence number of the IPSec SA to the estimated value, otherwise the sequence number goes out sync.

IKE and IPSec SAs are imported to the standby when it comes up. During import, the policy manager calls the fast API to Program Nitrox and IXP modules for inbound and outbound SAs. Outbound sequence number is the estimated sequence number based on IMIX or 64-byte traffic.

The sequence number is updated from the active to the standby at periodic intervals. The policy manager triggers the fast API to Program Nitrox and IXP modules for each periodic update.

seqnumber = active sequence number + estimated sequence number (packets processed for 5 minutes)

IPSec SA Replay Window

The WSG on the standby updates inbound anti-replay window base and mask of IPSec SA to prevent replay attack. The base value is the highest sequence number that has been received so far. This will limit the number of packets that can be replayed after a failover.

The Anti-replay window base and mask is updated periodically from the active to the standby at regular intervals.

When the standby comes up, IKE and IPSec SAs are imported to the standby. During import, the policy manager calls fast API to Program Nitrox and IXP modules for inbound and outbound SAs.

Certificate, CRL, DNS Handling

The WSG maintains certificate status between the the active and standby (Local Certificate, private keys and trustpoint certificates should be synced between the redundant pair) by using sync message or export and import mechanism. When a new standby WSG is inserted, the static certificates are synced to the standby. WSG does not maintain the DNS and CRL cache across failover. The DNS and CRLs are cached on the new active during new tunnel establishment.

Configuring IPSec

To protect addresses to which traffic is allowed from the tunnel, perform the following tasks:

Here is an example of the new access-permit command with the protocol options:

Site-to-Site Scalability

In site-to-site (S2S) scenario, tunnels are established between the WSG and the remote peer just like in a remote access scenario. The source of the traffic inside the tunnel is from multiple IP addresses on the remote peer’s side. As in the remote access scenario, the addresses on the trusted network behind the WSG can be a single IP or a network.

Additionally, in a S2S scenario, the remote peer can setup multiple tunnels to the WSG.

The TS can contain the protocol, source port range and destination port range, in addition to the source and destination IP range.

In case of site-to-site type tunnels, the WSG can initiate the tunnels to the peer device.

Note DHCP is supported for RAS profiles and not for site-to-site profiles.

Scalability and Throughput Improvement Description

In previous WSG releases, the S2S traffic selector lookup was done by looking up an array of TS on the IXP. This linear search limited the performance of the site-to-site traffic selector lookup algorithm. In WSG Release 2.0 and above, the traffic selector lookup algorithm speeds up the performance for site-to-site. There is no change to the remote access traffic selector lookup because it is different from the lookup algorithm for site-to-site, and is already optimized.

The new site-to-site traffic selector lookup is based on a hash lookup of the packet’s source and destination IP addresses after applying a network mask.

The list of source-mask and destination-mask combinations needs to be provided by the user through the CLI. The size of this list is limited to 6 entries. For best performance, the subnet combination that carries the most traffic needs to be configured on the top of the list.

The subnet combination values need to be figured out during network design and configured initially. Graceful addition, modification, and deletion of entries is not supported once the S2S profiles are activated. To modify the subnet combination configuration, deactivate all S2S profiles, change the subnet combination configuration, and then reactivate the S2S profiles. All established tunnels are lost during this procedure.

The access-permit command under site-to-site profile now accepts a netmask instead of an end IP address. The access-permit network configured for a profile can be larger than what is negotiated by a remote peer. This allows multiple peers to connect to the same site-to-site profile, and negotiate a subnet of the configured network. The TS negotiated by the peers of a WSG must be unique (no overlap).

The negotiated TS for the tunnels must be subnets, and not arbitrary ranges.

When a peer negotiates the TS with WSG, it must intersect one of the configured entries in the subnet combination table. If not, the negotiation is rejected. Debug and syslog messages are generated if tunnel negotiation fails under this condition.

TS negotiations based on protocol and port are also supported, but algorithm improvements only take effect when the different child SAs have TS that have unique source and destination IP subnets. There is a performance decrease if there are child SAs that differ only by port or protocol in their TS.

Upto 16666 S2S tunnels are supported per SAMI. S2S tunnels can only be configured on the director PPC.

WSG Release 2.0 and above does not support the IKE protocol that allows a peer to negotiate multiple TSs for the same S2S tunnel. Each S2S tunnel can negotiate only one TS. All other features that are currently supported for site-to-site and remote access are maintained in this release.

Configuring Scalability and Throughput

To configure the WSG to accept the netmask for the source and destination IP address, perform the following tasks:

Here is an example of the configuration:

Configuring Subnet Combination

This command assists the IXP for site-to-site performance improvement. This configuration is made based on the design of the network.

It is mandatory to enter one or more of this command before activating any S2S profiles. S2S profile cannot be activated if this command is not configured on the WSG.

To enable this feature, perform the following tasks:

Here is an example of the configuration:

Certificate Management Protocol

WSG releases prior to Release 2.0 can generate a private key, a certificate request and support manual enrollment with CA server. WSG Release 2.0 introduced support for Certificate Management Protocol (CMPv2). CMP allows for automatic enrollment with CA server. The Keypair is generated locally and the certificate request can be sent to CA server using existing network connectivity. The certificate can be downloaded without the need for manual intervention.

Only one outstanding CMPv2 initialize, enroll, or update request is permitted at any time from a WSG. You can place a new request after the certificate is obtained for the outstanding request. Alternatively, you can clear the pending request and place a new request. The certificate and the private key will be saved on the SUP. If the SUP is redundant, the files are also copied to the redundant SUP.

In case of the WSG HA, the certificate is copied over to the SUP on the redundant chassis only when the certificate configuration command is entered. If the SUP on the secondary chassis is redundant, the certificate is also copied to the redundant SUP.

Files written to the SUP storage cannot be deleted using the WSG CLI. They need to be deleted using the SUP CLI. Revoke and recover functions are not supported in WSG Release 2.0 and above.

Note A pending CMPv2 request from the WSG is not saved across reboots or WSG switchover. Do not reboot the WSG when a request is pending. If the WSG is rebooted or switched over during a pending request, the request must be reinitiated.

This feature only brings in an additional method of obtaining the certificates for WSG using new EXEC commands. The original manual enrollment process can still be used.

WSG Release 3.0 introduced support for automatic renewal of certificates, which includes automatic update and automatic retrieve. The automatic update of CMPv2 certificates is similar to the WSG CMP update command, but is performed by the system when the certificate is within a specified window before expiring (2 to 60 days). The automatic retrieval of certificates retrieves an updated certificate from the SUP when the certificate is within a specified window before expiring (2 to 60 days). Up to 20 certificates may be configured for automatic renewal.

Prior to Cisco 7600 WSG Release 4.4, WSG supported only TCP as the CMPv2 Transport Protocol. With Release 4.4 and above, WSG will support both transport protocols, TCP and HTTP. The HTTP based flows will be RFC 4210/4211/6712 compliant.

Configuring Certificate Management Protocol

To configure the WSG to generate the private key and make an initialize request to the CA server using CMPv2, perform the following tasks. The filenames for the private key and the certificate files will be automatically generated by the system.

	Command	Purpose
Step 1	WSG(config)# crypto cmp transport transport protocol	Configures the Transport Protocol for CMPv2 Messages. transport protocol —Transport Protocol options are http, and tcp. http—HTTP will be used as transport Protocol for all CMPv2 messages. tcp—TCP will be used as transport Protocol for all CMPv2 messages. The default is tcp.
Step 2	WSG# crypto cmp initialize modulus modulus id-type id-type id id subject-name subject string ca-psk reference-number:key ca-root root certificate ca-url url	Configures the WSG to generate the private key and make an initialize request to the CA server using CMPv2. This request for the client’s initial certificate is authenticated using the reference number and corresponding PSK received from the CA. modulus—Modulus of the generated certificate: 512, 1024, or 2048. id-type—Type of the ID: fqdn or ip. id—Word that is of id-type. subject string—Subject string of the certificate in double quotes. Note The supported characters while configuring the subject-name are dash, dot, underscore, a-z, A-Z and 0-9. The maximum size supported for the string is 256 bytes. reference-number:key—PSK provided by the CA server for CMPv2 operation. root certificate—Filename of the root certificate of the CA server (file present on SUP disk). url—URL where the CA server listens to requests.
Step 3	WSG# crypto cmp enroll current-wsg-cert wsg_certificate current-wsg-private-key wsg_privatekey modulus modulus id-type id-type id id subject-name subject string ca-root root certificate ca-url url	Makes an enroll request to the CA server using CMPv2. The exisiting WSG certificate and private key are user provided as input parameters to the CLI. The filenames for the new private key and the certificate files are automatically generated by the system. This request is similar to initialize except that it is authenticated using public-key methods. wsg_certificate—Current valid WSG certificate. wsg_privatekey—Current valid private key corresponding to the certificate provided in the previous parameter. modulus—Modulus of the generated certificate: 512, 1024, or 2048. id-type—Type of the ID: fqdn or ip. id—Word that is of id-type. subject string—Subject string of the certificate in double quotes. Note The supported characters while configuring the subject-name are dash, dot, underscore, a-z, A-Z and 0-9. The maximum size supported for the string is 256 bytes. root certificate—Filename of the root certificate of the CA server (file present on SUP disk). url—URL where the CA server listens to requests.
Step 4	WSG# crypto cmp update current-wsg-cert wsg_certificate current-wsg-private-key wsg_privatekey ca-root root certificate ca-url url	Sends an update request to the CA server using CMPv2 to update the existing WSG certificate. The exisiting WSG certificate and private key is provided by the user as input parameters to the CLI. The filenames for the new private key and the certificate files are automatically generated by the system. wsg_certificate—Current valid WSG certificate. wsg_privatekey—Current valid private key corresponding to the certificate provided in the previous parameter. root certificate—Filename of the root certificate of the CA server (file present on SUP disk). url—URL where the CA server listens to requests.

Here is an example of the crypto cmp transport command:

Here is an example of the crypto cmp initialize command:

Here is an example of the crypto cmp enroll command:

Here is an example of the crypto cmp update command:

The CA server may not immediately return the certificate. In this case, periodically use the crypto cmp poll command to check for availability. These commands are used if the request for a Privileged EXEC CMPv2 configuration command is pending.

To configure the WSG to use the certificate, use the following configuration commands. The filenames for the private key and certificate files will be the same filenames generated using the Privileged EXEC CMP initialize and enroll commands.

To configure CMPv2 automatic renewal, use the following configuration commands. The filenames for the private key and the certificate files will be the same filenames generated using the Privileged EXEC CMP initialize, enroll, or update commands. There is no implied command sequence in this list. Up to 20 certificate/private key pairs may be configured for automatic renewal on the WSG.

Timeline for CMPv2 certificate generation and manual certificate update:

1. CMP Initialize

2. CMP Enroll

3. Copy files to other Cisco 7600s

4. Use crypto pki wsg-cert command on all Cisco 7600s using the certificate

5. CMP Update

6. Copy files to other Cisco 7600s

7. Use crypto pki wsg-cert command on all Cisco 7600s using the certificate

8. Repeat before every expiration

Timeline for CMPv2 certificate generation and automatic certificate update:

1. CMP Initialize

2. CMP Enroll

3. Copy files to other Cisco 7600s

4. Use crypto pki wsg-cert command on all Cisco 7600s using the certificate

5. Use crypto cmp auto-update on one WSG and crypto cert renewal retrieve on all other WSGs using the certificate

6. No further action, unless the CA does not renew the certificate

Online Certificate Status Protocol

Currently, the WSG uses a CRL (Certificate Revocation List obtained from the CRL server), a file containing the list of certificates that have been revoked. If a peer negotiates a tunnel with a revoked certificate listed in the CRL file, the WSG will reject that negotiation. The CRL file is maintained one per trust anchor. The first negotiated tunnel for that trust anchor will retrieve the CRL file and cache it on the WSG. Subsequent negotiations will reuse the CRL file. The CRL file has an expiry data that denotes whether it is valid.

Some characteristics of the CRL mechanism make it undesirable in certain solutions. The longer the list, the longer it takes to download the CRL file. Additionally, a certificate can be revoked at any time, and the WSG will use the cached entry until the next time it retrieves the file.

The Online Certificate Status Protocol (OCSP) feature addresses some of the limitations of CRL. OCSP works to achieve the same objective as the CRL mechanism; to determine if a certificate offered by a peer has been revoked. However, OCSP differs from CRL in that the revocation status is obtained on a per-certificate basis rather than a trust anchor-basis. Since the revocation status is obtained when the certificate is first seen by the WSG, the status is up-to-date.

There is no explicit configuration. The only requirement is that CRL should be enabled for the corresponding trust anchor (we have a common knob for CRL and OCSP).

OCSP is not the best mechanism to check for certificate status in all solutions. There will be an impact to the tunnel setup rate, as each setup requires that the certificate status be verified.

DHCP Address Allocation

Previous WSG releases supported allocating IPv4 addresses from a DHCP server, or from a local IP address pool. The WSG communicates with the DHCP server as a DHCP relay agent, as configured by RFC 3046.

From Release 4.3 onwards, WSG also supports allocating IPv6 addresses from a DHCPv6 server. The WSG communicates with the DHCPv6 server as a DHCPv6 relay agent, as configured by RFC 3315. This section describes the DHCP interface from the WSG to the DHCP server, and how address pools are allocated.

Also, the WSG supports requesting DNS server IPs from the DHCP server or it can even be configured locally. As the WSG supports both DHCP configured and locally configured DNS IPs, preference will be given to IPs received from the DHCP Server. As an example, if we receive 3 DNS IPs from DHCP server and we have one DNS IP locally configured, then WSG will send only the 3 DNS IP which are received from DHCP server, since the WSG at most supports 3 DNS IPs. In case if we receive only 2 DNS IPs from DHCP server and having one locally configured DNS IP, then all locally configured and DHCP received DNS IPs will be forwarded to remote IPsec client.

The WSG sends messages to the DHCP server under various conditions. It, the WSG, uses “RAPID COMMIT” option to assign DHCPv6 addresses. All DHCP messages are unicast to the DHCP servers by the WSG. The WSG does not send or receive broadcast messages.

Each PPC is configured with its own unique giaddr in case of IPv4 and link address in case of IPv6. Each address pool is associated with a giaddr/link address. The giaddr/link address is sent in a DHCP message and indicates to the DHCP server which address pool an IP address should be allocated from. The address pool configured on the DHCP server for each PPC can be from one or more subnets. Each subnet can be of any size. Multiple PPC of SAMI WSG can share the same address pool on the DHCP server. Based on the available pool addresses, the server will allocate addresses for the client. Server may or may not allocate the same address for different requests from the same client, depending on server configuration.

All DHCP interactions on the WSG can be debugged using the appropriate debug command. Syslogs are generated for DHCP operation status at the appropriate log level. The IP address assigned to a remote access client can be discovered using CLI commands that show details of an IPsec SA. The WSG maintains statistics for a number of DHCP messages (per type) that are sent and received. You can display these statistics using the appropriate CLI command.

During tunnel set-up time, the WSG requests a lease time for the address assigned by the DHCP server. If the lease time returned by the DHCP server is less then 2 times the IKE lifetime, the tunnel setup fails and the address is released. The DHCP statistics, debugs, and syslog events are recorded for this event. Under normal circumstances, the WSG renews the lease during each phase-1 rekey, and the lease is never allowed the expire. However, if the lease renewal fails, the assigned address is released and the tunnel is deleted. The DHCP statistics, debugs, and syslog record this event, as well.

The DHCP address allocation feature is compatible with the Single-OAM feature on the WSG. However, the DHCP server must be configured to respond to the IP address in the discover/request rather than the giaddr.

Note DHCP is supported for RAS profiles and not for site-to-site profiles.

Client Identification

When the WSG contacts the DHCP server to obtain an IP address, it sends a unique ID in the DHCP messages. This client id (CID) is sent in the Client Identifier option (61) of the DHCP messages. The CID is either the entire IKE ID, or the CN field of a DN formatted IKE ID. The type field in the Client Identifier option is by default set to 0 unless you explicitly configure it for a different value.

Tunnel Rekey

The DHCP lease is renewed only on a phase-1 rekey. No DHCP action is taken on a phase-2 rekey (whether initiated by WSG or client).

IKE Timeout

When the WSG times out while waiting for a response to an IKE request from the HNB, the DHCP lease is released.

Load Balancing

The presence of a load balancer between an HNB and WSG(s) does not affect how the DHCP feature works in normal situations. However, if an HNB disconnects without deleting the tunnel, and then reconnects later, the load balancer might send the HNB to a different PPC. If this occurs, the DHCP server still has an active lease from the address pool for the original PPC. When the DHCP server sees the same HNB (same client identifier) from a different PPC, it needs to release the original lease and allocate a new IP address from the new PPC address pool.

High Availability

The DHCP Address Allocation feature is designed to work with a WSG is operating in a 1-1 redundant mode. The DHCP user configuration is synced from the active to standby WSG. The complete DHCP internal state is exported from the active WSG to the standby WSG. After failover the DHCP operations continue as specified for the active tunnels. But tunnels that were being setup during failover will not survive during the failover. Once the tunnel is setup, the DHCP operations must complete on either the old or new active card on failover.

Configuring DHCP Address Allocation

To configure the WSG to perform DHCP Address Allocation, perform the following tasks:

To monitor and troubleshoot the DHCP Address Allocation feature, perform the following tasks:

Here is a running configuration example:

Here is a running configuration example of WSG with DHCPv6 server:

IPv6

IPv6 support in WSG Release 3.0 includes support for both IPv6 IKE and IPv6 ESP packets and related IPv6 addressing where required. WSG Release 3.0 and above supports all four of the following combinations of IPv4/IPv6 encapsulation in the tunnels:

• IPv6 Over IPv6
• IPv6 Over IPv4
• IPv4 Over IPv6
• IPv4 Over IPv4

Configuring IPv6

The PPC requires an IPv6 VLAN interface to be configured to act as an IPv6 IKE server. The other changes required are to the traffic selectors inside the profile. The traffic selector accepts IPv6 addresses.

All the profile-based configuration remains the same. Changes have been made to the CLI at the IP address option level. Every option to enter an IP address now accepts either an IPv4 or IPv6 address.

IPv6 IP addresses for self identity are supported. Access Permit, Address pools, Local IP, Peer IP and all other CLIs that accept an IP address as a parameter have been enhanced for IPv6.

The traffic selector determines the protocol of the secured traffic inside the tunnel. The local-ip and peer-ip determine the protocol used for IKE exchange and the IP addresses in the outer header of the ESP packets sent out of WSG datapath to the peer.

The following is a sample configuration of an IPv6-over-IPv6 tunnel:

The following is a sample configuration of an IPv6-over-IPv4 tunnel:

The following is a sample configuration of an IPv4-over-IPv6 tunnel:

The following is a sample configuration of an IPv4-over-IPv4 tunnel: