12 de ago de 2009

Capitulo 3 - Design de Redes usando EIGRP, OSPF e BGP

Dando sequência aos estudos do curso de Arch, segue o que achei mais interessante nas seções que tratam de detalhes de Projeto de Protocolos de Roteamento:

EIGRP: Converge rapidamente quando há uma rota aplicável (feasible sucessor) no caso da falha do melhor link (sucessor). Sumarização, filtragem de queries e poucas vizinhanças ajudam na otimização da performance.
Múltiplos sistemas autônomos podem ser utilizados mas isto não limita o escopo das queries. Este artificio geralmente é usado como paliativo na hora de manter conectividade entre ASNs EIGRP de empresas distintas (solução provisória) ou para segmentar uma rede muito grande.
Quando se faz redistribuição entre sistemas autônomos EIGRP distintos, um dos problemas a se evitar é a realimentação de rotas (looping). A figura abaixo uma forma de "marcar" as rotas redistribuidas de um AS e filtrar a sua reentrada:



OSPF: A escalabilidade depende da sumarização e de como os LSAs são propagaqdos. Areas Stub e Totally Stub são mais eficientes em termos de performance. Na figura ao lado, temos um exemplo de Design OSPF com núcleo Full-mesh, uma estrutura hub and spoke de uma ou mais áreas para filiais remotas e Redes de Campus que exigem alta redundância.

BGP: no BGP, mais precisamente no iBGP, o grande dessafio para a escalabilidade está no fato de todos os vizinhos terem de estabelecer conexões TCP entre si, pois um vizinho iBGP não propaga as atualizações que recebe de outro vizinho:


Para resolver isto, temos duas opções:

1) Route Reflector - Cria-se clusters de roteadores onde um deles assume a função de refletir as atualizações de um cliente para todos os outros roteadores com os quais este mantém vizinhança. Pode-se criar mais de um Refletor para garantir redundância:


2) Confederation - Divide-se um Sistema Autônomo em "Sub-sistemas" autônomos que usam números de AS privados (64512 a 65535) que podem ter seus próprios IGPs. Para o mundo externo, o que é divulgado é apenas o AS Público (1 a 64511) que representa os vários sub-sistemas. Com isso, só é necessário Full-Mesh dentro de cada sub-sistema:


É possível ainda criar clusters Route Reflector dentro dos sub-sistemas de uma Confederation, embora isto ainda não seja muito comum.

Um comentário:

Adilson Florentino disse...

PessoALL,

Em relação ao OSPF, encontrei 3 técnicas que se propõe a diminuir o tempo de convergência:

Fast Hellos: Atualizações OSPF em menos de um segundo (cuidado com o número de vizinhos e o uso da CPU)
http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fasthelo.html

Incremental SPF: Uma pequena alteração no Algoritmo de Dijkstra que permite atualizações parciais e aumento de performance:
http://www.cisco.com/en/US/docs/ios/iproute/configuration/guide/irp_ospf_incre_spf_ps6350_TSD_Products_Configuration_Guide_Chapter.html

BFD - Bidirectional Forwarding Detection for OSPF. Rápida detecção de falhas de link usando hellos frequentes:
http://www.cisco.com/en/US/technologies/tk648/tk365/tk480/technologies_white_paper0900aecd80244005_ps6599_Products_White_Paper.html

Obs: BFD também pode ser usado no EIGRP, IS-IS e BGP

E ai, vamos "turbinar" um processo OSPF para testar ???

Abs,

LinkWithin

Related Posts with Thumbnails