Resumen

  • Megaport recomienda dos Ports separados, dominios de capa 2 distintos en los routers del cliente y peering de cada servicio con ambos route servers. Es una base lógica necesaria, no un inventario de diversidad física.
  • AMS-IX separa la conexión directa, EasyAccess cuyo transporte IP incluido coordina AMS-IX y la conexión mediante un revendedor. El modelo elegido cambia la cadena de entrega y la demarcación.
  • Dos servicios cuentan como dos caminos sólo después de una prueba en la que un fallo definido elimina uno y el otro conserva las rutas útiles, la capacidad y el control operativo previstos.

El diagrama que termina demasiado pronto

Un comprador ve dos servicios IX activos y dos sesiones BGP establecidas. El diagrama termina en esos iconos y la tabla de riesgos declara la conectividad redundante.

La pregunta profesional empieza allí. ¿Ambos servicios salen del mismo router? ¿Usan VLAN diferentes sobre un único Port? ¿Dos Ports dependen del mismo chasis, sala, alimentación o circuito metropolitano? ¿Convergen en el mismo punto de entrega del exchange o bajo una sola autoridad de mantenimiento? Si la respuesta no está documentada, el segundo objeto no prueba un segundo dominio de fallo.

No se puede afirmar que esa concentración exista en un cliente concreto. Las fuentes no publican sus rutas. Tampoco se puede presumir diversidad porque el portal muestre dos órdenes. La ausencia de evidencia debe conservarse como desconocida.

Megaport define MegaIX como un exchange virtual dentro de su red global definida por software. Permite alcanzar IX locales o remotos desde un Port existente, incluso mediante un VXC, y cambiar el servicio sin desplegar hardware o cross-connects en cada destino. La ventaja operativa es clara. Sin embargo, el transporte físico no desaparece: pasa a formar parte del servicio de otro actor.

AMS-IX expone tres cadenas diferentes. La conexión directa se realiza en una de sus colocaciones y puede requerir cross-connect. EasyAccess incluye transporte IP coordinado por AMS-IX. La conexión por socio se organiza con el revendedor elegido. La misma LAN de intercambio puede recibirse mediante cadenas de entrega, demarcaciones y procesos de incidencia distintos.

Separar las pruebas por capa

La guía de redundancia de Megaport exige dos Ports separados. Cada servicio debe establecer peering con ambos route servers y cada router del cliente debe operar en un dominio de capa 2 distinto. También advierte contra un switch común en el lado del cliente y contra dos servicios que sólo usan un route server.

Cumplir esa pauta evita fallos obvios. No informa, por sí solo, de las fibras, operadores, edificios, alimentación, enlaces de socio o ventanas de mantenimiento que hay detrás de una orden. Son categorías de evidencia diferentes.

El router del cliente, el Port, el dominio de capa 2, el transporte, la entrega del exchange, el sitio, la energía, la sesión BGP y la autoridad operativa deben evaluarse por separado. Los dos route servers protegen esa función concreta. No demuestran que dos transportes no compartan zanja, equipo o operación. A la inversa, dos fibras distintas no garantizan que las rutas recibidas o la capacidad de respaldo sean suficientes.

Esta comisión no reabre la cuestión Strategic Circle sobre las decisiones de política delegadas a un route server DE-CIX. Aquí no se decide qué prefijos redistribuye el servidor. Se comprueba si el trayecto que lleva las rutas aceptadas sobrevive al fallo anunciado.

Una sesión activa no describe el trayecto

Megaport distingue peering multilateral con route servers y peering bilateral con otro miembro. BGP establecido aporta una prueba útil de adyacencia. El looking glass aporta visibilidad de rutas. Ninguno revela todo el underlay.

La documentación de diagnóstico enumera errores de interfaz, óptica y cableado, MTU, LACP, VLAN, direcciones, tablas, alcance al route server o al par bilateral y errores BGP. También pide pruebas extremo a extremo. Por eso una sesión puede seguir activa mientras los paquetes fallan en otra capa; y una sesión caída no identifica la causa sin más observaciones.

La capacidad tampoco se deduce del estado. Un backup puede ser independiente y no soportar el tráfico desplazado. Las fuentes no publican la tasa contratada, congestión, latencia o ensayo de ningún comprador. “Disponible” debe separarse de “capaz de transportar el servicio bajo carga de fallo”.

APNIC registra AS133937 como MEGAPORTPTYLTD-AS-AP, con código de país AU. Ese objeto respalda la identidad enlazada. No prueba una sesión, una preferencia de ruta o la diversidad de una entrega privada.