cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <>
Subject Re: [PROPOSAL] Bridge functionality
Date Fri, 21 Mar 2014 11:15:05 GMT
What is the structure of the bridge URI?

 I might be interested in specifying the split of IP addresses across the bridge (e.g.,
on the overlay, on the VLAN).
Will there be separate DHCP providers for the 2 segments? How about multiple bridged segments?
Are there VMs controlled by CloudStack on the physical network ? (I assume this is a VLAN)

From: Hugo Trippaers <<>>
Reply-To: "<>" <<>>
Date: Thursday, March 13, 2014 at 2:32 AM
To: "<>" <<>>
Subject: Re: [PROPOSAL] Bridge functionality

On 11 mrt. 2014, at 21:51, Chiradeep Vittal <<>>

Is there a more detailed writeup? I am interested in the api and Œflow’

No, no more details at the moment. Still thinking a lot on how i want it to work. I’m trying
to get this as generic as possible so other SDN solution can benefit from the framework.

The main components are :

BridgeService (much like the FirewallService) that js responsible for handing the API commands
and making sure that users can on attach a bridge to a network that has been whitelisted by
an Admin.
BridgeProvider (network element extension) that is responsible for implementing a bridge on
a network, either triggered by the api (createBridgeCmd) or by an event (implement()).

The elements would also be responsible for gathering the details for their specific bridge
implementations, for example in the VMware NSX environment a bridge would need a gateway service
ID. An internal OVS implementation would need an ovs bridge name.

Admin api
AddBridgeUri( zone, domain, account, uri) <id>
RemoveBridgeUri ( id) <success>

User api
AddBridge(network, destination uri) <id>
DeleteBridge(id) <success>



On 3/11/14, 7:12 AM, "Hugo Trippaers" <<>>
Hey all,
I¹ve been working on adding Bridge support to CloudStack. The use case is
that with the introduction of SDN there is a need for us to link logical
networks to physical hosts or physical networks. A typical use case would
be to connect legacy infrastructure to cloud infrastructure, or to
support cloud bursting from an existing infrastructure to a network in
the cloud.
Routing can sometimes be used to accomplish the same effect (for example
the private gateway option in a VPC), but in some cases a L2 connection
is preferred.
The functionality would a central bridge manager in CloudStack. The
bridge manager would have a number of admin only commands that link a
number of networks to a specified domain or account. The user commands
would allow an account to link a logical network to an external physical
network. This separation is done to ensure users are never able to
configure a bridge to a network they shouldn¹t have access to. Admins
will have to make an external network available as a bridge destination
and a user can select it.
The network implementation will consists of a BridgeProvider element
extension which elements can implement. It¹s up to the elements to
configure the particulars of their bridge implementation.
Initial implementation will cover the admin commands, user commands and
an implementation in the VMware NSX  plugin. UI is out of scope for the
first implementation.
Any feedback is welcome :D

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