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

[Alexandre Kouznetsov <alk@xxxxxxxxxx>]

Hi.

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
> wrong).
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
> deprecated)
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
> network.
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
  address 11.22.33.44
  netmask 255.255.255.0
  gateway 11.22.33.254
  bridge_ports bond0
  bridge_stp off
  bridge_maxwait 0

#internal bridge
auto xenbr01
iface xenbr01 inet static
  address 192.168.X.X
  netmask 255.255.255.0
  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.
Greetings.

--
Alexandre Kouznetsov


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users