[rhos-list] Nova-network woes

[Brent Eagles]

Hi Kashif,

On Wed, Mar 20, 2013 at 05:23:16PM +0000, Kashif Mohammad wrote:
> 
> Hi Guys
> 
> I am using rhel6.4 and RedHat Openstack Folsom rpms. I have  one
> controller node which is running glance, cinder, scheduler, api
> server, consoleauth and other node is running compute, network and
> api. Both nodes have one public and one private IP and running in
> multi_host mode.
> 
> I am not running nova-network and nova-compute on controller node.
> Network bit is like this on compute node
> 
> public_interface = em1
> flat_interface = em2
> fixed_range = 10.0.1.0/24
> flat_network_dhcp_start = 10.0.1.5
> connection_type = libvirt
> flat_injected = False
> multi_host = True
> flat_network_bridge = br100
> 
> created network like this
> nova-manage network create private 10.0.1.0/24 1 256 --bridge=br100 --multi_host=True

I would try running nova-manage using the keyword=value approach instead
of relying on positional arguments (e.g.  --fixed_range_ipv4=10.0.1.0/24). 
It would avoid issues with getting the order wrong which can lead to
surprising results.

> I can create VM through dashboard and initially it couldn't get ip
> address from dhcp server running on compute node but after adding 
> 
> iptables -A POSTROUTING -t mangle -p udp --dport 68 -j CHECKSUM --checksum-fill

Mmmm.. if everything is configured properly, you shouldn't have to
modify the firewall rules for this to work. Was there something you came
across while debugging your setup that gave you the idea to add this?

> it is getting ip address and I can log in into vm from compute node.
> It can reach metadata server and grab public keys.  My problem is that
> VM's can not access outside word. I think that issue is in this line
> of iptable
> 
> 47  3247 nova-network-float-snat  all  --  any    any     anywhere             anywhere
>     2   168 SNAT       all  --  any    em1     10.0.1.0/24          anywhere            to:192.168.9.3
> 
> It is changing source IP address to local ip rather than external ip. If insert a rule
>
> iptables -t nat -I nova-network-snat 2 -o em1 -j SNAT --to-source 163.1.5.40 

That's weird. Can you describe how you configured and allocated the floating IPs? This
is another thing that generally just works.

> Then it vm can access interner but the moment I create a new VM this line disappear from iptable.
> 
> My n/w setting is like this
> 
> 2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
>     link/ether 00:22:19:6a:bc:09 brd ff:ff:ff:ff:ff:ff
>     inet 163.1.5.40/24 brd 163.1.5.255 scope global em1
>     inet6 fe80::222:19ff:fe6a:bc09/64 scope link
>        valid_lft forever preferred_lft forever
> 3: em2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
>     link/ether 00:22:19:6a:bc:0b brd ff:ff:ff:ff:ff:ff
>     inet6 fe80::222:19ff:fe6a:bc0b/64 scope link
>        valid_lft forever preferred_lft forever
> 5:  br100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
>     link/ether 00:22:19:6a:bc:0b brd ff:ff:ff:ff:ff:ff
>     inet 10.0.1.1/24 brd 10.0.1.255 scope global br100
>     inet 192.168.9.3/24 brd 192.168.9.255 scope global br100
>     inet6 fe80::80cd:6fff:fef7:d955/64 scope link
>        valid_lft forever preferred_lft forever
> 
> I can not reach vnc as well but I first fix this n/w issue and then look into vnc.
> 
> Thanks
> Kashif 

Heh. No VNC? It is the one thing you should *not* live without! I would
say that something got crossed during configuration. You might want to
"back up" to the beginning and try each thing in turn. If the "cookbook"
type instructions didn't work as described, it might be best to figure
out why instead of tweaking until things just kind of work. As one bit
of configuration tends to depend on another, if the most fundamental
thing does not work properly (e.g.  allocating a private IP to a VM) it
is very possible that things are going to go awry with other
configuration items (e.g. allocating floating IPs). 

However, instead of just leaving with you a note to "try again", and it
is just a thought/guess, but if iptables is giving you grief and you
have a pre-existing firewall configuration, you might want to look for
rules that might interfere with what openstack is trying to do.  What I
have done in the past when trying a new configuration is take a snapshot
of the current configuration with iptables-save (e.g.  iptables-save >
iptables.before) and again when everything is "done" (iptables.after?)
and visually compare the two. It is useful pedagogically because I see
what Openstack is doing and it helps identify configuration (and
sometimes bugs!) before I go too far.

Cheers,

Brent