Cisco Virtual Security Gateway for Nexus 1000V Series Switch Configuration Guide, Release 4.2(1)VSG1(1)

Redundancy

Cisco VSG redundancy is equivalent to HA pairing. The possible redundancy states are active and standby. An active Cisco VSG is paired with a standby Cisco VSG. HA pairing is based on the Cisco VSG ID. Two Cisco VSGs that are assigned the identical ID are automatically paired. All processes running in the Cisco VSG are data path critical. If one process fails in an active Cisco VSG, a failover to the standby Cisco VSG occurs instantly and automatically.

Isolation of Processes

The Cisco VSG software contains independent processes, known as services, that perform a function or set of functions for a subsystem or feature set. Each service and service instance runs as an independent, protected process. This way of operating provides a highly fault-tolerant software infrastructure and fault isolation between services. A failure in a service instance does not affect any other services that are running at that time. Additionally, each instance of a service can run as an independent process, which means that two instances of a routing protocol can run as separate processes.

Cisco VSG Failover

When a failover occurs, the Cisco VSG HA pair configuration allows uninterrupted traffic forwarding by using a stateful failover. For information about a Cisco VSG failover, see the “Cisco VSG HA Pair Failover” section.

System Manager

The System Manager (SM) directs overall system function, service management, and system health monitoring, and enforces high-availability policies. It is responsible for launching, stopping, monitoring, and restarting services. The SM is also responsible for initiating and managing the synchronization of service states and supervisor states.

Persistent Storage Service

The Persistent Storage Service (PSS) stores and manages the operational run-time information and configuration of platform services. The PSS component works with system services to recover states if a service restart occurs. It functions as a database of state and run-time information, which allows services to make a checkpoint of their state information whenever needed. A restarting service can recover the last known operating state that preceded a failure.

Each service that uses PSS can define its stored information as private (it can be read only by that service) or shared (the information can be read by other services). If the information is shared, the service can specify that it is local (the information can be read only by services on the same supervisor) or global (it can be read by services on either supervisor or on modules).

Message and Transaction Service

The message and transaction service (MTS) is a high-performance interprocess communications (IPC) message broker that specializes in high-availability semantics. The MTS handles message routing and queuing between services on and across modules and between supervisors. The MTS facilitates the exchange of messages, such as event notification, synchronization, and message persistency, between system services and system components. The MTS can maintain persistent messages and logged messages in queues for access even after a service restart.

HA Policies

The Cisco NX-OS software usually allows each service to have an associated set of internal HA policies that define how a failed service is restarted. When a process fails on a device, System Manager either performs a stateful resart, a stateless restart, or a failover.

Note For a Cisco VSG, only processes borrowed by a Cisco VSG from a VSM restart. Processes native to a Cisco VSG, such as policy engine or inspect, do not restart. A failed native Cisco VSG process causes an automatic failover.

Cisco VSG Roles

The Cisco VSG roles are as follows:

• Standalone—This role does not interact with other Cisco VSGs. You assign this role when there is only one Cisco VSG in the system. This role is the default.
• Primary—This role coordinates the active/standby state with the secondary Cisco VSG. It takes precedence during bootup when negotiating the active/standby mode. That is, if the secondary Cisco VSG does not have the active role at bootup, the primary Cisco VSG takes the active role. You assign this role to the first Cisco VSG that you install in an HA Cisco VSG system.
• Secondary—This role coordinates the active/standby state with the primary Cisco VSG. You assign this role to the second Cisco VSG that you add to a Cisco VSG HA pair.

HA Pair States

The Cisco VSG HA pair states are as follows:

• Active—This state indicates the Cisco VSG is active and controls the system. It is visible to the user through the show system redundancy status command.
• Standby—This state indicates that the Cisco VSG has synchronized its configuration with the active Cisco VSG so that it is continuously ready to take over in case of a failure or manual switchover.

Cisco VSG HA Pair Synchronization

The active and standby Cisco VSGs automatically synchronize when the internal state of one is active and the internal state of the other is standby.

If the output of the show system redundancy status command indicates that the operational redundancy mode of the active Cisco VSG is none, then the active and standby Cisco VSGs are not yet synchronized.

This example shows the internal state of Cisco VSG HA pair when they are synchronized:

vsg# show system redundancy status

Redundancy role

---------------

administrative: primary

operational: primary

Redundancy mode

---------------

administrative: HA

operational: HA

This supervisor (sup-1)

-----------------------

Redundancy state: Active

Supervisor state: Active

Internal state: Active with HA standby

Other supervisor (sup-2)

------------------------

Redundancy state: Standby

Supervisor state: HA standby

Internal state: HA standby

vsg#

Failover Characteristics

A failover occurs when the active Cisco VSG fails and it has the following characteristics:

• It is stateful, or nondisruptive, because control traffic is not affected.
• It does not disrupt data traffic because the Virtual Ethernet Modules (VEMs) are not affected.

Automatic Failover

When a stable standby Cisco VSG detects that the active Cisco VSG has failed, it initiates a failover and transitions to active. When a failover begins, another failover cannot be started until a stable standby Cisco VSG is available. If a standby Cisco VSG that is not stable detects that an active Cisco VSG has failed, then instead of initiating a failover, it tries to restart the pair.

Manual Failover

Before you can initiate a manual failover from the active to the standby Cisco VSG, the standby Cisco VSG must be stable. To find out if it is, see the “Verifying that a Cisco VSG Pair is Ready for a Failover” section. Once you have verified that the standby Cisco VSG is stable, you can manually initiate a failover. To find out if it is, see the “Manually Switching the Active Cisco VSG to Standby” section. Once a failover process begins, another failover process cannot be started until a stable standby Cisco VSG is available.

BEFORE YOU BEGIN

Before beginning this procedure, you must know or do the following:

• You are logged into the CLI in EXEC mode.
• To activate a change from a primary to a secondary Cisco VSG, you must reload the primary Cisco VSG by doing one of the following:

– Enter the reload command.

– Power the Cisco VSG off and then on from the vSphere Client.

• A change from a standalone to a primary Cisco VSG takes effect immediately.

To change a standalone Cisco VSG to a secondary Cisco VSG, see the “Pairing a Second Cisco VSG with an Active Cisco VSG” section.

SUMMARY STEPS

1. system redundancy role { standalone | primary | secondary }

2. show system redundancy status

3. (Optional) copy running-config startup-config

DETAILED STEPS

EXAMPLES

This example shows how to specify the HA role of a Cisco VSG:

vsg# system redundancy role standalone

vsg#

This example shows how to display the system redundancy status of a standalone Cisco VSG:

vsg# show system redundancy status

Redundancy role

---------------

administrative: standalone

operational: standalone

Redundancy mode

---------------

administrative: HA

operational: None

This supervisor (sup-1)

-----------------------

Redundancy state: Active

Supervisor state: Active

Internal state: Active with no standby

Other supervisor (sup-2)

------------------------

Redundancy state: Not present

vsg#

This example shows how to copy the running configuration to the startup configuration:

vsg# copy running-config startup-config

[########################################] 100%

vsg#

Guidelines and Limitations

Follow these guidelines when doing a failover:

• When you manually initiate a failover, system messages are generated that indicate the presence of two Cisco VSGs and identify which one is becoming active.
• A failover can only be done when both Cisco VSGs are functioning.

Verifying that a Cisco VSG Pair is Ready for a Failover

You can verify that both an active and standby Cisco VSG are in place and operational before proceeding with a failover.

BEFORE YOU BEGIN

Before beginning this procedure, you must know or do the following:

• You are logged into the CLI in EXEC mode.
• If the standby Cisco VSG is not in a stable state (the state must be ha-standby), then a manually initiated failover cannot be done.

PROCEDURE

EXAMPLES

This example shows how to verify that a Cisco VSG pair is ready for a failover:

Redundancy role

---------------

administrative: primary

operational: primary

Redundancy mode

---------------

administrative: HA

operational: None

This supervisor (sup-1)

-----------------------

Redundancy state: Active

Supervisor state: Active

Internal state: Active with no standby

Other supervisor (sup-2)

-----------------------

Redundancy state: Active

Supervisor state: Active

Internal state: Active with no standby

Manually Switching the Active Cisco VSG to Standby

You can manually switch an active Cisco VSG to standby in an HA pair.

BEFORE YOU BEGIN

Before beginning this procedure, you must know or do the following:

• You are logged in to the active Cisco VSG CLI in EXEC mode.
• You have completed the steps in the “Verifying that a Cisco VSG Pair is Ready for a Failover” section and have found the system to be ready for a failover.
• A failover can be performed only when two Cisco VSGs are functioning.
• If the standby Cisco VSG is not in a stable state, then you cannot initiate a manual failover. You will see the following error message:

• Once you enter the system switchover command, you cannot start another failover process on the same system until a stable standby Cisco VSG is available.
• Any unsaved running configuration that was available in the active Cisco VSG is still unsaved in the new active Cisco VSG. You can verify this unsaved running configuration by using the show running-config diff command. Save that configuration, if needed, as you would do in the other Cisco VSG by entering the copy running-config startup-config command.

SUMMARY STEPS

1. system switchover

2. (Optional) show running-config diff

3. configure

4. (Optional) copy running-config startup-config

DETAILED STEPS

EXAMPLES

This example shows how to switch an active Cisco VSG to the standby Cisco VSG and displays the output that appears on the standby Cisco VSG as it becomes the active Cisco VSG:

This example shows how to display the difference between the running and startup configurations:

vsg# show running-config diff

*** Startup-config

--- Running-config

***************

*** 1,38 ****

version 4.0(4)SV1(1)

role feature-group name new

role name testrole

username admin password 5 $1$S7HvKc5G$aguYqHl0dPttBJAhEPwsy1 role network-admin

telnet server enable

ip domain-lookup

This example shows how to copy the running configuration to the startup configuration:

vsg# configure

vsg(config)# copy running-config startup-config

[########################################] 100%

vsg(config)#

BEFORE YOU BEGIN

Before beginning this procedure, you must know or do the following:

• You are logged in to the CLI in configuration mode.

SUMMARY STEPS

1. configure

2. ha-pair id

DETAILED STEPS

EXAMPLES

This example shows how to assign an ID to an HA pair:

vsg# configure

vsg(config)# ha-pair id 10

vsg(config)#

BEFORE YOU BEGIN

Before adding a second Cisco VSG to a standalone system, you must know or do the following:

• You are logged into the CLI in EXEC mode.
• Although primary and secondary Cisco VSGs can reside in the same host, to improve redundancy install them in separate hosts and, if possible, connect them to different upstream switches.
• When installing the second Cisco VSG, assign it with the secondary role.
• Set up the port groups for the dual Cisco VSG VMs with the same parameters in both hosts.
• After the secondary Cisco VSG is paired, the following occurs automatically:

– The secondary Cisco VSG is reloaded and added to the system.

– The secondary Cisco VSG negotiates with the primary Cisco VSG and becomes the standby Cisco VSG.

– The standby Cisco VSG synchronizes its configuration and state with the primary Cisco VSG.

Changing the Standalone Cisco VSG to a Primary Cisco VSG

You can change the role of a Cisco VSG from standalone to primary in a Cisco VSG HA pair.

BEFORE YOU BEGIN

Before beginning this procedure, you must know or do the following:

• You are logged into the CLI in EXEC mode.
• A change from a standalone to a primary takes effect immediately.

SUMMARY STEPS

1. system redundancy role primary

2. show system redundancy status

3. configure

4. (Optional) copy running-config startup-config

DETAILED STEPS

EXAMPLES

This example shows how to change the standalone Cisco VSG to a primary Cisco VSG:

This example shows how to display the current system redundancy status for a Cisco VSG:

This example shows how to copy the running configuration to the startup configuration:

vsg# configure

vsg(config)# copy running-config startup-config

[########################################] 100%

vsg(config)#

Verifying the Change to a Cisco VSG HA Pair

You can verify a change from a single Cisco VSG to a Cisco VSG HA pair.

BEFORE YOU BEGIN

Before beginning this procedure, you must know or do the following:

• You are logged into the CLI in EXEC mode.
• You have already changed the single Cisco VSG role from standalone to primary. See the “Changing the Standalone Cisco VSG to a Primary Cisco VSG” section.

PROCEDURE

EXAMPLES

This example shows how to display the current redundancy status for Cisco VSGs in the system. In this example, the primary and secondary Cisco VSGs are shown following a change from a single Cisco VSG system to a dual Cisco VSG system.

Other supervisor (sup-2)
------------------------
Redundancy state: Standby
Supervisor state: HA standby
Internal state: HA standby

BEFORE YOU BEGIN

Before beginning this procedure, you must know or do the following:

• You are logged into the CLI in EXEC mode.
• You must configure the port groups so that the new primary Cisco VSG cannot communicate with the secondary Cisco VSG or any of the VEMs during setup. Cisco VSGs with a primary or secondary redundancy role have built-in mechanisms for detecting and resolving the conflict between two Cisco VSGs in the active state. In order to avoid these mechanisms during the configuration of the new primary Cisco VSG, you must isolate the new primary Cisco VSG from the secondary Cisco VSG.

Note Equipment Outage—This procedure requires powering down and reinstalling a Cisco VSG. During this time, your system will be operating with a single Cisco VSG.

Step 1 Power off the active Cisco VSG.

The secondary Cisco VSG becomes active.

Step 2 On a vSphere Client, change the port group configuration for the new primary Cisco VSG to prevent communication with the secondary Cisco VSG and the VEMs during setup.

Step 3 Install the new Cisco VSG as the primary, with the same domain ID as the existing Cisco VSG.

Step 4 On the vSphere Client, change the port group configuration for the new primary Cisco VSG to permit communication with the secondary Cisco VSG and the VEMs.

Step 5 Power up the new primary Cisco VSG.

The new primary Cisco VSG starts and automatically synchronizes all configuration data with the secondary, which is currently the active Cisco VSG. Because the existing Cisco VSG is active, the new primary Cisco VSG becomes the standby Cisco VSG and receives all configuration data from the existing active Cisco VSG.

PROCEDURE

EXAMPLES

This example shows how to display the system redundancy status:

This example shows how to display the state and start count of all processes:

vsg#