Open Stack

We us a external vm network of 10.36.6.0/23.  Looks like I do have some
snat rules but no idea what I should be specifically looking for in here:

$ ip netns | grep -i snat
snat-9e849e49-ed36-4280-a53c-47d6f5afbea2
snat-716dc7bd-9d6b-41da-aa6a-a484398785b1
snat-bece0591-c55b-4a48-bc2b-77873a3ebce1
snat-803e06a4-4499-4ce0-bda6-fb158e717b9e
snat-6e4669f9-0b63-4b60-bdf6-94037b4c1e23


$ sudo ip netns exec snat-9e849e49-ed36-4280-a53c-47d6f5afbea2 ip a | grep
"inet"
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
    inet 192.168.5.4/24 brd 192.168.5.255 scope global sg-86abc456-8d
    inet6 fe80::f816:3eff:fe23:7166/64 scope link
    inet 10.36.6.240/23 brd 10.36.7.255 scope global qg-09e400d1-28
    inet6 fe80::f816:3eff:fe52:dc9a/64 scope link


$ sudo ip netns exec snat-bece0591-c55b-4a48-bc2b-77873a3ebce1 ip a | grep
"inet"
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
    inet 192.168.8.4/24 brd 192.168.8.255 scope global sg-ec9b41fe-3b
    inet6 fe80::f816:3eff:feb5:a225/64 scope link
    inet 10.36.6.79/23 brd 10.36.7.255 scope global qg-b1f38a3f-0b
    inet6 fe80::f816:3eff:fe4b:4a1e/64 scope link

On Mon, May 2, 2016 at 10:09 PM, Remo Mattei <remo at italy1.com> wrote:

> not sure how you build your public network.. but usually it does not do
> dhcp. So those are details that are needed in order for us to give you
> solutions / options / checking etc based on what you are running, how it
> was configured etc..
>
> CentOS, Ubuntu, scripting just as an example..
>
> Remo
>
> On May 2, 2016, at 22:02, Jagga <jagga13 at gmail.com> wrote:
>
> That is what I thought but it does not seem to be working this way.  How
> would I check our snat namespace and what specifically should I be looking
> for?  My apologies but am very new to openstack.
>
> Thanks.
>
>
> On May 2, 2016, at 9:51 PM, Dileep Varma Bairraju <varma123 at gmail.com>
> wrote:
>
> Hi Jagga,
>
> I don't think that's the right approach.Floating ip will effectively do a
> 1:1 NAT for a given a vm to reach external resources. But, there should be
> a ip from the external network that gets assigned to SNAT namespace on
> network node, this effectively will let all vm's (without floating ip)
> access external resources.
>
> I'd suggest you check at your snat namespace for possible issues, as you
> seem to have patched the problem for that vm with floating ip's.
>
> > Is that by design or is there something wrong with our configuration?
> As per design, you don't need to assign floating ip's for your vm's to get
> out, this should be done by SNAT by default as mentioned earlier, where all
> the vm's internal ip space maps one external ip.
>
> Regards,
> Dileep
>
> On Mon, May 2, 2016 at 8:32 PM, Jagga Soorma <jagga13 at gmail.com> wrote:
>
>> Hi Guys,
>>
>> Need some clarification regarding routing for instances without a
>> floating ip address. Basically we have instances connected to a priv
>> network that is also connected to our external network and our security
>> group allows all egress traffic. However, we can't seem to get to any
>> resource on our external network till a floating ip address is assigned.
>> Once we assign a floating ip address we can get out.  Is that by design or
>> is there something wrong with our configuration?
>>
>> Thanks.
>>
>> _______________________________________________
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>>
>
>
> --
> Regards,
> Dileep V Bairraju
>
> !DSPAM:1,572831b2317776163816806!
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
> !DSPAM:1,572831b2317776163816806!
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160502/fe108b37/attachment.html>