Why and how fake ARP works: Difference between revisions
From Xen
Jump to navigationJump to search
Lars.kurth (talk | contribs) (Migrated page) |
Lars.kurth (talk | contribs) mNo edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 4: | Line 4: | ||
<!-- Page revision: 00000004 --> |
<!-- Page revision: 00000004 --> |
||
<!-- Original date: Mon Aug 10 01:47:39 2009 (1249868859000000) --> |
<!-- Original date: Mon Aug 10 01:47:39 2009 (1249868859000000) --> |
||
'''Why and how fake ARP works?''' |
|||
<!-- ! TOC here --> |
<!-- ! TOC here --> |
||
| Line 16: | Line 14: | ||
[[Image:FakeArp$fake_arp.png]] |
[[Image:FakeArp$fake_arp.png]] |
||
[[Media:FakeArp$fake_arp.dia]] |
|||
= How? = |
= How? = |
||
Latest revision as of 11:29, 4 May 2012
netfront driver should send a fake arp package to encourage switches to learn the MAC. This wiki page will show you why should we do that and how to get it.
Why?
This feature is mainly for live migration. In the following example, if the VM migrated from Server 1 to Server 2, Switch 1 still forward ICMP packages from Workstation 1 to Switch 2; until a ARP timeout (may take long time) in Switch 1 or the VM send some package out.
How?
We force the netfront drive to send a fake ARP package on every initializing time. Then all the switches will be flushed about the MAC <-> Port association.
The fake ARP package detail:
| HTYPE |
| PTYPE |
| HLEN |
| PLEN |
| OPER |
| SHA |
| SPA |
| THA |
| TPA |
The Ethernet transmission layer header:
| dst_hw |
| src_hw |
| type |
TODO?
- This feature is not implemented in the upstream linux kernel (which is using pv_ops): http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=drivers/net/xen-netfront.c;hb=HEAD (as of 20090703)
- For HVM guest using the ioemued vif, the solution is already in qemu upstream. So xen 3.4+ doesn't have this issue.
