Implementación de ExpressRoute para Microsoft 365

Este artículo se aplica a Microsoft 365 Enterprise.

ExpressRoute para Microsoft 365 proporciona una ruta de acceso de enrutamiento alternativa a muchos servicios de Microsoft 365 accesibles desde Internet. La arquitectura de ExpressRoute para Microsoft 365 se basa en la publicidad de prefijos IP públicos de los servicios de Microsoft 365 a los que ya se puede acceder a través de Internet en los circuitos ExpressRoute aprovisionados para la redistribución posterior de esos prefijos IP en la red. Con ExpressRoute, habilita de forma eficaz varias rutas de enrutamiento diferentes, a través de Internet y a través de ExpressRoute, para muchos servicios de Microsoft 365. Este estado de enrutamiento en la red puede representar un cambio significativo en la forma en que se diseña la topología de red interna.

Nota:

No se recomienda ExpressRoute para Microsoft 365 porque no proporciona el mejor modelo de conectividad para el servicio en la mayoría de las circunstancias. Por lo tanto, se requiere autorización de Microsoft para usar este modelo de conectividad. Revisamos cada solicitud de cliente y autorizamos ExpressRoute para Microsoft 365 solo en los escenarios poco frecuentes en los que sea necesario. Lea la guía de ExpressRoute para Microsoft 365 para obtener más información y, después de una revisión completa del documento con los equipos de productividad, red y seguridad, trabaje con el equipo de su cuenta microsoft para enviar una excepción si es necesario. Las suscripciones no autorizadas que intenten crear filtros de ruta para Microsoft 365 recibirán un mensaje de error.

Debe planear cuidadosamente la implementación de ExpressRoute para Microsoft 365 para adaptarse a las complejidades de red de tener el enrutamiento disponible a través de un circuito dedicado con rutas insertadas en la red principal e Internet. Si usted y su equipo no realizan el planeamiento y las pruebas detallados en esta guía, existe un alto riesgo de que experimente una pérdida intermitente o una pérdida total de conectividad con los servicios de Microsoft 365 cuando el circuito ExpressRoute esté habilitado.

Para tener una implementación correcta, tendrá que analizar los requisitos de la infraestructura, examinar la evaluación y el diseño detallados de la red, planear cuidadosamente el lanzamiento de forma provisional y controlada, y crear un plan detallado de validación y pruebas. Para un entorno grande y distribuido, no es raro ver que las implementaciones abarcan varios meses. Esta guía está diseñada para ayudarle a planear con antelación.

Las implementaciones de gran éxito pueden tardar seis meses en planearse e incluir a menudo miembros del equipo de muchas áreas de la organización, como redes, administradores de firewall y servidor proxy, administradores de Microsoft 365, seguridad, soporte técnico para el usuario final, administración de proyectos y patrocinio ejecutivo. La inversión en el proceso de planeación reducirá la probabilidad de que experimente errores de implementación que darán lugar a tiempo de inactividad o a una solución de problemas compleja y costosa.

Esperamos que se completen los siguientes requisitos previos antes de iniciar esta guía de implementación.

1. Ha completado una evaluación de red para determinar si Se recomienda y aprueba ExpressRoute.

2. Ha seleccionado un proveedor de servicios de red de ExpressRoute. Busque detalles sobre los asociados de ExpressRoute y las ubicaciones de emparejamiento.

3. Ya ha leído y comprendido la documentación de ExpressRoute y la red interna puede cumplir los requisitos previos de ExpressRoute de un extremo a otro.

4. El equipo ha leído toda la guía pública y la documentación en https://aka.ms/expressrouteoffice365, https://aka.ms/erty ha visto la serie de entrenamiento de Azure ExpressRoute para Microsoft 365 en Channel 9 para comprender los detalles técnicos críticos, entre los que se incluyen:

   • Dependencias de Internet de los servicios SaaS.

   • Cómo evitar rutas asimétricas y controlar el enrutamiento complejo.

   • Incorporación de controles perimetrales de seguridad, disponibilidad y nivel de aplicación.

Empezar por recopilar requisitos

Empiece por determinar qué características y servicios planea adoptar dentro de su organización. Debe determinar qué características de los diferentes servicios de Microsoft 365 se usarán y qué ubicaciones de la red hospedarán a las personas que usen esas características. Con el catálogo de escenarios, debe agregar los atributos de red que cada uno de esos escenarios requiere; como flujos de tráfico de red entrantes y salientes y si los puntos de conexión de Microsoft 365 están disponibles a través de ExpressRoute o no.

Para recopilar los requisitos de la organización:

• Cataloge el tráfico de red entrante y saliente para los servicios de Microsoft 365 que usa su organización. Consulte la página Direcciones URL y intervalos de direcciones IP de Microsoft 365 para obtener la descripción de los flujos que requieren distintos escenarios de Microsoft 365.

• Recopile la documentación de la topología de red existente que muestra los detalles de la red troncal y la topología interna de WAN, la conectividad de los sitios satélite, la conectividad de usuario de última milla, el enrutamiento a los puntos de salida perimetrales de red y los servicios proxy.

  • Identifique los puntos de conexión de servicio entrantes en los diagramas de red a los que se conectarán Microsoft 365 y otros servicios de Microsoft, que muestran las rutas de conexión a Internet y a las rutas de conexión de ExpressRoute propuestas.

  • Identifique todas las ubicaciones de usuarios geográficos y la conectividad WAN entre ubicaciones, junto con las ubicaciones que actualmente tienen una salida a Internet y qué ubicaciones se proponen para tener una salida a una ubicación de emparejamiento de ExpressRoute.

  • Identifique todos los dispositivos perimetrales, como servidores proxy, firewalls, etc., y cataloge su relación con los flujos que pasan por Internet y ExpressRoute.

  • Documente si los usuarios finales accederán a los servicios de Microsoft 365 a través de Enrutamiento directo o proxy indirecto de aplicación para flujos de Internet y ExpressRoute.

• Agregue la ubicación del inquilino y las ubicaciones meet-me al diagrama de red.

• Calcule las características de rendimiento y latencia de red esperadas y observadas desde las principales ubicaciones de usuario a Microsoft 365. Tenga en cuenta que Microsoft 365 es un conjunto global y distribuido de servicios y los usuarios se conectarán a ubicaciones que pueden ser diferentes de la ubicación de su inquilino. Por este motivo, se recomienda medir y optimizar la latencia entre el usuario y el perímetro más cercano de la red global de Microsoft a través de ExpressRoute y conexiones a Internet. Puede usar los resultados de la evaluación de red para ayudar con esta tarea.

• Enumera la seguridad de red de la empresa y los requisitos de alta disponibilidad que deben cumplirse con la nueva conexión de ExpressRoute. Por ejemplo, cómo los usuarios siguen obteniendo acceso a Microsoft 365 en caso de que se produzca un error de salida de Internet o del circuito ExpressRoute.

• Documente qué flujos de red entrantes y salientes de Microsoft 365 usarán la ruta de acceso de Internet y cuáles usarán ExpressRoute. Los detalles de las ubicaciones geográficas de los usuarios y los detalles de la topología de red local pueden requerir que el plan sea diferente de una ubicación de usuario a otra.

Catalogar el tráfico de red saliente y entrante

Para minimizar el enrutamiento y otras complejidades de red, se recomienda usar solo ExpressRoute para Microsoft 365 para los flujos de tráfico de red necesarios para pasar por una conexión dedicada debido a los requisitos normativos o como resultado de la evaluación de la red. Además, se recomienda almacenar provisionalmente el ámbito del enrutamiento de ExpressRoute y abordar los flujos de tráfico de red saliente y entrante como fases diferentes y distintas del proyecto de implementación. Implementar ExpressRoute para Microsoft 365 solo para flujos de tráfico de red saliente iniciados por el usuario y dejar flujos de tráfico de red entrantes a través de Internet puede ayudar a controlar el aumento de la complejidad topológica y los riesgos de introducir posibilidades adicionales de enrutamiento asimétrico.

El catálogo de tráfico de red debe contener listas de todas las conexiones de red entrantes y salientes que tendrá entre la red local y Microsoft.

• Los flujos de tráfico de red salientes son escenarios en los que se inicia una conexión desde el entorno local, como desde clientes o servidores internos, con un destino de los servicios de Microsoft. Estas conexiones pueden ser directas a Microsoft 365 o indirectas, como cuando la conexión pasa a través de servidores proxy, firewalls u otros dispositivos de red en la ruta de acceso a Microsoft 365.

• Los flujos de tráfico de red entrantes son escenarios en los que se inicia una conexión desde la nube de Microsoft a un host local. Estas conexiones suelen tener que pasar por el firewall y otras infraestructuras de seguridad que requiere la directiva de seguridad del cliente para los flujos originados externamente.

Lea la sección Asegurarse de la simetría de rutas para determinar qué servicios enviarán tráfico entrante y busque la columna marcada como ExpressRoute para Microsoft 365 en el artículo de referencia de puntos de conexión de Microsoft 365 para determinar el resto de la información de conectividad.

Para cada servicio que requiera una conexión saliente, querrá describir la conectividad planeada para el servicio, incluido el enrutamiento de red, la configuración del proxy, la inspección de paquetes y las necesidades de ancho de banda.

Para cada servicio que requiera una conexión entrante, necesitará información adicional. Los servidores de la nube de Microsoft establecerán conexiones a la red local. Para asegurarse de que las conexiones se realizan correctamente, querrá describir todos los aspectos de esta conectividad, incluidos; las entradas dns públicas para los servicios que aceptarán estas conexiones entrantes, las direcciones IP IPv4 con formato CIDR, qué equipo ISP está implicado y cómo se controla NAT de entrada o NAT de origen para estas conexiones.

Las conexiones entrantes deben revisarse independientemente de si se conectan a través de Internet o ExpressRoute para asegurarse de que no se ha introducido el enrutamiento asimétrico. En algunos casos, es posible que otros servicios de Microsoft y que no sean de Microsoft tengan que acceder a los puntos de conexión locales a los que los servicios de Microsoft 365 inician conexiones entrantes. Es fundamental que habilitar el enrutamiento de ExpressRoute a estos servicios con fines de Microsoft 365 no interrumpa otros escenarios. En muchos casos, es posible que los clientes deban implementar cambios específicos en su red interna, como NAT basada en origen, para asegurarse de que los flujos entrantes de Microsoft permanecen simétricos después de habilitar ExpressRoute.

Este es un ejemplo del nivel de detalle necesario. En este caso, Exchange Hybrid se enrutaría al sistema local a través de ExpressRoute.

Connection (propiedad)	Valor
Dirección del tráfico de red	Entrada
Servicio	Exchange Hybrid
Punto de conexión público de Microsoft 365 (origen)	Exchange Online (direcciones IP)
Punto de conexión local público (destino)	5.5.5.5
Entrada DNS pública (Internet)	Autodiscover.contoso.com
¿Usarán este punto de conexión local para otros servicios de Microsoft (que no sean de Microsoft 365)	No
¿Usarán este punto de conexión local los usuarios o sistemas en Internet?	Yes
Sistemas internos publicados a través de puntos de conexión públicos	Exchange Server rol de acceso de cliente (local) 192.168.101, 192.168.102, 192.168.103
Anuncio de IP del punto de conexión público	A Internet: 5.5.0.0/16 a ExpressRoute: 5.5.5.0/24
Controles de seguridad y perímetro	Ruta de acceso a Internet: DeviceID_002 ruta de acceso de ExpressRoute: DeviceID_003
Alta disponibilidad	Activo/activo en 2 circuitos ExpressRoute con redundancia geográfica: Chicago y Dallas
Control de simetría de ruta de acceso	Método: Ruta de acceso de Internet NAT de origen: conexiones entrantes NAT de origen a la ruta de acceso de ExpressRoute 192.168.5.5: conexiones NAT de origen a 192.168.1.0 (Chicago) y 192.168.2.0 (Dallas)

Este es un ejemplo de un servicio que solo es saliente:

Connection (propiedad)	Valor
Dirección del tráfico de red	Salida
Servicio	SharePoint Online
Punto de conexión local (origen)	Estación de trabajo de usuario
Punto de conexión público de Microsoft 365 (destino)	SharePoint Online (direcciones IP)
Entrada DNS pública (Internet)	*.sharepoint.com (y más FQDN)
Referencias de RED CDN	cdn.sharepointonline.com (y más FQDN): direcciones IP mantenidas por proveedores de red CDN)
Anuncio de IP y NAT en uso	Ruta de acceso a Internet/NAT de origen: 1.1.1.0/24 Ruta de acceso de ExpressRoute/NAT de origen: 1.1.2.0/24 (Chicago) y 1.1.3.0/24 (Dallas)
Método de conectividad	Internet: a través del proxy de capa 7 (archivo .pac) ExpressRoute: enrutamiento directo (sin proxy)
Controles de seguridad y perímetro	Ruta de acceso a Internet: DeviceID_002 Ruta de acceso de ExpressRoute: DeviceID_003
Alta disponibilidad	Ruta de acceso a Internet: salida redundante de Internet Ruta de acceso de ExpressRoute: enrutamiento activo o activo de "patata caliente" en dos circuitos ExpressRoute con redundancia geográfica: Chicago y Dallas
Control de simetría de ruta de acceso	Método: NAT de origen para todas las conexiones

Diseño de la topología de red con conectividad regional

Una vez que comprenda los servicios y sus flujos de tráfico de red asociados, puede crear un diagrama de red que incorpore estos nuevos requisitos de conectividad e ilustra los cambios que realizará para usar ExpressRoute para Microsoft 365. El diagrama debe incluir:

1. Todas las ubicaciones de usuario desde las que se accederá a Microsoft 365 y a otros servicios.

2. Todos los puntos de salida de Internet y ExpressRoute.

3. Todos los dispositivos salientes y entrantes que administran la conectividad dentro y fuera de la red, incluidos enrutadores, firewalls, servidores proxy de aplicaciones y detección y prevención de intrusiones.

4. Destinos internos para todo el tráfico entrante, como servidores ADFS internos que aceptan conexiones desde los servidores proxy de aplicación web de ADFS.

5. Catálogo de todas las subredes IP que se anunciarán

6. Identifique cada ubicación desde la que las personas accederán a Microsoft 365 y enumere las ubicaciones de reunión que se usarán para ExpressRoute.

7. Ubicaciones y partes de la topología de red interna, donde se aceptarán, filtrarán y propagarán los prefijos IP de Microsoft aprendidos de ExpressRoute.

8. La topología de red debe ilustrar la ubicación geográfica de cada segmento de red y cómo se conecta a la red de Microsoft a través de ExpressRoute o Internet.

En el diagrama siguiente se muestra cada ubicación desde la que los usuarios usarán Microsoft 365 junto con los anuncios de enrutamiento entrante y saliente a Microsoft 365.

Para el tráfico saliente, los usuarios acceden a Microsoft 365 de una de estas tres maneras:

1. A través de una ubicación de reunión en Norteamérica para la gente de California.

2. A través de una ubicación meet-me en la Región Administrativa Especial de Hong Kong para las personas de la RAE de Hong Kong.

3. A través de Internet en Bangladesh, donde hay menos personas y no se aprovisiona ningún circuito ExpressRoute.

Del mismo modo, el tráfico de red entrante de Microsoft 365 devuelve una de estas tres maneras:

1. A través de una ubicación de reunión en Norteamérica para la gente de California.

2. A través de una ubicación meet-me en la Región Administrativa Especial de Hong Kong para las personas de la RAE de Hong Kong.

3. A través de Internet en Bangladesh, donde hay menos personas y no se aprovisiona ningún circuito ExpressRoute.

Determinación de la ubicación adecuada de meet-me

La selección de ubicaciones meet-me, que son la ubicación física desde la que el circuito ExpressRoute conecta la red a la red de Microsoft, está influenciada por las ubicaciones desde las que las personas accederán a Microsoft 365. Como oferta de SaaS, Microsoft 365 no funciona bajo el modelo regional de IaaS o PaaS de la misma manera que Azure. En su lugar, Microsoft 365 es un conjunto distribuido de servicios de colaboración, donde los usuarios pueden necesitar conectarse a puntos de conexión en varios centros de datos y regiones, que pueden no estar necesariamente en la misma ubicación o región donde se hospeda el inquilino del usuario.

Esto significa que la consideración más importante que debe tener al seleccionar ubicaciones meet-me para ExpressRoute para Microsoft 365 es desde donde se conectarán las personas de su organización. La recomendación general para una conectividad óptima de Microsoft 365 es implementar el enrutamiento, de modo que las solicitudes de los usuarios a los servicios de Microsoft 365 se entreguen a la red de Microsoft a través de la ruta de acceso de red más corta, a menudo también se conoce como enrutamiento "patata caliente". Por ejemplo, si la mayoría de los usuarios de Microsoft 365 están en una o dos ubicaciones, la selección de ubicaciones meet-me que estén en la proximidad más cercana a la ubicación de esos usuarios creará el diseño óptimo. Si su empresa tiene grandes poblaciones de usuarios en muchas regiones diferentes, es posible que desee considerar la posibilidad de tener varios circuitos ExpressRoute y ubicaciones meet-me. Para algunas de las ubicaciones de usuario, es posible que la ruta de acceso más corta o óptima a la red de Microsoft y Microsoft 365 no sea a través de los puntos de reunión de WAN y ExpressRoute internos, sino a través de Internet.

A menudo, hay varias ubicaciones de reunión que se pueden seleccionar dentro de una región con proximidad relativa a los usuarios. Rellene la tabla siguiente para guiar sus decisiones.

Ubicaciones de reunión de ExpressRoute planeadas en California y Nueva York

Ubicación	Número de personas	Latencia esperada en la red de Microsoft a través de la salida de Internet	Latencia esperada en la red de Microsoft a través de ExpressRoute
Los Ángeles	10,000	~15 ms	~10 ms (a través de Silicon Valley)
Washington DC	15 000	~20 ms	~10 ms (a través de Nueva York)
Dallas	5,000	~15 ms	~40 ms (a través de Nueva York)

Una vez que se haya desarrollado la arquitectura de red global que muestra la región de Microsoft 365, las ubicaciones meet-me del proveedor de servicios de red ExpressRoute y la cantidad de personas por ubicación, se puede usar para identificar si se pueden realizar optimizaciones. También puede mostrar conexiones de red de horquilla globales donde el tráfico se enruta a una ubicación lejana con el fin de obtener la ubicación meet-me. Si se detecta una horquilla en la red global, debe corregirse antes de continuar. Busque otra ubicación de meet-me o use puntos de salida selectivos de salida de Internet para evitar la horquilla.

El primer diagrama muestra un ejemplo de un cliente con dos ubicaciones físicas en Norteamérica. Puede ver la información sobre las ubicaciones de office, las ubicaciones de inquilinos de Microsoft 365 y varias opciones para las ubicaciones meet-me de ExpressRoute. En este ejemplo, el cliente ha seleccionado la ubicación meet-me en función de dos principios, en orden:

1. Proximidad más cercana a las personas de su organización.

2. Más cercano a un centro de datos de Microsoft donde se hospeda Microsoft 365.

Ampliando ligeramente este concepto, en el segundo diagrama se muestra un cliente multinacional de ejemplo que se enfrenta a información y toma de decisiones similares. Este cliente tiene una pequeña oficina en Bangladesh con solo un pequeño equipo de diez personas centrado en aumentar su superficie en la región. Hay una ubicación meet-me en Chennai y un centro de datos de Microsoft con Microsoft 365 hospedado en Chennai, por lo que una ubicación meet-me tendría sentido; sin embargo, para diez personas, el gasto del circuito adicional es gravoso. Al examinar la red, deberá determinar si la latencia implicada en el envío del tráfico de red a través de la red es más eficaz que gastar el capital para adquirir otro circuito ExpressRoute.

Como alternativa, las diez personas de Bangladesh pueden experimentar un mejor rendimiento con su tráfico de red enviado a través de Internet a la red de Microsoft de lo que enrutarían en su red interna, como mostramos en los diagramas introductorios y reproducimos a continuación.

Creación del plan de implementación de ExpressRoute para Microsoft 365

El plan de implementación debe abarcar tanto los detalles técnicos de la configuración de ExpressRoute como los detalles de la configuración del resto de la infraestructura de la red, como los siguientes.

• Planee qué servicios se dividen entre ExpressRoute e Internet.

• Planee el ancho de banda, la seguridad, la alta disponibilidad y la conmutación por error.

• Diseñar el enrutamiento entrante y saliente, incluidas las optimizaciones de rutas de enrutamiento adecuadas para diferentes ubicaciones

• Decida hasta dónde se anunciarán las rutas de ExpressRoute en la red y cuál es el mecanismo para que los clientes seleccionen la ruta de acceso de Internet o ExpressRoute; por ejemplo, enrutamiento directo o proxy de aplicación.

• Planee los cambios en los registros DNS, incluidas las entradas del marco de directivas de remitente .

• Planifique la estrategia NAT, incluida la NAT de origen de salida y de entrada.

Planear el enrutamiento con rutas de acceso de red de Internet y ExpressRoute

• Para la implementación inicial, se recomienda usar Internet para todos los servicios entrantes, como el correo electrónico entrante o la conectividad híbrida.

• Planee el enrutamiento DE LAN de cliente de usuario final, como configurar un archivo PAC/WPAD, una ruta predeterminada, servidores proxy y anuncios de ruta BGP.

• Planee el enrutamiento perimetral, incluidos servidores proxy, firewalls y servidores proxy en la nube.

Planear el ancho de banda, la seguridad, la alta disponibilidad y la conmutación por error

Cree un plan para el ancho de banda necesario para cada carga de trabajo principal de Microsoft 365. Calcule por separado los requisitos de ancho de banda de Exchange Online, SharePoint Online y Skype Empresarial Online. Puede usar las calculadoras de estimación que hemos proporcionado para Exchange Online y Skype Empresarial como punto de partida; sin embargo, se requiere una prueba piloto con un ejemplo representativo de los perfiles de usuario y las ubicaciones para comprender completamente las necesidades de ancho de banda de su organización.

Agregue cómo se controla la seguridad en cada ubicación de salida de Internet y ExpressRoute al plan, recuerde que todas las conexiones de ExpressRoute a Microsoft 365 usan el emparejamiento público y deben protegerse de acuerdo con las directivas de seguridad de su empresa de conexión a redes externas.

Agregue detalles a su plan sobre qué personas se verán afectadas por el tipo de interrupción y cómo esas personas podrán realizar su trabajo a plena capacidad de la manera más sencilla.

Planear los requisitos de ancho de banda, incluidos los requisitos de Skype Empresarial en Jitter, Latency, Congestion y Headroom

Skype Empresarial Online también tiene requisitos de red adicionales específicos, que se detallan en el artículo Calidad de los medios y Rendimiento de conectividad de red en Skype Empresarial Online.

Lea la sección Planeamiento del ancho de banda para Azure ExpressRoute. Al realizar una evaluación del ancho de banda con los usuarios piloto, puede usar nuestra guía de optimización del rendimiento de Microsoft 365 mediante líneas base y el historial de rendimiento.

Planear los requisitos de alta disponibilidad

Cree un plan de alta disponibilidad para satisfacer sus necesidades e incorpore esto en el diagrama de topología de red actualizado. Lea la sección Alta disponibilidad y conmutación por error con Azure ExpressRoute.

Planear los requisitos de seguridad de red

Cree un plan para cumplir los requisitos de seguridad de red e incorpore esto en el diagrama de topología de red actualizado. Lea la sección Aplicación de controles de seguridad a Escenarios de Azure ExpressRoute para Microsoft 365.

Diseño de la conectividad de servicio saliente

ExpressRoute para Microsoft 365 tiene requisitos de red salientes que pueden no estar familiarizados. En concreto, las direcciones IP que representan a los usuarios y redes a Microsoft 365 y actúan como puntos de conexión de origen para las conexiones de red salientes a Microsoft deben seguir los requisitos específicos que se describen a continuación.

1. Los puntos de conexión deben ser direcciones IP públicas que estén registradas en su empresa o en el operador que le proporcione conectividad de ExpressRoute.

2. Los puntos de conexión deben anunciarse en Microsoft y ExpressRoute debe validarlo o aceptarlo.

3. Los puntos de conexión no deben anunciarse en Internet con la misma métrica de enrutamiento o más preferida.

4. Los puntos de conexión no se deben usar para la conectividad con servicios de Microsoft que no están configurados a través de ExpressRoute.

Si el diseño de red no cumple estos requisitos, hay un alto riesgo de que los usuarios experimenten errores de conectividad en Microsoft 365 y otros servicios de Microsoft debido a la holing negro de rutas o al enrutamiento asimétrico. Esto ocurre cuando las solicitudes a los servicios de Microsoft se enrutan a través de ExpressRoute, pero las respuestas se enrutan a través de Internet, o viceversa, y las respuestas se quitan mediante dispositivos de red con estado, como firewalls.

El método más común que puede usar para cumplir los requisitos anteriores es usar NAT de origen, ya sea implementado como parte de la red o proporcionado por el operador de ExpressRoute. NAT de origen le permite abstraer los detalles y el direccionamiento IP privado de la red de Internet desde ExpressRoute y; junto con anuncios de ruta IP adecuados, proporcione un mecanismo fácil para garantizar la simetría de la ruta de acceso. Si usa dispositivos de red con estado específicos de las ubicaciones de emparejamiento de ExpressRoute, debe implementar grupos NAT independientes para cada emparejamiento de ExpressRoute para garantizar la simetría de ruta de acceso.

Obtenga más información sobre los requisitos de NAT de ExpressRoute.

Agregue los cambios de la conectividad saliente al diagrama de topología de red.

Diseño de la conectividad de servicio entrante

La mayoría de las implementaciones de Microsoft 365 empresariales asumen algún tipo de conectividad de entrada de Microsoft 365 a servicios locales, como para Exchange, SharePoint y Skype Empresarial escenarios híbridos, migraciones de buzones y autenticación mediante la infraestructura de ADFS. Cuando ExpressRoute habilita una ruta de enrutamiento adicional entre la red local y Microsoft para la conectividad saliente, estas conexiones entrantes pueden verse afectadas involuntariamente por el enrutamiento asimétrico, incluso si piensa que esos flujos seguirán usando Internet. Se recomiendan algunas precauciones que se describen a continuación para asegurarse de que no haya ningún impacto en los flujos de entrada basados en Internet desde Microsoft 365 a sistemas locales.

Para minimizar los riesgos del enrutamiento asimétrico para los flujos de tráfico de red entrantes, todas las conexiones entrantes deben usar NAT de origen antes de que se enruten en segmentos de la red, que tienen visibilidad de enrutamiento en ExpressRoute. Si las conexiones entrantes se permiten en un segmento de red con visibilidad de enrutamiento en ExpressRoute sin NAT de origen, las solicitudes que se originan en Microsoft 365 entrarán desde Internet, pero la respuesta que vuelva a Microsoft 365 preferirá la ruta de acceso de red de ExpressRoute de vuelta a la red de Microsoft, lo que provocará el enrutamiento asimétrico.

Puede considerar uno de los siguientes patrones de implementación para satisfacer este requisito:

1. Realice NAT de origen antes de que las solicitudes se enruten a la red interna mediante equipos de red como firewalls o equilibradores de carga en la ruta de acceso desde Internet a los sistemas locales.

2. Asegúrese de que las rutas de ExpressRoute no se propaguen a los segmentos de red donde residen los servicios entrantes, como servidores front-end o sistemas de proxy inverso, que controlan las conexiones a Internet.

Tener en cuenta explícitamente estos escenarios en la red y mantener todos los flujos de tráfico de red entrantes a través de Internet ayuda a minimizar el riesgo operativo y de implementación del enrutamiento asimétrico.

Puede haber casos en los que puede optar por dirigir algunos flujos de entrada a través de conexiones ExpressRoute. Para estos escenarios, tenga en cuenta las siguientes consideraciones adicionales.

1. Microsoft 365 solo puede dirigirse a puntos de conexión locales que usan direcciones IP públicas. Esto significa que, incluso si el punto de conexión de entrada local solo está expuesto a Microsoft 365 a través de ExpressRoute, todavía debe tener asociada la dirección IP pública.

2. Toda la resolución de nombres DNS que realizan los servicios de Microsoft 365 para resolver los puntos de conexión locales se produce mediante DNS público. Esto significa que debe registrar el FQDN de los puntos de conexión de servicio entrantes en las asignaciones de IP en Internet.

3. Para recibir conexiones de red entrantes a través de ExpressRoute, las subredes IP públicas de estos puntos de conexión deben anunciarse a Microsoft a través de ExpressRoute.

4. Evalúe cuidadosamente estos flujos de tráfico de red entrantes para asegurarse de que se les aplican controles de red y seguridad adecuados de acuerdo con las directivas de red y seguridad de la empresa.

5. Una vez que los puntos de conexión de entrada locales se anuncian a Microsoft a través de ExpressRoute, ExpressRoute se convertirá efectivamente en la ruta de acceso de enrutamiento preferida a esos puntos de conexión para todos los servicios de Microsoft, incluido Microsoft 365. Esto significa que esas subredes de punto de conexión solo deben usarse para las comunicaciones con servicios de Microsoft 365 y ningún otro servicio de la red de Microsoft. De lo contrario, el diseño provocará un enrutamiento asimétrico donde las conexiones entrantes de otros servicios de Microsoft prefieren enrutar la entrada a través de ExpressRoute, mientras que la ruta de acceso de retorno usará Internet.

6. En caso de que un circuito ExpressRoute o una ubicación de meet-me estén inactivos, deberá asegurarse de que los puntos de conexión de entrada locales siguen estando disponibles para aceptar solicitudes a través de una ruta de acceso de red independiente. Esto puede significar la publicidad de subredes para esos puntos de conexión a través de varios circuitos ExpressRoute.

7. Se recomienda aplicar NAT de origen para todos los flujos de tráfico de red entrantes que entran en la red a través de ExpressRoute, especialmente cuando estos flujos fluyen entre dispositivos de red con estado, como firewalls.

8. Algunos servicios locales, como el proxy de ADFS o la detección automática de Exchange, pueden recibir solicitudes entrantes de los servicios de Microsoft 365 y de los usuarios de Internet. Para estas solicitudes, Microsoft 365 tendrá como destino el mismo FQDN que las solicitudes de usuario a través de Internet. Permitir conexiones de usuario entrantes desde Internet a esos puntos de conexión locales, al tiempo que se obliga a las conexiones de Microsoft 365 a usar ExpressRoute, representa una complejidad de enrutamiento significativa. Para la gran mayoría de los clientes que implementan este tipo de escenarios complejos a través de ExpressRoute no se recomienda debido a consideraciones operativas. Esta sobrecarga adicional incluye la administración de riesgos de enrutamiento asimétrico y requerirá que administre cuidadosamente los anuncios de enrutamiento y las directivas en varias dimensiones.

Actualizar el plan de topología de red para mostrar cómo evitar rutas asimétricas

Quiere evitar el enrutamiento asimétrico para asegurarse de que los usuarios de su organización puedan usar Microsoft 365 sin problemas, así como otros servicios importantes en Internet. Hay dos configuraciones comunes que los clientes tienen que provocan el enrutamiento asimétrico. Ahora es un buen momento para revisar la configuración de red que va a usar y comprobar si podría existir uno de estos escenarios de enrutamiento asimétrico.

Para empezar, examinaremos algunas situaciones diferentes asociadas con el siguiente diagrama de red. En este diagrama, todos los servidores que reciben solicitudes entrantes, como ADFS o servidores híbridos locales, se encuentran en el centro de datos de Nueva Jersey y se anuncian en Internet.

1. Aunque la red perimetral es segura, no hay ninguna NAT de origen disponible para las solicitudes entrantes.

2. Los servidores del centro de datos de Nueva Jersey pueden ver las rutas de Internet y ExpressRoute.

También tenemos sugerencias sobre cómo corregirlas.

Problema 1: Conexión de nube a local a través de Internet

En el diagrama siguiente se muestra la ruta de acceso de red asimétrica que se toma cuando la configuración de red no proporciona NAT para las solicitudes entrantes desde la nube de Microsoft a través de Internet.

1. La solicitud de entrada de Microsoft 365 recupera la dirección IP del punto de conexión local de DNS público y envía la solicitud a la red perimetral.

2. En esta configuración defectuosa, no hay ninguna NAT de origen configurada o disponible en la red perimetral donde se envía el tráfico, lo que da lugar a que la dirección IP de origen real se use como destino de devolución.

• El servidor de la red enruta el tráfico devuelto a Microsoft 365 a través de cualquier conexión de red de ExpressRoute disponible.

• El resultado es una ruta asimétrica para ese flujo a Microsoft 365, lo que da como resultado una conexión interrumpida.

Solución 1a: NAT de origen

Simplemente agregar una NAT de origen a la solicitud entrante resuelve esta red mal configurada. En este diagrama:

1. La solicitud entrante continúa ingresando a través de la red perimetral del centro de datos de Nueva Jersey. Esta vez nat de origen está disponible.

2. La respuesta del servidor vuelve a dirigirse a la dirección IP asociada a nat de origen en lugar de a la dirección IP original, lo que da lugar a que la respuesta vuelva a lo largo de la misma ruta de acceso de red.

Solución 1b: Ámbito de ruta

Como alternativa, puede optar por no permitir que se anuncie los prefijos BGP de ExpressRoute, quitando la ruta de acceso de red alternativa para esos equipos. En este diagrama:

1. La solicitud entrante continúa ingresando a través de la red perimetral del centro de datos de Nueva Jersey. Esta vez los prefijos anunciados por Microsoft a través del circuito ExpressRoute no están disponibles para el centro de datos de Nueva Jersey.

2. La respuesta del servidor vuelve a dirigirse a la dirección IP asociada a la dirección IP original a través de la única ruta disponible, lo que da lugar a que la respuesta vuelva a lo largo de la misma ruta de acceso de red.

Problema 2: Conexión de nube a local a través de ExpressRoute

En el diagrama siguiente se muestra la ruta de acceso de red asimétrica que se toma cuando la configuración de red no proporciona NAT para las solicitudes entrantes desde la nube de Microsoft a través de ExpressRoute.

1. La solicitud de entrada de Microsoft 365 recupera la dirección IP de DNS y envía la solicitud a la red perimetral.

2. En esta configuración defectuosa, no hay ninguna NAT de origen configurada o disponible en la red perimetral donde se envía el tráfico, lo que da lugar a que la dirección IP de origen real se use como destino de devolución.

• El equipo de la red enruta el tráfico devuelto a Microsoft 365 a través de cualquier conexión de red de ExpressRoute disponible.

• El resultado es una conexión asimétrica a Microsoft 365.

Solución 2: NAT de origen

Simplemente agregar una NAT de origen a la solicitud entrante resuelve esta red mal configurada. En este diagrama:

1. La solicitud entrante continúa ingresando a través de la red perimetral del centro de datos de Nueva York. Esta vez nat de origen está disponible.

2. La respuesta del servidor vuelve a dirigirse a la dirección IP asociada a nat de origen en lugar de a la dirección IP original, lo que da lugar a que la respuesta vuelva a lo largo de la misma ruta de acceso de red.

Comprobar en papel que el diseño de red tiene simetría de ruta de acceso

En este punto, debe comprobar en papel que el plan de implementación ofrece simetría de ruta para los distintos escenarios en los que usará Microsoft 365. Identificará la ruta de red específica que se espera que se tome cuando una persona use distintas características del servicio. Desde la red local y el enrutamiento WAN, a los dispositivos perimetrales, a la ruta de acceso de conectividad; ExpressRoute o Internet, y en la conexión al punto de conexión en línea.

Tendrá que hacerlo para todos los servicios de red de Microsoft 365 que se identificaron anteriormente como servicios que su organización adoptará.

Ayuda a hacer este tutorial de las rutas con una segunda persona. Explíqueles de dónde se espera que cada salto de red obtenga su siguiente ruta y asegúrese de que está familiarizado con las rutas de acceso de enrutamiento. Recuerde que ExpressRoute siempre proporcionará una ruta con más ámbito a las direcciones IP del servidor de Microsoft, lo que le proporcionará un costo de ruta menor que una ruta predeterminada de Internet.

Configuración de conectividad de cliente de diseño

Si usa un servidor proxy para el tráfico enlazado a Internet, debe ajustar los archivos de configuración de cliente o PAC para asegurarse de que los equipos cliente de la red están configurados correctamente para enviar el tráfico de ExpressRoute que desea a Microsoft 365 sin transitar el servidor proxy, y el tráfico restante, incluido algún tráfico de Microsoft 365, se envía al proxy correspondiente. Lea nuestra guía sobre la administración de puntos de conexión de Microsoft 365, por ejemplo, archivos PAC.

Nota:

Los puntos de conexión cambian con frecuencia, tan a menudo como semanalmente. Solo debe realizar cambios en función de los servicios y características que ha adoptado su organización para reducir el número de cambios que tendrá que realizar para mantenerse al día. Preste especial atención a la fecha de entrada en vigor en la fuente RSS donde se anuncian los cambios y se mantiene un registro de todos los cambios pasados, es posible que las direcciones IP anunciadas no se anuncien o se eliminen del anuncio hasta que se alcance la fecha de vigencia.

Garantizar la simetría de rutas

Los servidores front-end de Microsoft 365 son accesibles tanto en Internet como en ExpressRoute. Estos servidores prefieren enrutar de nuevo al entorno local a través de circuitos ExpressRoute cuando ambos estén disponibles. Por este motivo, existe la posibilidad de una asimetría de rutas si el tráfico de la red prefiere enrutar a través de los circuitos de Internet. Las rutas asimétricas son un problema porque los dispositivos que realizan la inspección de paquetes con estado pueden bloquear el tráfico devuelto que sigue una ruta de acceso diferente a los paquetes salientes seguidos.

Independientemente de si inicia una conexión a Microsoft 365 a través de Internet o ExpressRoute, el origen debe ser una dirección enrutable públicamente. Con muchos clientes emparejando directamente con Microsoft, no es factible tener direcciones privadas donde sea posible la duplicación entre los clientes.

A continuación se muestran escenarios en los que se iniciarán las comunicaciones de Microsoft 365 a la red local. Para simplificar el diseño de red, se recomienda enrutar lo siguiente a través de la ruta de Acceso a Internet.

• Servicios SMTP, como correo de un inquilino de Exchange Online a un host local o correo de SharePoint Online enviado desde SharePoint Online a un host local. El protocolo SMTP se usa más ampliamente dentro de la red de Microsoft que los prefijos de ruta compartidos a través de circuitos ExpressRoute y la publicidad de servidores SMTP locales a través de ExpressRoute provocará errores con estos otros servicios.

• ADFS durante la validación de contraseñas para iniciar sesión.

• Exchange Server implementaciones híbridas.

• Búsqueda híbrida federada de SharePoint.

• BCS híbrido de SharePoint.

• Skype Empresarial federación híbrida o Skype Empresarial.

• Skype Empresarial Cloud Connector.

Para que Microsoft vuelva a enrutar a la red para estos flujos de tráfico bidireccionales, las rutas BGP a los dispositivos locales deben compartirse con Microsoft. Al anunciar prefijos de ruta a Microsoft a través de ExpressRoute, debe seguir estos procedimientos recomendados:

1. No anuncie el mismo prefijo de ruta de dirección IP pública a Internet público y a través de ExpressRoute. Se recomienda que los anuncios de prefijo de ruta BGP ip para Microsoft a través de ExpressRoute procedan de un intervalo que no se anuncia a Internet en absoluto. Si esto no es posible lograr debido al espacio de direcciones IP disponible, es esencial asegurarse de anunciar un intervalo más específico a través de ExpressRoute que cualquier circuito de Internet.

2. Use grupos de DIRECCIONES NAT independientes por circuito ExpressRoute y separados del de los circuitos de Internet.

3. Cualquier ruta anunciada a Microsoft atraerá el tráfico de red desde cualquier servidor de la red de Microsoft, no solo aquellas para las que se anuncian rutas a la red a través de ExpressRoute. Anuncie solo rutas a servidores donde el equipo defina y comprenda bien los escenarios de enrutamiento. Anuncie prefijos de ruta de dirección IP independientes en cada uno de los circuitos ExpressRoute de la red.

Alta disponibilidad y conmutación por error con Azure ExpressRoute

Se recomienda aprovisionar al menos dos circuitos activos desde cada salida con ExpressRoute al proveedor de ExpressRoute. Este es el lugar más común donde vemos errores para los clientes y puede evitarlo fácilmente aprovisionando un par de circuitos ExpressRoute activos o activos. También recomendamos al menos dos circuitos de Internet activos o activos porque muchos servicios de Microsoft 365 solo están disponibles a través de Internet.

Dentro del punto de salida de la red hay muchos otros dispositivos y circuitos que desempeñan un papel fundamental en la forma en que las personas perciben la disponibilidad. Estas partes de los escenarios de conectividad no están cubiertas por los ACUERDOs de Nivel de Servicio de ExpressRoute o Microsoft 365, pero desempeñan un papel fundamental en la disponibilidad del servicio de un extremo a otro según lo perciban los usuarios de su organización.

Céntrese en las personas que usan y operan Microsoft 365; si un error de un componente afectaría a la experiencia de los usuarios con el servicio, busque formas de limitar el porcentaje total de personas afectadas. Si un modo de conmutación por error es operativamente complejo, tenga en cuenta la experiencia de los usuarios durante mucho tiempo para la recuperación y busque modos de conmutación por error operativos simples y automatizados.

Fuera de la red, Microsoft 365, ExpressRoute y el proveedor de ExpressRoute tienen distintos niveles de disponibilidad.

Disponibilidad del servicio

• Los servicios de Microsoft 365 están cubiertos por contratos de nivel de servicio bien definidos, que incluyen métricas de tiempo de actividad y disponibilidad para servicios individuales. Una razón por la que Microsoft 365 puede mantener niveles de disponibilidad de servicio tan altos es la capacidad de los componentes individuales para conmutar por error sin problemas entre los muchos centros de datos de Microsoft, mediante la red global de Microsoft. Esta conmutación por error se extiende desde el centro de datos y la red hasta los múltiples puntos de salida de Internet y permite la conmutación por error sin problemas desde la perspectiva de las personas que usan el servicio.

• ExpressRoute proporciona un Acuerdo de Nivel de Servicio de disponibilidad del 99,9 % en circuitos dedicados individuales entre Microsoft Network Edge y el proveedor de ExpressRoute o la infraestructura de asociados. Estos niveles de servicio se aplican en el nivel de circuito ExpressRoute, que consta de dos interconexiones independientes entre el equipo redundante de Microsoft y el equipo del proveedor de red en cada ubicación de emparejamiento.

Disponibilidad del proveedor

• Las disposiciones de nivel de servicio de Microsoft se detienen en el proveedor o asociado de ExpressRoute. Este es también el primer lugar en el que puede tomar decisiones que influirán en el nivel de disponibilidad. Debe evaluar de cerca las características de arquitectura, disponibilidad y resistencia que ofrece el proveedor de ExpressRoute entre el perímetro de red y la conexión de los proveedores en cada ubicación de emparejamiento de Microsoft. Preste mucha atención a los aspectos lógicos y físicos de la redundancia, el equipo de emparejamiento, los circuitos WAN proporcionados por el operador y los servicios adicionales de adición de valor, como los servicios NAT o los firewalls administrados.

Diseño del plan de disponibilidad

Se recomienda planear y diseñar la alta disponibilidad y resistencia en los escenarios de conectividad de un extremo a otro para Microsoft 365. Un diseño debe incluir;

• No hay puntos de error únicos, incluidos los circuitos De Internet y ExpressRoute.

• Minimizar el número de personas afectadas y la duración de ese impacto para los modos de error más esperados.

• Optimización para un proceso de recuperación simple, repetible y automático a partir de los modos de error más esperados.

• Compatibilidad con las demandas completas del tráfico de red y la funcionalidad a través de rutas de acceso redundantes, sin degradación sustancial.

Los escenarios de conectividad deben incluir una topología de red optimizada para varias rutas de acceso de red independientes y activas a Microsoft 365. Esto producirá una mejor disponibilidad de un extremo a otro que una topología optimizada solo para redundancia en el nivel de dispositivo o equipo individual.

Sugerencia

Si los usuarios se distribuyen entre varios continentes o regiones geográficas y cada una de esas ubicaciones se conecta a través de circuitos WAN redundantes a una única ubicación local donde se encuentra un único circuito ExpressRoute, los usuarios experimentarán menos disponibilidad de servicio de un extremo a otro que un diseño de topología de red que incluye circuitos ExpressRoute independientes que conectan las distintas regiones a la ubicación de emparejamiento más cercana.

Se recomienda aprovisionar al menos dos circuitos ExpressRoute con cada circuito que se conecte a con una ubicación de emparejamiento geográfica diferente. Debe aprovisionar este par de circuitos activo-activo para cada región en la que los usuarios usarán la conectividad de ExpressRoute para los servicios de Microsoft 365. Esto permite que cada región permanezca conectada durante un desastre que afecta a una ubicación principal, como un centro de datos o una ubicación de emparejamiento. Configurarlas como activas o activas permite que el tráfico del usuario final se distribuya entre varias rutas de acceso de red. Esto reduce el alcance de las personas afectadas durante las interrupciones del dispositivo o del equipo de red.

No se recomienda usar un único circuito ExpressRoute con Internet como copia de seguridad.

Ejemplo: Conmutación por error y alta disponibilidad

El diseño multi geográfico de Contoso se ha sometido a una revisión del enrutamiento, el ancho de banda, la seguridad y ahora debe pasar por una revisión de alta disponibilidad. Contoso piensa que la alta disponibilidad abarca tres categorías; resistencia, confiabilidad y redundancia.

La resistencia permite a Contoso recuperarse rápidamente de los errores. La confiabilidad permite a Contoso ofrecer un resultado coherente dentro del sistema. La redundancia permite a Contoso moverse entre una o varias instancias reflejadas de la infraestructura.

Dentro de cada configuración perimetral, Contoso tiene firewalls, servidores proxy e IDS redundantes. Por Norteamérica, Contoso tiene una configuración perimetral en su centro de datos de Dallas y otra configuración perimetral en su centro de datos de Virginia. El equipo redundante de cada ubicación ofrece resistencia a esa ubicación.

La configuración de red en Contoso se basa en algunos principios clave:

• Dentro de cada región geográfica, hay varios circuitos ExpressRoute de Azure.

• Cada circuito dentro de una región puede admitir todo el tráfico de red dentro de esa región.

• El enrutamiento prefiere claramente una u otra ruta de acceso en función de la disponibilidad, la ubicación, etc.

• La conmutación por error entre los circuitos De ExpressRoute de Azure se produce automáticamente sin necesidad de una configuración o acción adicional por parte de Contoso.

• La conmutación por error entre circuitos de Internet se produce automáticamente sin necesidad de una configuración o acción adicional por parte de Contoso.

En esta configuración, con redundancia en el nivel físico y virtual, Contoso es capaz de ofrecer resistencia local, resistencia regional y resistencia global de forma confiable. Contoso eligió esta configuración después de evaluar un único circuito ExpressRoute de Azure por región, así como la posibilidad de conmutar por error a Internet.

Si Contoso no pudiera tener varios circuitos ExpressRoute de Azure por región, el enrutamiento del tráfico que se origina en Norteamérica al circuito ExpressRoute de Azure en Asia Pacífico agregaría un nivel inaceptable de latencia y la configuración del reenviador DNS necesaria agrega complejidad.

No se recomienda usar Internet como configuración de copia de seguridad. Esto interrumpe el principio de confiabilidad de Contoso, lo que da lugar a una experiencia incoherente mediante la conexión. Además, se requeriría una configuración manual para conmutar por error teniendo en cuenta los anuncios BGP que se han configurado, la configuración nat, la configuración de DNS y la configuración del proxy. Esta complejidad de conmutación por error agregada aumenta el tiempo de recuperación y reduce su capacidad para diagnosticar y solucionar los pasos implicados.

¿Sigue teniendo preguntas sobre cómo planear e implementar la administración de tráfico o Azure ExpressRoute? Lea el resto de nuestra guía de rendimiento y red o las preguntas más frecuentes sobre Azure ExpressRoute.

Aplicación de controles de seguridad a Azure ExpressRoute para escenarios de Microsoft 365

La protección de la conectividad de Azure ExpressRoute comienza con los mismos principios que la protección de la conectividad a Internet. Muchos clientes deciden implementar controles perimetrales y de red a lo largo de la ruta de acceso de ExpressRoute que conecta su red local a Microsoft 365 y otras nubes de Microsoft. Estos controles pueden incluir firewalls, servidores proxy de aplicaciones, prevención de pérdida de datos, detección de intrusiones, sistemas de prevención de intrusiones, etc. En muchos casos, los clientes aplican distintos niveles de controles al tráfico iniciado desde el entorno local que va a Microsoft, frente al tráfico iniciado desde Microsoft que va a la red local del cliente, frente al tráfico iniciado desde el entorno local que va a un destino general de Internet.

Estos son algunos ejemplos de integración de la seguridad con el modelo de conectividad de ExpressRoute que elija implementar.

Opción de integración de ExpressRoute	Modelo perimetral de seguridad de red
Colocación en un intercambio en la nube	Instale nueva infraestructura perimetral o de seguridad existente en la instalación de colocación donde se establece la conexión de ExpressRoute. Use la instalación de colocación únicamente con fines de enrutamiento/interconexión y conexiones de transporte de regreso desde la instalación de colocación a la infraestructura de seguridad/perímetro local.
Ethernet de punto a punto	Finalice la conexión ExpressRoute de punto a punto en la ubicación de la infraestructura perimetral o de seguridad local existente. Instale una nueva infraestructura de seguridad o perímetro específica de la ruta de acceso de ExpressRoute y finalice allí la conexión de punto a punto.
IpVPN de cualquier a cualquier	Use una infraestructura perimetral o de seguridad local existente en todas las ubicaciones que salen al IPVPN que se usa para la conectividad de ExpressRoute para Microsoft 365. Redireccionar el IPVPN usado para ExpressRoute para Microsoft 365 a ubicaciones locales específicas designadas para servir como seguridad o perímetro.

Algunos proveedores de servicios también ofrecen funcionalidad de seguridad administrada o perimetral como parte de sus soluciones de integración con Azure ExpressRoute.

Al considerar la ubicación de la topología de las opciones de perímetro de red o seguridad que se usan para ExpressRoute para las conexiones de Microsoft 365, a continuación se indican consideraciones adicionales.

• La profundidad y el tipo de controles de red/seguridad pueden afectar al rendimiento y la escalabilidad de la experiencia del usuario de Microsoft 365.

• Los flujos salientes (locales de> Microsoft) y entrantes (Microsoft> local) [si están habilitados] pueden tener requisitos diferentes. Es probable que sean diferentes de los destinos salientes a los destinos generales de Internet.

• Los requisitos de Microsoft 365 para puertos o protocolos y subredes IP necesarias son los mismos, independientemente de si el tráfico se enruta a través de ExpressRoute para Microsoft 365 o a través de Internet.

• La colocación topológica de los controles de seguridad o red del cliente determina la red final entre el usuario y el servicio de Microsoft 365 y puede tener un impacto sustancial en la latencia y la congestión de la red.

• Se recomienda a los clientes diseñar su topología de seguridad o perímetro para su uso con ExpressRoute para Microsoft 365 de acuerdo con los procedimientos recomendados para la redundancia, la alta disponibilidad y la recuperación ante desastres.

Este es un ejemplo de Contoso que compara las distintas opciones de conectividad de Azure ExpressRoute con los modelos de seguridad perimetral descritos anteriormente.

Ejemplo: Protección de Azure ExpressRoute

Contoso está pensando en implementar Azure ExpressRoute y después de planear la arquitectura óptima para ExpressRoute para Microsoft 365 y después de usar las instrucciones anteriores para comprender los requisitos de ancho de banda, están determinando el mejor método para proteger su perímetro.

Para Contoso, una organización multinacional con ubicaciones en varios continentes, la seguridad debe abarcar todos los perímetros. La opción de conectividad óptima para Contoso es una conexión de varios puntos con varias ubicaciones de emparejamiento de todo el mundo para atender las necesidades de sus empleados en cada continente. Cada continente incluye circuitos Azure ExpressRoute redundantes dentro del continente y la seguridad debe abarcar todos ellos.

La infraestructura existente de Contoso es confiable y puede controlar el trabajo adicional, como resultado, Contoso puede usar la infraestructura para su seguridad perimetral de Azure ExpressRoute e Internet. Si este no fuera el caso, Contoso podría optar por comprar más equipos para complementar su equipo existente o para controlar un tipo diferente de conexión.

Planeamiento del ancho de banda para Azure ExpressRoute

Cada cliente de Microsoft 365 tiene necesidades de ancho de banda únicas en función del número de personas en cada ubicación, de su actividad con cada aplicación de Microsoft 365 y de otros factores, como el uso de equipos locales o híbridos y configuraciones de seguridad de red.

Tener demasiado poco ancho de banda provocará congestión, retransmisiones de datos y retrasos imprevisibles. Tener demasiado ancho de banda dará lugar a costos innecesarios. En una red existente, a menudo se hace referencia al ancho de banda en términos de la cantidad de espacio para la cabeza disponible en el circuito como un porcentaje. Tener un 10 % de espacio para la cabeza probablemente provocará congestión y tener un 80 % de espacio para la cabeza generalmente significa un costo innecesario. Las asignaciones de destino de espacio principal típicas son del 20 % al 50 %.

Para encontrar el nivel adecuado de ancho de banda, el mejor mecanismo es probar el consumo de red existente. Esta es la única manera de obtener una verdadera medida de uso y necesidad, ya que cada configuración de red y aplicaciones son de alguna manera únicas. Al medir, querrá prestar mucha atención al consumo total de ancho de banda, la latencia y la congestión TCP para comprender sus necesidades de red.

Una vez que tenga una línea base estimada que incluya todas las aplicaciones de red, pruebe Microsoft 365 con un grupo pequeño que incluya los distintos perfiles de personas de su organización para determinar el uso real y use las dos medidas para calcular la cantidad de ancho de banda que necesitará para cada ubicación de la oficina. Si hay problemas de latencia o congestión TCP en las pruebas, es posible que tenga que acercar la salida a las personas que usan Microsoft 365 o quitar el examen intensivo de red, como el descifrado o la inspección ssl.

Todas nuestras recomendaciones sobre qué tipo de procesamiento de red se recomienda se aplican a los circuitos ExpressRoute e Internet. Lo mismo sucede con el resto de las instrucciones de nuestro sitio de optimización del rendimiento.

Compilación de los procedimientos de implementación y pruebas

El plan de implementación debe incluir el planeamiento de pruebas y reversión. Si la implementación no funciona según lo esperado, el plan debe diseñarse para afectar al menor número de personas antes de que se detecten problemas. A continuación se muestran algunos principios de alto nivel que debe tener en cuenta el plan.

1. Almacene provisionalmente el segmento de red y la incorporación del servicio de usuario para minimizar la interrupción.

2. Planee la prueba de rutas con traceroute y conexión TCP desde un host conectado a Internet independiente.

3. Preferiblemente, las pruebas de los servicios entrantes y salientes se deben realizar en una red de prueba aislada con un inquilino de Microsoft 365 de prueba.

   • Como alternativa, las pruebas se pueden realizar en una red de producción si el cliente aún no usa Microsoft 365 o está en versión piloto.

   • Como alternativa, las pruebas se pueden realizar durante una interrupción de producción que se reserva solo para pruebas y supervisión.

   • Como alternativa, las pruebas se pueden realizar comprobando las rutas de cada servicio en cada nodo de enrutador de nivel 3. Esta reversión solo debe usarse si no es posible realizar otras pruebas, ya que la falta de pruebas físicas supone un riesgo.

Compilación de los procedimientos de implementación

Los procedimientos de implementación deben implementarse en grupos pequeños de personas en fases para permitir las pruebas antes de realizar la implementación en grupos de personas más grandes. A continuación se muestran varias maneras de almacenar provisionalmente la implementación de ExpressRoute.

1. Configure ExpressRoute con el emparejamiento de Microsoft y reenvíe los anuncios de ruta a un único host solo con fines de pruebas preconfiguradas.

2. Anuncie las rutas a la red de ExpressRoute a un único segmento de red al principio y expanda los anuncios de ruta por segmento de red o región.

3. Si implementa Microsoft 365 por primera vez, use la implementación de red de ExpressRoute como piloto para algunas personas.

4. Si usa servidores proxy, también puede configurar un archivo PAC de prueba para dirigir a algunas personas a ExpressRoute con pruebas y comentarios antes de agregar más.

El plan de implementación debe enumerar cada uno de los procedimientos de implementación que se deben tomar o los comandos que deben usarse para implementar la configuración de red. Cuando llega el tiempo de interrupción de la red, todos los cambios que se realizan deben ser del plan de implementación escrito por adelantado y revisado por el mismo nivel. Consulte nuestras instrucciones sobre la configuración técnica de ExpressRoute.

• Actualizar los registros TXT de SPF si ha cambiado las direcciones IP de los servidores locales que seguirán enviando correo electrónico.

• Actualizar las entradas DNS de los servidores locales si ha cambiado las direcciones IP para dar cabida a una nueva configuración NAT.

• Asegúrese de que se ha suscrito a la fuente RSS para las notificaciones de punto de conexión de Microsoft 365 para mantener las configuraciones de enrutamiento o proxy.

Una vez completada la implementación de ExpressRoute, se deben ejecutar los procedimientos del plan de prueba. Los resultados de cada procedimiento deben registrarse. Debe incluir procedimientos para revertir al entorno de producción original en caso de que los resultados del plan de prueba indiquen que la implementación no se realizó correctamente.

Compilación de los procedimientos de prueba

Los procedimientos de prueba deben incluir pruebas para cada servicio de red saliente y entrante para Microsoft 365 que usará ExpressRoute y los que no lo harán. Los procedimientos deben incluir pruebas desde cada ubicación de red única, incluidos los usuarios que no son locales en la LAN corporativa.

Algunos ejemplos de actividades de prueba incluyen lo siguiente.

1. Haga ping desde el enrutador local al enrutador del operador de red.

2. Valide que el enrutador local recibe más de 500 anuncios de direcciones IP de Microsoft 365 y CRM Online.

3. Valide que la NAT entrante y saliente funciona entre ExpressRoute y la red interna.

4. Valide que las rutas a su NAT se anuncian desde el enrutador.

5. Valide que ExpressRoute ha aceptado los prefijos anunciados.

   • Use el siguiente cmdlet para comprobar los anuncios de emparejamiento:

   Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeering
   

6. Valide que el intervalo de DIRECCIONES NAT públicas no se anuncia a Microsoft a través de ningún otro circuito expressroute o de red pública de Internet, a menos que sea un subconjunto específico de un intervalo mayor, como en el ejemplo anterior.

7. Los circuitos ExpressRoute están emparejados y validan que ambas sesiones BGP se están ejecutando.

8. Configure un único host en el interior de la NAT y use ping, tracert y tcpping para probar la conectividad entre el nuevo circuito y el host outlook.office365.com. Como alternativa, podría usar una herramienta como Wireshark o Microsoft Network Monitor 3.4 en un puerto reflejado en el MSEE para validar que puede conectarse a la dirección IP asociada a outlook.office365.com.

9. Pruebe la funcionalidad de nivel de aplicación para Exchange Online.

• Probar Outlook es capaz de conectarse a Exchange Online y enviar y recibir correo electrónico.

• Probar Outlook es capaz de usar el modo en línea.

• Pruebe la conectividad del teléfono inteligente y la funcionalidad de envío y recepción.

10. Prueba de la funcionalidad de nivel de aplicación para SharePoint Online

• Pruebe OneDrive para la Empresa cliente de sincronización.

• Pruebe el acceso web de SharePoint Online.

11. Pruebe la funcionalidad de nivel de aplicación para Skype Empresarial escenarios de llamada:

• Únase a la llamada de conferencia como usuario autenticado [invitación iniciada por el usuario final].

• Invite al usuario a la llamada de conferencia [invitación enviada desde MCU].

• Únase a la conferencia como usuario anónimo mediante la aplicación web Skype Empresarial.

• Unirse a la llamada desde su conexión de PC cableada, teléfono IP y dispositivo móvil.

• Llamada al usuario federado o Llamada a validación RTC: se completa la llamada, la calidad de la llamada es aceptable y el tiempo de conexión es aceptable.

• Compruebe que el estado de presencia de los contactos se actualiza tanto para los miembros del inquilino como para los usuarios federados.

Problemas comunes

El enrutamiento asimétrico es el problema de implementación más común. Estos son algunos orígenes comunes que se pueden buscar:

• Usar una topología de enrutamiento de red abierta o plana sin NAT de origen en su lugar.

• No usar SNAT para enrutar a los servicios entrantes a través de las conexiones de Internet y ExpressRoute.

• No probar los servicios entrantes en ExpressRoute en una red de prueba antes de implementarlo ampliamente.

Implementación de la conectividad de ExpressRoute a través de la red

Escenifique la implementación en un segmento de la red a la vez, implementando progresivamente la conectividad a diferentes partes de la red con un plan para revertir para cada nuevo segmento de red. Si la implementación está alineada con una implementación de Microsoft 365, implemente primero en los usuarios piloto de Microsoft 365 y amplíe desde allí.

Primero para la prueba y, después, para producción:

• Ejecute los pasos de implementación para habilitar ExpressRoute.

• Pruebe a ver que las rutas de red son las esperadas.

• Realice pruebas en cada servicio entrante y saliente.

• Reversión si detecta algún problema.

Configuración de una conexión de prueba a ExpressRoute con un segmento de red de prueba

Ahora que tiene el plan completado en papel, es el momento de probarlo a pequeña escala. En esta prueba, establecerá una única conexión de ExpressRoute con El emparejamiento de Microsoft a una subred de prueba en la red local. Puede configurar un inquilino de Prueba de Microsoft 365 con conectividad hacia y desde la subred de prueba e incluir todos los servicios salientes y entrantes que usará en producción en la subred de prueba. Configure DNS para el segmento de red de prueba y establezca todos los servicios entrantes y salientes. Ejecute el plan de prueba y asegúrese de que está familiarizado con el enrutamiento de cada servicio y la propagación de rutas.

Ejecución de los planes de implementación y prueba

A medida que complete los elementos descritos anteriormente, compruebe las áreas que ha completado y asegúrese de que usted y su equipo los han revisado antes de ejecutar los planes de implementación y pruebas.

• Lista de servicios salientes y entrantes que participan en el cambio de red.

• Diagrama de arquitectura de red global que muestra tanto la salida de Internet como las ubicaciones meet-me de ExpressRoute.

• Diagrama de enrutamiento de red que muestra las distintas rutas de acceso de red usadas para cada servicio implementado.

• Un plan de implementación con pasos para implementar los cambios y la reversión si es necesario.

• Un plan de prueba para probar cada servicio de red y Microsoft 365.

• Validación en papel completada de las rutas de producción para los servicios entrantes y salientes.

• Una prueba completada en un segmento de red de prueba, incluidas las pruebas de disponibilidad.

Elija una ventana de interrupción que sea lo suficientemente larga como para ejecutarse a través de todo el plan de implementación y el plan de prueba, tiene algún tiempo disponible para solucionar problemas y tiempo para revertir si es necesario.

Precaución

Debido a la naturaleza compleja del enrutamiento a través de Internet y ExpressRoute, se recomienda agregar tiempo de búfer adicional a esta ventana para controlar la solución de problemas de enrutamiento complejo.

Configuración de QoS para Skype Empresarial Online

QoS es necesario para obtener las ventajas de voz y reunión para Skype Empresarial Online. Puede configurar QoS después de asegurarse de que la conexión de red de ExpressRoute no bloquea ningún otro acceso al servicio de Microsoft 365. La configuración de QoS se describe en el artículo ExpressRoute y QoS en Skype Empresarial Online .

Solución de problemas de la implementación

El primer lugar que se debe examinar es en los pasos de esta guía de implementación, ¿se han perdido en el plan de implementación? Volver y ejecute pruebas de red más pequeñas si es posible para replicar el error y depurarlo allí.

Identifique qué servicios entrantes o salientes produjeron errores durante las pruebas. Obtenga específicamente las direcciones IP y subredes de cada uno de los servicios con errores. Siga adelante y recoste el diagrama de topología de red en papel y valide el enrutamiento. Valide específicamente dónde se anuncia el enrutamiento de ExpressRoute, pruebe ese enrutamiento durante la interrupción si es posible con seguimientos.

Ejecute PSPing con un seguimiento de red a cada punto de conexión de cliente y evalúe las direcciones IP de origen y destino para validar que son las esperadas. Ejecute telnet en cualquier host de correo que exponga en el puerto 25 y compruebe que SNAT oculta la dirección IP de origen original si se espera.

Tenga en cuenta que, al implementar Microsoft 365 con una conexión ExpressRoute, deberá asegurarse de que la configuración de red de ExpressRoute está diseñada de forma óptima y también ha optimizado los demás componentes de la red, como los equipos cliente. Además de usar esta guía de planeamiento para solucionar los pasos que puede haber perdido, también hemos escrito un plan de solución de problemas de rendimiento para Microsoft 365 .

Este es un vínculo breve que se puede usar para volver: https://aka.ms/implementexpressroute365

Temas relacionados

Evaluar la conectividad de red de Microsoft 365

Azure ExpressRoute para Microsoft 365

Calidad de medios y rendimiento de conectividad de red en Skype Empresarial Online

Optimización de la red para Skype Empresarial Online

ExpressRoute y calidad del servicio en Skype Empresarial Online

Flujo de llamadas con ExpressRoute

Optimización del rendimiento de Microsoft 365 mediante líneas base e historial de rendimiento

Plan de solución de problemas de rendimiento para Microsoft 365

Intervalos de direcciones IP y URL de Microsoft 365

Optimización de rendimiento y red de Microsoft 365