incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Musayev, Ilya" <imusa...@webmd.net>
Subject RouterVM bug fix patch - PLS DISCUSS
Date Wed, 05 Dec 2012 19:37:30 GMT
I've previously started few threads on router vm issue. After the reboot of Router VM, the
link local IP could not be reached until we initiate a ping request from within the Router
VM. This inturn creates an ARP entry and network is functional from then on.


You can see the details of my setup under this tutorial.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Advanced+Network+Tutorial+-+Step+by+Step


Example setup - I have 2 network - Link Local is untagged and Guest Network uses VLAN Tagging:

Guest Network: 10.18.24.0/23
Guest Network GW: 10.18.24.1
Guest Router IP: 10.18.24.20

Link Local Network: 10.12.34.0/24
Link Local GW: 10.12.34.1
Link Local Router IP: 10.12.34.30


CloudStack Net: 10.15.32.0/23
CloudStack Net GW: 10.15.32.1
CloudStack IP: 10.15.32.141


When router VM powers up, based on variables that are passed via /var/cache/cloud/cmdline,
the key variables for this patch are:
*Localgw=10.12.34.1
*Gateway=10.18.24.1
*Mgmtcidr=10.15.32.0/23

With one of somewhat recent patches you will notice that Router VM will ping the Localgw and
Geteway variables. This may fix some issue with local routing - however my CS Host and gateway
is 2 hops away and therefore - the ARP table is not populated completely for inbound communication
to function properly. Outbound from the RouterVM communication is fine.

My proposed fix is to do a 2 second ping count to a new variable MGMTGW, derived via:
MGMTGW=$(echo $Mgtmcidr | awk -F "." '{print $1"."$2"."$3"."1}'

This will generate the gateway of CloudStack Net GW - however there is an assumption that
your gateway always ends with ".1" - which is probably typical 97%.

Even is the ping to gateway fails because its not set to ".1", in theory - the ARP table should
be populated with proper MAC addresses and INBOUND communication should be functional after
a 2 hop ping.

The worst case user will get is a 2 second delay even if ping fails - no harm - so it's a
very low risk solution.

Please let me know if the proposed solution is acceptable, if so - I will push a patch into
JIRA.

Thanks
ilya

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message