¿Tiene sentido implementar OSPF en Metro Ethernet?

Cuando necesito conectar varios sitios de sucursales entre sí para un cliente, generalmente recomiendo una VPN MPLS a través de un operador de confianza. El CE en cada sitio habla BGP con su PE aguas arriba y cada sitio está numerado con su propio ASN privado. Esto es muy conveniente para nosotros ya que BGP proporciona una miríada de herramientas de ingeniería de tráfico y nuestras adyacencias se limitan a n + 1 para n sitios (el +1 es nuestro entorno colo).

Últimamente, sin embargo, he notado un creciente interés de los clientes en las soluciones Metro Ethernet. Muchos de nuestros clientes tienen sucursales dentro de un área metropolitana común y las cotizaciones de MetroE están llegando a varios cientos de dólares (USD) menos que el servicio MPLS para circuitos de las mismas velocidades. Si bien esto es atractivo, no estoy seguro de cómo establecer mejor el enrutamiento a través de una red troncal de capa dos mientras evito convertir una topología de malla en hub-and-speak.

BGP necesitaría una malla completa de adyacencias entre sitios de sucursal para mantener la conectividad de malla, lo que obviamente no es deseable desde una perspectiva de escalabilidad. La otra opción es implementar un IGP, es decir, OSPF, y hacer que todos los sitios formen adyacencias en la WAN. Me gustaría abordar cada sitio como su propia área, lo que parece excesivo, pero quiero preservar la capacidad de resumir las rutas anunciadas desde cada sitio y esto solo se puede hacer en las fronteras del área.

¿Esto tiene sentido? ¿Hay alguna advertencia a tener en cuenta al implementar OSPF de esta manera (por ejemplo, ¿debería considerar deshabilitar las inundaciones de LSA)? ¿O hay otra solución que he pasado por alto?

Esta es una pregunta compleja, ya que los dos productos diferentes son muy diferentes. Un circuito MPLS L3VPN es inherentemente una malla completa entre todas las ubicaciones que participan, mientras que una conexión MetroE es generalmente un enlace punto a punto entre dos sitios específicos.

En mi experiencia, un circuito MetroE es una ruta directamente aprovisionada, sin servicios de protección, a menos que se contrate con una ruta de protección. Esto significa que la falla de una interfaz o enrutador a lo largo de la ruta específica sería la interrupción del tráfico entre los dos sitios que están directamente vinculados por el servicio MetroE. El MPLS L3VPN curará las fallas de interfaz / enrutamiento para mantenerlo con una malla completa entre sus sitios. Esto generalmente explica la diferencia de precio entre los dos.

No hay nada de malo en construir sus propios servicios sobre una plataforma MetroE: solo necesita trabajar con los requisitos del cliente para determinar qué tipo de enrutamiento es apropiado. Si está trabajando con una red de oficina pequeña, OSPF / IS-IS / EIGRP podría ser una forma maravillosa de intercambiar información de enrutamiento entre los sitios conectados directamente que ha establecido. Si es más un NSP / ISP / * SP, separar la infraestructura y las rutas de los clientes entre IGP y EGP se vuelve mucho más importante a medida que escala.

Como ingeniero de ISP, utilizamos ampliamente los enlaces MetroE y EWAN para construir nuestra red troncal, y utilizamos nuestro conocimiento de los enlaces físicos para diseñar nuestro entorno iBGP / eBGP. En muchos casos, utilizamos reflectores de ruta y reflectores de ruta dual (ruta-reflector-cliente en ambos lados del emparejamiento) para reducir nuestro recuento de pares iBGP. Sin embargo, a menos que esté trabajando con más de 6 enrutadores en un POP, iBGP escala bastante bien.

En resumen, si es para un solo cliente, que no ofrece servicios de red a sus propios clientes, quédese con un IGP. Si es necesario compartir la conectividad externa entre sitios, con conmutación por error / redundancia / etc., examine detenidamente las rutas físicas que tiene y diseñe su eBGP / iBGP para reflejar eso. No tiene sentido tener un enrutador en una ubicación remota con solo 1 enlace fuera del sitio a un par iBGP con todos los otros enrutadores en el AS: use un reflector de doble ruta.

Cambiar de un L3VPN administrado (lo que supongo que quiso decir con "VPN MPLS") a un L2VPN es un buen paso adelante en el sentido de que puede ejecutar protocolos que no son IP y obtener un control total de los protocolos de enrutamiento y las plataformas de enrutamiento que definen su enrutamiento topología

Suponiendo que coloca solo una dirección MAC Ethernet en el lado CPE de cada uno de sus sitios, es mucho más simple para el equipo del proveedor aprender y reenviar 1 direcciones MAC por sitio, que aprender y enrutar potencialmente muchas subredes por sitio.

En cuanto al protocolo, esta es una pregunta un poco difícil de responder sin mucha más información, ya que la mejor opción depende de su tráfico y sus planes de crecimiento.

¿Es este un gran cliente que necesita conectividad interna y de internet, o también vende conectividad? Suponiendo que todo es interno, entonces solo implementará un IGP y tal vez ejecute algunos eBGP para anunciar rutas.

Si no tiene muchos sitios o prefijos internos, un protocolo de estado de enlace como OSPF o IS-IS tiene más sentido, ya que convergerá rápidamente y puede construir el FIB a partir del RIB rápidamente si solo hay unos pocos prefijos .

Si tendrá muchos sitios o muchos prefijos, esto comenzará a gravar sus plataformas de enrutamiento, ya que cada una necesita procesar cada una. Esto es algo que comienza a tomar n ² veces. Si tiene sitios que suben y bajan con frecuencia, esta rotación en el estado de enlace también puede comenzar a gravar su grupo de enrutadores.

Si va a tener muchos sitios, muchos sitios rechonchos (una ruta "aguas arriba", ningún otro enrutador aguas abajo) o muchos cambios de ruta, tendrá que buscar otros protocolos o topologías.

En un caso como ese, recomendaría usar BGP con algunos reflectores de ruta. De esta manera, puede aprovisionar 2+ reflectores de ruta de servicio pesado en los que los radios anuncian, y de los cuales los otros radios pueden tomar una tabla de enrutamiento. De esta manera, puede implementar CPE livianos en sus muchos sitios de radio que solo se conectan, anuncian su espacio y obtienen una tabla interna o una ruta predeterminada a un enrutador que lo hace.

Aproximadamente, sugeriría algunas escalas y equipo (y suponiendo rendimientos sub-Gigabit):

• 1 - 20 radios - OSPFv3 entre todos los sitios. Juniper SRX240 o similar para todos los sitios.
• 20-100 radios - iBGP con reflectores de ruta. Juniper SRX240 en los radios, Juniper MX5 / 10/40/80 para la reflexión de ruta (o Debian Linux / BIRD).
• 100 - 500 radios - Comience a dividirlos en diferentes redes L2, AS o áreas

Solo para agregar dos bits comúnmente ignorados a la discusión de BGP:

• Si ejecuta iBGP, generalmente necesita otro protocolo de enrutamiento para establecer la conectividad entre los próximos saltos de BGP. Desde la perspectiva del diseño, iBGP es más una herramienta de escalabilidad que un protocolo de enrutamiento;
• Si ejecuta eBGP, no necesita una malla completa de sesiones BGP para flujos de tráfico óptimos de extremo a extremo; El procesamiento del siguiente salto de BGP resuelve bien esos problemas.

Consulte http://blog.ioshints.info/2011/08/bgp-next-hop-processing.html para obtener más detalles.

Muy bien podría ejecutar OSPF (u otro IGP) en un servicio de metro-Ethernet multipunto, y debería funcionar muy bien.

Sin embargo, podría haber razones para continuar ejecutando BGP ... aunque serían los mismos argumentos de por qué es posible que también desee ejecutar BGP dentro de su propia red.

No necesariamente tiene que poner todos sus altavoces BGP en el mismo AS en una red de "transmisión" como esa. Piense en ello como una especie de IXP interno ejecutado por las telecomunicaciones donde sus AS privados pueden interconectarse entre sí a través de una malla de capa 2. Ni siquiera tendría que mantener necesariamente una malla completa de pares BGP ya que las actualizaciones BGP pueden llevar un siguiente salto en su mensaje de actualización que no es el mismo de donde proviene la sesión de pares.

Entonces, por ejemplo, si tiene una malla de capa 2 con los enrutadores A, B y C y tiene pares BGP entre A y B, y entre B y C, cuando C obtiene actualizaciones para las rutas originadas en A, será tenga A como el siguiente salto, a pesar de que se aprendieron a través de la sesión de emparejamiento con B. Obviamente, querría más emparejamiento de ruta que un solo concentrador y radio, por lo que no depende del concentrador único, pero usted no necesita una malla completa de ninguna manera.

Aún así, obtiene todos los beneficios de la política de enrutamiento de ejecutar BGP si lo hace de esta manera ... y también, como mencionó otro encuestado, puede usar el mismo espacio de número AS privado e incluso podría interconectarse con el L3VPN existente para que su modelo y Los mecanismos de apoyo no necesitan cambiar.

Dicho esto, tengo un par de enlaces metro-E (punto a punto en mi caso) con los que ejecuto OSPF e iBGP y funciona bien.

¿Qué pasa con una configuración de servidor de ruta con 'radios' siendo rs-clientes de los enrutadores principales / concentradores?

A pesar de que los pares bgp serían como una topología de concentrador y radio, todos los radios deberían poder enviar tráfico directamente a todos los demás.

Incluso podría reutilizar los mismos números AS privados que los utilizados con el proveedor MPLS para facilitar la migración de un servicio a otro.

Recomiendo encarecidamente leer y tomar una decisión con respecto a las topologías OSPF alternativas, como comenzar como NBMA en lugar de estándar. Pronto se dará cuenta de que OSPF no puede seleccionar correctamente entre dos rutas que van al mismo enrutador / sitio dentro de la misma red Ethernet, debido a la forma en que se calcula el costo a través de la interfaz de salida, los enlaces WAN principales y de respaldo aparecerán igual costo en OSPF estándar. Sin embargo, si elige usar NBMA, por ejemplo, puede definir manualmente los costos vecinos, pero ahora tiene que definir manualmente las mallas / adyacencias.

Hagas lo que hagas, RUTA POR ELLA NO REPITO NO SE UNE A LA CAPA 2, solo está pidiendo problemas más adelante, si necesita interconectividad de capa 2, use OTV u otra característica de capa 2 sobre capa 3.

Descubrirá rápidamente que aprenderá mucho más sobre OSPF (y necesita saber mucho más) en comparación con un simple proveedor MPLS-VPN donde el núcleo WAN está oculto para usted.

OSPF sobre metroE funciona bien, pero tendrá que asegurarse de que se ajuste a sus necesidades y de diseñar en consecuencia. Una advertencia que no he visto mencionada es asegurarse de que sabe qué MTU admite su proveedor. He visto una caída de MTU en un enlace de metroE durante el mantenimiento de un proveedor que hace que el vecino OSPF no aparezca. Probablemente solo sea un problema porque en realidad no son compatibles con los marcos gigantes pero lo hicieron solo por nosotros :) Ser amable a veces no vale la pena.