Tag Archive for: Networking (End User)

Securing CloudStack 4.11 with HTTPS/TLS

Apache CloudStack is generally considered secure out of the box, however it does have the capability of protecting both system VM traffic as well as management traffic with TLS certificates. Prior to version 4.11 CloudStack used Tomcat as the web server and servlet container. With 4.11 this has been changed to embedded Jetty web server and servlet container that makes CloudStack more secure and independent of distribution provided Tomcat version which could be prone to security issues. This changes the management server’s TLS configuration.

In this blog post we’ll go through how to implement native TLS to protect both the system VMs – CPVM and SSVM – as well as the management server with public TLS certificates.

Please note since SSL is now being deprecated we now refer to the replacement – TLS – throughout this post.

Overview

The TLS configuration in CloudStack provides different functionality depending on the system role:

  • TLS protecting the management server is a Jetty configuration which protects the main web GUI and API endpoint only. The configuration of this is handled in the underlying embedded Jetty configuration files.
  • System VMs:
    • The Console Proxy VM TLS configuration provides secure HTTPS connection between the main console screen (your browser) and the CPVM itself.
    • The Secondary Storage VM SSL configuration provides a secure HTTPS connection for uploads and downloads of templates / ISOs / volumes to secondary storage as well as between zones.
    • System VM SSL configuration is carried out through global settings as well as the CloudStack GUI.

System VM HTTPS configuration

Global settings

The following global setting are required configured to allow system VM TLS configuration:

Global settingValue
consoleproxy.url.domaindomain used for CPVM (see below)
consoleproxy.sslEnabledSwitches SSL configuration of the CPVM on / off
Values true | false
secstorage.ssl.cert.domaindomain used for SSVM (see below)
secstorage.encrypt.copySwitches SSL configuration of the SSVM on / off
Values true | false

The URL configurations can take three formats – and these also determine what kind of TLS certificate is required.

  • Blank: if left blank / unconfigured the URLs used for CPVM and SSVM will simply be passed as the actual public IP addresses of the system VMs.
  • Static URL: e.g. console.mydomain.com or ssvm.mydomain.com. In these cases CloudStack rely on external URL load balancing / redirection and/or DNS resolution of the URL to the IP address of the CPVM or SSVM. This can be achieved in a number of different ways through load balancing appliances or scripted DNS updates.
    This configuration relies on:

    • The same URL used for both CPVM and SSVM, or
    • a multi-domain certificate provided to cover both URLs if different ones are used for CPVM and SSVM.
  • Dynamic URL: e.g. *.mydomain.com. In this case CloudStack will redirect the connections to the CPVM / SSVM to the URL “a-b-c-d.mydomain.com” where a/b/c/d represent the IP address, i.e. a real world URL would be 192-168-34-145.mydomain.com.
    This relies on two things:

    • DNS name resolution configured for the full public system VM IP range, such that all combinations of “a-b-c-d.mydomain.com” can be resolved. Please note in CloudStack version 4.11 the public IP range used purely by system VMs can be limited by reserving a subrange of public IP addresses just for system use.
    • An TLS wildcard certificate covering the full “mydomain.com” domain name.

Configuration process – GUI

The first step is to configure the four global settings above, then restart the CloudStack management service to make these settings live.

Next upload the TLS root certificate chain, the actual TLS certificate as well as the PKCS8 formatted private key using the “TLS certificate” button in the zone configuration. In this example we use a wildcard certificate.

Configuration process – API / CloudMonkey

The uploadCustomCertificate API call can be used to upload the TLS certificates. Please note the upload process does require at least two API calls – more depending on how many intermediary certificates are used. If you use CloudMonkey the certificates can be uploaded in cleartext – otherwise they have to be URLencoded when passed as part of a normal HTTP GET API call.

  • In the first API call the combined root and intermediary certificates are uploaded. In this API call the following parameters are passed – note we don’t pass the private key:
    • id=1
    • name: Give the certificate a name.
    • certificate: the root / intermediary certificate in cleartext, with all formatting / line breaks in place. In the example below we pass a chain of root and intermediary certificates.
    • domainsuffix: provide the suffix used, e.g. *.mydomain.com.
  • The second API call in our example uploads the site certificate. In this case we do not give the certificate a name (CloudStack automatically names this):
    • id=2
    • certificate: the issued site certificate, again in cleartext.
    • privatekey: the private key, same cleartext format as certificate.
    • domainsuffix: as above.
cloudmonkey upload customcertificate id=1 name=RootCertificate certificate='-----BEGIN CERTIFICATE-----
MIIE0DCCsdf8HqjeIHgkqhkiG9w0BAQsFADCBgzELMAk
...8V3Idv7kaWKK3245lsoynJuh87/BKONvPi8BDAB
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEfTCCA2WgAwIBAgIDG+cVMA8djwj1ldggKd9d9s
.....mw4TRfZHcYQFHfjDCmrw==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEADCCAuigAwIBAgIBADANBgkqhkiG9w0BAQUFA
.....csbkqWletNw+vHX/bvZ8=
-----END CERTIFICATE-----'
domainsuffix='*.mydomain.com'

cloudmonkey upload customcertificate id=2 certificate='-----BEGIN CERTIFICATE-----
MIIGrjCCBZagAwIBAgIJAJ....
...xKjPTkOLfwMVWXc8Ul25t7lkyi0+a9jZxFAuDXFRgkQnbw==
-----END CERTIFICATE-----'
privatekey='-----BEGIN PRIVATE KEY-----
MIIEvEbidvik1gkqhkiG9w0BAQEFAASCBK
.....rEF5Qyuyserre87d234jj/Uddf
-----END PRIVATE KEY-----'
domainsuffix='*.mydomain.com'

 

System VM restart

Once uploaded the CPVM and SSVM will automatically restart to pick up the new certificates. If the system VMs do not restart cleanly they can be destroyed and will come back online with the TLS configuration in place.

Testing the TLS protected system VMs

To test the Console Proxy VM simply open the console to any user VM or system VM. The popup browser window will at this point show up as a non-secure website. The reason for this is the actual console session is provided in an inline frame – and the popup page itself is presented from the unsecured management servers. If you however look at the page source for the page the HTTPS link which presents the inline frame shows up in the expected format:

Once the management server is also TLS protected the CPVM console popup window will also show as secured:

The SSVM will also now utilise the HTTPS links for all browser based uploads as well as downloads from secondary storage:

Securing the CloudStack management server GUI with HTTPS

Protecting the management servers requires creating a PCKS12 certificate and updating the underlying Jetty configuration to take this into account. This is described in http://wiki.eclipse.org/Jetty/Howto/Configure_SSL#Configuring_Jetty

First of all combine the TLS private key file, certificate and root certificate chain into one file (in the specified order), then convert this into PKCS12 format and write it to a new CloudStack keystore. Enter a new keystore password when prompted:

# cat myprivatekey.key mycertificate.crt gd_bundle-g2-g1.crt > mycombinedcert.crt

# openssl pkcs12 -in mycombinedcert.crt -export -out mycombinedcert.pkcs12
Enter Export Password: ************
Verifying - Enter Export Password:************

# keytool -importkeystore -srckeystore mycombinedcert.pkcs12 -srcstoretype PKCS12 -destkeystore /etc/cloudstack/management/keystore.pkcs12 -deststoretype pkcs12
Importing keystore mycombinedcert.pkcs12 to /etc/cloudstack/management/keystore.pkcs12...
Enter destination keystore password:************
Re-enter new password:************
Enter source keystore password:************
Entry for alias 1 successfully imported.
Import command completed:  1 entries successfully imported, 0 entries failed or cancelled

 

Next edit /etc/cloudstack/management/server.properties and update the following:

https.enable=true
https.keystore=/etc/cloudstack/management/keystore.pkcs12
https.keystore.password=<enter the same password as used for conversion>

 

In addition automatic redirect from HTTP/port 8080 to HTTPS/port 8443 can also be configured in /usr/share/cloudstack-management/webapp/WEB-INF/web.xml. Add the following section before the section around line 22:

  <security-constraint>
    <web-resource-collection>
      <web-resource-name>Everything</web-resource-name>;
      <url-pattern>*</url-pattern>
    </web-resource-collection>
    <user-data-constraint>
      <transport-guarantee>CONFIDENTIAL></transport-guarantee>
    </user-data-constraint>
  </security-constraint>

 

Lastly restart the management service:

# systemctl restart cloudstack-management

Conclusion

The TLS capabilities of CloudStack has been extended over the last few releases – and we hope this article helps to explain the new global settings and configuration procedure.

About The Author

Dag Sonstebo is  a Cloud Architect at ShapeBlue, The Cloud Specialists. Dag spends most of his time designing, implementing and automating IaaS solutions based on Apache CloudStack.



/by 
Layer 2 Networks in CloudStack
Layer 2 (also known as the Data Link Layer) is the second in the seven-layer OSI reference model for network protocol design, and is equivalent to the link layer (the lowest layer) in the TCP/IP network model. Layer 2 is the network layer used to transfer data between adjacent network nodes in a wide area network, or between nodes on the same local area network.


We have recently introduced a new Layer 2 network offering in CloudStack. This enables all network services to be provided from network equipment external to CloudStack. As a result, the Virtual Router is not required, and VMs deployed to the network will get their IP addresses and other network services from these external appliances. This new network type is acting like a shared network, but it leaves all network services to be managed outside of CloudStack.


This article describes how to set up a Layer 2 network in the upcoming 4.11 CloudStack release.


The network offering


Following CloudStack’s architecture, there must first be a specific network offering enabled in order to deploy a L2 network. Such an offering can be created by selecting ‘Guest Type: L2’ (it also supports the ability to specify VLAN). When selected, the user will need to specify a VLAN id when creating the network, and the network will be implemented using a dynamically assigned VLAN. Otherwise, the administrator will have to manage this externally from CloudStack, by appliance or other VM. Once created, the network offering needs to be enabled in order to implement the L2 network.


 




The network


CloudStack Administrators are able to create Layer 2 networks simply by clicking ‘Network’, where a new button is introduced: ‘Add L2 Guest Network’. By clicking this button, a CloudStack administrator will have the ability to fill in the network specifics to implement it. Please note, that where the network offering requires a VLAN, CloudStack administrators must specify a particular VLAN id. When all details are complete the network can be saved by clicking ‘OK’. At this stage our Layer 2 network is ready to use and we can start deploying VMs in it.


Add network button:




Add network pop-up:




How it looks


As soon as we get our VMs into ‘Running’ state, we can see on the NICs section that there are no network details available (such as IP Address, gateway, etc.), but the VM is reachable and available through the Console Proxy VM. Since we don’t have any of these services, our network is running without a Virtual Router, which makes the deployment fast.




On the physical network side, the cloud administrators needs to setup all the resources managing the network services, since they are now external to CloudStack. They need to setup routers/switches, DHCP, additional load balancers and etc. Please note that once setup, all services are managed externally, and therefore CloudStack cannot handle IP assignments, port forwarding or other networking services that the Virtual Router normally does. Layer 2 type networks can only be managed by cloud administrators.


About the author


Boris Stoyanov is Software Engineer in testing at ShapeBlue, The Cloud Specialists. Bobby spends his time testing features for the Apache CloudStack Community and for our ShapeBlue clients.


/by 
VPC to VPC VPN configuration in CloudStack
Introduction


Configuring connectivity between CloudStack hosted VPCs can be done by either using private gateways – which has to be configured by CloudStack root administrators to use dedicated network segments – or by using VPC-to-VPC connections, which can be configured by the CloudStack end user without admin input.


In this blog post we will cover how to configure the VPC-to-VPC VPN connections and ensuring that these are up and working as expected. This is covered in the CloudStack administration guide – but the terms used may be unfamiliar to anyone new to CloudStack and VPC networking, and we hope to add some clarity to this. In addition to the configuration of VPN we also cover some troubleshooting and operational steps.


Networking overview


To be able to route traffic from a VM in one VPC to a VM in another VPC the IP ranges used in the two VPCs must be unique and can not overlap. If the same IP ranges were used the traffic from one side of the VPN tunnel to the other would not route over the tunnel itself, hence connectivity could not be established.


As an example the two VPC networks could be configured as follows:


VPC1:


    

  • Super-CIDR: 10.1.0.0/16
    • 

  • Tier 1: 10.1.0.0/24
    • 

  • Tier 2: 10.1.1.0/24
    • 



VPC2:


    

  • Super-CIDR: 10.2.0.0/16
    • 

  • Tier 1: 10.2.0.0/24
    • 

  • Tier 2: 10.2.1.0/24
    • 



Apart from this the VPC-to-VPC VPN tunnel will be using the CloudStack public network – hence the two VPC networks can be:


    

  • On the same CloudStack infrastructure, using the same account.
    • 

  • On the same CloudStack infrastructure, using different accounts.
    • 

  • On different CloudStack infrastructures altogether (please note however different versions of CloudStack may run different VPN versions hence there may be incompatibilities under some circumstances).
    • 



For the purpose of this article we are going to use the following network topology:






Terms used


VPN gateway


The VPN gateway is the term used for the local VPN endpoint. This is simply enabled on the source-NAT IP address of the VPC virtual router – and it allows the local VR to accept incoming VPN connections.


VPN customer gateway


The VPN customer gateway is the remote endpoint we target when we configure the VPN connection. When we configure these we need to specify all the details for this VPN connection:


    

  • Name: user friendly name for the gateway
    • 

  • Gateway: the public facing IP address of the remote VPC virtual router.
    • 

  • CIDR list: this is a list of CIDR networks which are reachable at the remote end of the tunnel. Multiple CIDR ranges can be specified, separated my commas.
    • 

  • IPsec pre-shared key: this is effectively the VPN passphrase used when the VPN connection is negotiated – and it should therefore follow standard password best practices in a production environment.
    • 

  • IKE / ESP encryption details for the VPN tunnels.
    • 



VPN connection


The VPN connection is the pairing from the source – or local – VPN gateway to the remove VPN customer gateway.  This is configured in one of two modes:


    

  • Active: the connection which initiates the VPN tunnel, typically from the VPC hosting VMs which consumes resources on the remote VPC.
    • 

  • Passive: this connection waits for the opposite VPC VR to initiate the connection, and is typically on the VPC hosting the resources to be consumed.
    • 



Please note for both of these connections the resources either end must be reachable over the CIDR list configured for the VPN customer gateway.


 


Configuring the VPN tunnels


Create and configure the VPC networks


First of all configure the VPC networks at either end with the required VPC ACL lists.




Create customer gateways


Navigate to “Network” and select “VPN customer gateway” on the pulldown menu, the click the “Add VPN customer gateway” button.


In this example we assume that VMs on both VPC1 tier 1 and 2 will consume resources on VPC2. Please note in this case we only configure the name, public gateway, CIDR list and the IPsec preshared key, all other fields are left as defaults.




Repeat this step for the customer gateway on VPC2:




Create the VPN gateway on each VPC


Navigate to each VPC, click the configure button and then click the “Site to site VPN” pane under “Router”. Confirm you want to create the VPN gateway:




This will simply configure the local VPN gateway – and no further configuration input is required. The only actions that can be carried out against a VPN gateway is to delete this from the VPC.


Repeat the above step for VPC2 before continuing.


Configure the VPN connections


First of all configure the active connection – in this example we will configure this to be the connection from VPC1 to VPC2.


Navigate to VPC1, click “configure”, then click on the “Site to site VPN” pane. From the “select view” pulldown menu select “VPN connections” and click the “Create VPN connection” button.


Next select the remote Customer VPN gateway – and do not tick the “active” tick box. Click OK.




Repeat this step for the passive connection from VPC2 to VPC1, but for this one tick the “passive” tick box:




Once both VPN connection have been configured refresh the screen and ensure the VPN connection state is “connected”.

If the VPN connection doesn’t come up automatically simply go back to the active connection (from VPC1 to VPC2) and click the “Reset VPN connection” button:




Once the VPN connections are in a “connected” state VMs on VPC1 should be able to connect to VMs on VPC2.


Operation and troubleshooting


If the VPC-to-VPC connection doesn’t work as expected check the following:


    

  • ACL lists: all VPC-to-VPC connections still adhere to the Access Control Lists set for each VPC tier, i.e. if a tier is configured to use e.g. “default_deny” then neither traffic on a different tier locally or traffic from remote VPCs will reach the VMs in question.
    • 

  • To check the VPN tunnels on the VPC virtual router, log in using the standard connection method for the hypervisor in use, then check the status of the VPN tunnels with the “ipsec statusall” command:
    • 



root@r-12-VM:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.1, Linux 3.2.0-4-amd64, x86_64):
uptime: 7 days, since Jun 12 11:06:50 2017
malloc: sbrk 675840, mmap 0, used 570816, free 105024
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 7
loaded plugins: charon test-vectors ldap pkcs11 aes rc2 sha1 sha2 md5 rdrand random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem gcrypt af-alg fips-prf gmp xcbc cmac hmac ctr ccm curl attr kernel-netlink resolve socket-default farp stroke updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 eap-radius eap-tls eap-ttls eap-tnc xauth-generic xauth-eap xauth-pam tnc-tnccs dhcp lookip error-notify certexpire led addrblock unity
Listening IP addresses:
169.254.0.47
10.1.35.205
10.1.0.1
Connections:
vpn-10.1.35.206: 10.1.35.205...10.1.35.206 IKEv1/2
vpn-10.1.35.206: local: [10.1.35.205] uses pre-shared key authentication
vpn-10.1.35.206: remote: [10.1.35.206] uses pre-shared key authentication
vpn-10.1.35.206: child: 10.1.0.0/16 === 10.2.0.0/24 10.2.1.0/24 TUNNEL
L2TP-PSK: 172.26.0.151...%any IKEv1
L2TP-PSK: local: [172.26.0.151] uses pre-shared key authentication
L2TP-PSK: remote: uses pre-shared key authentication
L2TP-PSK: child: dynamic[udp/l2f] === 0.0.0.0/0[udp] TRANSPORT
Security Associations (1 up, 0 connecting):
vpn-10.1.35.206[20]: ESTABLISHED 11 minutes ago, 10.1.35.205[10.1.35.205]...10.1.35.206[10.1.35.206]
vpn-10.1.35.206[20]: IKEv2 SPIs: 8eb5107dc41c7283_i* b780fce44dd22ba5_r, pre-shared key reauthentication in 23 hours
vpn-10.1.35.206[20]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
vpn-10.1.35.206{25}: INSTALLED, TUNNEL, ESP SPIs: c884bc58_i cf7ce84c_o
vpn-10.1.35.206{25}: AES_CBC_128/HMAC_SHA1_96, 57204 bytes_i (681 pkts, 1s ago), 58212 bytes_o (693 pkts, 1s ago), rekeying in 31 minutes
vpn-10.1.35.206{25}: 10.1.0.0/24 10.1.1.0/24 === 10.2.0.0/24 10.2.1.0/24



    

  • From the above please note the following lines which lined the tunnel connection:
    • 



Connections:
vpn-10.1.35.206: 10.1.35.205...10.1.35.206 IKEv1/2
vpn-10.1.35.206: local: [10.1.35.205] uses pre-shared key authentication
vpn-10.1.35.206: remote: [10.1.35.206] uses pre-shared key authentication
vpn-10.1.35.206: child: 10.1.0.0/16 === 10.2.0.0/24 10.2.1.0/24 TUNNEL



    

  • As well as the following which list the networks at each side of the connection:
    • 



vpn-10.1.35.206{25}: 10.1.0.0/24 10.1.1.0/24 === 10.2.0.0/24 10.2.1.0/24



    

  • The logs for the IPsec VPN connections can be found in:

      

    • /var/log/cloud.log: CloudStack handshaking for the VPN tunnels.
      • 

    • /var/log/auth.log: shows the IPsec handshakes for the VPN tunnel.
      • 

    • /var/log/daemon.log: similar to auth.log, shows the VPN tunnel handshaking and output.
      • 

    

    • 

  • To stop a VPN connection simply delete it from the VPC configuration screen – this will remove the VPN connection but leave the VPN gateway and VPN customer gateway in place:
    • 





Conclusion


We hope this article will clarify the terms used and the configuration steps required to configure a VPC-to-VPC VPN connection. As always we’re happy to receive feedback , so please get in touch with any comments, questions or suggestions.


About The Author


Dag Sonstebo is a Cloud Architect at ShapeBlue, The Cloud Specialists. Dag spends most of his time designing, implementing and automating IaaS solutions based on on Apache CloudStack.


/by 
Inter-VPC connectivity in CloudStack
Introduction


In this article Abhinandan  Prateek discusses a method for allowing inter-VPC routing in CloudStack utilising Quagga on the VPC Virtual Router. Please note – this feature is currently in development, this is being considered for release in CloudStack 4.10 (please refer to upcoming release notes for details).


In CloudStack a VPC acts as a container for multiple isolated networks that can communicate with each other via its virtual router (VPC-VR).  A VPC can have its own virtual network topology resembling a traditional multi-tier physical network that it is substituting itself for.  The following figure shows a typical CloudStack VPC with three tiers. The traffic flows from one tier to another is via VPC virtual router (VPC-VR), which acts as the default gateway for each tier. CloudStack manages the traffic flow by configuring the firewall rules on the virtual router. Any communication that goes in and out of VR to the public network requires network address translation (NAT-ing).




Figure 1: Cloudstack VPC with three tiers


In large organisations where the end-to-end access is a requirement, the current VPC model brings more complexity to management and hands-on configuration beside the overhead involved in the NAT address translations processing. In these kind of enterprise environments, the VR needs to route networks using both public and private IP addresses. This requires advance configuration that involves NAT-ing – which in itself brings in its own overheads.


This article explains an approach that will make the NAT-ing unnecessary because the networks will be routed and announced dynamically using the Open Shortest Path First (OSPF) protocol. There are several implementations of OSPF on Linux like gated, zebra and quagga.  After some initial comparison it was decided that we will use Quagga on VPC-VR to provide OSPF implementation.


Quagga is an advanced software routing package which provides a suite of TCP/IP-based routing protocols and provides implementations of OSPFv2, OSPFv3, RIP v1 and v2, RIPng and BGP-4 for Unix-like platforms, particularly FreeBSD, Linux, Solaris and NetBSD. The Cloudstack VPC-VR will use quagga to configure inter-VPC dynamic routing. Quagga implements OSPF (v2, v3) and is found suitable to run on the Debian based VPC virtual router to provide dynamic routing.


When a new network is added, OSPF protocol running on the VPS-VR is instrumented by CloudStack to advertise the newly added network to other VPC-VRs that are part of the physical network as shown in Figure 2. The OSPF protocol running on VPC routers in conjunction with the core-routers will take care of routing between different VPC’s as well as public network in most efficient manner.


 




Figure 2:  VPC-VRs advertising routes on physical network


For CloudStack to configure Quagga running on VPC-VR the most important piece of information is the distribution of subnets between various VPCs. These subnets are part of a unique super subnet defined at zone level. We will refer to it as the Zone Super-CIDR. CloudStack manages this zone level Super-CIDR, and when a new VPC is being created, it carves out a subnet for that VPC from this Zone Super-CIDR.


Dynamic VPC addressing scheme


In order a user VM that is part of a dynamically routed VPC to be able to address another, the IP addresses are carved out from the same network. This section describes how CloudStack manages the IP addressing scheme.


 




Figure 3: Address allocation for VMs across two VPC tiers


In Figure 3, the Zone Wide Super CIDR is 200.200.0.0/16. The two VPC in Figure 3, requested a /22 subnet. CloudStack carved out 200.100.0.0/22 and 200.100.4.0/22 for these VPC referred to as Left and Right VPCs respectively.


Two tiers Left and Right were further created below the two VPCs and allocated 200.100.1.0/24 and 200.100.5.0/24 respectively, from the subnet of their parent VPC. The newly created VMs then take the IP address from the VPC-tier’s subnet. These are 200.100.1.101 for LeftVM1 and 200.100.5.101 from RightVM1.


Please note the above super-CIDR partitioning scheme is an example only. The selection of super-CIDR and subsequent partitioning of it is user driven.


Some of the operators may want their users to have public IP assigned to their VPC-VMs. To facilitate that CloudStack will allow both private and public class super-CIDRs to be specified for the zone.


Now that CloudStack has worked out the addressing scheme all that remains is passing the subnet and addresses along with some more configuration information to the VPC VR. The information is synchronized whenever a new network is created or changes are made to existing VPCs. In OSPF terminology a CloudStack VPC is referred to as a unique area, identified by an area id. CloudStack generates these unique area ids. Some of the other additional information is about various timeouts and authentication parameters.


 


Using OSPF in Cloudstack


With OSPF implementation following is the methodical way to create dynamic VPCs in cloudstack:


Enable OSPF in the zone


Login as admin and then go-to: Infrastructure->Zones, select the zone in which you want to enable OSPF and click the tab “Dynamically Routed”.  You will be asked to select some options. Most important of these option is zone level Super-CIDR. You need to set it as per your setup and needs.




Figure 4: Dynamically routed zones have a button to ‘Add Routed VPC’


Service offerings


The default service offerings to create VPC and VPC tier are provided by CloudStack. In addition, you can create your own custom service offerings that are dynamically routed as described below.


Create Dynamic VPC Service Offering


Go to Service Offerings and then select VPC Offering. From here you can add VPC Offering. One of the supported services should be “VPCDynamicRouting” in order for the VPC to be dynamically routing enabled.


Create Dynamic VPC Network tier offering


Go-to Service Offerings and then select Network Offering. From here you can add Network Offering. Select “VPC” and add “VPCDynamicRouting” as one of the supported services.


Create VPC




Now you can create dynamically routed VPCs by selecting the dynamic service offering for VPC. In a regular VPC you need to provide a CIDR, but since in dynamically routed VPC the VPCs will get a share from the zone level super CIDR. So instead of a CIDR you need to specify a netmask, CloudStack allocates a suitable subnet that caters to the netmask that you specified. In case no such range exists the VPC creation fails.


 


Create VPC tiers




Create a dynamic VPC tier by selecting the dynamic network offering. You need to provide gateway and netmask. CloudStack will automatically carve out the subnet from the VPC CIDR.


 


Create ACLs


To provide access across tiers create appropriate ACL rules to allow traffic to the VMs.


Create User VM


Create VMs in the dynamic tiers. User VMs will now get an ip allocated to them from their tier subnet. These VMs can reach out to other VMs on different VPC if appropriate ACLs are configured to allow the traffic.


VPC VR


You can login into the VPC virtual router, refer to CloudStack documentation on how to do that.  Following are some interesting quagga commands and sample output that will show you OSPF in action.


$vtysh -c "show ip ospf neighbor"
Neighbor ID Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
192.168.100.68    1 Full/DR           34.090s 192.168.100.68  eth1:192.168.100.67      0     0     0


$vtysh -c "show ip ospf route"
============ OSPF network routing table ============
N    200.200.1.0/24         [10] area: 0.0.0.67
directly attached to eth2
N    200.200.2.0/24         [10] area: 0.0.0.67
directly attached to eth3
N IA 200.200.5.0/24         [20] area: 0.0.0.0
via 192.168.100.68, eth1
N IA 200.200.6.0/24         [20] area: 0.0.0.0
via 192.168.100.68, eth1
N    200.200.100.0/24      [10] area: 0.0.0.0
directly attached to eth1
============ OSPF router routing table =============
R    192.168.100.68        [10] area: 0.0.0.0, ABR, ASBR
via 192.168.100.68, eth1
============ OSPF external routing table ===========


 


With this approach and with some settings on your core router you can dynamically route internet traffic to public ip addresses within the VPCs. Dynamic routing also simplifies the book keeping done by CloudStack in persisting and applying the routing information.


About The Author


Abhinandan Prateek is a Software Engineer at ShapeBlue, The Cloud Specialists. Abhi spends his time developing solutions for the CloudStack community as well as for our ShapeBlue clients.


/by