À pedidos, a primeira parte do tutorial focado no protocolo ISIS. Muitos não sabem, mas o protocolo ISIS foi concebido pela ISO e, por isso, pode ser mapeado diretamente ao modelo ISO-OSI. Existem muitas semelhanças que merecem ser observadas entre os protocolos de roteamento ISIS e OSPF. Ambos são protocolos de roteamento definidos como “link state”, são “classless”, possuem tipos específicos de routers definidos em diferentes partes da rede, são hierárquicos (podem definir áreas distintas) dentre outras semelhanças. O número de diferenças entre ambos, entretanto, também é igualmente numerosa.

Uma diferença importante é a maneira como os dois protocolos manipulam pacotes “hello”. Como sabemos, pacotes “hello” são fundamentais para manter adjacências OSPF e ISIS ativas. Uma vez que ambos são protocolos link-state, as atualizações são enviadas apenas na medida em que ocorrem alterações na rede (incrementalmente).

O protocolo OSPF nos dá algumas ótimas opções quando se trata de manter a tabela de roteamento em um tamanho moderado, por meio da aplicação do conceito de “áreas” associado à sumarização de rotas. Entretanto, para o protocolo OSPF, apenas 1 tipo de pacote hello é definido. Em redes ISIS, os roteadores são capazes de enviar dois tipos distintos de pacotes hello: Nível 1 e Nível 2. Roteadores ISIS são, por sua vez,  classificados como Nível 1 (L1), Nível 2 (L2), e Nível 1-2 (L1, L2). Por padrão, roteadores Cisco são roteadores L1-L2. Isto significa que cada interface ISIS irá propagar pacotes hello L1 e L2. Se uma das interfaces está formando apenas uma adjacência L1 ou L2, não há motivo para transmitir pacotes hello de outro tipo.

Outra diferença interessante entre os protocolos seria os tipos de routers definidos em cada um. O protocolo ISIS define tipos de roteadores que podem, até certo ponto, ser mapeados para os tipos de routers definidos em redes OSPF.

O protocolo ISIS define basicamente 3 tipos de routers: Level 1 (L1), Level 2(L2), e L1/L2. Routers L1 são definidos em uma única área, e podem ser mapeados para o “Area Router” do OSPF. Estes routers conectam-se à outras áreas ISIS via routers L1/L2, análogos aos ABRs (Area Border Routers) de redes OSPF.  Routers L1 usam os routers L1/L2 router como “default gateway” para alcançar redes pertencentes à outras áreas, da mesma forma que um Area Router, no OSPF, usa o ABR.

Na figura acima, todos os router – com exceção do router R2 – são do tipo L1. Routers  L1 são, portanto, routers definidos apenas em uma mesma área.  Routers L1 não pssuem em suas tabelas de roteamento nenhuma informação sobre redes que se encontram fora da área na qual se encontram. Routers ISIS L1 têm que ter suas bases de dados em sincronia.

Assim como temos routers L1, temos também routers L2. Toda vez que seja necessário o roteamento inter-área, um router L2 ou L1/L2 deve ser envolvido. Todos os routers L2 também devem ter suas bases de dados em sincronia.

Routers do tipo L1 e L2 enviam seus pacotes hello próprios. Assim como ocorre em redes OSPF, os pacotes hello permitem aos routers ISIS a formação de adjacências entre si. A principal diferença aqui é que routers L1 enviam mensagens hello do tipo 1, enquanto routers L2 enviam mensagens hello do tipo 2. Como estes pacotes são distintos, routers L1 não formam adjacências com routers L2. Como já foi dito, um mesmo router pode ser do tipo L1 e L2 simultaneamente (este é o modo default para routers Cisco). Neste caso, um mesmo router envia mensagens hello dos 2 tipos.

Bom, este é apenas a primeira parte de uma série de tutoriais sobre ISIS. Começamos simples, e vamos nos aprofundando neste interessante protocolo!

Espero que tenham gostado.

Um abraço!

Marco Filippetti

Está aí algo que há 10 anos atrás achava que nunca veria e que há 5 anos atrás comecei acreditar que fosse possível.

HOLOGRAMAS!

Tem a ver com a Telepresence da Cisco, não?

Abraços!

Fábio A. de Amorim 

Fonte: Circuito Integrado da Folha: 

A rede norte-americana CNN apresentou a correspondente Jessica Yellin, que estava em Chicago, representada por uma imagem tridimensional no estúdio de Nova York.

De acordo com o Gizmodo, para conseguir o feito –a Yellin dupla podia ser enxergada de vários ângulos– foram usadas 44 câmeras de alta definição e 20 computadores.

O negócio é meio bizarro, mas funcionou bem.

Segundo notícia publicada pela info, a NET começa a testar uma tecnologia desenvolvida em conjunto com a Cisco que permite aos usuários do serviço de banda larga do provedor atingirem “singelos” 60 Mbps em suas residências.

Os testes da chamada “quinta geração” da banda larga, pela NET, têm início nesta quarta-feira e permite conexões a uma velocidade de até 60 Megabits por segundo (Mbps), ou seja, cinco vezes mais que a conexão mais rápida disponível hoje, pelo provedor.

A tecnologia mistura fibra óptica com cabos coaxiais e precisa de um novo cable modem, desenvolvido em parceria com a Cisco. Até o momento, a velocidade mais alta oferecida pela NET era de 12 Mbps. No país, existem ofertas como de 20 Mbps, da GVT, e de 30 Mbps, da Telefônica em São Paulo (esta última disponível apenas via fibra ótica FTTH, e na região da Av. Paulista, em São Paulo).

A velocidade de 60 Mbps vai ser testada a partir desta quarta-feira somente para clientes da NET do bairro fluminense do Leblon. Os assinantes que tiverem o pacote NET Combo HD Max poderão solicitar a migração sem custo para a nova velocidade por seis meses. A única exigência é que eles agendem uma visita técnica para trocar seu atual cable modem pelo modelo desenvolvido com a Cisco.

Com essa velocidade, a NET pretende distribuir vídeos em alta definição entregues simultaneamente na tela da TV e do computador através de sua rede de cabos. Segundo a companhia, outros bairros do Rio de Janeiro estão sendo preparados para testar a novidade até o final deste ano, de acordo com o decorrer dos testes no Leblon. O lançamento comercial, entretanto, não deve ocorrer antes do final dos testes de seis meses, de acordo com informações da assessoria de imprensa.

Para quem não sabe, a Cisco e a NET já têm parcerias em outras áreas. A Scientific Atlanta, empresa comprada pela Cisco há não muito tempo, é a fornecedora oficial dos decoders e equipamentos de vídeo digital para os “head-ends” da NET. Esta parceria, ao que parece, está caminhando firme e forte, e avançando para a área de dados.

Re$ta $aber quanto vai cu$tar.

Abs!!

Marco.

Senhores, sei que o assunto é meio fora de tópico, mas gostaria de informá-los sobre o lançamento da 3a edição do meu livro Construindo Supercomputadores com Linux.

Esta edição foi totalmente reformulada, dando um tratamento parte acadêmico parte corporativo, de tal forma que os leitores iniciantes ou não na área da supercomputação consigam entender bem todos os conceitos envolvidos na tecnologia, desde hardware, rede (inclusive super importante em termos de desempenho), programação paralela e distribuída, armazenamento de dados (storages), dentre outros tópicos. Um assunto muito interessante, na qual desde 1994 quando li o primeiro artigo de Donald Becker e Thomas Sterling, ambos cientistas da Nasa, senti que isso iria muito a frente pois, grande parte dos estudos da área espacial são revertidos para o mundo em que vivemos.

A constante demanda de poder computacional vem gerando a necessidade de processadores cada vez mais rápidos.

Na computação de alto desempenho, utilizada para programação científica, multimídia, gerenciamento de grandes volumes de dados etc., a solução passa por máquinas com múltiplos processadores ou ainda clusters proprietários fornecidos por grandes empresas. Ambas as soluções são custosas e de pouca escalabilidade.

A estrutura de agrupamento de computadores, ou cluster, apresenta vantagens competitivas em relação aos ambientes multiprocessados de memória compartilhada (computadores com diversos processadores em uma placa-mãe), permitindo que o acréscimo de computadores torne o sistema mais rápido.

Como exemplo de uma aplicação comercial, podemos citar a produção das imagens tridimensionais dos filmes Titanic, Total Recall, Apollo 13, True Lies dentre outros.

Uma dessas tecnologias foi a paralelização de computadores. Após mais de vinte anos em laboratório é que ela foi parar no mercado dos computadores de grande porte, e somente há alguns anos apareceram várias tecnologias bem interessantes para microcomputadores. Dentre elas, a que teve maior destaque foi o cluster de PCs classe Beowulf da NASA, que é o foco principal deste livro.

Através de linguagem fácil, didática no estilo “faça você mesmo”, são demonstrados como escolher o hardware, a ligação dos computadores, a configuração e instalação do sistema operacional Linux, a configuração de todos os nós de rede para que passem a ter a ilusão de uma imagem do sistema de recurso único (Single System Image), gerenciar o cluster, executar testes básicos de funcionamento, usar ferramentas de avaliação de performance e colocar seu supercomputador para executar processamento de imagens tridimensionais e integrar o leitor iniciante, médio ou avançado no mundo dos supercomputadores classe Beowulf para computação de alto desempenho, também conhecido como Clusters para High Performance Computing.

Nesta terceira edição vários capítulos foram totalmente reescritos e remodelados, para adequar novas informações, aprofundamento de alguns conceitos e atualizar as aplicações descritas no livro. Cada um deles cobre assuntos específicos para sua construção, gerência, administração e execução de aplicações paralelas.

link: www.brasport.com.br

Um abraço e até a próxima…

Um pequeno “OFF” de fim de semana! Como muitos sabem, recentemente a Google anunciou para o mundo o lançamento de seu sistema operacional, o “Android“. Bom, até aí, tudo bem. A Google não tem chances contra a Microsoft e seu Windows, não é mesmo? Será mesmo?

A Google já está na frente na plataforma “Computação nas Nuvens“, e seu novo sistema operacional, mesmo sendo ainda muito novo e com poucos recursos - se comparado à outros - já deixa a Apple e seu iPhone, por exemplo, um pouco desconfortável. O novo sistema da Google já pode ser adquirido juntamente com o telefone celular “G1″ (vídeo abaixo).

Parece que a Google ainda vai dar MUITO o que falar.

É esperar para ver.

Abs!

Marco.

Espera-se que a Cisco apresente um novo roteador de borda focado no mercado SP (Service Providers) já em Novembro (dia 11, para ser mais exato). O novo router deve ser o sucessor da linha 7600, que já começa a sofrer com a idade “avançada”. O novo modelo deve suportar um troughput de 5 a 7 Tbps, entretanto - inicialmente - deve disponibilizar um troughput de “apenas” 1 Tbps.

Espera-se que a nova plataforma venha a otimizar o transporte dos novos formatos de dados e, especialmente, atender a crescente demanda por banda das aplicações de àudio e vídeo.

Segundo a empresa Oppenheimer & Co., é provável que a nova plataforma venha a ser batizada de “ASR X000″. A Cisco ainda não se manisfestou oficialmente sobre o assunto. Estima-se que a capacidade entregue pela nova plataforma supere a da linha MX da Juniper, concorrente direto nesta fatia de mercado. Também, ao que parece, a nova plataforma utilizará o sistema operacional CRS-1 IOS-XR e não o IOS-XE, utilizado atualmente na plataforma ASR 1000.

Abaixo, a foto da família ASR1000. A nova linha deve ser semelhante fisicamente.

Portanto, preparem-se…! Vem novidade por aí!!!

Fonte: http://www.networkworld.com/news/2008/103108-cisco-edge.html

Um abraço,

Marco Filippetti

Este post trata, de forma breve, da feature DMVPN, que permite a implementação de redes virtuais privadas (VPNs) de pequeno, médio ou mesmo de grande porte, de forma simples e rápida, por meio da combinação de tunelamento GRE, IPSec e NHRP (Next Hop Resolution Protocol).

Sei que este tópico é um pouco avançado, mas com o advento do Dynamips, mesmo aqueles que não compreenderem plenamente a tecnologia será capaz de implementá-la em um ambiente de testes. Apesar de não ser algo novo, a primeira vez que tive contato com DMVPN foi na BT, ou seja, não faz muito tempo (pouco mais de 1 ano). Achei fantástica esta feature e, desde então, estou para escrever um post sobre ela.

Referências:

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a008075ea98.pdf
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftgreips.pdf

É importante ressaltar que nem todas as versões do IOS suportam DMVPN. As referências acima indicam quais as versões suportadas.

DMVPN é uma feature de IOS baseada em 2 tecnologias Cisco muito bem difundidas e aceitas:

• Next Hop Resolution Protocol (NHRP) - O HUB da topologia mantém uma base de dados com os endereços válidos (públicos / roteáveis) de todos os SPOKES da rede.
• Multipoint GRE Tunnel Interface - Permite que uma única interface GRE suporte múltiplos túneis IPsec.

A feature DMVPN não altera túneis VPN padrão IPsec, mas altera o modo como estes são configurados. Os spokes mantém um túnel IPsec permanente com o HUB, porém, não entre eles. Quando um spoke precisa enviar um pacote com destino a outro spoke, ele realiza uma busca na base de dados NHRP para identificar o endereço público (roteável) do spoke em questão. O túnel entre os spokes é então estabelecido via interface mGRE.

É necessário ativar roteamento dinâmico nos túneis entre o hub e o spoke, uma vez que o spoke aprende os endereços de rede configurados em outros spokes e no hub via atualizações de roteamento. Dentre os protocolos de roteamento possíveis, temos: RIP, BGP, EIGRP e OSPF.

Em termos de configuração, como já foi mencionado, ela é bastante simplificada. O melhor modo de compreender isso é comparando o modo tradicional (IPsec + GRE) e o modo DMVPN.

A figura abaixo apresenta o modo tradicional. Observe que, no HUB, temos tantas interfaces “tunnel” quantas se fizerem necessárias: Uma para cada conexão com um spoke.

Observemos então, as linhas de configuração necessárias para estabelecimento do cenário anteriormente apresentado:

Notem a necessidade de se configurar uma interface tunnel para cada spoke. Temos cerca de 13 linhas para cada spoke! Se tivermos uma rede com 300 spokes, mais de 3900 linhas de configuração seriam necessárias! Isso pode “matar” um roteador facilmente.

A alternativa: Dynamic Multipoint VPN (DMVPN). Observem a topologia da mesma rede anteriormente mencionada, porém, agora com DMVPN sendo utilizado.

Notem que temos apenas 1 interface tunnel no HUB, agora. Vamos dar uma olhada na configuração do HUB:

Não é mais necessário 13 linhas de configuração por spoke! Agora, uma rede com 300 spokes consomem as mesmas 13 linhas de uma rede com apenas 1. Ótimo, não??

Vamos dar uma olhada nas configs dos spokes. Comecemos pelo spoke A:

Passemos ao spoke B:

Notem como as configs seguem uma uniformidade. Pouco se altera na config de um spoke para outro. Fica muito mais simples gerenciar e realizar troubleshooting em uma rede configurada desta forma.

O melhor de tudo: Pode-se praticar o que está sendo mostrado aqui no Dynamips, sem problemas (apenas tenham certeza que estão usando um IOS que suporte DMVPN).

Uma breve comparação entre os 2 métodos (tradicional X DMVPN) :

Por hora, é só! Espero que tenham gostado!

um abraço para todos!

Marco Filippetti

Olá pessoal ai vai uma dica quente!!!!!

Para construir PABX´s digitais com software livre temos duas excelentes opções:

disc-os - http://www.disc-os.org
trixbox - http://www.trixbox.org

Com o DISC-OS, vocês podem conseguir suporte na Intelbras, que fabrica placas para PC´s (ISDN, MFC-R2, FXS, FXS) compatíveis com as da empresa Digium.

A Trixbox é a primeira distribuição Linux para o Asterisk. Carrega o pioneirismo e comentam ser o melhor sistema pois tem mais recursos configuráveis via web que o Disc-OS.

Ambas têm interface web para toda a administração dos serviços do Asterisk, criação de ramais, rotas, troncos, filas, voicemails, etc. O Disc-OS tem a vantagem de ser em português.

Recomendo ter todas as configurações armazenadas em banco de dados, que pode ser MySQL. CDR também armazenado em Banco Dados (configurado no mysql add-ons), e uso do Asterisk Real Time, pois isso facilita o trabalho de manutenção (criação de ramais), uma vez que assim não é necessário recarregar o asterisk para reconhecer um novo ramal.

Se houver ramais em outras localidades, use o protocolo G729 (tem que adquirir licenças) desde que esse cliente também tenha telefone compatível.

O QoS, como vocês sabem, é fundamental em toda a rede VoIP, inclusive o lado dos clientes.

As configurações iniciais do asterisk estão em /etc/asterisk:

sip.conf –> Ramais sip e sip trunk.
extensions.conf –> Todos os planos de discagem.
iax.conf –> Ligações entre asterisk.
zapata.conf –> Configurações regionais, ramais, etc, para E1, fxs, fxo.
/etc/zaptel.conf –> Configurações para placas E1,fxs, fxo (protocolos, clock, etc)

Até a próxima…

Marcos Pitanga

Tenho observado várias pessoas querendo simular estes recursos nos switches Cisco aqui fica a dica:

Em http://freeradius.org/ além de você poder construir seu servidor Radius você também poderá criar seu servidor VMPS para suas VLANS Dinâmicas.

Para colocar um servidor Radius gerenciado via Web aqui vai mais uma dica:

http://www.howtoforge.com/authentication-authorization-and-accounting-with-freeradius-and-mysql-backend-and-webbased-management-with-daloradius

Bons Estudos…

Marcos Pitanga

“Os pinguins dominarão o universo”

Pessoal,

Buscando na Net, me deparei com este excelente artigo sobre o BGP, escrito há algum tempo por Alex Soares de Moura, para o site da RNP (Rede Nacional de Pesquisa). Como alguns leitores aqui já pedirama publicação de algo sobre este protocolo, pensei em começarmos por este artigo. Partindo dele, vou escrevendo, aos poucos, posts relacionados à este complexo protocolo (BGP).

Atenção! Eu não sou autor do artigo abaixo! Estou apenas colocando-o para leitura e discussão. Mais adiante, estou planejando colocar alguns estudos de caso reais, para discussão. Mas estes apenas serão úteis se a teoria básica for compreendida. Espero que este post ajude neste sentido!

Autor do post original: Alex Soares de Moura <alex@nc-rj.rnp.br>
Publicado no site da Rede Nacional de Ensino e Pesquisa (RNP)

Esta é a primeira parte do artigo de introdução ao protocolo BGP-4. Neste primeiro momento são abordados alguns conceitos básicos para o entendimento da atual arquitetura utilizada na Internet mundial e a participação do BGP-4.Para a devida compreensão do assunto abordado, é interessante que se esteja familiarizado com conceitos básicos de protocolos de roteamento. O artigo “Roteamento: O Que É Importante Saber”, publicado no RNP News Generation, No.1, Vol.1, pode servir para tal.

Introdução

Este artigo procura apresentar uma introdução ao protocolo de roteamento Border Gateway Protocol Version 4, BGP-4, que podemos considerar, parafraseando o Dr. Douglas E. Comer, “a cola que mantém a Internet unida e permite a interconexão universal” atualmente.

O BGP-4 possibilita o intercâmbio de informações de roteamento entre os diversos sistemas autônomos, ou ASs (Autonomous Systems), que em conjunto, formam a Internet. Explicando de uma forma simplificada, ele permite que os dados trafeguem entre os ASs até chegar ao AS de destino, e dentro dele siga até o seu destino final (máquina).

Uma vez que o BGP-4 também está presente (em uma versão chamada BGP-4+ [RFC 2283]) no backbone Internet do futuro, o 6bone, conhecer seus mecanismos básicos é fundamental para qualquer um que esteja ou deseja estar envolvido na administração de um AS de qualquer porte ou que precisa saber mais sobre roteamento na Internet.

Histórico

Há alguns anos, quando o principal backbone da Internet era a ARPANET, as instituições de pesquisa conectadas à rede precisavam gerenciar manualmente as tabelas de rotas para todos os possíveis destinos, ou seja, todas as outras redes conectadas (ver Figura 1).

Com o crescimento da Internet, verificou-se que era impraticável manter todas as tabelas atualizadas dessa forma, e que mecanismos de atualização automática eram necessários. Os pesquisadores da Internet optaram, então, por usar uma arquitetura que consistia de um reduzido e centralizado grupo de roteadores (core routers) que tinham, em suas tabelas, as rotas para todos os possíveis destinos da Internet; e um outro grupo maior de roteadores que possuíam em suas tabelas apenas informações (rotas) parciais, e não para toda a Internet.

Os core routers eram administrados pelo INOC (Internet Network Operations Center), e o grupo maior de roteadores externos ficou conhecido pelo termo “noncore routers” (roteadores fora do núcleo), que conectavam as redes locais das instituições de pesquisa ao backbone da ARPANET.

Figura 1: Backbone da ARPANET

Foi desenvolvido, então, o protocolo GGP (Gateway-To-Gateway Protocol), que foi usado nos core routers para atualização automática das tabelas de rotas entre eles. O GGP era um protocolo baseado no algoritmo de vetor de distância (Vector-Distance, também conhecido como Bellman-Ford).

Essa arquitetura tem, tecnicamente, graves pontos fracos principalmente com relação a sua capacidade de expansão, e a Internet acabou crescendo muito, indo além de um único backbone gerenciado de forma centralizada. Verificou-se, portanto, não ser possível expandir esse backbone arbitrariamente, por haver diversas limitações técnicas.

Como o backbone de cada site pode ter uma estrutura complexa, o esquema de core routers não iria conseguir suportar conectar todas as redes diretamente. Era necessário um novo esquema que permitisse aos noncore routers passar informações aos core routers sobre as redes que estavam “atrás” de si, além de oferecer autonomia de gerenciamento aos sites.

Até o momento, estava sendo usado o conceito de interconexão que levava em conta apenas a arquitetura do roteamento em uma internet e não contemplava as questões administrativas envolvidas.

Os projetistas notaram que as interconexões de um backbone com arquitetura complexa não devem ser encaradas como várias redes independentes conectadas a uma internet, mas como uma organização que controla várias redes e que garante que as informações sobre as rotas internas são consistentes e que pode escolher um de seus roteadores para fazer a ponte de comunicação para o “mundo exterior”.

Entra em cena o conceito do Sistema Autônomo (Autonomous Systems - AS), no qual as redes e roteadores estão sob o controle de uma mesma entidade administrativa. Esse conceito substitui a idéia das redes locais conectadas ao backbone central. Cada AS tem a liberdade de escolher o esquema e arquitetura que melhor lhe convém para descobrir, propagar, validar e verificar a consistência das suas rotas internas e a responsabilidade de anunciar para os outros ASs as rotas para suas redes internas não visíveis. A Figura 2 ilustra o conceito de Sistema Autônomo.

Figura 2: Exemplo de Sistema Autônomo

Para anunciar as rotas para suas redes internas entre si, os ASs precisavam concordar em usar um esquema único, como um mesmo idioma por toda a Internet; e para permitir um algoritmo de roteamento automatizado distinguir entre um AS e outro, foi designado a cada AS, um número (Autonomous System Number - ASN) pela mesma autoridade central encarregada de atribuir todos os endereços identificadores das redes conectadas à Internet (ver Figura 3).

Figura 3: Arquitetura de Backbone Usando o Conceito de ASs

Exterior Gateway Protocol - EGP

Dois roteadores que pertençam a ASs diferentes e trocam informações de roteamento entre si são considerados “vizinhos externos” (exterior neighbors). Se ambos pertencerem ao mesmo AS são considerados “vizinhos internos” (interior neighbors). O protocolo de roteamento usado pelos exterior neighbors é o Exterior Gateway Protocol ou simplesmente EGP [RFC 904]. É ele que permite o anúncio das rotas para as redes internas do AS para o núcleo (core) da Internet (ver Figura 4).

Com o tempo, o EGP apresentou diversas limitações técnicas e potenciais problemas para ser usado na Internet. Apesar das tentativas para produzir novas versões (EGP2 e EGP3) do protocolo, os projetistas não obtiveram sucesso por haver a necessidade de muitas alterações fundamentais na estrutura do mesmo.

O EGP apresentou deficiências insustentáveis, como restrições em topologia, incapacidade de evitar “loops” de roteamento e pouca flexibilidade para a configuração de políticas de roteamento.

Um grande desafio para os projetistas era a solução de como transformar uma arquitetura internet para não depender de um sistema centralizado (core routers) - deixando uma topologia organizada hierarquicamente e iniciando outra, com diferente estrutura. Além disso, tinha o desafio de como fazer uma arquitetura internet suportar uma forma de colaboração mais próxima entre certos ASs do que entre outros.

Figura 4: Arquitetura da NFSNET Usando o EGP

Isso levou os engenheiros do IETF a desenvolver uma solução para esses problemas através de um novo, mais moderno e mais robusto protocolo de roteamento externo, como será visto a seguir.

Border Gateway Protocol Version 4 - BGP-4

O BGP é um protocolo de roteamento para ser usado entre múltiplos sistemas autônomos em internets baseadas no protocolo TCP/IP. O BGP-4 [RFCs 1771, 1772] tornou-se o sucessor natural do EGP, efetivamente atacando suas deficiências mais sérias, ou seja, evitando “loops” de roteamento e permitindo o uso de políticas de roteamento entre ASs baseado em regras arbitrárias por eles definidas. Além disso, o BGP-4 foi a primeira versão do BGP a suportar endereços agregados (Classless Interdomain Routing, ou simplesmente CIDR) e o conceito de supernets.

O protocolo BGP-4 assume que o roteamento interno do AS é feito através de um sistema IGP (Interior Gateway Protocol) de roteamento interno. Este pode ser um protocolo de roteamento como o RIP, OSPF, IGRP, EIGRP; ou até mesmo através de rotas estáticas. O BGP constrói um gráfico dos ASs, usando as informações trocadas pelos “vizinhos BGP” (BGP neighbors), que são compostas dos números identificadores dos ASs, os ASN. A conexão entre ASs forma um “caminho” (path), e a coleção desses caminhos acaba formando uma rota composta pelos números dos ASs que devem ser percorridos até se chegar a um determinado AS destino.

O BGP faz uso do TCP (porta 179) para o transporte das informações de roteamento de modo que ele próprio não precisa preocupar-se a respeito a correta da transmissão das informações.

Outra característica do BGP-4 é atualização das tabelas de rotas feitas de forma incremental, como nos algoritmos de estado de enlace. A atualização completa da tabela de rotas é feita somente uma vez, quando se estabelece a sessão entre os neighbors ou peers.

Para o estabelecimento de uma sessão BGP entre neighbors ou peers, basicamente, os seguintes passos são executados:

• É estabelecida a conexão TCP entre os dois roteadores que trocam mensagens de abertura da sessão e negociam os parâmetros de operação;
• O primeiro fluxo de dados transmitido é a tabela de rotas BGP completa. Posteriores atualizações nesta tabela são feitas, incrementalmente, à medida que as mudanças ocorrerem;
• Como não há a atualização completa da tabela após a primeira, o roteador mantém a informação da versão da tabela que todos os seus peers possuem, enquanto durar a sessão entre eles. Se esta for interrompida por qualquer motivo, o processo é iniciado novamente a partir do primeiro passo;
• Mensagens de keepalive são enviadas periodicamente para manter a sessão aberta;
• Mensagens de aviso são enviadas quando ocorrem erros ou outras situações especiais;
• Caso uma conexão verifique um erro, uma mensagem é enviada e a conexão fechada, encerrando a sessão.

A figura abaixo representa a atual arquitetura da Internet, onde ASs comunicam-se via BGP-4.

Figura 5: ASs Comunicando-se Via BGP-4

O uso do BGP-4

O BGP é usado nas situações em que uma rede precisa conectar-se a mais de um provedor simultaneamente (multi-home), ou quando se deseja ter um pouco mais de controle sobre quais caminhos seus dados seguirão pela Internet.

Basicamente, o BGP serve para informar às redes externas a um AS quais são as rotas para redes atingíveis dentro de sua rede. Falando de outra forma, o propósito do BGP-4 é anunciar rotas para outras redes externas, ou sistemas autônomos. Esses anúncios são como “promessas” de que os dados serão transportados para o espaço IP representado pela rota sendo anunciada.

Se, por exemplo, um AS anunciar uma rota para 192.168.4.0/24 (na sintaxe anterior ao CIDR, este endereço é a classe “C” que começa em 192.168.4.0 e termina em 192.168.4.255) e alguém enviar dados destinados a qualquer endereço dentro dessa faixa, esse AS está “garantindo” que sabe enviar os dados até o destino.

Neighbors, Peers, eBGP e iBGP

Sistemas (roteadores) que são “vizinhos BGP” (BGP neighbors) comunicam-se através de “sessões” estabelecidas entre eles. Os roteadores de “borda” (border routers) de ASs vizinhos são considerados peers. Esses peers são as “fronteiras políticas” dos ASs, que trocam tráfego de acordo com as regras definidas pelos ASs participantes.

São chamados neighbors os sistemas BGP (roteadores) que possuem sessões BGP estabelecidas entre eles. Então, os roteadores de borda são neighbors? Sim. Porém, quando uma importância política é a eles atribuída, a forma correta de chama-los é de peers, enquanto que os neighbors são quaisquer vizinhos BGP.

Existem outras situações em que os vizinhos BGP não são, obrigatoriamente, os roteadores entre ASs e sim roteadores do mesmo AS. Neste caso as sessões estabelecidas entre eles acontece internamente ao AS. O que permite isso é o iBGP ou internal BGP, que permite a troca de rotas no mesmo AS. De forma análoga, a troca de rotas entre ASs é feita pelo eBGP (exterior BGP). Um importante conceito do iBGP é que os neighbors não têm a obrigação de estar diretamente conectados (ver Figura 6) através de uma linha serial ou via interface Ethernet, por exemplo. Os peers por outro lado não podem estar conectados de outra forma que não seja a direta, seja link serial ou interface Ethernet.

Figura 6: Exemplo de Peers, Neighbors, eBGP e iBGP

O algoritmo do eBGP trabalha, basicamente, anunciando todas rotas que conhece, enquanto o do iBGP faz o possível para não anunciar rotas. Assim, para fazer o iBGP funcionar adequadamente dentro de um AS é necessário estabelecer sessões BGP entre todos os roteadores que “falam” iBGP (ver Figura 7), formando uma “malha completa” (full mesh) de sessões iBGP dentro do AS.

Figura 7: Exemplo de Configuração “Malha Completa” de iBGP

Estas características serão abordadas de foma mais completa posteriomente.

Atributos do BGP

Atributos do BGP são um conjunto de parâmetros usados para controlar informações específicas relativas a rotas, como informação sobre o caminho (path), grau de preferência da rota, o valor do next-hop da rota e informações sobre agregação. Estes parâmetros são usados pelo algoritmo do BGP como elementos para decisão da escolha das rotas e para decisão sobre filtragem de rotas. Alguns dos atributos do BGP são:

• AS_path
• Next hop
• Local preference
• Multi-Exit Discriminator (MED)
• Origin
• Atomic Aggregator
• Agregator
• Community
• Weight

Os atributos e outras características do BGP4 serão explicados em detalhes na próxima parte deste artigo.

Conclusão

Nesta primeira parte do artigo, foi mostrado como era a arquitetura inicial da Internet e sua evolução. Com o crescimento da rede, tornou-se necessária a criação de sistemas automatizados de configuração de rotas. Para tal, inicialmente, foi desenvolvido o EGP e, posteriormente, veio o BGP. Foram abordados, ainda que superficialmente, alguns conceitos e características do BGP-4. Na continuação deste artigo, será feita uma abordagem mais profunda do protocolo, com exemplos de configuração baseados na implementação da Cisco Systems em seus roteadores.

Referências bibliográficas

Internetworking with TCP/IP - Principles, Protocols and Architecture
Douglas E. Comer, 3^rd Edition, 1995, Prentice Hall

Routing In The Internet
Christian Huitema, 1995, Prentice Hall

Internet Routing Architectures
Bassam Halabi, 1997, Cisco Press

RFC 1771
A Border Gateway Protocol 4 (BGP-4)
ftp://ftp.isi.edu/in-notes/rfc1771.txt

RFC 1772
Application of the Border Gateway Protocol in the Internet
ftp://ftp.isi.edu/in-notes/rfc1772.txt

RFC 1773
Experience with the BGP-4 protocol
ftp://ftp.isi.edu/in-notes/rfc1773.txt

RFC 1930
Guidelines for creation, selection, and registration of an Autonomous System
ftp://ftp.isi.edu/in-notes/rfc1930.txt

RFC 1965
Autonomous System Confederations for BGP
ftp://ftp.isi.edu/in-notes/rfc1965.txt

BGP Route Reflection - An alternative to full mesh IBGP
ftp://ftp.isi.edu/in-notes/rfc1966.txt

RFC 1997
BGP Communities Attribute
ftp://ftp.isi.edu/in-notes/rfc1997.txt

RFC 2270
Using a Dedicated AS for Sites Homed to a Single Provider
ftp://ftp.isi.edu/in-notes/rfc2270.txt

Sites relacionados

BGP-4 Protocol Overview
http://www.FreeSoft.org/CIE/Topics/88.htm

Using the Border Gateway Protocol for Interdomain Routing
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/icsbgp4.htm