Arquivo

Archive for the ‘Protocolos’ Category

Modelos: BGP, Internet e outros componentes

 

Instead of trying to impress the reader with what I know,
I try to explain why the things I’ve learned impress me.

Donald Knuth, aqui

 

Introdução

 

Este é o terceiro da série (imagino, longa) de artigos necessários para consolidar as ideias do projeto sobre Objetos de Projeto Estendido (OPE)1. Na sequência do primeiro artigo foi apresentada a MEF (Máquina de Estado Finito) do BGP1. O modelo da MEF foi construído com base na descrição fundamental, isto é, a RFC42714.

Um dos mais importantes componentes dos artigos são os modelos. Via de regra abstratos e produzidos por imagens ou figuras, eles são acompanhados de uma descrição para que se desfaça algumas confusões mentais. A noção de modelos, tal qual se imagina é descrita, a seguir.

 

Modelos

 

Modelos tem sido explorados por muitos pesquisadores e autores. Particularmente, por Scott E. Page5, 6 e 7, em seus inúmeros textos além dos citados. Por exemplo, em seu curso Model Thinking. Professor Scott5 chama a atenção para fatos interessantes, sobre modelos:

  • Quando mais você conhece o contexto, mais seu modelo se aproxima da realidade.
  • Modelos devem ser aperfeiçoados, isto é, refinados de forma sistemática.
  • Nenhum modelo é perfeito. O modelo da MEF do BGP se aproxima mais da realidade quando damos nomes aos arcos com o objetivo de descrever, compreender e garantir sua consistência.
  • Muitas vezes, principalmente em sistema com razoável complexidade, precisamos de vários modelos para descrevê-lo. É o caso do BGP. A MEF não modela o BGP como um todo, mas sim uma parte dele que é o automato finito para que a conexão seja estabelecida. A figura e a respectiva descrição2 representam, por outro lado, uma parte da MEF do BGP. Está faltando o comportamento do autômato finitoo (ou MEF), no que diz respeito às mensagem recebidas, que está disponível no livro do Stewart8.
  • Sistemas como a MEF do BGP tendem a permitir a construção de modelos bem representativos do seu comportamento. Em sistema mais complexos isto só será possível com um conglomerado (ou nuvem) de modelos. O próprio BGP é um sistema muito complicado, como já foi dito. A MEF é um componente, simples, do BGP. Para entender o BGP, como um todo, precisamos de vários modelos. Até mesmo vários modelos de autômatos finitos. por exemplo, para que o BGP funcione, os pares precisam estar conectados. A conexão é feita em TCP. A modelagem de uma conexão TCP exige um outro autômato finito. Veremos isto mais à frente.
  • Há três equívocos comuns cometidos por pessoas, sobre modelos:
    1. Pessoas acreditam piamente em modelos.
    2. Algumas pessoas desacreditam os modelos, por razões políticas.
    3. Pessoas confundem modelos com o que foi produzido por eles. Algo como considerar o BGP como sendo a MEF. Ou, mais simplesmente, como diz Scott, a árvore com a madeira.

Dependendo das ferramentas utilizadas, modelos podem ser complicados para entendermos. É o caso de modelos mais formais onde matemática e física são utilizadas. O próprio Scott6, exibe um formalismo para modelar o comportamento de redes, em geral, com aplicações na Internet, na sociologia, nas finanças e em muitas outras áreas do conhecimento. O formalismo matemático apresentado pelo Professor Scott é necessário para manter o rigor da modelagem e permitir a verificação do desempenho de um modelo usando ferramentas computacionais. As dificuldades podem ser vistas no que o eminente físico Richard Freynman disse para Leonard Mlodinow, [9, página 54]: …eu jamais deveria pensar que compreendi um trabalho de física se tudo o que fiz foi ler a prova de outra pessoa. A única maneira de realmente entender uma teoria, afirmou, é refazer a prova por conta própria – quem sabe você não acaba refutando a teroria? … No mesmo parágrafo, Mlodinow lembra, também, que um professor de Harvard, especializado em probabilidade e estatística disse, a propósito de dificuldades de pessoas e bons matemáticos não conseguirem identificar o erro em algo aparentemente óbvio: …Nosso crérebro não foi muito bem projetado para resover problemas de probabilidade. …

 

O problema de Monty Hall

 

Leonard Mlodinow, faz as citações acima no capítulo 3 do seu incrível livro, páginas 50-68: Encontrando o caminho em meio a um espaço de possibilidades. É a abordagem sobre um programa de televisão apresentado por Monty Hall (nos períodos de 1963-1976 e 1981-1991), uma famosa colunista chamada Marilyn vos Savant (maior QI já registrado no planeta, segundo o Guiness), o brilhante matemático Paul Erdös e uma imensa parcela do povo americano.

Se você ouvir o Scott E. Page falar sobre o problema das três portas de Monty Hall, e em seguida responder a um questionário, este poderá ser apenas uma tentativa. Isto porque, naquele momento você não está acostumado com a Lei do Espaço Amostral, lembrada inicialmente por Gerolamo Cardano, no século XVI. Vejamos o problema, as consequências para Marilyn e sua coluna “Ask Marylin”, Paul Erdös, um pedaço do povo americano e você, ao assistir a aula de Scott.

Com pequenas modificações, ao invés de portas, teremos três caixas de chapéus idênticas e indevassáveis (digamos, chapéus de inglesas abastadas). Elas são grandes o suficiente para caber, em uma delas, o roteador dos seus sonhos (valor em torno de $50,000.00). Nas outras duas caixas serão colocadas “switches” usados, que não necessariamente funcionam, cujo preço de novos está em torno de R$50,00, cada um (“hubs”, talvez). Como a Figura 1, que segue.

 

Figura 1. Três caixas de chapéus enormes, idênticas e indevassáveis. (Desenhadas pelo autor)

 

Se olharmos as caixas com visão de raios X teremos algo parecido com a Figura 2. Esta é a visão do apresentador, que sabe qual caixa contem roteador e quais as duas que contem os equipamentos usados. Este é um fato importante que qualifica o apresentador para interferir no processo da escolha feita pelo competidor (ou você).

 

Figura 2. Conteúdo das caixas de chapéus, vistas com visão de raios X. (Desenhadas pelo autor)

 

O esquema é o seguinte: Você escolhe uma caixa. O apresentador irá então interferir no processo, abrindo uma das caixas que contem um equipamento usado. A seguir ele lhe pergunta se você quer trocar ou não a sua escolha original. O que você deve fazer? Permanecer na caixa escolhida ou trocar de caixa (só tem mais uma para a troca). Em outras palavras, você tem duas caixas a escolher, o que significa que você tem 50% de ganhar o roteador. O que fazer? Continuar na escolha original ou trocar?

Fizeram a mesma pergunta no “AskMarilyn”. Marilyn afirmou em sua coluna que o melhor seria mudar a escolha! Marilyn recebeu cerca de 10.000 cartas reagindo contra sua posição de trocar a caixa original. Também, quase 1.000 matemáticos, aparentemente irados, com a posição de Marilyn. Paul Erdös, em particular, foi agressivo: “Impossível!”, afirmou ele. Foi tão brutal, o impacto que Marilyn parou de discutir o tema. Até que ficou provado que Marilyn estava correta. Paul Erdös só se convenceu depois de avaliar uma simulação feita por computador que mostrou a resposta correta de Marilyn, e admitiu estar errado. Na realidade, quando você tinha de escolher, inicialmente, uma das três caixas, sua chance de coincidir com a caixa do roteador era de 1/3. Mas, quando o apresentador interferiu no processo que era aleatório ele alterou o estado da probabilidade. Melhor dizendo, você sabe que uma das caixas (ela foi aberta!), portanto tem de escolher 2 entre três (2/3!). Dobrou a probabilidade de acertar! Então, troque, pois sua escolha inicial foi com a chance de 1/3! Leonard Mlodinow é perfeito na descrição do problema, no capítulo 3 de seu livro. O modelo (Oops, figura?) exibido na Figura 3 nos dá a noção precisa de nossas escolhas em cada uma das alternativas.

 

Figura 3. Esquema de Monty Hall (adaptado pelo autor)

 

 

Modelando uma conexão BGP

 

Quando estabelecemos uma rede interna, usando o TCP/IP, ou em outras palavras, usando IPv6 ou IPv4 (hoje estamos preferindo o IPv6), nosso cenário é como o da Figura 4. É necessário que nossa LAN (rede local) tenha um “gateway” que seja capaz de receber pacotes em IPv6 de algum equipamento de origem e os encaminhe de volta para a LAN, na direção do destino, na mesma LAN. Este modelo não é único, pois neste caso, o “gateway” pode ser um simples “switch”. Estamos colocando um “gateway”, no modelo, porque estamos enxergando a Internet, na qual deseja-se ardorosamente conectar. Tanto que a exibimos no modelo.

 

Figura 4. Modelo de uma LAN com expectativa de se ligar à Internet em futuro próximo.

 

Quando da decisão de se conectar à Internet, o primeiro passo é encontrar um operador de trânsito que seja membro da Internet. Em outras palavra, procurar por um operador de trânsito que seja um Sistema Autônomo (AS). Por ser um AS, o operador de trânsito poderá nos fornecer os IPv6 que precisamos para estabelecer nossas conexões à Internet. Nosso modelo ficará um pouco mais complexo, visto na Figura 5. Agora temos IPv6 para atender nossas expectativas e nosso “gateway” passa a ser um roteador, quem sabe o que ganhamos do Monty Hall… Para os equipamentos que estão na rede local, a rota “default”, isto é, a direção de pacotes que contem IPv6 que não são nossos, é o IPv6v, colocado na LAN de nosso roteador. Já pacotes com IPv6 desconhecidos do roteador serão encaminhados para a sua rota “default”, que é o IPv6a.

 

Figura 5. Modelo de uma conexão simples de uma rede à Internet.

 

O modelo da Figura 5 não está legal. Falta a ele capturar diversas informações importantes, que podemos enumerar:

  1. A LAN, passou a ser uma rede do operador de trânsito. Na realidade, embora a LAN não pertença ao operador de trânsito, os IPv6 pertencem a ele, partindo do pressuposto de que são IPv6 válidos.
  2. A LAN é cliente comercial do operador de trânsito. O operador de trânsito é um AS.
  3. O cliente comercial não é um Sistema Autônomo. É parte de um Sistema Autônomo.
  4. A conexão TCP estabelece um tráfego de pacotes para, e da Internet usando um protocolo que não é o BGP. Quem usa o BGP é o operador de trânsito.
  5. O cliente comercial é uma rede que está na Internet, via o operador de trânsito.

Como estamos usando um modelo gráfico e estático, muitas informações complementares devem ser descritivas. Porém, à medida que padronizarmos o modelo gráfico, menos descrições complementares serão necessárias. Padronizar, neste caso, envolve um cenário mais universal, no sentido de que a grande maioria dos envolvidos concordam com o que está sendo desenhado. Já existem propostas para isto. Os diagramas da UML (Unified Modeling Language), iniciativa da OMG (Object Management Group) é uma proposta de unificação de padrões, que não cobre somente a engenharia de software.

 

Figura 6. Refinamento do modelo, de uma conexão simples de uma rede à Internet.

 

A Figura 6 é uma proposta de modelo com um significativo refinamento ao da Figura 5. Ele nos traz muito mais informações do que o frágil modelo da Figura 5. Eis os pontos importantes exibidos no novo modelo, os quais dizemos que fazem parte do escopo do modelo:

  1. A Internet que ele está exibindo é a Internet IPv6. Hoje temos duas Internet. A outra é a Internet IPv4.
  2. O operador de trânsito em questão é um Sistema Autônomo. Ele possui um número de AS, no modelo representado por n, ou ASn.
  3. A Internet é um conjunto de ASes (nuvens em verde), incluindo o operador de trânsito.
  4. Está claro agora, que o cliente do operador de trânsito tem acesso à Internet, e que é membro da rede do operador de trânsito, pois ele não é um AS.

Há, também, coisas que o modelo não nos informa (são partes do que chamamos de não escopo), a saber:

  1. Não nos fala nada sobre a Internet IPv4. Fica apenas o registro da Internet IPv6.
  2. O modelo não identifica qualquer acordo entre o cliente e seu operador de trânsito.

O próximo modelo, finaliza nosso refinamento desta etapa, pressupondo de que o cliente passa a ser um AS. Está na figura 7, a seguir.

 

Figura 7. Modelo de uma conexão BGP nas duas Internet.

 

O comentários importantes sobre o modelo da Figura 7, são os seguintes:

  1. Retiramos a ideia de operador de trânsito. Temos agora, somente os ASes que, na realidade, fornecem tráfego através da Internet ou não. Tráfego é trânsito, ou transporte, ou “peering”, ou todos eles. Estas noções podem ser vistas em [10].
  2. As duas Internet estão transparentes. O ex-cliente, agora ASj é dono de seus próprios IPs. Como, geralmente, um AS tem IPv6 e IPv4, ele pode se conectar à Internet IPv6 e/ou IPv4, através de várias técnicas, uma das quais é a pilha dupla, que o modelo subentende.
  3. A ideia mais importante mostrada no modelo é a Conexão TCP. Antes de ser AS, o cliente tinha, também, uma conexão TCP. Agora, sendo AS, ele ativou o protocolo BGP, que só se viabiliza, se os “pares” tiverem uma conexão TCP, entre si.

 

Modelando o BGP

 

Na seção anterior, os modelos foram construídos para conexões BGP e não para o BGP propriamente dito. Já está claro que para uma conexão BGP funcionar, dois componentes são importantes: uma conexão TCP e a MEF do BGP. A MEF do BGP já é nossa conhecida. Sobre conexão TCP, muito pouco foi dito, até agora. A questão importante sobre conexão TCP é de que ela é estabelecida, usando-se soquetes. Um exemplo prático pode ser visto aqui no blogue3, onde soquetes foram usados para estabelecer uma conexão de telnet sob a ótica do paradigma cliente-servidor. Entretanto, já sabemos, também, que ao falarmos de BGP, a característica cliente-servidor desaparece. O mesmo acontece com a conexão TCP que dá suporte, ou que viabiliza o BGP. Isto nos leva a pensar da forma correta de que uma conexão TCP é estabelecida atrávés de um autômato finito ou MEF, também.

Falaremos sobre a MEF de uma conexão TCP em outro momento, mas podemos modelar o BGP conforme a Figura 8, que segue.

 

Figura 8. Modelo de uma conexão da MEF do BGP.

 

Eis as informações que nos interessam sobre o modelo acima:

  1. Os empareamentos são: ASi com ASj e ASj com ASk.
  2. O pré-requisito para iniciar uma conexão TCP é a existência de ligações físicas (camada L1), entre os empareados. Não interessa a extensão destas ligações.
  3. A MEF do TCP inicia o processo em entendimento entre os pares. Uma vez estabelecida a conexão TCP, o estado IDLE da MEF do BGP é acionado.
  4. A MEF do TCP mantêm a conexão TCP. Se ela cair, a conexão BGP cai e o processo começa novamente por ela, que no momento adequado aciona novamente o estado IDLE do BGP.
  5. Cada empareamento age de maneira independente. Se cair a conexão de um, o outro continua.
  6. Observa-se que, cada dia que passa, as conexões de camada física estão se tornando mais estáveis, apesar do preço cada vez mais baixo. Provavelmente, consequência da competição que está aumentando e a necessidade das operadoras (ou ASes) se tornarem mais eficientes. Um visível sintoma é o fato do Nic.br (no Brasil) já admitir que um AS possa ter somente uma conexão.

 

Conclusões

 

A MEFTCP é o mais importante para a proposta de OEP1. Da mesma forma que a MEFBGP, a qual ficará completa quando for analisado o mecanismo de mensagens do BGP.

A noção sobre modelos é apenas um princípio de como se pode tratar questões ligadas a implementação de BGP. O tratamento deve ser semelhante a um projeto. Os processos são as diversas etapas que seguem aquelas recomendadas a um projeto normal. Há requisitos, escopo e a implementação propriamente dita. Provedores de Internet, principalmente os pequenos sofrem na mão de grandes operadores. Se as propostas referente a um esquema mais profissional de implementação de projetos, quando se tratar de BGP, os ganhos serão enormes e podem, inclusive, admitir à ANATEL a criação de um mecanismo adequado para ela administrar sua função de vigilante das normas legais. Um exemplo é o uso de algo parecido com um Termo de Abertura do Projeto (TAP), criado especificamente para este fim. Sobre este assunto, isto é, a aplicação de metodologias e/ou técnicas de projetos sobre implementações de BGP, incluindo análise de topologias e outros protocolos associados (iBGP, OSPF, entre outros), oportunamente serão tratadas aqui neste blogue.

 

Referências

 

  1. Julião Braga. (Agosto 2012). Objetos de Projeto Estendidos (OPE). Disponível em: https://juliaobraga.wordpress.com/2012/08/22/objetos-de-projeto-estendidos-ope/. Acessado em 05/09/2012.
  2. Julião Braga. (Agosto 2012). Máquinas de estado finito: Parte Prática: MEF do BGP. Disponível em: https://juliaobraga.wordpress.com/category/projetos/gerenciamento-de-projetos/. Acessado em 05/09/2012.
  3. Julião Braga. (Março 2012). Soquetes: PHP, IPv6 e ‘inseguridade. Disponível em: https://juliaobraga.wordpress.com/2012/03/04/soquetes-em-php-ipv6/. Acessado em 05/09/2012.
  4. RFC4271, A Border Gateway Protocol 4 (BGP-4) Y. Rekhter, T. Li, S. Hares [ January 2006 ] (TXT = 222702) (Obsoletes RFC1771) (Updated-By RFC6286, RFC6608) (Status: DRAFT STANDARD) (Stream: IETF, Area: rtg, WG: idr). Acessado em 05/09/2012.
  5. Scott E. Page. Prologue The Card Catalogue. Disponível em: http://www.cscs.umich.edu/~spage/ONLINECOURSE/R1Page.pdf. Acessado em 09/09/2012.
  6. Scott E. Page, Lecture 23 Networks. July 28, 2006. Disponível em: http://www.cscs.umich.edu/~spage/teaching_files/modeling_lectures/MODEL5/M29networknotes.pdf. Acessado em 09/09/2012.
  7. Scott E. Page, The Difference: How the power of diversity creates better groups, firms, schools, and societies. Aug 11, 2008. Disponível em: http://pt.scribd.com/doc/82442356/Scott-E-Page. 424 p. Acessado em 09/09/2012.
  8. Stewart, J. W. III. BGP4: inter-domain routing in the Internet. Reading, Mass.: Addison Wesley, 1998.
  9. Leonard Mlodinow (1954). O andar do bêbado: como o acaso determina nossas vidas. Rio de Janeiro: Zahar, 2009. Tradução de Diego Alfaro.
  10. Julião Braga. (Março 2010). Tráfego, trânsito, transporte e peering (uma proposta de definição). Disponível em: https://juliaobraga.wordpress.com/2010/03/09/trafego-transito-transporte-e-peering/. Acessado em 10/09/2012.
Anúncios

Máquinas de estado finito: Parte Prática: MEF do BGP

 

Introdução

 

O foco deste blogue é a infraestrutura da Internet (II). Vez ou outra, um deslize ocorre resultando um texto inesperado e desconexo com a II. Geralmente, tais desvios decorrem de motivações que não estão claras nos textos mas que, eventualmente, serão esclarecidas.

Dada a justificativa, o texto atual está orientado a um dos componentes que irão fazer parte do projeto descrito em [3]. Trata-se da máquina de estado finito (MEF), base para o autômato finito presente na relação entre ROPEs (Repositórios de Objetos de Projeto Estendidos). Máquina de estado finito é um modelo que captura trecho de uma computação. Há definições melhores, e para avançarmos sobre elas veremos os aspectos práticos e teóricos relacionados.

A visão prática é a máquina de estado finito ou MEF, do BGP, já falada no blogue, mas sem os detalhes importantes de seu comportamento. A visão teórica será a representação formal da MEF do BGP à luz de uma modelagem aritmética apropriada, seguindo a sugestão de [6], página 443.

A descrição da MEF do BGP será um apanhado do que está descrito em alguns textos importantes. Stewart4, na página 31, item 2.1 tem uma descrição simples e didáticamente irrepreensível, como sempre. Ele avança, no item seguinte (2.2, página 33) para os tipos de mensagens do BGP. É imperdível, a leitura! White e outros5, na página 22 oferecem uma oportunidade de vislumbrar o MFE do BGP, em uma única figura, com tudo o que será descrito abaixo, sob a ótica prática (ou direta). Por fim, vale lembrar que a RFC42711 é, naturalmente, a referência definitiva e no item 8, página 37, ela lembra bem que a proposta é conceitual e não necessáriamente exige-se sua implementação ipsis literae. Mas, o autor não sabe informar se algum BGP (a.k.a., sua MEF) implementado em algum roteador disponível no mercado deixa de cumprir a especificação da RFC4271.

 

A MEF do BGP

 

A Figura 1, abaixo exibe uma representação da MEF do BGP. Na realidade, como veremos mais tarde esta MEF é um autômato finito representado por seis estados: Idle, Connect, Active, OpenSent, OpenConfirm e Established. O estado inicial do MEF é o Idle. Um estado muda para outro estado de acordo com a representação das setas (arcos ou arestas) identificadas por uma letra (de A a U), para facilitar o entendimento do MEF, na sequência.

 

Figura 1. Máquina de Estado Finito do BGP. Desenhado pelo autor com base no item 8.2.2 da RFC4271.

 

Existem 28 eventos que podem gerar transições na MEF do BGP, e eles estão enumeradas abaixo:

    1. ManualStart
    2. ManualStop
    3. AutomaticStart
    4. ManualStart_with_PassiveTcpEstablishmen
    5. AutomaticStart_with_PassiveTcpEstablishment
    6. AutomaticStart_with_DampPeerOscillations
    7. AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment
    8. AutomaticStop
    9. ConnectRetryTimer_Expires
    10. HoldTimer_Expires
    11. KeepaliveTimer_Expires
    12. DelayOpenTimer_Expires
    13. IdleHoldTimer_Expires
    14. TcpConnection_Valid
    15. Tcp_CR_Acked
    16. Tcp_CR_Invalid
    17. TcpConnectionConfirmed
    18. TcpConnectionFails
    19. BGPOpen
    20. BGPOpen with DelayOpenTimer running
    21. BGPHeaderErr
    22. BGPOpenMsgErr
    23. OpenCollisionDump
    24. NotifMsgVerErr
    25. NotifMsg
    26. KeepAliveMsg
    27. UpdateMsg
    28. UpdateMsgErr

Alguns destes eventos são opcionais, mas é pouco provável que alguma implementação de BGP deixe algum de fora. A descrição detalhada destes eventos estão na RFC42711, item 8.1 na página 38. Muitos destes eventos precisam de parâmetros, denominados atributos de sessão associados a eles. Existem dois tipos de atributos, os obrigatórios (ou mandatórios) e os opcionais. Os obrigatórios são:

      1. State
      2. ConnectRetryCounter
      3. ConnectRetryTimer
      4. ConnectRetryTime
      5. HoldTimer
      6. HoldTime
      7. KeepaliveTimer
      8. KeepaliveTime
      9.  

        O atributo state indica o estado corrente da MEF do BGP e o atributo ConnectRetryCounter indica o número de vezes que um BGP tentou estabelecer uma sessão com seu empareado. O restantes dos atributos obrigatórios estão escritos no item 10 da RFC42711. Os atributos opcionais são, continuando a sequência acima:

      10. AcceptConnectionsUnconfiguredPeers
      11. AllowAutomaticStart
      12. AllowAutomaticStop
      13. CollisionDetectEstablishedState
      14. DampPeerOscillations
      15. DelayOpen
      16. DelayOpenTime
      17. DelayOpenTimer
      18. IdleHoldTime
      19. IdleHoldTimer
      20. PassiveTcpEstablishment
      21. SendNOTIFICATIONwithoutOPEN
      22. TrackTcpState

Os atributos opcionais e as relações com os eventos estão descritos no item 8.1.1 e 8.2.1.3 da RFC42711.

Um exemplo de como os atributos estão associados a eventos é o evento 9, ConnectRetryTimer_Expires. Este evento ocorrerá (ou será gerado), se o atributo obrigatório 3, ConnectRetruTimer expirar.

 

O comportamento da MEF do BGP

 

A transição entre cada estado da MEF mostrada na Figura 1 é uma combinação do evento e de atributos a ele associados. A RFC42711, no item 8.2.2 descreve com detalhes refinados como ocorre a transição entre cada estado da MEF. Não entraremos em detalhes sobre a transição, por limitação de espaço e de foco. Entretanto daremos uma ideia geral do mecanismo, mostrando a transição do estado Connect para o estado OpenConfirm, através de L, pois esta transição é uma novidade em relação às RFCs anteriores, do BGP.

Suponha que o estado da MEF seja Connect. Se uma mensagem OPEN é recebida enquanto o evento 20 (BGPOpen with DelayOpenTimer running) está ativo no sistema local (MEF que estamos analisando), então ocorrerá o seguinte:

      • Se o processo sobre o atributo ConnectRetryTimer está ativo, então ele é parado e o ConnectRetryTimer (c) é zerado;
      • Completa a inicialização do BGP;
      • Para e zera o atributo DelayOpenTimer (p);
      • Envia uma mensagem OPEN;
      • Envia uma mensagem KEEPALIVE;
      • Se o valor inicial do atributo HoldTimer (e) não é zero, então:
        • Inicia o valor do atributo KeepaliveTimer (g) com o valor inicial e,
        • Restabeleça o atributo HoldTimer para o valor negociado;
      • Entretanto, se o valor inicial do atributo HoldTimer (e) é zero, então:
        • Restabeleça o atributo KeepaliveTimer (g) e,
        • Restabeleça o atributo HoldTimer (e) para zero;
      • Mude o estado para OpenConfirm

Então podemos dizer que L (transição do estado Connect para o estado OpenConfirm) será ativada, quanto o evento 20c,e,g,p ocorrer (dependendo de condições dos atributos apresentados nos índices superiores). É uma representação abstrata, cuja principal finalidade é a de exibir a transição, o evento e os atributos diretamente envolvidos. A abstração remove detalhes relevantes que a RFC4271 esclarece apropriadamente, razão pela qual a ela se deve recorrer para o comportamento completo da transição. Assim pensando, a Tabela 1 mostra as 21 transições (representadas pelas letras maiúsculas na Figura 1), os eventos envolvidos em cada uma e os atributos associados.

Arco Transição Eventos e atributos envolvidos
A Idle=>Idle 6m, 7m, 13m
B Idle=>Active 4b,c, 5b,c
C Active=>Active 16c,n, 17c,n
D Active=>OpenConfirm 20c,e,g,p
E OpenConfirm=>Established 26e
F Established=>Established 26e, 27e
G Established=>Idle 2b,c, 8b,c,m, 9b,c,m, 10b,c,e,m, 12b,c,m, 13b,c,m, 18b,c, 19b,c,l,m, 20b,c,m, 21b,c,m, 22b,c,m, 23b,c,l,m, 24b,c, 25b,c, 28b,c,m
H Idle=>Connect 1b,c, 3b,c
I Connect=>Idle 2b,c, 8b,d,m,p, 10b,d,m,p, 11b,d,m,p, 13b,d,m,p,18c,p, 19b,d,m,p, 21c,m,t, 23b,d,m,p, 24d,m,p, 25b,d,m,p, 26b,d,m,p, 27b,d,m,p, 28b,d,m,p
J Connect=>Connect 9c,p, 16c,n,p, 17c,n,p
K Connect=>OpenSent 12e, 16c,e,n, 17c,e,n
L Connect=>OpenConfirm 20c,e,g,p
M Connect=>Active 18c,p
N Active=>Connect 9c
O Active=>OpenSent 12c,p, 16c,e,n, 17c,e,n
P OpenSent=>Active 18c
Q OpenSent=>OpenConfirm 19e,g,p
R OpenSent=>Idle 2c, 8b,c,m, 9b,c,m, 10b,e,m, 11b,c,m, 12b,c,m, 13b,c,m, 20b,c,m, 21b,c,m, 22b,c,m, 23b,c,m, 24c, 25b,c,m, 26b,c,m, 27b,c,m, 28b,c,m
S OpenConfirm=>OpenConfirm 11g
T OpenConfirm=>Idle 2b,c, 8b,c,m, 9b,c,m, 10b,c,m, 12b,c,m, 13b,c,m, 14b,c,m, 16b,c,m, 17b,c,m, 18b,c, 19b,c,m, 20b,c,m, 21b,c, 22b,c, 23b,c,m, 25b,c, 27b,c,m, 28b,c,m
U Active=>Idle 2b,c,p,t, 8b,c,m, 10b,c,m, 11b,c,m, 13b,c,m, 18b,c,m, 19b,c,m, 21b,c,m,t, 22b,c,m,t, 23b,c,m, 24b,c,m,p, 25b,c,m, 26b,c,m, 27b,c,m, 28b,c,m
Tabela 1. Transições do MEF do BGP, eventos e atributos envolvidos.

 

Observações complementares

 

As RFC62867 e RFC66082 aparecem em Referências, por serem atualizações da RFC42711, sem interesse direto, no presente texto, embora sejam importantes na implementação do BGP e de sua MEF.

 

Referências

 

    1. RFC4271, A Border Gateway Protocol 4 (BGP-4) Y. Rekhter, T. Li, S. Hares [ January 2006 ] (TXT = 222702) (Obsoletes RFC1771) (Updated-By RFC6286, RFC6608) (Status: DRAFT STANDARD) (Stream: IETF, Area: rtg, WG: idr). Acessado em 26/08/2012.
    2. RFC6608, Subcodes for BGP Finite State Machine Error J. Dong, M. Chen, A. Suryanarayana [ May 2012 ] (TXT = 8612) (Updates RFC4271) (Status: PROPOSED STANDARD) (Stream: IETF, Area: rtg, WG: idr). Acessado em 26/08/2012.
    3. Julião Braga. (2012). Objetos de Projeto Estendidos (OPE). Disponível em: https://juliaobraga.wordpress.com/2012/08/22/objetos-de-projeto-estendidos-ope/. Acessado em 26/08/2012.
    4. Stewart, J. W. III. BGP4: inter-domain routing in the Internet. Reading, Mass.: Addison Wesley, 1998.
    5. White, R., McPherson, D., Sangli, S. Practical BGP. Boston, MA: Pearson, 2005. 434 p.
    6. Gersting, J. L. Fundamentos Matemáticos para a Ciência da Computação: um tratamento moderno de matemática discreta. Tradução: Valéria de Magalhães Iorio. Rio de Janeiro: LTC, 2008. PLT 166, Anhanguera Educacional S. A. 5a. edição, 597 p.
    7. 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). Acessado em 26/08/2012.

Meu ambiente de trabalho

Introdução

O tempo anda escasso, ultimamente. O de todo mundo, pelo que parece. Estou com dois artigos na agulha, um deles a continuação do último, sobre a conexão aos PTTs em IPv4 e IPv6. O outro é sobre um ano “quase” sabático, que me dei de presente, a partir de março de 2011. O ano “quase” sabático obrigou-me a preparar adequadamente o ambiente de trabalho. E vou descrevê-lo, por pura curiosidade, organização das idéias e reconher que, nas entrelinhas, será útil para muita gente. O bloque tem a vantagem de você escrever o que desejar para que leiam as pessoas que desejarem ler. No passado, chamávamos de “livre arbítrio”. Hoje seria mais prudente chamar de “escolha pessoal”. Geralmente, a “escolha pessoal” é baseada, EMHO, no conjunto de informações que um ser humano possui em sua cabeça, adquirida ao longo dos anos. Mas, o conjunto é complementado pela manipulação que o ser humano fez e faz, sistematicamente, do conhecimento adquirido. É uma questão um pouco mais complicada, pois vê-se, no dia-a-dia e na história, que este conjunto de conhecimento pode ser usado para o bem e para o mal.

O comentário da “escolha” aparece, a propósito de uma opinião que vi em um dos artigos do Silvio Meira onde, no debate alguém diz que uma pessoa é míope porque decide usar o Facebook. Em linhas gerais, justificou a miopia, pelo fato de que usar o Facebook está tornando mais rico o seu criador. É uma observação, a meu ver, sem propósito. Mas, trata-se de uma opinião. Não é possível preocupar-se com uma opinião (quando ela não é técnica), que você simplesmente não concorda. Minha escolha nestes casos é o da relevância. Se a opinião não técnica não for relevante ou não contribuir para o enriquecimento de minhas próximas escolhas, ignoro-a, no sentido de não participar do debate. Prefiro a visão shakesperiana: “A vida é uma simples sombra que passa (…); é uma história contada por um idiota, cheia de ruído e de furor e que nada significa”. Por outro lado, não acho que a história da miopia acima, qualifique um idiota. Pessoalmente, aperfeiçoei meu conhecimento, com a abordagem da opinião e na simples leitura. Sempre acontece, mesmo que inusitada.

Os recursos físicos

Tenho um “notebook” Dell Vostro 1320, com 8 GRam e um HD de 230 Gbytes. Localmente, tenho um “desktop” Intel Core 2 duo com 8 GRam e 2 HDs de 520 Gbytes. Remotamente, tenho uma outra máquina semelhante a este “desktop”. Para a Internet uso a Net com 10M de banda, que chega a 800 Kbps, medidos no SIMET do Nic.br. Para mim, a Net é uma provedora de serviços, no mínimo, irresponsável! Conectado à Net tenho um Mikrotik em uma máquina simples, com HD em “flash”, já há muitos anos.

No meu “notebook” tenho o Windows 7 Professional, em IPv4 e IPv6. O IPv6 é um túnel com a HE, que faço via anúncio de um /48 através do AS de minha empresa. Eventualmente, ativo uma VPN com um dos roteadores apropriados. Assim, consigo manter minhas configurações originais, onde estiver, em qualquer parte do mundo. Se não tenho Internet, mas há disponibilidade de celular, uso-a via meu iPhone. Complementarmente, tenho um “tablet” Samsung 8.1, que suporta alguns casos extremos e usado muito para leitura dos trabalhos em .pdf. Este conjunto de facilidades me satisfaz plenamente, no quesito de interconexão á Internet, que é o componente fundamental de trabalho e, via de regra, não me deixa ocioso, exceto quando for minha escolha. Fico ocioso, sempre, quando estou com meu neto querido.

As outras facilidade

Naturalmente, minhas maiores facilidades estão no “notebook”. Eis algumas delas:

  • Thunderbird: meu atual cliente de correio eletrônico. Não é meu preferido, infelizmente, mas dá para o gasto. Ele tem uma facilidade muito interessante que é o uso do PGP.
  • Browsers: Tenho quase todos, Chrome, Firefox, Explorer e Safari. Meu preferido é o Chrome. Antes era o Firefox, mas ultimamente com muitos problemas. Explorer só para alguns bancos, que não respeitam escolhas de seus clientes. Safari uso muito pouco, principalmente em testes de desenvolvimento.
  • Putty: minha principal ferramenta de ssh. É também, uma das mais importantes ferramentas de trabalho. Tenho outros, como o SCP, mas uso pouco.
  • Zope/Plone/Zeo: Uso pouco, no “notebook”. Somente para segurança de outros servidores, os quais uso muito.
  • Warftp: Insubstituível servidor de ftp. Entre outras funções ele é o principal componente de integração com o “tablet”. E, naturalmente, como integrador com os outros servidores.
  • PHPDesigner: Depois de muitos anos, há 5 uso-o preferencialmente. Está instalada, a versão 8. Não somente os programas em PHP, mas também, com editor de outras linguagens com C, Java e Perl, particularmente.
  • Wamp: Aplicação fantástica e simples, que implementa os servidores de MySQL, PHP, Apache em suas diversas versões, o que é muitíssimo útil.
  • Clientes para o MySQL: Tenho instalado o MuSQL Workbench, o MySQL Administrator e o MySQL-Front. Cada um com sua utilidade.
  • MikTex: Ferramenta preferida para os textos que preciso escrever em Latex. Ando me afastando um pouco do Latex e preferindo o Word. O Word é muito mais fácil para lidar, nos textos técnicos. O Latex é cansativo gerando muita perda de tempo na procura de compatibilidades. Mas, é insubstituível em alguns casos.
  • Office: Ótima ferramenta, pois domino-a. Além do Word sou usuário permanente do PowerPoint. Como não sou especialista em imagens, uso-o como intermediário para o aperfeiçoamento do que preciso, no Adobe Photoshop.
  • Adobe Photoshop: Para quem entende, deve ser uma maravilhosa ferramenta. Para mim resolve milhares de problemas relacionado com figuras, imagens, etc., que preciso no dia-a-dia.
  • eyeBean: Meu “softphone” preferido para testes e uso do FaleOK. Hoje tenho-o instalado no iPhone, também, e uso-o para receber e fazer chamadas via o FaleOK. Tenho números fixos em algumas cidades.
  • Wireshark: Eventualmente uso-o para avaliações e diagnósticos de problemas em redes. Pouca atividade, mas uma fantástica ferramenta, quando necessária.
  • Camtasia: Este e outros recursos estão associados a um Bamboo da Wacon, plugado em uma das USBs do “notebook”.
  • Enterprise Architect: Minha principal ferramenta de projetos e apoio ao desenvolvimento de idéias. Indescritível, os recursos disponíveis! É complexa e ao longo do tempo pode aperfeiçoar o uso.
  • FileZilla: Cliente preferido para ftp. Fica aberto o tempo todo no “notebook”.
  • Adobe Acrobat X: É um software de apoio. Usei-o muito quando meu orientador solicitou que os textos fossem feitos em Word e eu os fazia em Latex. Não entendi muito bem a razão dessa preferência já que existe hoje, o Adobe Reader X. Tal exigência, fez-me mudar em definitivo para o Word. No final, a mudança foi melhor e mais prática.
  • Skype: Há muito abandonei o MSN pelo Skype. Este é muito mais confortável e estável (pelo menos era, na época da escolha). Só uso o Skype para me comunicar com outros Skypes. Telefonia prefiro o FaleOK, muito mais flexível…
  • Segurança: Tenho vários anti-vírus e uso intensivamente o “firewall” do Windows 7.
  • VMWare: Ferramenta versátil e simples para criação de máquinas virtuais. Não fosse o VMWare não sei como poderia criar ambientes de testes, verificação de comportamento e integração (usualmente, em rede), de diferentes sistemas operacionais, tais como: Windows, Mikrotik, BSDs, Linux, etc. Cada um deles nas suas diversas versões.
  • CygWin: Ah! Grande achado! Tornou muito mais fácil lidar com o Windows, ao sair fora do “prompt”. Bem mais fácil!! Não se pode prescindir do CygWin, principalmente se você desenvolve com o apoio de “framework”, no Windows. Para se ter um exemplo, as duas figuras abaixo mostram o whois no CygWin e no Windows, respectivamente:

    Também, um recurso bastante valioso é o servidor sshd. Não tem preço!!

Finalmente, para ilustrar, eis a barra de tarefas do “notebook”:


Nos servidores local e remoto uso o FreeBSD (versão 9). Ambos possuem Apache2, MySQL5 e PHP5. Em ambos, como no “notebook” está instalado o Zope/Plone/Zeo. O Zeo admite perfeita integração entre os três, o que me deixa despreocupado em relação à segurança dos dados. No Plone local, mantenho toda e qualquer documentação de todos os servidores sob minha responsabilidade. Incluo todos os trabalhos em .pdf que mantenho em minha bibliografia no Word. Senhas (codificadas), IPs, v4 e v6 (uso a flecha para documentar), informações pessoais, agenda, etc., etc. O Plone é algo, também indescritível. Uso o Zope desde que ele apareceu pela primeira vez.

O servidor remoto tem um DNS escondido (Bind), que é “master” para um “master”, de um conjunto de outros servidores de dominio (autoritativos). Como recursivo, uso o Unbound no servidor local e em um outro servidor remoto.

Conclusão

O “notebook” tem suportado com altivez a demanda sobre ele. É claro que 16 GRam, no mínimo, com um processado I5 ou I7 seria o desejável. É o que provavelmente acontecerá em breve, espero. De resto estou muito feliz com meu ambiente, cuja foto parcial do local, segue abaixo!


Conectando-se a um PTT, em Mikrotik (IPv4 e IPv6)


Todos os infortúnios que vivi me tornaram um homem mais forte,
me ensinaram lições importantes. Aprendi a tolerar os medíocres;
afinal, Deus deve amá-los, porque fez vários deles.

ABRAHAM LINCOLN
16o presidente norte-americano
Prefácio Póstumo
Em “Oportunidades Disfarçadas”, Carlos Domingos.
Editora Sextante 2009

Introdução

O objetivo deste artigo é apresentar a experiência de conexão a um PTT (PTT Belém), através de um Mikrotik incluindo as preocupações, cuidados e o necessário planejamento para que isto seja feito.

Uma ótima referência para o que será dito aqui está em [1].

Planejamento

Os recursos e facilidades envolvidos na conexão e no entorno do PTT Belém são:

  1. Estado inicial.
  2. Conexão ao PTT, propriamente dita.
  3. Rede local, anúncios IPv4 e IPv6 para o PTT e empareados.
  4. Filtros
  5. Trânsito IPv4 via o PTT, em acordo bilateral com o fornecedor do trânsito.
  6. Trânsito IPv6 via Tunnel Broker
  7. Empareamento com o Team-Cymru, para receber “full bogon”, IPv4 e IPv6.
  8. Outras providências

O cenário fica mais claro com a Figura 1, com os comentários a seguir.

 

Figura 1. Cenário existente e projetado, no entorno do PTT Belém.

 

O comentários sobre a Figura 1 são:

  • Está sendo usada uma RB750 com versão 5.7 do Mikrotik. Há um trânsito (considerado como temporário) através da FAEPA. A Tabela 1 exibe o plano das 5 interfaces da RB750 e antecipa as VLANs que serão necessárias para os respectivos empareamentos IPv4 e IPv6. Também, a VLAN de trânsito com a FAEPA através do PTT, que irá substituir o trânsito estático através da interface 1, por um trânsito BGP.

     

    # Nome Tipo
    1 E1-FaepaTemp Ethernet1
    2 E2-PTTBelem Ethernet2
    3 E3-Disponivel Ethernet3
    4 E4-Disponivel4 Ethernet
    5 E5-Disponivel Ethernet5
    6 VLAN-PTTIPv4 VLAN
    7 VLAN-PTTIPv6 VLAN
    8 VLAN-TransitoIPv4-FAEPA VLAN
    9 HE Túnel 6to4

    Tabela 1. Interfaces atuais e projetadas.

  • Sabe-se que o administrador do PTT (aPTT) exigirá VLANs para a conexão no “switch” do PIX. Uma para cada protocolo (IPv4 e IPv6), para as quais ele informará o respectivo ID. Criamos as VLANs (#6 e #7, Tabela 1), na espera do ID. O aPTT irá nos enviar um ID inicial, para cada VLAN, que corresponderá ao período de quarentena (que pode durar até uns 10 dias, aproximadamente). Passado a quarentena e eventuais ajustes de interconexão, o aPTT nos enviará os IDs definitivos. Após a implementação definitiva solicitaremos ao aPTT o ID da VLAN de trânsito via o PTT Belém, tudo com conhecimento do parceiro de trânsito. O cenário com as duas VLANs iniciais pode ser visto conforme a Figura 2 abaixo.

     

    Figura 2. Cenário com as VLANs IPv4 e IPv6.

     

    Importante lembrar que as VLANs são possíveis porque a conexão do Mikrotik está, diretamente, com o “switch” do PIX, em L2 (muitas vezes vê-se, sem sucesso, tentativas usar VLANs em conexões não Ethernet). Na Figura 2, acima, as duas VLANs estão definidas sob a interface 2 do Mikrotik. Também, não se pode esquecer que o Mikrotik estabelece as VLANs em modo transparente (recomendado pelo aPTT). A Figura 3, abaixo, mostra a presença da VLAN para trânsito, criada sob a VLAN IPv4 (Q-in-Q). Neste momento, não estamos seguros se há ou não restrições nesta forma, e portanto, o melhor é confirmar com o aPTT.

     

    Figura 3. VLAN para trânsito via PTT.

     

  • A interface 2 da RB está conectada, como já foi dito, diretamente à porta do “switch” do PIX Faepa. Esta conexão é local, pois nossos servidores estão hospedados no centro de dados da Faepa. No mesmo centro de dados está localizado o PIX Central do PTT Belém. O material do José Eduardo, em [1] permite extrapolar a visão da topologia do PTT Belém.

Estado inicial

A Figura 4, na sequência, exibe o estado inicial da nossa topologia. O Mikrotik já foi configurado de acordo com a Tabela 1.

 

Figura 4. Configuração inicial.

 

O tráfego de trânsito será mantido por algum tempo, mesmo depois da interconexão com o PTT Belém.

Conexão ao PTT

As informações iniciais para conexão em um PTT está em http://sp.ptt.br/adesao.html. Mesmo que o PTT Metro escolhido ainda não esteja divulgado, mas sabe-se que está em fase final.

Dai para frente, siga a sequência das mensagens, e sempre que surgir alguma dúvida, não se acanhe a perguntar ao aPTT. Embora seja perceptível um alto grau de ocupação do pessoal do PTT, já usei o INOC-BR. Por outro lado, se já sabe o caminho das pedras, prepare-se do lado de cá. Já estabeleci um empareamento com o PTT-SP em menos de 5 dias. O PTT Belém, na oportunidade, em construção, levou uns 30 dias ou mais. Como já sabia, não tive pressa.

Rede local, mecanismos de acesso remoto e respectivos anúncios IPv4 e IPv6 para o PTT e empareados.

Para o Belém, o empareamento com a HE via “tunnel broker” levou menos de 15 minutos, pois já havia outro estabelecido. A HE permite até 5 túneis, a princípio. Anunciamos um /48.

O anúncio do IPv4 foi de um /23, pois haviam outros pontos de presença de nossa empresa. Para o PTT Belém o /23 foi dividido em dois /24 e para o trânsito externo (fora do PTT) será anunciado o /23. O trânsito externo é trânsito redundante, simplesmente. Foi incluída, nesta fase, uma interface de “loopback” IPv6, para túneis a serem construídos em futuro próximo. A seguir, as interfaces até o momento disponíveis:

Flags: D - dynamic, X - disabled, R - running, S - slave 
 #     NAME                    TYPE               MTU L2MTU  MAX-L2MTU
 0  R  E1-FaepaTemp            ether             1500  1526       1526
 1  R  E2-PTTBelem             ether             1500  1524       1524
 2     E3-Disponivel           ether             1500  1524       1524
 3     E4-Disponivel           ether             1500  1524       1524
 4     E5-Disponivel           ether             1500  1524       1524
 5  R  VLAN-PTTIPv4            vlan              1500  1520
 6  R  VLAN-PTTIPv6            vlan              1500  1520
 7  R  VLAN-TransitoIPv4-FAEPA vlan              1500  1516
 8  R  ;;; Hurricane Electric IPv6 Tunnel Broker
       HE                     sit               1280
 9  R  Loopback-IPv6-Interno  bridge            1500 65535

A interface de “loopback” em IPv6 pode ser construida, no Mikrotik, de várias maneiras. A recomendável é apresentada logo abaixo, onde o MAC administrativo utilizado foi: 01:01:01:01:01:01, pois a “loopback” exige-o. Se precisar de outro, usa-se os MACs do tipo: 02:02:02:02:02:02 e assim, sucessivamente.

/interface bridge add name=Loopback-IPv6-Interno auto-mac=no admin-mac=01:00:00:00:01:00
/ipv6 address add address=abcd:efgh::1/64 advertise=no interface=Loopback-IPv6-Interno

Percebe-se que do /48 anunciado separamos um /64 somente para “loopbacks”.

Filtros

Eis a listagem dos filtros, até o momento:

[admin@Belem] > routing filter print detail 
Flags: X - disabled 
 0   ;;; Route Server 1 IPv4
     chain=RS1-PTT-IPv4_in prefix=0.0.0.0/0 invert-match=no action=discard 
 1   chain=RS1-PTT-IPv4_out prefix=abc.def.0.0/24 invert-match=no action=accept 
 2   chain=RS1-PTT-IPv4_out prefix=abc.def.1.0/24 invert-match=no action=accept 
 3   chain=RS1-PTT-IPv4_out invert-match=no action=discard 
 4   ;;; Route Server 2 IPv4
     chain=RS2-PTT-IPv4_in prefix=0.0.0.0/0 invert-match=no action=discard 
 5   chain=RS2-PTT-IPv4_out prefix=abc.def.0.0/24 invert-match=no action=accept 
 6   chain=RS2-PTT-IPv4_out prefix=abc.def.1.0/24 invert-match=no action=accept 
 7   chain=RS2-PTT-IPv4_out invert-match=no action=discard 
 8   ;;; Route Server 1 IPv6
     chain=RS1-PTT-IPv6_in prefix=::/0 invert-match=no action=discard 
 9   chain=RS1-PTT-IPv6_out prefix=rstu:vxyz:1::/49 invert-match=no action=accept 
10   chain=RS1-PTT-IPv6_out prefix=rstu:vxyz:1:8000::/49 invert-match=no action=accept 
11   chain=RS1-PTT-IPv6_out invert-match=no action=discard 
12   ;;; Route Server 2 IPv6
     chain=RS2-PTT-IPv6_in prefix=::/0 invert-match=no action=discard 
13   chain=RS2-PTT-IPv6_out prefix=rstu:vxyz:1::/49 invert-match=no action=accept 
14   chain=RS2-PTT-IPv6_out prefix=rstu:vxyz:1:8000::/49 invert-match=no action=accept 
15   chain=RS2-PTT-IPv6_out invert-match=no action=discard 
16   ;;; LG IPv4
     chain=LG-PTT-IPv4_in invert-match=no action=discard 
17   chain=LG-PTT-IPv4_out invert-match=no action=accept 
18   ;;; LG IPv6
     chain=LG-PTT-IPv6_in invert-match=no action=discard 
19   chain=LG-PTT-IPv6_out invert-match=no action=accept 
20   ;;; HE Tunel Broker
     chain=Tunel-IPv6-HE_in prefix=::/0 invert-match=no action=discard 
21   chain=Tunel-IPv6-HE_out prefix=rstu:vxyz:1::/48 invert-match=yes action=discard

Comentários sobre os filtros:

  1. De 0 a 15 estão as regras para os dois “Route Servers” de cada protocolo (IPv4 e IPv6). Cada um com 4 regras: (a) não recebe rota default (e recebe tudo mais…); (b) encaminha o bloco desagregado (duas regras); (d) não envia mais nada.
  2. De 16 até 19, duas regras para cada LG: (a) não recebe nada; (b) envia tudo.
  3. De 20 a 21, duas regras para o “tunnel broker”: (a) não recebe rota default; (b) só anuncia o /48. Vale observar o “invert-match=yes” da regra 21 => descarta tudo, menos o /48.

Acordo bilateral de trânsito IPv4 via o PTT

Já foi solicitada a VLAN (tag) para o trânsito via o PTT. Assim que for implementado, as informações serão incluídas neste texto.

Trânsito IPv6 via Tunnel Broker

A referência para o “Tunnel Broker” com a Hurricane Eletric é http://tunnelbroker.net/. É gratuito e há o esquema de implementação para o Mikrotik, disponível no sítio.

Empareamento com o Team-Cymru, para receber “full bogon”, IPv4 e IPv6.

Os filtros não estão garantindo que IPs (v4 e v6), não estejam sendo encaminhados para o PTT, em particular, nas regras dos “Route Servers”. Existem duas soluções para isto:

  • Identificar, manualmente, os bogons no IRR ou outros locais. Construir uma lista de IPs (v4 e v6) e incluir as regras correspondentes. A complicação a a revisão destas listas, em particular, de cada um dos RIRs, pois IPs são liberados sem maiores avisos.
  • Mais confortável, estabelecer um empareamento com o Team-Cymru que enviará as listas atualizadas para serem encaminhadas ao “blackhole” do Mikrotik.

As informações do Team-Cymru, incluindo esquema de implementação no Mikrotik pode ser encontrada em http://www.team-cymru.org/, com muitas outras informações disponíveis. Como o Team-Cymru faz um ótimo trabalho e é de longe a melhor opção. A sugestão no sítio do Team-Cymru, para o Mikrotik é:

# Empareamento
/routing bgp peer add address-families=ip,ipv6 disabled=no in-filter=TeamCymru_in \
 instance=default multihop=yes name=TeamCymru1 out-filter=Teamcymru_out \
 remote-address=IPV4_INFORMADO_PELO_TEAM-CYMRU remote-as=65332 \
 tcp-md5-key=INFORMADO_PELO_TEAM-CYMRU

/routing bgp peer add address-families=ip,ipv6 disabled=no in-filter=TeamCymru_in \
 instance=default multihop=yes name=TeamCymru2 out-filter=Teamcymru_out \
 remote-address=IPV4_INFORMADO_PELO_TEAM-CYMRU remote-as=65332 \
 tcp-md5-key=INFORMADO_PELO_TEAM-CYMRU

# Filtros
/routing filter add action=accept bgp-communities=65332:888 \
 chain=TeamCymru_in comment="" disabled=no invert-match=no \
 set-type=blackhole
/routing filter add action=discard chain=TeamCymru_in comment="" \
 disabled=no invert-match=no
/routing filter add action=discard chain=TeamCymru_out comment="" \
 disabled=no invert-match=no

Eis os comentários e observações úteis sobre as sugestões acima:

  • São dois empareamentos (dois servidores, diferentes), para efeitos de redundância.
  • O empareamento é “multihop” e, com um ASN privativo(!).
  • Um BGP que fala com chave MD5, para adicionar segurança.
  • Os três filtros, na ordem: (a) recebe somente os IPs que chegam associados à comunidade 65332:888, do AS65332. O Team-Cymru diferencia o “full bogon” e o “tradicional bogon”, por comunidades. Todas as rotas que chegam associadas à comunidade 65332:888, são marcadas como “blackhole”. (b) Nada mais é recebido do empareamento com o AS65332. (c) Nada será enviado via o empareamento com o AS65332.
  • As rotas marcadas como “blackhole” são “silenciosamente” descartadas na FIB (uma das tabelas de roteamento), e portanto, nada mais precisa ser feito. As regras de descarte de rotas nas tabelas de roteamento são muitas e complexas para lembra a todo momento, mas podem ser estudadas com carinho, nas seguintes referências:
  • Após o estudo das referências acima, para adquirir mais intimidade com o BGP e sua incrível complexidade, que tal identificar uma outra forma de lidar com os bogons (ainda usando o Team-Cymru)? Por exemplo, sem marcar como “blakhole”? Uma dica: sem necessidade de filtrar a saída em cada empareamento.

 

Implementação

A Figura 5, que segue, mostra o estado dos empareados no nosso Mikrotik. Ainda não foi implementado o empareamento com o Team-Cymru. Portanto, ele não aparece, ainda.

 

Figura 5. Estado dos empareamentos.

 

A visibilidade externa ainda é pequena, mas já pode ser vista em aqui. Por exemplo, o empareamento multilateral com a RNP, no PTT-Belém e dois blocos IPv6, /48, anunciados nos empareamento de Belém e SJCampos.

 

Comentários Finais

A nova versão do Mikrotik está com quase todas as facilidades implementadas em IPv6. Isto significa que é possível deixar de usar o IPv4 nas interconexões inter AS e, também, intra ASes. E os acessos via SSH estão disponíveis a qualquer interface IPv6 (inclusive wireless), vantagem, neste caso para os ISPs. Nos próximos ensaios daremos preferência ao IPv6

Referências

[1] José Eduardo de Oliveira, PTT Metro, 03/01/2011, Disponível em http://www.ipv6.br/pub/IPV6/MenuIPv6CursoPresencial/introducao-ao-pttmetro.pdf. Acessado em 29/10/2011 08:08.

BGP no Mikrotik (IX): Filtros

Cada homem interpreta os limites do seu campo de visão
como sendo os limites do mundo.

Arthur Schopenhauer

 

Introdução

 

Naturalmente, filtros, neste texto são equivalentes a filtros no BGP, exclusivamente. Outra informação importante é de que todos os Mikrotiks foram atualizados na Versão 5.1.

Por outro lado, uma recomendação importante e pouco usada: ao se estabelecer empareamentos BGP, implemente primeiro os filtros, para depois estabelecer o empareamento propriamente dito. Porque? Porque se evitará de poluir a tabela de roteamento do roteador eliminando a necessidade de reinicializá-lo.

Para o que segue, iremos nos referenciar à Figura 1, abaixo, última topologia vista no artigo [Braga, 2011]1.

 

Figura 1: Empareamento independente do MK6 (AS65536) ao MK2 (AS65532).

 

Como filtrar no Mikrotik

 

Os exemplos preliminares de filtros concentrarão no componente MK8.6, da topologia mostrada na Figura 1, acima. Filtros do BGP no Mikrotik, são feitos no caminho mostrado na Figura 2, via Winbox.

 

Figura 2: Onde os filtros são feitos, no Mikrotik.

 

A janela “Route Filters” é onde estarão os filtros. Quando clicamos no “+”, aparece a janela de inclusão dos filtros, que possui 4 abas, vistas nas Figuras 3 e 4, que seguem.

 

Figura 3: Abas “Matches” e “BGP”

 

Figura 4: Abas “Actions” e “BGP Actions”

 

Como pode-se verificar são muitas as alternativas que giram em torno de Filtros, o que permite uma quantidade enorme de combinações. Na primeira aba, o parâmetro “Chain” deve indicar o que estamos filtrando. Os principais filtros estão associados ao emparemento que fazemos. A Figura 5 abaixo, exibe a maneira como indicamos, no empareamento, quais os filtros associados a ele, isto é, filtros de entrada e filtros de saída. A primeira parte da Figura 5 mostra o empareamento com o MK2, sem nenhuma indicação de filtros, enquanto que a segunda aba exibe o nome dados aos filtros de entrada e de saída, respectivamente, “MK2_entra” e “MK2_sai”. Uma vez salva, a aba “Matches” (Figura 3) irá mostrar estas duas identificações, no “Chain”.

 

Figura 5: Dando nomes aos filtros de entrada e saída, associados ao empareamento.

 

O estado atual do MK8.6

A listagem abaixo mostra o estado do MK8.6 em relação à tabela de rotas e aos anúncios que ele está fazendo.

[admin@MK8-6] > ip route print                  
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADb  10.201.0.0/23                      10.202.0.13        20 
 1 ADb  10.202.0.0/23                      10.202.0.13        20 
 2 ADC  10.202.0.12/30     10.202.0.14     MK2                0 
 3 ADb  10.203.0.0/23                      10.202.0.13        20
 4 ADb  10.204.0.0/23                      10.202.0.13        20
 5 ADb  10.205.0.0/23                      10.202.0.13        20
 6 ADb  10.206.0.0/23                      10.202.0.13        20
 7 ADb  10.207.0.0/23                      10.202.0.13        20
 8 ADb  10.226.0.0/24                      10.202.0.13        20
 9 ADb  10.226.1.0/24                      10.202.0.13        20 
10 ADC  10.236.0.1/32      10.236.0.1      LoopBack           0        
[admin@MK8-6] > routing bgp advertisements print
PEER     PREFIX               NEXTHOP          AS-PATH 
MK2      10.236.0.0/23        10.202.0.14 

 

Filtrando o recebimento de anúncios dos próprios blocos

 

Filtrar a entrada dos próprios blocos não faz muito sentido já que o mecanismo de prevenção de laços infinitos do BGP já faz isso e, que pode ser visto nas rotas do próprio MK8.6 e nos anúncios de MK2 para MK.6, mostrado na relação a seguir:

 

[admin@MK2] > routing bgp advertisements print peer=MK8.6 
PEER     PREFIX               NEXTHOP          AS-PATH
MK8.6    10.201.0.0/23        10.202.0.13      65531
MK8.6    10.206.0.0/23        10.202.0.13      65537,65536
MK8.6    10.204.0.0/23        10.202.0.13      65531,65534 
MK8.6    10.226.1.0/24        10.202.0.13      65537,65536
MK8.6    10.205.0.0/23        10.202.0.13      65531,65534,65535
MK8.6    10.207.0.0/23        10.202.0.13      65537
MK8.6    10.203.0.0/23        10.202.0.13      65533
MK8.6    10.226.0.0/24        10.202.0.13      65537,65536 
MK8.6    10.202.0.0/23        10.202.0.13

 

Entretando, volta e meia ouvimos: “Filtre seus blocos, na entrada!”. Para efeitos ditáticos, vamos fazer isso. A Figura 6 mostra como e os respectivos resultados mostrando, como foi inócuo tal filtro.

 

Figura 6: Filtro inócuo de entrada e os resultados.

Em 1 a indicação da existência do filtro, mostrando a “Chain” (MK2_entra), o bloco filtrado e a ação do filtro (“discard”). Em 2 e 3, as abas do filtro, como foram preenchidas. Em 4, a tela do terminal, listando os resultados para efeitos de comparação.

Outro filtro importante de entrada é não deixar entrar a rota padrão, embora possa ver que MK2, único vizinho de MK8.6, não anuncia a rota padrão. Esta decisão é do administrador do MK8.6. Um bom administrador vê que isso não precisa ser feito. Mas, o administrador do MK2 pode, involuntariamente, anunciar a rota padrão. Copiando o primeiro filtro e alterando somente o bloco para 0.0.0.0/0, temos o resultado da Figura 7.

 

Figura 7: Filtrando a rota padrão, na entrada.

 

Filtrando a saída

 

A recomendação é de imediato: somente deixe passar os blocos que serão anunciados. Isso inclui o bloqueio da rota padrão, para que não haja efeitos involuntários. Mesmo que a rota padrão não esteja sendo usada, como é o caso do MK8.6 (ela pode vir a ser usada a qualquer momento). Antes de fazer este bloqueio, vamos confirmar o funcionamento de filtros, pois não vimos isso ainda. Se fizermos o bloqueio do bloco do MK8.6, ilustramos o fato. Vejamos na Figura 8, onde uma nova cópia do primeiro filtro é suficiente, desde que mudemos a “Chain”.

 

Figura 8: Filtrando a saída do próprio bloco.

 

O bloco não aparece mais na listagem de anúncios, mostrado no terminal, abaixo da janela de filtros. Então, funciona! Mas este filtro não interessa, exceto pelo efeito didático. Na realidade, tal filtro é indevido, pois impede a divulgação mais importante e desejada pelo administrador do MK8.6! Vamos então ao que interessa, bloqueando a rota padrão e tudo mais, exceto o bloco que MK8.6 quer anunciar. A técnica no Mikrotik é bloquear tudo, menos o bloco a ser anunciado. Na Figura 9, mostra o resultado, usando o próprio bloqueio de efeito didático. Um parâmetro na primeira aba do filtro, chamado de ‘Invert Matcher”, faz este trabalho. Como o bloco está com a ação “discard”, o Mikrotik irá bloquear tudo, menos o bloco definido em “Prefix”. Assim, até a rota padrão foi bloqueada!

 

Figura 9: Filtrando tudo, menos o bloco que se deseja anunciar.

 

Uma outra maneira de fazer isso é usando três filtros: o primeiro bloqueia a rota padrão, o segundo libera o bloco e o terceiro, bloqueia todo o resto (sem especificar qualquer coisa no campo Prefix.

 

Controlando os anúncios com o Networks

 

Uma questão a lembrar é o uso do Prefix Length nos filtros que juntamente com o “Networks”, flexibiliza as regras de filtragem.

Suponha que o AS tenha um bloco IPv4, /20 (Por exemplo, x.y.n.0/20). E que no Networks inclua-se somente um /24 (ex. x.y.zj.0/20, n <= j <= n+15), pois é o que se deseja anunciar em uma determinada conexão BGP. Então, o filtro abaixo, garante que somente o /24 será anunciado:

Prefix => x.y.n.0/20
Prefix Length => 20-24

Se, entretanto, o Prefix Length não for utilizado, todo o bloco /20 será anunciado e ele deverá estar representado no Networks. A variedade de alternativas implica na necessidade de se planejar os filtros com esmerado cuidado.

Vale lembrar que o BGP de trânsito (ou de transporte) deverá ter a opção Redistribute Other BGP, marcada em Instances (também, distribui prefixos entre instâncias). Em todos os seus empareamentos, o Nexthop Choice deve ser force self evitando um grave erro. Em anúncios de terceiros, para um PTT, o Next-Hop estará errado ao indicar o IP do roteador do consumidor de trânsito (ou de transporte) e, não o do roteador que oferece o trânsito (ou o transporte), como seria o correto. Neste caso, a punição pode ser a desconexão com o ATM (o pessoal do PTT.br avisa antes…). Finalmente, deve-se lembrar que o Client to Client Reflection, ainda em Instances, distribui prefixos entre os membros (empareados), de uma mesma instância.

Há algumas variações sobre a questão do force self. Basicamente ele se aplica somente ao último empareado do trânsito (ou do transporte). Muito embora, se existe roteadores intermediários, o correto é que cada um deles passe o Next-Hop de forma correta. Isto implica em uma aparente regra: sempre use o force self. E teste, quando no PTT, via o LG. Quando em um trânsito somente, faça um traceroute de fora, via um outro LG qualquer e veja o estado do caminho.

 

Assuntos relacionados, neste blogue

 

  1. BGP no Mikrotik: Dois operadores de trânsito. Versão anterior a este artigo.
  2. BGP em Mikrotik – Parte I
  3. BGP em Mikrotik – Parte II
  4. BGP em Mikrotik – Parte III
  5. BGP no Mikrotik (IV): Anúncios e rotas no FFE
  6. BGP no Mikrotik (V): Analisando anúncios de implementações de BGP
  7. BGP no Mikrotik (VI): Estabelecendo enlaces (rotas) backup
  8. BGP no Mikrotik (VII): Mesmo AS em empareamentos remotos e independentes
  9. BGP no Mikrotik (VIII): Alterando a política de roteamento
  10. Atributos do BGP
  11. BGP: Tabelas de roteamento
  12. Convergência, no BGP
  13. A Seta IPv6: Preparando para trabalhar com IPv6 no Mikrotik
  14. Conectando-se a um PTT, em Mikrotik (IPv4 e IPv6)
  15. BGP: topologias, abstrações, eBGP e iBGP (Parte 1)

 

Referências

 

  1. Braga, J., BGP no Mikrotik (VII): Mesmo AS em empareamentos remotos e independentes. Infraestrutura da Internet. 2011. Disponível em: https://juliaobraga.wordpress.com/2011/04/04/bgp-no-mikrotik-vii-mesmo-as-em-empareamentos-remotos-e-independentes/. Acessado em 15/04/2011 11:13.
Categorias:BGP, Mikrotik, Protocolos, TCP/IP

BGP em Mikrotik – Parte III

Há duas possibilidades:
Se o resultado confirma a hipótese, então você fez uma medição.
Se o resultado for contrário à hipótese, então você fez uma descoberta.
Enrico Fermi, físico e prêmio Nobel (1901-1954)

Introdução

O MK3 andou preocupado com a sua conexão com a Internet via MK2. Completa ausência de redundância. Trânsito é mais barato, via MK2, mas não suficientemente confiável. Não propriamente, por MK2, mas pelos dois enlaces até MK1. Então, MK3 resolveu negociar trânsito com MK1 (uma banda menor, talvez) e assim agregar valor ao seu serviço. Isso que MK3 fez chama-se inovação de valor. A Figura 1, abaixo, exibe a conexão desejada por MK3 e a inserção de uma interface Loopback em cada MKi, para i=1, …, 7. Servirá para exercícios, principalmente de conectividade.

 

Figura 1: A alternativa do MK3 para preservar a confiabilidade do trânsito para seus Clientes e interfaces Loopback em cada MKi.

 

Conectando MP3 a MP1, via Loopback.

Essa é uma alternativa ilustrativa somente. Primeiro porque é possível uma conexão, em BGP, via Loopback por haver acessibilidade. Segundo, não é uma conexão que resolve os interesses de MK3 sob o ponto de vista da confiabilidade do trânsito. Uma conexão via Loopback manterá o mesmo risco, pois o tráfego de trânsito segue o mesmo caminho dos BGPs construídos entre MK3, MK2 e MK1.

Mas, o interesse didático insiste no BGP via Loopback. Antecipando alguns problemas, vamos lembrar sobre os 6 estados que o BGP assume, para tomar decisões sobre suas operações. São eles: Idle, Connect, Active, OpenSent, OpenConfirm e Established. Tudo está explicado na RFC42711, a partir do item 8, e não repetiremos aqui, exceto o esquema da Máquina de Estado Finito (MEF), que o BGP usa para transitar entre seus diversos estados, durante o processo de entendimento com seus pares. O esquema está na Figura 2, e não é muito comum ver uma versão atualizada da MEF do BGP.

 

Figura 2: Autômato finito do BGP (desenhado pelo autor).

 

Vamos então usar o mesmo esquema para estabelecer a sessão BGP entre MK3 e MK1, via Loopback. Eis o resultado na Figura 3.

 

Figura 3: BGP via Loopback entre MK3 e MK1.

 

O estado (State) tanto no MK1 como no MK3, está active. Recorrendo à Figura 2 e à referência [1], podemos reconhecer alguma pista sobre porque o estado final, Established, não foi atingido. Os problemas que estão fazendo com que o BGP retorne insistemente ao estado active, podem ser:

  1. Porta TCP 179 não está aberta
  2. Portas TCP, randômicas, acima de 1023 não estão abertas
  3. Configuração errada do BGP
  4. Instabilidade da interface de rede

Podemos descartar (1) e (2), pois não há firewall, nem em MK1 e nem em MK3. Podemos, também eliminar o item (4), já que usamos uma interface Loopback e, uma de suas vantagens é a de não produzir instabilidades. Além do mais, o BGP de MK1 para MK2 está Established. O mesmo acontece com o BGP de MK2 para MK3. Então, só nos resta o item (3): Configuração errada do BGP!! Essa é a alternativa mais difícil pois depende de prática. Mas, nesse caso o erro é bem comum e ocorreu por provocação didática. Temos um caso típico de uma sessão BGP entre dois pares não diretamente conectados! Tal fato é visível, pois os IPs das respectivas Loopbacks estão em redes diferentes (não conectadas diretamente), apesar de acessíveis entre si. Em outras palavras, temos um BGP multi-hop. Então podemos alterar a configuração dos MK1 e MK2. Após a inclusão do Multi-hop, o problema ainda não fica resolvido e os estados do BGP ficam trocando entre Idle, Active e OpenSent. A presença do estado Active, em nosso cenário, induz ao fato de que continua havendo um erro na nossa configuração BGP. Não é uma falha tão óbvia, como a do Multi-hop. Uma olhada nos possíveis problemas quando o estado OpenSent aparece, não ajuda a posição de quem não tem muita experiência em BGP. Mas vejamos as indicações expostas em [2]:

  1. O autômato do BGP está aguardando uma mensagem de Open de seu par
  2. Recebida a mensagem de Open, o roteador verifica a sua validade
  3. Se há um erro, um dos campos da mensagem de Open é incompatível entre os pares (versão do BGP, senha MD5 incompatível, informação de AS incompatível). O fato é que o roteador envia uma mensagem para o par, indicando o erro.
  4. Não há erro. Uma mensagem de Keepalive é enviada várias vezes e o estado é alterado para OpenConfirm

Em uma reflexão simplista podemos eliminar o item (4), pois não recebemos indicação de mudança de estado para OpenConfirm. Podemos ir em Logging e incluir uma opção de mensagens vindas do BGP. Veremos quase nenhuma indicação para nos auxiliar. Melhor alternativa talvez seja ir no Google e procurar por três palavras “bgp loopback opensent”. A referência da Cisco, na Parte I, desse tópico, também mostra a solução. Quando usamos Loopback para estabelecer um empareamento BGP é necessário forçar o BGP a usar a interface Loopback. Isso é feito com o recurso Update-source, na aba Advanced do BGP Peer, como nos mostra a Figura 4, logo abaixo.

 

Figura 4: Forçando o BGP a usar a Loopback.

 

BGP direto entre o MK1 e o MK3

Iremos supor que a Figura 1 está agora com o BGP entre MK1 e MK2, usando o bloco passado pelo MK1: 10.201.0.14/30 e assim daremos a continuidade na parte IV, onde veremos as bases iniciais do longo debate sobre filtros, em BGP. Então, a Figura 5 mostra essa configuração final de nossos membros da FFE.

 

Figura 5: Configuração final da FFE.

 

Conclusão da Parte III

A FFE sempre irá representar topologias que estão na mesma rede. Mesmo que estejamos criando interfaces com IPs de redes diferentes, como foi o caso do exemplo da Loopback. Basta simplesmente nos abstrair desse fato, que tudo irá parecer como sendo roteadores interconectados remotamente.

Outra questão muito importante é que quando nos expressamos com a palavra BGP, com foi feito até o presente momento, a referência é exclusiva ao eBGP. Quem está acostumado com Cisco, verá que os comandos sempre conterão ebgp. Quando fizermos abordagens a iBGP não deixaremos o contexto nos confundir. Por outro lado, em iBGP os ASNs dos pares são sempre os mesmos.

 

Referências

  1. RFC4271, A Border Gateway Protocol 4 (BGP-4) Y. Rekhter, T. Li, S. Hares [ January 2006 ] (TXT = 222702) (Obsoletes RFC1771) (Updated-By RFC6286, RFC6608) (Status: DRAFT STANDARD) (Stream: IETF, Area: rtg, WG: idr). Acessado em 26/08/2012.
  2. Wikipedia, Border Gateway Protocol. Disponível em: http://en.wikipedia.org/wiki/Border_Gateway_Protocol. Acessado em 08/03/2011.

Categorias:BGP, Mikrotik, Protocolos, TCP/IP

Convergência, no BGP

Introdução

Convergência é um problema relacionado com o tempo em que toda uma rede se estabiliza após a ocorrência de um evento qualquer. Rede no contexto desse artigo é, a Internet.

Sabemos que logo na infância da Internet, ela foi dividida em sub-redes não isoladas, cada uma identificada e denominada Sistema Autônomo (AS, de Autonomous System). O objetivo foi o de facilitar a entrega de pacotes ou o roteamento dos pacotes da origem para o destino. Pouco tempo depois, foi criado um protocolo, conhecido por todos nós, o BGP (Border Gateway Protocol) com o objetivo de facilitar o mecanismo de roteamento entre os ASes (nos livrar do processo manual de estabelecer as rotas estáticas. O BGP, em sua versão original mostrou-se frágil diante da velocidade do crescimento da a Internet e antes dela se tornar de uso geral ou “comercial” (em 1993), já havia uma nova versão do BGP na praça: o BGP-4. Interessante lembrar, um fato histórico: o AS veio antes do BGP!

O BGP-4, apesar de ser um protocolo robusto começou a apresentar algumas deficiências de origem. Uma delas, impossível de solucionar sem alterações radicais é a sua estratégia de roteamento: hop-by-hop. De uma forma simples, no BGP, um parceiro (“peer”) só sabe o que acontece na Internet através de seus vizinhos imediatos. Parceiro nesse caso é um AS e, tambem, os vizinhos o são. Vamos imaginar o tamanho da Internet e, por razões de simplicidade, usar a Figura 1 para modelar a Internet. A Figura 1 foi retirada do artigo de Russ WhiteWhite, escrito em 2005, com o objetivo de propor uma solução para a questão do tempo de convergência do BGP-4 sob a ótica da estratégia hop-by-hop.

Exemplo de convegência no BGP

Figura 1. Ilustração do problema da convergência no BGPWhite

O problema da convergência

Na figura de Russ White os números dentro dos círculos representam ASes, de 1 a 12. A figura representa uma pequena rede de 12 ASes deve ser extrapolada para a Internet, com mais de 35.000 ASes (isto é, nós como os da pequena figura). A escolha da figura do trabalho de Russ White é simplesmente uma aplicação da navalha de OccamOccam. É de uma genialidade e simplicidade sem igual.

Na figura, vamos supor que o AS12 anuncia o bloco 10.1.1.0/24. Se AS12 anuncia esse bloco, ele é o único na rede que sabe como atingí-lo. Assim, o AS1 para enviar um pacote para um IP do bloco 10.1.1.0/24, o caminho deve seguir a direção do AS12. Vamos supor que AS1 atinja o bloco, com o menor caminho [AS6, AS12]. Muito embora, na tabela de roteamento de AS1, esteja a informação de que ele poderia enviar pelo caminho [AS2, AS9, AS12], por exemplo. A escolha pode não ser pelo menor caminho. Há vários parâmetros que podem afetar a escolhaCisco. Lembramos que caminho é o mesmo que ASPath, no BGP.

Eis um problema de convergência: suponha que o AS12 pare de anunciar o bloco 10.1.1.0/24, subitamente. Como AS12 era o único que sabia onde chegar aos IPs do bloco fatídico, o que ocorre com as informações na tabela de roteamento de AS1? Ops! O que acontece na Internet, quando ocorre uma falha dessa natureza?

Analisando o problema da convergência

Na tabela que segue, vamos exibir o caminho escolhido (escolha arbritrária!), por cada AS para chegar ao bloco 10.1.1.0/24:

AS Caminho
AS1 [AS6, AS12]
AS2 [AS9, AS12]
AS3 [AS7, AS10, AS12]
AS4 [AS5, AS8, AS11, AS12]
AS5 [AS8, AS11, AS12]
AS6 [AS12]
AS7 [AS10, AS12]
AS8 [AS11, AS12]
AS9 [AS12]
AS10 [AS12]
AS11 [AS12]

Vamos supor que AS12 não saiba mais como chegar ao bloco 10.1.1.0/24. O AS12 envia uma mensagem BGP para todos seus vizinhos, AS6, AS9, AS10 e AS11 retirarem o referido anúncio. Esses vizinhos, imeditatamente avisam seus respectivos vizinhos para retirarem o anúncio do bloco 10.1.1.0/24. No mesmo momento, recebem essa mensagem: AS1, AS2, AS7 e AS8. Então, AS1, ao receber seu primeiro pedido de retirada do bloco, analisa sua tabela de rotas locais e procura pelo próximo melhor caminho. Como ele não recebeu ainda nenhuma mensagem de retirada do AS2, ele muda a tabela para o outro caminho, digamos [AS3, AS7, AS10, AS12] e continua a enviar pacotes para o bloco 10.1.1.0/24.

Nesse momento, AS2, AS7 e AS8 enviam mensagens de retirada para seus parceiros vizinhos: AS1, AS3 e AS5. AS1 recebe uma nova mensagem de retirada e procura outra rota continuando a enviar tráfego para o bloco 10.1.1.0/24, pois ele tem uma outra rota, [AS3, AS7, AS12] já que seu vizinho AS3 não lhe disse nada.

Na sequência, AS3 e AS5 pedem a retirada a seus vizinhos, AS1 e AS4. E, AS1, novamente altera sua tabela, descobrindo outro caminho, [AS4,AS5,AS8,AS11,AS12] e encaminha pacotes para o bloco 10.1.1.0/24, sem saber que AS4 acabou de receber a mensagem de retirada.

Finalmente, AS4 envia a mensagem de retirada a AS1 que agora remove a última informação sobre como chegar ao bloco 10.1.1.0/24. Então para de encaminhar pacotes para esse bloco. Finalmente! Nesse ponto, a pequena rede converge. Ops! Queríamos dizer, a Internet, presumivelmente, converge.

Conclusões e Atualizações

Assim funciona o esquema da convergência do BGP. De tempos em tempos aparecem recomendações para alterações no BGP que são aceitas e virão na próxima versão. Como por exemplo, a sugestão que motiva o artigo de Russ White, onde ele recomendou que quando o AS1 recebesse a primeira mensagem de retirada, do seu vizinho AS6, ele pesquisaria toda a sua tabela de rotas, localmente e retiraria as referências ao bloco 10.1.1.0/24, evitando tráfego inútil.

Algum tempo depois de escrito esse pequeno artigo, encontrei uma referência bem mais completa na Internet Lapukhov, que recomendo aos interessados.

Em 14/02/2011, Vasco Asturiano fez um experimento e exibiu alguns gráficos relacionados com a convergência do BGP quando se anunciava e retirava o anúncio de um prefixo Asturiano. Muito interessante o artigo, onde ele conclui que é mais fácil (~rápido), para o BGP, a convergência quando se anuncia um prefixo, do que a convergência quando se retira o anúncio de um prefixo.

Em 19/07/2013, Randy Busch escreveu um curto e-mail na lista, com algumas frase interessantes, entre as quais: “global bgp never converges (and how would you know if it did?)“. Lembrando-me deste artigo e a última frase no final da seção anterior, onde dizia que a “…a Internet, presumivelmente, converge” escrevi um e-mail para Randy dizendo-lhe que achei muito interessante a sua frase. Gentilmente, ele retornou-me com a indicação do artigo [Roughan, Willinger, Maennel, Perouli & Bush]. É um texto imperdível! Com uma imensa referência, cito abaixo o último parágrafo, com a promessa de brevemente fazer uma resenha aqui no blogue:

The lessons of this paper will hopefully form a checklist for any student or new researcher in this area that will enable them to avoid the pitfalls which have reduced the value of some past research. Simply stated, to ensure value of future research in this area, any work on the structure and evolution of the Internet’s Autonomous System has to account for the economic, technological, and social forces that shape this critical element of the Internet.

Referências

White, Russ, Graph Overlays on Path Vector: A Possible Next Step in BGP, The Internet Protocol Journal, Volume 8, Number 2, Junho 2005. Disponível em http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_8-2/graph_overlays.html. Acessado em: 20/01/2011.

Wikipedia, Navalha de Occam. Disponível em http://pt.wikipedia.org/wiki/Navalha_de_Occam. Acessado em: 20/01/2011.

Cisco, BGP Best Path Selection Algorithm. Disponível em: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml#bestpath. Acessado em: 27/01/2011.

Petr Lapukhov, Understanding BGP Convergence. Disponível em: http://blog.ine.com/2010/11/22/understanding-bgp-convergence/. Acessado em: 27/01/2011.

Vasco Asturiano, The Shape of a BGP Update. Disponível em: http://labs.ripe.net/Members/vastur/the-shape-of-a-bgp-update. Acessado em: 14/02/2011.

Matthew Roughan, Walter Willinger, Olaf Maennel, Debbie Perouli, and Randy Bush. 10 Lessons from 10 Years of Measuring and Modeling the Internet’s Autonomous Systems. IEEE Journal on Selected Areas in Communications, Vol. 29, No. 9, October 2011.

Categorias:BGP, Peering, Protocolos, TCP/IP