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).
I prefer 1) than 2) because:
It could do some verficiation and should work well under all conditions.
Tests who want to test the function of multiple nics could change the
policy by themselves.
I don't know whether 2) would could work well under all kinds of dhcp
server ( consider rebooting , restarting of network or dhcp nack) and
all conditions.
--
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
