Unha copia de ficheiro polo túnel detense un segundo, retómase e os rexistros da VPN non mostran nada. A aplicación culpa á rede, a rede culpa á aplicación, e o porto do conmutador leva once meses activo. Este percorrido comeza na pausa e avanza cara á ligazón física: que está a facer realmente o porto, que está a facer o extremo remoto e que fixeron os contadores mentres vostede miraba. Paga a pena facelo antes de que alguén toque un axuste de dúplex.

Empece pola pausa, non polo porto

Describa o síntoma dunha forma que se poida probar. Unha parada duns segundos durante unha transferencia masiva é un problema distinto dunha conexión que se reinicia, e unha pausa que ocorre unha vez por hora é distinta dunha que ocorre cada poucos segundos. Anote a carga, a dirección e o intervalo aproximado.

Despois reprodúzao mentres observa a interface. Un problema físico maniféstase como movemento nos contadores durante a carga afectada, e un problema que non move ningún contador probablemente está por riba da capa de ligazón. Observe un minuto, non un segundo, porque estas avarías adoitan necesitar tráfico sostido antes de aparecer. A monitorización en repouso non demostra nada sobre unha ligazón que só se comporta mal baixo carga.

Isto importa porque os desaxustes de dúplex teñen unha sinatura: erros que só aparecen baixo carga, na dirección do tráfico, mentres os pings pequenos e as sesións interactivas seguen perfectos. Se o tráfico en repouso tamén falla, busque primeiro noutro sitio.

Lea o modo operativo nos dous extremos

A configuración gardada non é o estado operativo. Un porto pode estar configurado para a autonegociación e acabar en medio dúplex, ou estar configurado a unha velocidade fixa coa que o outro extremo nunca estivo de acordo. Lea que está a facer a ligazón agora mesmo nos dous lados.

ethtool eth0
ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0

Anote a velocidade, o dúplex e se a autonegociación está activada, e despois obteña os mesmos tres datos do conmutador adxacente ou do porto do provedor. Un só extremo non di nada, porque o desaxuste é unha relación e non un axuste. Poña as dúas filas no tícket, unha xunto á outra, coa hora na que as leu. A metade do valor do exercicio é ter as dúas lecturas nun mesmo sitio.

Se non pode ler o extremo remoto, non pode diagnosticar isto. Pida ao propietario o modo operativo e os contadores, ou organice o acceso antes de comezar a cambiar o seu lado.

Como se ve o caso 10/100 en medio dúplex

Nas ligazóns de cobre 10/100, un extremo que autonegocia pode detectar a velocidade dun par forzado sen aprender o seu axuste de dúplex. A detección paralela determina a velocidade a partir do sinal, e o dúplex supónse en lugar de negociarse, así que un lado pode acabar en medio dúplex mentres o outro funciona a dúplex completo.

A guía de autonegociación de Cisco explica ese caso concreto. Non é un argumento para desactivar a negociación en todas partes, e non di nada útil sobre o cobre gigabit, onde o dúplex é fixo e a autonegociación é necesaria para que a ligazón se levante.

A evidencia observable é unha mestura de erros que só existen nunha dirección: erros FCS ou CRC no lado de dúplex completo, colisións ou colisións tardías no lado de medio dúplex, e un rendemento que se derruba baixo carga mentres a latencia se mantén normal en repouso. Esa asimetría é a sinatura. Unha ligazón simplemente sobresubscrita degrádase nas dúas direccións e en todo momento.

Cambie os dous extremos á vez, cun camiño de volta

Unha corrección de dúplex é un cambio coordinado, non local. Forzar o seu lado sen o acordo do extremo remoto é como unha ligazón que funciona se converte nunha rota, e que a CLI acepte a orde só demostra que a sintaxe era válida.

sudo ethtool -s eth0 speed 100 duplex full autoneg off
ethtool eth0

Antes de executar algo así, confirme que a plataforma admite a combinación e que o extremo remoto se cambiará na mesma xanela. Conserve unha vía independente para administrar o dispositivo, porque o porto que está a piques de cambiar pode ser o que transporta a súa sesión de xestión.

En moitas ligazóns modernas a resposta correcta é deixar a autonegociación activada nos dous extremos en lugar de forzar nada. Forzar é un remedio para un desaxuste concreto nunha tecnoloxía concreta, non unha mellora xeral. O cobre gigabit, en particular, necesita a autonegociación para que a ligazón se levante, así que o consello para 10/100 non se traslada.

Confirme que os contadores se movieron a mellor

Despois do cambio, volva ler o estado operativo nos dous extremos e confirme que coinciden. Despois execute a mesma carga que produciu a pausa e compare as diferenzas dos contadores en lugar dos totais acumulados, porque un total que se acumula desde hai un ano non pode dicirlle que pasou nos últimos dez minutos.

ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0
ping -f -c 200 10.90.0.1

Unha ligazón sen erros novos baixo a mesma carga é a evidencia que lle faltaba. Unha ligazón que segue fallando, ou unha na que os contadores nunca se moveron, envíao á seguinte fronteira en lugar de máis dentro da discusión do dúplex. Calquera dos dous resultados é progreso, que é máis do que o ficheiro de configuración lle pode dar. Non salte a segunda lectura porque a primeira parecese correcta.

Escriba os números de antes e despois no tícket con marcas de tempo. Ese rexistro é o que converte «a VPN vai mellor» en algo sobre o que o seguinte enxeñeiro pode construír.

Artigos relacionados