1) VPC
Vpc creation
Amazon
createVpc
- CidrBlock - the CIDR block you want the VPC to cover
- instanceTenancy - The supported tenancy of instances launched into the VPC.
Unlike cloudStack, Amazon has separate command for setting up the networkDomain for the VPC - CreateDhcpOptions. Following parameters can be set as a part of it:
- domain-name - in cloudStack, set in createVPC command
- domain-name-servers - in cloudStack, taken from the DataCenter object as all resources in the datacenter share the same DNS (networks, hosts, etc)
- ntp-servers - not supported by cloudStask
- netbios-name-servers - not supported by cloudStack
- netbios-node-type - not supported by cloudStack
cloudStack
createVpc
- zoneId (required) - zone VPC will belong to
- name (required)
- cidr (required) - the CIDR block you want the VPC to cover
- vpcOffering (required) - vpc offering (some important parameters are defined in this offering, such as serviceOfferingId for the VR and number of services this VPC is limited to). There is a defualt vpc offering in the system that can be used.
- displayText
- networkDomain - network domain inside the VPC. All guest networks inside the VPC are going to be a part of this domain
- account/domainId (If not specified, will be taken from )
describeVPC/deleteVpc are pretty much the same.
2) Gateway
VPN gateway:
Amazon:
createVpnGateway - creates the vpn gateway
- The type of VPN connection this virtual private gateway supports.
attachVpnGateway - attaches vpn gateway to the VPC
- gatewayId (required)
- vpcId (required)
CloudStack:
createVpnGateway - combines Amazon createVpnGateway + attachVpnGateway. The gateway is created for the particular VPC from the very beginning and can't be detached.
Private gateway:
Amazon doesn't have equivalent for this command
3) Static route
The main difference - in Amazon, each network in VPC has its own route table; in cloudStack route table is shared across networks, and can be applied either to all of them or none.
Amazon:
createRouteTable - creates route table for VPC.
AssociateRouteTable - associates route table to network
- vpcId (required)
- subnetId (required)
createRoute
- routeTableId (required)
- gatewayId (required)
- cidr - dest CIDR
- InstanceId
- NetworkInterfaceId
cloudStack:
createStaticRoute
- gatewayId (required)
- cidr (required) - dest cidr
Once static route is created, it's available for all networks in the VPC.
In order to switch to Amazon model in the future release, we should:
- add 4 new apis - createRouteTable/deleteRouteTable, AssociateRouteTable/AssociateRouteTable
- To upgrade existing setups, 1) create static route table per VPC 2) Associate all VPC static route rules with this table 3) Add associations from the table to all networks in the VPC
If customer wants to remove some associations, he can do it with AssociateRouteTable after the ugprade is done.
4) Network ACL (Applicable only to pre-4.2 releases; works amazon way since 4.2)
Amazon:
createNetworkACL - creates network ACL for VPC and adds default ingress (deny all) and egress network acl entry (deny all) to it. NetworkACL acts like a container for networkACLEntries - actual firewall rules.
createNetworkACLEntry - creates new network ACL entry in the network ACL
- networkACLId (required)
- ruleNumber (required)
- protocol (required)
- ruleAction (required, allow/deny)
- egress
- icmpCode
- icmpType
- startPort
- endPort
replaceNetworkACLEntry - replaces network ACL entry with the given priority
- networkACLId (required)
- ruleNumber (required)
- protocol (required)
- ruleAction (required, allow/deny)
- egress
- icmpCode
- icmpType
- startPort
- endPort
By default, each new network gets associated with default networkACL. To change network->ACL association, following API is used:
replaceNetworkACLAssociation
CloudStack:
In cloudStack each networkACL entry is tight to the network.
createNetworkACL - equivalent to addNetworkACLEntry; ruleAction and rule number are missing. In cloudStack networkACL rule always has action=allow, and we check for conflicts before allowing the rule creation, so the "rule number" is not applicable with the current implementation.
- networkId (required)
- protocol (required)
- startPort
- endPort
- cidrList
- icmpType
- icmpCode
- trafficType (Ingress/Egress)
In order to support more Amazon like model in the future, following needs to be done:
- add ruleAction/ruleNumber to createNetworkACL api
- implement replaceNetworkACL API
- For existing customers, for all network ACL db entries, add "ruleAction = allow" and "ruleNumber". Rule number should be calculated based on rule DB id.
- introduce networkACLList concept - list of network ACL rules that can be associated with a particular network. CreateNetworkACL will continue having networkId parameter (We'll just make it optional to provide backwards compatibility). Plug new parameterwill be added - networkACLListId (also optional).If no networkACLListId is specified, the networkACL will be added to the default container (list) of the network.
- New api replaceNetworkACLList will be used to change network->ACL association
5. Ability to extend VPC network ip ranges
As in CS isolated networks we have no support for extending ip ranges, we can't do it in the VPC networks as Amazon does. So no analogs for following EC2 VPC commands:
- AssignPrivateIpAddress
- UnassignPrivateIpAddress
6. Ability to add/remove existing networks to VPC
In order to be used in VPC, network has to be created fresh in the VPC. We can't attach/detach existing networks to/from VPC the way amazon lets you:
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-AttachNetworkInterface.html
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-DetachNetworkInterface.html