"Estabelecemos uma conexão telefônica entre nós e os caras da SRI ...", Kleinrock ... disse em uma entrevista:
"Digitamos o L e perguntamos ao telefone:" Você vê o L? ""
"Sim, nós vemos o L", veio a resposta.
"Digitamos o O e perguntamos:" Você vê o O. ""
"Sim, nós vemos o O."
"Então digitamos o G, e o sistema travou" ...
No entanto, uma revolução havia começado ...
O começo da internet.
Olá pessoal!
Meu nome é Alexander, sou engenheiro de rede no Linxdatacenter. No artigo de hoje, falaremos sobre pontos de troca de tráfego (Internet Exchange Point, IXP): o que precedeu sua aparência, quais tarefas eles resolvem e como são construídos. Também neste artigo, demonstrarei como o IXP funciona usando a plataforma EVE-NG e o roteador BIRD, para que você possa entender como ele funciona "sob o capô".
Um pouco de história
Se você olhar
aqui , pode ver que o rápido crescimento no número de pontos de troca de tráfego começou em 1993. Isso se deve ao fato de que a maior parte do tráfego das operadoras de telecomunicações existentes naquele momento passava pela rede de backbone dos EUA. Assim, por exemplo, quando o tráfego passou do operador na França para o operador na Alemanha, ele veio primeiro da França para os EUA e somente depois dos EUA para a Alemanha. A rede de backbone, nesse caso, atuou como um trânsito entre a França e a Alemanha. Até o tráfego dentro de um país costumava passar não diretamente, mas através das redes principais das operadoras americanas.
Esse estado de coisas afetou não apenas o custo da entrega do tráfego de trânsito, mas também a qualidade dos canais e o atraso. O número de usuários da Internet aumentou, surgiram novas operadoras, o volume de tráfego aumentou, a Internet cresceu. Operadores em todo o mundo começaram a perceber que era necessária uma abordagem mais racional para a organização da interação entre operadores. "Por que eu devo, operadora A, pagar pelo trânsito em outro país para entregar tráfego à operadora B, localizada em uma rua vizinha?" Algo assim foi solicitado pelas operadoras de telecomunicações na época. Assim, em diferentes partes do mundo, os pontos de troca de tráfego começaram a aparecer nos pontos de concentração do operador:
- 1994 - LINX em Londres,
- 1995 - DE-CIX em Frankfurt,
- 1995 - MSK-IX, em Moscou, etc.
Internet e hoje
Conceitualmente, a arquitetura da Internet moderna é um conjunto de sistemas autônomos (sistemas autônomos, AS) e muitas conexões entre eles, tanto físicos quanto lógicos, que determinam o caminho do tráfego de um AS para outro.
AS são geralmente operadoras de telecomunicações, provedores de Internet, CDNs, data centers, empresas do segmento corporativo. Os ASs organizam o peering entre si, como regra, usando o protocolo BGP.
Como os sistemas autônomos organizam esses relacionamentos é determinado por vários fatores:
- geográfico
- econômico
- político
- acordos e interesses comuns entre os proprietários de SA,
- etc.
Obviamente, nesse esquema há uma certa estrutura e hierarquia. Portanto, os operadores são divididos em camada 1, camada 2 e camada 3 e, se os clientes do provedor de Internet local (camada 3) forem geralmente usuários comuns, então, por exemplo, para operadoras de camada 1 outros operadores. As operadoras de camada 3 agregam o tráfego de seus assinantes, as operadoras de telecomunicações de camada 2, por sua vez, agregam o tráfego das operadoras de camada 3 e a camada 1 - todo o tráfego da Internet.
Esquematicamente, isso pode ser representado da seguinte maneira:
Nesta imagem, você pode ver que o tráfego é agregado de baixo para cima, ou seja, de usuários finais a operadores de nível 1. Há também uma troca de tráfego horizontal entre os ASs aproximadamente equivalentes entre si.Parte integrante e ao mesmo tempo uma desvantagem desse esquema é uma certa confusão de conexões entre sistemas autônomos localizados mais próximos do usuário final, dentro da zona geográfica. Considere a imagem abaixo:
Suponha que em uma cidade grande existam 5 operadores de comunicação, entre os quais, por um motivo ou outro, esteja organizado conforme mostrado acima.
Se o usuário Petya, conectado ao provedor de Internet Go, quiser obter acesso ao servidor conectado ao provedor ASM, o tráfego entre eles será forçado a passar por 5 sistemas autônomos. Isso aumenta o atraso, porque aumentando o número de dispositivos de rede pelos quais o tráfego passará, bem como a quantidade de tráfego de trânsito em sistemas autônomos entre Go e ASM.
Como reduzir o número de ASs de trânsito que são forçados a passar tráfego? É isso mesmo - um ponto de troca de tráfego.
Atualmente, o surgimento de novos IXPs deve-se às mesmas necessidades do início dos anos 90- 2000, apenas em menor escala, em resposta ao crescente número de operadoras, usuários e tráfego de telecomunicações, à crescente quantidade de conteúdo gerado pelas 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 em que os participantes interessados na troca de tráfego mútuo organizam pares. Os principais participantes nos pontos de troca de tráfego: operadoras de telecomunicações, provedores de Internet, provedores de conteúdo e data centers. Nos pontos de troca de tráfego, os participantes são conectados diretamente entre si. Isso permite que você resolva os seguintes problemas:
- reduzir atraso
- reduzir a quantidade de tráfego de trânsito,
- Otimize o roteamento entre ASs.
Considerando que os IXPs estão presentes em muitas grandes cidades do mundo, tudo isso afeta favoravelmente a Internet como um todo.
Se a situação descrita acima com Petya for resolvida com a ajuda do IXP, ocorrerá algo como isto:
Como é organizado o ponto de troca de tráfego?
Como regra, o IXP é um AS separado com seu próprio bloco de endereços IPv4 / IPv6 públicos.
A rede IXP geralmente é um domínio L2 contínuo. Às vezes, é apenas uma VLAN que hospeda todos os clientes IXP. Quando se trata de IXPs maiores e distribuídos geograficamente, tecnologias como MPLS, VXLAN etc. podem ser usadas para organizar o domínio L2.
Elementos IXP
- SCS. Não há nada incomum aqui: racks, países ópticos, painéis de remendo.
- Os switches são a base do IXP. A porta do switch é o ponto de entrada da rede IXP. Os comutadores também executam parte das funções de segurança - filtram o tráfego indesejado que não deve estar presente na rede IXP. Como regra, os switches são selecionados com base nos requisitos funcionais - confiabilidade, velocidade da porta suportada, recursos de segurança, suporte ao sFlow, etc.
- O servidor de rota (RS) é parte integrante e necessária de qualquer ponto de troca de tráfego moderno. Funciona como um refletor de rota no iBGP ou um roteador designado no OSPF e resolve os mesmos problemas. À medida que o número de participantes em um ponto de troca de tráfego aumenta, o número de sessões BGP aumenta, que cada participante precisa oferecer suporte, ou seja, assemelha-se à topologia de malha completa clássica no iBGP. O RS resolve o problema da seguinte maneira: estabelece uma sessão BGP com cada participante IXP interessado e ele se torna um cliente do RS. Aceitando uma atualização do BGP de um de seus clientes, o RS envia essa atualização para todos os outros clientes, é claro, exceto aquele de onde essa atualização foi recebida. Assim, o RS elimina a necessidade de instalar a malha completa entre todos os participantes do IXP e resolve com elegância o problema de escalabilidade. Vale ressaltar que o servidor de rota transfere transparentemente as rotas de um AS para outro, sem fazer alterações nos atributos BGP transmitidos, por exemplo, não adiciona um número no AS ao caminho do AS. Além disso, a filtragem básica de rotas ocorre no RS: por exemplo, o RS não aceita redes marcianas e prefixos IXP.
Um roteador de software de código aberto, o BIRD (daemon de roteamento de Internet para aves), é frequentemente usado como uma solução de servidor de rota. É bom porque é gratuito, implementado rapidamente na maioria das distribuições Linux, possui um mecanismo flexível para definir políticas de roteamento / filtragem e não exige recursos de computação. Além disso, o hardware / roteador virtual da Cisco, Juniper etc. pode ser selecionado como RS. - Segurança Como a rede IXP é uma concentração de um grande número de ASs, a política de segurança que todos os participantes devem seguir deve ser bem definida. Como regra, todos os mesmos mecanismos usados para estabelecer uma vizinhança de BGP entre dois pares de BGP separados fora do IXP são aplicados aqui, bem como alguns recursos de segurança adicionais.
Por exemplo, é uma boa prática permitir apenas o tráfego de um endereço MAC IXP específico, negociado antecipadamente. Negar tráfego com campos ethertype diferentes de 0x0800 (IPv4), 0x08dd (IPv6), 0x0806 (ARP); isso é feito para filtrar o tráfego que não tem espaço para o peering do BGP. Mecanismos como GTSM, RPKI, etc. também podem ser usados.
Talvez os itens acima sejam os principais componentes de qualquer IXP, independentemente da escala. Obviamente, grandes IXPs podem usar tecnologias e soluções adicionais.
Acontece que o IXP também fornece a seus membros serviços adicionais:
- hospedado no servidor DNS do IXP TLD,
- Instale servidores NTP de hardware, permitindo que os participantes sincronizem com precisão o tempo,
- fornecer proteção contra ataques DDoS, etc.
Princípio de funcionamento
Analisaremos o princípio de operação de um ponto de troca de tráfego usando o IXP mais simples simulado pelo EVE-NG como exemplo e, em seguida, consideraremos a configuração básica do roteador BIRD. Para simplificar o esquema, omitimos coisas importantes como redundância e tolerância a falhas.
A topologia de rede é mostrada na figura abaixo.
Suponha que administremos um pequeno ponto de troca de tráfego e forneça as seguintes opções de emparelhamento:
- peering público
- peering privado
- peering via servidor de rota.
Nosso número AS é 555, possuímos um bloco de endereços IPv4 - 50.50.50.0/24, do qual emitimos endereços IP, para aqueles que desejam se conectar à nossa rede.
50.50.50.254 - O endereço IP configurado na interface do servidor de rota, com este cliente IP, estabelecerá uma sessão BGP em caso de emparelhamento via RS.
Também para o peering pelo RS, desenvolvemos a política de roteamento mais simples baseada na comunidade BGP, que permite aos participantes do IXP regular a quem e quais rotas enviar:
3 clientes desejam conectar e trocar tráfego com nosso IXP; digamos que esses sejam provedores de internet. Todos eles querem organizar o peering através do servidor de rotas. Abaixo está um diagrama com parâmetros de conexão do cliente:
Configuração básica do BGP em um roteador 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
A configuração aqui não é bgp enforce-first-as. Por padrão, o BGP exige que o número como bgp do par do qual esta atualização foi recebida esteja presente no caminho como da atualização BGP recebida. Mas como o servidor de rota não faz alterações no caminho, seu número estará ausente no caminho e a atualização será descartada. Essa configuração é usada para fazer com que o roteador ignore esta regra.
Também vemos que o cliente instalou a comunidade bgp 555: 555 nesse prefixo, o que, de acordo com nossa política, significa que o cliente deseja anunciar esse prefixo para todos os outros participantes.
Para os roteadores de outros clientes, a configuração será semelhante, exceto por seus parâmetros exclusivos.
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, descreve um filtro que não aceita prefixos marcianos, bem como 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; }
Esta 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; }
Estabelecemos pares, aplicamos 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; } }
Vale ressaltar que, no servidor de rota, é uma boa forma adicionar rotas de diferentes pares para diferentes RIBs. O PÁSSARO permite que você faça isso. Em nosso exemplo, por simplicidade, todas as atualizações recebidas de todos os clientes são adicionadas a um RIB comum.
Então, vamos verificar o que temos.
No servidor de rota, vemos que, com todos os três clientes, uma sessão BGP está instalada:
Vemos que recebemos prefixos de todos os clientes:
No roteador as 100, vemos que, se houver apenas uma sessão BGP com o servidor de rota, obteremos prefixos de 200 e 300, enquanto os atributos do BGP não foram alterados, como se o peering entre os clientes fosse realizado diretamente:
Assim, vemos que a presença de um servidor de rota simplifica muito a organização de emparelhamento no IXP.
Espero que esta demonstração tenha ajudado a entender melhor como os pontos de troca de tráfego são organizados e como o servidor de rota no IXP é implementado.
Linxdatacenter ix
No Linxdatacenter, construímos nosso próprio IXP com base em uma infraestrutura tolerante a falhas de 2 comutadores e 2 servidores de rota. Agora nosso IXP foi lançado no modo de teste e convidamos todos a se conectarem ao Linxdatacenter IX e participarem dos testes. Ao conectar, você receberá uma porta com uma largura de banda de 1 Gbit / s, a possibilidade de espiar através de nossos servidores de rota, bem como o acesso à conta pessoal do portal IX, disponível em
ix.linxdatacenter.com .
Escreva em comentários ou mensagens privadas para obter acesso aos testes.
Conclusão
Os pontos de troca de tráfego surgiram no início da Internet como uma ferramenta para abordar a questão do fluxo de tráfego não ideal entre as operadoras de telecomunicações. Agora, com o advento de novos serviços globais e um aumento no número de tráfego de CDN, os pontos de troca também continuam otimizando a operação da rede global. O aumento no número de IXPs no mundo é benéfico tanto para o usuário final do serviço quanto para operadores de telecomunicações, operadores de conteúdo etc. Para os participantes do IXP, o benefício é expresso em uma redução no custo de organização de serviços ponto a ponto externos, uma redução na quantidade de tráfego que custa operadores mais altos, otimização de roteamento e a capacidade de ter uma interface direta com os operadores de conteúdo.
Links úteis