Este tema tende a ser bastante interessante, já que muitos têm me perguntado algo sobre ao menos um deles, e no fórum do blog “pipocam” discussões sobre o assunto de tempos em tempos. A questão enviada para a seção “P&R” e selecionada para a montagem deste post segue abaixo:

“Eu estou começando a estudar mais a fundo as opções e protocolos de balance, até porque aqui onde estou trabalhando roda GLBP com HSRP, dependendo da localidade da filial. É muito interessante, e tende a cada vez mais se tornar necessário nos ambientes de hoje. Poste lá no site sua visão sobre isso por favor, e o que vc pode filtrar, como explicação do funcionamento. Ajudará a todos.”

Lembrando que o assunto deve ser de interesse especial aos candidatos ao CCNP, já que é assunto cobrado pela certificação. Vamos então ao post sobre o assunto, visando elucidar a questão acima descrita. Quando falamos de alta disponibilidade de roteadores, atualmente, temos 3 protocolos que se destacam, tornando isso possível de uma forma, ou de outra. Vejam bem que não estou dizendo que temos APENAS estes 3 protocolos. Outros fabricantes também possuem protocolos proprietários que podem operar de forma semelhante (como o SMLT, da Nortel). Como o blog foca em Cisco, vamos falar dos protocolos mais aplicados em nosso “mundinho”. Dos três protocolos, dois são proprietários Cisco (HSRP e GLBP), e outro é independente de fabricantes (VRRP, criado e mantido pelo IETF).

VRRP e HSRP

O protocolo Cisco Hot-Standby Routing Protocol (HSRP) e o IETF Virtual Routing Redundancy Protocol (VRRP) são particamente idênticos, em termos de funcionalidades e configuração. O HSRP, por ser proprietário Cisco, apenas roda em elementos Cisco. O VRRP, por sua vez, roda em qualquer elemento que suporte a RFC 3768.

A idéia por trás de ambos os protocolos é relativamente simples: Chavear o tráfego de um roteador para outro, em caso de queda no link, ou do próprio roteador. O diagrama abaixo ilustra a situação:

Neste diagrama, temos 2 routers (A e B), ambos conectados aos respectivos provedores e ao switch da LAN. Tanto o HSRP quanto o VRRP possibilitam que a rede local (LAN) “enxergue” ambos os routers via um único endereço IP (192.168.10.3, no exemplo), conhecido como “Virtual IP”, ou “VIP”, já que este seria o endereço IP de um roteador virtual. Ou seja, nas máquinas da rede local, o default gateway à ser configurado seria apenas um: 192.168.10.3. Entretanto, os protocolos HSRP e VRRP não fazem o balanceamento do tráfego entre os 2 roteadores, por default. Ao invés disso, um dos dois routers é configurado como “ACTIVE” (ou “MASTER”, no caso do VRRP), e o outro, como “STANDBY” (ou BACKUP, no caso do VRRP). Desta forma, o tráfego gerado pela LAN sempre atravessará o mesmo router (o que se encontra como ACTIVE, na rede). O outro router apenas será usado caso o router ACTIVE venha a ter problemas. Tanto o HSRP quanto o VRRP permitem que se monitore interfaces ou mesmo entradas na tabela de roteamento. É possível, portanto, informar aos routers participantes do grupo HSRP ou VRRP o que deve ser observado para que o tráfego cheveie automaticamente para o router STANDBY. Por exemplo, se uma entrada na tabela de roteamento “sumir”, ou se a interface serial “cair”, por algum motivo, no router que se encontrava como ACTIVE na rede, este pode ter sua prioridade decrescida e o router que antes era o STANDBY automaticamente - e rapidamente - passaria a ser o ACTIVE, e todo o tráfego passaria a ser desviado para ele.

Em termos de configuração básica, ambas são semelhantes. O router com maior prioridade será o ACTIVE no HSRP ou o MASTER, no VRRP. Existem, entretanto, algumas diferenças entre o HSRP e o VRRP:

• Apesar de ambos suportarem o modo de preempção, ou seja, um router STANDBY assume automaticamente a função de ACTIVE se sua prioridade - em um dado momento - for maior que a do antigo router que se encontrava como ACTIVE na rede. Se posteriormente, a falha for solucionada, o router ACTIVE original retoma suas funções automaticamente. O VRRP, entretanto, tem este modo ativo por default no router MASTER. No HSRP este modo deve ser manualmente ativado.
• O VRRP possui timers ligeiramente mais curtos, ou seja, em caso de falha no MASTER, o BACKUP assume de modo relativamente mais rápido que se comparado à operação do HSRP.
• No VRRP, o endereço ip do grupo VRRP (o VIP) é o mesmo endereço IP de um dos roteadores. No HSRP, o endereço VIP do grupo HSRP é um endereço exclusivo.
• VRRP é independente de fabricante, enquanto o HSRP é proprietário Cisco
• Existem outras diferenças mínimas (como o endereço IP de multicast utilizado por um, e por outro), mas não vêm ao caso para este post…

Abaixo, alguns exemplos de configurações de ambos os protocolos, usando como modelo o mesmo diagrama ilustrado mais acima:

VRRP:

Router A (MASTER)

interface F1/0
 ip address 192.168.10.1 255.255.255.0
 vrrp 1 description GRUPO_VRRP_1
 vrrp 1 ip 192.168.10.1 !Endereço IP do MASTER
 vrrp 1 priority 120 !(default é 100)
 vrrp 1 preempt
 no shutdown

Router B (BACKUP)

interface F1/0
 ip address 192.168.10.2 255.255.255.0
 vrrp 1 description GRUPO_VRRP_1
 vrrp 1 ip 192.168.10.1 !Endereço IP do MASTER
 vrrp 1 priority 110 !Default é 100
 vrrp 1 preempt
 no shutdown

Para realizar o monitoramento de elementos, é preciso antes definir o que será monitorado, no modo global de configuração:

RouterA(config)# track 2 interface serial 1/0 line-protocol

Uma vez definido o objeto à ser monitorado, podemos incluí-lo na configuração do VRRP:

Router A (MASTER)

interface F1/0 vrrp 1 track 2 decrement 20

O resultado disso é que, se a interface Serial1/0 do router A (que é o MASTER) cair, sua prioridade terá um decréscimo de 20 (120-20=100), ficando mais baixa que a prioridade do Router B (110), que consequentemente assumirá como MASTER já que o modo de preempção está ativo.

HSRP:

Como foi dito, as configs do HSRP são semelhantes às do VRRP:

Router A (ACTIVE)

interface F1/0
 ip address 192.168.10.1 255.255.255.0
 standby 1 description GRUPO_VRRP_1
 standby 1 ip 192.168.10.3 !Endereço IP do Grupo HSRP
 standby 1 priority 120 !(default é 100)
 standby 1 preempt
 no shutdown

Router B (STANDBY)

interface F1/0
 ip address 192.168.10.2 255.255.255.0
 standby 1 description GRUPO_VRRP_1
 standby 1 ip 192.168.10.3 !Endereço IP do Grupo HSRP
 standby 1 priority 110 !Default é 100
 standby 1 preempt
 no shutdown

Quanto ao monitoramente dos elementos, o processo é idêntico ao descrito para o VRRP:

RouterA(config)# track 2 interface serial 1/0 line-protocol

Uma vez definido o objeto à ser monitorado, podemos incluí-lo na configuração do HSRP:

Router A (MASTER)

interface F1/0 standby 1 track 2 decrement 20

Como podemos observar, as configurações para ambos os protocolos são relativamente simples.

Mas… e o GLBP? O GLBP (Gateway Load Balance Protocolo) é um protocolo proprietário Cisco, criado em 2005. Portanto, é um protocolo relativamente recente. A idéia por trás do GLBP era prover algo que nem o HSRP nem o VRRP conseguiam fazer de modo descomplicado: Balanceamento de carga entre os gateways. Como vimos, tanto o VRRP quanto o HSRP adotam o modo de operação “ACTIVE”/ “STANDBY”, ou seja, enquanto um router está sendo usado (”ACTIVE”), o outro permanece parado. Isso pode não ser muito interessante, especialmente quando temos links com as operadoras (ISPs) sendo subutilizados. O GLBP implementa o balanceamento de carga de forma relativamente simples, para contornar estas limitações.

PS: É importante mencionar que tanto o HSRP quanto o VRRP também suportam designs que possibilitem balanceamento de carga, por meio da criação de múltiplos grupos virtuais (MHSRP e MVRRP). Este método não é tão simples e não será abordado por este post, entretanto .

O modo como o GLBP implementa o balanceamento de carga é via implementação de múltiplos endereços MAC associados à um mesmo endereço IP. Ou seja, em uma rede local (LAN), você tem seus hosts apontando para um mesmo IP como default gateway, entretanto, os MACs associados à este IP, de host para host, pode ser diferente. Ou seja, o que o GLBP faz, na verdade, é um balanceamento de MACs, se pensarmos bem… . À cada solicitação ARP, o GLBP ativo nos routers responde com um MAC virtual diferente, resolvendo o mesmo endereço IP para o MAC address de um roteador diferente.

A figura abaixo procura ilustrar o que foi mencionado.

Apesar de comprir seu papel relativamente bem, o GLBP não faz um balanceamento de carga homogêneo. Isso porque o balanceamento não ocorre pacote por pacote.

Em termos de configuração, segue em linha com o que foi apresentado para o VRRP e para o HSRP:

Router A:

interface F0/0
 ip address 192.168.10.1 255.255.255.0
 glbp 1 ip 192.168.10.3
 glbp 1 priority 150

Router B:

interface F0/0
 ip address 192.168.10.2 255.255.255.0
 glbp 1 ip 192.168.10.3
 glbp 1 priority 140

É isso pessoal! Espero que tenham gostado, e o mais importante… entendido ! É possível praticar tudo o que foi colocado aqui no Dynamips / Dynagen. Não sei se o PT suporta estas features. Talvez valha a pena testar

Fontes pesquisadas:

VRRP: http://www.ietf.org/rfc/rfc3768.txt
HSRP: http://www.cisco.com/en/US/tech/tk648/tk362/tk321/tsd_technology_support_sub-protocol_home.html
GLBP: http://www.cisco.com/en/US/docs/ios/12_2t/12_2t15/feature/guide/ft_glbp.html

Depois de algum tempo sem postar tutoriais e labs para o Dynamips, bateu uma saudade ! Procurei pela NET um lab que implementasse os principais recursos deste protocolo, de modo que vocês, que estão estudando para o CCIP (ou mesmo para o BSCI do CCNP) tenham, em um único PC, um laboratório completo para testar praticamente todas as nuances e recursos que este sofisticado e complexo protocolo pode oferecer.

O lab proposto abaixo é composto de 10 roteadores. Portando, para rodá-lo em apenas 1 PC, este deve ser um tanto quanto potente. Existe sempre a opção de criar um lab distribuído, iniciando 2 ou mais instâncias do Dynamips em PCs diferentes. Se você não sabe como proceder para criar um lab distribuído, cheque os tutoriais sobre Dynamips disponíveis no blog. Se ainda assim não estiver claro, poste no comment e eu vejo se consigo explicar. Pode acabar sendo um bom tema para uma “Vídeo Aula” !

Na essência, do modo como está estruturado, este lab permite a implementação dos seguintes elementos:

• Multihoming para múltiplos ISP
• Aplicação de filtros usando os atributos BGP (ex: Weight, Local Preference, AS-Path, e MED)
• Multipath BGP
• BGP dampening
• ORF
• BGP Confederation
• BGP Route-Reflector
• BGP Next-Hop
• BGP route aggregation
• BGP Cluster
• e certamente… MUITO MAIS!!!

Para aqueles que buscam conhecer um pouco mais sobre o protocolo antes de sair tentando a sorte em um lab como este, recomendo o post sobre o BGP, aqui no blog, e também este link, da Rede Nacional de Pesquisas (RNP).

Bons estudos! Depois me contem se conseguiram implementá-lo!

Fonte: http://www.davidsudjiman.info/2008/03/06/bgp-lab-v01/

Marco.

Configs dos routers:

bgp_configs.zip

Config “.net” do Dynagen:

autostart = false
model = 3640

[localhost]

[[3640]]
image = ./c3640-js-mz.124-18.bin.image
workingdir = /bgp/private
ram = 128
slot0 = NM-1FE-TX
slot1 = NM-4T
disk0 = 8

idlepc = 0×604f7b2c

# Router 1
[[Router as1r1]]
f0/0 = S1 11

# Router 2
[[Router as1r2]]
f0/0 = S1 12
s1/0 = F1 2

# Router 3
[[Router as1r3]]
f0/0 = S1 13
s1/0 = F1 3

# Router 4
[[Router as5r1]]
s1/0 = F1 4

# Router 5
[[Router as2r2]]
f0/0 = S1 22
s1/0 = F1 5

# Router 6
[[Router as2r3]]
f0/0 = S1 23
s1/0 = F1 6

# Router 7
[[Router as3r1]]
s1/0 = F1 7

# Router 8
[[Router as2r4]]
f0/0 = S1 24
s1/0 = F1 8

# Router 9
[[Router as2r1]]
f0/0 = S1 21
s1/0 = F1 9

# Router 10
[[Router as4r1]]
s1/0 = F1 10

[[ETHSW S1]]
11 = access 111
12 = access 111
13 = access 111

21 = access 222
22 = access 222
23 = access 222
24 = access 222

[[FRSW F1]]
2:205 = 5:502
2:215 = 5:512
2:206 = 6:602

3:306 = 6:603
3:307 = 7:703

4:407 = 7:704

7:710 = 10:107

8:810 = 10:108

Pessoal,

Partindo de uma questão que postei semana passada e fiquei devendo a resposta, resolvi escrever este pequeno artigo sobre os componentes do MPLS. O Marco já fez dois belos posts sobre MPLS: Multi Protocol Label Switching - Parte I e Multi Protocol Label Switching - Parte II. Vale a pena ler antes para se familiarizar com o que você vai ler abaixo.

Uma observação importante sobre o que está escrito a seguir: tudo está baseado em tecnologias Cisco. Mas não muda muito para outros fabricantes, ok?

Como vocês já leram no post do Marco, labels são adicionados ou removidos pelos Edge LSRs (Label Switching Routers), também conhecidos como LERs (Label Edge Routers) e, em alguns casos, como PEs (Provider Edges). Estes são os roteadores que estão realmente na boda da rede MPLS, fazendo a a conexão entre uma rede não-MPLS (pode ser ATM, Frame-Relay, Ethernet, etc.) e uma rede MPLS. Os roteadores puramente MPLS, conhecidos como LSRs, encaminham tráfego baseados somente em labels. Quando o pacote chega ao destino ou próximo dele, na saída da rede MPLS há outro Edge LSR, que agora remove o label e faz o roteamento do pacote para fora da rede MPLS.

Para que tudo isso funcione, em termos de “arquitetura”, o MPLS possui dois mecanismos separados:

• Control Plane: Matém a troca de informações sobre roteamento e labels entre dispositivos adjacentes. Para o roteamento, ele lida com todas as complexidades dos protocolos de roteamento como OSPF, EIGRP, IS-IS e BGP por exemplo, que, como vocês sabem, roteiam pacotes com base no IP de destino. Por outro lado, por também cuidar dos labels, ele trabalha com protocolos de “roteamento“ baseados em labels, Como o TDP(Tag Distribution Protocol) e o LDP (Label Distribution Protocol), sendo o último o mais utilizado.

• Data Plane: Responsável por encaminhar o tráfego baseado somente em labels, utilizando para isso informações geradas e coletadas pelo Control Plane. O Data Plane também é conhecido como Fowarding Plane.

O que qualquer router habilitado para MPLS faz, ou seja, o que qualquer LSR faz é, basicamente, utilizar o Control Plane para, através dos Protocolos de Roteamento, descobrir e escolher os melhores caminhos, que no MPLS são conhecidos como LSPs ( Label Switching Paths) e enviar este mapeamento para que o Data Plane execute. Simples não?!

Como analogia, imagine um rally. Vão sempre dois caras no carro. Um é o Navegador, que mapeia o caminho todo, faz todo planejamento e, durante a execução, fica monitorando o percurso afim de garantir que o caminho escolhido é o melhor ou ao menos é o pré-determinado. Este Navegador é o Control Plane. Já o Motorista executa o plano da melhor maneira possível , o mais rápido possível, sem se preocupar em ficar olhando o mapa ou o GPS. Simplesmente segue as instruções, na maior velocidade possível! Esse motorista é o Data Plane!

Se vocês gostaram do post e têm interesse em saber mais sobre MPLS, dependendo da participação e dos comentários, continuarei a série, falando no próximo post das essenciais tabelas que operam no Control Plane e no Data Plane: FIB, LIB e LFIB.

Abraços,

Fábio A. de Amorim

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

Olá Pessoal,

Segue questão sobre MPLS, afim de incentivar os estudos sobre esta tecnologia tão presente nas redes hoje e também de aproveitar o embalo dos posts do Marco sobre o assunto ( veja aqui ) .

Comentem!

Abraços,

Fábio A. de Amorim

- De acordo com a topologia abaixo, qual tabela será usada pelo roteador R1 se ele receber um pacote originado de 172.20.0.200 e destinado à 172.30.0.100?

a, Label Forwarding Information Base (LFIB)

b, Tabela de Adjacência

c, Forwarding Information Base (FIB)

d, Label Information Base (LIB)

e, Tabela de Roteamento

TestKinger: sua casa pode estar começando a cair!

É pessoal… conforme eu já imaginava, fosse por iniciativa da Cisco e/ou de outras empresas que oferecem certificações como a Microsoft e a Oracle, fosse por iniciativa das empresas de testes (VUE e Prometric), ou por um terceiro, alguém iria começar a tentar a sufocar os “espertinhos” que passam em exames decorando Testkings ou P4Sures.

Recentemente, a Cisco e a VUE anunciaram e o Marco replicou aqui no blog (Cisco and Pearson VUE Launch Global Test Delivery Exam Security Enhancements) medidas que visam ao menos inibir fraudes na realização dos exames de certificação.

A novidade neste sentido é um simulador que pode ser usado por empresas no processo de seleção para garantir que o profissional que ela está contratando realmente tem os conhecimentos que suas certificações dizem que ele tem

Que é possível é. Que é interessante, é também. Mas fica a pergunta: isso “pega”? Se o software for confiável e de bom custo-benefício, as empresas realmente o adotarão? Alguém discorda dessa idéia?

Segue matéria e link abaixo. Destaque para a última frase.

Abraços,

Fábio A. de Amorim

Link da matéria

Cisco simulator can help thwart exam cheating

Gambit Communications says its MIMIC Virtual Lab software can help resolve the cheating on Cisco certification tests

By Jim Duffy , Network World , 07/30/2008

A Nashua, N.H., maker of Cisco network simulators says its software can help enterprises make sure they are hiring legitimate Cisco-certified engineers to run their networks.

Gambit Communications says its MIMIC Virtual Lab software, which has been on the market for about four years, can help resolve the recent spate of cheating on Cisco certification tests by enabling enterprises to run network operations candidates through sample scenarios before hiring them. This allows enterprises to screen candidates to ensure they are not hiring fraudulent network operators at handsome salaries.

Cisco recently moved to thwart cheating on certification tests by employing photo identification requirements and a data forensics program. According to Cisco, pilot programs using the new detection methods have already uncovered 1,400 suspected cheaters who hired proxies to take the exams for them.

But Gambit claims the photo and forensics programs only go so far: what about the many unqualified candidates already hired by enterprises prior to the new Cisco enforcement programs?

Sit ‘em down and run them through a simulated lab environment, Gambit says.

Gambit’s CCNA Virtual LAB software starts at $99 and can be downloaded to a laptop or PC. It creates a simulated environment with seven Cisco devices – Catalyst 2950, 3550 and 6500 switches and 2620, 3640 and 7206 series routers — and users can type in IOS and SNMP commands to configure devices and protocols.

Test conductors and “students” can replace and establish LAN, WAN, ISDN and serial links, change IP addresses and create virtual LANs with the program, but cannot change the devices themselves. Also, the program is not certified by Cisco but is resold by a Cisco – certified training partner, Tech 2000. Cisco also uses the CCNA Virtual Lab’s predecessor, the MIMIC Simulator Suite for IOS, Gambit says.

Gambit says it has 1,000 customers for CCNA Virtual Lab since it was introduced in 2002, including AT&T, IBM, the U.S. Army and several financial firms.