En esta página
Puntos clave
- Documente ambos sentidosLa entrega filtrada y el retorno deben cumplir el modelo elegido de enrutamiento y protección.
- Use la MTU entregadaLa encapsulación y los caminos de respaldo pueden requerir valores diferentes.
- Demuestre reenvío y recuperaciónUna sesión de enrutamiento establecida no demuestra por sí sola que el tráfico útil llegue al servicio.
Defina la interfaz antes de activar
La entrega es la frontera donde un equipo proporciona tráfico y otro asume su responsabilidad. Registre extremos públicos del túnel o interfaz física, direcciones internas, VLAN cuando proceda, familias de direcciones, vecinos, prefijos autorizados y MTU. Mantenga camino normal, protegido y de retorno en el mismo diagrama para que ningún equipo suponga que el otro cubre un paso ausente.
Asigne responsables de interfaz, política BGP, reglas de filtrado y servicio destino. Acuerde ventana de cambios, evidencias de cada lado y contacto de recuperación. El documento debe permitir distinguir fallo del camino exterior, ruta interna incorrecta y aplicación que no responde.
| Elemento | Documente expresamente | Compruebe en la aceptación |
|---|---|---|
| Encapsulación o acceso físico | Extremo, protocolo, interfaz o VLAN y familia de direcciones reales. | El camino existe y es alcanzable por la red subyacente prevista. |
| Enrutamiento interno | Direcciones local y vecina, ASN, anuncios permitidos y rutas recibidas. | Prefijos y rutas de retorno esperados son utilizables, no solo están configurados. |
| Tamaño de paquete | MTU entregada por camino y comportamiento de descubrimiento esperado. | Funcionan intercambios legítimos pequeños y mayores. |
| Recuperación | Camino preferido, política de respaldo, criterios de convergencia y responsable de reversión. | El tráfico usa un camino funcional tras el fallo acordado y vuelve según lo previsto. |
Trate la MTU como propiedad del camino completo
La encapsulación consume parte del presupuesto del paquete exterior. En un ejemplo simple, una ruta IPv4 exterior de 1.500 bytes con cabecera IPv4 de 20 bytes y GRE básica de 4 deja 1.476 bytes para el paquete interior. Opciones GRE, otra capa de túnel o una MTU subyacente inferior pueden cambiar el resultado. No es un valor universal para copiar en todas las interfaces GRE.
Use la MTU indicada en el documento real de cada túnel. Camino principal y respaldo pueden necesitar valores distintos; una entrega de 1.452 en un camino no debe sustituirse por 1.476 porque otro lo use. Compruebe qué capa de paquete informa una interfaz o captura antes de interpretar el tamaño.
También importan descubrimiento de MTU y transporte. Un ping pequeño exitoso no demuestra que funcionen intercambios TCP o UDP grandes. El ajuste de MSS TCP solo afecta al tamaño de segmentos TCP; no repara cualquier problema UDP o de encapsulación. Preserve los mensajes de control necesarios para el mecanismo elegido según la política de seguridad acordada.
Pruebe intercambios reales pequeños y grandes
Elija pruebas acordes al servicio. Compruebe establecimiento y una acción útil de aplicación, después una transferencia mayor o intercambio representativo de datagramas. Repita en sentidos y familias cubiertos por la entrega. Registre tamaños, puntos de observación, expiraciones y contadores en lugar de confiar en un único resultado de «alcanzable».
El rendimiento TCP depende también de tiempo de ida y vuelta, pérdidas, límites del receptor y otros aspectos del transporte. El objetivo es localizar el problema, no atribuir toda transferencia lenta al filtrado. Use referencia de aplicación y medidas de transporte juntas; las cargas que saturan recursos pertenecen a un entorno aislado autorizado.
Distinga estado BGP y reenvío útil
Una sesión puede estar Established aunque falten rutas necesarias, la política las rechace o sean menos preferidas. Verifique lo que cada vecino envía y recibe, prefijos aceptados, siguientes saltos elegidos y entradas de reenvío. Si el cliente necesita ruta por defecto, establezca si se entrega por BGP o mediante otro método acordado.
Pruebe también el retorno. Una ruta estática obsoleta o un camino incompatible con estado puede hacer parecer roto el respaldo aun con BGP sano. Revise la especificidad: una ruta de respaldo menos específica no reemplaza tráfico que sigue atraído por otra más específica instalada. Investigue la selección real antes de cambiar preferencias.
Defina qué fallo debe cubrir el respaldo
Mantenga activos el túnel y la sesión de reserva acordados cuando el diseño espere recuperación automática. Preferencia normal y elegibilidad como respaldo son cuestiones distintas. Ambos extremos necesitan políticas compatibles; la existencia de una sesión no documenta por sí sola la preferencia aplicada a rutas recibidas.
Pruebe el escenario con los responsables de producción: perder una sesión, el camino del túnel o el router no es lo mismo. Dos túneles en un router no demuestran redundancia de equipos. Registre pérdidas, comportamiento de aplicaciones, rutas y restauración; no prometa una transición sin pérdidas a partir de una prueba que solo mostró alcance.
Correlacione ambos extremos y la recuperación
Use una ventana común y nombre la dirección de cada contador. Compare emisor, interfaz del túnel o entrega, receptor, filtro y aplicación destino. Registre cuándo cambió el enrutamiento y cuándo volvió el servicio útil. Ver un paquete salir de un componente no prueba su llegada al siguiente; conserve evidencias para localizar la interrupción.
Tras restaurar el camino preferido, compruebe que se selecciona, que el respaldo sigue disponible y que las aplicaciones establecidas se comportan según lo requerido. Revise también la monitorización: el colector puede haberse recuperado en otro momento. Guarde configuración final y resultados con el documento de entrega.
Un acta breve de entrega y aceptación
Son tareas de aceptación, no autorización para interrumpir producción sin coordinación. Separe pruebas intrusivas de controles rutinarios y defina antes sus condiciones de parada. El resultado útil es un registro reproducible de la entrega real, no una afirmación genérica de red plenamente validada.
Identifique el servicio
Registre interfaces, responsables, prefijos autorizados y configuración versionada.
Verifique el reenvío normal
Compruebe rutas recibidas, siguientes saltos, ambas direcciones y éxito de la aplicación.
Verifique tamaños de paquete
Use la MTU de cada camino y transferencias pequeñas y grandes representativas.
Documente fallo y restauración
Capture fallo acordado, observaciones de convergencia, límites pendientes y resultado de reversión.
Preguntas sobre la entrega
¿Puedo usar la misma MTU GRE para todos los túneles?
No. Use el valor entregado para cada camino completo. Encapsulación adicional o una red subyacente distinta pueden cambiar la MTU interior disponible.
¿Una sesión BGP Established demuestra que funciona el respaldo?
No. Revise rutas aceptadas y seleccionadas, reenvío, retorno y comportamiento de aplicaciones ante el fallo acordado.
¿Qué debe contener el informe final?
Configuración real y responsables, resultados normales, comprobaciones de tamaño, comportamiento observado durante fallo y recuperación y condiciones no probadas explícitas.
