Arquivo

Archive for the ‘iBGP’ Category

Topologias, Interconexões e Protocolos

Introdução

 

Desde que iniciei com este blogue, no final de 2005, muitos amigos e leitores encaminham-me, sistematicamente, sugestões e críticas, construtivas, de vários tipos. Alguns dizem que os textos estão muito longos e pedem para que os segmente, outros indicam falhas ou conteúdo que geram dúvidas, principalmente de interpretação, por não estarem suficientemente claros. Outros insistem para que os textos sejam transformados em livro. Há uns três anos atrás pensei, seriamente, nesta possibilidade. Portanto, recentemente decidi que isto seria feito. Na realidade, pensei em dois livros. Um com a exposição dos textos do blogue, refinados e organizados em forma e conteúdo adequados, a preservar a tese de conhecimento auxiliar àqueles que precisam de uma referência imediata e simples.

capaLivro-1

Entretanto, durante um ano “quase” sabático que me dei, refleti e imaginei a possibilidade de escrever o segundo livro, no qual a simplicidade do conhecimento e experiências que acumulei ao longo dos muitos anos de trabalho pudessem ser expostos a partir de uma topologia que fosse capaz de exibir a aplicação de problemas de interconexões e de decisões sobre quais protocolos usar, principalmente, orientados aos pequenos e médios provedores.

Desde então, comecei a me preparar para este segundo livro, já que a decisão sobre o primeiro livro estava tomada e em andamento, com a ajuda do Deivison Moraes, o qual participou, remotamente, de diversas experiências necessárias à consolidação do conhecimento envolvido. Para o segundo livro, escolhi uma arquitetura, que a princípio parece complexa (mas, não é), contendo tudo aquilo necessário para que o administrador de um pequeno e médio provedor deve conhecer, para construir uma infraestrutura da Internet melhor. Ao dizer isto estou fazendo apologia à estrutura e missão do IETF, que pode ser adaptada do RFC3935: “É uma comunidade internacional de pessoas interessadas em cumprir a missão de produzir, com alta qualidade e relevância técnica, documentos de engenharia, que influenciam a maneira como as pessoas projetam, usam e gerenciam a Internet, de tal maneira, que ela possa funcionar cada vez melhor.”

capa

O título escolhido, para o segundo livro, “Topologias, Interconexões e Protocolos” insiste no fato de que estas três palavras evidenciam questões inter-relacionadas que exigem decisões corretas e seguras, de implementação. A arquitetura (no sentido de uma topologia ou de diversas topologias) é o planejamento ou projeto, com base nas disponibilidade de recursos e facilidades disponíveis, no cenário em que se insere. As Interconexões exigem ou são exigidas na escolha dos Protocolos. Protocolos dependem de Interconexões e são tratados, pelo livro, em um sentido mais amplo, ao adotar componentes necessários ao funcionamento da Infraestrutura da Internet, local ou não. Observações anotadas e retiradas das listas do IETF (de grupos de trabalhos ou independentes), das listas dos RIRs (Regional Internet Registers), de listas internacionais independentes, das listas brasileiras (GTER, a peculiar, finada prematuramente, GT-AS, entre outras), dos cursos de IPv6 do Nic.br e outros (como o recente curso para ASes), tudo, foi usado para compor a proposta do livro. Adicionalmente, uma extensa referência bibliográfica coletada e lidas por mim, ao longo dos anos (artigos, livros, RFCs e equivalentes) expande a estrutura fundamental, do conhecimento exigido e exposto. O que faltava era ajustar tudo isto de forma simples, atento ao ponto de vista de Alfred North Whitehead: “Seek simplicity, but distrust it”.

Abaixo seguem extratos dos dois primeiros capítulos do livro (Introdução e Topologias), que orienta o sobre como será o conteúdo dos capítulos restantes. Vamos esperar para uma avaliação dos autores.



 

Topologias, Interconexões e Protocolos

 

1. Introdução

 

A Infraestrutura da Internet está, sistematicamente, em movimento. Há poucos anos atrás, a perspectiva da escassez do IPv4 trouxe o IPv6 para resolver o problema. Foi um impacto radical, em particular, sobre a mente dos administradores da Infraestrutura da Internet. Assim, antes da chegada do IPv6 e durante muitos anos, a Internet era representada nos textos, de forma abstrata, como se fosse um nuvem, em variações diversas, semelhante à Figura 1.1.

 

InternetAntiga
Figura 1.1. Representação abstrata da Internet.

 

Com a chegada do IPv6, até podemos representar a Internet como a Figura 1.1, desde que fique claro que a Internet, na realidade é composta de dois ambientes bem definidos: o ambiente IPv4 e o ambiente IPv6. Uma possível representação desta nova abstração é a Figura 1.2.

 

InternetNova
Figura 1.2. Nova representação abstrata da Internet.

 

Neste livro, por razões didáticas iremos preferir uma representação mais apropriada para escapar das imagens confusas, ao associarmos topologias, interconexões e protocolos. A Figura 1.3 exibe a nossa proposta, onde o fundo branco servirá para desenhar os modelos propostos.

 

Topologia-01
Figura 1.3. A representação abstrata da Internet, para efeitos deste livro.

 

Se a Internet está envolvida, qualquer roteador colocado na área branca da Figura 1.3, que esteja conectado a outro roteador de um Sistema Autônomo (AS) tornará, imediatamente, membro da Internet, juntamente com toda a sua rede interna de usuários e/ou computadores. Portanto, o espaço em branco é outra abstração, que estamos usando, para facilitar a exploração didática dos conceitos abordados.

O livro está estruturado em quatro capítulos básicos: Introdução, Topologias, Interconexões e Protocolos. Completam o livro, um considerável glossário, seguido de uma Referência Bibliográfica bastante completa e de índices (analítico, remissivo e figuras), além de Anexos abordando equipamentos, roteadores, ferramentas e servidores essenciais à Infraestrutura da Internet. Os anexos sobre outros roteadores que não aqueles usados no capítulo de Protocolos, adicionam alternativas de usá-los, por alguma razão específica do leitor.

 

2. Topologias

 

2.1 Tráfego, trânsito e transporte

 

Topologia é o recurso inicial, que um administrador da Infraestrutura da Internet tem disponível, para planejar e desenvolver o projeto de uma ou mais interconexão e os respectivos protocolos necessários. Geralmente, usamos um processo de modelagem (ou desenho) de uma topologia, usando a técnica de refinamentos sucessivos para chegarmos ao modelo final esperado, ou melhor, o modelo ótimo. Por outro lado, a apresentação das diversas topologias neste texto, nos dá a impressão de que foi imediato, o desenvolvimento do projeto. Não foi! Levou-se um bom tempo para chegar à etapa descrita, inicialmente, neste capítulo e, outras mudanças virão na sequência. Na prática percebe-se de que a oportunidade de usar a técnica de refinamentos sucessivos é fundamental e fortemente recomendada, pois ela permite o entendimento completo do problema, etapa por etapa. Em cada refinamento, ou cada etapa, a utilização de ferramentas de simulação representaram uma decisão de projeto extremamente eficaz, mas reconhecidamente trabalhosa. Várias outras ferramentas foram utilizadas, sobre as quais comentamos nos Anexos.

 

2.2 Topologia da Localidade 1

 

O exemplo escolhido para ilustrar as questões que encontramos em nosso dia a dia, envolvendo topologia, interconexões e protocolos foi o de uma empresa, que possui filiais em seis localidades remotas e principais, além de quatro outras localidades “secundárias”, mas também remotas. O objetivo da empresa é atender suas demandas de tráfego de dados dentro de cada localidade e entre todas as localidades. Como qualquer empresa, custo é um componente importante e a máxima é minimizá-lo.

A Localidade 1 possui uma característica importante: nela estão os recursos necessários para administrar toda a infraestrutura de tráfego de dados. Por recursos entende-se pessoal, equipamentos, software, ferramentas e tudo mais necessário para atender a este objetivo. A Figura 2.1 exibe a topologia da Localidade 1, a qual passamos a descrever.

 

Topologia-02
Figura 2.1. Topologia da Localidade 1.

 

Na topologia da Figura 2.1, vemos a rede interna (azul claro) e o seu roteador de borda identificado pelo número 1. Este roteador tem três conexões. A conexão em verde, com o roteador T11 é a oferta de tráfego de dados para a Internet. Dizemos, então, que T11 pertence a um provedor que oferece trânsito. Reforçando, tráfego de dados para a Internet, chamamos de trânsito. Esta conexão de trânsito, entre 1 e T11 é direta, no sentido de que existe um meio físico conectando os dois roteadores. Há, entretanto, uma curiosidade neste trânsito: ele é assíncrono, isto é, as velocidade de subida e descida, do tráfego de dados, são diferentes. Verde é a cor que usaremos para identificar conexão assíncrona. O fornecedor de trânsito para a Localidade 1, somente oferece trânsito para a Internet IPv4. Foi necessário conseguir um trânsito IPv6 usando um túnel (“tunnelbroker”), com a Hurricane Electric (HE), que oferece tal facilidade, sem custo. A conexão com a HE não é direta e, portanto, exige interconexão com a Internet, em IPv4. Embora a HE não exija, a empresa usou seu ASN para fazer um empareamento (“peering”) com o HE1 (roteador da HE que atende ao trânsito IPv6 para a empresa, na Localidade 1. Como a empresa precisa de trânsito IPv6, em todas as localidades, a equipe técnica resolveu solicitar um empareamento com o Team Cymru (TCY), com o objetivo de receber os blocos IPv6 que não são anunciados na Internet, informação muito útil para os administradores da empresa, ao eliminar um considerável esforço extra de gerenciamento. O TCY estabelece o empareamento através de ASNs privativos, o que indica que não é necessário possuir um ASN para o empareamento com eles.

O trânsito assíncrono com T11 é uma aDSL. Os fornecedores de aDSL no Brasil, não possuem o hábito de estabelecer empareamento em seus roteadores com os clientes.

Não estamos interessados em avaliar o mérito do significado de um trânsito assíncrono. A escolha foi feita partindo das premissas: baixíssimo custo e interesse técnico.

Há diferenças entre o tráfego de dado estabelecido com o Team Cymru e com a HE. O primeiro é somente tráfego de dados (em uma única direção) e o segundo é trânsito! Tráfego de dados como o do Team Cymru, é dito tráfego de empareamento (ou tráfego de “peering”), ou mais simplesmente, tráfego (quando não há custos envolvidos, como é o caso). A conexão com o Team Cymru não é direta, razão pela qual usamos a cor vermelha.

Já é possível perceber, que não estamos interessados em questões de implementação ou outros detalhes de cada fornecedor de tráfego. Isto acontecerá nos Capítulos 3 e 4. Por hora, nossa preocupação são as topologias. Claro é, entretanto, que os envolvidos na topologia possuem um conhecimento técnico anterior. Até o final do livro, isto será transmitido para aqueles que ainda não detêm tal conhecimento.

A importância da Localidade 1, para a equipe técnica está caracterizada pelo retângulo, no desenho.

 

2.2 Topologia da Localidade 2

 

A Figura 2.2, apresenta a topologia da Localidade 2.

 

Topologia-031

Figura 2.2. Topologia das Localidades 1 e 2.

 

A topologia da Localidade 2 mostra uma conexão de trânsito em T21 (via fibra ótica), agora síncrona. T21 é um AS, o que implica em um trânsito com empareamento entre os roteadores 2 e T21. Este empareamento com T21 recebe a tabela completa de rotas disponível da Internet e, o roteador 1, não faz nenhuma restrição do que chega até ele, nesta tabela, exceto a rotas padrões (ou, “default”) e seus blocos anunciados. Também, trânsito IPv6 não é oferecido por T21 e, portanto, suprido pela HE (HE2). Como temos agora, IPv4 e IPv6 sendo oferecidos foi conveniente fazer dois empareamentos com o TCY, para receber os blocos IPv4 e IPv6, não anunciados (chamado de “bogon”, em ambos os casos). O TCY exige dois empareamentos (para segurança adicional da conexão), para cada tipo de “bogon”: dois para o IPv4 e dois para o IPv6. Então, o roteador 2 tem quatro empareamentos com o TCY (no roteador 1, são dois empareamentos).

A novidade na Localidade 2 é a conexão com um dos Pontos de Troca de Tráfego (PTTs) brasileiros. Nesta Localidade temos o PTT1, com uma conexão de tráfego, parecida com a do Team Cymru e por isto, conexões a PTTs são chamadas simplesmente de tráfego (ou tráfego de empareamento). Ao PTT1, está conectado o T22, com o qual a empresa resolveu fazer um acordo bilateral dentro do PTT1, para seu trânsito redundante na Localidade 2, à Internet. Há entretanto, uma conexão de trânsito, entre o T21 e o T22 indicando que o trânsito da empresa na Localidade 2 é feita, na realidade, somente pelo T22. Este aparente excesso será analisado detalhadamente no Capítulo 3 (Interconexões). A conexão do roteador 2 com o PTT1 é direta (local, para sermos mais precisos).

 

2.3 Topologia da Localidade 3

 

Nossa abordagem agora será sobre a Figura 2.3, que expõe a topologia da Localidade 3.

 

Topologia-043

Figura 2.3. Topologias das Localidades 1, 2 e 3.

 

A Localidade 3 tem trânsito IPv6 e IPv4, diretamente de T31. O fornecedor T31 recebe trânsito IPv6 de T32 do qual, também. recebe trânsito IPv4 e transporte até o PTT4. O T31 recebe trânsito IPv4 de T33, o qual fornece transporte até o PTT2. Nesta topologia, o roteador 3 possui um empareamento em pilha dupla (IPv4 + IPv6) com seu único fornecedor de trânsito, o T31. O TCY é usado, com quatro empareamentos para receber os “bogons” IPv4 e IPv6. É do nosso conhecimento, que T31 possui trânsitos com bandas diferentes, de T32 e T33. O conexão de 3 com T31 é local, o que favorece, no empareamento, somente o recebimento da rota padrão, sem necessidade de tabelas de roteamento.

Vamos à topologia da Localidade 4, mostrada na Figura 2.4.

 

2.4 Topologia da Localidade 4

 

 

Topologia-052

Figura 2.4. Topologias das localidades 1, 2, 3 e 4.

 

A topologia para a Localidade 4 é parecida com a da Localidade 3, exceto pelo fato de possuir trânsito somente com um fornecedor, o T41, que por sua vez, também possui uma única conexão de trânsito, com o T411. Um pouco mais elaborada, a topologia mostra que o roteador 2 recebe trânsito IPv6, através de uma conexão com o PTT2, em um acordo bilateral com um fornecedor por lá conectado. Com podemos observar, o PTT2 é também, uma conexão da Localidade 3 mas, que não recebe trânsito IPv6, por lá. O Team Cymru está, também, empareado nesta localidade (TCY).

O desenho ilustra que o tráfego do roteador 4 ao PTT2 é invisível aos fornecedores de trânsito. Bem como o trânsito IPv6.

A topologia da Localidade 5 é discutida no tópico abaixo.

 

2.5 Topologia da Localidade 5

 

A Figura 2.5 exibe a topologia da penúltima localidade.

Topologia-062

Figura 2.5.

 

Sem redundância, o T51 fornece trânsito para a empresa, através de T52. Como T52 não é uma conexão direta, é a localidade com a pior deficiência na segurança de tráfego para a Internet, muito embora isto não aconteça nos trânsitos construídos por T52. Um novo PTT, o PTT1 está acessível aproveitando a oportunidade de transporte que T52 oferece para T51.

 

2.6 Topologia da Localidade 6

 

A Figura 2.6 mostra uma topologia preliminar da Localidade 6.

 

Topologia-072

Figura 2.6.

 

É a única em que o trânsito não é direto com o roteador de borda da Internet. Mas, isto não representa uma insegurança para a conexão, porque o roteador T61 está em uma rede diretamente conectada. Além do mais, o T61 está diretamente conectado a diversos trânsitos redundantes. Embora um dos trânsitos de T61 ofereçam IPv6, não foi possível, ainda, usar esta facilidade. Por esta razão, o trânsito IPv6 é feito via túnel, com a HE (HE6). Via T61, conseguiu-se acesso a um outro PTT, o PTT5. A troca de tráfego multilateral no PTT1 é muito interessante para a Localidade 6. Insistentemente, o TCY é usado, também.

A Localidade 6 possui uma característica especial, no contexto da empresa, que é o controle sobre atividades de quatro outras localidades próximas, mas remotas. Esta relação está exibida na Figura 2.7. O trânsito de Internet para estas localidades é feito pela Localidade 6. Por outro lado, a Localidade 6 possui uma série de outros recursos especialmente úteis para atender a sua demanda remota.

 

Topologia-07.12

Figura 2.7. Topologias de todas as localidades e a extensão da Localidade 6.

 

 

2.9 A arquitetura final

 

Cada localidade da empresa está acessível através da Internet. Logo, a empresa ESTÁ na Internet, pois ela usa seus ASNs, em cada localidade, para que isto aconteça (exceto a Localidade 1). A Figura 2.8 ilustra bem este fato.

O pessoal de administração da rede da empresa, presentes, em sua quase totalidade, na Localidade 1, gerencia todos os recursos, principalmente usando o IPv6.

 

Topologia-Final4

Figura 2.8. Visão final da topologia global da empresa.

 

Mas, há algumas pequenas dificuldades, a maioria delas identificadas quando toda a arquitetura (o conjunto das seis topologias) se tornou operacional. Como não eram problemas graves foi prudente esperar algum tempo para iniciar um processo de otimização e refinamento granular da arquitetura. O que foi feito estará descrito nos Capítulos 3 e 4, deste livro.

 

2.10 ASNs, IPv4 e IPv6 usados neste documento

 

O RFC5398 indica os seguintes números para identificar ASNs privativos:

64496 - 64511 e 65536 - 65551

 

O RFC5735 (página 5), apresenta o quadro reproduzido abaixo, os IPv4 indicados para uso específico:

 

Address Block       Present Use                Reference
------------------------------------------------------------------
0.0.0.0/8           "This" Network             RFC 1122, Section 3.2.1.3
10.0.0.0/8          Private-Use Networks       RFC 1918
127.0.0.0/8         Loopback                   RFC 1122, Section 3.2.1.3
169.254.0.0/16      Link Local                 RFC 3927
172.16.0.0/12       Private-Use Networks       RFC 1918
192.0.0.0/24        IETF Protocol Assignments  RFC 5736
192.0.2.0/24        TEST-NET-1                 RFC 5737
192.88.99.0/24      6to4 Relay Anycast         RFC 3068
192.168.0.0/16      Private-Use Networks       RFC 1918
198.18.0.0/15       Network Interconnect
                    Device Benchmark Testing   RFC 2544
198.51.100.0/24     TEST-NET-2                 RFC 5737
203.0.113.0/24      TEST-NET-3                 RFC 5737
224.0.0.0/4         Multicast                  RFC 3171
240.0.0.0/4         Reserved for Future Use    RFC 1112, Section 4
255.255.255.255/32  Limited Broadcast          RFC 919, Section 7
                                               RFC 922, Section 7

 

O RFC3849 recomenda o uso do bloco IPv6

2001:DB8::/32

em documentos. Contudo, há em andamento, no IETF um Internet-Draft (I-D) propondo disponibilizar o bloco DDDD:D000::/20, para documentação (draft-moreiras-v6ops-rfc3849bis-00.txt). Embora o I-D esteja em fase de obtenção do consenso no IETF usaremos endereçamento IPv6 retirado deste bloco.

Arbitrariamente, vamos supor que a empresa abordada possua o AS64500 e tenha recebido, associados a este ASN, do Registro.br, os blocos 10.1.0.0/20 e DDDD:D000::/32. Suponha, também, que esta empresa obteve um outro ASN (AS65536), sem nenhum bloco IPv6 ou IPv4. Para efeito didático, o conteúdo deste livro abstrai-se das restrições privativas dos números escolhidos, isto é, a noção de uso privado não será considerado, nestes casos.



 

Agradecimentos

 

Foram muitas as pessoas que me deram suporte para o desenvolvimento deste trabalho. De várias maneiras, direta e indiretamente. Isto inclui meus inúmeros clientes, velhos amigos e novos amigos. A eles, meus agradecimentos. Em particular, gostaria de nomear algumas pessoas que colocaram recursos físicos, materiais, experiências incomuns e incentivos, permitindo incondicionalmente, que a topologia pudesse ser testada e simulada de forma integral, sistemática e intensivamente, em suas diversas etapas, mesmo sem conhecimento do objetivo final. São elas, em ordem alfabética: Éder Zagui (IBL Telecom, Guaratinguetá, SP), Fabrício Mota Camargo (MutumNet, Mutum, MG), José Marconi de Almeida (Cooperabaeté, Abaeté, MG), Luciano Inácio (Jupiter Telecom, Imperatriz, MA), Luciano Rampanelli (Comodoro, MT), Marcelo Micucci (BM Promoções, Belém, PA), Marcos Paulo Fernandes (Heliodora Online, Heliodora, MG), Samyr Bechelane (Netcetera, Betim, BH).



Anúncios
Categorias:Bogon, eBGP, iBGP, IPv4, MPTCP, PTT, RPKI, TCP/IP

BGP: topologias, abstrações, eBGP e iBGP (Parte 1)

Introdução

Este artigo tem o propósito de evoluir o entendimento do BGP, que se está procurando dar, ao longo dos artigos anteriores. Neles a abordagem foi dada sobre o Mikrotik, um roteador (entre outras funções) simples e versátil de lidar. De agora em diante será rompida a forte vinculação única e, abandonaremos, também, o FFE, para ampliarmos a complexidade do BGP em abordagens mais práticas, do dia-a-dia.

Finalmente iremos apreciar o iBGP, componente inseparável do BGP. O outro componente inseparável é o eBGP. A completude do BGP exige ênfase na topologia, como iremos verificar. Desenhar a topologia adequada para o planejamento do BGP é uma questão fundamental, pois deve-se perseguir a simplicidade das representações para contornar a sua complexidade, como um todo.

A topologia, que na prática apresenta-se em formas semelhantes, mas dificilmente idênticas tem sido relegada a um plano secundário, já que a tendência é evitar projetos ou planejamentos em redes, que demandam imenso esforços, mas extremamente importantes para bons resultados na implementação de um BGP. Geralmente, a partir do instante em que o BGP se comporta de forma aceitável é comum deixar de lado as preocupações com sua otimização sob o ponto de vista da eficiência. No Brasil, aparentemente, tem-se uma curiosa tendência em permitir que as grandes operadoras façam o que bem entenderem em relação à topologia, facilitando seus interesses e não os de seus clientes, e até mesmo, os interesses da própria Internet. É um cenário abusivo, monopolista, oligopolista e, pior, um cenário de oportunistas a soldo de interesses pessoais, de grupos muito bem articulados e econômicos predatórios. Tais questões, por demais importantes serão tratadas em outro momento.

Um autor será muito referenciado, inclusive nas entrelinhas: John W. Stewart III, ou simplesmente, John Stewart. Ele escreveu o imperdível, fascinante e único romance sobre o BGP41, disponível para leitura contínua e de cabeceira. Mas, nossa bíblia continuará sendo a RFC42712. Em um sentido mais amplo, completo e detalhado, nada como o livro de Radia Perlman7 que exibe sua intensa experiência. Mais recente, atualizado e imperdível é o livro de Russ White e outros9. Uma referência prática e específica é o artigo de Caesar e Rexford6 que propõem dicas importantes para quem precisa trabalhar, de forma sistemática, com políticas de roteamento, principais preocupações dos administradores de BGP. Finalmente, não se pode esquecer que o BGP é constantemente ampliado e atualizado pelas RFCs.

Uma topologia para o debate

A Figura 1, abaixo, exibe uma topologia para iniciar o debate. São três pontos independentes de conexão estática à Internet, uma interconexão ao PTT-Belém, três pontos de empareamento em túneis IPv6 com um mesmo operador de trânsito e dois empareamentos (IPv4 e IPv6), com o Team-Cymru, para recebimento dos “bogons” (Belém).

 

Figura 1. Visão inicial da topologia.

 

As observações que nos interessam sobre a Figura 5, são:

  1. Tudo está funcionando a contento.
  2. Embora não mostrada na Figura 1 há uma VPN entre Guará e SJCampos.
  3. Há três túneis 6to4, com a Hurricane Eletric, para o mesmo AS6939 (Belém, Guará e SJCampos).
  4. Face a independência das conexões seria necessário o empareamento com o Team Cymru, também, em Guará, onde terá BGP.

Talvez refinando um pouco mais a topologia da Figura 1, com base nas observações de 1 a 4, acima, algo mais virá a tona. Por exemplo, a representação da Internet está fora do lugar, na Figura 1.

 

Figura 2. Refinando a topologia da Figura 1.

 

Figura 2 exige outras observações, mais detalhadas:

  1. As setas em vermelho, representam empareamentos BGP. Neste caso temos eBGP pois as conexões são entre Sistemas Autõnomos com ASNs diferentes. Em outras palavras, eBGP é um protocolo EGP5. O eBGP é um dos dois principais componentes do BGP. O outro é o iBGP, que é um protocolo do tipo IGP5. O iBGP é usado para as interconexões entre roteadores de um mesmo AS e, existem diversos protocolos que exercem funções equivalentes ao iBGP (RIP, OSPF, etc.).
  2. As setas pretas são interconexões de trânsito.
  3. A conexão de trânsito em Belém é estática. Será transformada para um trânsito em BGP quando houver outro trânsito através do PTT, em acordo bilateral com um fornecedor de trânsito, claro, também, no PTT. Na oportunidade de implementação de um trânsito “multihoming”, já espera-se que a tabela de roteamento seja do tipo “full routing”.
  4. O trânsito em Guará é estático, também. Brevemente será dinâmica, via BGP, com um único operador.
  5. Embora não mostrada na Figura 1 há uma VPN entre Guará e SJCampos.
  6. Há três túneis 6to4, com a Hurricane Eletric (AS6939): Belém, Guará e SJCampos.
  7. Face a independência das conexões seria necessário empareamento com o Team Cymru, também, em Guará, onde terá BGP. O empareamento com o Team Cymru é somente em uma direção (unicamente para recebimento das tabelas de bogon (IPv4 e IPv6).
  8. Embora a figura apresente somente uma Internet é bom lembrar que são duas: IPv4 e IPv6.
  9. Seria interessante empareamento BGP em SJCampos, mas há um impedimento comercial, pois a conexão com a Internet é uma aDSL. BGP (isto é, eBGP), entre ASes, tipicamente exige conectividade física. Não que interconexões assíncronas impeçam o eBGP.

Procurando uma topologia sem os detalhes irrelevantes

Na Figura 3, mostramos uma topologia idêntica à da Figura 2, mas totalmente abstrata, sem mostrar as questões irrelevantes, tais como, IPs, ASNs, formas de conectividade, localidades, anúncios, etc.

 

Figura 3. Topologia abstrata da Figura 2.

 

Veremos que pensar/planejar em uma topologia abstrata ficará mais fácil. Podemos melhorar mais ainda se pensarmos que as respectivas conexões de R!, R2 e R3, com os roteadores externos ao domínio local, RA, RB, …, RG são todas via BGP, isto é, eBGP. Portanto, a Figura 4 torna mais simples e adequada a topologia na qual iremos trabalhar. Realmente, em uma implementação de BGP, na qual esperamos anunciar nossos IPs e receber anúncios de vizinhos, tanto faz pensar em uma única implementação ou em várias. Na primeira implementação de um BGP sabemos que tratamentos diferenciados com vizinhos distintos, serão feitos através de filtros. Recursos mais elaborados serão feitos através de políticas de roteamento mais sofisticadas. Filtros fazem parte da política de roteamento, mas não são suficientes para outros tratamentos, eventualmente necessários, que não seriam atendidos pela política do melhor caminho (“shortest-path policy”), inerente ao BGP.

 

Figura 4. Topologia com a abstração máxima.

 

A topologia da Figura 4 é nossa melhor representação, sem dúvida. Mas, existem questões didáticas que remete-nos à Figura 5, para lembar que cada roteador do Domínio Local (DL) possui sua própria rede local (basta ver nossa topologia original, da Figura 2, representadas pelas localidades. Na oportunidade vale lembrar que cada um dos roteadores externos e vizinhos dos roteadores DL, possui seus respectivos domínios, sobre os quais o administrador do DL não consegue interferir diretamente.

 

Figura 5. Topologia sob efeito didático: as redes de cada Ri (i=1, 2 e 3).

 

Tipicamente, o DL possui diversos roteadores internos, em cada rede. Tais roteadores estão interconectados, a partir do roteador Ri. Cada um destes roteadores internos, constroem sua própria rede, muito embora alguns roteadores possam ser transformados em “bridge”. Mas, “bridge” não é um roteador! Então não estamos interessados nelas, nesta etapa de entendimento sobre o BGP. Portanto, a força da didática nos induz a um aperfeiçoamento, mostrado na Figura 5, e na Figura 6, onde estão representados os inúmeros roteadores de cada rede local. Inúmeros é força de expressão, pois por razões práticas representaremos uns poucos, para depois representarmos somente um.

 

Figura 6. Topologia sob efeito didático: os roteadores, Rij (i=1, 2,… 3; j=1, 2, …, n), de cada Ri.

 

Há detalhes irrelevantes na Figura 6. Por exemplo, a representação das redes internas a cada Ri e a especificação dos domínios dos vizinhos. A Figura 7, que segue, abstrai-se de tais detalhes, pois intuitivamente induz-nos a imaginar as redes locais de cada Ri e, também, as redes locais dos Rij.

 

Figura 7. Topologia sem os detalhes irrelevantes da topologia da Figura 6.

 

Neste ponto, fixaremos na Figura 7 e passaremos a entender sobre os protocolos EGPs e IGPs.

Protocolos EGPs e IGPs.

eBGP é um protocolo EGP (“Exterior Gateway Protocol”). iBGP é um protocolo IGP (“Interior Gateway Protocol). O mais famoso protocolo do tipo EGP é o BGP4. Existem outros, como o BGP (versão anterior do BGP4, às vezes chamado de BGP3), o GGP (“Gateway to Gateway Protocol”), o protocolo Hello, o protocolo EGP (conflitando com o nome do tipo EGP). Já os protocolos do tipo IGP são vários: RIP (“Routing Information Protocol”), OSPF (“Open Shortest Path First”), IS-IS (“Intermediate System do Intermediate System”), IGPR e EIGPR. Estes dois últimos são protocolos proprietários da Cisco. O RIP é muito usado em pequenas redes com topologia não complexas. Esta lembrança sobre o RIP se deve ao fato de ser um dos protocolos muito usados no mundo inteiro e para lembrar que topologia exerce uma influência muito grande na escolha do protocolo. Por outro lado, percebe-se que o RIP é pouco usado no Brasil, onde se dá preferência ao OSPF, independente da topologia ser simples ou não. O BGP tem seu próprio IGP, como já sabemos: o iBGP.

Ao escolher um protocolo, a preocupação está na capacidade de que um ponto da rede possa alcançar qualquer outro ponto (interno ou externo), e vice-versa. Esta é a propriedade da atingibilidade, do inglês “reachability”. Neste ponto, vale lembrar que Sistema Autônomo (AS) exerce um efeito significativo, principalmente quando lembramos o que diz Stewart1, na página 18: “… um AS é uma coleção de roteadores e não uma coleção de prefixos IPs”. Stewart1 diz isto para esclarecer que o objetivo de um protocolo EGP é o de permitir que dois diferentes ASes possam trocar informações de roteamento de tal forma que tráfego de dados possa atravessar entre eles, em ambas as direções. Para que tal tráfego seja eficaz, em todos os sentidos, um protocolo EGP deve incluir mecanismos que permitam os administradores de ambos os ASes definir suas regras de comportamento do tráfego, independentemente, já que ambos estão em domínios administrativo e técnicos diferentes, que em tese, mal se conhecem. Tais mecanismos são o que conhecemos como política de roteamento. Filtros do BGP (eBGP!) fazem parte da política de roteamento quando, decidimos quais prefixos podem ser anunciados ou não. Um bom exemplo, que amplia esta noção de política de roteamento para além dos filtros (mas com a ajuda deles) é a opção de empareamento com o Team Cymru para garantir a prática desejável de não transferir “bogons” para os vizinhos do empareamento BGP.

Neste momento, podemos identificar algumas questões que devem ser resolvidas e outras observações que podem influenciar nosso planejamento:

  • A atingibilidade entre os roteadores, R1i, R2j e R3k, só acontecem via Internet (IPv4 e IPv6).
  • A atingibilidade de R14, por exemplo, só é possível com rotas estáticas. Sem um protocolo dinâmico, o trabalho pode ser muito grande. Imagine um ambiente interno com mais de 50 roteadores, como é o caso de Belém.
  • Considerando o DL com 3 pontos de presença separados, a redundância só pode ser conseguida em cada ponto. É possível alterar tal condição? Sob o ponto de vista econômico/financeiro como deve ser tratada tal questão? Aqui entrará um outro componente competindo com a topologia: o componente econômico. Caesar e Rexford6 chamam o componente econômico de relações de negócios, como uma das quatro outras políticas que um administrador de AS deve considerar: escalabilidade, engenharia de tráfego e segurança. Na política relações de negócios eles incluem as relações políticas, além das econômicas. Na política de engenharia de tráfego incluem as necessidades de controle do fluxo de tráfego e preocupações relacionadas com congestionamento e qualidade de serviços, tanto internamente quanto externamente. Na política de escalabilidade, as preocupações estão ligadas à redução do controle do tráfego e eliminação de sobrecarga dos roteadores. Finalmente, a política de segurança, relaciona-se com as proteções contra ataques maliciosos ou acidentais.
  • Podemos pensar em “manutenção móvel” com roteadores móveis? Por exemplo, um roteador em uma VM de um notebook, digamos, openBSD.

O principal dilema, para seguir as preocupações acima é identificar o melhor protocolo do tipo IGP a ser usado na topologia da Figura 7. Em seguida, entender, profundamente, o escolhido. É claro que a escolha recai sobre o iBGP. Mas, porque? Para responder a esta pergunta, precisamos ir um pouco além do que sabemos atualmente sobre protocolos (na realidade só conhecemos um pouco do BGP). Ir um pouco além significa abordar:

  • A diferença entre EGP e IGP.
  • O que se sabe e não se sabe, até agora, sobre o BGP.

Diferenças entre EGP e IGP


Protocolo é uma palavra que referencia múltiplas atividades em uma rede. Por exemplo, protocolo IP é um protocolo que trata do formato de informações que são encaminhadas de um ponto de origem até um ponto de destino de uma rede que trabalha sob as características do protocolo TCP/IP. Protocolo TCP/IP é a designação genérica de um conjunto de atividades que são manipuladas em uma instância do modelo de camadas que conhecemos como OSI. A literatura, às vezes, chama o protocolo IP, que estamos usando como exemplo, de protocolo roteado (“routed protocol”). Já o BGP é um protocolo de roteamento, ou mais formalmente, um protocolo que implementa um algoritmo de roteamento. Protocolos, como o BGP, que implementam um algoritmo de roteamento são reconhecidos protocolos de roteamento dinâmicos, em contraste com os protocolos de roteamento estáticos, onde o ser humano é o agente de sua implementação, isto é, as rotas são implementadas manualmente, nos roteadores.

Há, infelizmente, uma outra confusão na literatura sobre o BGP ser ou não um protocolo dinâmico. Alguns dizem que ele não é dinâmico, nem estático (!?). Outros dizem, como Perlman7, que ele é um protocolo estático. Mais à frente, quando falarmos sobre o BGP, o contexto irá indicar-nos onde ele se insere.

Os protocolos dinâmicos (exceto o BGP…), são implementados usando um dos dois tipos de algoritmos: distance vector e link state. A análise de tais algoritmos nos dará base para a escolha de nosso protocolo inter-domínio. Não iremos entrar em muitos detalhes sobre eles, exceto o necessário para nossas decisões, mas estão muito bem descritos em Perlman7.

Roteamento do tipo “distance vector”

O algoritmo “distance vector” (DV), conhecido também como algoritmo de Bellman-Ford exige que cada nó (ou roteador) da rede envie para seus vizinhos, parte ou toda a informação de sua tabela de roteamento. Para ver seu funcionamento usaremos a rede formada pelo roteador R1, da Figura 7, sobre a qual incluímos uma identificação do enlace (caminho), em vermelho, para efeito didática.

 

Figura 8. Modelo para explicar os tipos de algoritmos.

 

A tabela de roteamento de cada roteador, no início, contem as informações relacionadas com os anúncios que ele deve informar para seus vizinhos, com o único objetivo de que os vizinhos possam atingir toda sua rede. Para entendermos o funcionamento do DV, eis os prefixos de cada um dos 5 roteadores presentes na rede:

R1 abcd:efgh:1::/48
R11 abcd:efgh:11::/48
R12 abcd:efgh:12::/48
R13 abcd:efgh:13::/48
R14 abcd:efgh:14::/48

No início, quando todos os 5 roteadores forem simultaneamente ligados e o algoritmo começar a funcionar (operação conhecida como “cold start” => partida fria), cada um deles terá uma tabela de roteamento construída pelas seguintes informações: para quem anuncia, o quê anuncia, qual o caminho e a distância para atingir (custo), a partir do caminho indicado. Abaixo, eis a imagem de cada tabela de roteamento quando da partida fria, à qual inserimos uma indicação do momento em que isto ocorreu (T). Quando T = 1, o item da tabela foi criado na partida fria. Também, por razões didáticas será acrescentada uma coluna de observações para facilitar o entendimento do algoritmo:

  • Tabela do R1:
    T Para O quê Caminho Custo Observações
    1 R1 abcd:efgh:1::/48 local 0  
  • Tabela do R11:
    T Para O quê Caminho Custo Observações
    1 R11 abcd:efgh:11::/48 local 0  
  • Tabela do R12:
    T Para O quê Caminho Custo Observações
    1 R12 abcd:efgh:12::/48 local 0  
  • Tabela do R13:
    T Para O quê Caminho Custo Observações
    1 R13 abcd:efgh:13::/48 local 0  
  • Tabela do R14:
    T Para O quê Caminho Custo Observações
    1 R14 abcd:efgh:14::/48 local 0  

Cada tabela acima está informando ao seu respectivo roteador, para onde ele deve seguir quando desejar alcançar (atingir), sua própria rede e quanto isto irá custar. O quanto irá custar é o resultado mais importante do algoritmo e recebe o nome do próprio algoritmo: vetor de distância, isto é, “distance vector”.

O próximo passo é cada roteador informar para seus vizinhos o conteúdo de toda sua tabela de roteamento. Por exemplo, o R1 informará para seu único vizinho, R11, o conjunto (R1;abcd:efgh:1::/48;local;0). O R11 irá então instalar em sua tabela de roteamento esta informação de R1 e, consequentemente, aumentará seu conhecimento de atingibilidade, dentro da rede. E assim o nosso T=2 ficará da seguinte forma:

  • Tabela do R1:
    T Para O quê Caminho Custo Observações
    1 R1 abcd:efgh:1::/48 local 0  
    2 R11 abcd:efgh:11::/48 3 1 Recebida de R11. Criada em T=1.
  • Tabela do R11:
    T Para O quê Caminho Custo Observações
    1 R11 abcd:efgh:11::/48 local 0 Criado na partida fria
    2 R1 abcd:efgh:1::/48 1 1 Recebida de R1. Criada em T=1.
    2 R13 abcd:efgh:13::/48 2 1 Recebida de R13. Criada em T=1.
  • Tabela do R12:
    T Para O quê Caminho Custo Observações
    1 R12 abcd:efgh:12::/48 local 0 Criada na partida fria.
    2 R13 abcd:efgh:13::/48 4 1 Recebida de R13. Criada em T=1.
  • Tabela do R13:
    T Para O quê Caminho Custo Observações
    1 R13 abcd:efgh:13::/48 local 0 Criada na partida fria.
    2 R12 abcd:efgh:12::/48 4 1 Recebida de R12. Criada em T=1.
    2 R11 abcd:efgh:11::/48 2 1 Recebida de R11. Criada em T=1.
    2 R14 abcd:efgh:14::/48 3 1 Recebida de R14. Criada em T=1.
  • Tabela do R14:
    T Para O quê Caminho Custo Observações
    1 R14 abcd:efgh:14::/48 local 0 Criada na partida fria.
    2 R13 abcd:efgh:13::/48 3 1 Recebida de R13. Criada em T=1.

Embora o processo de mensagens de um roteador para seus vizinhos esteja sempre acontecendo nossa visão passo a passo observa que a tabela de R11 tem algumas entradas que ocorreram no T=2 que não estão em R1 (a informação sobre o anúncio de R13). O mesmo se pode dizer de R11 em relação a R13 (a entrada de R1) e assim por diante. O algoritmo envia todos os componentes de uma tabela de roteamento. Ao receber a tabela inteira, ele verifica se já existe alguma entrada e se houver, compara o custo com a existente. Se o custo for igual ou maior ignora a entrada. Se for menor, substitui a entrada anterior por esta. Vamos ao passo T=3 e ver o estado de cada tabela, a seguir:

  • Tabela do R1:
    T Para O quê Caminho Custo Observações
    1 R1 abcd:efgh:1::/48 local 0  
    2 R11 abcd:efgh:11::/48 1 1  
    3 R13 abcd:efgh:13::/48 1 2 Recebida de R11 (T=2).
  • Tabela do R11:
    T Para O quê Caminho Custo Observações
    1 R11 abcd:efgh:11::/48 local 0  
    2 R1 abcd:efgh:1::/48 1 1  
    2 R13 abcd:efgh:13::/48 2 1  
    3 R12 abcd:efgh:12::/48 2 2 Recebida de R13 (T=2)
    3 R14 abcd:efgh:13::/48 2 2 Recebida de R13 (T=2)
  • Tabela do R12:
    T Para O quê Caminho Custo Observações
    1 R12 abcd:efgh:12::/48 local 0  
    2 R13 abcd:efgh:13::/48 4 1  
    3 R11 abcd:efgh:11::/48 4 2 Recebida de R13 (T=2)
    3 R14 abcd:efgh:14::/48 4 2 Recebida de R13 (T=2)
  • Tabela do R13:
    T Para O quê Caminho Custo Observações
    1 R13 abcd:efgh:13::/48 local 0  
    2 R12 abcd:efgh:12::/48 4 1  
    2 R11 abcd:efgh:11::/48 2 1  
    2 R14 abcd:efgh:14::/48 3 1  
    3 R1 abcd:efgh:1::/48 2 2 Recebida de R11 (T=2)
  • Tabela do R14:
    T Para O quê Caminho Custo Observações
    1 R14 abcd:efgh:14::/48 local 0  
    2 R13 abcd:efgh:13::/48 3 1  
    3 R12 abcd:efgh:12::/48 3 2 Recebida de R13 (T=2)
    3 R11 abcd:efgh:11::/48 3 2 Recebida de R13 (T=2)

Vamos ao passo 4. Se nesse ponto houver dúvida sobre o que o algoritmo decide quando recebe uma entrada com um “Para” igual ao destino, basta lembar que na partida fria ele recebe o DV com valor do custo zero.

  • Tabela do R1:
    T Para O quê Caminho Custo Observações
    1 R1 abcd:efgh:1::/48 local 0  
    2 R11 abcd:efgh:11::/48 1 1  
    3 R13 abcd:efgh:13::/48 1 2 Recebida de R11 (T=2).
    4 R12 abcd:efgh:12::/48 1 3 Recebida de R11 (T=3).
    4 R14 abcd:efgh:14::/48 1 3 Recebida de R11 (T=3).
  • Tabela do R11: Sem alteração!
  • Tabela do R12:
    T Para O quê Caminho Custo Observações
    1 R12 abcd:efgh:12::/48 local 0  
    2 R13 abcd:efgh:13::/48 4 1  
    3 R11 abcd:efgh:11::/48 4 2 Recebida de R13 (T=2)
    3 R14 abcd:efgh:14::/48 4 2 Recebida de R13 (T=2)
    3 R1 abcd:efgh:1::/48 4 3 Recebida de R13 (T=3)
  • Tabela do R13: Sem alteração!
  • Tabela do R14:
    T Para O quê Caminho Custo Observações
    1 R14 abcd:efgh:14::/48 local 0  
    2 R13 abcd:efgh:13::/48 3 1  
    3 R12 abcd:efgh:12::/48 3 2 Recebida de R13 (T=2)
    3 R11 abcd:efgh:11::/48 3 2 Recebida de R13 (T=2)
    3 R1 abcd:efgh:1::/48 3 3 Recebida de R13 (T=3)

A tabela de roteamento de cada roteador está completa. É possível perceber que cada roteador tem, em sua tabela de roteamento a imagem de toda a rede da Figura 8. Logo, os anúncios recebidos dos nodos vizinhos garante a visibilidade completa da rede, o que garante uma conectividade completa (ou total), pois consegue-se atingir qualquer um dos IPs anunciados. Uma outra conclusão a ser tirada é de que o algoritmo DV é fácil de entender e implementar. Por outro lado, tabelas de roteamento são trocadas entre os nós, de tempos em tempos, e retransmitidas em intervalos regulares. Dependendo do número de roteadores da rede, os protocolos que implementam o algoritmo DV pode nos trazer sérios problemas. Tais problemas são derivados de uma particularidade no algoritmo chamada de contagem até o infinito, do inglês, “counting to infinity”. Para entender, retornemos à Figura 8, imaginando que a houve um rompimento no enlace entre R14 e R13, como pode ser visto na Figura 9, abaixo:

 

Figura 9. Rompimento de um enlace da topologia.

 

Os roteadores R13 e R14 irão detectar o rompimento do caminho 3, quase que imediatamente. Então eles irão alterar suas respectivas tabelas de roteamento, informando que o custo de tudo aquilo que referencia o caminho afetado (3) terá um custo “infinito”. Vejamos as duas tabelas após o rompimento (agora sem as colunas T e Observações.

  • Tabela do R13 após o rompimento:
    Para O quê Caminho Custo
    R13 abcd:efgh:13::/48 local 0
    R12 abcd:efgh:12::/48 4 1
    R11 abcd:efgh:11::/48 2 1
    R14 abcd:efgh:14::/48 3 infinito
    R1 abcd:efgh:1::/48 2 2
  • Tabela do R14 após o rompimento:
    Para O quê Caminho Custo
    R14 abcd:efgh:14::/48 local 0
    R13 abcd:efgh:13::/48 3 infinito
    R12 abcd:efgh:12::/48 3 infinito
    R11 abcd:efgh:11::/48 3 2
    R1 abcd:efgh:1::/48 3 infinito

Mas, os roteadores R12, R11 e R1 não conseguem enxergar tal rompimento imediatamente, e consequentemente não sabem que o R14 está isolado. Eles dependem de uma atualização do R13. Suponha que R12 ainda não tenha sido atualizado por R13. Então, a tabela de roteamento de R12 continua a mesma, isto é:

  • Tabela do R12, ainda sem conhecimento do rompimento:
    Para O quê Caminho Custo
    R12 abcd:efgh:12::/48 local 0
    R13 abcd:efgh:13::/48 4 1
    R11 abcd:efgh:11::/48 4 2
    R14 abcd:efgh:14::/48 4 2
    R1 abcd:efgh:1::/48 4 3

O procedimento de atualização das tabelas é automático e não sabemos o momento e quais vizinhos são notificados por quem. Vamos então, supor que R12 encaminhe sua tabela para R13. Ao recebê-la, R13 verifica que o seu registro atual do anuncio de R14 está com o valor infinito (ou maior do que o registro de R12, para R14). Então, ele troca o registro de R14 pelo que R12 enviou. A nova tabela de R13 fica assim:

  • Tabela do R13 após o rompimento:
    Para O quê Caminho Custo
    R13 abcd:efgh:13::/48 local 0
    R12 abcd:efgh:12::/48 4 1
    R11 abcd:efgh:11::/48 2 1
    R14 abcd:efgh:14::/48 3 infinito
    R1 abcd:efgh:1::/48 4 3

Com este arranjo na tabela de roteamento de R13, teremos os seguintes cenários:

  • Qualquer pacote, vindo de fora, com destino final R14 passará por R13. R13 o encaminhará para R12. R12 devolve-o para R13, que por sua vez envia de volta a R12 e assim por diante, até que o tempo de vida (“TTL”) do pacote expire. Qualquer pacote tem um TTL, mas quem decide sobre ele é outro protocolo. Este efeito saltitante, do pacote formando “loop” é denominado “bouncing effect”.
  • Se R13 enviar uma atualização de tabela para R11, a entrada para R14 nunca será alterada, pois o custo atual de R14 na tabela de R11 é menor. Logo, qualquer pacote vindo de fora, na direção de R14 passará por R13.
  • As atualizações de tabelas de roteamento provocadas por R12 e R13, sempre irão aumentar, rapidamente, na direção do infinito. Este efeito é denominado contagem até o infinito, ou “counting to infinity”.

Este cenário, muito conhecido, fez com que as implementações do algoritmo DV incorporassem técnicas para responderem tanto ao efeito saltitante quanto o efeito da contagem para o infinito. O RIP, que implementa o DV, possui tais técnicas, que fogem de nosso propósito. Em redes internas pequenas, o RIP funciona muito bem. Em grandes redes (muitos roteadores), certamente haverá queda sensível na eficiência do tráfego, se o algoritmo DV for usado. O dilema, então está construído: fácil de entender, mas restrito em cenários de falha. Em redes redundantes, entretanto, ele se mostra uma bela alternativa.

Conclusão

Protocolos que implementam o algoritmo distance vector, não estão nos nossos planos para a topologia da Figura 7. Portanto, precisamos analisar o algoritmo link state. Um protocolo muito usado que implementa esse algoritmo é o OSPF.

Após tal análise é necessário justificar a escolha do iBGP. Para implementá-lo deve-se ampliar o conhecimento sobre ele. Em particular há duas questões importantes no BGP que devem ser apreciadas: route reflection e confederações.

Feito isto estaremos prontos para o conhecimento prático do iBGP, que é sua implementação. Estas questões serão motivos para os próximos documentos aqui do blogue.

 

Referências

  1. John W. Stewart III. (1999). BGP4: Inter-Domain Routing in the Internet. Addison-Wesley.
  2. RFC4271, A Border Gateway Protocol 4 (BGP-4) Y. Rekhter, T. Li, S. Hares [ January 2006 ] (TXT = 222702) (Obsoletes RFC1771) (Status: DRAFT STANDARD) (Stream: IETF, Area: rtg, WG: idr).

  3. RFC6286, Autonomous-System-Wide Unique BGP Identifier for BGP-4 E. Chen, J. Yuan [ June 2011 ] (TXT = 7497) (Updates RFC4271) (Status: PROPOSED STANDARD) (Stream: IETF, Area: rtg, WG: idr)
  4. Xiaoliang Zhao , Beichuan Zhang , Dan Massey , Lixia Zhang, A Study on BGP AS Path Characteristics. Disponível em: http://www.cs.colostate.edu/~massey/pubs/tr/massey_usctr04-818.pdf. Acessado em 10/03/2011.

  5. Braga, J. (2008). Glossário da Infraestrutura da Internet. Disponível em: https://juliaobraga.wordpress.com/2008/12/01/glossario/. Acessado em 05/11/2011.

  6. Caesar, M., & Rexford, J. (21 de novembro de 2005). BGP routing policies in ISP networks. Acesso em 25 de novembro de 2011, disponível em Princenton University: http://www.cs.princeton.edu/~jrex/papers/policies.pdf

  7. Perlman, R. (1999). Interconnection: bridges, routers, switches and internetworking protocols (2a. ed.). Addison-Wesley.
  8. RFC4456,BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) T. Bates, E. Chen, R. Chandra [ April 2006 ] (TXT = 23209) (Obsoletes RFC2796, RFC1966) (Status: DRAFT STANDARD) (Stream: IETF, Area: rtg, WG: idr)
  9. Russ White, D. M. (2005). Practical BGP. Boston, MA, USA: Pearson Education, Inc.
Categorias:BGP, Bogon, eBGP, iBGP, IPv4, IPv6, PTT, TCP/IP
%d blogueiros gostam disto: