...
Since asa1kv works with n1kv and this is available only for Vmware HV, guest networks with asa1kv will only be supported on Vmware only.
VNMC setup (external to CS)
VNMC appliance needs to be setup externally and then registered with CS using admin API.
ASA setup (external to CS)
ASA1000v appliance is needs ot be setup externally and then registered with CS using admin API. Typically admin will create a pool of ASA1000v appliances and register them with CS.
Following inputs to be provided for setting up ASA:
- ESX host
- Standalone/HA mode
- Port profiles for mgmt. and ha n/w interfaces (pre-created on n1kv switch, can be same or different)
- Port profiles for inside/outside n/w interfaces (pre-created on n1kv switch, updated appropriately while implementing guest n/w)
- Mgmt. IP for ASA, specify g/w such that VNMC IP is reachable
- Admin password
- VNMC IP and other parameters
Inside port profile configuration on Nexus1000v
- in_port_profile
port-profile type vethernet %asa-in-port-profile%
vmware port-group
switchport mode access
no shutdown
state enabled
Outside port profile configuration on Nexus1000v
- out_port_profile
port-profile type vethernet %asa-out-port-profile%
vmware port-group
switchport mode access
switchport access vlan %vlanid-of-outside%
no shutdown
state enabled
After the ASA instance is powered on the VNMC needs to be registered from ASA console
- ASA1000V(config)# vnmc policy-agent
- ASA1000V(config-vnmc-policy-agent)# registration host vnmc_ip_address
- ASA1000V(config-vnmc-policy-agent)# shared-secret key where key is the shared secret for authentication of the ASA 1000V connection to the Cisco VNMC
ASA limitation
- ASA inside and outside interfaces cannot act as trunk interfaces to support multiple VLANs. What this mean for CS is that multiple guest networks cannot be trunked to the inside interface. So in order to support VPC, some alternate needs to be thought out for deploying ASA. The same applies to outside interface as well implying that a single public subnet can be used with ASA deployments. See http://goo.gl/rZPFx
- ASA outside interface ip cannot be used in any NAT rule. This means that source NAT ip allocated to a guest network in CS cannot be used as ASA outside ip.
Guest network implement() logic
...
VNMC lifecycle APIs
- addCiscoVNMCResource
- Request parameters
- physical n/w id (required) - id of the physical n/w to which VNMC is associated with; validation - check that physical network id is valid
- mgmt. ip (required) - IP address for connecting to VNMC; check ip address format is valid
- username (required) - Username for connecting to VNMC; no validation
- password (required) - Password for the above username; no validation
- Response
- resource id
- physical n/w id
- provider name
- resource name
- deleteCiscoVNMCResource
- Request parameters
- resource id (required) - unique id of VNMC; validation - check that resource id is valid. Deletion would fail if there are one or more ASA appliances attached to the physical network to which this VNMC belongs.
- Response
- boolean (success/failure)
- listCiscoVNMCResources
- Request parameters
- resource id (optional) - unique id of VNMC
- physical n/w id (optional) - id of physical n/w to which VNMC is associated with
- Response
- resource id
- physical n/w id
- provider name
- resource name
ASA lifecycle 1000v APIs
Typically lifecycle of ASA is tied to the associated guest network. But since ASA setup requires some license check, CLI configuration configurations it is not possible to spin it up as part of guest network creation. One option is to pre-create a pool of ASA appliancesThe list of ASA1000v appliances needs to be provisioned into CloudStack using admin APIs. During network creation available ASA instance is assigned to it from the pool list and released when the network is gets destroyed. The pool will be created using lifecycle APIs
- addCiscoASA1000vResource
- Request parameters
- physical n/w id (required) - id of the physical n/w to which ASA1000v is associated with; validation - check that physical network id is valid
- mgmt. ip of ASA (required) - IP address for connecting to ASA; check ip address format is valid
- cluster id (required) - CS cluster id (Vmware cluster only) this appliance is tied to; validation - check that cluster id is valid and Vmware cluster
- inside port profile name (required) - name of Nexus port profile associated with ASA inside interface; no validation
- Response
- resource id
- physical n/w id
- mgmt. ip
- inside port profile name
- guest n/w id
- deleteCiscoASA1000vResource
- Request parameters
- resource id (required) - unique id of ASA; validation - check that id is valid. Deletion would fail if the appliance is associated with a guest network. Association will be removed when the network gets destroyed.
- Response
- boolean (success/failure)
- listCiscoASA1000vResources
- Request parameters
- resource id (optional) - unique id of ASA1000v
- physical n/w id (optional) - id of physical n/w to which ASA1000v appliance is associated with
- Response
- resource id
- physical n/w id
- mgmt. ip
- inside port profile name
- guest n/w id
As part of response, if the ASA is associated with a guest network, the uuid for the same is also returned. From this the cloud operator can find out if the appliance is available or not.
DB changes
- table for storing VNMC details.
_CREATE TABLE `cloud`.`external_cisco_vnmc_devices` (
`id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT 'id',
`uuid` varchar(255) UNIQUE,
`physical_network_id` bigint unsigned NOT NULL COMMENT 'id of the physical network in to which cisco vnmc device is added',
`provider_name` varchar(255) NOT NULL COMMENT 'Service Provider name corresponding to this cisco vnmc device',
`device_name` varchar(255) NOT NULL COMMENT 'name of the cisco vnmc device',
`host_id` bigint unsigned NOT NULL COMMENT 'host id coresponding to the external cisco vnmc device',
PRIMARY KEY (`id`),
CONSTRAINT `fk_external_cisco_vnmc_devices__host_id` FOREIGN KEY (`host_id`) REFERENCES `host`(`id`) ON DELETE CASCADE,
CONSTRAINT `fk_external_cisco_vnmc_devices__physical_network_id` FOREIGN KEY (`physical_network_id`) REFERENCES `physical_network`(`id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;_
...
A new provider needs to be added for Cisco VNMC (similar to SRX). This will provide services for firewall, source nat, port forwarding and static nat. Rest of the services will be provided by VR.
There will be APIs to manage lifecycle of VNMC appliances (add, delete, list). These also needs to be plugged to the UI. Also there will be APIs to manage lifecycle of ASA appliances.
Open items (for future support if required)
VSG
The VSG can be used to provide security group isolation.
There is an alternate feature proposal where SG isolation for Vmware will be done using PVLANs. Needs to be re-visited if there is no need for VSG integration.
VXLAN support
VXLAN based network isolation.
Links
http://www.cisco.com/en/US/docs/security/asa/quick_start/asa1000V/setup_vnmc.html