[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] Network Interface Problems for DomU Firewall
> On Wed, Jul 29, 2009 at 5:24 AM, Thomas > Jensen<tom.jensen@xxxxxxxxxxxxxxxxxxxxxx> wrote: >> I changed the DomU configuration file to use the vif=[''] line. > > Actually I don't recommend using empty vif line, as it would assign > MAC address dynamically on every boot. You should give it a static > MAC. > >> The DomU >> started fine. I checked the results of ifconfig after the initial boot >> and >> the interfaces were still opposite of what they should be (i.e. eth1 >> should >> be eth0, eth0 should be eth1). > > This would be domU OS issue, not Xen issue. On RHEL/Centos I can have > something like HWADDR on /etc/sysconfig/network-scripts/ifcfg-eth0 to > bind a device name (eth0, eth1) to a NIC with a particular MAC. Not > sure how to do it on Lenny though. > I agree that this is a DomU OS issue. On my physical installations of Debian Lenny, there is always a file /etc/udev/rules.d/70-persistent-net.rules where a user can assign interfaces based upon MAC addresses. However, this file does not exist in my DomU Debian Lenny installation. Is this a change that is made in order for the OS to be Xen aware? Otherwise, I have tried to manually create the file, but the DomU hangs when starting. >> >> When I tried the command 'ip link set eth1 name eth0', I get the result >> 'RTNETLINK answers: File exists'. > > Probably because there's still another link called eth0 :) Try > renaming eth0 to eth-tmp (or something), then rename eth1 to eth0, and > eth-tmp to eth1. > I can try writing a script that would rename the interfaces as a workaround. But it appears that the "correct" way to do what I would like with Debian Lenny is the udev rules. >> I found that I can define vifname >> which appears to address my intention of defining the interface name. >> So I >> tried adding the syntax so that my DomU config file had the following >> line >> with the exception of the sanitized MAC address: >> >> vif = [ 'mac=00:16:XX:XX:XX:XX,vifname=eth1,bridge=eth1' ] >> >> When trying to boot the DomU with the configuration, I received the >> following error: >> >> Error: Device 0 (vif) could not be connected. Hotplug scripts not >> working. >> > > That won't do you what you want. vifname is the name of the interface > on dom0 (the one that's usually called vifx.y). So (for example) > instead of vif1.0 you can have fw-eth0. Note that it's on dom0, not on > domU. In your case it don't work because there's already another > interface on dom0 called eth1. > I must have misinterpreted the documentation. I incorrectly believed the vifname parameter was used to assign the interface name in the DomU. >> Can someone share what syntax combination or steps I need to follow in >> order >> to obtain a DomU with three interfaces; one of which is "real" as a >> result >> of PCI pass through and two which are virtual interfaces? > > Give the virtual interfaces static MAC, and lookup Debian's > documentation on how to assign a static name to a specific MAC. > On a side note, I believe you could also dump PCI passthrough, and > simply create another bridge on dom0, using that physical interface, > with no IP address (at least this works on RHEL and Ubuntu). That way > all interfaces will be virtual (vif), and you can adjust which one is > listed first on domU config. > As I mentioned before, my ultimate goal is to configure a standard three interface firewall within the DomU. Most of the information I have found on the subject suggests the most secure way to accomplish this is to dedicate the interface connected to the Internet to the DomU using PCI passthrough. The other two interfaces (DMZ & LAN) would be virtual interfaces bridged to the Dom0. I am open to other concepts for creating a firewall DomU if anyone cares to share their configurations. > -- > Fajar > _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |