Nick,
Not sure of the answer to your question, but I'm curious whether
you have STP turned on in your bridge interface.
If you do, you might try turning it off, and vice versa, to see
if it helps your network infrastructure respond to changes in topology either
way.
Jeff
From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Nick
Couchman
Sent: Thursday, August 06, 2009 2:38 PM
To: XEN Mailing List
Subject: [Xen-users] Bridge Changes Cause Connections to Drop
This may be more of a Linux Bridge question, but
I thought I'd ask on the XEN list just to see if anyone has any experience with
this. I'm running Xen 3.2 on SLES10 SP2. I run several XP Virtual
Machines that people can log in to remotely (via RDP). Many of these
machines sit on the same bridge on the dom0 machine, and I'm running into a
situation where anytime the "bridge topology" changes the RDP
connections are lost. So, if I reboot one of the VMs, which causes the
bridge to first drop the Xen virtual interface for that VM, then re-add it
under the new ID, everyone loses their connections to the other VMs and has to
reconnect. I did some packet tracing, and all I found was an RST packet,
but no indication as to why the host sent the RST packet. Can anyone
offer any insight into this issue?
Thanks,
Nick
<br><hr>
This e-mail may contain confidential and privileged material for the sole use
of the intended recipient. If this email is not intended for you, or you are
not responsible for the delivery of this message to the intended recipient,
please note that this message may contain SEAKR Engineering (SEAKR)
Privileged/Proprietary Information. In such a case, you are strictly prohibited
from downloading, photocopying, distributing or otherwise using this message,
its contents or attachments in any way. If you have received this message in
error, please notify us immediately by replying to this e-mail and delete the
message from your mailbox. Information contained in this message that does not
relate to the business of SEAKR is neither endorsed by nor attributable to
SEAKR.
|
