0

I've got a workstation with Supermicro X10DRi-T mainboard. It has three Ethernet ports. One of them (IPMI LAN) is dedicated to IPMI. The other two, LAN1 and LAN2 are general-purpose. This question Configuring SuperMicro IPMI to use one of the LAN interfaces instead of the IPMI port? mentions that LAN1 can be used as IPMI.

My problem is the following: when I use LAN1 to connect this computer to LAN, it works OK for some time, but then SSH connection spuriously fails. The host responds to pings, but attempt to reconnect via SSH fails like this:

$ cat ./ssh.log 
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /home/miyuki/.ssh/config
debug1: /home/miyuki/.ssh/config line 1: Applying options for *
debug1: /home/miyuki/.ssh/config line 10: Applying options for *.lan
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/miyuki/.ssh/config
debug1: /home/miyuki/.ssh/config line 1: Applying options for *
debug1: /home/miyuki/.ssh/config line 11: Applying options for 192.168.123.*
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/tmp/ssh-miyuki@192.168.123.6:22" does not exist
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.123.6 [192.168.123.6] port 22.
debug1: Connection established.

<... snip ...>

debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "192.168.123.6" from file "/home/miyuki/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/miyuki/.ssh/known_hosts:33
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received

<... snip ...>

debug2: mac_setup: setup hmac-sha1
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug2: mac_setup: setup hmac-sha1
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug2: bits set: 1034/2048
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
Connection to 192.168.123.6 timed out while waiting to read

The OS is Debian 8:

$ uname -a
Linux workstation 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u1 (2015-12-14) x86_64 GNU/Linux

Disconnecting the network locally (via ifdown/ifup) cures this problem. It can also disappear after waiting for some time (say, an hour).

Finally, the problem has gone completely, after I started using LAN2 interface instead of LAN1. For now it's OK because this computer is a sort of playground (yeah, I apologize for question that is not exactly on-topic here), so I don't need such features as IPMI, but it would be nice to have two fully functional LAN ports.

My questions are: does this problem look related to incorrect IPMI configuration? How to fix it (i.e. I need a working LAN1 interface; IPMI is not necessary)?

Mikhail Maltsev
  • 51
  • 4
  • 1
    From your description, it sounds more a network issue. May be you can perform some tests: ftp://ftp.supermicro.com/CDR-009_1.21_for_Via_platform/Intel/LAN/v6.2/Guides/Common/diag1000.htm – Diamond Feb 16 '16 at 11:25

2 Answers2

0

Did you, by any chance, assign the same ipaddress to both the BMC and to the server NIC? Because that would result in this behaviour. Both the BMC and the regular NIC use a different MAC address, so when they are announcing their IP to the network (ARP), that would result in a loss of connectivity to either one of them.

Jeroen
  • 1,339
  • 7
  • 16
0

If Jeroen answer doesn't solve your issue, try going in the BIOS and set the IPMI to dedicated LAN

(I.E. use the dedicated lan port for IPMI rather than share the IPMI with LAN1 & 2)

JFL
  • 2,006
  • 1
  • 11
  • 16