warren at wangspeed
Jun 29, 2012, 9:29 AM
Post #3 of 7
(777 views)
Permalink
|
|
Re: VMs not reachable through public floating IPs
[In reply to]
|
|
Funny you mention this. Looks like we ran into a similar problem, assuming
no security group issues. Can you just try, as a temporary fix, to add a
route to a destination host that you want to reach? This would be from the
controller to guarantee that you have a non-circular route. In your case,
you want all VM traffic to use eth2 on the controller, but right now you
probably see packets leaving from eth0, and coming back in eth2.
Until we figure out what's going on with internal routing/iptables issues,
add a test route:
route add -host <some test ip> gw 85.254.50.254 dev eth2
I'm making the assumption that .254 is your general router IP, based on
your default route. Adding the route has other implications, so I hope
someone has a better answer :)
Good luck,
Warren
On Fri, Jun 29, 2012 at 11:08 AM, Jānis Ģeņģeris
<janis.gengeris [at] gmail>wrote:
> Hi all,
>
> After exhaustive experiments and searches I'm writing this mail with great
> hopes.
>
> The setup:
> I have dual node Essex setup(controller and compute node) on Ubuntu 12.04.
> Controller node hosts various different nova services, including
> nova-network, except nova-compute. The only difference from the official
> docs is that public floating IP subnet is configured on different interface
> than servers public interface. That means on controller I have the
> following interfaces set up:
>
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> inet 169.254.169.254/32 scope link lo
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> UP qlen 1000
> link/ether 00:16:3e:2b:ee:ff brd ff:ff:ff:ff:ff:ff
> inet 85.254.49.85/24 brd 85.254.49.255 scope global eth0
> inet6 fe80::216:3eff:fe2b:eeff/64 scope link
> valid_lft forever preferred_lft forever
> 3: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
> pfifo_fast master br100 state UP qlen 1000
> link/ether 00:16:3e:2b:cc:aa brd ff:ff:ff:ff:ff:ff
> inet6 fe80::216:3eff:fe2b:ccaa/64 scope link
> valid_lft forever preferred_lft forever
> 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> UP qlen 1000
> link/ether 00:16:3e:2b:dd:aa brd ff:ff:ff:ff:ff:ff
> inet 85.254.50.1/24 scope global eth2
> inet 85.254.50.1/32 scope global eth2
> 7: br100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
> UP
> link/ether 00:16:3e:2b:cc:aa brd ff:ff:ff:ff:ff:ff
> inet 192.168.4.1/24 brd 192.168.4.255 scope global br100
> inet 192.168.1.1/24 brd 192.168.1.255 scope global br100
> inet6 fe80::216:3eff:fe2b:ccaa/64 scope link
> valid_lft forever preferred_lft forever
>
>
> eth0 - main network connection
> eth1 - bridged interface from br100
> eth2 - public internet interface for VMs (NATted to VM network)
>
> 85.254.50.0/24 - public floating IP pool
> 192.168.4.0/ <http://192.168.4.1/27>24 - fixed IP pool
>
> routes on controller:
> Kernel IP routing table
> Destination Gateway Genmask Flags MSS Window irtt
> Iface
> 0.0.0.0 85.254.49.254 0.0.0.0 UG 0 0 0
> eth0
> 85.254.49.0 0.0.0.0 255.255.255.0 U 0 0 0
> eth0
> 85.254.50.0 0.0.0.0 255.255.255.0 U 0 0 0
> eth2
> 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0
> br100
> 192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0
> br100
>
> net.ipv4.ip_forward = 1 on both nodes
>
> Compute node runs only nova-compute, using libvirt with kvm. VMs can be
> spawned from Horizon dashboard without any problems, and they get fixed and
> also floating IPs assigned to them.
>
> The problem:
> When trying to connect from public network to assigned floating IP (eg.
> 85.254.50.1), connection fails, but tcpdump on eth2 interface shows that
> packets come in. Also when tracing iptables, I can see that incoming
> packets are being matches against DNAT rules and then nothing happens next.
> Direct connections from controller to VMs private address (192.168.4.x)
> work fine.
>
> I also tried changing net.bridge.bridge-nf-call-iptables to 0 on
> controller, same problem remained.
>
>
> Can you give any clues if the setup is correct and what might be causing
> this problem?
>
> Regards,
> --janis
>
> _______________________________________________
> Openstack-operators mailing list
> Openstack-operators [at] lists
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
|
