Arquivo

Archive for the ‘BGP’ 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

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.

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.

Objetos de Projeto Estendidos (OPE)

When knowledge is involved,
it is best to bring the Internet to the user,
instead of taking the user to Internet.

 

Uma dificuldade na Infraestrutura da Internet

 

Em tudo o que tem sido escrito sobre BGP neste blogue há sempre uma observação persistente: BGP é complexo. Na realidade, a complexidade do BGP está na sua abrangência e sua perspectiva de mudar constantemente. Mas, há outro componente importante quando se deseja implementar o BGP em roteadores de borda: a topologia.

Vamos a um exemplo. Recentemente, um Provedor consultou-me sobre uma topologia com três (3) trânsitos: dois com uma operadora A e um terceiro com a operadora B. A topologia parecia ser a mostrada na Figura 1, abaixo.

 

Figura 1. Três trânsitos sendo dois com a mesma operadora.

 

Este texto não propõe a implementação da topologia acima, com o BGP. Ele trata de outro assunto, correlato. Entretanto, vou dar algumas dicas sobre a implementação. Até aquele momento, nunca tinha passado por experiência semelhante. Ao entrar no roteador do Provedor foi curioso observar o fato de que a operadora A recomendou que se estabelecesse dois empareamentos com cada um de seus enlaces de trânsito: um com a tabela de roteamento completa e outro com tabela de roteamento parcial. Incluindo o empareamento da Operadora B haviam cinco sessões BGP ativas. O roteador estava em produção e alguns comportamentos ruins eram incompreensíveis. A primeira visão da implementação, sempre segue o instinto (da suposta experiência): (a) a Operadora A entende mais do que qualquer um e, (b) um ajuste nos filtros poderia resolver o comportamento ruim (abstraindo-se do fato do BGP ser complexo). Duas premissas completamente equivocadas. Revendo a presunção inicial, observou-se que, na realidade havia uma novidade na topologia: dois trânsitos com a mesma operadora. Google, eis a saída! Nesta hora é que você vê como o Google cansa!!! Depois de algum tempo, a luz no final do túnel veio com a RFC22701. Esta RFC, de 1998 é um pouco confusa, pois trata de topologias bem mais simples sem as variações possíveis do futuro atual. Por exemplo, a topologia poderia não ser a da Figura 1, exatamente. Em outras palavras, o trânsito poderia estar vindo através de um único roteador da Operadora A, ou chegando em uma única porta do roteador do Provedor. Ou ainda, alguma outra variação do tema. No Google, eficaz sintáticamente, infelizmente não consegue interpretar a semântica, ainda. Quem propõe a solução para implementar BGP em uma topologia destas é o primeiro autor da RFC2270, J. Stewart. No romance do BGP, escrito por ele2, Capítulo 3 há uma completa descrição de todos os comportamentos do BGP em casos como estes, incluindo balanceamento. Em particular, a Fig. 3.2, na página 78, Stewart explica em detalhes um multi-homed com uma mesma operadora, de forma didática!

Mas o erro mais grave da dúvida produzida pela topologia da Figura 1 é que, ao lidarmos com o BGP associado a uma topologia qualquer, não é por hábito fazer um projeto, minimamente cuidadoso, que permita o entendimento do comportamento esperado. Em outras palavras, não se pensa sobre o problema. Isto tem acontecido sistematicamente com os pequenos e médios provedores. Por outro lado, observa-se que a falta de pensar e/ou a falta de projeto são recorrentes, mesmo tendo do seu lado as grandes operadoras brasileiras. A Operadora A da Figura 1 é uma enorme de uma operadora. Por outro lado, o Google demorou demais em ajudar a encontrar uma saída.

 

Uma dificuldade em outras áreas de projetos

 

Há alguns meses atrás fiquei dependendo de uma informação relacionada com seguradoras que estariam dispostas a segurar riscos fortuitos. Suponha que você tenha um projeto cujo objetivo é a realização de um evento em uma determinada localidade. Um evento de grande porte, com um orçamento considerável. Imagine que na véspera do evento aconteça (digamos, uns 3 dias antes), uma tempestade de enormes proporções, que arrase a cidade e cause danos materiais irreversíveis (neste exemplo, não há perdas de vida, felizmente), causando uma perda total do evento. Qual seguradora seria capaz de segurar a perspectiva de uma perda destas? Procurei, procurei, googlei, telefonei, mandei e-mails e não consegui uma resposta. Finalmente entrei no Linkedin e coloquei uma pergunta relacionada, em um grupo de projetos. Houve um debate muito interessante, até que alguém passou o nome de uma seguradora que bancou um risco semelhante, na cidade de New Orleans e acabou pagando o prejuízo causado a um projeto semelhante que iria acontecer por lá. Desta forma, a dúvida e a ausência do seguro foram resolvidas.

Para uma equipe de projetos, a indisponibilidade de competências para descrever, detalhar ou desenvolver partes do projeto (ou mesmo o projeto completo) é a principal motivação para recorrer a opiniões especializadas.

 

Perdas de tempo em projetos

 

No primeiro exemplo, do BGP e topologias, o problema maior é a falta de pensar, com certa antecedência sobre a implementação de um trânsito com a Internet. Mas, esta questão, com a maturidade será resolvida e em breve teremos projetos sendo desenvolvidos para preparar devidamente os roteadores de borda ou até mesmo as redes internas que estão se tornando, também, complexas. Mesmo que sejam pequenos Sistemas Autônomos. Neste momento, o administrador (ou preposto) de um Sistema Autônomo passa a ser um gerente de projetos.

No segundo exemplo, a questão de segurar perdas fortuitas foi resolvida por um membro de um projeto completamente dissociado do meu projeto. Por acaso expor a dúvida em um grupo de alto nível do Linkedin foi um sucesso, embora a iniciativa tenha demorado um pouco para ser tomada.

Geralmente, dentro de uma mesma empresa, obter informações úteis ou fundamentais para projetos não levam muito tempo, porque há sempre disponível o chamado “golden book”, que vai acumulando informações úteis a cada término de um projeto. Entretanto, intergrupos desconexos de projetos, isto não acontece. Um provedor, dificilmente troca informações com outros Provedores. Não por considerarem as informações preciosas ou de valor competitivo, mas por falta de oportunidades ou de local adequado para fazê-los. Geralmente, as informações são trocadas quando alguém, em uma lista de e-mail ou fórum apropriados provoca a questão. Não é, portanto, usual alguém colocar em algum fórum ou lista, por livre e espontânea vontade: “o problema do multi-homed para um mesmo operador de trânsito resolve-se assim e assado…”. Da mesma forma, porque um membro ou gerente de projeto iria divulgar o nome de uma seguradora de riscos fortuitos, se não há um ambiente apropriado para fazê-lo?

 

Objetos de Projeto Estendidos

 

Se houvesse um ambiente apropriado, seguro, confiável e com um mecanismo de pesquisa mais “inteligente”, do que os disponíveis atualmente, a cooperação fluiria espontâneamente. Por várias razões, algumas relacionadas abaixo:

  • Pelo natural espírito de cooperação do ser humano, interessado e consciente.
  • Pela garantia de autoria da informação.
  • Pela perspectiva de auxiliar no crescimento de um repositório de sabedoria útil para projetos, em geral, do qual todos se beneficiarão.
  • Pela rapidez de acesso à informação.
  • Pela possibilidade de manter informações pessoais e privativas.
  • Pela garantia de intervir no ambiente garantindo a qualidade da informação.
  • Pela existência de mecanismos de pesquisa semântica, mais próximos do pensamento humano.

 

A disponibilidade de informações (textos, gráficos, imagens, videos, etc.), tratadas neste documento são armazenadas no que se convencionou chamar Objetos de Projeto Estendido (OPE). Existem dois tipos de OPEs: público e privado. Um OPE é público se ele pode ser compartilhado com terceiros. Um OPE é privado se ele não puder ser compartilhado com terceiros. Os OPEs são agrupados (ou armazenados) em um ambiente chamado de ROPE (Repositório de Objetos de Projeto Estendidos). Existem inúmeros ROPEs, cada um deles hospedados no computador do usuário interessado (o “dono” do ROPE). Um ROPE, possui uma interface humano-computador que, de forma independente classifica, pesquisa e visualiza os OPEs armazenados, além de permitir operações de criação/inclusão e demais atividades necessárias ao tratamento de um OPE isoladamente ou em conjunto. OPEs podem ser enviados ou recebidos de um Sistema de Gerenciamento de Projetos (SGP), através de uma interface apropriada que funcionaria da forma representada na Figura 2.

 

Figura 2. OPE e o Sistema de Gerenciamento de Projetos

 

Se o SGP possuir as facilidades adequadas, os recursos de WEB Semântica serão utilizados, mais apropriadamente, ontologias7 e as propostas da W3C relacionadas com a OWL (Web Ontologoy Language)6. Em futuro próximo, outro artigo abordará este tema, em detalhes, oportunidade em que será mostrado que ontologias podem ser transformadas em XML e vice-versa, aperfeiçoando a proposta da Figura 2. Uma ótima e rápida leitura pode ser encontrada no artigo da Scientific American8 e com maior profundidade, um texto clássico e completo em [9].

Cada OPE possui uma medida de aceitação, denominada assimetria e pode sofrer alterações por terceiros, no sentido de aprovar, reprovar ou identificar a relevância. Assimetria é uma medida de qualidade de um OPE. Por outro lado, o conteúdo de um OPE pode, também, sofrer alterações. Neste caso, o repositório manterá um histórico de tais alterações, desde o OPE original até o atual, incluindo cada uma das contribuições efetivamente aceitas, aprovadas ou reprovadas, e relacionadas com o OPE. A técnica usada para que este procedimento ocorra adequadamente é a procedência de dados, a qual garante que um OPE conterá a descrição de “como”, “quando”, “onde”, “porque” os dados foram obtidos e “quem” os obteve. Cada um dos componentes históricos de uma OPE, caracterizado pela procedência de dados, também tem o sua respectiva assimetria associada, que representa uma medida de aprovação/reprovação e relevância da nova alteração OPE. Por outro lado, a informação oferecida em um OPE pode ou não ter um valor financeiro para que ela se torne visível.

A contribuição da procedência de dados foi obtida da interessante experiência sobre imagens, proposta por Braga4. A noção de assimetria tem sido experimentada e abordada neste blogue em diversas oportunidades, como medida representativa de distorções sociais, de pessoas, entre outras.

 

Caracterizando o tratamento do ROPE

 

A Figura 3 é um esboço preliminar de um diagrama (que parece, mas não é uma diagrama de caso de uso!), caracterizando os pontos mais importantes. Na sequência uma abordagem, também preliminar, sobre o escopo do sistema. A formalização definitiva dependerá de alguns componentes ainda pendentes no âmbito acadêmico em que o autor está atualmente engajado.

 

Figura 3. Diagrama preliminar do sistema de tratamento do ROPE (Fonte: autor).

 

Os desafios de pesquisa avaliados a partir da abstração exposta na Figura 3, são:

  1. A medida de assimetria e as intervenções históricas (procedência) sobre um OPE exigem autenticação do usuário, a qual irá configurar sua validação. Também, a assimetria poderá indicar a permanência ou não de um OPE no repositório distribuído ou no repositório local, sem que haja intervenção humana direta, com base em critérios pré-definidos.
  2. O ROPE deverá estar disponível na Internet, da forma descrita em (c). A disponibilidade de um ROPE é ativa ou passiva. Uma disponibilidade é ativa, se o ROPE está hospedado em um IP público (IPv4 e/ou IPv6), e a disponibilidade é passiva se o IPv4 e/ou IPv6, no qual ele se hospeda é privado (não está visível na Internet). IPv6 é a alternativa preferencial.
  3. Não pode haver um sistema central, característica do paradigma cliente/servidor. Apesar de este paradigma criar uma imensa facilidade para o usuário, uma vez que o acesso poderia ser feito por qualquer navegador (cliente da WEB), ele traria um componente de custo que poderia inviabilizar sua implementação ou mesmo exigir um patrocínio, para garantir servidores e seus respectivos sistemas de segurança associados. Além do mais, tal alternativa afrontaria o princípio do domínio local.
  4. Os mecanismos de pesquisa e acesso ao ROPE que é, na verdade, uma base de conhecimento deve seguir as recomendações propostas nos padrões W3C e em técnicas derivadas.
  5. A quebra do paradigma cliente/servidor exige um mecanismo que permita que os ROPEs sejam distribuídos, isto é, sejam hospedados nas máquinas de cada usuário interessado. Tal predisposição leva às seguintes preocupações:
    1. Fácil implementação e uso de linguagem universal independente do sistema operacional utilizado pelo usuário. Preferencialmente em código objeto com versão bem definida onde, o sistema operacional é uma completa abstração.
    2. Cada ROPE deve ter uma identificação única sempre associada a seu usuário. Está identificação será um número de 32 bits permitindo até 4.294.967.296 repositórios diferentes. Tal identificação pode ser obtida através de qualquer repositório ativo (sempre o mais próximo do usuário, preferencialmente).
    3. Disponibilidade de mecanismo que permita atualização do(s) procedimento(s) associado(s) à operação local do ROPE. Por exemplo, o código objeto dito em (i).
    4. Atualização do repositório de OPE, em tempo real, que não poderá usar qualquer SGBD (Sistema de Gerenciamento de Base de Dados). O uso de um SGDB implicaria em complexidade adicional à implementação. Tal imposição leva à criação de representações de arquivos (incorporando XML, RDF, …) sob uma estrutura de diretórios locais, em texto ou outro formato, bem como qualquer outro tipo de informação (como por exemplo, aquelas necessárias ao mecanismo de autenticação).
    5. O projeto deve prever a ubiquidade, e usar recursos pervasivos.
    6. As propriedades ubíquas e pervasivas implicam na necessidade de mecanismo de cooperação entre os ROPEs disponíveis. A propriedade pervasiva somente poderá ocorrer em ROPEs ativos. Neste caso, o proprietário do ROPE pode autorizar ou não, terceiros usarem seu repositório para atender tal demanda.
    7. Por fim, um ROPE deve ser autônomo, com todas as facilidades e demandas disponíveis localmente.
  6. Mecanismos de criptografia adequados e transparentes aos usuários para garantir a segurança a todos os requisitos exigidos.
  7. O OPE deve ser caracterizado, também, pela sua aplicação às recomendações do PMBOK5, suas seções e capítulos. Consequentemente, deverá atualizar as características recomendadas pelas novas versões de padronizações propostas pelo PMI. Na hipótese de ocorrerem mudanças fundamentais na estrutura do PMBOK de referência, o OPE deverá manter histórico referencial.
  8. Os ROPEs devem ser identificados com garantia de autonomia. O mecanismo de cooperação (item d, subitem v), deve propagar tais informações para outros repositórios. A princípio, o mecanismo de propagação seguirá um esquema conhecido por empareamento (peering). Em outras palavras, um repositório OPE tem um ou mais empareados (peers).
  9. Cada empareado age ativamente (e de forma autônoma), no sentido de atualizar seus ROPEs, das seguintes maneiras:
    1. Cada ROPE está disposto a receber e enviar atualizações de um ou mais empareados, quando seu hospedeiro for ativo (item b);
    2. Um ROPE busca e envia atualizações em um ou mais empareados, previamente conhecidos, quando seu hospedeiro for passivo (item b).
  10. ROPEs empareados possuem um protocolo de relacionamento que permita a troca segura de informações. Tal protocolo é caracterizado por um autômato finito e seguirá os exemplos mais eficazes e simples, disponíveis na literatura.
  11. Um ROPE empareado que tenha sofrido uma alteração comunica-se com todos os seus empareados conhecidos com o objetivo de atualizá-los.
  12. Um OPE pode ter um custo associado à informação que ele está disponibilizando. Baseado na descrição objetiva do conteúdo do OPE pode-se decidir pelo pagamento com regras bem estabelecidas, inclusive uso de cartões de crédito. Neste caso, um mecanismo de pagamento deverá estar disponível para acesso imediato via o próprio OPE. A previsão de mecanismos de segurança descritas no item (e) torna factível esta proposição.

Vale lembrar, que o BGP é uma implementação que quebra o paradigma cliente/servidor (o que não é uma novidade), e usa a Internet para criar os ambientes de redes autônomas. Aliás, melhor seria afirmar que as implementações de BGP constroem a Internet.

Ademais, não é uma proposta de um sistema de relacionamento. Os ROPEs não possuem a identificação de seus proprietários, muito embora os OPEs e seus históricos, sim. Neste último caso, se o autor do OPE ou histórico, assim o desejar. Isto não configura o anonimato pois só se pode criar ou alterar um OPE se existir um proprietário de ROPE bem identificado.

Com referência à metodologia há fortes indícios que levam às recomendações propostas por Eeles e Crips3.

 

Observações finais

 

O trabalho deve ser desenvolvido em três etapas, a saber:

  1. Definição do problema: é a etapa em que o refinamento do texto acima irá acontecer, com a especificação do mecanismo de bases de dados distribuídas, as relações ubíqua e pervasiva. Formalização do esquema de mensagens e o autômato finito das conexões dos repositórios entre si. Adicionalmente, a especificação do modelo da base da dados do ROPE, através de uma metalinguagem.
  2. A descrição geral do sistema e suas relações com o PMBOK: etapa que irá descrever todo o sistema, com os detalhes das especificações e os componentes teóricos envolvidos. Os mecanismos de arbitragem das medidas de aceitação (assimetrias). Os tipos de OPEs possíveis e seus formatos relacionados com a estrutura do PMBOK. A proposta da linguagem de programação com base em comparações específicas.
  3. A evolução: propostas de estudos e pesquisas que possam viabilizar a implementação, testes de protótipos e fortalecimento de fragilidades a serem identificadas. Esta etapa está fora do escopo da proposta de trabalho inicial, que representam os itens (1) e (2), acima.

Referências

 

  1. RFC2270, Using a Dedicated AS for Sites Homed to a Single Provider J. Stewart, T. Bates, R. Chandra, E. Chen [ January 1998 ] (TXT = 12063) (Status: INFORMATIONAL) (Stream: IETF, Area: rtg, WG: idr)
  2. John W. Stewart III. (1999). BGP4: Inter-Domain Routing in the Internet. Addison-Wesley.
  3. Peter Eeles e Peter Cripps. (2012, Second Printing). The process of software architecting. Addison-Wesley.
  4. Juliana Cristina Braga. Procedência de Dados: Teoria e Aplicações ao Processamento de Imagens. 2004. 110 f. Tese de Doutorado do Curso de Pós-Graduação em Computação Aplicada. INPE, São José dos Campos, 2007.
  5. PMI. Um guia do conhecimento em gerenciamento de projetos (Guia PMBOK), 4a. edição, 2008
  6. W3C. OWL Web Ontology Language Guide. W3C Recommendation 10 February 2004. Disponível em: http://www.w3.org/TR/owl-guide/. Acessado em 16/12/2012.
  7. NOY, N.; MCGUINNESS, D. Ontology development 101: A guide to creating your first ontology, 2001. Disponivel em: http://liris.cnrs.fr/alain.mille/enseignements/Ecole_Centrale/What is an ontology and why we need it.htm. Acessado em 20/12/2012.
  8. BERNERS-LEE, T. I. M.; HENDLER, J.; LASSILA, O. R. A. The Semantic Web will enable machines to. Scientific American, n. May, p. 1-4, 2001. Disponível em http://www-sop.inria.fr/acacia/cours/essi2006/Scientific%20American_%20Feature%20Article_%20The%20Semantic%20Web_%20May%202001.pdf
  9. TRUSZKOWSKI, W.; BREITMANN, K. K.; CASANOVA, M. A. Semantic Web: Concepts, Technologies and Applications. [S.l.] Springer-Verlag, 2007.

 

Na sequência: Máquinas de estado finito: Parte Prática: MEF do BGP

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!


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

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.