Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
References: <0A739147-99A4-4382-A66B-3E03A45478C1@kelceydamage.com>
 <67EF18FDCA335F489B366120481AB6C5EE3BB5FE17@BANPMAILBOX01.citrite.net>
In-Reply-To: 
 <67EF18FDCA335F489B366120481AB6C5EE3BB5FE17@BANPMAILBOX01.citrite.net>
Mime-Version: 1.0 (1.0)
Content-Type: text/plain;
	charset=us-ascii
Message-Id: <C08B247B-4FC1-44EA-8216-0B9F8426C1DF@bbits.ca>
Content-Transfer-Encoding: quoted-printable
From: "Kelceydamage@bbits" <kelcey@bbits.ca>
Subject: Re: Virtual Routers and ARP handling
Date: Thu, 9 Aug 2012 08:54:18 -0700
To: "cloudstack-dev@incubator.apache.org"
 <cloudstack-dev@incubator.apache.org>

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 o=
nly 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.bud=
umuru@citrix.com> wrote:

> First question I have is : how often your gateway cluster results in unsol=
icited ARP broadcast i.e. how quickly the gateway is moving ?
>=20
> -----Original Message-----
> From: Kelcey Damage [mailto:me@kelceydamage.com]=20
> Sent: Thursday, August 09, 2012 12:15 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Virtual Routers and ARP handling
>=20
> 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.=20
>=20
> This makes them loose connectivity if they live behind a perimeter firewal=
l cluster running floating IPs for gateway addresses (for example: Conntrack=
, CRM/Pacemaker, VRRP).  Any vm using a shared network connection to the flo=
ating gateway has no issues, but isolated networks requiring the VR to be an=
 initial gateway will loose connectivity as the Debian VR aggressively flush=
es its ARP cache.=20
>=20
> You can even watch connections stop then start when the gateway cluster se=
nds its unsolicited ARP broadcasts, and then within a few seconds, stop agai=
n.
>=20
> Can we look into this?
>=20
> My setup is below
>=20
> Gateway cluster running:=20
> 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=
)
>=20
> *No issues connecting VMs directly to the gateway cluster with shared netw=
orks(VLAN)
>=20
> *connection issues when using isolated networks routed through VR to gatew=
ay cluster
>=20
> -kelcey
>=20
> Sent from my iPhone
>=20
>=20