At 08:09 AM 7/24/2006, Marko Zec wrote:
Yes this should work with a virtualized stack - all the "outsied" interfaces in each jail / virtual stack could be simply bridged together using netgraph which is virtualization-agnostic, i.e. a global facility in the current implementation of "vimage".
Does this virtualization facility virtualize the arp table? It would need to, because there would be hosts with duplicate addresses inside each interface.
I've been noodling over this for two weeks now, and am thinking that the easiest thing to do might be is map every address in each "virtual" router to a unique address from FreeBSD's point of view (i.e. 192.168.0.2 on LAN 1 becomes 10.0.0.2, while 192.168.0.2 on LAN 1 becomes 10.0.1.2, etc.). The translation would be done by "hooks" as close as possible to the interfaces, so FreeBSD's stack wouldn't know it was being done.
All that would be needed in that case would be to do "dumb" address translation at the interfaces -- transparently to FreeBSD -- just before the packets entered and left. This seems to be the method that would leverage FreeBSD's existing facilities the most, since FreeBSD's own routing, NAT, etc. would "just work" as they always do. I'd need to figure out what to do about protocols like DHCP.... I don't know if DHCP will assign addresses that it are not on the subnet it "thinks" it's talking to. And I might need to hack into the content of some packets. For example, I'd have to make ARP work.
If I were to try this, the question would of course be which "hook" to use to capture the packets (BPF? Divert sockets? Netgraph? Something in IPFW? A hook into the driver?)... and whether I could use existing code to do the bilateral translation or would have to hack an "address smasher".
--Brett Glass _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
