Optimización de enrutamiento de ExpressRoute

Cuando hay varios circuitos ExpressRoute, tiene más de una ruta de acceso para conectarse a Microsoft. Como resultado, se puede producir un enrutamiento no óptimo: es decir, el tráfico puede utilizar una ruta más larga para conectarse con Microsoft y este a su vez, con su red. Cuanto más larga sea la ruta de acceso a la red, mayor será la latencia. La latencia tiene un efecto directo en la experiencia del usuario y en el rendimiento de las aplicaciones. En este artículo se describe este problema y se explica cómo optimizar el enrutamiento mediante las tecnologías de enrutamiento estándar.

Selección de rutas en el emparejamiento de Microsoft

Es importante asegurarse de que, al usar Microsoft, el tráfico fluya a través de la ruta deseada si se tienen uno o varios circuitos de ExpressRoute. También debe asegurarse de que las rutas de acceso a Internet usan un Intercambio de Internet (IX) o un proveedor de servicios de Internet (ISP). BGP emplea un algoritmo de selección de la mejor ruta basado en muchos factores, entre los que se incluye la coincidencia de prefijo más larga (LPM). Para asegurarse de que el tráfico destinado a Azure a través de Microsoft atraviese la ruta de ExpressRoute, deberá implementar el atributo Preferencia local. Esta configuración garantiza que la ruta de acceso siempre se prefiera en ExpressRoute.

Nota:

La preferencia local predeterminada suele ser 100. Las preferencias locales más altas son más preferidas.

Considere el escenario de ejemplo siguiente:

En el ejemplo anterior, para preferir las rutas de ExpressRoute, configure la preferencia local como se indica a continuación.

Configuración de Cisco IOS-XE desde la perspectiva de R1:

• R1(config)#route-map prefer-ExR permit 10

• R1(config-route-map)#set local-preference 150

• R1(config)#router BGP 345

• R1(config-router)#neighbor 1.1.1.2 remote-as 12076

• R1(config-router)#neighbor 1.1.1.2 activate

• R1(config-router)#neighbor 1.1.1.2 route-map prefer-ExR in

Configuración de Junos desde la perspectiva de R1:

• user@R1# set protocols bgp group ibgp type internal
• user@R1# set protocols bgp group ibgp local-preference 150

Enrutamiento no óptimo de cliente a Microsoft

Eche un vistazo más detenidamente al problema del enrutamiento mediante un ejemplo. Imagine que tiene dos oficinas en Estados Unidos, una en Los Ángeles y la otra en Nueva York. Las oficinas están conectadas a una red de área extensa (WAN), que puede ser su propia red troncal o la VPN de la dirección IP del proveedor de servicios. Tiene dos circuitos ExpressRoute, uno en el Oeste de EE. UU. y otro en el Este de EE. UU. Ambos también están conectados en la WAN. Obviamente, tiene dos rutas de acceso para conectarse a la red de Microsoft.

Ahora supongamos que tiene una implementación de Azure (por ejemplo, una instancia de Azure App Service) en el Oeste de EE. UU. y en el Este de EE. UU. Su intención es conectar los usuarios de Los Ángeles a Azure en el Oeste de EE. UU. y los usuarios de Nueva York a Azure en el Este de EE. UU. El motivo de esta configuración es que el administrador del servicio indica a los usuarios de cada oficina que accedan a los servicios de Azure cercanos para obtener experiencias óptimas. El plan funciona bien para los usuarios de la costa este, pero no para los usuarios de la costa oeste.

El problema se debe a que, en cada circuito ExpressRoute, se indica en el entorno local tanto el prefijo para la implementación de Azure del Este de EE. UU. 23.100.0.0/16 como el prefijo para Azure del Oeste de EE. UU. 13.100.0.0/16. Si no sabe qué prefijo pertenece a cada región, probablemente los tratará de la misma forma. La red WAN puede considerar que ambos prefijos están más próximos a la implementación del este de EE.UU. que a la del oeste y, por tanto, enrutará a los usuarios de ambas oficinas al circuito ExpressRoute del este. Al final, tendrá muchos usuarios descontentos en la oficina de Los Ángeles.

Solución: utilice comunidades de BGP.

Para optimizar el enrutamiento para los usuarios de ambas oficinas, debe saber qué prefijo pertenece al oeste y qué prefijo al este. Esta información se codifica mediante los valores de las comunidades de BGP. Se ha asignado un valor único de comunidad de BGP para cada región de Azure, por ejemplo, 12076:51004 para el Este de EE. UU., y 12076:51006 para el Oeste de EE. UU. Ahora que sabe qué prefijo pertenece a cada región de Azure, puede configurar qué circuito de ExpressRoute debe ser el preferido. Como se utiliza el BGP para intercambiar información de enrutamiento, puede usar la preferencia local de BGP para influir en el enrutamiento.

En nuestro ejemplo, puede asignar un valor de preferencia local superior a 13.100.0.0/16 para el oeste y, de forma similar, un valor de preferencia local superior a 23.100.0.0/16 para el este. Esta configuración garantiza que, cuando estén disponibles ambas rutas de acceso a Microsoft, los usuarios de Los Ángeles utilizarán el circuito de ExpressRoute del Oeste de EE. UU. para conectarse a la implementación oeste de Azure, mientras que los usuarios de Nueva York utilizarán el del Este de EE. UU. para conectarse a la implementación este. Con lo cual, se obtendrá un enrutamiento óptimo en ambas regiones.

Nota

La misma técnica, con preferencia Local, se puede aplicar en el enrutamiento de cliente a la red virtual de Azure cuando se usa el emparejamiento privado. Microsoft no etiqueta los valores de la comunidad de BGP a los prefijos anunciados de Azure a la red. Sin embargo, dado que se sabe cuál de las implementaciones de la red virtual está cerca de cada oficina, puede configurar en consecuencia los enrutadores para que prefieran un circuito ExpressRoute a otro.

Enrutamiento no óptimo de Microsoft al cliente

En este ejemplo, las conexiones de Microsoft toman una ruta de acceso más larga para llegar a la red. En este caso, se utilizan servidores de Exchange locales y Exchange Online en un entorno híbrido. Las oficinas están conectadas a una red WAN. Usted indica los prefijos de los servidores locales de ambas oficinas a Microsoft a través de dos circuitos de ExpressRoute.

Exchange Online inicia las conexiones a los servidores locales en algunos casos como, por ejemplo, la migración de buzones. La conexión a la oficina de Los Ángeles se enruta a través del circuito de ExpressRoute en el Este de EE. UU. antes de atravesar todo el país hasta la costa oeste. La causa del problema es similar a la del primer caso. Sin ninguna indicación, la red de Microsoft no puede saber qué prefijo local está más próximo al Este de EE. UU. y cuál al Oeste de EE. UU. Y sucede que se elige la ruta de acceso incorrecta a la oficina de Los Ángeles.

Solución: anteponga AS PATH

Hay dos soluciones al problema. En primer lugar, indica el prefijo local de la oficina de Los Ángeles, 177.2.0.0/31, en el circuito de ExpressRoute en el Oeste de EE. UU. A continuación, indica el prefijo local de la oficina de Nueva York, 177.2.0.2/31, en el circuito de ExpressRoute en el Este de EE. UU. Como resultado, Microsoft tendrá una única ruta de acceso para conectarse a cada una de sus oficinas. No hay ninguna ambigüedad y, por tanto, el enrutamiento se optimiza. Con este diseño, debe pensar acerca de la estrategia de conmutación por error. Si la ruta de acceso a Microsoft a través de ExpressRoute deja de funcionar, deberá asegurarse de que Exchange Online puede conectarse a los servidores locales a pesar de ello.

La segunda solución es que continúe anunciando ambos prefijos para los dos circuitos de ExpressRoute y, además, nos indique qué prefijo está más cerca de cada una de sus oficinas. Dado que se admite la anteposición de BGP AS Path, puede configurar AS Path como prefijo para que influya en el enrutamiento. En este ejemplo, puede alargar AS PATH para 172.2.0.0/31 en el Este de EE. UU. para que se prefiera el circuito de ExpressRoute del Oeste de EE. UU. para el tráfico destinado a este prefijo. De igual manera, puede alargar AS PATH para 172.2.0.2/31 en el Oeste de EE. UU. para que se prefiera el circuito de ExpressRoute en el Este de EE. UU. De esta forma, se optimizará el enrutamiento para ambas oficinas. Con este diseño, si se interrumpe un circuito de ExpressRoute, Exchange Online podrá conectarse a través de otro circuito de ExpressRoute y de la red WAN.

Importante

Al realizar el emparejamiento con números de AS privados, estos números se quitan de AS PATH en los prefijos recibidos en el emparejamiento de Microsoft. Para influir en el enrutamiento del emparejamiento de Microsoft, este se debe realizar con un AS público y asociar ese número en AS PATH.

Nota:

Aunque los ejemplos que se proporcionan aquí son para emparejamientos de Microsoft, se admiten las mismas funcionalidades para emparejamientos privados. Además, la ruta de acceso de AS antepuesta funciona dentro de un único circuito ExpressRoute, para influir en la selección de las rutas de acceso principales y secundarias.

Enrutamiento no óptimo entre redes virtuales

Con ExpressRoute, puede habilitar la comunicación de una instancia de Virtual Network a otra instancia de Virtual Network (también conocidas cada una como "VNet" o "red virtual") vinculándolas a un circuito de ExpressRoute. Cuando se vinculan a varios circuitos de ExpressRoute, puede producirse enrutamiento no óptimo entre las redes virtuales. Veamos un ejemplo. Tiene dos circuitos ExpressRoute, uno en el Oeste de EE. UU. y otro en el Este de EE. UU. En cada región, tiene dos redes virtuales. Los servidores web están implementados en una red virtual y los servidores de aplicaciones en la otra. Para conseguir redundancia, vincule las dos redes virtuales en cada región tanto al circuito de ExpressRoute local como al remoto. Como puede verse en el diagrama siguiente, de cada red virtual hay dos rutas de acceso a la otra red virtual. Las redes virtuales no saben cuál circuito de ExpressRoute es el local y cuál es el remoto. Dado que enrutamiento multidireccional de igual costo (ECMP) se utiliza para equilibrar la carga del tráfico entre redes virtuales, algunos flujos de tráfico toman la ruta de acceso más larga y se enrutan al circuito de ExpressRoute remoto.

Solución: asignar un peso alto a la conexión local

La solución es sencilla. Dado que usted sabe dónde están las redes virtuales y los circuitos, puede decirnos cuál debería ser la ruta de acceso preferida de cada red virtual. Específicamente para este ejemplo, se asigna a la conexión local un peso mayor que a la conexión remota (vea el ejemplo de configuración aquí). Cuando una red virtual recibe el prefijo de la otra red virtual en varias conexiones, prefiere la conexión con el mayor peso para enviar el tráfico destinado a ese prefijo.

Nota:

También puede influir en el enrutamiento de la red virtual a la red local, si tiene varios circuitos ExpressRoute, configurando el peso de una conexión en lugar de aplicar la anteposición de la ruta de acceso AS, una técnica que se describe en el segundo escenario. Para cada prefijo siempre atenderemos primero al peso de la conexión antes que a la longitud de ruta de acceso AS a la hora de decidir cómo enviar tráfico.

Pasos siguientes

• Obtenga información sobre el diseño de ExpressRoute para alta disponibilidad.
• Obtenga información sobre el diseño de ExpressRoute para la recuperación ante desastres.