Hub

electrosystems

gi-calzada 🕒

done medium work
Creado
2026-05-21
Actualizado
2026-05-21
Directorios
  • (server remoto — SSH alias `gi-calzada` vía ProxyJump `gi-corp`)

Actividad en bitácora 1 día

jun
jul
ago
sep
oct
nov
dic
ene
feb
mar
abr
may
L
X
V
Menos
Más

gi-calzada — routing cross-VLAN (red plana ↔ teléfonos)

Contexto

gi-calzada es un servidor del cliente Grupo Imperial (mismo cliente que gi-siptrunks-replacement, gi-corp bastion). Vive en la sucursal Calzada y es el PBX local para teléfonos de ese sitio. Topología relevante:

  • eth0 = 172.16.187.254/24 — VLAN de teléfonos. Los teléfonos lo usan como gateway.
  • eth1 = 172.16.87.11/24 — red plana del sitio. (Más alias legacy 192.168.1.5/24.)
  • Switch cisco del sitio tiene SVI en AMBAS VLANs: 172.16.87.199 (gw de la red plana) y 172.16.187.1 (también L3 en la VLAN teléfonos).
  • OSPF: ES NO administra los enlaces. El cliente usa OSPF solo entre sus equipos (no en este server).
  • SSH: ssh gi-calzada (config en ~/.ssh/config, puerto 58695, ProxyJump gi-corp).

Incidente resuelto — 2026-05-21

Equipos en 172.16.87.0/24 no veían nada de 172.16.187.0/24 (ni siquiera al propio server por su IP .187.254). gi-corp (red 172.16.0.0/22) tampoco. Sergio venía arrastrando el síntoma del día anterior.

Causa raíz

Routing asimétrico que moría en el server por net.ipv4.ip_forward = 0:

  • .87.x → .187.y: el cisco enruta directo (tiene SVI en ambas VLANs), nunca toca al server. ✅ llega.
  • .187.y → .87.x (respuesta): el teléfono usa al server como gateway → server intenta reenviar a eth1 → dropea, porque ip_forward = 0. ❌

Por la misma razón cualquier handshake bidireccional fallaba.

Por qué los teléfonos sí venían funcionando

Asterisk vive en .187.254 (el mismo segmento L2 que los teléfonos). Registro y voz contra el PBX no requieren routing. El problema solo aparece cuando alguien quiere cruzar VLANs.

Fix

sysctl -w net.ipv4.ip_forward=1
# persistido en /etc/sysctl.conf (línea: net.ipv4.ip_forward = 1)

Lo aplicó Selene manualmente. Validado en frío:

  • /proc/sys/net/ipv4/ip_forward = 1.
  • /etc/sysctl.conf con la directiva → sobrevive reboot. (/etc/sysctl.d/99-sysctl.conf es symlink a ese archivo.)
  • iptables -L FORWARD -nv pasó de 0 packets / 0 bytes (prefix) a 367 paquetes / 99 KB en cuestión de minutos → kernel reenviando confirmado.

Tareas pendientes

(Ninguna.)

En progreso

(Nada activo.)

Notas técnicas

  • SSH: gi-calzada en ~/.ssh/config, HostName 172.16.87.11, Port 58695, User root, ProxyJump gi-corp. Llaves heredadas de la config legacy GI (no requiere los +ssh-rsa que sí necesita gi-siptrunks).
  • OS: CentOS 7 (3.10.0-1127.19.1.el7.x86_64), uptime 311 días al momento del fix.
  • Asterisk: pid 1126 (chan_sip clásico), udp/5060 + udp/4569 (IAX), AMI en 127.0.0.1:5038.
  • iptables: FORWARD policy ACCEPT sin reglas. INPUT permite 172.16.0.0/16 y RELATED/ESTABLISHED. No hay NAT.
  • rp_filter: strict (1) en all/default/eth0/eth1. No rompe los flujos esperados — cada red sale por su interfaz natural.
  • No corre routing dinámico: ni FRR, ni quagga, ni zebra, ni bird. Acorde con la convención del cliente (ellos hacen OSPF entre sus propios equipos, no piden que el server participe).
  • Alias raro 192.168.1.5/24 en eth1:0 — legacy, no relacionado al incidente. (Pendiente menor: averiguar para qué es y si se puede limpiar.)

Hipótesis descartadas en el diagnóstico

  • ❌ iptables bloqueando — FORWARD vacío con policy ACCEPT.
  • ❌ Falta ruta estática en el cisco — el cisco YA tiene SVI en .187.1, no necesita ruta estática.
  • ❌ Falta OSPF en el server — el cliente NO usa OSPF en este server por diseño.
  • ❌ rp_filter rompiendo — chequeado, las rutas inversas matchean la interfaz por la que entra cada paquete.

Bitácora

2026-05-21

Pidió Sergio: retomar el diagnóstico que había empezado el día anterior. Síntoma: red plana .87 no ve VLAN teléfonos .187 (ni siquiera al server mismo), y gi-corp 172.16.0.0/22 tampoco ve .187. El server es gateway de los teléfonos pero NO de la red plana (esa la maneja el cisco .87.199). OSPF lo usan ellos entre sus equipos, ES no administra esos enlaces.

Diagnóstico (SSH read-only):

  • Estado base: eth0 .187.254, eth1 .87.11, default gw .87.199, ruta estática 172.16.0.0/16 via .87.199. Asterisk vivo. Teléfonos REACHABLE en eth0.
  • Tres hallazgos: ip_forward=0 + ningún daemon OSPF + iptables limpio.
  • tcpdump -i eth1 'dst net 172.16.187.0/24' durante 5s captó 0 paquetes.

Hipótesis inicial: cisco sin ruta a .187 o server sin OSPF.

Sergio corrigió: el cisco también tiene SVI en .187.1 (confirmado en mi ARP eth0: 172.16.187.1 lladdr a0:3d:6e:cf:41:c8). Ellos usan OSPF solo entre sus equipos, no este server. La pista correcta era el forwarding.

Replanteo: routing asimétrico — la ida .87 → .187 va por el cisco directo, la vuelta .187 → .87 pasa por el server y muere porque ip_forward=0. Fix de un solo bit.

Hice:

  • Propuse sysctl -w net.ipv4.ip_forward=1 + persistir en sysctl.conf/sysctl.d.
  • Selene aplicó el cambio manualmente.
  • Validé: runtime=1, persistido en /etc/sysctl.conf, FORWARD chain ya acumulando paquetes (367 paq / 99 KB en minutos).

Cierre: fix limpio, sin tocar nada más del server. No requiere cambios en cisco, ni levantar FRR/OSPF, ni ACLs.

Memorias persistidas:

  • [[reference-cisco-svi-dual-vlan-needs-ip-forward]] — patrón reusable: si el switch L3 del sitio tiene SVI en ambas VLANs Y los hosts de una de ellas usan a un server Linux como gateway, ese server DEBE tener ip_forward=1 o el retorno cross-VLAN muere.
  • [[reference-gi-calzada-server]] — info técnica del server (eth0/eth1, IPs, rol, SSH).