You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Dave Cahill <dc...@midokura.com> on 2013/08/22 03:26:38 UTC
Source NAT not applied on network startup (See Jira CLOUDSTACK-234)
Hi Murali,
After this change [1], how do Source NAT IPs get applied to a network on
network startup / first VM launch?
Previously, applyIpAssociations would get called as part of
reprogramNetworkRules, but this change introduces what it calls "a lazy
approach". From what I can see, this means that source NAT doesn't work on
startup, and I need to add a Static NAT or some other rule in order to wake
up the lazy approach and have the Source NAT + the new rule be applied.
Is there a workaround I'm missing? Maybe it's necessary to also enable the
firewall service to trigger application of the source NAT rules?
Thanks,
Dave.
[1]
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=server/src/com/cloud/network/NetworkManagerImpl.java;h=2b53565297dc7bd96c6102cdc1c90cb166e9e704;hp=dac6a3a42e75324a963997e17e076f4020a7103e;hb=fe568fe;hpb=c7f26583a26eb7e4f15feafc292ec9576df61a8d
On Tue, Jul 9, 2013 at 5:47 PM, Murali Reddy (JIRA) <ji...@apache.org> wrote:
>
> [
> https://issues.apache.org/jira/browse/CLOUDSTACK-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Murali Reddy resolved CLOUDSTACK-234.
> -------------------------------------
>
> Resolution: Fixed
>
> > create/delete firewa/lb/pf rule: send ip assoc command only on first
> rule is created on the IP and last rule is revoked on the IP
> >
> ---------------------------------------------------------------------------------------------------------------------------------
> >
> > Key: CLOUDSTACK-234
> > URL:
> https://issues.apache.org/jira/browse/CLOUDSTACK-234
> > Project: CloudStack
> > Issue Type: Bug
> > Security Level: Public(Anyone can view this level - this is the
> default.)
> > Components: Management Server
> > Affects Versions: 4.0.0
> > Reporter: Alena Prokharchyk
> > Assignee: Murali Reddy
> > Fix For: 4.2.0
> >
> >
> > We have to improve the logic for creating/deleting any kind of firewall
> rules. At the moment ipAssoc is being called when:
> > * the first rule for the ip address is being created
> > * the last rule for the IP address is being removed
> > As a part of ipAssoc command, we send all ip addresses assigned to the
> guest network of the rule. The behavior has to be fixed the way we send ip
> assoc only for the ip address the rule is being created for.
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA
> administrators
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
Re: Source NAT not applied on network startup (See Jira CLOUDSTACK-234)
Posted by Dave Cahill <dc...@midokura.com>.
Sounds great Murali, thanks for the quick response!
On Thu, Aug 22, 2013 at 10:42 PM, Murali Reddy <Mu...@citrix.com>wrote:
>
> I made a commit in 4.2-forward, will wait for BVT to run before raising a
> pull request to 4.2.
>
> On 22/08/13 12:12 PM, "Dave Cahill" <dc...@midokura.com> wrote:
>
> >Adding Chiradeep for guidance, as Murali seems to be away at the moment.
> >
> >Prasanna kindly verified that this is an issue with Virtual Router as well
> >as MidoNet, so I have filed a bug against 4.2:
> >https://issues.apache.org/jira/browse/CLOUDSTACK-4442
> >
> >
> >
> >On Thu, Aug 22, 2013 at 12:10 PM, Dave Cahill <dc...@midokura.com>
> >wrote:
> >
> >> Also, I tried to find the code review for this change, but couldn't
> >>track
> >> it down - could someone point me to it?
> >>
> >>
> >> On Thu, Aug 22, 2013 at 10:26 AM, Dave Cahill
> >><dc...@midokura.com>wrote:
> >>
> >>> Hi Murali,
> >>>
> >>> After this change [1], how do Source NAT IPs get applied to a network
> >>>on
> >>> network startup / first VM launch?
> >>>
> >>> Previously, applyIpAssociations would get called as part of
> >>> reprogramNetworkRules, but this change introduces what it calls "a lazy
> >>> approach". From what I can see, this means that source NAT doesn't
> >>>work on
> >>> startup, and I need to add a Static NAT or some other rule in order to
> >>>wake
> >>> up the lazy approach and have the Source NAT + the new rule be applied.
> >>>
> >>> Is there a workaround I'm missing? Maybe it's necessary to also enable
> >>> the firewall service to trigger application of the source NAT rules?
> >>>
> >>> Thanks,
> >>> Dave.
> >>>
> >>> [1]
> >>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=se
> >>>rver/src/com/cloud/network/NetworkManagerImpl.java;h=2b53565297dc7bd96c6
> >>>102cdc1c90cb166e9e704;hp=dac6a3a42e75324a963997e17e076f4020a7103e;hb=fe5
> >>>68fe;hpb=c7f26583a26eb7e4f15feafc292ec9576df61a8d
> >>>
> >>> On Tue, Jul 9, 2013 at 5:47 PM, Murali Reddy (JIRA)
> >>><ji...@apache.org>wrote:
> >>>
> >>>>
> >>>> [
> >>>>
> >>>>
> https://issues.apache.org/jira/browse/CLOUDSTACK-234?page=com.atlassian
> >>>>.jira.plugin.system.issuetabpanels:all-tabpanel]
> >>>>
> >>>> Murali Reddy resolved CLOUDSTACK-234.
> >>>> -------------------------------------
> >>>>
> >>>> Resolution: Fixed
> >>>>
> >>>> > create/delete firewa/lb/pf rule: send ip assoc command only on first
> >>>> rule is created on the IP and last rule is revoked on the IP
> >>>> >
> >>>>
> >>>>-----------------------------------------------------------------------
> >>>>----------------------------------------------------------
> >>>> >
> >>>> > Key: CLOUDSTACK-234
> >>>> > URL:
> >>>> https://issues.apache.org/jira/browse/CLOUDSTACK-234
> >>>> > Project: CloudStack
> >>>> > Issue Type: Bug
> >>>> > Security Level: Public(Anyone can view this level - this is the
> >>>> default.)
> >>>> > Components: Management Server
> >>>> > Affects Versions: 4.0.0
> >>>> > Reporter: Alena Prokharchyk
> >>>> > Assignee: Murali Reddy
> >>>> > Fix For: 4.2.0
> >>>> >
> >>>> >
> >>>> > We have to improve the logic for creating/deleting any kind of
> >>>> firewall rules. At the moment ipAssoc is being called when:
> >>>> > * the first rule for the ip address is being created
> >>>> > * the last rule for the IP address is being removed
> >>>> > As a part of ipAssoc command, we send all ip addresses assigned to
> >>>>the
> >>>> guest network of the rule. The behavior has to be fixed the way we
> >>>>send ip
> >>>> assoc only for the ip address the rule is being created for.
> >>>>
> >>>> --
> >>>> This message is automatically generated by JIRA.
> >>>> If you think it was sent incorrectly, please contact your JIRA
> >>>> administrators
> >>>> For more information on JIRA, see:
> >>>> http://www.atlassian.com/software/jira
> >>>>
> >>>
> >>>
> >>
> >
>
>
>
Re: Source NAT not applied on network startup (See Jira
CLOUDSTACK-234)
Posted by Murali Reddy <Mu...@citrix.com>.
I made a commit in 4.2-forward, will wait for BVT to run before raising a
pull request to 4.2.
On 22/08/13 12:12 PM, "Dave Cahill" <dc...@midokura.com> wrote:
>Adding Chiradeep for guidance, as Murali seems to be away at the moment.
>
>Prasanna kindly verified that this is an issue with Virtual Router as well
>as MidoNet, so I have filed a bug against 4.2:
>https://issues.apache.org/jira/browse/CLOUDSTACK-4442
>
>
>
>On Thu, Aug 22, 2013 at 12:10 PM, Dave Cahill <dc...@midokura.com>
>wrote:
>
>> Also, I tried to find the code review for this change, but couldn't
>>track
>> it down - could someone point me to it?
>>
>>
>> On Thu, Aug 22, 2013 at 10:26 AM, Dave Cahill
>><dc...@midokura.com>wrote:
>>
>>> Hi Murali,
>>>
>>> After this change [1], how do Source NAT IPs get applied to a network
>>>on
>>> network startup / first VM launch?
>>>
>>> Previously, applyIpAssociations would get called as part of
>>> reprogramNetworkRules, but this change introduces what it calls "a lazy
>>> approach". From what I can see, this means that source NAT doesn't
>>>work on
>>> startup, and I need to add a Static NAT or some other rule in order to
>>>wake
>>> up the lazy approach and have the Source NAT + the new rule be applied.
>>>
>>> Is there a workaround I'm missing? Maybe it's necessary to also enable
>>> the firewall service to trigger application of the source NAT rules?
>>>
>>> Thanks,
>>> Dave.
>>>
>>> [1]
>>>
>>>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=se
>>>rver/src/com/cloud/network/NetworkManagerImpl.java;h=2b53565297dc7bd96c6
>>>102cdc1c90cb166e9e704;hp=dac6a3a42e75324a963997e17e076f4020a7103e;hb=fe5
>>>68fe;hpb=c7f26583a26eb7e4f15feafc292ec9576df61a8d
>>>
>>> On Tue, Jul 9, 2013 at 5:47 PM, Murali Reddy (JIRA)
>>><ji...@apache.org>wrote:
>>>
>>>>
>>>> [
>>>>
>>>>https://issues.apache.org/jira/browse/CLOUDSTACK-234?page=com.atlassian
>>>>.jira.plugin.system.issuetabpanels:all-tabpanel]
>>>>
>>>> Murali Reddy resolved CLOUDSTACK-234.
>>>> -------------------------------------
>>>>
>>>> Resolution: Fixed
>>>>
>>>> > create/delete firewa/lb/pf rule: send ip assoc command only on first
>>>> rule is created on the IP and last rule is revoked on the IP
>>>> >
>>>>
>>>>-----------------------------------------------------------------------
>>>>----------------------------------------------------------
>>>> >
>>>> > Key: CLOUDSTACK-234
>>>> > URL:
>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-234
>>>> > Project: CloudStack
>>>> > Issue Type: Bug
>>>> > Security Level: Public(Anyone can view this level - this is the
>>>> default.)
>>>> > Components: Management Server
>>>> > Affects Versions: 4.0.0
>>>> > Reporter: Alena Prokharchyk
>>>> > Assignee: Murali Reddy
>>>> > Fix For: 4.2.0
>>>> >
>>>> >
>>>> > We have to improve the logic for creating/deleting any kind of
>>>> firewall rules. At the moment ipAssoc is being called when:
>>>> > * the first rule for the ip address is being created
>>>> > * the last rule for the IP address is being removed
>>>> > As a part of ipAssoc command, we send all ip addresses assigned to
>>>>the
>>>> guest network of the rule. The behavior has to be fixed the way we
>>>>send ip
>>>> assoc only for the ip address the rule is being created for.
>>>>
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> If you think it was sent incorrectly, please contact your JIRA
>>>> administrators
>>>> For more information on JIRA, see:
>>>> http://www.atlassian.com/software/jira
>>>>
>>>
>>>
>>
>
Re: Source NAT not applied on network startup (See Jira CLOUDSTACK-234)
Posted by Dave Cahill <dc...@midokura.com>.
Adding Chiradeep for guidance, as Murali seems to be away at the moment.
Prasanna kindly verified that this is an issue with Virtual Router as well
as MidoNet, so I have filed a bug against 4.2:
https://issues.apache.org/jira/browse/CLOUDSTACK-4442
On Thu, Aug 22, 2013 at 12:10 PM, Dave Cahill <dc...@midokura.com> wrote:
> Also, I tried to find the code review for this change, but couldn't track
> it down - could someone point me to it?
>
>
> On Thu, Aug 22, 2013 at 10:26 AM, Dave Cahill <dc...@midokura.com>wrote:
>
>> Hi Murali,
>>
>> After this change [1], how do Source NAT IPs get applied to a network on
>> network startup / first VM launch?
>>
>> Previously, applyIpAssociations would get called as part of
>> reprogramNetworkRules, but this change introduces what it calls "a lazy
>> approach". From what I can see, this means that source NAT doesn't work on
>> startup, and I need to add a Static NAT or some other rule in order to wake
>> up the lazy approach and have the Source NAT + the new rule be applied.
>>
>> Is there a workaround I'm missing? Maybe it's necessary to also enable
>> the firewall service to trigger application of the source NAT rules?
>>
>> Thanks,
>> Dave.
>>
>> [1]
>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=server/src/com/cloud/network/NetworkManagerImpl.java;h=2b53565297dc7bd96c6102cdc1c90cb166e9e704;hp=dac6a3a42e75324a963997e17e076f4020a7103e;hb=fe568fe;hpb=c7f26583a26eb7e4f15feafc292ec9576df61a8d
>>
>> On Tue, Jul 9, 2013 at 5:47 PM, Murali Reddy (JIRA) <ji...@apache.org>wrote:
>>
>>>
>>> [
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>>>
>>> Murali Reddy resolved CLOUDSTACK-234.
>>> -------------------------------------
>>>
>>> Resolution: Fixed
>>>
>>> > create/delete firewa/lb/pf rule: send ip assoc command only on first
>>> rule is created on the IP and last rule is revoked on the IP
>>> >
>>> ---------------------------------------------------------------------------------------------------------------------------------
>>> >
>>> > Key: CLOUDSTACK-234
>>> > URL:
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-234
>>> > Project: CloudStack
>>> > Issue Type: Bug
>>> > Security Level: Public(Anyone can view this level - this is the
>>> default.)
>>> > Components: Management Server
>>> > Affects Versions: 4.0.0
>>> > Reporter: Alena Prokharchyk
>>> > Assignee: Murali Reddy
>>> > Fix For: 4.2.0
>>> >
>>> >
>>> > We have to improve the logic for creating/deleting any kind of
>>> firewall rules. At the moment ipAssoc is being called when:
>>> > * the first rule for the ip address is being created
>>> > * the last rule for the IP address is being removed
>>> > As a part of ipAssoc command, we send all ip addresses assigned to the
>>> guest network of the rule. The behavior has to be fixed the way we send ip
>>> assoc only for the ip address the rule is being created for.
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> If you think it was sent incorrectly, please contact your JIRA
>>> administrators
>>> For more information on JIRA, see:
>>> http://www.atlassian.com/software/jira
>>>
>>
>>
>
Re: Source NAT not applied on network startup (See Jira CLOUDSTACK-234)
Posted by Dave Cahill <dc...@midokura.com>.
Also, I tried to find the code review for this change, but couldn't track
it down - could someone point me to it?
On Thu, Aug 22, 2013 at 10:26 AM, Dave Cahill <dc...@midokura.com> wrote:
> Hi Murali,
>
> After this change [1], how do Source NAT IPs get applied to a network on
> network startup / first VM launch?
>
> Previously, applyIpAssociations would get called as part of
> reprogramNetworkRules, but this change introduces what it calls "a lazy
> approach". From what I can see, this means that source NAT doesn't work on
> startup, and I need to add a Static NAT or some other rule in order to wake
> up the lazy approach and have the Source NAT + the new rule be applied.
>
> Is there a workaround I'm missing? Maybe it's necessary to also enable the
> firewall service to trigger application of the source NAT rules?
>
> Thanks,
> Dave.
>
> [1]
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=server/src/com/cloud/network/NetworkManagerImpl.java;h=2b53565297dc7bd96c6102cdc1c90cb166e9e704;hp=dac6a3a42e75324a963997e17e076f4020a7103e;hb=fe568fe;hpb=c7f26583a26eb7e4f15feafc292ec9576df61a8d
>
> On Tue, Jul 9, 2013 at 5:47 PM, Murali Reddy (JIRA) <ji...@apache.org>wrote:
>
>>
>> [
>> https://issues.apache.org/jira/browse/CLOUDSTACK-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>>
>> Murali Reddy resolved CLOUDSTACK-234.
>> -------------------------------------
>>
>> Resolution: Fixed
>>
>> > create/delete firewa/lb/pf rule: send ip assoc command only on first
>> rule is created on the IP and last rule is revoked on the IP
>> >
>> ---------------------------------------------------------------------------------------------------------------------------------
>> >
>> > Key: CLOUDSTACK-234
>> > URL:
>> https://issues.apache.org/jira/browse/CLOUDSTACK-234
>> > Project: CloudStack
>> > Issue Type: Bug
>> > Security Level: Public(Anyone can view this level - this is the
>> default.)
>> > Components: Management Server
>> > Affects Versions: 4.0.0
>> > Reporter: Alena Prokharchyk
>> > Assignee: Murali Reddy
>> > Fix For: 4.2.0
>> >
>> >
>> > We have to improve the logic for creating/deleting any kind of firewall
>> rules. At the moment ipAssoc is being called when:
>> > * the first rule for the ip address is being created
>> > * the last rule for the IP address is being removed
>> > As a part of ipAssoc command, we send all ip addresses assigned to the
>> guest network of the rule. The behavior has to be fixed the way we send ip
>> assoc only for the ip address the rule is being created for.
>>
>> --
>> This message is automatically generated by JIRA.
>> If you think it was sent incorrectly, please contact your JIRA
>> administrators
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>
>