Pular para conteúdo

Configurando Configurações Avançadas de BGP

Este tópico descreve como gerenciar as configurações avançadas do Border Gateway Protocol (BGP) no Megaport Cloud Router (MCR), incluindo:

  • Uma opção para substituir o número de sistema autônomo (ASN) padrão.
  • Uma opção de prepend de ASN para definir prioridades de anúncio de rota.
  • O Multi-Exit Discriminator (MED), que identifica o VXC preferido usado para redirecionar o tráfego após uma falha de rota.
  • O protocolo Bidirectional Forwarding Detection (BFD), que detecta falhas de caminho entre vizinhos BGP.

Substituindo o ASN do MCR

O ASNNúmero de Sistema Autônomo.
Uma coleção de prefixos de roteamento IP conectados, controlados por um ou mais operadores de rede em nome de uma única entidade ou domínio administrativo.
padrão atribuído ao MCR é 133937. Para a maioria das configurações, o ASN padrão é adequado. Opcionalmente, você pode especificar outro ASN local para substituir o ASN padrão em uma base por vizinho.

Importante

Provedores de nuvem podem ter restrições sobre o valor do ASN. Consulte a documentação do seu provedor de nuvem antes de substituir o valor padrão.

Para substituir o ASN do MCR

  1. Selecione o VXC e selecione a terminação A ou terminação B.

  2. Ao lado da conexão BGP, clique em Editar.

  3. Selecione a aba Avançado.

  4. No campo ASN Local, insira um ASN público ou privado (por exemplo, um número entre 64512 e 65534).

    O intervalo de ASN é de 2 a 4294967294, mas os seguintes ASNs não estão disponíveis:

    • 8074, 8075, 12076, 65515 - 65520 (reservados no Azure)
    • 23456, 64496-64511, 65535 - 65551 (reservados pela Internet Assigned Numbers Authority (IANA))

    Override MCR ASN

  5. Clique em Atualizar.

Definindo a prioridade de anúncio de rota com prepend de ASN

O comprimento do caminho ASN determina a prioridade de anúncio de rota para caminhos BGP de saída. A rota com o caminho de sistema autônomo (AS) mais curto tem a maior preferência e vence sobre qualquer anúncio de caminho mais longo. Caminhos mais longos têm prioridade mais baixa. O prepend de ASN aumenta o comprimento do caminho para reduzir a prioridade da rota.

Definir um valor de prepend de ASN é opcional.

Para definir a prioridade de anúncio de rota em uma conexão BGP existente

  1. Selecione o VXC e selecione a terminação A ou terminação B.
  2. Ao lado da conexão BGP, clique em Editar.
  3. Selecione a aba Avançado.

    ASN Prepend setting

  4. No campo Prepend do Caminho AS, insira o número de vezes adicionais para adicionar o ASN local ao caminho BGP. Insira inteiros dentro do intervalo de 1 a 10. Por exemplo, 2 adiciona o ASN ao caminho AS existente duas vezes, criando um comprimento de caminho AS de 3. Números mais altos reduzem a prioridade do caminho.

  5. Clique em Atualizar.

Para definir a prioridade de anúncio de rota em uma nova conexão BGP

  1. Adicione uma nova conexão BGP.
  2. Selecione a aba Avançado.
  3. No campo ASN Path Prepend, insira o número de vezes adicionais para adicionar o ASN local ao caminho BGP. Insira inteiros dentro do intervalo de 1 a 10. Por exemplo, 2 faz prepend do ASN ao caminho AS existente duas vezes, criando um comprimento de caminho AS de 3. Números maiores despriorizam o caminho.
  4. Clique em Adicionar.

Configurando o protocolo BFD

O BGP compartilha informações de acessibilidade de rede com sistemas BGP adjacentes, referidos como vizinhos ou pares. O protocolo BFD detecta falhas de caminho entre vizinhos BGP diretamente conectados, permitindo um tempo de reconvergência mais rápido no roteamento BGP. Ativar BFD em uma conexão VXC fornece detecção rápida de falhas de link e failover ao conectar-se a serviços que suportam BFD no vizinho remoto. Após o BFD ser ativado, uma relação de vizinhança BGP pode ser rapidamente encerrada após notificações do BFD, falhando para outro vizinho BGP.

O protocolo BFD opera independentemente do BGP. Quando o BFD é ativado, o failover é mais rápido, pois ocorre antes que o intervalo do temporizador do BGP termine. O valor padrão para o temporizador BGP é de 3 falhas de janela keep-alive de 60 segundos cada. Quando não ativado, o failover só ocorrerá após o intervalo do temporizador do BGP.

As configurações do BFD se aplicam a todas as conexões BGP na interface.

Importante

Para evitar alta utilização de CPU, antes de ativar o BFD, desative o envio de mensagens de redirecionamento de Internet Control Message Protocol (ICMP) inserindo o comando no ip redirect.

Para configurar o BFD

  1. Selecione o VXC e selecione a terminação A ou terminação B.

  2. Ao lado da conexão BGP, clique em Editar.

  3. Selecione a aba Avançado.

  4. Ao lado de Usar BFD, clique em Ligado.
    BFD settings

  5. Após Intervalo de Transmissão, especifique o tempo mínimo que o vizinho BGP envia pacotes de detecção de vida BFD para o vizinho BGP. O padrão é 300 milissegundos. O intervalo é de 300 a 9000 milissegundos.

  6. Após Intervalo de Recebimento, especifique o tempo mínimo que o vizinho BGP envia pacotes de detecção de vida BFD para esta interface. O padrão é 300 milissegundos. O intervalo é de 300 a 9000 milissegundos.

  7. Após Multiplicador, especifique o número mínimo de pacotes BFD que podem ser perdidos antes que a sessão BGP seja considerada offline. O padrão é 3 pacotes. O intervalo é de 3 a 50 pacotes.

  8. Clique em Atualizar.

Importante

Você deve ativar o BFD no vizinho BGP também.

Valores padrão de BFD por provedor de serviços de nuvem

  • AWS Direct Connect – O BFD é suportado nativamente por conexões AWS Direct Connect. O BFD assíncrono é automaticamente ativado para interfaces virtuais Direct Connect do AWS no lado do CSP. No entanto, você deve configurar o BFD nos VXCs do MCR para AWS Direct Connect para ativá-lo para sua conexão.

    O intervalo de detecção de vida padrão do BFD da AWS é de 300 milissegundos, e o multiplicador é de 3 pacotes.

    Aviso

    Confirme o suporte para outros vizinhos com seu CSP, assim como os valores padrão específicos.

  • Azure ExpressRoute – O BFD é suportado nativamente pelo Azure ExpressRoute em peering privado. O BFD é configurado por padrão em todas as interfaces de peering privado recém-criadas no ExpressRoute nos MSEEs. No entanto, você deve configurar os VXCs do MCR para o Azure ExpressRoute para ativar o BFD em sua conexão. Entre os pares BFD, o peer mais lento determina a taxa de transmissão.

  • Roteadores ExpressRoute Microsoft Enterprise Edge (MSEE) – Os intervalos de transmissão e recepção do BFD são configurados para 300 milissegundos. Em certos cenários, você pode definir os intervalos para um valor maior de 750 milissegundos. Você pode definir valores mais altos para aumentar os intervalos, mas não pode configurar valores inferiores a 300 milissegundos para diminuí-los.

  • Google Cloud Services – No final de 2021, o Google Cloud Partner Interconnect anunciou suporte para recursos aprimorados com seu serviço Interconnect. Os novos recursos estão incluídos no Dataplane V2. O BFD é um recurso que agora está disponível no V2. O BFD não era suportado antes do lançamento do V2.

    O Google está no processo de migração do V1 para o V2, com data de conclusão prevista para setembro de 2022. Para suportar os novos recursos, incluindo o BFD, o Local do Interconnect (Google Edge) e a região onde o Interconnect se conecta ao Google Cloud Router devem ter o V2 ativado. Para mais informações sobre como confirmar sua versão do Dataplane, veja Bidirectional Forwarding Detection (BFD) for Cloud Router.

    Importante

    Antes de ativar o BFD no MCR após 11 de maio de 2022, você precisa validar se o Megaport VXC/Google VLAN Attachment com seu serviço Partner Interconnect ativou o V2. Para mais informações sobre como validar sua versão do Dataplane, veja Bidirectional Forwarding Detection (BFD) for Cloud Router. Se o V2 não estiver ativado, você precisará abrir um caso de suporte do Google para ativá-lo. Em alguns casos, o V2 pode não estar disponível. Se sua VLAN Attachment não usar o Dataplane V2, não ative o BFD.

    O MCR opera automaticamente em modo BFD single-hop para os VXCs criados após 11 de maio de 2022. Os VXCs criados no MCR antes de 11 de maio de 2022 usam BFD multihop e não são compatíveis com o BFD. Você precisa reordenar quaisquer VXCs criados no MCR para o Google antes de 11 de maio de 2022 antes de poder ativar o BFD.

Configurando uma rota preferencial

Um Multi-Exit Discriminator (MED) é um atributo de caminho BGP que pode influenciar um vizinho BGP a escolher uma rota preferencial quando o sistema autônomo (AS) de anúncio é o mesmo para rotas candidatas e há múltiplos pontos de entrada para esse AS. Uma métrica MED mais baixa é preferida em relação a uma métrica mais alta. Você pode usar o atributo MED para alternar o tráfego entre dois VXCs e evitar o comportamento ECMP (equal-cost multipath).

Outros atributos BGP são levados em consideração antes de considerar o atributo MED. O atributo MED desempata entre duas rotas quando o peso, preferência local, caminho AS e tipo de origem são os mesmos. O ponto de saída com a métrica MED mais baixa é preferido.

Por exemplo, uma configuração que consiste em um dispositivo vizinho BGP, R3, com uma métrica MED de 20 e outro dispositivo vizinho, R2, com uma métrica MED de 10, fará com que o sistema autônomo (AS) 123 (do qual os dispositivos R2 e R3 são membros) prefira o caminho através do R2 para alcançar o ASN4.

Adicionar ou alterar uma métrica MED não interrompe o serviço.

Para configurar o MED

  1. Selecione o VXC e selecione terminação A ou terminação B.

  2. Ao lado da conexão BGP, clique em Editar.

  3. Selecione a aba Avançado.

  4. Ao lado de Inbound, especifique uma métrica MED de 32 bits para aplicar a todas as rotas recebidas nesta conexão BGP. Deixe em branco para usar o valor recebido do vizinho BGP. BFD settings

  5. Ao lado de Outbound, especifique uma métrica MED de 32 bits para aplicar a todas as rotas transmitidas por esta conexão BGP.

  6. Clique em Atualizar.

Usando o MED com o Google Cloud Platform

O egress do Google Cloud Platform Cloud Router é determinado pela primeira condição que for atendida:

  • Todo o tráfego de saída é enviado para a rota com o menor comprimento de caminho AS.
  • Se as rotas tiverem o mesmo comprimento de caminho AS, todo o tráfego de saída é enviado para a rota com o menor valor MED (a menor métrica da rota).
  • Se as rotas tiverem o mesmo comprimento de caminho AS e os mesmos valores MED (as mesmas métricas de rota), o tráfego de saída é balanceado entre todas as rotas usando equal-cost multipath (ECMP).

Aviso

Confirme o suporte para outros vizinhos com seu CSP, junto com quaisquer influências de métricas de roteamento específicas que possam ter maior prioridade que o MED.