Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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 (mockbuild@builder10.centos.org) (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 (mockbuild@builder10.centos.org) (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.

share|improve this question
    
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? –  Jeremy Bouse Jun 11 '09 at 20:51
    
tcpdump on the physical interface, to show us what exactly is going on. –  womble Jun 12 '09 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 '09 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 '09 at 9:25
add comment

2 Answers 2

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
share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.