cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Roque Marques <pedro.r.marq...@gmail.com>
Subject Re: contrail virtual network controller
Date Tue, 03 Dec 2013 06:12:05 GMT
Radhika,
There are several aspects that need to be documented:
1) How to build the software (OpenContrail + hypervisor support).
2) How to install the software (Starting the multiple components of the contrail solution).
3) How to provision a zone to use the contrail plugin.
4) Usage: document any deltas when using this plugin when it comes to the user API (network,
etc).

When it comes to building OpenContrail, we currently have that we distribute as devstack fork
(https://github.com/dsetia/devstack/tree/master/contrail) that builds and starts the OpenContrail
configuration, control and virtual-router components. This script needs to be split out such
that we can separate from OpenStack and can be use to build and start the OpenContrail components
independently. Deepinder is working on this but it is not complete yet.

For a XenServer hypervisor, one also needs to build the virtual-router components on a DDK
VM, so that this can then be executed on the target.

The management server must have a file "contrail.properties" with the following content:
api.hostname = localhost
api.port = 8082

This is how the management server plugin locates the contrail API server.

Provisioning a zone is relatively simple process:
1. create a zone (networktype: Advanced)
2. create Pods/Clusters as required
3. create physical network using the following parameters:
	
	        args = {'name': 'ip-fabric',
                'zoneid': zone_id,
                'isolationmethods': 'L3VPN'}
        response = client.request('createPhysicalNetwork', args)

4. setup the Public network parameters:
        response = client.request('listNetworks',
                                  {'issystem': 'true',
                                   'traffictype': 'Public'})
        uuid = response['listnetworksresponse']['network'][0]['id']
        args = {'networkid': uuid,
                'zoneid': zone_id,
                'vlan': 'untagged',
                'startip': PARAMS['public_net']['startip'],
                'endip': PARAMS['public_net']['endip'],
                'gateway': PARAMS['public_net']['gateway'],
                'netmask': PARAMS['public_net']['netmask']}
        response = client.request('createVlanIpRange', args)

5. Enable the providers JuniperContrailRouter and JuniperContrailVpcRouter (uncommited):
	    args = {'name': provider,
                'physicalnetworkid': physnet}
        response = client.request('addNetworkServiceProvider', args)

Step 3 above uses the new isolation mechanism (L3VPN) which is uncommitted. This was a change
requested during the plugin code review that is being tested but not yet upstreamed.

When it comes to usage:
	a) The public network is virtualized.

	The admin of the DC is expected to configure a gateway between the virtualized domain and
the "outside world"
	One of the main goal of the OpenContrail design is to enable DC operators to run the network
as a pure IP underlay. This means no VLAN support. The advantage is that one can run network
topologies that provide a much higher throughput; but you still need a gateway to the outside
world. One can use a RFC 4364 compliant router/switch for this task (it also need to support
RFC 4023). The OpenContrail project also provides an option to run the virtual-router software
as a gateway; this is for testing purposes only since it is not a cost effective solution
for high traffic volumes.

	Having a gateway in place, one needs to configure the OpenContrail controller and the gateway
to speak to each other. This step is independent of CloudStack itself and is the same on OpenStack.

	b) Guest networks work as expected;
	c) Static IP is supported (implemented directly on the vrouter);
	d) VPC code is not upstreamed yet... you should see the code review requests soon; it can
be used for a tenant to exchange traffic between its networks without having the traffic flow
through a DomainRouter.
	e) SourceNAT (1:n NAT) requires a virtual machine appliance...

	f) We don't have today a cloudstack API to allow a tenant network to connect to another tenant
(or admin) network; One of the main features of OpenContrail is that it enables this sort
of communication to go directly without having to flow through a DomainRouter VM; this is
very useful when the admin is providing services to the tenant (e.g. think database-as-a-service).

There is a lot of ground to cover... I would also like us to put together a test rig like
devstack where all of these pieces can come together.

  Pedro.

On Dec 1, 2013, at 9:29 PM, Radhika Puthiyetath <radhika.puthiyetath@citrix.com> wrote:

> Hi Pedro,
> 
> Is there a documentation exist on this feature ? If not, I am interested to work on it.
> 
> Please let me know how we can collaborate developing content. 
> 
> Regards
> -Radhika
> 
> -----Original Message-----
> From: Pedro Roque Marques [mailto:pedro.r.marques@gmail.com] 
> Sent: Tuesday, September 17, 2013 3:42 AM
> To: dev@cloudstack.apache.org
> Subject: contrail virtual network controller
> 
> Myself and a few others in the Contrail team have been working on a cloudstack network
plugin that interfaces with the contrail VNC (http://www.opencontrail.org). At the moment
the plugin provides isolated guest networks (and a virtualized "Public" network) as an overlay
that is capable of interconnecting directly with routers/switches that implement the existing
standard for network virtualization (RFC 4364).
> 
> We would like to contribute this code to CloudStack. We intend to continue to enhance
it in order to add full support for functionality one would expect out of the EC2 VPN API.
> 
> What is the process to do that ?
> 
> thanks,
>  Pedro.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message