Temas relacionados
Mi problema es similar pero no exactamente igual queTubería SSH rota, código de autenticación de mensaje incorrectopara lo cual no hay respuesta.
Tarea
Copie archivos grandes de un Linux a otro. Ambos se encuentran en la misma ubicación del ISP.
Configuración
El origen y el destino son ambos: Ubuntu 16.04.3 LTS
Versión SSH en ambos: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 de marzo de 2016
La máquina original ha estado en uso durante un año y no ha habido problemas. La máquina de destino es un servidor dedicado recién configurado (1 día).
comando scp:
scp -P [customport] /some/large/file user@targetmachine:/target/folder/
El archivo tiene un tamaño de unos 20 GB.
Descripción del problema
Por lo general, aborta después de aproximadamente el 3-4%. La velocidad máxima es de aproximadamente 112 MB/s. Cuando acelero con, por ejemplo, scp -l 16384, va a aproximadamente 2 MB/s, se cancela mucho más tarde, pero en un porcentaje similar.
El aborto es siempre exactamente de la misma manera. El cliente obtiene:
Write failed: Broken pipe
lost connection
Mientras el servidor tiene esto en /var/log/auth.log
Nov 24 13:04:54 Ubuntu-1604-xenial-64-minimal-no-hwe sshd[1900]: Corrupted MAC on input.
Nov 24 13:04:54 Ubuntu-1604-xenial-64-minimal-no-hwe sshd[1900]: fatal: ssh_dispatch_run_fatal: Connection from [client-ip] port 54050: message authentication code incorrect
Investigación
Probé ambos con iptables habilitado y deshabilitado, sin cambios.
De aproximadamente 10 intentos, 1 tuvo éxito hasta el final y luego el siguiente archivo se canceló nuevamente.
Parece que después de reiniciar la máquina de destino, se pueden escribir más bytes en ella.
SSH no es ningún problema. Puedo mantener abierta una conexión ssh inactiva durante horas, o una en la que el topcomando se esté ejecutando y no se interrumpa.
Preguntas
Este es un bloqueador. En primer lugar, parece imposible copiar un archivo de 200 GB. En segundo lugar, no quiero una máquina en producción con problemas de red.
¿Qué puedo hacer para investigar más a fondo esto?
Leí en otro lugar que podría ser un problema de tarjeta de red/hardware, ¿cómo puedo demostrarle esto a mi proveedor para obtener un reemplazo?
Actualización 1
El resultado durante 10 minutos mtrparece bueno:
└─(~)─(49 files, 12Gb)─> mtr -r -c 600 -rw [targetserver]
Start: Fri Nov 24 18:36:21 2017
HOST: Ubuntu-1404-trusty-64-minimal Loss% Snt Last Avg Best Wrst StDev
1.|-- static.XX.XX.XX.XX.clients.your-server.de 0.0% 600 0.5 0.3 0.2 24.5 1.3
2.|-- core24.fsn1.hetzner.com 0.0% 600 0.3 0.3 0.2 6.8 0.4
3.|-- core22.fsn1.hetzner.com 0.0% 600 0.4 0.4 0.3 9.7 0.8
4.|-- ex9k2.dc1.fsn1.hetzner.com 0.0% 600 0.4 0.5 0.3 6.8 0.8
5.|-- my.target.hostname 0.0% 600 0.4 0.3 0.3 0.4 0.0
┌(myuser@Ubuntu-1404-trusty-64-minimal)─(✓)─(06:46 PM Fri Nov 24)
Inmediatamente después probé otro scp, falló al 44% después de 7,5 GB, la velocidad fue de 111 MB/seg. El fallo volvió a producirse instantáneamente, sin detenerse antes de eso.
Con respecto al posible duplicado: siempre recibí el "tubo roto", nunca el "Tipo de protocolo incorrecto para el enchufe". No uso Mac, ambos Linux (versiones anteriores). No uso rsync. La respuesta fue que el usuario puso otra tarjeta de red en el servidor, sin descubrir cuál fue la causa real, hasta donde tengo entendido. No tengo esta opción (servidor dedicado en el centro host remoto).
Aquí está el resultado de lshw con respecto a la tarjeta de red:
myuser@Ubuntu-1604-xenial-64-minimal-no-hwe /home/myuser # lshw -class network
*-network:0 DISABLED
description: Ethernet interface
product: NetXtreme II BCM57810 10 Gigabit Ethernet
vendor: Broadcom Corporation
physical id: 0
bus info: pci@0000:61:00.0
logical name: eth0
version: 10
serial: e0:d5:5e:1e:73:18
capacity: 1Gbit/s
width: 64 bits
clock: 33MHz
capabilities: pm vpd msix pciexpress bus_master cap_list rom ethernet physical fibre 1000bt-fd
configuration: autonegotiation=off broadcast=yes driver=bnx2x driverversion=1.712.30-0 firmware=bc 7.14.2 latency=0 link=no multicast=yes port=fibre
resources: iomemory:14c0-14bf iomemory:14c0-14bf iomemory:14c0-14bf irq:81 memory:14c0b000000-14c0b7fffff memory:14c0a800000-14c0affffff memory:14c0b810000-14c0b81ffff memory:e5f80000-e5ffffff memory:14c0ba20000-14c0bc1ffff memory:14c0bca0000-14c0bd1ffff
*-network:1 DISABLED
description: Ethernet interface
product: NetXtreme II BCM57810 10 Gigabit Ethernet
vendor: Broadcom Corporation
physical id: 0.1
bus info: pci@0000:61:00.1
logical name: eth1
version: 10
serial: e0:d5:5e:1e:73:1a
capacity: 1Gbit/s
width: 64 bits
clock: 33MHz
capabilities: pm vpd msix pciexpress bus_master cap_list rom ethernet physical fibre 1000bt-fd
configuration: autonegotiation=off broadcast=yes driver=bnx2x driverversion=1.712.30-0 firmware=bc 7.14.2 latency=0 link=no multicast=yes port=fibre
resources: iomemory:14c0-14bf iomemory:14c0-14bf iomemory:14c0-14bf irq:102 memory:14c0a000000-14c0a7fffff memory:14c09800000-14c09ffffff memory:14c0b800000-14c0b80ffff memory:e5f00000-e5f7ffff memory:14c0b820000-14c0ba1ffff memory:14c0bc20000-14c0bc9ffff
*-network:0
description: Ethernet interface
product: I350 Gigabit Network Connection
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:62:00.0
logical name: eth2
version: 01
serial: 6c:b3:11:23:32:18
size: 1Gbit/s
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi msix pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=igb driverversion=5.3.0-k duplex=full firmware=1.63, 0x80000cbb ip=94.130.51.145 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
resources: irq:71 memory:e5900000-e59fffff memory:e5a84000-e5a87fff memory:e5a00000-e5a7ffff memory:14c0bf60000-14c0bf7ffff memory:14c0bf40000-14c0bf5ffff
*-network:1 DISABLED
description: Ethernet interface
product: I350 Gigabit Network Connection
vendor: Intel Corporation
physical id: 0.1
bus info: pci@0000:62:00.1
logical name: eth3
version: 01
serial: 6c:b3:11:23:32:19
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi msix pciexpress bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=igb driverversion=5.3.0-k firmware=1.63, 0x80000cbb latency=0 link=no multicast=yes port=twisted pair
resources: irq:82 memory:e5800000-e58fffff memory:e5a80000-e5a83fff memory:14c0bf20000-14c0bf3ffff memory:14c0bf00000-14c0bf1ffff
*-network DISABLED
description: Ethernet interface
physical id: 1
logical name: virbr0-nic
serial: 52:54:00:80:b4:28
size: 10Mbit/s
capabilities: ethernet physical
configuration: autonegotiation=off broadcast=yes driver=tun driverversion=1.6 duplex=full link=no multicast=yes port=twisted pair speed=10Mbit/s
Esto me recuerda que instalé KVM.
apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils
Pero todavía no hay ninguna máquina virtual encendida.
Respuesta1
Tuve un problema similar al usar scpo rsync+ samba/ cifs.
El problema se resolvió en el lado rsync+ samba/ cifsomitiendo el caché de escritura al --cache=nonemontar el servidor en el cliente (consulte tambiénrsync sigue desconectándose: tubería rota). Se proporciona una explicación detallada sobre la causa raíz de este problema enHaga que Linux escriba en el sistema de archivos de la red simultáneamente con las lecturas del disco local.
Podría scpconsiderar limitar la velocidad de transferencia para evitar llenar el caché de la página antes de que el disco pueda ponerse al día; consulte, por ejemplohttps://stackoverflow.com/questions/30020519/broken-pipe-error-on-scp.
Respuesta2
Esta fue una instalación "mínima-sin-hwe". Lo más probable es que la versión "mínima" de Ubuntu hubiera funcionado desde el principio.
Estos comandos se utilizaron para instalar hwe en esta versión no-hwe que funciona mal (por lo que no es necesario realizar una reinstalación completa):
apt-get install --install-recommends linux-generic-hwe-16.04
shutdown -r now
Después de esto, todas las copias de scp funcionan, no se cancelan.
Una nota al margen, el saludo en la terminal todavía se muestra.
"myuser@Ubuntu-1604-xenial-64-minimal-no-hwe"
a pesar de que estamos en marcha ahora.
Aclaro una vez más el comportamiento antes de esta solución: todos los scp grandes HACIA esta máquina, desde varias ubicaciones, abortaron, mientras que todos los scp DESDE esta máquina, hacia varias ubicaciones, tuvieron éxito.
Esta es la especificación del servidor.https://www.hetzner.de/epyc-serveraunque el proveedor de alojamiento no especifica los modelos para placa base/redes.