>>This model is also used by openvz venet, so this is well known, and should
>>work with
>>migration. I don’t see how live migration works if you hardcode a gateway?
it's not working.(unless you can dynamicaly change routes on routes, with a
protocol like rip,ospf,bgp,...)
But on public internet,hosting provider have always external router with
hardcoded routes to proxmox host.
So arp proxy will not help, as the external router route the packet to proxmox
host, without doing an arp request
client--->external router----->proxmox host----->guest
Also, I'm not sure that provider will not block on switchs packets with wrong
"macadress(host)-ip(guest)', seeing this like spoofing.
----- Mail original -----
De: "Dietmar Maurer" <[email protected]>
À: "Alexandre DERUMIER" <[email protected]>
Cc: [email protected]
Envoyé: Mardi 27 Août 2013 07:41:38
Objet: RE: [PATCH] add routed network mode
> In your setup, you need proxy-arp on host interface because you don't have
> the route on the client or between the client and the target network, so you
> need arpproxy on host to trick.
> But for me, this kind of setup is not real "routing", It's more like a
> pseudo-
> bridge with arp tricks.
This model is also used by openvz venet, so this is well known, and should work
with
migration. I don’t see how live migration works if you hardcode a gateway?
The openvz code does something like this to setup the interface:
---------
my $external_iface = 'vmbr0'; # fixme: autotetect?
# add entry to local ARP cache
my $cmd = "ip neigh add proxy $net->{ip} dev ${external_iface}";
PVE::Tools::run_command($cmd);
# Send ARP request to update neighbour ARP caches
$cmd = "arpsend -c 1 -w 1 -U -i $net->{ip} -e $net->{ip} ${external_iface}";
PVE::Tools::run_command($cmd);
--------
So we only need to set proxyarp on the tap device.
_______________________________________________
pve-devel mailing list
[email protected]
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
