This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-users] Trouble with manual bridging on Xen3/CentOS 5

To: Teck Choon Giam <giamteckchoon@xxxxxxxxx>
Subject: Re: [Xen-users] Trouble with manual bridging on Xen3/CentOS 5
From: Digimer <linux@xxxxxxxxxxx>
Date: Sat, 30 Apr 2011 17:32:18 -0400
Cc: "xen-users@xxxxxxxxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sat, 30 Apr 2011 14:33:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <BANLkTi=Gjp7OdfTyF7DE9SVZ3uFn2W5uxA@xxxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <4DBB36EA.2030202@xxxxxxxxxxx> <BANLkTimE1YDM86_rYj6PHWqgDyRa1gQoHw@xxxxxxxxxxxxxx> <4DBC3DCE.4060206@xxxxxxxxxxx> <BANLkTi=Gjp7OdfTyF7DE9SVZ3uFn2W5uxA@xxxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110428 Fedora/3.1.10-1.fc14 Thunderbird/3.1.10
On 04/30/2011 03:25 PM, Teck Choon Giam wrote:
> On Sun, May 1, 2011 at 12:50 AM, Digimer <linux@xxxxxxxxxxx> wrote:
>> On 04/29/2011 06:26 PM, Teck Choon Giam wrote:
>>> On Sat, Apr 30, 2011 at 6:08 AM, Digimer <linux@xxxxxxxxxxx> wrote:
>>> (network-script /bin/true)
>> That was the ticket. I was able to provision a new VM with two
>> interfaces, however, the vifs were at MTU 1500 so I still have work to
>> do. :)
> Glad to hear that ;)
> Whereby for MTU... maybe you want to try manually set those?  For example:
> To get the link of various ip link... ...
> ip link show
> Then if you want to set the mtu for vif1.0 for instance... do something like:
> ip link set dev vif1.0 mtu 1412
> Of course in your case, vif1.0 or whatever appended with .0 for vif#.0
> will be your xenbr0/eth0... so you might want to do something like:
> ip link set dev eth0 mtu 1412 << This can be configure in ifcfg-eth0
> ip link set dev xenbr0 mtu 1412 << This also can be set in ifcfg-xenbr0
> ip link set dev vif1.0 mtu 1412
> ip link set dev vif2.0 mtu 1412
> OR using ifconfig to set the related interface mtu.
> so on... ... I don't think this is difficult to find the vif related
> script in /etc/xen/scripts/ to add in the appropriate link for your
> desired mtu value... ... IMO.  I think this is vif-common.sh as the
> below codes:
> if [ "$type_if" = vif ]; then
>     # Check presence of compulsory args.
>     dev="${dev:?}"
>     vifname=$(xenstore_read_default "$XENBUS_PATH/vifname" "")
>     if [ "$vifname" ]
>     then
>         if [ "$command" == "online" ] && ! ip link show "$vifname" >&/dev/null
>         then
>             do_or_die ip link set "$dev" name "$vifname" << THIS IS
> APPENDED mtu "$mtu"
>         fi
>         dev="$vifname"
>     fi
> elif [ "$type_if" = tap ]; then
>     # Check presence of compulsory args.
>     : ${INTERFACE:?}
>     # Get xenbus_path from device name.
>     # The name is built like that: "tap${domid}.${devid}".
>     dev_=${dev#tap}
>     domid=${dev_%.*}
>     devid=${dev_#*.}
>     XENBUS_PATH="/local/domain/0/backend/vif/$domid/$devid"
> fi
> Something like:
> do_or_die ip link set "$dev" name "$vifname" mtu "$vifmtu"
> Or if doesn't work just split to another line:
> do_or_die ip link set "$dev" name "$vifname"
> do_or_die ip link set dev "$vifname" mtu "$vifmtu"
> Or use ifconfig... ...
> Of course you will need to set $vifmtu somewhere before the above or
> use a function/line to get its bridge/parent interface name
> (xenbr0/eth0) mtu value ... ... this is purely talking rubbish from me
> without testing... just thoughts/ideas :p
> Example:
> Get parent/bridge interface mtu value for xenbr0:
> local vifmtu=`ip link show xenbr0|head -n 1|sed 's@.*\Wmtu\W@@'|sed 
> 's@\W.*@@'`
> Or even better way is we know vif#.N where N will be the bridge number:
> local myxenbrN=`echo $vifname | cut -f2 -d '.'`
> local myxenbrname="xenbr${myxenbrN}"
> local vifmtu=`ip link show ${myxenbrname}|head -n 1|sed
> 's@.*\Wmtu\W@@'|sed 's@\W.*@@'`
> do_or_die ip link set "$dev" name "$vifname" mtu "$vifmtu"
> Again, the above are ideas/thoughts without testing at all and I might
> be totally wrong :p
> Hope this helps!
> Thanks.
> Kindest regards,
> Giam Teck Choon

Hi Giam,

  This was the approach I took, which resulted in this patch:


  The trick with doing it manually is that the bridge's MTU is set to
the lowest MTU of all attached ifs. So if a new vif comes up at 1500 and
is then connected to a bridge that had been at 9000, all traffic >1500
bytes will die on the bridge. So, as you explored, I had to edit the
userland scripts to up the vif's MTU before it connected to the bridge.

  I'd done this earlier, but it was bugged. While trying to solve that
new bug, Pasi suggested I take the bridge control out of Xen's control
and that prompted the experimenting that got me in trouble. :)

E-Mail: digimer@xxxxxxxxxxx
AN!Whitepapers: http://alteeve.com
Node Assassin:  http://nodeassassin.org

Xen-users mailing list