incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <>
Subject Re: Virtual Router Network Service Restrictions
Date Wed, 13 Mar 2013 02:04:06 GMT
Nevertheless a good endeavor to start breaking up these dependencies.

On 3/12/13 6:55 PM, "Sheng Yang" <> wrote:

>Sorry missed it at first place...
>The reason is our logic in the VR scripts would presume that source
>nat is enabled, if we want to enable other services. For example, if
>you don't want to enable source nat, then we assume you only want to
>run VR as a dhcp server, then we won't bring up eth2(normally for
>public network) in the VR.
>The ability of defining different services for the network service
>offering has been added at 3.0, but our VR behavior in this way since
>we have VR(I think), so it's hard to decouple source nat with other
>public network services. And it's also hard to decouple them in mgmt
>server side. So I've added this change to 3.0 to make sure user didn't
>break it though API.
>There are large numbers of the code(both mgmt server and backend
>scripts) depends on the assumption that VR should have source nat when
>it's serving as VR for isolate network. I am afraid it would be very
>hard to remove them for now.
>On Tue, Mar 12, 2013 at 6:46 PM, Dave Cahill <> wrote:
>> Hi Sheng,
>> CCing you in case this slipped through first time around in the flood of
>> cloudstack-dev mail. :)
>> Joe explains more below, but the core of this is if you look at
>> VirtualRouterElement.verifyServicesCombination():
>>         if (!services.contains(Service.SourceNat)) {
>>             if (services.contains(Service.StaticNat) ||
>> services.contains(Service.Firewall) || services.contains(Service.Lb) ||
>>                     services.contains(Service.PortForwarding) ||
>> services.contains(Service.Vpn)) {
>> <snip>
>>                 s_logger.warn("Virtual router can't enable services " +
>> servicesList + " without source NAT service");
>> <snip>
>> It looks like this restriction came in with a commit of yours
>> (46a12b378c288d27d86c9c885534f1309fee0f63), and we're not sure why the
>> restriction exists - could you give us some background?
>> Thanks,
>> Dave.
>> On Mon, Mar 4, 2013 at 12:17 PM, Mills, Joseph <> wrote:
>>> Hi Sheng,
>>> I was looking into possible plugin combinations with the Virtual Router
>>> network service provider, and I saw the restriction that VPN, LB,
>>> Firewall,
>>> PortForwarding, and Static NAT on the VirtualRouter all require that
>>> VirtualRouter also be the Source NAT service provider. I am hoping to
>>> able to change this to create a network service offering that could
>>> example) use the VirtualRouter for VPN, but Midonet for everything
>>> What was the initial reason for requiring Source NAT on the
>>> for service like VPN or LB? Is it possible to remove these
>>> Thanks,
>>> Joe

View raw message