Por que as comunidades BGP são melhores que os prefixos AS-path

A internet, em sua forma mais pura, é um esquema conectado de forma livre de redes independentes (também chamadas de Sistemas Autônomos [AS, para abreviar]). Essas redes usam um protocolo de sinalização chamado BGP (Border Gateway Protocol) para informar seus vizinhos (também conhecidos como pares) sobre a acessibilidade de prefixos de IP (um grupo de endereços de IP) em e por meio de sua rede. Parte dessa troca contém metadados úteis sobre o prefixo de IP que são usados para informar as decisões de roteamento da rede. Um exemplo de metadados é o AS-path completo, que consiste nos diferentes sistemas autônomos pelos quais um pacote IP precisa passar para chegar ao seu destino.

Como todos queremos que nossos pacotes cheguem ao seu destino o mais rápido possível, selecionar o AS-path mais curto para um determinado prefixo é uma boa ideia. É aqui que algo chamado prefixo entra em jogo.

Roteamento na internet, o básico

Vamos falar brevemente sobre como a internet funciona em seu nível mais fundamental, antes de nos aprofundarmos em alguns detalhes essenciais.

A internet é, em sua essência, uma rede extremamente interconectada de milhares de redes. Cada rede possui duas coisas que são críticas:

1. Um Número de Sistema Autônomo (ASN): um inteiro de 32 bits que identifica exclusivamente uma rede. Por exemplo, um dos ASNs da Cloudflare (temos vários) é 13335.

2. Prefixos de IP: Um prefixo de IP é um intervalo de endereços de IP agrupados em potências de dois: no espaço IPv4, dois endereços formam um prefixo /31, quatro formam um prefixo /30 e assim por diante, até /0, que é uma abreviação de “todos os prefixos de IPv4”. O mesmo se aplica ao IPv6, mas em vez de agregar no máximo 32 bits, você pode agregar até 128 bits. A figura abaixo mostra essa relação entre os prefixos de IP, ao contrário, um /24 que contém dois /25s que contém dois /26s e assim por diante.

Para se comunicar na internet, você deve ser capaz de chegar ao seu destino, e é aí que entram os protocolos de roteamento. Eles permitem que cada nó na internet saiba para onde enviar sua mensagem (e que o destinatário envie uma mensagem de volta).

Conforme mencionado anteriormente, esses destinos são identificados por endereços de IP e intervalos contíguos de endereços de IP são expressos como prefixos de IP. Usamos prefixos de IP para roteamento como uma otimização de eficiência: Manter o controle de onde ir para quatro bilhões (2³²) de endereços de IP em IPv4 seria incrivelmente complexo e exigiria muitos recursos. Aderir aos prefixos reduz esse número para cerca de um milhão.

Agora lembre-se de que os Sistemas Autônomos são operados e controlados de forma independente. Na rede de redes da internet, como digo à Origem A em alguma outra rede que existe um caminho disponível para chegar ao Destino B na (ou através da) minha rede? Aí entra o BGP. O BGP é o Border Gateway Protocol e é usado para sinalizar informações de acessibilidade. As mensagens de sinal geradas pelo ASN de origem são referidas como "anúncios" porque declaram à internet que os endereços de IP no prefixo estão on-line e acessíveis.

Dê uma olhada na figura acima. A Origem A agora deve saber como chegar ao Destino B por meio de duas redes diferentes.

Esta é a aparência de uma mensagem BGP real:

BGP Message
    Type: UPDATE Message
    Path Attributes:
        Path Attribute - Origin: IGP
        Path Attribute - AS_PATH: 64500 64496
        Path Attribute - NEXT_HOP: 198.51.100.1
        Path Attribute - COMMUNITIES: 64500:13335
        Path Attribute - Multi Exit Discriminator (MED): 100
    Network Layer Reachability Information (NLRI):
        192.0.2.0/24

Como você pode ver, as mensagens BGP contêm mais do que apenas o prefixo de IP (o NLRI bit) e o caminho, mas também vários outros metadados que fornecem informações adicionais sobre o caminho. Outros campos incluem comunidades (mais sobre isso adiante), bem como MED, ou código de origem. MED é uma sugestão para outras redes conectadas diretamente sobre qual caminho deve ser seguido se várias opções estiverem disponíveis, o valor mais baixo vence. O código de origem pode ser um dos três valores: IGP, EGP ou Incompleto. O IGP será definido se você originar o prefixo através do BGP. O EGP não é mais usado (é um protocolo de roteamento antigo) e Incompleto é definido quando você distribui um prefixo no BGP de outro protocolo de roteamento (como IS-IS ou OSPF).

Agora que a origem A sabe como chegar ao destino B por meio de duas redes diferentes, vamos falar sobre engenharia de tráfego.

Engenharia de tráfego

A engenharia de tráfego é uma parte essencial do gerenciamento diário de qualquer rede. Assim como no mundo físico, os desvios podem ser implementados pelos operadores para otimizar os fluxos de tráfego de entrada e saída de sua rede. A engenharia de tráfego de saída é significativamente mais fácil do que a engenharia de tráfego de entrada porque os operadores podem escolher entre redes vizinhas e até mesmo priorizar alguns tráfegos em detrimento de outros. Em contraste, a engenharia de tráfego de entrada requer influenciar uma rede que é totalmente operada por outra pessoa. A autonomia e o autogoverno de uma rede são fundamentais, portanto, os operadores usam as ferramentas disponíveis para informar ou moldar os fluxos de pacotes de entrada de outras redes. A compreensão e utilização dessas ferramentas é complexa e pode ser um desafio.

O conjunto disponível de ferramentas de engenharia de tráfego, tanto de entrada quanto de saída, depende da manipulação de atributos (metadados) de uma determinada rota. Como estamos falando sobre engenharia de tráfego entre redes independentes, vamos manipular os atributos de uma rota aprendida por EBGP. O BGP pode ser dividido em duas categorias:

1. EBGP: comunicação BGP entre dois ASNs diferentes
2. IBGP: comunicação BGP no mesmo ASN

Embora o protocolo seja o mesmo, certos atributos podem ser trocados em uma sessão IBGP que não são trocados em uma sessão EBGP. Um deles é a preferência local. Vamos ver mais sobre isso em breve.

Seleção do melhor caminho BGP

Quando uma rede está conectada a várias outras redes e provedores de serviços, ela pode receber informações de caminho para o mesmo prefixo de IP de muitas dessas redes, cada uma com atributos ligeiramente diferentes. Cabe então à rede receptora dessas informações usar um algoritmo para seleção do melhor caminho BGP para escolher o “melhor” prefixo (e rota) e usá-lo para encaminhar o tráfego de IP. Coloquei “melhor” entre aspas, pois melhor é um requisito subjetivo. “Melhor” geralmente é o mais curto, mas o que pode ser melhor para minha rede pode não ser o melhor resultado para outra rede.

O BGP considera vários atributos de prefixo ao filtrar pelas opções recebidas. No entanto, em vez de combinar todos esses atributos em um único critério de seleção, a seleção do melhor caminho do BGP usa os atributos em níveis, em qualquer nível, se os atributos disponíveis forem suficientes para escolher o melhor caminho, o algoritmo termina com essa escolha.

O algoritmo de seleção do melhor caminho de BGP é extenso, contendo 15 etapas diferentes para selecionar o melhor caminho disponível para um determinado prefixo. Dadas as inúmeras etapas, é do interesse da rede decidir o melhor caminho o mais cedo possível. As primeiras quatro etapas são as mais usadas e influentes e são representadas na figura abaixo como funis.

Escolher o caminho mais curto possível geralmente é uma boa ideia, e é por isso que o “AS-path length” é uma etapa executada no início do algoritmo. Porém, olhando a figura acima, o “AS-path length” aparece em segundo lugar, apesar de ser o atributo para encontrar o caminho mais curto. Então vamos falar sobre o primeiro passo: preferência local.

Preferência local
A preferência local é uma das favoritas dos operadores porque permite que eles escolham a dedo uma combinação de rota+caminho de sua escolha. É o primeiro atributo no algoritmo porque é único para qualquer combinação de rota+vizinho+AS-path.

Uma rede define a preferência local na importação de uma rota (tendo aprendido sobre a rota de uma rede vizinha). Sendo uma propriedade não transitiva, ou seja, é um atributo que nunca é enviado em uma mensagem EBGP para outras redes. Isso significa intrinsecamente, por exemplo, que o operador do AS 64496 não pode definir a preferência local de rotas para seus próprios (ou em trânsito) prefixos de IP dentro do AS 64511 vizinho. A incapacidade de fazer isso é parcialmente o motivo pelo qual a engenharia de tráfego de entrada por meio do EBGP é tão difícil.

O prefixo aumenta artificialmente o AS-path length
Como nenhuma rede é capaz de definir diretamente a preferência local por um prefixo dentro de outra rede, a primeira oportunidade de influenciar as escolhas de outras redes é modificando o AS-path. Se os próximos saltos forem válidos e a preferência local para todos os caminhos diferentes para uma determinada rota for a mesma, modificar o AS-path é uma opção óbvia para alterar o caminho que o tráfego seguirá em direção à sua rede. Em uma mensagem BGP, o prefixo se parece com isto:

ANTES:

BGP Message
    Type: UPDATE Message
    Path Attributes:
        Path Attribute - Origin: IGP
        Path Attribute - AS_PATH: 64500 64496
        Path Attribute - NEXT_HOP: 198.51.100.1
        Path Attribute - COMMUNITIES: 64500:13335
        Path Attribute - Multi Exit Discriminator (MED): 100
    Network Layer Reachability Information (NLRI):
        192.0.2.0/24

DEPOIS:

BGP Message
    Type: UPDATE Message
    Path Attributes:
        Path Attribute - Origin: IGP
        Path Attribute - AS_PATH: 64500 64496 64496
        Path Attribute - NEXT_HOP: 198.51.100.1
        Path Attribute - COMMUNITIES: 64500:13335
        Path Attribute - Multi Exit Discriminator (MED): 100
    Network Layer Reachability Information (NLRI):
        192.0.2.0/24

Especificamente, os operadores podem fazer o prefixo AS-path. Ao fazer o prefixo AS-path, um operador adiciona sistemas autônomos adicionais ao caminho (geralmente o operador usa seu próprio AS, mas o protocolo não impõe isso). Desta forma, um AS-path pode ir de 1 a 255 de comprimento. Como o comprimento agora aumentou drasticamente, aquele caminho específico para a rota não será escolhido. Ao alterar o AS-path anunciado para diferentes pares, um operador pode controlar os fluxos de tráfego que entram em sua rede.

Infelizmente, o prefixo tem um problema: para ser o fator decisivo, todos os outros atributos precisam ser iguais. Isto raramente é verdadeiro, especialmente em grandes redes que podem escolher entre muitas rotas possíveis para um destino.

Mecanismo de política de negócios

O BGP também é coloquialmente referido como um mecanismo de política de negócios: ele não seleciona o melhor caminho do ponto de vista do desempenho; em vez disso, e na maioria das vezes, ele seleciona o melhor caminho do ponto de vista comercial. Os critérios de negócios podem ser qualquer coisa, desde a eficiência do investimento (porta) até o aumento da receita e muito mais. Isso pode soar estranho, mas, acredite ou não, é para isso que o BGP foi projetado. O poder (e a complexidade) do BGP é que ele permite que um operador de rede faça escolhas de acordo com as necessidades, contratos e políticas do operador, muitos dos quais não podem ser refletidos pelas noções convencionais de desempenho de engenharia.

Preferências locais diferentes

Muitas redes (incluindo a Cloudflare) atribuem uma preferência local dependendo do tipo de conexão usada para nos enviar as rotas. Um valor mais alto é uma preferência mais alta. Por exemplo, rotas aprendidas de conexões de rede em trânsito terão uma preferência local menor de 100 porque são as mais caras de usar; as rotas aprendidas de backbone serão 150, as rotas de troca de internet (IX) obterão 200 e, por último, as rotas de interconexão privada (PNI) obterão 250. Isso significa que, para o tráfego de saída, a rede da Cloudflare, por padrão, vai preferir uma rota aprendida de PNI, mesmo se um AS-path mais curto estiver disponível através de uma IX ou vizinho de trânsito.

Parte do motivo pelo qual uma PNI é preferível a uma IX é a confiabilidade, porque não há nenhuma plataforma de comutação de terceiros envolvida que esteja fora de nosso controle, o que é importante porque operamos com a suposição de que todo hardware pode e acabará quebrando. Outra parte do motivo é por razões de eficiência de porta. Aqui, a eficiência é definida pelo custo por megabit transferido em cada porta. Grosso modo, o custo é calculado por:

((custo_do_switch / contagem_de_portas) + custo_do_transceptor)

que é combinado com o custo de conexão cruzada (pode ser recorrente mensal (MRC) ou uma taxa única). A PNI é preferível porque ajuda a otimizar o valor reduzindo o custo geral por megabit transferido, porque o preço unitário diminui com a maior utilização da porta.

Esse raciocínio é semelhante para muitas outras redes e é muito comum em redes de trânsito. O BGP tem tanto a ver com custo e política de negócios quanto com desempenho.

Preferência de trânsito local

Para simplificar, quando me refiro a trânsitos, refiro-me às redes de trânsito tradicionais de nível 1. Devido à natureza dessas redes, elas têm dois conjuntos distintos de pares de rede:

1. Clientes (como a Cloudflare)
2. Settlement-free peers (como outras redes de nível 1)

Em circunstâncias normais, os clientes de trânsito recebem uma preferência local mais alta atribuída do que a preferência local usada para seus settlement-free peers. Isso significa que, não importa o quanto de prefixo você anexa, se o tráfego entrar nessa rede de trânsito, o tráfego sempre chegará à sua interconexão com essa rede de trânsito e não será descarregado para outro ponto.

Um prefixo ainda pode ser usado se você quiser alternar/descarregar o tráfego de um único link com um trânsito, se você tiver vários links distintos com eles ou se a origem do tráfego for multihomed atrás de vários trânsitos (e eles não tiverem seus próprios manuais de preferência local preferindo um trânsito em detrimento de outro). Mas o tráfego de engenharia de tráfego de entrada de uma porta de trânsito para outra por meio do prefixo AS-path tem retornos decrescentes significativos: depois de passar de três prefixos, é improvável que mude muito, se houver alguma coisa, nesse ponto.

Exemplo

No cenário acima, não importa o ajuste que a Cloudflare faça em seu AS-path em direção ao AS 64496, o tráfego continuará fluindo pela interconexão Transit B <> Cloudflare, mesmo que o caminho Origin A → Transit B → Transit A → Cloudflare seja mais curto do ponto de vista do AS-path.

Neste cenário, não mudou muito, mas a Origem A agora é multihomed atrás dos dois provedores de trânsito. Nesse caso, o prefixo do AS-path foi eficaz, pois os caminhos vistos no lado da Origem A são tanto o caminho prefixado quanto o não prefixado. Contanto que a Origem A não esteja fazendo nenhuma engenharia de tráfego de saída e esteja tratando ambas as redes de trânsito igualmente, o caminho escolhido será Origin A → Transit A → Cloudflare.

Engenharia de tráfego baseada na comunidade

Portanto, agora identificamos um problema bastante crítico no ecossistema da internet para os operadores: com as ferramentas mencionadas acima, nem sempre (alguns podem até dizer que é totalmente impossível) é possível ditar com precisão os caminhos que o tráfego pode entrar em sua própria rede, reduzindo o controle que um sistema autônomo tem sobre sua própria rede. Felizmente, existe uma solução para esse problema: a preferência local baseada na comunidade.

Alguns provedores de trânsito permitem que seus clientes influenciem a preferência local na rede de trânsito por meio do uso de comunidades BGP. As comunidades BGP são um atributo transitivo opcional para um anúncio de rota. As comunidades podem ser informativas (“aprendi esse prefixo em Roma”), mas também podem ser usadas para desencadear ações no lado receptor. Por exemplo, a Cogent publica as seguintes comunidades de ação:

Quando você sabe que a Cogent usa as seguintes preferências locais padrão em sua rede:

Pares → Preferência local 100
Clientes → Preferência local 130

É fácil ver como poderíamos usar as comunidades fornecidas para alterar a rota usada. É importante notar, porém, que, como não podemos definir a preferência local de uma rota para 100 (ou 130), o prefixo AS-path permanece amplamente irrelevante, pois a preferência local nunca será a mesma.

Veja a seguinte configuração como exemplo:

term ADV-SITELOCAL {
    from {
        prefix-list SITE-LOCAL;
        route-type internal;
    }
    then {
        as-path-prepend "13335 13335";
        accept;
    }
}

Anexamos o Cloudflare ASN duas vezes, resultando em um AS-path total de três, mas ainda víamos muito (muito) tráfego entrando em nosso link Cogent. Nesse ponto, um engenheiro poderia adicionar outro prefixo, mas para uma rede bem conectada como a Cloudflare, se dois prefixos, ou três, não fazem muito, então quatro ou cinco também não vão fazer. Em vez disso, podemos aproveitar as comunidades Cogent documentadas acima para alterar o roteamento dentro do Cogent:

term ADV-SITELOCAL {
    from {
        prefix-list SITE-LOCAL;
        route-type internal;
    }
    then {
        community add COGENT_LPREF70;
        accept;
    }
}

A configuração acima altera o fluxo de tráfego para isto:

Que é exatamente o que queríamos.

Conclusão

O prefixo AS-path ainda é útil e tem seu uso como parte da cadeia de ferramentas para os operadores fazerem engenharia de tráfego, mas deve ser usado com moderação. A prefixação excessiva abre uma rede para sequestros de rota de propagação mais ampla, que devem ser evitados a todo custo. Como tal, usar a engenharia de tráfego de entrada baseada na comunidade é altamente preferido (e recomendado). Nos casos em que as comunidades não estão disponíveis (ou não estão disponíveis para direcionar o tráfego do cliente), os prefixos podem ser aplicados, mas eu incentivo os operadores a monitorar ativamente seus efeitos e revertê-los se forem ineficazes.

Uma observação, P. Marcos et al. publicaram um artigo interessante sobre o prefixo AS-path e abordam algumas tendências observadas em relação ao prefixo, recomendo fortemente a leitura: https://www.caida.org/catalog/papers/2020_aspath_prepending/aspath_prepending.pdf