En esta página
Puntos clave
- Asignar una función concretaTerminar túneles, controlar rutas y reenviar paquetes requieren recursos y comprobaciones diferentes.
- Dimensionar todo el recorridoLa velocidad indicada por un puerto virtual no mide lo que pueden sostener la VM, el host y el enlace físico.
- Probar un servicio realUna segunda sesión BGP sirve cuando las rutas seleccionadas y el servicio se recuperan como estaba previsto.
Decidir las funciones de la VM antes de elegir su tamaño
Un router VM puede terminar una entrega GRE aprobada, mantener sesiones BGP o enrutar entre redes. Especifique cuáles son sus funciones. El control de rutas y el reenvío están relacionados, pero son trabajos distintos: una VM que intercambia rutas sin transportar tráfico de aplicaciones no se dimensiona igual que una pasarela situada en el recorrido de ese tráfico.
Dibuje el recorrido real: entrada pública, extremo del túnel, redes de aplicaciones, retorno y administración. Identifique al responsable de cada frontera. Separe IPv4 e IPv6 cuando se utilicen. Este registro permite distinguir un problema de la VM de otro del host, proveedor o extremo remoto.
Un servidor dedicado existente quizá ya desempeñe parte de esas funciones. Añadir una VM debe resolver una necesidad concreta, como separar el enrutamiento o preparar otra entrega aprobada. Repartir las mismas dependencias entre dos procesos no crea por sí solo redundancia independiente.
Incluir la política de rutas en la especificación de entrega
Acuerde para cada vecino BGP los ASN local y remoto, familia de direcciones, dirección de origen y del vecino, anuncios permitidos y rutas esperadas. Una ruta predeterminada, un conjunto limitado y la tabla completa de Internet tienen necesidades distintas. Admitir BGP no significa incluir una tabla completa.
Enumere importaciones y exportaciones autorizadas, límites de prefijos y comportamiento al superarlos. Conserve la autorización y titularidad de los prefijos anunciados. La seguridad operativa de BGP incluye políticas de rutas y protección de la sesión; RFC 7454 es una referencia útil para esta revisión.
Tras establecer la sesión, inspeccione las rutas aceptadas y las instaladas para los destinos relevantes. Verifique el siguiente salto y el recorrido desde la aplicación. El estado de sesión no demuestra que se haya recibido una ruta predeterminada, aceptado sus prefijos o resuelto el retorno hacia la aplicación.
Medir el recorrido de reenvío virtualizado
La velocidad de interfaz mostrada dentro de la VM no es un compromiso de rendimiento sostenido. Registre CPU, memoria, controlador invitado, NIC virtual y colas, e identifique los recursos del host realmente disponibles. La competencia por recursos y el enlace físico siguen formando parte del recorrido.
Mida volumen y tasa de paquetes en la dirección relevante. Un flujo de paquetes grandes y muchos paquetes pequeños pueden ocupar un ancho de banda similar y exigir cantidades muy distintas de operaciones. Incluya NAT, filtros, procesamiento de túneles y las funciones que estarán activas en producción.
Inspeccione pérdidas y utilización en la VM y el host cuando haya datos. Un promedio bajo de CPU puede ocultar una cola o núcleo saturado. La documentación de Linux explica RSS, RPS y mecanismos relacionados; su configuración necesita una revisión del despliegue, no una receta universal de número de colas.
Validar la encapsulación y el MTU por separado
Registre para cada túnel el extremo externo entregado, direcciones internas, encapsulación y MTU. GRE básico sobre IPv4 consume 24 bytes antes de opciones u otra encapsulación. Esa operación no determina el MTU real del recorrido. El túnel principal y el de respaldo pueden tener restricciones de transporte diferentes.
Compruebe intercambios representativos con cargas útiles mayores además de pequeñas pruebas de conectividad. Un ping corto o una sesión BGP establecida no validan todos los servicios TCP y UDP. Revise el retorno y el descubrimiento de MTU con el equipo de red; cambiar la MSS TCP no resuelve todos los datagramas UDP demasiado grandes.
Definir qué fallo debe soportar el respaldo
Una segunda VM en el mismo host puede sobrevivir a un fallo específico de la primera y compartir alimentación, hipervisor, NIC física y proveedores. Registre esos componentes comunes antes de hablar de redundancia. Dos sesiones establecidas no demuestran dos recorridos de datos independientes.
Acuerde la selección principal y de respaldo en ambas direcciones. ¿Qué evento elimina o reduce la preferencia de la ruta principal? ¿Hay una alternativa elegible? ¿Qué sucede cuando vuelve? Revise las rutas estáticas persistentes además de BGP: una ruta estática independiente puede seguir seleccionando el recorrido averiado.
Utilice una prueba de mantenimiento autorizada, con una aplicación de referencia funcional y un responsable de reversión. Compare ruta seleccionada, contadores y resultado aplicativo durante el fallo concreto. Registre tiempo de recuperación e impacto en sesiones existentes. Un reinicio de la VM no valida la resistencia ante fallos del host o del proveedor.
Aceptar el despliegue con resultados observables
Antes de asignar a la VM una dependencia importante de producción, acuerde un registro breve de aceptación. Reserve las pruebas de sobrecarga a un entorno aislado que no pueda afectar a clientes. RFC 6815 explica por qué las pruebas de capacidad RFC 2544 no son adecuadas para redes de producción.
| Comprobación | Evidencia que conservar | Alcance del resultado |
|---|---|---|
| Enrutamiento | Importaciones, exportaciones, rutas instaladas y siguientes saltos previstos | BGP establecido solo describe el estado de sesión |
| Recorrido aplicativo | Intercambio completado por la entrada y retorno previstos | Una aplicación no valida todos los protocolos |
| MTU | Valores entregados e intercambios mayores en cada recorrido | Un cálculo de bytes no mide una ruta |
| Reenvío | Contadores bidireccionales, tamaños, funciones activas y pérdidas | La velocidad del puerto virtual no es capacidad de reenvío medida |
| Recuperación | Rutas elegidas, efecto en usuarios, tiempo y retorno al estado normal | Solo cubre el fallo y las dependencias probados |
Preguntas antes de contratar Router VM
¿Sustituye Router VM a la protección DDoS aguas arriba?
No por sí solo. Puede encargarse del enrutamiento o de la entrega, pero el tráfico debe llegar por un recorrido utilizable. Distinga capacidad aguas arriba, filtrado, recursos virtuales y alcance del servicio.
¿El soporte BGP incluye una tabla completa?
No. Confirme familias de direcciones, rutas recibidas, límites y condiciones reales. La memoria para rutas y el procesamiento de actualizaciones deben ajustarse a la política acordada.
¿Qué datos ayudan a preparar el despliegue?
Describa la función, ASN y prefijos autorizados si corresponden, entrega del túnel, tráfico previsto en Gbit/s y paquetes/s, funciones activas y requisitos de recuperación. No envíe credenciales ni claves privadas.
