O BGP é um protocolo de gateway externo padronizado projetado para trocar informações de roteamento e alcançabilidade entre sistemas autônomos (AS) na Internet.
Com base nas suas configurações e aproveitando as informações de roteamento BGP, a Nuvem Cato pode tomar decisões de roteamento em tempo real informadas sem que você precise configurar manualmente vários caminhos estáticos e/ou tomar qualquer ação. Isso possibilita suporte aprimorado para cenários como conexão direta e/ou configuração ativa-ativa na AWS, recuperação de desastres (DR) com IPs virtuais, integração com sistemas autônomos (AS) dentro de sites, e maior flexibilidade em implantações graduais.
Esta seção descreve os componentes BGP da Cato (incluindo objetos globais), e como o suporte da Cato para BGP é projetado e desempenha.
O suporte BGP da Cato é composto por três componentes principais: vizinhos BGP, faixas dinâmicas e faixas flutuantes.
Nota
Nota: Todas as faixas definidas na Faixa Nativa de um site são referidas como "faixas estáticas" em toda esta seção.
A conectividade é necessária para estabelecer sessões BGP com vizinhos. Estas são as opções de onde um vizinho BGP pode residir e sua interação resultante com sua conta na Nuvem Cato.
-
BGP entre Cato Networks PoP e um roteador BGP dentro de um túnel - Cato anuncia intervalos de conta, incluindo a rota padrão (0/0), e recebe estáticos, Faixas Dinâmicas e Faixas Flutuantes para um site. Por exemplo, o BGP é o modo preferido para troca de rotas em uma conexão Amazon AWS IPSec.
-
BGP entre a Nuvem Cato e um roteador BGP que reside na LAN / Alt. Link WAN - A Cato pode se comunicar com um vizinho BGP sobre intervalos estabelecidos na tomada: intervalos diretos, intervalos nativos, ou intervalos VLAN.
As sessões BGP podem ser estabelecidas apenas sobre intervalos roteados, desde que todos os intervalos tenham o mesmo próximo salto que o par BGP.
Nota
Notas:
-
Esta opção não depende do estabelecimento de um túnel.
-
A Cato assume que todas as conexões BGP são "next-hop-self": o vizinho é sempre o próximo salto selecionado pela Cato, e a Cato anuncia o IP do seu vizinho como o próximo salto para todas as rotas anunciadas.
-
Quando o BGP está no Alt. WAN, geralmente recebe intervalos de outros sites (todos os outros sites que são acessíveis via o Alt. Link WAN). A Cato filtra esses intervalos antes de considerar os intervalos dinâmicos e flutuantes.
-
Quando um Socket é desconectado da Nuvem Cato, todos os outros intervalos de sites são retirados. Isso permite a continuidade da alcançabilidade no caso de o par BGP ter um caminho secundário que possa ser usado alternativamente como um próximo salto se for temporariamente desconectado da Nuvem Cato. (Suportado a partir da Versão 17.0 do Socket e superior)
Para saber mais sobre a configuração de um vizinho BGP, veja Definindo Vizinhos BGP.
Existem várias etapas para estabelecer a conexão BGP. Dependendo do seu Tipo de Conexão, as conexões BGP são estabelecidas da seguinte forma:
-
Uma sessão TCP inicial é iniciada. Se a sessão TCP não puder ser estabelecida, uma tentativa é agendada a cada 30 segundos até que a sessão seja estabelecida com sucesso
-
Uma sessão BGP é iniciada imediatamente após a sessão TCP ser estabelecida
-
Se a sessão BGP não puder ser estabelecida, uma tentativa é agendada a cada 5 segundos
Nota: Para sites iPsec e Interconexão de Nuvem, uma tentativa é agendada a cada 15 segundos
-
Se uma sessão BGP for encerrada após ter sido estabelecida, a próxima tentativa é agendada a cada 1 segundo
Faixas dinâmicas são intervalos de IP que são aprendidos dinamicamente pela Cato de um vizinho BGP. Uma vez aceitas pela Cato, elas se propagam por toda uma conta e se tornam acessíveis via aquele vizinho de qualquer lugar na rede.
Nota
Nota: Como faixas dinâmicas são aprendidas dinamicamente do vizinho BGP e não podem ser configuradas como objetos globais no Aplicativo de Gerenciamento Cato, elas não podem ser usadas explicitamente em regras de rede e/ou segurança, e portanto se comportam de acordo a política do site em que residem.
Faixas flutuantes são intervalos de IP globais que não estão conectados a um site específico, mas podem ser aprendidos de qualquer site com um vizinho BGP. Por exemplo, em um cenário de Recuperação de Desastres (DR), muitas aplicações (como VMware NSX) podem mover servidores de uma localização para a outra mantendo seus endereços IP. Nesses casos, o BGP ajuda a atualizar os objetos de rede restantes e anuncia onde esses servidores residem agora.
Intervalos flutuantes são definidos como objetos globais. Faixas Flutuantes não estão associadas a um Site específico e devem ser definidas em regras de Segurança ou Redes (a associação de Site pode mudar dinamicamente). Você pode aproveitar a definição do objeto global para criar explicitamente regras de rede e/ou segurança de acordo com os requisitos de política da sua organização.
Para que um intervalo de faixa dinâmica BGP herde a segurança ou política de rede para uma faixa flutuante, deve corresponder exatamente à faixa flutuante. Por exemplo, se o intervalo dinâmico BGP é 192.168.1.0/24 e o intervalo flutuante é definido como 192.168.1.1/32, então não há conexão entre eles e o intervalo dinâmico BGP não herda as políticas do intervalo flutuante.
Nota
Nota: Faixas Flutuantes não podem se sobrepor a intervalos estáticos.
O vizinho BGP na Cato Cloud está conectado a um PoP da Cato ou com a conexão do Site. A conexão do Site pode ser um Socket ou um túnel IPsec. Quando a Cato Cloud recebe uma nova rota BGP ou atualizada, ela sempre se sincroniza com a rede WAN global (conexões de Site e PoPs).
Quando uma rota BGP é recebida, Cato a associa ao objeto relevante da seguinte forma:
-
Intervalos de IP definidos como intervalos flutuantes são associados aos seus objetos definidos e aderem a todas as políticas de rede e segurança atribuídas aos objetos.
-
Todos os outros intervalos de IP são considerados como intervalos dinâmicos e aderem a todas as políticas de rede e segurança atribuídas ao Site.
Rotas podem ser retiradas através de uma mensagem BGP ou através de um desconexão do vizinho (CEASE ou física), e a Cato Cloud imediatamente propaga a retirada.
Sites na Cato, como sites IPSec ou Socket, podem ter múltiplos túneis conectados para enviar tráfego sobre a LAN ou a Internet. Se múltiplos túneis estão conectados, sua prioridade é baseada na qualidade do link e outros fatores. A tela Tabela de Roteamento (Monitoramento > Tabela de Roteamento) mostra a Métrica do Túnel para as rotas. Este é o valor que a Cato atribui para garantir que o tráfego seja enviado pelo melhor túnel. Quanto menor o valor da Métrica do Túnel indica que esse túnel tem uma prioridade maior. Por exemplo, em uma implantação de Alta Disponibilidade de Socket, o túnel ativo pode ter uma métrica de 5 e o túnel do socket passivo tem uma métrica de 10.
Ao contrário dos intervalos estáticos regulares, o BGP permite múltiplas rotas que podem se sobrepor ou até mesmo serem duplicadas em partes da sua rede. Então, como a Cato Cloud decide por qual caminho rotear os pacotes?
Quando múltiplas rotas podem ser aplicadas a um endereço IP de destino, as decisões de roteamento serão realizadas de acordo com as seguintes prioridades:
-
Rotas mais específicas são selecionadas sobre rotas menos específicas (/24 sobre /22 e assim por diante).
-
A ordem de preferência para os seguintes intervalos de IP:
-
Intervalos estáticos
-
Intervalos flutuantes
-
Intervalos dinâmicos
-
-
Métrica de vizinho mais baixa é preferida.
-
Caminho AS-PATH mais curto é preferido.
-
Métrica do Túnel mais baixa é preferida.
-
Menor BGP MED (Multi-Exit-Discriminator) do ID da rota é preferido.
Desde a Cato Cloud realiza o Roteamento Baseado em Política de Camada 7, a necessidade de evitar rotas assimétricas é decisiva. Por esse motivo, a prioridade da rota é universal dentro da mesma conta: em outras palavras, uma única origem será selecionada de qualquer localização dentro da rede Cato Cloud.
Quando rotas são aceitas por um vizinho BGP, as informações associadas a ela (Caminho AS, Comunidades BGP) são preservadas. Quando intervalos dinâmicos são anunciados para vizinhos BGP, o Caminho AS será anexado com o número AS da Cato Cloud (como usual com BGP).
Cato propaga transparentemente todos os Atributos de Caminho marcados com a bandeira Transitiva (RFC 4271), incluindo Comunidades.
Os intervalos de conta (estáticos) são anunciados com o ASN do Vizinho Cato Socket como o ASN de origem (Número do Sistema Autônomo - veja abaixo Atribuindo um ASN a um Vizinho).
Para mais sobre resumos de rotas BGP, consulte Trabalhando com Resumos de Rotas BGP.
Nota
Nota: Algumas comunidades bem conhecidas não são propagadas pela Cato para vizinhos BGP na saída, como no-export.
O ASN é um número entre 64.512 – 65.534 (ASN privado), que representa a entidade de roteamento que estabelece a comunicação. O ASN padrão da Cato Networks é 64.515.
Cato Cloud suporta eBGP, então um vizinho BGP deve ter um ASN diferente do lado da Cato Cloud.
Nota
Nota: É uma boa prática usar globalmente um único ASN para representar o lado de comunicação da Cato Cloud em todas as sessões BGP. Se você estiver considerando usar diferentes ASNs para diferentes vizinhos, por favor, contate o Suporte.
Como loops são prevenidos
Quando uma rota é recebida pela Cato, o Caminho AS é verificado para o ASN do vizinho da Cato Cloud. Qualquer rota que contenha este ASN será Descartado. Observe que o vizinho apenas verifica o ASN do vizinho atual.
Nota
Nota: Cato não suporta Reinício Gradual.
Intervalos dinâmicos são automaticamente associados ao site de onde a rota foi recebida e herdam todos os grupos de política, políticas de rede e políticas de segurança. Faixas flutuantes são definidas globalmente e as regras de segurança são aplicadas diretamente a elas, ou ao associá-las a grupos de política.
Quais Tipos de Conexão de Site eu posso usar?
-
Cato suporta BGP para sites que usam Sockets, vSockets e sites IPSec (IPsec IKEv1 iniciado pela Cato, IPSec IKEv2). Além disso, é necessário ter conectividade com seus roteadores BGP existentes.
Como o vizinho BGP irá estabelecer a sessão BGP com a Cato?
-
Sessões BGP requerem conectividade estabelecida entre um vizinho BGP e um site através de rotas locais em sockets ou através de um túnel IPSec.
-
Para a implantação do Socket Cato, apenas faixas diretas, VLAN e nativas podem ser usadas para estabelecer sessões
As sessões BGP podem ser estabelecidas apenas sobre faixas roteadas desde que todas as faixas tenham o mesmo Próximo Salto que o par BGP.
Configuração de Sessões BGP sobre Links WAN Alternativos
Na Cato, destinos WAN alternativos incluem duas redes (potencialmente marcadas com VLAN): pública e privada. Um vizinho BGP deve estar dentro de uma dessas duas redes, e o vizinho BGP no lado da Cato Cloud será o IP da Cato correspondente para essa faixa.
Ao definir uma sessão BGP sobre uma interface pública, você também pode realizar NAT de Origem no tráfego que atravessa esse link. Isso significa que para todo o tráfego de saída através desse vizinho, o endereço de origem será o IP Cato.
-
A Cato Cloud suporta apenas IPv4.
-
Se múltiplos ASNs forem configurados para múltiplos vizinhos, os ASNs não serão Detectados pelo vizinho e podem resultar em loops.
-
A Cato Cloud permite a propagação de rotas que Contém o ASN do vizinho, confiando no vizinho para verificar loops.
-
Faixas flutuantes não podem se sobrepor a uma faixa estática.
-
Cato não suporta Reinício Gradual para retirada de rota.
-
Mudanças de rota BGP (incluindo retirada de rota) que são iniciadas pela Cato, não geram Eventos.
-
Cato não realiza a sumarização de rotas.
-
Por padrão, a Cato limita o número de prefixos recebidos de cada vizinho BGP a 1024. Para aumentar este Limite, contate o Suporte.
-
BGP não é suportado para contas que usam Tradução de Intervalo Estático. Se você precisar de BGP para uma Faixa Nativa traduzida para um site Socket, por favor, contate o Suporte.
0 comentário
Por favor, entre para comentar.