[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Setting routes for routed setup
> > I'm still trying to get a routed setup to work (the data centre
> > infrastructure does not let me do bridged). The problem I currently
> > have is that I'm unsure how to set up the routes. The Linux scripts
> > would set up routes like
> > ip route add 184.108.40.206 dev xvif1.0 src 220.127.116.11
> > where 18.104.22.168 is the address of the domU and 22.214.171.124 the address of
> > the dom0. On Linux the dom0 would sit in a netmask 255.255.255.255
> > and have the main IP address assigned to both the physical
> > interface and xvif1.0. Then the host routes between the physical
> > interface and xvif1.0 make sense. Should this be done on NetBSD,
> > too? Or is there a better way of handling this?
> This is a strange setup. It looks like linux uses the xvif interface
> like a point to point interface, while it emulates an ethernet one.
> I'm not sure how this would work on NetBSD. A better way would
> probably to have all the domUs in the same netmask, and assing the
> dom0 one IP address in this netmask on a virtual interface (e.g. a
> tap0 created for this purpose), distinct from the IP/netmask of the
> hardware interface. Then you bridge all the domUs and tap0 in the
> same ethernet domain, and route between tap0 and the hardware
I've been thinking about this and I do agree with you. This setup is
rather strange. However, there is an advantage to it, that I actually
like. If you use a bridge behind an internal route (as with the tap0
device), all traffic to a virtual machines is visible to all other
virtual machines. Now, you could use more than one bridge but then you
end up with host routes again as with the setup used on Linux.
While the setup is really messy on Linux, it seems the only way of
achieving a full separation between the VMs. Every machine only
receives only the traffic intended for it. That is in fact a very neat
feature that I would love to have.
> Other setups involving ipf/ipnat are probably possible, but that would
> require some experiments.
I don't want to use NAT because for one I have enough IP addresses to
not need it and I might run the same service on more than one VM.
Main Index |
Thread Index |