cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <>
Subject Re: [DISCUSS] vpc gateway networks are guestnetworks
Date Mon, 26 May 2014 10:39:21 GMT

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?


On Fri, May 23, 2014 at 10:56 PM, Daan Hoogland <> 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
> <> 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 (
>> As you can see it isn’t trivial.
>> From: Daan Hoogland <>
>> Date: Friday, May 23, 2014 at 2:06 AM
>> To: Chiradeep Vittal <>, Alena Prokharchyk
>> <>, Sheng Yang <>, Alex
>> Huang <>
>> Cc: "" <>
>> 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]
>> --
>> Daan
> --
> Daan


View raw message