Differences

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

--- cisco:switch:9500:cisco_catalyst_9500_series_manual [2025/07/31 18:26] – aperez
+++ cisco:switch:9500:cisco_catalyst_9500_series_manual [2026/06/11 17:26] (current) – aperez
@@ Line 7: / Line 7: @@
 ----
+  Switch#do show interfaces status
   Switch#show running-config interface Port-channel2
   Switch#show interfaces status
@@ Line 1286: / Line 1288: @@
   * For production EVPN deployment, BGP configuration will be required.
+----
+----
+{{ :aruba_networks:switch:6400:vxlan_cli_ap.pdf |}}
+{{pdfjs 46em >:aruba_networks:switch:6400:vxlan_cli_ap.pdf}}
+----
+----
+{{ :cisco:switch:9500:mtu_utm_switch_6400_9500.pdf |}}
+{{pdfjs 46em >:cisco:switch:9500:mtu_utm_switch_6400_9500.pdf}}
+----
+----
+====== 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, sitio local)
+**Estado:** Resuelto
+===== Síntoma =====
+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 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 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 cliente -> switch), no lo que el switch //envía// hacia el sitio remoto.
+===== Solución =====
+Bajar el MTU de IP de la SVI de gestión para que quepa en el path. Es seguro: solo afecta el MTU de IP de Vlan1 (gestión), no el MTU L2, ni las interfaces físicas/uplinks, ni el tráfico de producción. No genera flap. Reversible con ''no ip mtu''.
+<code>
+configure terminal
+interface Vlan1
+ ip mtu 1400
+end
+write memory
+</code>
+Limpieza opcional (el mss clamp global no era necesario y deja un warning de throughput):
+<code>
+configure terminal
+no ip tcp mss 1360
+end
+write memory
+</code>
+===== Validación =====
+Desde el sitio remoto de gestión:
+<code bash>
+ssh admin@172.20.28.37
+</code>
+El SSH ahora conecta normal. El SNMPv3 ya estaba en su lugar:
+<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.example.local"
+</code>
+===== Comandos de diagnóstico (referencia) =====
+<code>
+! Confirmar el MTU del path (desde el switch)
+ping 10.57.0.241 source Vlan1 size 1400 df-bit repeat 5   ! pasa
+ping 10.57.0.241 source Vlan1 size 1500 df-bit repeat 5   ! falla (MMMMM)
+! Confirmar el MTU jumbo en la SVI de gestión
+show interface Vlan1 | include MTU                        ! mostró MTU 9100
+</code>
+===== Notas =====
+  * 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.
+----
+----