Hey Hugo, Thanks for the reply. At the moment we are still evaluating technologies but Nicira is one of them.
Jeffrey S. McGovern SunGard Availability Services 401 N. Broad Street - Mezzanine Philadelphia, PA 19108 Desk: 215-446-2722 Fax: 215-408-4700 jeffrey.mcgov...@sungard.com On Thu, Feb 7, 2013 at 5:11 PM, Hugo Trippaers < htrippa...@schubergphilis.com> wrote: > Not at all. > > He is raising a valid point. The current code is actively rejecting > external elements for vpcs. I'm already working on a fix for that as we > want to use our Nicira stuff with vpc as well. It looks like its a trivial > fix, as it used to work before this restriction was put in. > > There are also some dependencies on vlans that I might have to remove or > workaround. As soon as I got packaging fixed for the 4.1 branch this is > next on my list. There is already some code in a branch for this, but I > haven't been able to test it yet due to time constraints. > > Which overlay networks are you intending to use? I can make sure to test > with that as well. > > Cheers, > > Hugo > > > Verstuurd vanaf mijn iPad > > Op 7 feb. 2013 om 23:00 heeft "Chip Childers" <chip.child...@sungard.com> > het volgende geschreven: > > > Hugo - Mind taking a look at the questions that Jeff has? > > > > On Thu, Feb 07, 2013 at 04:53:19PM -0500, Jeffrey McGovern wrote: > >> So after more research I found this > >> article<https://cwiki.apache.org/CLOUDSTACK/inter-vlan-routing.html> > >> which > >> is where we are trying to get to in terms of our network design. As I > was > >> reading through the Inter-VLAN routing link it mentions the following: > >> > >> "In vpcOffering you define which services you want to support in the > VPC. > >> When new Guest network is added to the VPC, we should check if its set > of > >> services/providers are within VPC service/providers list. As > >> sourceNatService is required by the VPC, even when its not specified in > >> serviceProviders list, we add it automatically (with the > VpcVirtualRouter > >> provider). Only VpcVirtualRouter can play a provider role inside the > VPC." > >> > >> > >> I have an additional question which is if we intend to use an overlay > >> network and the overlay vendor is implemented as a network service > provider > >> can we use the overlay in conjunction with the VpcVirtualRouter even > though > >> the last line of the above quote states: Only VpcVirtualRouter can play > a > >> provider role inside the VPC? > >> > >> > >> The source of my confusion comes from slide 12 - 16 of this > >> deck<http://www.slideshare.net/hugotrippaers/cloudstack-nvp-integration > > > >> where > >> Nicira appears to be implemented as a Service Provider which would > appear > >> to not allow the two to coexist. > >> > >> > >> > >> Jeffrey S. McGovern > >> SunGard Availability Services > >> 401 N. Broad Street - Mezzanine > >> Philadelphia, PA 19108 > >> Desk: 215-446-2722 > >> Fax: 215-408-4700 > >> jeffrey.mcgov...@sungard.com > >> > >> > >> On Wed, Feb 6, 2013 at 10:01 AM, Jeffrey McGovern < > >> jeffrey.mcgov...@sungard.com> wrote: > >> > >>> Geoff, > >>> Kinda sort of what I am looking for but can you help me understand this > >>> statement taken from > >>> > http://incubator.apache.org/cloudstack/docs/en-US/Apache_CloudStack/4.0.0-incubating/html/Installation_Guide/configure-vpc.html#add-gateway-vpc > >>> ? > >>> > >>> "A private gateway can be added by the root admin only. The VPC private > >>> network has 1:1 relationship with the NIC of the physical network. No > >>> gateways with duplicated VLAN and IP are allowed in the same data > center.? > >>> > >>> > >>> Given a multi-tenant environment does this actually imply that this > >>> network must be bound to a physical interface? Or does this mean that > there > >>> must be a physical interface dedicated to this type of traffic which > can > >>> then be carved up among multiple tenants based on the providers model? > >>> > >>> > >>> > >>> Jeffrey S. McGovern > >>> SunGard Availability Services > >>> 401 N. Broad Street - Mezzanine > >>> Philadelphia, PA 19108 > >>> Desk: 215-446-2722 > >>> Fax: 215-408-4700 > >>> jeffrey.mcgov...@sungard.com > >>> > >>> > >>> On Tue, Feb 5, 2013 at 7:41 PM, Geoff Higginbottom < > >>> geoff.higginbot...@shapeblue.com> wrote: > >>> > >>>> Hi Jeff, > >>>> > >>>> If I have interpreted your requirements correctly, you want to send > >>>> traffic from the Guest Instances to a network which is probably > within the > >>>> Data Centre and not on the internet. The Default Gateway for the > Guest VMs > >>>> is the VPC Virtual Router, and the Gateway used by the VPC Virtual > Router, > >>>> is the Public Network Gateway. > >>>> > >>>> If you want to direct traffic destined for a particular CIDR, you can > >>>> configure the VPC Virtual Router to route the traffic via a different > >>>> Gateway by using the 'Private Gateway' feature. > >>>> > >>>> Imagine you have a set of physical servers running in the same DC, > create > >>>> a VPC Private Gateway, and then create the Routing Rules for the > required > >>>> CIDR, specifying the alternate Gateway IP which has L3 connectivity > to the > >>>> physical servers. This will add a new Virtual Interface onto the VPC > >>>> Virtual Router, and create the routes so traffic is sent via the > alternate > >>>> Gateway rather than the Public Network Gateway. You will obviously > need to > >>>> update the routing rules on alternate gateway so the traffic can flow > back > >>>> to the Guest VMs. > >>>> > >>>> Regards > >>>> > >>>> Geoff Higginbottom > >>>> > >>>> D: +44 20 3603 0542 | S: +44 20 3603 0540 | M: +447968161581 > >>>> > >>>> geoff.higginbot...@shapeblue.com > >>>> > >>>> -----Original Message----- > >>>> From: Chip Childers [mailto:chip.child...@sungard.com] > >>>> Sent: 05 February 2013 19:12 > >>>> To: cloudstack-users@incubator.apache.org > >>>> Subject: Re: Configuring static routes on VM > >>>> > >>>> On Tue, Feb 05, 2013 at 10:47:15AM -0800, Chiradeep Vittal wrote: > >>>>> We could enhance the CloudStack API to support DHCP options per > subnet. > >>>>> One DHCP option could be static routes. > >>>> > >>>> +1 to that... Jeff, want to open a feature request [1] for this? > >>>> > >>>> -chip > >>>> > >>>> [1] https://issues.apache.org/jira/browse/CLOUDSTACK > >>>> > >>>>> On 2/5/13 10:06 AM, "Chris Sears" <chris.x.se...@sungard.com> wrote: > >>>>> > >>>>>> Hi Jeff, > >>>>>> > >>>>>> CloudStack currently does all in-guest network configuration via > DHCP > >>>>>> and, as far as I can tell, no DHCP options are being set that would > >>>>>> push static routes. > >>>>>> > >>>>>> If you have a VM with multiple NICs, the DHCP server will hand out > >>>>>> IPs to each of them, while trying not to confuse the guest about the > >>>>>> default gateway. In an earlier discussion, it was mentioned that > this > >>>>>> can be challenging due to differences in DHCP client of each guest > OS: > >>>>>> http://markmail.org/message/a5nwds7emxxix3ux > >>>>>> > >>>>>> - Chris > >>>>>> > >>>>>> On Tue, Feb 5, 2013 at 9:29 AM, Chip Childers > >>>>>> <chip.child...@sungard.com> > >>>>>> wrote: > >>>>>>> On Mon, Feb 4, 2013 at 2:59 PM, Jeffrey McGovern > >>>>>>> <jeffrey.mcgov...@sungard.com> wrote: > >>>>>>>> Hello, > >>>>>>>> I was wondering if there is a way to configure static routes on a > >>>>>>>> guest VM after it has been provisioned via Cloudstack? > >>>>>>> > >>>>>>> Jeff, > >>>>>>> > >>>>>>> It may help if you provide a little more context to the question to > >>>>>>> help folks understand what you're looking to do. > >>>>>>> > >>>>>>> -chip > >>>> > >>>> ShapeBlue provides a range of strategic and technical consulting and > >>>> implementation services to help IT Service Providers and Enterprises > to > >>>> build a true IaaS compute cloud. ShapeBlue’s expertise, combined with > >>>> CloudStack technology, allows IT Service Providers and Enterprises to > >>>> deliver true, utility based, IaaS to the customer or end-user. > >>>> > >>>> ________________________________ > >>>> > >>>> This email and any attachments to it may be confidential and are > intended > >>>> solely for the use of the individual to whom it is addressed. Any > views or > >>>> opinions expressed are solely those of the author and do not > necessarily > >>>> represent those of Shape Blue Ltd. If you are not the intended > recipient of > >>>> this email, you must neither take any action based upon its contents, > nor > >>>> copy or show it to anyone. Please contact the sender if you believe > you > >>>> have received this email in error. Shape Blue Ltd is a company > incorporated > >>>> in England & Wales. > >>> > >>> > >
