Open Stack

Two ways that I can think of...

1) disable forwarding on the NC, not sure if this would impact regular services.
2) add additional rules, something like "-s 10.10.10.0/24 -d 10.0.0.0/8 drop".

-Simon

On Mon, Jul 30, 2012 at 4:34 AM, Wael Ghandour (wghandou)
<wghandou at cisco.com> wrote:
>
> We are also seeing another issue:
>
> VMs belonging to different tenants are supposed to be isolated from each
> other, except if they have public IPs that are made accessible.
>
> What I'm seeing now however is that VMs belonging to different tenants, but
> running on the same physical host, are able to communicate to each other via
> their private IPs.
>
> Has anyone faced this issue before?
>
>
> Regards,
>
> Wael
>
>
>
> On Jul 21, 2012, at 5:36 AM, Xu (Simon) Chen <xchenum at gmail.com> wrote:
>
> Here is what happened on a different thread:
> http://buriedlede.blogspot.com/2012/07/debugging-networking-problems-with.html
>
> I feel that using this might solve your issue too without changing iptables
> drivers...
>
> On Fri, Jul 20, 2012 at 12:58 PM, Wael Ghandour (wghandou)
> <wghandou at cisco.com> wrote:
>>
>>
>> Yup, that has definitely helped, thanks a bunch Xu.
>>
>>
>> Regards,
>>
>> Wael
>>
>>
>>
>> On Jul 20, 2012, at 8:09 AM, Xu (Simon) Chen wrote:
>>
>> Yes, one solution is to modify the iptables driver, so that you don't SNAT
>> for internal subnets...
>>
>> So, at the beginning of the nova-network-floating-snat rules, you add
>> something like this:
>> -A nova-network-floating-snat -s 10.0.0.0/24 -d 10.0.0.0/24 -j ACCEPT
>> ...
>> -A nova-network-floating-snat -s 10.0.88.16/32 -j SNAT --to-source pub1
>> -A nova-network-floating-snat -s 10.0.16.7/32 -j SNAT --to-source pub2
>> -A nova-network-floating-snat -s 10.0.4.11/32 -j SNAT --to-source pub3
>>
>> Then it should solve the unnecessary NATting issue...
>>
>> On Fri, Jul 20, 2012 at 10:13 AM, Wael Ghandour (wghandou)
>> <wghandou at cisco.com> wrote:
>>>
>>>
>>> I can confirm that the VM traffic is undergoing NAT with using its
>>> floating IP on the private interface of the nova-compute node when it tries
>>> to reach the private address of the VMs belonging to the same tenant and on
>>> other compute nodes. That obviously is breaking internal connectivity....
>>>
>>>
>>> Regards,
>>>
>>> Wael
>>>
>>>
>>>
>>> On Jul 20, 2012, at 5:42 AM, Xu (Simon) Chen wrote:
>>>
>>> There was an issue that we saw in an earlier nova-network...
>>>
>>> Due to multi_host configuration, the nova-network runs on every
>>> nova-compute node. Therefore the floating IP assignment happens on the
>>> compute nodes directly. So between two VMs within the same tenant on
>>> different hosts, private->public SNAT happens unnecessarily.
>>>
>>> Not sure if this is fixed in Essex...
>>>
>>> On Fri, Jul 20, 2012 at 3:49 AM, Edgar Magana (eperdomo)
>>> <eperdomo at cisco.com> wrote:
>>>>
>>>> Folks,
>>>>
>>>>
>>>>
>>>> We are using Essex for our multi-host OpenStack deployment with Vlan
>>>> Manager.
>>>>
>>>> All the private IPs are working as expected in a multi-tenant scenario
>>>> but the problem that we are seen is with Floating IPs.
>>>>
>>>>
>>>>
>>>> We have three tenants,  all of them are able to use  Floating IPs and
>>>> then VMs are reachable from the public network but the inter VMs
>>>> connectivity by private IPs is totally lost. Once we dissociate the Floating
>>>> IPs to the corresponding VMs, the connectivity is back. The odd part is that
>>>> we are seeing this behavior in just two of the three tenants that we have
>>>> tested so far.
>>>>
>>>>
>>>>
>>>> Is anyone aware of any bug or misconfiguration in Nova-network that
>>>> could explain this behavior? We will be running more tests and we can
>>>> provide detailed information of our environment if needed.
>>>>
>>>>
>>>>
>>>> Thanks for your help,
>>>>
>>>>
>>>>
>>>> Edgar
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to     : openstack at lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>
>>>
>>
>>
>
>