[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] network setup with one bonded interface and one virtual interface

  • To: xen-users@xxxxxxxxxxxxx
  • From: Alexandre Kouznetsov <alk@xxxxxxxxxx>
  • Date: Thu, 04 Oct 2012 16:38:10 -0500
  • Delivery-date: Thu, 04 Oct 2012 21:39:10 +0000
  • List-id: Xen user discussion <xen-users.lists.xen.org>


Simon's response stays valid.

El 04/10/12 11:30, Adam Gold escribió:

 I want to keep the VMs on a private network and haven't quite
worked out the right way to do this.  If I attach bond0 to a bridge, it
seems I have to assign public IPs to the VMs (please correct me if I'm
Correction: you don't *have* to. You may assign whatever IP's you like, but topologically they will be in the same Ethernet network as the public interface. Sometimes this setup is useful, but looks like it's not your case.

- create dummy0 and attach that to xenbr0 which is intended to be the
private network gateway
Should work, but as Simon said, dummy0 is not needed there.

- create an alias bond0:1 and attach that to xenbr0
That's weired, I guess it behaved funny. Alias are made on IP level, and the members of the bridge are on network interface (device) level. Wrong mix.

- I've also tried various combinations with the xen routing and nat
scripts (which I'd rather not use if possible given they are becoming
You'd do well. Native OS's tools for networking setup are much more predictable, between other advantages.

- for all of the above I've used IP tables for the forwarding and
masquerading between the 'attempted' private network and the external
facing NIC
Make 2 bridges:
- One of them will contain you bond0 device and any VM's interface you want public (if any). - Other will not have any physical device, instead is will be used to attach the virtual interfaces of your DomU's.

Make your routing rules and iptables setup as on any NAT router. Treat the first bridge as external interface, the second one will be internal.

In all cases, I either end up cutting off access to bond0 or the private
Just keep your DomU's network out of the bridge, containing bond0.

About interface file. Keep in mind the abstraction order of things.
You have two physical network interfaces. They already exists (but might be down, that is not a problem), no need to create them.
On top of them, you have the bond0 device, enslaving the interfaces.
On top of it, you have a ethernet bridge, of which bond0 is member.
You could assign IP directly to bond0, rendering it unusable for VM's. I would advise to use it with a bridge, it will make your configuration more homogeneous.

So, interfaces file might look similar to this. That is from my own working config, I use another type of bonding and not sure about the right options for your case (active-backup):

auto lo
iface lo inet loopback

#underlying bond, have no IP
auto bond0
iface bond0 inet manual
    slaves eth0 eth1
    bond-mode 802.3ad
    bond-miimon 100
    bond-downdelay 200
    bond-updelay 200

#external bridge
auto xenbr00
iface xenbr00 inet static
  bridge_ports bond0
  bridge_stp off
  bridge_maxwait 0

#internal bridge
auto xenbr01
iface xenbr01 inet static
  address 192.168.X.X
  bridge_ports none
  bridge_stp off
  bridge_maxwait 0

#another internal bridge, just as example
#let's attach it to bond0's VLAN2
#no IP assigned on Dom0, bridge is useful only for DomUs
auto xenbr02
iface xenbr02 inet manual
  bridge_ports bond0.2
  bridge_stp off
  bridge_maxwait 0
  bridge_fd 5


Note that eth0 and eth1 are not mentioned. Debian's ifupdown scripts are smart enough, no need to confuse them. The interfaces will be woke up as soon as they implicitly required.

Another advice, leave Dom0 to venerate the hypervisor, and set up a separated DomU to serve as firewall. Much cleaner setup, and your firewall will need not to worry about the forwarding within the Dom0's bridges.

Good idea to leave Dom0 a (second) external IP, heavily firewalled, just in case of doing something that risks you DomU firewall not doing well (like reboot). Not strictly necessarily.


Alexandre Kouznetsov

Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.