Otimizar o Encaminhamento do ExpressRoute

Se tem vários circuitos do ExpressRoute, significa que tem mais do que um caminho para se ligar à Microsoft. Sendo assim, o encaminhamento poderá não ser o ideal, ou seja, o tráfego poderá optar por um caminho mais longo para chegar à Microsoft e da Microsoft à sua rede. Quanto mais longo for o caminho de rede, maior será a latência. A latência tem efeito direto no desempenho do aplicativo e na experiência do usuário. Este artigo ilustra esse problema e explica como otimizar o roteamento usando as tecnologias de roteamento padrão.

Seleção de caminho para emparelhamento da Microsoft

É importante garantir que, ao utilizar a Microsoft, o tráfego flua pelo caminho desejado se você tiver um ou mais circuitos de Rota Expressa. Você também precisa garantir que os caminhos para a Internet usem um Internet Exchange (IX) ou Internet Service Provider (ISP). O BGP utiliza um algoritmo de seleção de melhor caminho com base em muitos fatores, incluindo a correspondência de prefixo mais longa (LPM). Para garantir que o tráfego destinado ao Azure por meio da Microsoft percorra o caminho da Rota Expressa, você deve implementar o atributo Preferência Local . Essa configuração garante que o caminho seja sempre preferido na Rota Expressa.

Nota

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

Considere o seguinte cenário de exemplo:

No exemplo acima, para preferir caminhos de Rota Expressa, configure Preferência Local da seguinte maneira.

Configuração do Cisco IOS-XE da perspetiva R1:

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

• R1(config-route-map)#set preferência local 150

• R1(configuração)#router BGP 345

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

• R1(config-router)#neighbor 1.1.1.2 ativar

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

Configuração Junos da perspetiva R1:

• user@R1# definir protocolos bgp grupo ibgp tipo interno
• user@R1# definir protocolos bgp grupo ibgp local-preference 150

Encaminhamento inferior ao ideal do cliente para a Microsoft

Vamos analisar o problema de encaminhamento com um exemplo. Imagine que tem dois escritórios nos EUA, um em Los Angeles e outro em Nova Iorque. Os escritórios estão ligados através de uma Rede Alargada (WAN), que pode ser a sua própria rede principal ou a VPN de IP do seu fornecedor de serviços. Tem dois circuitos do ExpressRoute, um nos E.U.A. Oeste e outro nos E.U.A. Leste. Ambos também estão conectados na WAN. Tem, obviamente, dois caminhos para se ligar à rede da Microsoft.

Agora imagine que você tem uma implantação do Azure, por exemplo, um Serviço de Aplicativo do Azure no Oeste e no Leste dos EUA. Sua intenção é conectar seus usuários em Los Angeles ao Azure US West e seus usuários em Nova York ao Azure US East. A razão para essa 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 experiências ideais. O plano funciona bem para os utilizadores da costa leste, mas não para os utilizadores da costa oeste.

A causa do problema é em cada circuito de Rota Expressa, anunciamos para o local o prefixo no Azure US East 23.100.0.0/16 e o prefixo no Azure US West 13.100.0.0/16. Se você não sabe qual prefixo é de qual região, você não é capaz de tratá-lo de forma diferente. A rede WAN poderá achar que ambos os prefixos estão mais próximos dos E.U.A. Leste do que dos E.U.A. Oeste e, por conseguinte, encaminhar ambos os utilizadores do escritório para o circuito do ExpressRoute nos E.U.A. Leste. No final, você tem muitos usuários insatisfeitos no escritório de Los Angeles.

Solução: utilizar Comunidades do BGP

Para otimizar o encaminhamento para os utilizadores dos dois escritório, é necessário saber qual é o prefixo do Azure dos E.U.A. Oeste e qual é o do Azure dos E.U.A. Leste. Codificamos estas informações com os Valores das Comunidades do BGP. Atribuímos um valor exclusivo da Comunidade BGP a cada região do Azure, por exemplo 12076:51004 , para Leste dos EUA, 12076:51006 para Oeste dos EUA. Agora que sabe que prefixo corresponde a que região do Azure, já pode configurar que circuito do ExpressRoute deve ser o preferencial. Como usamos o BGP para trocar informações de roteamento, você pode usar a Preferência Local do BGP para influenciar o roteamento.

No nosso exemplo, pode atribuir um valor de preferência local mais alto a 13.100.0.0/16 nos E.U.A. Oeste do que nos E.U.A. Leste, e, da mesma forma, um valor de preferência local mais alto a 23.100.0.0/16 nos E.U.A. Leste do que nos E.U.A. Oeste. Essa configuração garante que, quando ambos os caminhos para a Microsoft estiverem disponíveis, seus usuários em Los Angeles usem o circuito ExpressRoute no Oeste dos EUA para se conectar ao Azure US West, enquanto seus usuários em Nova York pegam a ExpressRoute no Leste dos EUA para o Azure US East. O encaminhamento fica otimizado em ambos os lados.

Nota

A mesma técnica, usando a Preferência Local, pode ser aplicada ao roteamento do cliente para a rede virtual do Azure ao usar o emparelhamento privado. A Microsoft não marca valores da comunidade BGP para os prefixos anunciados do Azure para sua rede. No entanto, como você sabe qual de sua implantação de rede virtual está perto de qual de seu escritório, você pode configurar seus roteadores de acordo para preferir um circuito de Rota Expressa sobre outro.

Encaminhamento inferior ao ideal da Microsoft para o cliente

Neste exemplo, temos conexões da Microsoft que percorrem um caminho mais longo para chegar à sua rede. Neste caso, está a utilizar servidores do Exchange no local e o Exchange Online num ambiente híbrido. Os seus escritórios estão ligados a uma WAN. Você anuncia os prefixos de seus servidores locais em ambos os escritórios para a Microsoft por meio de dois circuitos de Rota Expressa.

O Exchange Online inicia conexões com os servidores locais em casos como a migração de caixa de correio. A conexão com o seu escritório em Los Angeles é encaminhada para o circuito ExpressRoute no leste dos EUA antes de atravessar todo o continente de volta para a costa oeste. A causa do problema é semelhante à anterior. Sem qualquer dica, a rede da Microsoft não pode dizer qual prefixo local está perto do Leste dos EUA e qual está perto do Oeste dos EUA. E escolhe o caminho errado para o seu escritório em Los Angeles.

Solução: utilizar prefixação COMO CAMINHO

Existem duas soluções para o problema. A primeira é simplesmente anunciar seu prefixo local para seu escritório em Los Angeles 177.2.0.0/31 no circuito ExpressRoute no oeste dos EUA. Em seguida, você anuncia seu prefixo local para seu escritório em Nova York, 177.2.0.2/31 no circuito ExpressRoute no Leste dos EUA. Como resultado, há apenas um caminho para a Microsoft se conectar a cada um dos seus escritórios. Não há ambiguidade e o roteamento é otimizado. Com esta estrutura, tem de pensar sobre a sua estratégia de ativação pós-falha. Se o caminho para a Microsoft através da Rota Expressa ficar incorreto, você precisará certificar-se de que o Exchange Online ainda pode se conectar aos seus servidores locais.

A segunda solução é continuar a anunciar ambos os prefixos em ambos os circuitos do ExpressRoute e, além disso, dar-nos uma sugestão de qual é o prefixo que está próximo de qual dos seus escritórios. Uma vez que suportamos a prefixação COMO Caminho do BGP, pode configurá-la para o seu prefixo de modo a influenciar o encaminhamento. Neste exemplo, você pode alongar o AS PATH para 172.2.0.0/31 no Leste dos EUA para que prefiramos o circuito ExpressRoute no Oeste dos EUA para o tráfego destinado a esse prefixo. Da mesma forma, você pode alongar o AS PATH para 172.2.0.2/31 no Oeste dos EUA para que prefiramos o circuito ExpressRoute no Leste dos EUA. O encaminhamento fica otimizado para ambos os escritórios. Com esta estrutura, se um circuito do ExpressRoute for interrompido, o Exchange Online ainda consegue contactá-lo através de outro circuito do ExpressRoute e da sua WAN.

Importante

Removemos números AS privados no AS PATH para os prefixos recebidos no Microsoft Peering ao emparelhar usando um número AS privado. Você precisa emparelhar com um AS público e acrescentar números AS públicos no AS PATH para influenciar o roteamento para o Microsoft Peering.

Nota

Embora os exemplos dados aqui sejam para emparelhamento da Microsoft, oferecemos suporte aos mesmos recursos para o emparelhamento privado. Além disso, a prefixação COMO Caminho funciona dentro de um circuito único do ExpressRoute para influenciar a seleção dos caminhos primários e secundários.

Encaminhamento inferior ao ideal entre redes virtuais

Com o ExpressRoute, pode permitir a comunicação de Rede Virtual para Rede Virtual (também conhecida como “VNet”), ao ligá-las a um circuito do ExpressRoute. Quando as liga a vários circuitos do ExpressRoute, o encaminhamento entre as VNets pode ter um desempenho inferior ao ideal. Vamos considerar um exemplo. Tem dois circuitos do ExpressRoute, um nos E.U.A. Oeste e outro nos E.U.A. Leste. Em cada região, tem duas VNets. Os seus servidores Web estão implementados numa VNet e os servidores de aplicações noutra. Para redundância, liga as duas VNets em cada região aos circuitos local e remoto do ExpressRoute. Como pode ser visto no diagrama a seguir, de cada VNet há dois caminhos para a outra VNet. As VNets não sabem que circuito do ExpressRoute é o local ou o remoto. Como o roteamento ECMP (Equal-Cost-Multi-Path) é usado para balancear a carga do tráfego entre VNet, alguns fluxos de tráfego tomam o caminho mais longo e são roteados no circuito remoto da Rota Expressa.

Solução: atribuir uma ponderação elevada à ligação no local

A solução é simples. Uma vez que sabe onde estão as VNets e os circuitos, pode dizer-nos que caminho cada VNet deve preferir. Mais concretamente para este exemplo, vai atribuir uma ponderação mais elevada à ligação local do que à remota (veja o exemplo de configuração aqui). Quando uma VNet recebe o prefixo da outra VNet em várias conexões, ela prefere a conexão com o maior peso para enviar o tráfego destinado a esse prefixo.

Nota

Você também pode influenciar o roteamento da VNet para sua rede local, se tiver vários circuitos de Rota Expressa, configurando o peso de uma conexão em vez de aplicar a opção AS PATH pendente, uma técnica descrita no segundo cenário. Para cada prefixo, para decidir como enviar o tráfego, vamos sempre considerar primeiro a ponderação da ligação face ao comprimento de COMO CAMINHO.

Próximos passos

• Saiba mais sobre como projetar o ExpressRoute para alta disponibilidade.
• Saiba mais sobre como projetar o ExpressRoute para recuperação de desastres.