Hi Matthew, We added a storage network in 3.0.2, which is used for SSVM to access secondary storage. The issue you saw is introduced by this, which happens only when private network and storage network are using the same sub net. It is harmless, because the NIC for storage network is not used. I assume the new NIC is eth3, eth2 is the default gateway, route for eth2 is before route for eth3, so eth3 is never used in your case.
You don't need any work around for this. But this is a bug, please file a bug for it. Thanks, Anthony > -----Original Message----- > From: Matthew Hartmann [mailto:mhartm...@tls.net] > Sent: Monday, June 18, 2012 5:45 AM > To: cloudstack-dev@incubator.apache.org > Subject: Re: Advice on SSVM network interfaces > > On 6/15/2012 2:59 PM, Anthony Xu wrote: > > Hi Salvatore, > > > > > From your description, the ARP response is sent out through eth1, > some switches may drop this kind of package, it expects to receive ARP > response from the same port ARP request sent out. > > > > I think it is a bug, in this case, CloudStack should not configure > eth2 and eth3 for SSVM, if SSVM does need several IPs, all IPs should > be configured on eth1 if they are in the same subnet. > > > > > > > > Regards, > > Anthony > > I'm not experiencing any ARP issues, but I wanted to comment that I too > noticed my SSVM has two private management network IP's. This started > when I upgraded from CS 3.0.1 to CS 3.0.2. If this is a bug, is there a > temporary work around so that I can ifdown the superfluous eth device > and release the IP in the cloud database? > > Thanks! > > Matthew
