Re: Antwort: Re: Xen 3.0.3 and VLAN

[Tim Post <tim.post@netkinetics.net>]

On Fri, 2006-11-03 at 10:15 +0100, Bruno.Voigt@ic3s.de wrote:

> /etc/network/interfaces:
> 
> auto lo
> iface lo inet loopback
> 
> auto eth0.94
> iface eth0.94 inet static
>         address 172.17.94.48
>         netmask 255.255.255.0
>         gateway 172.17.94.254
>         broadcast 172.17.94.255
> 
Bruno, 

I notice that you're giving eth0.94 and xenbr0 the same IP. The bridge
should be treated as if it were a network interface. 

If you simply take out the entire entry for eth0.94 , and change the
line

bridge_ports eth0.94 to :

bridge_ports eth0

it should be fine. 

Once done, for all intensive purposes, xenbr0 *is* eth0. The bridge will
port the physical device itself, not an alias to it.

Also, I noticed I forgot a comma in one of my examples, in particular :

vif  = [ 'bridge=xenbr0 mac=00:16:3e:06:a2:f8' ]

should read :

vif  = [ 'bridge=xenbr0, mac=00:16:3e:06:a2:f8' ] (note the added comma)

Are you sure your not using hotplug? What does dpkg -l | grep hotplug
tell you?

May want to add this right after lo/loopback is brought up:

mapping hotplug
        script grep
        map xenbr0

Everything else in your snippets as far as networking looks ok, should
work once you make the changes. 

You should then be able to start broadcasting other IP's on your vlan
from within the dom-u's, provided you specify unique mac addresses for
them in the dom-u config files. 

I don't think there's an accepted "virtual mac" prefix yet, such as you
would find a prefix for a hardware manufacturer. It really doesn't
matter what you put for a mac, I usually start vnics with 00:00:00:0A
just so I can tell what's what at my router. 

If your data center is using a Cisco network (and chances are, yes they
are) it could take up to 9 - 10 minutes for their core to arp the
changes you're making.. so if it doesn't work at first, give it 10 - 15
minutes and try again.

Since the bridge will come up with the default ff:ff:ff:ff:ff:ff mac and
eth0's IP becomes xenbr0 (i.e mac to ip changes), they will need to arp
the new change. In most newer facilities this is a non issue, but I've
battled a few DC's over it especially with live migration of load
balanced pairs. 

If doing this via SSH you may want to rent a KVM if they offer it as
you'll most likely get kicked once you restart networking again.

Hope this helps, again feel free to post back if you can't get it
working .. its a bridging issue, not Xen.

Just in case, I'm pasting my /etc/network/interfaces file from my
desktop (running xen 3). br1 is just a dummy brige to simulate a second
network between my dom-u's that I use for ocfs2.

Best,
-Tim

---- example interfaces ::

root@tower:/# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them.

auto lo
iface lo inet loopback

mapping hotplug
        script grep
        map br0
        map br1

# public bridge
auto br0
iface br0 inet static
        address 10.92.1.10
        netmask 255.255.255.0
        network 10.92.1.0
        gateway 10.92.1.1
        bridge_helo 0
        bridge_fd 0
        bridge_maxwait 0
        bridge_stp off
        bridge_ports eth0

# private bridge for ocfs2
auto br1
iface br1 inet static
        address 192.168.0.1
        netmask 255.255.255.0
        network 192.168.0.0
        bridge_helo 0
        bridge_fd 0
        bridge_maxwait 0
        bridge_stp off
        bridge_ports none