You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Sebastian Gomez <ti...@gmail.com> on 2017/06/09 07:02:38 UTC
Cloudstack 4.9.2, Error on routes on systemvm
Hi all,
We are trying to upgrade our PRE environment from 4.5.2 to 4.9.2.0 to check
the behaviour and apply on our production environment.
I have noticed two problems on the new installation, one of them is that I
can't access the VMs console via the console proxy VM (the other will
arrive on other request ;)
Analyzing the problem I noticed that a new routes are added on systemvm,
for private networks:
root@s-262-VM:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
0.0.0.0 147.148.149.225 0.0.0.0 UG 0 0 0
eth2
*10.0.0.0 192.168.100.2 255.0.0.0 UG 0 0 0
eth1*
147.148.149.224 0.0.0.0 255.255.255.224 U 0 0 0
eth2
*172.16.0.0 192.168.100.2 255.240.0.0 UG 0 0 0
eth1*
*192.168.0.0 192.168.100.2 255.255.0.0 UG 0 0 0
eth1*
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.101.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3
(Public IPs are not real)
And searching into the systemvm scripts I realized that there is a script
"/etc/init.d/*cloud-early-config*" which is responsible of those new
routes, and more concretely, on the funciont
"setup_system_rfc1918_internal", that is called when setting the Console
proxy and Secondary Storage VM.
setup_system_rfc1918_internal() {
public_ip=`getPublicIp`
* echo "$public_ip" | grep -E
"^((127\.)|(10\.)|(172\.1[6-9]\.)|(172\.2[0-9]\.)|(172\.3[0-1]\.)|(192\.168\.))"*
if [ "$?" == "0" ]; then
log_it "Not setting up route of RFC1918 space to $LOCAL_GW befause
$public_ip is RFC1918."
else
log_it "Setting up route of RFC1918 space to $LOCAL_GW"
# Setup general route for RFC 1918 space, as otherwise it will be sent
to
# the public gateway and not work
# More specific routes that may be set have preference over this
generic route.
ip route add 10.0.0.0/8 via $LOCAL_GW
ip route add 172.16.0.0/12 via $LOCAL_GW
ip route add 192.168.0.0/16 via $LOCAL_GW
fi
}
The problem on our environment is that we use real public IPs for public
network, but we use private addresses for internal use (10.x.0.0/16). In
this case, the "if" statement will enter into the "else" block, and the
private routes are added, one of them is 10.0.0.0/8, that includes our
private "public" network (10.x.0.0/16).
When I try to access the VM console, the console proxy is redirecting my
network traffic through the management network, and in consecuense I can't
reach the console due the routing rule:
10.0.0.0 192.168.100.2 255.0.0.0 UG 0 0 0 eth1
Dones anyone know how to avoid this behaviour?
Thanks in advanced.
Best regards,
Sebastián Gómez