On Tue, Aug 11, 2009 at 1:16 PM, Michael Goldish<mgoldish@xxxxxxxxxx> wrote: > > ----- "Jason Wang" <jasowang@xxxxxxxxxx> wrote: > >> Hello Michael: >> Based on our experiences with TAP networking scripts, the >> verify_mac_ip_pair() could not work well under multiple nics when >> testing linux guests. The main problem is the policy of multiple >> interfaces responding in linux, we should take care of the value of >> net.ipv4.conf.all.arp_ignore. Its default value(0) may cause the host >> get a mac address that does not configured on the target interface of >> guest. >> Maybe we could run a simple 'setup' case for all linux guests to set >> the value of arp_ignore to 1. >> What's your opinion? Ok, I haven't read this before I finished my review of the patchset. My test was too simplistic and limited to 1 guest with 1 NIC, that's why I saw this. > Thanks for pointing this out. > > You're right, there seems to be a problem with Linux guests (I tried > RHEL 3.9). I started RHEL 3.9 with two NICs. At boot time the guest > got 2 IP addresses and tcpdump collected them properly, but /sbin/arp -n > listed the addresses as though they were both assigned to the MAC address > of the first NIC. It's possible that regardless of the NIC I try to > contact, the reply always comes from eth0, so it seems that both IP > addresses have the same MAC address. > > I don't think we should solve this by messing with the guest, because > different guests may require different hackish solutions. I think it's > better to fix the test framework instead. > The solution you suggested may not work for all Linux guests -- for > example, on RHEL 3.9 I couldn't find net.ipv4.conf.all.arp_ignore, or any > arp_ignore. (I did find arp_filter and arp_announce though, and none of > them helped solve the problem.) > > I'm considering 2 solutions: > > 1. Do not require the MAC address reported by 'arp -n' to be assigned to > the NIC we are 'verifiying' -- require it to be assigned to any NIC of > the guest. This will probably work in all cases. This already would give us a certain degree of security that we are talking to who we are planning to. Not sure if we should bother though. > 2. Stop using verify_mac_ip_pair() altogether. Instead, when destroying > a VM, remove the MAC addresses of its NICs from the address cache. > Also, when starting a new test, check each address in the cache and > make sure it belongs to some living VM, and otherwise remove it. > This should work in most cases, but _theoretically_ a guest might > release its IP address during a test, and then the DHCP server might > assign the same IP address to some other machine, so when we try > talking to our guest using that IP address, we'll end up talking to > the other machine. That's exactly the sort of situation > verify_mac_ip_pair() was meant to prevent, but this situation sounds so > unlikely to occur, that it might be safe to use this proposed solution. I also think this is an unlikely situation, unless we are going to write tests that involve the guest explicitly releasing the IP address at some point of the test. So the minimalist in me would go for 2). -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
