H, Please, have a look at the example picture in https://cwiki.apache.org/confluence/display/CLOUDSTACK/inter+vpc+network
It depicts a mix of the use cases I described earlier and gives an overview of the possibilities required. regards, Daan On Tue, May 27, 2014 at 10:15 PM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > Absolutely, will be next week I am afraid. > > On Tue, May 27, 2014 at 7:04 PM, Chiradeep Vittal > <chiradeep.vit...@citrix.com> wrote: >> Hi Daan, >> >> Sounds interesting! Could I beg you to post some images / figures and more >> text so that I can understand better? >> >> Thanks >> — >> Chiradeep >> >> From: Daan Hoogland <daan.hoogl...@gmail.com> >> Date: Monday, May 26, 2014 at 3:39 AM >> To: Chiradeep Vittal <chiradeep.vit...@citrix.com> >> Cc: Alena Prokharchyk <alena.prokharc...@citrix.com>, Sheng Yang >> <sheng.y...@citrix.com>, Alex Huang <alex.hu...@citrix.com>, >> "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>, Jayapal Reddy Uradi >> <jayapalreddy.ur...@citrix.com> >> Subject: Re: [DISCUSS] vpc gateway networks are guestnetworks >> >> Chiradeep, >> >> I read the vpc-peering option again and it seems not to give us >> enough. We want a superset of this feature where more then two vpc can >> be connected to the same intervpc network. Use cases are >> - have a single monitor and other management devices for several >> applications in different vpcs >> - have a promotion mechanism across test/acceptance/prod/postprod >> environments >> - (as long as we don't have redundant vpc routers) have a management >> environment connected to two vpc's to manage fail-over/dr scenario's >> >> using all peer to peer connections for this can get rather mashy. >> What do you think? >> >> Daan >> >> >> On Fri, May 23, 2014 at 10:56 PM, Daan Hoogland <daan.hoogl...@gmail.com> >> wrote: >> >> As you can see it isn’t trivial. >> >> I guess you refer to the overlapping cidrs. I am afraid that some >> responsibility here will have to lay with the domain admin(s). If we >> limit inter vpc networks to one domain we can enforce the ip ranges >> not to overlap. >> >> the routing problem is tackled by a next hop field near the cidr. >> >> I am sure I am missing some other non trivial challenges. >> >> On Fri, May 23, 2014 at 7:23 PM, Chiradeep Vittal >> <chiradeep.vit...@citrix.com> wrote: >> >> I guess the ‘proper’ way to have done this would be to have a >> ‘createPrivateGateway’ API that is independent of the vpc and a >> attachPrivateGateway that attaches it to the vpc. >> >> Re: next hop, I’d like to see an FS for this feature. It seems to me that it >> is very similar to VPC peering (http://goo.gl/Y7tNkM). >> As you can see it isn’t trivial. >> >> From: Daan Hoogland <daan.hoogl...@gmail.com> >> Date: Friday, May 23, 2014 at 2:06 AM >> To: Chiradeep Vittal <chiradeep.vit...@citrix.com>, Alena Prokharchyk >> <alena.prokharc...@citrix.com>, Sheng Yang <sheng.y...@citrix.com>, Alex >> Huang <alex.hu...@citrix.com> >> Cc: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org> >> Subject: [DISCUSS] vpc gateway networks are guestnetworks >> >> Hi, >> >> please considder this ugly peace of my work I am now compiling into >> cloudstack master VpcManagerImpl.createVpcPrivateGateway(..) that will >> fix a bug: >> >> { // experimental block, this is a hack >> // set vpc id in network to null >> // might be needed for all types of broadcast domains >> // the ugly hack is that vpc gateway nets are created as >> guest network >> // while they are not. >> // A more permanent solution would be to define a type of >> 'gatewaynetwork' >> // so that handling code is not mixed between the two >> NetworkVO gatewaynet = _ntwkDao.findById(privateNtwk.getId()); >> gatewaynet.setVpcId(vpcId); >> _ntwkDao.persist(gatewaynet); >> } >> >> the problem I want to solve is that vpc routers, when restarting >> assign the ip of the gateway to their gw-interface [1]. this is a ip >> conflict and it has bitten us. My first take was to create the network >> without passing the vpc id but that lead to all kinds of errors so I >> reverted. It seemed cleaner then this solution I am scheming for now. >> If this doesn't lead to obvious errors in my environment I will commit >> and be happy to again revert when integration tests fail. It is in any >> case not a permanent solution. >> >> Question: should the network for gateways be a special type that is >> handled almost the same as guest network (except for in this case) or >> is more refactoring needed? >> in any case I think this is something that will have to be dealt with soon. >> >> One consideration on the side: I want to add a next-hop field to the >> cidrs on the gateway so that it is possible to create a network with >> more vpcs that direct traffic to each other. The use case for this is >> a vpc for a customers mangement network connected to one for >> production and one for acceptance and one .... >> >> please flame, criticize or pose your questions >> >> [1] https://issues.apache.org/jira/browse/CLOUDSTACK-6485 >> >> -- >> Daan >> >> >> >> >> -- >> Daan >> >> >> >> >> -- >> Daan >> > > > > -- > Daan -- Daan
