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 da aplicação e na experiência do utilizador. Este artigo ilustra este problema e explica como otimizar o encaminhamento com as tecnologias de encaminhamento padrão.

Seleção de caminhos para Peering Público e Microsoft

É importante garantir que, ao utilizar o peering da Microsoft ou do Peering Público, o tráfego flui sobre o caminho pretendido se tiver um ou mais circuitos do ExpressRoute. Também tem de garantir que os caminhos para a Internet utilizam um Internet Exchange (IX) ou um Fornecedor de Serviços Internet (ISP). O BGP utiliza um melhor algoritmo de seleção de caminho com base em muitos fatores, incluindo a correspondência de prefixo mais longa (LPM). Para garantir que o tráfego destinado ao Azure através da Microsoft ou do Peering Público percorre o caminho do ExpressRoute, tem de implementar o atributo Preferência Local . Esta definição garante que o caminho é sempre preferido no ExpressRoute.

Nota

Normalmente, a preferência local predefinida é 100. As preferências locais mais elevadas são mais preferenciais.

Considere o seguinte cenário de exemplo:

Diagrama que mostra o problema do Caso 1 do ExpressRoute – encaminhamento subótimo do cliente para a Microsoft

No exemplo acima, para preferir os caminhos do ExpressRoute, configure a Preferência Local da seguinte forma.

Configuração do Cisco IOS-XE do ponto de vista R1:

  • R1(configuração)#route-mapear a licença prefer-ExR 10

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

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

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

  • R1(config-router)#neighbor ativação 1.1.1.2

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

Configuração de Junos do ponto de vista R1:

  • user@R1# definir protocolos bgp grupo ibgp tipo interno
  • user@R1# set protocols bgp group 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 ligados na WAN. Tem, obviamente, dois caminhos para se ligar à rede da Microsoft.

Agora imagine que tem uma implementação do Azure, por exemplo, uma Serviço de Aplicações do Azure nos E.U.A. Oeste e E.U.A. Leste. A sua intenção é ligar os seus utilizadores em Los Angeles ao Azure US West e aos seus utilizadores em Nova Iorque ao Azure E.U.A. Leste. O motivo desta configuração deve-se ao facto de o seu administrador de serviços anunciar que os utilizadores em cada escritório acedem aos serviços do Azure nas proximidades para obter 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 do ExpressRoute, anunciamos no local o prefixo no Azure E.U.A. Leste 23.100.0.0/16 e o prefixo no Azure E.U.A. Oeste 13.100.0.0/16. Se não souber qual é o prefixo de que região, não poderá 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, tem muitos utilizadores infelizes no escritório de Los Angeles.

Problema de Caso 1 do ExpressRoute - encaminhamento inferior ao ideal do cliente para a Microsoft

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 , E.U.A. Leste, 12076:51006 para E.U.A. Oeste. Agora que sabe que prefixo corresponde a que região do Azure, já pode configurar que circuito do ExpressRoute deve ser o preferencial. Uma vez que utilizamos o BGP para trocar informações de encaminhamento, pode utilizar a Preferência Local do BGP para influenciar o encaminhamento.

No nosso exemplo, pode atribuir um valor de preferência local mais elevado a 13.100.0.0/16 no E.U.A. Oeste do que no E.U.A. Leste e, da mesma forma, um valor de preferência local superior a 23.100.0.0/16 no Leste dos EUA do que no E.U.A. Oeste. Esta configuração garante que, quando ambos os caminhos para a Microsoft estão disponíveis, os seus utilizadores em Los Angeles assumem o circuito expressRoute nos E.U.A. Oeste para se ligarem ao Azure E.U.A. Oeste, enquanto os seus utilizadores em Nova Iorque levam o ExpressRoute nos E.U.A. Leste para o Azure E.U.A. Leste. O encaminhamento fica otimizado em ambos os lados.

Solução do Caso 1 do ExpressRoute - utilizar Comunidades do BGP

Nota

A mesma técnica, com a Preferência Local, pode ser aplicada ao encaminhamento do cliente para a rede virtual do Azure ao utilizar o peering privado. A Microsoft não identifica os valores da comunidade BGP com os prefixos anunciados do Azure para a sua rede. No entanto, uma vez que sabe qual da sua implementação de rede virtual está próxima de qual do seu escritório, pode configurar os routers em conformidade para preferir um circuito do ExpressRoute em vez de outro.

Encaminhamento inferior ao ideal da Microsoft para o cliente

Neste exemplo, temos ligações da Microsoft que tomam 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. Publicita os prefixos dos seus servidores no local em ambos os seus escritórios para a Microsoft através de dois circuitos do ExpressRoute.

Exchange Online inicia ligações aos servidores no local em casos como a migração da caixa de correio. A ligação ao seu escritório em Los Angeles é encaminhada para o circuito expressRoute no leste dos EUA antes de atravessar todo o continente de volta à costa oeste. A causa do problema é semelhante à anterior. Sem qualquer sugestão, a rede Microsoft não consegue saber qual o prefixo no local que está próximo do E.U.A. Leste e qual está próximo do E.U.A. Oeste. E escolhe o caminho errado para o seu escritório em Los Angeles.

Caso 2 do ExpressRoute - encaminhamento inferior ao ideal da Microsoft para o cliente

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

Existem duas soluções para o problema. A primeira é simplesmente anunciar o seu prefixo no local para o seu escritório em Los Angeles 177.2.0.0/31 no circuito expressRoute em E.U.A. Oeste. Em seguida, anuncia o seu prefixo no local para o seu escritório em Nova Iorque, 177.2.0.2/31 no circuito expressRoute no E.U.A. Leste. Como resultado, existe apenas um caminho para a Microsoft se ligar a cada um dos seus escritórios. Não existe ambiguidade e o encaminhamento está 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 do ExpressRoute for inativo, tem de se certificar de que Exchange Online ainda se consegue ligar aos seus servidores no local.

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, pode alongar o CAMINHO AS para 172.2.0.0/31 nos E.U.A. Leste para que prefiramos o circuito do ExpressRoute em E.U.A. Oeste para tráfego destinado a este prefixo. Da mesma forma, pode alongar o CAMINHO AS para 172.2.0.2/31 em E.U.A. Oeste para que prefira o circuito expressRoute no E.U.A. Leste. 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 CAMINHO AS para os prefixos recebidos no Peering da Microsoft ao peering utilizando um número AS privado. Tem de criar um peering com um AS público e acrescentar números AS públicos no CAMINHO AS para influenciar o encaminhamento para o Peering da Microsoft.

Solução do Caso 2 do ExpressRoute - utilizar prefixação COMO CAMINHO

Nota

Apesar de os exemplos apresentados aqui se referirem à Microsoft e aos Peerings públicos, também suportamos as mesmas funções no Peering 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 ver no diagrama seguinte, a partir de cada VNet existem dois caminhos para a outra VNet. As VNets não sabem que circuito do ExpressRoute é o local ou o remoto. Uma vez que o encaminhamento ECMP (Equal-Cost-Multi-Path) é utilizado para balancear a carga do tráfego entre VNet, alguns fluxos de tráfego seguem o caminho mais longo e são encaminhados no circuito remoto do ExpressRoute.

Caso 3 do ExpressRoute - encaminhamento inferior ao ideal entre redes virtuais

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 ligações, prefere que a ligação com a ponderação mais elevada envie tráfego destinado a esse prefixo.

Solução do Caso 3 do ExpressRoute - atribuir uma ponderação elevada à ligação no local

Nota

Também pode influenciar o encaminhamento da VNet para a sua rede no local, se tiver vários circuitos do ExpressRoute, ao configurar a ponderação de uma ligação em vez de aplicar a predefinição COMO PATH, 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.

Passos seguintes