Differences

This shows you the differences between two versions of the page.

--- cisco:switch:9500:cisco_catalyst_9500_series_manual [2026/06/11 17:23] – aperez
+++ cisco:switch:9500:cisco_catalyst_9500_series_manual [2026/06/11 17:26] (current) – aperez
@@ Line 1310: / Line 1310: @@
 ----
-====== Cisco C9500 SUR — Timeout de SSH desde Bogotá (MTU residual de VXLAN) ======
+====== Cisco C9500 SUR — Timeout de SSH desde sitio remoto (MTU residual de VXLAN) ======
 **Fecha:** 2026-06-11
-**Equipo:** C9500SP1 (LAG-17-C9500SP2) — 172.20.28.37 (SUR, Houston)
+**Equipo:** C9500SP1 (LAG-17-C9500SP2) — 172.20.28.37 (SUR, sitio local)
 **Estado:** Resuelto
 ===== Síntoma =====
-El SSH al switch funcionaba desde la LAN local de Houston pero daba timeout desde Bogotá (10.57.0.x). El ping ICMP y el SNMPv3 (snmpget) desde Bogotá funcionaban bien; solo fallaba el SSH (y el playbook de baseline de ASH, que usa SSH) con "Connection timed out". Aparentaba funcionar solo mientras había una sesión local de Houston activa.
+El SSH al switch funcionaba desde la LAN local del mismo sitio, pero daba timeout desde el sitio remoto de gestión (10.57.0.x). El ping ICMP y el SNMPv3 (snmpget) desde el sitio remoto funcionaban bien; solo fallaba el SSH (y el playbook de baseline de ASH, que usa SSH) con "Connection timed out". Aparentaba funcionar solo mientras había una sesión local activa.
 ===== Causa raíz =====
 Problema de MTU en el path, secuela del VXLAN removido:
-  * El path WAN/VPN Houston <-> Bogotá tiene MTU menor a 1500 (ping con DF: 1400 pasa, 1500 falla con "MMMMM" = fragmentación necesaria con DF activo).
+  * El path WAN/VPN entre el sitio local y el sitio remoto tiene MTU menor a 1500 (ping con DF: 1400 pasa, 1500 falla con "MMMMM" = fragmentación necesaria con DF activo).
   * La SVI de gestión **Vlan1** había quedado con **MTU 9100 (jumbo)**, heredado de la configuración VXLAN.
-  * Con ese MTU local jumbo, el switch enviaba segmentos TCP grandes hacia Bogotá (respetando el MSS anunciado por Bogotá, 1460), y esos paquetes de ~1500 morían en el enlace de ~1400. ICMP/SNMP (paquetes chicos) pasaban; por eso solo se rompía el SSH/TCP.
+  * Con ese MTU local jumbo, el switch enviaba segmentos TCP grandes hacia el sitio remoto (respetando el MSS anunciado por el cliente, 1460), y esos paquetes de ~1500 morían en el enlace de ~1400. ICMP/SNMP (paquetes chicos) pasaban; por eso solo se rompía el SSH/TCP.
   * También explica por qué solo este switch fallaba y no los demás del SUR: los otros tienen MTU normal en su interfaz de gestión.
-Un ''ip tcp mss 1360'' global por sí solo NO lo resolvió, porque solo limita el MSS que el switch //anuncia// (dirección Bogotá -> switch), no lo que el switch //envía// hacia Bogotá.
+Un ''ip tcp mss 1360'' global por sí solo NO lo resolvió, porque solo limita el MSS que el switch //anuncia// (dirección cliente -> switch), no lo que el switch //envía// hacia el sitio remoto.
 ===== Solución =====
@@ Line 1348: / Line 1348: @@
 ===== Validación =====
-Desde Bogotá:
+Desde el sitio remoto de gestión:
 <code bash>
 ssh admin@172.20.28.37
@@ Line 1355: / Line 1355: @@
 <code bash>
 snmpget -v3 -l authPriv -u ash-monitor -a SHA -A '<auth>' -x AES -X '<priv>' 172.20.28.37 1.3.6.1.2.1.1.5.0
-# -> STRING: "C9500SP1.stfs.local"
+# -> STRING: "C9500SP1.example.local"
 </code>
@@ Line 1371: / Line 1371: @@
   * Tras cualquier remoción futura de VXLAN en un switch, revisar el MTU de la SVI de gestión: el residuo jumbo causa exactamente este síntoma.
   * El playbook baseline de ASH usa SSH, así que esto también desbloquea LAG-17 en baseline_south.yml en la próxima corrida.
 ----
 ----