This chapter contains the following sections:
Cisco Nexus 1000V
for KVM and OpenStack
Cisco Nexus 1000V for KVM consists of two main components:
Each of these
components is tightly integrated with the OpenStack environment:
Module (VEM)—A software component that is deployed on each kernel-based virtual
machine (VM) host. Each VM on the host is connected to the VEM through virtual
Ethernet (vEth) ports.
Module (VSM)—The Management component that controls multiple VEMs and helps in
the definition of VM-focused network policies. It is deployed either as a
virtual appliance on any KVM host or on the Cisco Cloud Services Platform
Using OpenStack, you
create VMs, networks, and subnets on the
Cisco Nexus 1000V for KVM, by defining components such as the
The VEM is a
hypervisor-resident component and is tightly integrated with the KVM
The VSM is
integrated with OpenStack using the OpenStack Neutron Plug-in.
Neutron API has been extended to include two additional user-defined resources:
profiles are logical groupings of network segments.
profiles group port policy information, including security.
- Network segments, such as
VLANs, VLAN trunks, and VXLANs
- IP address pools (subnets)
Cisco Nexus 1000V for KVM VSM, you create port profiles (called
policy profiles in OpenStack), which define the port policy information,
including security settings.
When a VM is deployed,
a port profile is dynamically created on the
Cisco Nexus 1000V for KVM for each unique combination of policy
port profile and network segment. All other VMs deployed with the same policy
to this network reuse this dynamic port profile.
You must consistently use
OpenStack for all VM network and subnet configuration. If you use
OpenStack and the VSM to configure VM networks and subnets, the OpenStack and
the VSM configurations can become out-of-sync and result in faulty or
inoperable network deployments.
Authentication, Authorization, and Accounting
Authentication, Authorization, and Accounting (AAA) is an architectural framework for configuring a set of three independent, consistent, and modular security functions
Authentication—Provides the method of identifying users, including login and password dialog, challenge and response, messaging support, and, depending on the security protocol that you select, encryption. Authentication is the way a user is identified prior to being allowed access to the network and network services. You configure AAA authentication by defining a named list of authentication methods and then applying that list to various interfaces.
Authorization—Provides the method for remote access control, including one-time authorization or authorization for each service, per-user account list and profile, user group support, and support of IP, IPX, ARA, and Telnet. Remote security servers, such as RADIUS and TACACS+, authorize users for specific rights by associating attribute-value (AV) pairs, which define those rights, with the appropriate user. AAA authorization works by assembling a set of attributes that describe what the user is authorized to perform. These attributes are compared with the information contained in a database for a given user, and the result is returned to AAA to determine the user’s actual capabilities and restrictions.
Accounting—Provides the method for collecting and sending security server information used for billing, auditing, and reporting, such as user identities, start and stop times, executed commands (such as PPP), number of packets, and number of bytes. Accounting enables you to track the services that users are accessing, as well as the amount of network resources that they are consuming.
You can configure authentication outside of AAA. However, you must configure AAA if you want to use RADIUS or TACACS+, or if you want to configure a backup authentication method.
RADIUS Security Protocol
AAA establishes communication between your network access server and your RADIUS security server. RADIUS is a distributed client/server system implemented through AAA that secures networks against unauthorized access. In the Cisco implementation, RADIUS clients run on Cisco routers and send authentication requests to a central RADIUS server that contains all user authentication and network service access information.
TACACS+ Security Protocol
AAA establishes communication between your network access server and your TACACS+ security server.
TACACS+ is a security application implemented through AAA that provides a centralized validation of users who are attempting to gain access to a router or network access server. TACACS+ services are maintained in a database on a TACACS+ daemon that usually runs on a UNIX or Windows NT workstation. TACACS+ provides separate and modular authentication, authorization, and accounting facilities.
You can use the Secure Shell (SSH) server to enable an SSH client to make a secure, encrypted connection to a device. SSH uses strong encryption for authentication. The SSH server can operate with publicly and commercially available SSH clients.
The SSH client works with publicly and commercially available SSH servers.
You can use the Telnet protocol to set up TCP/IP connections to a host. Telnet allows a person at one site to establish a TCP connection to a login server at another site and then passes the keystrokes from one device to the other. Telnet can accept either an IP address or a domain name as the remote device address.
IP ACLs are ordered
sets of rules that you can use to filter traffic based on IPv4 information in
the Layer 3 header of packets. Each rule specifies a set of conditions that a
packet must satisfy to match the rule. When the Cisco NX-OS software determines
that an IP ACL applies to a packet, it tests the packet against the conditions
of all rules. The first match determines whether a packet is permitted or
denied, or if there is no match, the Cisco NX-OS software applies the
applicable default rule. The Cisco NX-OS software continues processing packets
that are permitted and drops packets that are denied.
ACLs are ACLs that filter traffic using the information in the Layer 2 header
of each packet. Each rule specifies a set of conditions that a packet must
satisfy to match the rule. When the Cisco NX-OS software determines that a MAC
ACL applies to a packet, it tests the packet against the conditions of all
rules. The first match determines whether a packet is permitted or denied, or
if there is no match, the Cisco NX-OS software applies the applicable default
rule. The Cisco NX-OS software continues processing packets that are permitted
and drops packets that are denied.
Unknown unicast packet
flooding (UUFB) limits unknown unicast flooding in the forwarding path to
prevent the security risk of unwanted traffic reaching the Virtual Machines
(VMs). UUFB prevents packets received on both vEthernet and Ethernet interfaces
destined to unknown unicast addresses from flooding the VLAN. When UUFB is
applied, Virtual Ethernet Modules (VEMs) drop unknown unicast packets received
on uplink ports, while unknown unicast packets received on vEthernet interfaces
are sent out only on uplink ports.