Otimizar o roteamento do ExpressRoute

  • Artigo

Quando você tem vários circuitos de ExpressRoute, tem mais de um caminho para se conectar à Microsoft. Portanto, pode ocorrer um roteamento abaixo do ideal, ou seja, o tráfego pode levar um caminho mais longo para acessar a Microsoft e esta para acessar a sua rede. Quanto maior o caminho de rede, maior será a latência. A latência tem impacto direto na experiência de usuário e no desempenho do aplicativo. Esse artigo ilustra esse problema e explica como otimizar o roteamento usando tecnologias de roteamento padrão.

Seleção de caminho para emparelhamento da Microsoft

É importante garantir que, ao utilizar a Microsoft, o tráfego flua sobre o caminho desejado caso você tenha um ou mais circuitos do ExpressRoute. Você também precisa garantir que os caminhos para a Internet usem um Internet Exchange (IX) ou um Provedor de Serviços de Internet (ISP). O BGP utiliza um algoritmo de seleção de caminho melhor com base em diversos fatores, incluindo a correspondência de prefixo mais longo (LPM). Para garantir que o tráfego destinado ao Azure através da Microsoft percorra o caminho do ExpressRoute, você deve implementar o atributo Preferência Local. Essa configuração garante que o caminho seja sempre preferencial no ExpressRoute.

Observação

A preferência local padrão é normalmente 100. Preferências mais altas de local são preferenciais.

Considere o seguinte cenário de exemplo:

O diagrama mostra o problema de Caso 1 do ExpressRoute - qualidade inferior de roteamento do cliente para a Microsoft

No exemplo acima, para preferir caminhos do ExpressRoute, configure a preferência local da seguinte maneira.

Configuração do Cisco IOS-XE da perspectiva do 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

Configuração do Junos da perspectiva do R1:

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

Roteamento abaixo do ideal do cliente para a Microsoft

Vamos examinar o problema de roteamento usando um exemplo. Imagine que você tem dois escritórios nos EUA, um em Los Angeles e um em Nova York. Seus escritórios estão conectados em uma WAN (rede de longa distância), que pode ser sua própria rede backbone ou VPN de IP do provedor de serviços. Você tem dois circuitos de ExpressRoute, um no Oeste dos EUA e outro no Leste dos EUA. Os dois também estão conectados na WAN. Obviamente, você tem dois caminhos para se conectar à rede da Microsoft.

Agora imagine que você tem uma implantação do Azure, por exemplo, o Serviço de Aplicativo do Azure, no Oeste dos EUA e no Leste dos EUA. Você deseja conectar usuários em Los Angeles ao Azure do Oeste dos EUA e usuários em Nova York ao Azure do Leste dos EUA. O motivo dessa configuração é porque o administrador do serviço anuncia que os usuários em cada escritório acessam os serviços do Azure próximos para obter experiências ideais. Infelizmente, o plano funciona bem para os usuários da Costa Leste, mas não para os usuários da Costa Oeste.

A causa do problema é que em cada circuito do ExpressRoute, anunciamos para o local o prefixo 23.100.0.0/16 no Azure do Leste dos EUA e o prefixo 13.100.0.0/16 no Azure do Oeste dos EUA. Se você não souber qual prefixo é de que região, não conseguirá tratá-los de maneira diferente. Sua rede WAN pode pensar que ambos os prefixos são mais próximos do Leste dos EUA que do Oeste dos EUA e, portanto, rotear os usuários de ambos os escritórios para o circuito de ExpressRoute no Leste dos EUA. Como consequência, você terá muitos usuários insatisfeitos no escritório de Los Angeles.

Problema de ExpressRoute, Caso 1 - qualidade inferior de roteamento do cliente para a Microsoft

Solução: usar comunidades BGP

Para otimizar o roteamento nos dois usuários, você precisa saber qual é o prefixo do Azure no Oeste dos EUA e no Leste dos EUA. Nós codificamos essas informações usando Valores da Comunidade BGP. Atribuímos um valor de Comunidade BGP exclusivo para cada região do Azure, por exemplo, 12076:51004 para o Leste dos EUA e 12076:51006 para o Oeste dos EUA. Agora que você sabe que prefixo é de que região do Azure, pode configurar qual circuito de ExpressRoute deve ser preferencial. Como usamos o BGP para trocar informações de roteamento, você pode usar a preferência de local do BGP para influenciar o roteamento.

Em nosso exemplo, você pode atribuir um valor maior de preferência de local a 13.100.0.0/16 no Oeste dos EUA que no Leste dos EUA e, da mesma forma, um valor mais alto de preferência de local a 23.100.0.0/16 no Leste dos EUA que no Oeste dos EUA. Essa configuração fará com que, quando os dois caminhos para a Microsoft estiverem disponíveis, os usuários em Los Angeles usarão o circuito de ExpressRoute do Oeste dos EUA para se conectar ao Azure no Oeste dos EUA e os usuários em Nova York usarão o ExpressRoute no Leste dos EUA para se conectar ao Azure no Leste dos EUA. O roteamento é otimizado em ambos os lados.

Solução de ExpressRoute, Caso 1 - usar Comunidades BGP

Observação

A mesma técnica, usando a Preferência Local, pode ser aplicada ao roteamento de cliente para rede virtual do Azure ao usar o emparelhamento privado. A marcamos Microsoft não marca os valores da comunidade BGP para os prefixos anunciados do Azure para a rede. No entanto, como você sabe qual implantação da rede virtual está próxima de qual escritório, pode configurar os roteadores adequadamente para preferir um circuito do ExpressRoute em vez do outro.

Roteamento abaixo do ideal da Microsoft para o cliente

Nesse exemplo, vemos conexões da Microsoft que usam um caminho mais longo para acessar a sua rede. Nesse caso, você usa servidores Exchange locais e o Exchange Online em um ambiente híbrido. Seus escritórios estão conectados a uma WAN. Você anuncia os prefixos dos seus servidores locais nos dois escritórios à Microsoft por meio de dois circuitos de ExpressRoute.

O Exchange Online irá iniciar conexões com os servidores locais em situações como migração de caixa de correio. Infelizmente, a conexão com o escritório de Los Angeles é roteada para o circuito do ExpressRoute no Leste dos EUA antes de percorrer o continente inteiro de volta à Costa Oeste. A causa do problema é semelhante à do primeiro caso. Sem ter uma noção, a rede da Microsoft não pode determinar qual prefixo do cliente está próximo ao Leste dos EUA e qual está próximo ao Oeste dos EUA. Ela acaba escolhendo o caminho errado para seu escritório em Los Angeles.

ExpressRoute, Caso 2 - qualidade inferior de roteamento da Microsoft para o cliente

Solução: usar precedência de caminho AS

Há duas soluções para o problema. A primeira é simplesmente anunciar seu prefixo local como 177.2.0.0/31 para seu escritório de Los Angeles no circuito ExpressRoute no Oeste dos EUA. Em seguida, você anuncia seu prefixo local como 177.2.0.2/31 para seu escritório em Nova York no circuito do ExpressRoute no Leste dos EUA. Como resultado, sobra apenas um caminho para a Microsoft se conectar a cada um dos seus escritórios. Não há ambiguidade e o roteamento é otimizado. Com esse design, você precisa pensar sobre a estratégia de failover. Se o caminho para a Microsoft pelo ExpressRoute for interrompido, você precisa fazer com que o Exchange Online ainda consiga se conectar aos servidores locais.

A segunda solução é continuar a anunciar ambos os prefixos em ambos os circuitos do ExpressRoute e, além disso, fornecer uma dica de qual prefixo é mais próximo de qual escritório. Como damos suporte a precedência de caminho AS do BGP, você pode configurar do caminho AS para o prefixo a fim de influenciar o roteamento. Nesse exemplo, você pode aumentar o AS PATH de 172.2.0.0/31 no Leste dos EUA para que passemos a preferir circuito do ExpressRoute no Oeste dos EUA para o tráfego destinado a esse prefixo. Da mesma forma, você pode aumentar o AS PATH de 172.2.0.2/31 no Oeste dos EUA para que vejamos o circuito do ExpressRoute no Leste dos EUA como preferencial. O roteamento é otimizado para ambos os escritórios. Com esse design, se um circuito do ExpressRoute for interrompido, o Exchange Online poderá ainda acessá-lo por meio de outro circuito do ExpressRoute e sua WAN.

Importante

Removemos os números AS privados no AS PATH para os prefixos recebidos no emparelhamento da Microsoft feito com um número AS privado. É necessário emparelhar com um AS público e acrescentar os números de AS público no AS PATH para influenciar o roteamento para o emparelhamento da Microsoft.

Solução de ExpressRoute, caso 2 - usar precedência de AS PATH

Observação

Embora os exemplos fornecidos aqui sejam para o emparelhamento da Microsoft, oferecemos suporte para os mesmos recursos para o emparelhamento privado. Além disso, o prefixo AS Path funciona em um único circuito do ExpressRoute para influenciar a seleção dos caminhos primário e secundário.

Qualidade inferior de roteamento entre redes virtuais

Com o ExpressRoute, você pode habilitar a comunicação de Rede Virtual a Rede Virtual (que também é conhecida como "VNet") vinculando-as a um circuito do ExpressRoute. Quando você os vincula a vários circuitos do ExpressRoute, o roteamento abaixo do ideal pode ocorrer entre as redes virtuais. Vamos considerar um exemplo. Você tem dois circuitos de ExpressRoute, um no Oeste dos EUA e outro no Leste dos EUA. Em cada região, você tem duas VNets. Os servidores Web são implantados em uma VNet e os servidores de aplicativos na outra. Para redundância, você pode vincular as duas redes virtuais em cada região ao circuito do ExpressRoute local e ao circuito do ExpressRoute remoto. Como podemos ver no diagrama abaixo, a partir de cada VNet, há dois caminhos para a outra VNet. As VNets não sabem qual circuito do ExpressRoute é local e qual é remoto. Consequentemente, como realizam o roteamento Equal-Cost-Multi-Path (ECMP) para fazer o balanceamento de carga de tráfego entre VNets, alguns fluxos de tráfego usam o caminho mais longo e são roteados no circuito do ExpressRoute remoto.

ExpressRoute, Caso 3 - qualidade inferior de roteamento entre redes virtuais

Solução: atribuir um peso alto à conexão local

A solução é simples. Como você sabe onde as redes virtuais e os circuitos estão, pode indicar qual caminho cada VNet deve preferir. Especificamente para esse exemplo, você atribui um peso mais alto à conexão local do que à conexão remota (consulte o exemplo de configuração aqui). Quando uma VNet receber o prefixo da outra VNet em várias conexões, ela preferirá a conexão com o peso mais alto para enviar o tráfego destinado a esse prefixo.

Solução de ExpressRoute, Caso 3 - atribuir peso alto à conexão local

Observação

Você também poderá influenciar o roteamento da VNet à rede local se tiver vários circuitos do ExpressRoute, configurando o peso de uma conexão em vez de aplicar AS PATH para prefixação, uma técnica descrita no segundo cenário acima. Para cada prefixo, sempre veremos o peso de conexão antes do comprimento do Caminho AS ao decidir como enviar o tráfego.

Próximas etapas