Table of Contents
Cisco Virtual Security Gateway for Cisco Nexus 1000V Series Switch Release Notes, Release 4.2(1)VSG1(3.1)
This document describes the features, limitations, and caveats for the Cisco Virtual Security Gateway and Cisco Virtual Network Management Center software. Use this document in combination with documents listed in the “Related Documentation” section. The following is the change history for this document.
- Moved the CSCtu 47525 caveat from the open caveat list to the resolved caveat list for Release 4.2(1)VSG1(3.1).
- Added the following resolved caveats for Release 4.2(1)VSG1(3.1a):
The Cisco Virtual Security Gateway (VSG) for the Cisco Nexus 1000V Series switch is a virtual firewall appliance that provides trusted access to virtual data center and cloud environments with dynamic policy-driven operation, mobility-transparent enforcement, and scale-out deployment for dense multitenancy. The Cisco VSG enables a broad set of multitenant workloads that have varied security profiles to share a common compute infrastructure. By associating one or more Virtual Machines into distinct trust zones, the Cisco VSG ensures that access to trust zones is controlled and monitored through established security policies.
- Efficient deployment—Each Cisco VSG can protect Virtual Machines across multiple physical servers, which eliminates the need to deploy one virtual appliance per physical server.
- Performance optimization—By offloading Fast-Path to one or more Cisco Nexus 1000V VEM vPath modules, the Cisco VSG boosts its performance through distributed vPath-based enforcement.
- Operational simplicity—You can insert a Cisco VSG in one-arm mode without creating multiple switches or temporarily migrating VMs to different switches or servers. Zone scaling is based on security profile, not on vNICs that are limited for virtual appliances.
- High availability—For each tenant, you can deploy a Cisco VSG in an active-standby mode to ensure a highly available operating environment with vPath redirecting packets to the standby Cisco VSG when the primary Cisco VSG is unavailable
- Independent capacity planning—You can place a Cisco VSG on a dedicated server, controlled by the security operations team so that maximum compute capacity can be allocated to application workloads. Capacity planning can occur independently across server and security teams, and operational segregation across security, network, and server teams can be maintained.
- Product Architecture
- Trusted Multi-Tenant Access
- Dynamic (Virtualization-Aware) Operation
- Setting Up Cisco VSG and VLAN Usages
The Cisco VSG operates with the Cisco Nexus 1000V distributed virtual switch in the VMWare vSphere hypervisor. The Cisco VSG leverages the virtual network service data path (vPath) that is embedded in the Cisco Nexus 1000V Virtual Ethernet module (VEM). vPath steers traffic, whether external-to-VM or VM-to-VM, to the Cisco VSG of a tenant. A split-processing model is applied where initial packet processing occurs in the Cisco VSG for policy evaluation and enforcement. After the policy decision is made, the Cisco VSG off-loads policy enforcement of remaining packets to vPath.
You can transparently insert a Cisco VSG into the VMware vSphere environment where the Cisco Nexus 1000V distributed virtual switch is deployed. Upon insertion, one or more instances of the Cisco VSG is deployed on a per-tenant basis, which allows a highly scaled-out deployment across many tenants. Because tenants are isolated from each other, no traffic can cross tenant boundaries. Depending on the use case, you can deploy Cisco VSG at the tenant level, at the virtual data center (vDC) level, as well as at the vApp level.
As VMs are instantiated for a given tenant, association to security profiles and zone membership occurs immediately through binding with the Cisco Nexus 1000V port profile. Upon instantation, each VM is placed into a logical trust zone. Security profiles contain context-aware rule sets that specify access policies for traffic that enters and exits each zone. With the VM and network contexts, you can leverage custom attributes to define zones directly through security profiles. The profiles are applied to zone-to-zone traffic and external-to-zone/zone-to-external traffic. This enforcement occurs within a VLAN because a VLAN often identifies a tenant boundary.
The Cisco VSGs evaluate access control rules and then offloads enforcement to the Cisco Nexus 1000V VEM vPath module for performance optimization. Access is permitted or denied based on policies. The Cisco VSG provides policy-based traffic monitoring capability and generates access logs.
A virtualization environment is dynamic, where frequent additions, deletions, and changes occur across tenants and especially across VMs. Live migration of VMs can occur due to manual or programmatic vMotion events.
A Cisco VSG operates with the Cisco Nexus 1000V (and vPath), which supports a dynamic VM environment. Typically, a tenant is created with the Cisco VSG (standalone or active-standby pair) and on the Cisco Virtual Network Management Center (VNMC). Associated security profiles are defined that include trust zone definitions and access control rules.
Each security profile is bound to a Cisco Nexus 1000V port profile (authored on the Cisco Nexus 1000V Virtual Supervisor Module and published to the VMWare Virtual Center). When a new VM is instantiated, you can assign appropriate port profiles to the virtual Ethernet port of the VM. Because the port profile uniquely refers to a security profile and VM zone membership, security controls are immediately applied. A VM can be repurposed by assigning a different port profile or security profile.
As vMotion events occur, VMs move across physical servers. The Cisco Nexus 1000V ensures that port profile policies and associated security profiles follow the VMs. Security enforcement and monitoring remain transparent to vMotion events.
A Cisco VSG is set up in an overlay fashion so that VMs can reach a Cisco VSG irrespective of its location. The vPath component in the Cisco Nexus 1000V VEM intercepts the packets from the VM and sends them to the Cisco VSG for further processing.
- The Management VLAN connects management platforms such as the VMware vCenter, Cisco Virtual Network Management Center, Cisco Nexus 1000V VSM, and the managed Cisco VSGs.
- The Service VLAN provides communications between the Cisco Nexus 1000V VEM and Cisco VSGs. All Cisco VSGs are part of the Service VLAN. In layer 2 mode the VEM uses this VLAN for interaction with Cisco VSGs.
- The HA VLAN identifies the active and standby relationship.
You can allocate one or more VM Data VLAN(s) for VM-to-VM communications. In a multitenant environment, the Management VLAN is shared among all tenants. The Service VLAN, HA VLAN, and the VM Data VLAN are allocated on a per-tenant basis. When VLAN resources are scarce, you can use a single VLAN for Service and HA functions.
Locator/ID Separation Protocol (LISP) allows mobility of VMs across Layer 3 boundaries. Each VEM acts as a single Ingress Tunnel Router (ITR) and Egress Tunnel Router (ETR) and must have a Locator IP address configured on the VSM. The VEM and the VSM do not need to run the routing protocols.
Without LISP, a VM that requires IP connectivity can only vMotion to a VEM in the same Layer 2 broadcast domain. Moving to a VEM that does not have the same Layer 2 access is not prevented by VC but results in loss of IP connectivity. LISP removes this restriction. A VM can vMotion anywhere so long as the map server/resolver and other LISP infrastructure remain accessible at Layer 3.
- Support for Layer 3 mode—Release 4.2(1)VSG1(3.1) supports the Cisco VSG deployment in the Layer 3 mode. The Cisco VSG and the VEM are no longer required to be in the same Layer 2 network. The VEM and the Cisco VSG communicate with each other through a special virtual network interface called the Virtual Kernel NIC (vmknic). This vnmknic is created by an administrator. For more information, see the Cisco Virtual Security Gateway for Nexus 1000V Series Switch Configuration Guide, Release 4.2(1)VSG1(3.1) .
- VXLAN— Cisco Nexus 1000V release 4.2(1)SV1(5.1) supports Virtual Extensible Local Area Network (VXLAN) feature that defines a 24-bit LAN segment identifier to provide segmentation at cloud scale (for more information, see the C isco Nexus 1000v Interface Configuration Guide, Release 4.2(1)SV1(5.1). With Release 4.2(1)VSG1(3.1), the Cisco VSG supports protection for VM backed by VXLAN.
- Jumbo frames cannot be configured for the Cisco VSG management interface.
- Vmotion of the Cisco VSG is validated for host upgrades only and not for DRS purposes.
- Enabling firewall protection on a router virtual machine may cause problems for policies based on VM attributes; firewall protection should be enabled only for end-point Virtual Machines.
- The maximum numbers for Cisco VSG objects are as follows:
- OVA Installation Behavior
Workaround: Ensure that all three network interfaces in the Cisco VSG port profile are set to VM Network (port profile from vSwitch) during OVA installation. Once the virtual machine is created, the port profile for these three interfaces should be changed according to the Cisco Virtual Security Gateway, Release 4.2(1)VSG1(2) and Cisco Virtual Network Management Center, Release 1.2 Installation and Upgrade Guide .
For better performance, increase the MTU of all links between the VEM and the Cisco VSG by 74 bytes to account for packet encapsulation which occurs for communication between vPath and the Cisco VSG. For example, if the MTU values of the client and server VMs and uplink are all 1500 bytes, set the uplink MTU to 1574 bytes.
– When the VEM communicates with the Cisco VSG in the Layer 3 mode, an additional header with 94 bytes is added to the original packet. The VEM does not support fragmentation in Layer 3 mode and the ports/network-elements (which carry vPath encapsulated packets) must be configured in such a way that the vPath overhead is accommodated. For example, if MTU values of client and server VMs and uplink are all 1500 bytes, set the uplink MTU to 1594 bytes.
– If the jumbo frames are enabled in the network, make sure the MTU of the client and server VMs are 94 bytes smaller than the uplink. For example, if the uplink MTU is 9000 bytes, set the MTU of the client and server VMs to 8906 bytes.
– When encapsulated traffic that is destined to a Cisco VSG is connected to a different subnet other than the vmknic subnet, the VEM does not use the VMware host routing table. Instead, the vmknic initiates an ARP for the remote Cisco VSG IP addresses. You must configure the upstream router to respond by using the proxy ARP feature.
Configuring a rule with a reset action for the non-TCP/UDP protocol will result in dropped traffic. However, the syslog generated for this traffic shows that the action performed for the traffic is reset as shown below:2011 June 16 07:19:56 VSG-Fw %POLICY_ENGINE-6-POLICY_LOOKUP_EVENT: policy=ps-web@root/Tenant-A rule=pol-B/udp-rule@root/Tenant-A action=Reset direction=ingress src.net.ip-address=172.31.2.107 dst.net.ip-address=172.31.2.101 net.protocol=1 net.ethertype=800 src.vm.name=sg-centos-vk-7 src.vm.host-name
=10.193.75.91 src.vm.os-fullname="red hat enterprise linux 5 (64-bit)" dst.vm.cluster-name
="sg1-dc1-clu1 ankaa tenth" src.vm.cluster-name="sg1-dc1-clu1 ankaa tenth" dst.vm.portprofile-name=access-3770-tenant-a src.vm.portprofile-name=access-3770-tenant-a dst.zone.name=centos-zone@root/Tenant-A src.zone.name=centos-zone@root/Tenant-A src.vm.os-hostname=(null) src.vm.res-pool=(null)
The CLI session for the Cisco VSG version 1.3x that is newly deployed will time out after a period of five minutes of an inactivity. The CLI session time out does not work on Cisco VSG that has been upgraded from version 1.0x.
- On the Cisco VSG that is upgraded from version 1.0x, the show running-config will consist only of the following items:
As a workaround, when upgrade is done from 1.0x to 1.3 version of VSG, “exec-timeout 5” can be configured under “line console” and “line vty” command modes to enable a five minutes CLI session inactivity timeout.
After upgrading the Cisco VSG from Release 4.2(1)VSG1(2) to Release 4.2(1)VSG1(3.1) using the install all command , any changes to the VSG configuration that are done at the Cisco VNMC do not get applied to the Cisco VSG.
After upgrading the Cisco VSG from Release 4.2(1)VSG1(2) to Release 4.2(1)VSG1(3.1a) using the install all command , any changes to the VSG configuration that are done at the Cisco VNMC do not get applied to the Cisco VSG.
- Cisco Virtual Security Gateway for Nexus 1000V Series Switch Release Notes, Release 4.2(1)VSG1(3.1)
- Cisco Virtual Security Gateway, Release 4.2(1)VSG1(3.1) and Cisco Virtual Network Management Center, Release 1.3 Installation and Upgrade Guide
- Cisco Virtual Security Gateway for Nexus 1000V Series Switch License Configuration Guide, Release 4.2(1)VSG1(3.1)
- Cisco Virtual Security Gateway for Nexus 1000V Series Switch Configuration Guide, Release 4.2(1)VSG1(3.1)
- Cisco Virtual Security Gateway for Nexus 1000V Series Switch Command Reference, Release 4.2(1)VSG1(3.1)
- Cisco Virtual Security Gateway for Nexus 1000V Series Switch Troubleshooting Guide, Release 4.2(1)VSG1(3.1)
For information on obtaining documentation, submitting a service request, and gathering additional information, see What’s New in Cisco Product Documentation at: http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html .
Subscribe to What’s New in Cisco Product Documentation , which lists all new and revised Cisco technical documentation, as an RSS feed and deliver content directly to your desktop using a reader application. The RSS feeds are a free service.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)