No luck. There is only a single host(router) that is on the same network(VLAN) as the VR.
I have zero issues with centOS hosts acting as VRs. Only the built in VR does this. Messages is clean. I am still scratching my head in this one. It seams build specific to the built-in VR. I will try and deploy a debian guest alongside the centOS ones and see if it has the same issue, at least that might prove out the distrobution. Then I can focus on the build scripts. Sent from my iPhone On Aug 12, 2012, at 10:37 PM, Chiradeep Vittal <chiradeep.vit...@citrix.com> wrote: > Anything in /var/log/messages at all? > Does this link help: > http://www.serveradminblog.com/2011/02/neighbour-table-overflow-sysctl-conf > -tunning/ > > > On 8/9/12 8:54 AM, "Kelceydamage@bbits" <kel...@bbits.ca> wrote: > >> Not often at all. I simply set the unsolicited requests to 30s to prove >> out. default is os default centos 6.2. >> >> All the IPs share the same MAC and the gateway should not be "moving". >> >> Again, no issues from a centos guest using it directly as a gateway. >> Issues only when the VR is using it as a gateway. >> >> Sent from my iPhone >> >> On Aug 9, 2012, at 1:10 AM, Venkata SwamyBabu Budumuru >> <venkataswamybabu.budum...@citrix.com> wrote: >> >>> First question I have is : how often your gateway cluster results in >>> unsolicited ARP broadcast i.e. how quickly the gateway is moving ? >>> >>> -----Original Message----- >>> From: Kelcey Damage [mailto:m...@kelceydamage.com] >>> Sent: Thursday, August 09, 2012 12:15 PM >>> To: cloudstack-dev@incubator.apache.org >>> Subject: Virtual Routers and ARP handling >>> >>> Not sure if this is a bug, but I have found in testing the Virtual >>> Routers dump their arp cash almost every 5-10 seconds. >>> >>> This makes them loose connectivity if they live behind a perimeter >>> firewall cluster running floating IPs for gateway addresses (for >>> example: Conntrack, CRM/Pacemaker, VRRP). Any vm using a shared network >>> connection to the floating gateway has no issues, but isolated networks >>> requiring the VR to be an initial gateway will loose connectivity as the >>> Debian VR aggressively flushes its ARP cache. >>> >>> You can even watch connections stop then start when the gateway cluster >>> sends its unsolicited ARP broadcasts, and then within a few seconds, >>> stop again. >>> >>> Can we look into this? >>> >>> My setup is below >>> >>> Gateway cluster running: >>> 4 floating IPs on eth4 (Cloud public network gateways, 1 per zone, all >>> VRs point to these) >>> 36 floating IPs on eth0 (SNAT addresses into cloud) >>> 2 floating IPs on eth1 (Management Gateways) HB on eth2 (Cluster >>> heartbeat) >>> >>> *No issues connecting VMs directly to the gateway cluster with shared >>> networks(VLAN) >>> >>> *connection issues when using isolated networks routed through VR to >>> gateway cluster >>> >>> -kelcey >>> >>> Sent from my iPhone >>> >>> >
