"Estabelecemos uma conexão telefônica entre nós e a equipe da SRI...", disse Kleinrock em uma entrevista:
"Digitamos o 'L' e perguntamos pelo telefone, 'Você vê o 'L'?"
"Sim, vemos o 'L'," foi a resposta.
"Digitamos o 'O' e perguntamos, 'Você vê o 'O'?"
"Sim, vemos o 'O'."
"Então digitamos o 'G' e o sistema travou"...Ainda assim, uma revolução havia começado...
O início da internet.
Olá a todos!
Meu nome é Alexandre, sou engenheiro de rede na empresa Linxdatacenter. No artigo de hoje, falarei sobre os pontos de troca de tráfego (Internet Exchange Point, IXP): o que precedeu o seu aparecimento, quais problemas eles resolvem e como são construídos. Também neste artigo, demonstrarei o princípio de funcionamento do IXP utilizando a plataforma EVE-NG e o roteador BIRD, para que fique claro como isso funciona "por trás das cortinas".
Um pouco de história
Se observamos , podemos notar que o crescimento explosivo do número de pontos de troca de tráfego começou em 1993. Isso ocorreu porque a maior parte do tráfego dos operadores de telecomunicações da época passava pela rede backbone dos EUA. Assim, por exemplo, quando o tráfego ia de um operador na França para um operador na Alemanha, ele primeiro chegava aos EUA, e só depois seguia da EUA para a Alemanha. A rede backbone atuava como um trânsito entre a França e a Alemanha. Mesmo o tráfego dentro de um único país frequentemente não seguia diretamente, mas passava pelas redes de operadoras americanas.
Essa situação afetava não apenas o custo de entrega do tráfego em trânsito, mas também a qualidade das conexões e o atraso. O número de usuários da internet aumentava, novos operadores surgiam, e o volume de tráfego crescia, à medida que a internet amadurecia. Operadores ao redor do mundo começaram a perceber que era necessário um enfoque mais racional na organização da interação entre operadores. "Por que eu, operador A, deveria pagar pelo trânsito em outro país para entregar tráfego ao operador B, que está na rua ao lado?". Essa era a questão que os operadores se faziam na época. Assim, em diferentes partes do mundo, nos pontos de concentração dos operadores começaram a surgir os pontos de troca de tráfego:
- 1994 – LINX em Londres,
- 1995 – DE-CIX em Frankfurt,
- 1995 – MSK-IX, em Moscovo, etc.
A internet e os nossos dias
Conceitualmente, a arquitetura da internet moderna consiste em múltiplos sistemas autônomos (autonomous system, AS) e inúmeras conexões entre eles, tanto físicas quanto lógicas, que determinam o caminho que o tráfego segue de um AS para outro.
Normalmente, os AS são operadoras de telecomunicações, provedores de internet, CDN, data centers e empresas do segmento empresarial. Os AS organizam conexões lógicas (peering) entre si, geralmente por meio do protocolo BGP.
A forma como os sistemas autônomos organizam essas conexões é definida por uma série de fatores:
- geográficos,
- econômicos,
- políticos,
- acordos e interesses comuns entre os proprietários dos AS,
- etc.
Certamente, nessa estrutura há uma certa hierarquia. Assim, as operadoras são divididas em tier-1, tier-2 e tier-3, e se os clientes de um provedor de internet local (tier-3) são, em regra, usuários comuns, por exemplo, para operadoras de tier-1, os clientes são outras operadoras. As operadoras tier-3 agregam o tráfego de seus assinantes, as operadoras tier-2, por sua vez, agregam o tráfego das operadoras tier-3, e as tier-1 – todo o tráfego da internet.
Esquematicamente, pode ser representado assim:
Nesta imagem, é visível que o tráfego é agregado de baixo para cima, ou seja, dos usuários finais para as operadoras tier-1. Também ocorre troca horizontal de tráfego entre ASs aproximadamente equivalentes.
Uma parte integrante e, ao mesmo tempo, uma desvantagem dessa estrutura é uma certa desorganização nas conexões entre os sistemas autônomos, que estão mais próximos do usuário final, dentro da zona geográfica. Vamos analisar a imagem abaixo:
Suponha que em uma grande cidade existam 5 operadoras de telecomunicações, cujo peering, por razões variadas, é organizado como mostrado acima.
Se o usuário Petya, conectado ao provedor de internet Go, desejar acessar um servidor conectado ao provedor ASM, o tráfego entre eles será obrigado a passar por 5 sistemas autônomos. Assim, aumenta a latência, pois cresce o número de dispositivos de rede pelos quais o tráfego passará, assim como o volume de tráfego de trânsito nos sistemas autônomos entre Go e ASM.
Como reduzir o número de ASs de trânsito que o tráfego é obrigado a percorrer? Correto – um ponto de troca de tráfego.
Nos dias atuais, o surgimento de novos IXPs é motivado pelas mesmas necessidades que existiam no início dos anos 90 e 2000, mas em uma escala menor, em resposta ao aumento do número de provedores de telecomunicações, usuários e tráfego, além da crescente quantidade de conteúdo gerado por redes CDN e data centers.
O que é um ponto de troca de tráfego?
Um ponto de troca de tráfego é um local com uma infraestrutura de rede especial, onde participantes interessados na troca mútua de tráfego organizam o peering mútuo. Os principais participantes dos pontos de troca de tráfego incluem provedores de telecomunicações, provedores de internet, provedores de conteúdo e data centers. Nos pontos de troca de tráfego, os participantes se conectam diretamente entre si. Isso permite resolver as seguintes questões:
- reduzir a latência,
- diminuir a quantidade de tráfego de transitário,
- otimizar a roteação entre AS.
Considerando que IXPs estão presentes em muitas grandes cidades do mundo, isso tem um impacto positivo na rede de Internet como um todo.
Se a situação descrita acima com o Petya for resolvida utilizando IXPs, seria algo assim:
Como funciona um ponto de troca de tráfego?
Em geral, um IXP é uma AS separada com seu próprio bloco de endereços públicos IPv4/IPv6.
A rede IXP na maioria das vezes é um domínio L2 contínuo. Às vezes, é apenas uma VLAN na qual todos os clientes do IXP estão localizados. Quando se trata de IXPs maiores e geograficamente distribuídos, tecnologias como MPLS, VXLAN, etc., podem ser utilizadas para organizar um domínio L2.
Elementos do IXP
- SCS. Aqui não há nada de incomum: racks, cross connects, painéis de patch.
- Os switches – a base do IXP. A porta do switch é o ponto de entrada na rede IXP. Além disso, os switches desempenham parte das funções de segurança - filtram o tráfego indesejado que não deveria estar presente na rede IXP. Na maioria das vezes, os switches são selecionados de acordo com os requisitos funcionais - confiabilidade, velocidade de porta suportada, funções de segurança, suporte a sFlow, etc.
- Servidor de roteamento (RS) – uma parte essencial e necessária de qualquer ponto moderno de intercâmbio de tráfego. Seu funcionamento é muito semelhante ao route reflector no iBGP ou ao designated router no OSPF, resolvendo os mesmos problemas. À medida que o número de participantes no ponto de troca de tráfego aumenta, o número de sessões BGP que cada participante precisa manter também cresce, ou seja, isso lembra a clássica topologia full-mesh no iBGP. O RS resolve o problema da seguinte maneira: estabelece uma sessão BGP com cada participante interessado do IXP, que se torna um cliente do RS. Aceitando atualizações BGP de um de seus clientes, o RS distribui essas atualizações a todos os seus outros clientes, exceto aquele de onde a atualização foi recebida. Assim, o RS elimina a necessidade de estabelecer uma conexão full-mesh entre todos os participantes do IXP e resolve elegantemente o problema da escalabilidade. Vale ressaltar que o servidor de rotas transmite de forma transparente rotas de um AS para outro, sem alterar os atributos BGP transmitidos, como não adicionar seu número de AS no AS-path. Além disso, o RS realiza uma filtragem básica de rotas: por exemplo, o RS não aceita redes martianas e os prefixos do próprio IXP.
Como solução, o route server geralmente utiliza um roteador de software de código aberto – BIRD (bird internet routing daemon). Ele é vantajoso porque é gratuito, pode ser rapidamente implantado na maioria das distribuições Linux, possui um mecanismo flexível para configuração de políticas de roteamento/filtragem e não exige muitos recursos computacionais. Além disso, como RS, pode-se optar por um roteador físico/virtual Cisco, Juniper, etc.
- Segurança. Como a rede IXP é uma concentração de um grande número de AS, a política de segurança que todos os participantes devem seguir deve estar bem definida. Como regra geral, todos os mesmos mecanismos aplicados ao estabelecer vizinhança BGP entre dois pares BGP separados fora do IXP também se aplicam aqui, além de alguns meios adicionais de proteção.
Por exemplo, uma boa prática é permitir o tráfego apenas de um determinado endereço MAC de um participante do IXP, que deve ser acordado previamente. É proibido o tráfego com campos de ethertype diferentes de 0x0800 (IPv4), 0x08dd (IPv6), 0x0806 (ARP); isso é feito para filtrar o tráfego que não tem espaço durante o peering BGP. Outros mecanismos, como GTSM, RPKI, etc., também podem ser aplicados.
Certamente, os itens mencionados acima são os principais componentes de qualquer IXP, independentemente de sua escala. Claro, IXPs maiores podem utilizar tecnologias e soluções adicionais.
Às vezes, o IXP também fornece serviços adicionais aos seus participantes:
- hospedagem de servidores DNS TLD no IXP,
- instalação de servidores NTP de hardware, permitindo que os participantes sincronizem o tempo com precisão,
- oferecendo proteção contra ataques DDoS, etc.
Princípio de funcionamento
Vamos analisar o funcionamento de um ponto de troca de tráfego usando um exemplo de um IXP simples, modelado com o EVE-NG, e em seguida veremos a configuração básica de um roteador de software, BIRD. Para simplificar o esquema, vamos omitir aspectos importantes, como redundância e resistência a falhas.
A topologia da rede é apresentada na figura abaixo.
Suponhamos que estamos administrando um pequeno ponto de troca de tráfego e oferecemos as seguintes opções de peering:
- peering público,
- peering privado,
- peering através de um route server.
O número do nosso AS é 555, possuímos um bloco de endereços IPv4 - 50.50.50.0/24, do qual distribuímos endereços IP para aqueles que desejam se conectar à nossa rede.
50.50.50.254 é o endereço IP configurado na interface do route server; com este IP, os clientes estabelecerão a sessão BGP em caso de peering através do RS.
Para o peering através do RS, desenvolvemos uma política de roteamento simples baseada em BGP community, que permite que os participantes do IXP regulem para quem e quais rotas enviar:
BGP community
Descrição
LOCAL_AS:PEER_AS
Transmitir prefixos apenas para PEER_AS
LOCAL_AS:IXP_AS
Transmitir prefixos para todos os participantes do IXP
Três clientes desejam se conectar ao nosso IXP e trocar tráfego; suponhamos que sejam provedores de internet. Todos eles desejam organizar o peering através do route server. Abaixo estão apresentados um diagrama com os parâmetros de conexão dos clientes:
Cliente
Número AS do cliente
Prefixos anunciados pelo cliente
endereço IP atribuído ao cliente para conexão ao IXP
ISP #1
AS 100
1.1.0.0/16
50.50.50.10/24
ISP #2
AS 200
2.2.0.0/16
50.50.50.20/24
ISP #3
AS 300
3.3.0.0/16
50.50.50.30/24
Configuração básica do BGP no roteador do cliente:
router bgp 100
no bgp enforce-first-as
bgp log-neighbor-changes
neighbor 50.50.50.254 remote-as 555
address-family ipv4
network 1.1.0.0 mask 255.255.0.0
neighbor 50.50.50.254 activate
neighbor 50.50.50.254 send-community both
neighbor 50.50.50.254 soft-reconfiguration inbound
neighbor 50.50.50.254 route-map ixp-out out
exit-address-family
ip prefix-list as100-prefixes seq 5 permit 1.1.0.0/16
route-map bgp-out permit 10
match ip address prefix-list as100-prefixes
set community 555:555
É importante observar a configuração no bgp enforce-first-as. Por padrão, o BGP requer que o número AS do peer BGP que recebeu a atualização BGP esteja presente no AS-path. No entanto, como o roteador de controle de rota não altera o AS-path, seu número não estará no AS-path e a atualização será descartada. Essa configuração é aplicada para que o roteador comece a ignorar essa regra.
Além disso, vemos que o cliente definiu a comunidade BGP 555:555 para esse prefixo, o que, de acordo com nossa política, significa que o cliente deseja anunciar esse prefixo a todos os outros participantes.
Para os roteadores dos demais clientes, a configuração será similar, com exceção de seus parâmetros únicos.
Exemplo de configuração do BIRD:
define ixp_as = 555;
define ixp_prefixes = [ 50.50.50.0/24+ ];
template bgp RS_CLIENT {
local as ixp_as;
rs client;
}
A seguir, descrevemos o filtro que não aceita prefixos martianos, assim como os prefixos do próprio IXP:
function catch_martians_and_ixp()
prefix set martians;
prefix set ixp_prefixes;
{
martians = [
0.0.0.0/8+,
10.0.0.0/8+,
100.64.0.0/10+,
127.0.0.0/8+,
169.254.0.0/16+,
172.16.0.0/12+,
192.0.0.0/24+,
192.0.2.0/24+,
192.168.0.0/16+,
198.18.0.0/15+,
198.51.100.0/24+,
203.0.113.0/24+,
224.0.0.0/4+,
240.0.0.0/4+ ];
if net ~ martians || net ~ ixp_prefixes then return false;
return true;
}
Essa função implementa a política de roteamento que descrevemos anteriormente.
function bgp_ixp_policy(int peer_as)
{
if (ixp_as, ixp_as) ~ bgp_community then return true;
if (ixp_as, peer_as) ~ bgp_community then return true;
return false;
}
filter reject_martians_and_ixp
{
if catch_martians_and_ixp() then reject;
if ( net ~ [0.0.0.0/0{25,32} ] ) then {
reject;
}
accept;
}
Configuramos o peering, aplicamos os filtros e políticas apropriados.
protocol as_100 from RS_CLIENT {
neighbor 50.50.50.10 as 100;
ipv4 {
export where bgp_ixp_policy(100);
import filter reject_martians_and_ixp;
}
}
protocol as_200 from RS_CLIENT {
neighbor 50.50.50.20 as 200;
ipv4 {
export where bgp_ixp_policy(200);
import filter reject_martians_and_ixp;
}
}
protocol as_300 from RS_CLIENT {
neighbor 50.50.50.30 as 300;
ipv4 {
export where bgp_ixp_policy(300);
import filter reject_martians_and_ixp;
}
}
É importante observar que, em um roteador de controle de rota, é uma boa prática agrupar rotas de diferentes peers em RIBs distintas. O BIRD permite isso. No nosso exemplo, por simplicidade, todas as atualizações recebidas de todos os clientes são agrupadas em uma única RIB.
Então, vamos verificar o que conseguimos.
No servidor de rota, vemos que foi estabelecida uma sessão BGP com todos os três clientes:
Observamos que recebemos os prefixos de todos os clientes:
No roteador as 100, vemos que com apenas uma sessão BGP com o servidor de rotas, recebemos os prefixos tanto de as 200 quanto de as 300, sem que os atributos BGP tenham mudado, como se o peering entre os clientes fosse feito diretamente:
Assim, podemos ver que a presença de um servidor de rotas simplifica significativamente a organização do peering no IXP.
Espero que esta demonstração tenha ajudado você a entender melhor como funcionam os pontos de troca de tráfego e como o servidor de rotas opera no IXP.
Linxdatacenter IX
No Linxdatacenter, construímos nosso próprio IXP com uma infraestrutura resiliente composta por 2 switches e 2 servidores de rota. Atualmente, nosso IXP está em modo de teste, e convidamos todos os interessados a se conectar ao Linxdatacenter IX e participar dos testes. Ao se conectar, você terá um porta com uma capacidade de 1 Gbit/s, a possibilidade de peering através dos nossos servidores de rota e acesso ao painel do portal IX, acessível em .
Entre em contato nos comentários ou mensagens diretas para obter acesso ao teste.
Saída
Os pontos de troca de tráfego surgiram no início da internet como uma ferramenta para resolver o problema do tráfego não otimizado entre operadores de telecomunicações. Hoje, com o surgimento de novos serviços globais e o aumento do tráfego de CDN, os pontos de troca continuam a otimizar o funcionamento da rede global. O aumento do número de IXP no mundo beneficia tanto o usuário final do serviço quanto os operadores de telecomunicações, operadores de conteúdo, etc. Para os participantes do IXP, a vantagem se manifesta na redução de custos para a organização de peerings externos, na diminuição do tráfego pelo qual é necessário pagar aos operadores superiores, na otimização da roteação e na possibilidade de ter uma conexão direta com os operadores de conteúdo.
Links Úteis
- Veja o mapa de localização dos pontos de troca de tráfego:
- Veja estatísticas detalhadas sobre peering BGP, incluindo presença no IXP:
Fonte: habr.com
