“Estabelecemos uma conexão telefônica entre nós e o pessoal do SRI...”, disse Kleinrock... em entrevista:
“Digitamos o L e perguntamos ao 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."
“Aí digitamos G e o sistema travou”...No entanto, uma revolução havia começado...
O começo da internet.
Olá a todos!
Meu nome é Alexander, sou engenheiro de rede na Linxdatacenter. No artigo de hoje falaremos sobre pontos de troca de tráfego (Internet Exchange Points, IXP): o que precedeu seu surgimento, quais tarefas resolvem e como são construídos. Também neste artigo irei demonstrar o princípio de funcionamento do IXP utilizando a plataforma EVE-NG e o roteador do software BIRD, para que você tenha uma compreensão de como ele funciona “nos bastidores”.
Um pouco de história
Se você olhar , então você pode ver que o rápido crescimento no número de pontos de troca de tráfego começou em 1993. Isto se deve ao fato de que a maior parte do tráfego das operadoras de telecomunicações que existiam naquela época passava pela rede backbone dos EUA. Assim, por exemplo, quando o tráfego passou de um operador em França para um operador na Alemanha, primeiro foi de França para os EUA e só depois dos EUA para a Alemanha. A rede backbone, neste caso, funcionou como um trânsito entre a França e a Alemanha. Mesmo o tráfego dentro de um país muitas vezes não passava diretamente, mas através das redes de base das operadoras americanas.
Esta situação afectou não só o custo de entrega do tráfego de trânsito, mas também a qualidade dos canais e os atrasos. O número de utilizadores da Internet aumentou, surgiram novos operadores, o volume de tráfego aumentou e a Internet amadureceu. Operadores de todo o mundo começaram a perceber que era necessária uma abordagem mais racional para organizar a interação entre operadores. “Por que eu, operador A, deveria pagar pelo trânsito por outro país para entregar o tráfego ao operador B, que está localizado na rua ao lado?” Esta é aproximadamente a pergunta que as operadoras de telecomunicações se perguntaram naquela época. Assim, pontos de troca de tráfego começaram a aparecer em diferentes partes do mundo nos pontos de concentração das operadoras:
- 1994 – LINX em Londres,
- 1995 – DE-CIX em Frankfurt,
- 1995 – MSK-IX, em Moscou, etc.
Internet e nossos dias
Conceitualmente, a arquitetura da Internet moderna consiste em muitos sistemas autônomos (AS) e muitas conexões entre eles, tanto físicas quanto lógicas, que determinam o caminho do tráfego de um AS para outro.
ASs geralmente são operadoras de telecomunicações, provedores de Internet, CDNs, data centers e empresas do segmento empresarial. Os ASes organizam conexões lógicas (peering) entre si, geralmente utilizando o protocolo BGP.
A forma como os sistemas autônomos organizam essas conexões é determinada por vários fatores:
- geográfico,
- econômico,
- político,
- acordos e interesses comuns entre proprietários de AS,
- и т.д.
Claro, este esquema tem uma certa estrutura e hierarquia. Assim, as operadoras são divididas em nível 1, nível 2 e nível 3, e se os clientes de um provedor de Internet local (nível 3) são, via de regra, usuários comuns, então, por exemplo, para nível 1 operadores de nível os clientes são outros operadores. As operadoras de nível 3 agregam o tráfego de seus assinantes, as operadoras de telecomunicações de nível 2, por sua vez, agregam o tráfego das operadoras de nível 3 e as de nível 1 – todo o tráfego da Internet.
Esquematicamente pode ser representado assim:
Esta imagem mostra que o tráfego é agregado de baixo para cima, ou seja, desde usuários finais até operadores de nível 1. Há também uma troca horizontal de tráfego entre ASs que são aproximadamente equivalentes entre si.
Parte integrante e ao mesmo tempo uma desvantagem deste esquema é uma certa confusão de ligações entre sistemas autónomos localizados mais perto do utilizador final, dentro de uma área geográfica. Considere a imagem abaixo:
Suponhamos que numa grande cidade existam 5 operadoras de telecomunicações, cujo peering, por um motivo ou outro, é organizado conforme mostrado acima.
Caso o usuário Petya, conectado ao ISP Go, queira acessar um servidor conectado ao provedor ASM, então o tráfego entre eles será forçado a passar por 5 sistemas autônomos. Isso aumenta o atraso porque aumenta o número de dispositivos de rede pelos quais o tráfego passará, bem como o volume de tráfego de trânsito em sistemas autônomos entre Go e ASM.
Como reduzir o número de ASs de trânsito pelos quais o tráfego é forçado a passar? Isso mesmo - ponto de troca de tráfego.
Hoje, o surgimento de novos IXPs é impulsionado pelas mesmas necessidades do início dos anos 90-2000, só que em menor escala, em resposta ao crescente número de operadores de telecomunicações, utilizadores e tráfego, à crescente quantidade de conteúdos gerados pelas redes CDN e centros de dados.
O que é um ponto de troca?
Um ponto de troca de tráfego é um local com uma infraestrutura de rede especial onde os participantes interessados na troca mútua de tráfego organizam peering mútuo. Os principais participantes dos 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 se conectam diretamente entre si. Isso permite que você resolva os seguintes problemas:
- reduzir a latência,
- reduzir a quantidade de tráfego de trânsito,
- otimizar o roteamento entre AS.
Considerando que os IXPs estão presentes em muitas grandes cidades ao redor do mundo, tudo isso tem um efeito benéfico na Internet como um todo.
Se a situação acima com Petya for resolvida usando IXP, será algo assim:
Como funciona um ponto de troca de tráfego?
Como regra, um IXP é um AS separado com seu próprio bloco de endereços IPv4/IPv6 públicos.
A rede IXP geralmente consiste em um domínio L2 contínuo. Às vezes, trata-se simplesmente de 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 um domínio L2.
Elementos IXP
- SKS. Não há nada de incomum aqui: racks, conexões cruzadas ópticas, painéis de conexão.
- Comuta – a base do IXP. A porta do switch é o ponto de entrada na rede IXP. Os switches também desempenham parte das funções de segurança - eles filtram o tráfego indesejado que não deveria estar presente na rede IXP. Como regra, os switches são selecionados com base nos requisitos funcionais - confiabilidade, velocidades de porta suportadas, recursos de segurança, suporte sFlow, etc.
- Servidor de rota (RS) – uma parte integrante e necessária de qualquer ponto de troca de tráfego moderno. O princípio de operação é muito semelhante ao refletor de rota no iBGP ou ao roteador designado no OSPF e resolve os mesmos problemas. À medida que o número de participantes em um ponto de troca de tráfego cresce, aumenta o número de sessões BGP que cada participante precisa para suportar, ou seja, isso é uma reminiscência da topologia clássica de malha completa no iBGP. O RS resolve o problema da seguinte forma: estabelece uma sessão BGP com cada participante IXP interessado, e esse participante se torna um cliente RS. Ao receber uma atualização BGP de um de seus clientes, o RS envia essa atualização para todos os seus outros clientes, é claro, com exceção daquele de quem esta atualização foi recebida. Assim, o RS elimina a necessidade de estabelecer uma malha completa entre todos os membros do IXP e resolve com elegância o problema de escalabilidade. Vale ressaltar que o servidor de rotas transmite rotas de forma transparente de um AS para outro sem fazer alterações nos atributos transmitidos pelo BGP, por exemplo, ele não adiciona o número do seu AS ao AS-path. Também no RS há filtragem básica de rotas: por exemplo, o RS não aceita redes marcianas e os prefixos do próprio IXP.
Um roteador de software de código aberto, BIRD (bird internet routing daemon), é frequentemente usado como uma solução de servidor de rota. O bom disso é que ele é gratuito, é implementado rapidamente na maioria das distribuições Linux, possui um mecanismo flexível para configurar políticas de roteamento/filtragem e não exige recursos computacionais. Além disso, um roteador hardware/virtual da Cisco, Juniper, etc. pode ser selecionado como RS.
- Segurança. Como uma rede IXP concentra um grande número de ASes, a política de segurança que todos os participantes devem seguir deve ser bem escrita. Em geral, todos os mesmos mecanismos que se aplicam ao estabelecer uma adjacência de BGP entre dois pares BGP separados fora de um IXP se aplicam aqui, além de alguns recursos de segurança adicionais.
Por exemplo, é uma boa prática permitir o tráfego apenas de um endereço MAC específico do participante IXP, que é 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 pertence ao peering BGP. Mecanismos como GTSM, RPKI, etc. também podem ser utilizados.
Talvez os itens acima sejam os principais componentes de qualquer IXP, independentemente da escala. É claro que IXPs maiores podem ter tecnologias e soluções adicionais implementadas.
Acontece que o IXP também oferece aos seus participantes serviços adicionais:
- colocado no servidor DNS IXP TLD,
- instalar servidores NTP de hardware, permitindo que os participantes sincronizem o horário com precisão,
- fornecer proteção contra ataques DDoS, etc.
Como funciona
Vejamos o princípio de funcionamento de um ponto de troca de tráfego usando o exemplo de um IXP simples, modelado usando EVE-NG, e a seguir consideraremos a configuração básica de um roteador de software BIRD. Para simplificar o diagrama, omitiremos coisas importantes como redundância e tolerância a falhas.
A topologia da rede é mostrada na figura abaixo.
Vamos supor que administramos um pequeno ponto de troca e fornecemos as seguintes opções de peering:
- 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, a partir do qual emitimos endereços IP para quem deseja se conectar à nossa rede.
50.50.50.254 – Endereço IP configurado na interface do servidor de rotas, com este IP os clientes estabelecerão uma sessão BGP em caso de peering via RS.
Além disso, para peering via RS, desenvolvemos uma política de roteamento simples baseada na comunidade BGP, que permite aos participantes do IXP regular para quem e quais rotas enviar:
Comunidade BGP
descrição
LOCAL_AS:PEER_AS
Envie prefixos apenas para PEER_AS
LOCAL_AS:IXP_AS
Transferir prefixos para todos os participantes IXP
3 clientes desejam se conectar ao nosso IXP e trocar tráfego; Digamos que sejam provedores de Internet. Todos querem organizar o peering através de um servidor de rota. Abaixo está um diagrama com os parâmetros de conexão do cliente:
Cliente
Número AS do cliente
Prefixos anunciados pelo cliente
Endereço IP emitido para o cliente se conectar ao IXP
ISP nº 1
AS 100
1.1.0.0/16
50.50.50.10/24
ISP nº 2
AS 200
2.2.0.0/16
50.50.50.20/24
ISP nº 3
AS 300
3.3.0.0/16
50.50.50.30/24
Configuração básica do BGP no 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
Vale a pena observar a configuração no bgp aplicar primeiro como aqui. Por padrão, o BGP exige que o as-path de uma atualização BGP recebida contenha o número as bgp do peer do qual a atualização foi recebida. Mas como o servidor de rota não faz alterações no as-path, seu número não estará no as-path e a atualização será descartada. Esta configuração é usada para fazer o roteador ignorar esta regra.
Vemos também que o cliente configurou a comunidade BGP 555:555 para esse prefixo, o que, de acordo com nossa política, significa que o cliente deseja anunciar esse prefixo para todos os outros participantes.
Para roteadores de outros clientes, as configurações serão semelhantes, com exceção dos 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-se um filtro que não aceita prefixos marcianos, bem 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;
}
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;
}
Configuramos peering, aplicamos filtros e políticas apropriadas.
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 a pena notar que em um servidor de rotas é uma boa prática colocar rotas de diferentes pares em diferentes RIBs. O BIRD permite que você faça isso. No nosso exemplo, para simplificar, todas as atualizações recebidas de todos os clientes são adicionadas em um RIB comum.
Então, vamos verificar o que temos.
No servidor de rota vemos que uma sessão BGP foi estabelecida com todos os três clientes:
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, recebemos prefixos tanto de 200 quanto de 300, enquanto os atributos do BGP não foram alterados, como se o peering entre clientes fosse realizado diretamente:
Assim, vemos que a presença de um servidor de rota simplifica muito a organização do peering no IXP.
Espero que esta demonstração tenha ajudado você a entender melhor como funcionam os IXPs e como funciona o servidor de rotas em um IXP.
Linxdatacenter IX
Na Linxdatacenter, construímos nosso próprio IXP baseado em uma infraestrutura tolerante a falhas de 2 switches e 2 servidores de rotas. Nosso IXP agora está rodando em modo de teste e convidamos todos a se conectarem ao Linxdatacenter IX e participarem dos testes. Quando conectado, você terá uma porta com largura de banda de 1 Gbit/s, a possibilidade de peering através de nossos servidores de rotas, bem como acesso à sua conta pessoal do portal IX, disponível em .
Escreva em comentários ou mensagens privadas para ter acesso aos testes.
Jogar aviator online grátis: hack aviator funciona
Os pontos de troca de tráfego surgiram nos primórdios da Internet como uma ferramenta para resolver o problema do fluxo de tráfego abaixo do ideal entre operadoras de telecomunicações. Agora, com o advento de novos serviços globais e o aumento da quantidade de tráfego CDN, os pontos de troca continuam a otimizar o funcionamento da rede global. O aumento do número de IXPs no mundo beneficia tanto o usuário final do serviço quanto as operadoras de telecomunicações, operadoras de conteúdo, etc. Para os participantes do IXP, o benefício é expresso na redução dos custos de organização de peering externo, na redução da quantidade de tráfego que os operadores de nível superior têm de pagar, na otimização do roteamento e na capacidade de ter uma interface direta com os operadores de conteúdo.
Links úteis
- Veja um mapa da localização dos pontos de troca de tráfego:
- Veja estatísticas detalhadas sobre peering BGP, incluindo presença em IXP:
Fonte: habr.com