1

When network to domU is connected via bridge config, having an open ssh connection to dom0 and domU at the same time randomly drops dom0 connection (Connection reset by peer) and doesn't allow me back in.

Authorization is done via ssh keys. Any tips on solving that one?

EDIT: some more details about the environment

dom0

# cat /proc/version
Linux version 2.6.18-128.1.10.el5xen ([email protected]) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) #1 SMP Thu May 7 11:07:18 EDT 2009

domU

# cat /proc/version
Linux version 2.6.9-78.0.22.ELxenU ([email protected]) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-10)) #1 SMP Thu Apr 30 19:39:33 EDT 2009

Xen version 3.1.2-128.1.10.el5

Important detail I first forgot to mention: this happens only when dom0 has an external IP associated with it.

Current solution: no external IP on dom0, access to dom0 via domU -> dom0 path. This could be relatively safe when having a separate domU which does nothing but provide this route. I can still connect to dom0 remotely and reboot other machines when needed.

EDIT2: additional info about MAC addresses on dom0

dom0

# ifconfig|grep HWaddr
bond0     Link encap:Ethernet  HWaddr 00:04:23:DC:28:60  
bond0.100 Link encap:Ethernet  HWaddr 00:04:23:DC:28:60  
eth0      Link encap:Ethernet  HWaddr 00:04:23:DC:28:60  
eth1      Link encap:Ethernet  HWaddr 00:04:23:DC:28:60  
tap0      Link encap:Ethernet  HWaddr 7E:CE:49:45:3F:2E  
vif4.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
vif4.1    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
vif22.0   Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
xenbr0    Link encap:Ethernet  HWaddr 00:04:23:DC:28:60  
xenbr1    Link encap:Ethernet  HWaddr 00:04:23:DC:28:60

It would seem that there's really some issue with dup MAC addresses.

4
  • Can you provide any more details regarding the environment? I have several Xen servers and have not seen this behavior exhibited before. could possibly be something with your configuration? Jun 11, 2009 at 20:51
  • tcpdump on the physical interface, to show us what exactly is going on.
    – womble
    Jun 12, 2009 at 7:44
  • 1
    Could it be that you have duplicate MAC addresses on dom0 and domU? Could you paste an ifconfig of dum0 physical and virtual intreface and domU interface?
    – katriel
    Jun 12, 2009 at 7:57
  • Duplicate MACs seem most likely at this stage. Check not only ifconfig on each machine, but also the ARP cache arp -an of your workstation to see what they are resolving to before, during and after it happens.
    – Dan Carley
    Jun 12, 2009 at 9:25

3 Answers 3

1

Based on the information you've provided so far I would suggest that problem is with the MAC address duplication and the disconnections may be from the switch you're ethernet port is going through.

That said there will be some MAC address duplication. I just checked on one of my Xen servers that I have been working on and I get the following when I run ifconfig | grep HWaddr

eth0      Link encap:Ethernet  HWaddr 00:E0:81:2D:66:AC  
eth1      Link encap:Ethernet  HWaddr 00:E0:81:2D:66:AD  
peth0     Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
peth1     Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
vif0.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
vif0.1    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
vif31.0   Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
vif31.1   Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
virbr0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
xenbr0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
xenbr1    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  

This is on a RHEL5 Xen 3.0.3 server so I am assuming the interface differences are based on changes between 3.0.3 and 3.1.2. That aside you can see that both my eth0 and eth1 interfaces are different MAC addresses whereas yours are both identical. the pethX and vifX.X entries are all virtual interfaces for Xen so the MAC address FE:FF:FF:FF:FF:FF is perfectly fine.

The xenbr0 is the bridge that eth0 is attached to and xenbr1 is the bridge for eth1 and use the same MAC address. The virbr0 interface is the bridge for the internal virtual network and has the 00:00:00:00:00:00 MAC because of having spanning tree protocol enabled. You can confirm the bridging on your system by running brctl show which should give you something like:

bridge name bridge id       STP enabled interfaces
virbr0      8000.000000000000   yes     
xenbr0      8000.feffffffffff   no  vif31.0
                            peth0
                            vif0.0
xenbr1      8000.feffffffffff   no  vif31.1
                            peth1
                            vif0.1
0

Without the details requested by others in the comments on your question my guess is some odd routing issue, such as incorrectly configured NAT.

One workaround to try would be to run sshd on a different port in either domU or dom0 and see if that works. If this fixes the connection drops then that would support the suggestion that NAT is setup wrongly so the translation table entry for port-22-to/from-domU gets clobbered by the entry for port-22-to/from-dom0. Don't just leave this "fix" in place if it works though - you'd need to get the routing issue sorted or it will cause other problems down the line.

This workaround may also have the desired affect if you have duplicate MAC addresses, as suggested by katriel, so check that possibility first.

0

I do this a bunch and know this method will work. Plus you don't have to think about ports at all. To connect to the terminal of the Host from the vm guest it is mounted to i do the following. The way xenserver is setup is that there are limitations on port traffic. I tried learning this and working through the managed methods, but then realized i had another option. It requires the vm your operating on to have an external connection to the network that the host is on. Managing by static ip's is an easy way to do this.

ASSUMPTIONS:

  1. "host_a" ( contains vm_a )
  2. "vm_a" shares ip with host_a and has an external nic configured.
  3. "host_b"

You will know if assumption 2 has been configured correctly if you can ssh into other machines on the network from the vm. This is needed because that is how we will connect to "host_a". To connect from ssh session on VM_A you ssh to either HOST_B.

so your terminal will look something like this.

[root@vm_a]$ssh root@host_b
[roo@host_b]#ssh root@host_a

now we have made a fun little circle and are connected to the host terminal. There are other ways to directly connect by porting but 2 lines are simpler to me.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .