Mudanças entre as edições de "Boas praticas para a implantacao do ospf em ambientes de isp"

De Wiki BPF
Ir para: navegação, pesquisa
m
Linha 7: Linha 7:
  
 
Caso você tenha muitas "lacunas" sobre questões mais fundamentais relacionadas a redes no geral, recomendo a leitura do seguinte artigo: [[Fundamentos de Roteamento para Provedores]].
 
Caso você tenha muitas "lacunas" sobre questões mais fundamentais relacionadas a redes no geral, recomendo a leitura do seguinte artigo: [[Fundamentos de Roteamento para Provedores]].
 +
 +
Em tempo, este artigo dissemina boas práticas para um conjunto contendo 11 (onze) situações envolvendo o OSPF em ambientes de ISP:
 +
 +
'''''1) Mantenha o OSPF dedicado apenas para os prefixos internos da rede do ISP'''''
 +
 +
'''''2) Opte por um projeto de rede Ethernet/IP hierárquico, estruturado e modular'''''
 +
 +
'''''3) Elabore um plano de endereçamento IPv4 e IPv6 adequado para acomodar as interfaces Loopback e os links internos da sua rede'''''
 +
 +
'''''4) Configure os enlace físicos ponto a ponto como redes OSPF ponto-a-ponto'''''
 +
 +
'''''5) Configure corretamente a banda de referência do OSPF para evitar problemas com a derivação de custos de interfaces OSPF'''''
 +
 +
'''''6) Sumarize as rotas OSPF sempre que possível, mas cuidado com os problemas quanto a esta prática nas redes MPLS'''''
 +
 +
'''''7) Saiba quando e onde implementar Áreas especiais do OSPF'''''
 +
 +
'''''8) Evite o uso de Virtual-Links!'''''
 +
 +
'''''9) Sempre que possível, opte por um protocolo IGP que não seja o OSPF para clientes L3VPN MPLS'''''
 +
 +
'''''10) Proteja o seu OSPF contra determinados riscos de segurança'''''
 +
 +
'''''11) Opte por soluções mais apropriadas para engenharia de tráfego, evitando manipulações frequentes da métrica do OSPF'''''
 +
 
[[Arquivo:Bpf-ospf-1.png|centro|miniaturadaimagem|900x900px|Boas Práticas para a Implantação do OSPF em Ambientes de ISP, by Leonardo Furtado @ Brasil Peering Forum]]
 
[[Arquivo:Bpf-ospf-1.png|centro|miniaturadaimagem|900x900px|Boas Práticas para a Implantação do OSPF em Ambientes de ISP, by Leonardo Furtado @ Brasil Peering Forum]]
  
Linha 42: Linha 67:
 
[[Arquivo:Bpf-ospf-3.png|centro|miniaturadaimagem|1092x1092px|Diagrama ilustrativo sobre um projeto de rede hierárquica e exemplos de funções prestadas por cada camada]]
 
[[Arquivo:Bpf-ospf-3.png|centro|miniaturadaimagem|1092x1092px|Diagrama ilustrativo sobre um projeto de rede hierárquica e exemplos de funções prestadas por cada camada]]
  
==== 3) Elabore um plano de endereçamento IPv4 e IPv6 adequado para os links internos da sua rede ====
+
==== 3) Elabore um plano de endereçamento IPv4 e IPv6 adequado para acomodar as interfaces Loopback e os links internos da sua rede ====
 
Um plano de endereçamento IP hierárquico, adequado e eficiente, resolverá muitos dos desafios introduzidos pelos próprios protocolos de roteamento IGP, principalmente no que diz respeito à escalabilidade, tempo de convergência, e à estabilidade da infraestrutura. O endereçamento IP precisa ser bem "encaixado" sobre a topologia da rede, e isto será um alívio para quando você precisar crescer com a rede usando o OSPF em múltiplas áreas.
 
Um plano de endereçamento IP hierárquico, adequado e eficiente, resolverá muitos dos desafios introduzidos pelos próprios protocolos de roteamento IGP, principalmente no que diz respeito à escalabilidade, tempo de convergência, e à estabilidade da infraestrutura. O endereçamento IP precisa ser bem "encaixado" sobre a topologia da rede, e isto será um alívio para quando você precisar crescer com a rede usando o OSPF em múltiplas áreas.
  
Linha 74: Linha 99:
 
|'''Broadcast   '''  
 
|'''Broadcast   '''  
 
|• Uma rede multiaccess broadcast. Aqui há a expectativa que dois ou mais roteadores rodando o OSPF sejam vizinhos através da mesma subrede IP.
 
|• Uma rede multiaccess broadcast. Aqui há a expectativa que dois ou mais roteadores rodando o OSPF sejam vizinhos através da mesma subrede IP.
• Por este motivo, é mandatório a presença de um roteador designado (Designated Router ou DR), e, recomendado, o roteador designado de backup (BDR)
+
• Por este motivo, é mandatório a presença de um roteador designado (Designated Router ou DR), e, recomendado, ocorrendo naturalmente, do roteador designado de backup (BDR).
 
|Todas as redes Ethernet, incluindo interfaces L3 ou virtuais L3 (VLAN, SVI, BVI, BDI, etc.).
 
|Todas as redes Ethernet, incluindo interfaces L3 ou virtuais L3 (VLAN, SVI, BVI, BDI, etc.).
  
Linha 82: Linha 107:
 
|-
 
|-
 
|'''Point-to-point'''
 
|'''Point-to-point'''
|• Uma rede que une um par de roteadores. Aqui assumimos que a conexão física ou lógica vá atender a comunicação entre apenas dois roteadores, e não mais.
+
|• Uma rede que une um par de roteadores. Aqui assumimos que a conexão física ou lógica vá atender a comunicação entre apenas dois roteadores, e não mais que isto.
 
• Por este motivo, não são requeridos as funções DR / BDR para este segmento.
 
• Por este motivo, não são requeridos as funções DR / BDR para este segmento.
 
|Originalmente prevendo enlaces Seriais usando PPP, HDLC.
 
|Originalmente prevendo enlaces Seriais usando PPP, HDLC.
Linha 116: Linha 141:
 
• point-to-multipoint
 
• point-to-multipoint
  
•Modos proprietários Cisco:
+
• Modos proprietários Cisco:
  
 
• broadcast
 
• broadcast
Linha 129: Linha 154:
 
Se você for um ISP completamente isento de infraestruturas legadas, ou seja, tendo o Ethernet como única tecnologia de enlace de toda a sua rede, você não precisará preocupar-se com o OSPF em NBMA.
 
Se você for um ISP completamente isento de infraestruturas legadas, ou seja, tendo o Ethernet como única tecnologia de enlace de toda a sua rede, você não precisará preocupar-se com o OSPF em NBMA.
 
|}
 
|}
 +
Para facilitar este entendimento, forneço uma apresentação visual destes tipos de redes OSPF, com ênfase nas melhores práticas. Identifique-se com os tipos de conexões mostradas a seguir, e certifique-se de configurar as suas interfaces de roteadores habilitadas para o OSPF conforme as sugestões de "network types":
  
==== 5) Configure corretamente a banda de referência do OSPF ====
+
[[Arquivo:Bpf-ospf-4.png|centro|miniaturadaimagem|1024x1024px|Exemplos de tipos de redes OSPF, em especial as boas práticas para cada cenário]]
 +
 
 +
==== 5) Configure corretamente a banda de referência do OSPF para evitar problemas com a derivação de custos de interfaces OSPF ====
 
Talvez uma das coisas mais negligenciadas por vários ISPs: os profissionais simplesmente se esquecem de definir a banda de referência do OSPF!
 
Talvez uma das coisas mais negligenciadas por vários ISPs: os profissionais simplesmente se esquecem de definir a banda de referência do OSPF!
  
 
Permita-me explicar algo: a métrica do OSPF é o "''Cost''" (custo), e muitos afirmam que o custo de uma interface é inversamente proporcional à sua banda. Isto está parcialmente correto. Na prática, o OSPF determina os custos da seguinte forma:
 
Permita-me explicar algo: a métrica do OSPF é o "''Cost''" (custo), e muitos afirmam que o custo de uma interface é inversamente proporcional à sua banda. Isto está parcialmente correto. Na prática, o OSPF determina os custos da seguinte forma:
  Custo = Banda de Referência / Banda da Interface
+
  Custo = Banda de Referência (em bps) / Banda da Interface (em bps)
 
O problema é que a banda de referência considerada pelo OSPF na maioria das plataformas/equipamentos é de 100 Mbps (cem megabits por segundo!). Isto significa que qualquer interface de roteador que possuir banda/capacidade igual ou superior a 100 Mbps terá o custo de... "1" (um)! Você vê algum problema nisto?
 
O problema é que a banda de referência considerada pelo OSPF na maioria das plataformas/equipamentos é de 100 Mbps (cem megabits por segundo!). Isto significa que qualquer interface de roteador que possuir banda/capacidade igual ou superior a 100 Mbps terá o custo de... "1" (um)! Você vê algum problema nisto?
  
 
Ou seja, em uma rede onde você possuir interfaces 1 Gbps, 10 Gbps, 40 Gbps, e, talvez, 100 Gbps, enfim, todas as interfaces acima de 100 Mbps terão o custo de 1, e isto significa que a convergência do OSPF não será capaz de compreender as diferenças entre estas capacidades reais, e que, consequentemente, não conseguirá compreender que um caminho com largura de banda de 40 Gbps é melhor que um caminho que tenha largura de banda de 1 Gbps. E o chamado e indesejável '''''roteamento subótimo''''' (''suboptimal routing'') poderá existir, pois uma "melhor rota" poderá ser uma rota que envolve um enlace de 1 Gbps, ao invés de considerar como melhor rota um enlace que ofereça 40 Gbps. Vejamos algumas situações considerando o valor de banda de referência padrão, ou seja, 100 Mbps:
 
Ou seja, em uma rede onde você possuir interfaces 1 Gbps, 10 Gbps, 40 Gbps, e, talvez, 100 Gbps, enfim, todas as interfaces acima de 100 Mbps terão o custo de 1, e isto significa que a convergência do OSPF não será capaz de compreender as diferenças entre estas capacidades reais, e que, consequentemente, não conseguirá compreender que um caminho com largura de banda de 40 Gbps é melhor que um caminho que tenha largura de banda de 1 Gbps. E o chamado e indesejável '''''roteamento subótimo''''' (''suboptimal routing'') poderá existir, pois uma "melhor rota" poderá ser uma rota que envolve um enlace de 1 Gbps, ao invés de considerar como melhor rota um enlace que ofereça 40 Gbps. Vejamos algumas situações considerando o valor de banda de referência padrão, ou seja, 100 Mbps:
 
  '''Interface Fast Ethernet (100 Mbps)'''
 
  '''Interface Fast Ethernet (100 Mbps)'''
  Custo = 100 / 100
+
  Custo = 100000000 / 100000000
 
  Custo = 1
 
  Custo = 1
  
 
  '''Interface Gigabit Ethernet (1 Gbps)'''
 
  '''Interface Gigabit Ethernet (1 Gbps)'''
  Custo = 100 / 1000
+
  Custo = 100000000 / 1000000000
 
  Custo = 1
 
  Custo = 1
  
 
  '''Interface Ten Gigabit Ethernet (10 Gbps)'''
 
  '''Interface Ten Gigabit Ethernet (10 Gbps)'''
  Custo = 100 / 10000
+
  Custo = 100000000 / 10000000000
 
  Custo = 1
 
  Custo = 1
 
E assim por diante, para 40 e 100 Gbps, por exemplo.
 
E assim por diante, para 40 e 100 Gbps, por exemplo.
  
 +
OBS: obviamente não há escala negativa (valores de métricas abaixo de 0), portanto, com a banda de referência padrão (100 Mbps), o custo OSPF de interfaces igual ou superior a 100 Mbps será sempre "1".
 +
[[Arquivo:Bpf-ospf-5.png|centro|miniaturadaimagem|900x900px|Exemplo de consequências com o valor padrão de banda de referência do OSPF em uma rede]]
 
<u>Sugestões:</u> configure a banda de referência do OSPF em todos os roteadores para a capacidade máxima suportada por todos os equipamentos. Se todo os seus roteadores suportarem a configuração da banda de referência para 100 Gbps, faça-o! Do contrário, configure então a banda de referência para 40 Gbps, e ajuste os custos manualmente nas interfaces 40 Gbps e 100 Gbps para ter a granularidade necessária e exigida pelo seu projeto.
 
<u>Sugestões:</u> configure a banda de referência do OSPF em todos os roteadores para a capacidade máxima suportada por todos os equipamentos. Se todo os seus roteadores suportarem a configuração da banda de referência para 100 Gbps, faça-o! Do contrário, configure então a banda de referência para 40 Gbps, e ajuste os custos manualmente nas interfaces 40 Gbps e 100 Gbps para ter a granularidade necessária e exigida pelo seu projeto.
  
 
Em último caso, defina os custos manualmente nas interfaces. Mas, no entanto, procure resolver a questão primeiro com a configuração do parâmetro global (banda de referência), e evite ter que intervir com a configuração dos custos manualmente nas interfaces.
 
Em último caso, defina os custos manualmente nas interfaces. Mas, no entanto, procure resolver a questão primeiro com a configuração do parâmetro global (banda de referência), e evite ter que intervir com a configuração dos custos manualmente nas interfaces.
  
==== 6) Sumarize as rotas OSPF sempre que possível, mas cuidado com os problemas no MPLS ====
+
==== 6) Sumarize as rotas OSPF sempre que possível, mas cuidado com os problemas quanto a esta prática nas redes MPLS ====
 
Conforme comentado previamente, o protocolo de roteamento OSPF somente suporta a sumarização de rotas nativas do OSPF pelos roteadores de borda de área (ABR) e de rotas externas redistribuídas para o OSPF por roteadores ASBR. E isto significa que a sumarização de rotas nativas do OSPF só é possível em projetos com múltiplas áreas.  
 
Conforme comentado previamente, o protocolo de roteamento OSPF somente suporta a sumarização de rotas nativas do OSPF pelos roteadores de borda de área (ABR) e de rotas externas redistribuídas para o OSPF por roteadores ASBR. E isto significa que a sumarização de rotas nativas do OSPF só é possível em projetos com múltiplas áreas.  
  
 
Se o seu ISP possuir em sua rede uma única área OSPF (single area), não será possível sumarizar rotas OSPF neste tipo de ambiente.
 
Se o seu ISP possuir em sua rede uma única área OSPF (single area), não será possível sumarizar rotas OSPF neste tipo de ambiente.
  
'''<u>OBS: não sumarize o bloco alocado/dedicado para endereçar as interfaces Loopback (com os endereços /32 e /128) de seus roteadores!</u>''' Especialmente se aa sua rede MPLS possuir LSPs sendo estendido para o perímetro de Acesso, pois, neste caso, haverá a "quebra" dos LSPs e a consequente perda de conectividade.
+
'''<u>OBS: cuidado com a sumarização do bloco alocado/dedicado para endereçar as interfaces Loopback!</u>''' Especialmente se a sua rede MPLS possuir LSPs sendo estendidos para o perímetro de Acesso, pois, neste caso, haverá a "quebra" dos LSPs, e a consequente perda de conectividade. Exemplos de LSP "fim a fim" incluem L2VPN e L3VPN. Redes que contam com túneis de engenharia de tráfego entre roteadores especificamente de Core (P-routers) também estão sujeitas ao problema de quebra de LSP fim a fim.
 +
 
 +
A ilustração a seguir demonstra esta situação e fornece três alternativas para evitarmos este problema com a sumarização de prefixos em uma rede MPLS. O roteador P-1 está com
 +
[[Arquivo:Bpf-ospf-6.png|centro|miniaturadaimagem|1024x1024px|As complicações quanto a sumarização de prefixos em um backbone MPLS, e a possível perda de conectividade de serviços na rede]]
  
Por que você deveria sumarizar rotas do seu IGP, mas, lembrando, não fazendo para o bloco que atende os endereços IP das interfaces Loopback dos seus roteadores?
+
Por que você deveria sumarizar rotas do seu IGP, mas, lembrando, não fazendo para o bloco que atende os endereços IP das interfaces Loopback dos seus roteadores (ou adotando outras medidas cautelares)?
 
* Os LSA "detalhados" (Type 1 - Router, e Type 2 - Network) ficam confinados nas áreas onde são produzidos. Isto é, não cruzam de uma área para outra.
 
* Os LSA "detalhados" (Type 1 - Router, e Type 2 - Network) ficam confinados nas áreas onde são produzidos. Isto é, não cruzam de uma área para outra.
 
* Os roteadores ABR, os quais conectam uma ou mais áreas para a Area 0.0.0.0 (backbone), fazem um "resumo" (e não uma sumarização) das redes IP de cada área a anunciam estes resumos para a Area 0.0.0.0, assim como produzem o resumo das redes IP da Area 0.0.0.0 e injetam isto para as demais áreas onde possuírem interfaces configuradas para o OSPF.
 
* Os roteadores ABR, os quais conectam uma ou mais áreas para a Area 0.0.0.0 (backbone), fazem um "resumo" (e não uma sumarização) das redes IP de cada área a anunciam estes resumos para a Area 0.0.0.0, assim como produzem o resumo das redes IP da Area 0.0.0.0 e injetam isto para as demais áreas onde possuírem interfaces configuradas para o OSPF.
Linha 182: Linha 215:
 
*** Ganha-se muito na questão de estabilidade geral da rede!
 
*** Ganha-se muito na questão de estabilidade geral da rede!
 
Os benefícios quanto à sumarização de rotas são notórios: diminuição dos tamanho dos bancos de dados do OSPF (LSDB), diminuição das rotas OSPF da tabelas de roteamento (RIB), diminuição da frequência e propagação de mensagens LSU (os quais transportam os LSAs), ou seja, menor "falatório", consequentemente menor overhead de processamento e melhores tempos de convergência para a rede.
 
Os benefícios quanto à sumarização de rotas são notórios: diminuição dos tamanho dos bancos de dados do OSPF (LSDB), diminuição das rotas OSPF da tabelas de roteamento (RIB), diminuição da frequência e propagação de mensagens LSU (os quais transportam os LSAs), ou seja, menor "falatório", consequentemente menor overhead de processamento e melhores tempos de convergência para a rede.
 +
 +
==== 7) Saiba quando e onde implementar Áreas especiais do OSPF ====
 +
 +
==== 8) Evite o uso de Virtual-Links! ====
 +
 +
==== 9) Sempre que possível, opte por um protocolo IGP que não seja o OSPF para clientes L3VPN MPLS ====
 +
 +
==== 10) Proteja o seu OSPF contra determinados riscos de segurança ====
 +
 +
==== 11) Opte por soluções mais apropriadas para engenharia de tráfego, evitando manipulações frequentes da métrica do OSPF ====
  
 
=== Momento didático: por que o OSPF? ===
 
=== Momento didático: por que o OSPF? ===

Edição das 20h51min de 3 de janeiro de 2020

Boas Práticas para a Implantação do OSPF em Ambientes de ISP

Introdução

Este artigo trata única e exclusivamente do tema OSPF, e pouco será discutido acerca de conceitos de roteamento e outros pré-requisitos para a compreensão e configuração do OSPF. Ou seja, para este artigo, eu estou assumindo que você já seja um profissional de redes e com alguma prática na configuração e suporte do OSPF, assim como de outros serviços e protocolos de roteamento IPv4 e IPv6.

Para constar, o OSPF é um daqueles componentes de seu projeto técnico que, se você fizer a coisa certa, muito raramente experimentará qualquer tipo de problema. Quando adotando as boas práticas sugeridas por este artigo, será o tipo de protocolo ou serviço em que configura-se, literalmente, apenas uma única vez.

Caso você tenha muitas "lacunas" sobre questões mais fundamentais relacionadas a redes no geral, recomendo a leitura do seguinte artigo: Fundamentos de Roteamento para Provedores.

Em tempo, este artigo dissemina boas práticas para um conjunto contendo 11 (onze) situações envolvendo o OSPF em ambientes de ISP:

1) Mantenha o OSPF dedicado apenas para os prefixos internos da rede do ISP

2) Opte por um projeto de rede Ethernet/IP hierárquico, estruturado e modular

3) Elabore um plano de endereçamento IPv4 e IPv6 adequado para acomodar as interfaces Loopback e os links internos da sua rede

4) Configure os enlace físicos ponto a ponto como redes OSPF ponto-a-ponto

5) Configure corretamente a banda de referência do OSPF para evitar problemas com a derivação de custos de interfaces OSPF

6) Sumarize as rotas OSPF sempre que possível, mas cuidado com os problemas quanto a esta prática nas redes MPLS

7) Saiba quando e onde implementar Áreas especiais do OSPF

8) Evite o uso de Virtual-Links!

9) Sempre que possível, opte por um protocolo IGP que não seja o OSPF para clientes L3VPN MPLS

10) Proteja o seu OSPF contra determinados riscos de segurança

11) Opte por soluções mais apropriadas para engenharia de tráfego, evitando manipulações frequentes da métrica do OSPF

Boas Práticas para a Implantação do OSPF em Ambientes de ISP, by Leonardo Furtado @ Brasil Peering Forum

Resumo de boas práticas para o OSPF em infraestruturas de redes de ISPs

Para aqueles um tanto "impacientes" ou que necessitem de respostas mais rápidas e diretas.

1) Mantenha o OSPF dedicado apenas para os prefixos internos da rede do ISP

No que diz respeito às boas práticas para projetos de redes em ISP, toda e qualquer rota IGP oriunda de um protocolo de roteamento dinâmico - e isto obviamente inclui o OSPF - ou de rotas estáticas, deve servir apenas para quatro propostas primárias:

  1. Transportar as sessões IBGP entre os roteadores participantes no AS.
  2. Fornecer a devida conectividade para o endereço IP especificado pelo atributo NEXT_HOP das rotas BGP mantidas no seu sistema autônomo (AS). Ou seja, para fins de roteamento recursivo.
    • A conectividade para este endereço IP (NEXT_HOP) precisa ser o mais eficiente e otimizada possível, podendo seguir integralmente pelo processo de seleção de caminhos do OSPF ou por túneis de engenharia de tráfego (MPLS TE), ou por policies de engenharia de tráfego (SR-TE).
  3. Fornecer o roteamento necessário para o transporte das sessões LDP entre os roteadores participantes, no caso de ambientes MPLS.
  4. Fornecer conectividade para serviços internos específicos do próprio ISP.

Qualquer coisa fora disto é gambiarra ou fora das boas práticas. A título de boas práticas, para constar, rotas de trânsito, peering e de qualquer outra coisa externa deve ser provida pelo BGP, e não pelo OSPF, assim como rotas de clientes do ISP, as quais, também, devem ser rotas mantidas pelo BGP! Isto significa que você jamais deverá permitir no seu projeto que rotas de clientes sejam IGP na sua tabela de roteamento global ou que compartilhem o mesmo processo de roteamento que mantém toda a conectividade IGP do seu backbone! É viável usar o OSPF com clientes, no entanto, apenas em setups de L3VPN MPLS, ou seja, em VRFs dedicadas para clientes, numa relação chamada "PE-CE", e em combinação com MP-BGP no seu backbone para as famílias de endereços VPNv4 e VPNv6.

Já com relação aos assinantes PPPoE, as rotas /32 correspondentes a estes assinantes autenticados em um concentrador BNG/BRAS também não podem existir como rotas IGP na sua rede! Você, neste caso, poderia até agregar todo o bloco que corresponde aos assinantes autenticados em um concentrador BNG/BRAS (ex: um /22) em uma rota estática apontando para Null0, juntamente com um tag específico indicando uma ação para fins de redistribuição, e redistribuir esta rota estática com este tag para o OSPF como External Type-1, sem complicações, ou, melhor ainda, para o BGP, que é o que recomendo em todos os casos.

As consequências quanto ao não cumprimento desta boa prática: rotas de clientes na sua tabela de roteamento como IGP poderão representar uma ameaça nas questões de segurança e disponibilidade da sua rede, além de instabilidades e incidentes de convergência, e o inconveniente aumento de processamento decorrente de computações frequentes e excessivas do LSDB dos roteadores. E, por último, excesso de rotas IGP que poderão estourar os limites dos seus equipamentos.

O diagrama mostrado a seguir destaca esta boa prática, que é a de deixar o OSPF dedicado para o atendimento das quatro situações discutidas acima.

Diagrama ilustrando o OSPF dedicado para os links internos e loopbacks dos roteadores do ISP

2) Opte por um projeto de rede Ethernet/IP hierárquico, estruturado e modular

Em tese, você poderia interconectar os seus roteadores e switches do jeito que você desejasse em sua rede, e isto é uma grande verdade. No entanto, o arranjo topológico desorganizado e sem sentido de uma rede tende a incorrer em alguns indesejáveis desafios, além de introduzir impactos desnecessários sobre o funcionamento de determinados componentes lógicos especificados pelo seu projeto técnico. O bom funcionamento dos protocolos de roteamento IGP, em particular no caso do OSPF, exige algumas definições hierárquicas da topologia da rede.

Talvez você não saiba, mas o OSPF é disparado o protocolo de roteamento mais exigente em termos de organização topológica, pois, ao contrário dos demais protocolos, a sua abordagem em projetos de múltiplas áreas obriga o estabelecimento de uma hierarquia de dois níveis. Esta hierarquia de dois níveis não é opcional em projetos com múltiplas áreas OSPF, é mandatório!

O que seria um projeto de rede hierárquica + estruturada + modular? As famosas "camadas de função", tais como Acesso, Pré-Agregação, Agregação, Core e Borda de Serviços. Não, não são apenas nomes bonitos! Cada camada corresponde a conjuntos de especificações tecnológicas que ditam a padronização de funcionalidades/recursos que deverão operar naquela camada, assim como a concepção de arquitetura e plataforma de hardware e software a serem empregados naquela camada.

Dependendo do tamanho do seu ISP, uma única área OSPF pode ser considerada para todo o projeto. No entanto, na medida em que a sua rede for crescendo, a necessidade pelo estabelecimento do OSPF em múltiplas áreas será cada vez mais exigida, e, nestas horas, uma rede com boa apresentação hierárquica fará toda a diferença para os resultados almejados.

As consequências quanto ao não cumprimento desta boa prática: inabilidade de sumarizar apropriadamente as rotas OSPF, consequentemente estruturas de dados (LSDB e RIB) ficarão mais inchadas; excesso de "falatório" (distribuição de LSAs), impactos mais perceptíveis ou prolongados relacionados aos eventos de convergência da rede, especialmente quando ocorrerem oscilações dos links internos da rede, e você não conseguirá escalar tão bem quanto um projeto OSPF mais organizado neste sentido.

Mais do que ajudar o OSPF a fazer um bom trabalho: um projeto de redes adequado e com uma abordagem hierárquica promove muitos benefícios para diversos dos recursos lógicos e serviços da infraestrutura, além de facilitar muito a vida dos times de operações da rede! A ilustração a seguir mostra estas camadas, exemplifica algumas de suas funções, e destaca os principais benefícios desta abordagem:

Diagrama ilustrativo sobre um projeto de rede hierárquica e exemplos de funções prestadas por cada camada

3) Elabore um plano de endereçamento IPv4 e IPv6 adequado para acomodar as interfaces Loopback e os links internos da sua rede

Um plano de endereçamento IP hierárquico, adequado e eficiente, resolverá muitos dos desafios introduzidos pelos próprios protocolos de roteamento IGP, principalmente no que diz respeito à escalabilidade, tempo de convergência, e à estabilidade da infraestrutura. O endereçamento IP precisa ser bem "encaixado" sobre a topologia da rede, e isto será um alívio para quando você precisar crescer com a rede usando o OSPF em múltiplas áreas.

Um plano de endereçamento IP mal projetado e mal distribuído sobre os roteadores e enlaces da rede poderá resultar em complicações em diversas situações. Uma delas tem relação com a agregação ou sumarização de rotas do OSPF: o protocolo de roteamento OSPF é um tanto burocrático em alguns de seus recursos e facilidades. Para exemplificar, no OSPF é possível sumarizar rotas apenas nas seguintes circunstâncias:

  1. Sumarização de rotas OSPF no roteador de borda de área (Area Border Router ou ABR): rotas nativas do OSPF só podem ser sumarizadas nos roteadores ABR!
  2. Sumarização de rotas externas injetadas pelo roteador de borda de sistema autônomo (Autonomous System Boundary Router ou ASBR): no ponto de redistribuição de rotas de outros protocolos ou domínios de roteamento, ou seja, no ASBR, é possível, no momento da redistribuição, fazer a sumarização destas rotas externas redistribuídas para o OSPF.

Isto significa que:

a) Se a sua rede consistir de uma única área OSPF, não será possível sumarizar rotas OSPF nativas. Isto porque roteadores ABR só existem, obviamente, em projetos OSPF com duas ou mais áreas (multiárea).

b) Mesmo que a sua rede OSPF seja multiárea, se você foi negligente com a alocação e distribuição dos endereços IP, você será incapaz de sumarizar as rotas OSPF conforme desejado ou será completamente incapaz de fazê-lo.

Recomenda-se equipar o seu software de IPAM para projetar os blocos com bastante atenção e prevendo o crescimento ou a expansão da rede. Por exemplo:

  • Projete o endereçamento IPv4/IPv6 da sua rede para ser o mais compatível e hierárquico possível com relação à topologia da sua rede!
  • Elabore o seu plano de endereçamento prevendo cenários de expansão de longo prazo.
  • Separe um bloco contínuo e bem confortável de endereços IPv4 e IPv6 para atender as interfaces Loopback dos roteadores.
  • Separe um bloco contínuo e bem confortável de endereços IPv4 e IPv6 por área para atender as interfaces dos links ponto a ponto da rede.
    • Por mais que você hoje não tenha múltiplas áreas, busque promover esta antecipação de cenário futuro.
  • Separe um bloco contínuo e bem confortável por área de endereços IPv4 e IPv6 por área para endereçar outras partes internas, não ponto a ponto, de sua infraestrutura.

4) Configure os enlace físicos ponto a ponto como redes OSPF ponto-a-ponto

Uma "mexida" um tanto sutil e que, aparentemente, não faz muita diferença para os projetos com o OSPF. Mas não deixa de ser aquela história que "a soma de pequenas iniciativas promove grandes resultados".

Resumindo: recomenda-se configurar o OSPF para tratar as interfaces Ethernet físicas ou lógicas (incluindo interfaces VLAN) como ponto-a-ponto, ao invés do padrão "Broadcast". Há regras para isto. Consulte a tabela a seguir:

"Network Types" do OSPF
Network Type Descrição Exemplos
Broadcast    • Uma rede multiaccess broadcast. Aqui há a expectativa que dois ou mais roteadores rodando o OSPF sejam vizinhos através da mesma subrede IP.

• Por este motivo, é mandatório a presença de um roteador designado (Designated Router ou DR), e, recomendado, ocorrendo naturalmente, do roteador designado de backup (BDR).

Todas as redes Ethernet, incluindo interfaces L3 ou virtuais L3 (VLAN, SVI, BVI, BDI, etc.).

A proposta (boa prática) sugerida por este artigo:

Mantermos como redes "Broadcast" somente aquelas onde de fato possuírem dois ou mais roteadores e que devam formar adjacências OSPF entre si através de uma mesma subrede IP.

Point-to-point • Uma rede que une um par de roteadores. Aqui assumimos que a conexão física ou lógica vá atender a comunicação entre apenas dois roteadores, e não mais que isto.

• Por este motivo, não são requeridos as funções DR / BDR para este segmento.

Originalmente prevendo enlaces Seriais usando PPP, HDLC.

A proposta (boa prática) sugerida por este artigo:

Se a conexão física for Ethernet (ex: um enlace de fibra) e conectar apenas dois roteadores, por que não definir as interfaces envolvidas nesta conexão como point-to-point ?

Neste caso, modificaríamos o tipo de rede OSPF destes enlaces de "Broadcast" para "Point-to-Point"!

Benefícios:

a) Eliminará a necessidade de eleição de roteadores DR e BDR, o que economizará, mesmo que discretamente, o tempo requerido para a formação da vizinhança (adjacência) competa.

b) Cada enlace físico ponto a ponto que for configurado como rede OSPF point-to-point resultará em uma entrada a menos no banco de dados (LSDB) dos roteadores da Área OSPF.

• O LSA Type 2 (Network LSA) é produzido somente pelos roteadores designados (DR). Cada DR numa rede produz uma entrada de LSA Type 2 no LSDB da área onde a interface do DR residir.

• Ao eliminarmos os roteadores DR das áreas da nossa rede OSPF, melhoraremos um pouquinho os tempos de formação de vizinhanças entre os roteadores, além de podermos reduzir um tanto do tamanho do LSDB de cada área!

• O exposto acima diminuirá o tamanho do LSDB de cada área, o que, por sua vez, resultará em menor esforço por parte dos roteadores para a realização das computações devidas, reduzirá um pouco do "falatório" (propagação de LSAs), e deverá ainda melhorar o tempo de convergência geral da rede.

Nonbroadcast multiaccess (NBMA) • Uma rede que interconecta mais de dois roteadores, mas que, ao mesmo tempo, esta rede não possui capacidade de transmissão broadcast (as mensagens broadcast e multicast não são recebidas por todos os roteadores).

• A presença de roteadores DR / BDR poderá ou não ser requerida.

• Há cinco modos de operação OSPF disponíveis para redes NBMA:

• Modos RFC-compliant:

• non-broadcast

• point-to-multipoint

• Modos proprietários Cisco:

• broadcast

• point-to-multipoint non-broadcast

• point-to-point

A escolha do modo dependerá da topologia NBMA da rede.   

Originalmente prevendo conexões entre os roteadores através de redes Frame Relay, ATM ou X.25.

Se você for um ISP completamente isento de infraestruturas legadas, ou seja, tendo o Ethernet como única tecnologia de enlace de toda a sua rede, você não precisará preocupar-se com o OSPF em NBMA.

Para facilitar este entendimento, forneço uma apresentação visual destes tipos de redes OSPF, com ênfase nas melhores práticas. Identifique-se com os tipos de conexões mostradas a seguir, e certifique-se de configurar as suas interfaces de roteadores habilitadas para o OSPF conforme as sugestões de "network types":

Exemplos de tipos de redes OSPF, em especial as boas práticas para cada cenário

5) Configure corretamente a banda de referência do OSPF para evitar problemas com a derivação de custos de interfaces OSPF

Talvez uma das coisas mais negligenciadas por vários ISPs: os profissionais simplesmente se esquecem de definir a banda de referência do OSPF!

Permita-me explicar algo: a métrica do OSPF é o "Cost" (custo), e muitos afirmam que o custo de uma interface é inversamente proporcional à sua banda. Isto está parcialmente correto. Na prática, o OSPF determina os custos da seguinte forma:

Custo = Banda de Referência (em bps) / Banda da Interface (em bps)

O problema é que a banda de referência considerada pelo OSPF na maioria das plataformas/equipamentos é de 100 Mbps (cem megabits por segundo!). Isto significa que qualquer interface de roteador que possuir banda/capacidade igual ou superior a 100 Mbps terá o custo de... "1" (um)! Você vê algum problema nisto?

Ou seja, em uma rede onde você possuir interfaces 1 Gbps, 10 Gbps, 40 Gbps, e, talvez, 100 Gbps, enfim, todas as interfaces acima de 100 Mbps terão o custo de 1, e isto significa que a convergência do OSPF não será capaz de compreender as diferenças entre estas capacidades reais, e que, consequentemente, não conseguirá compreender que um caminho com largura de banda de 40 Gbps é melhor que um caminho que tenha largura de banda de 1 Gbps. E o chamado e indesejável roteamento subótimo (suboptimal routing) poderá existir, pois uma "melhor rota" poderá ser uma rota que envolve um enlace de 1 Gbps, ao invés de considerar como melhor rota um enlace que ofereça 40 Gbps. Vejamos algumas situações considerando o valor de banda de referência padrão, ou seja, 100 Mbps:

Interface Fast Ethernet (100 Mbps)
Custo = 100000000 / 100000000
Custo = 1
Interface Gigabit Ethernet (1 Gbps)
Custo = 100000000 / 1000000000
Custo = 1
Interface Ten Gigabit Ethernet (10 Gbps)
Custo = 100000000 / 10000000000
Custo = 1

E assim por diante, para 40 e 100 Gbps, por exemplo.

OBS: obviamente não há escala negativa (valores de métricas abaixo de 0), portanto, com a banda de referência padrão (100 Mbps), o custo OSPF de interfaces igual ou superior a 100 Mbps será sempre "1".

Exemplo de consequências com o valor padrão de banda de referência do OSPF em uma rede

Sugestões: configure a banda de referência do OSPF em todos os roteadores para a capacidade máxima suportada por todos os equipamentos. Se todo os seus roteadores suportarem a configuração da banda de referência para 100 Gbps, faça-o! Do contrário, configure então a banda de referência para 40 Gbps, e ajuste os custos manualmente nas interfaces 40 Gbps e 100 Gbps para ter a granularidade necessária e exigida pelo seu projeto.

Em último caso, defina os custos manualmente nas interfaces. Mas, no entanto, procure resolver a questão primeiro com a configuração do parâmetro global (banda de referência), e evite ter que intervir com a configuração dos custos manualmente nas interfaces.

6) Sumarize as rotas OSPF sempre que possível, mas cuidado com os problemas quanto a esta prática nas redes MPLS

Conforme comentado previamente, o protocolo de roteamento OSPF somente suporta a sumarização de rotas nativas do OSPF pelos roteadores de borda de área (ABR) e de rotas externas redistribuídas para o OSPF por roteadores ASBR. E isto significa que a sumarização de rotas nativas do OSPF só é possível em projetos com múltiplas áreas.

Se o seu ISP possuir em sua rede uma única área OSPF (single area), não será possível sumarizar rotas OSPF neste tipo de ambiente.

OBS: cuidado com a sumarização do bloco alocado/dedicado para endereçar as interfaces Loopback! Especialmente se a sua rede MPLS possuir LSPs sendo estendidos para o perímetro de Acesso, pois, neste caso, haverá a "quebra" dos LSPs, e a consequente perda de conectividade. Exemplos de LSP "fim a fim" incluem L2VPN e L3VPN. Redes que contam com túneis de engenharia de tráfego entre roteadores especificamente de Core (P-routers) também estão sujeitas ao problema de quebra de LSP fim a fim.

A ilustração a seguir demonstra esta situação e fornece três alternativas para evitarmos este problema com a sumarização de prefixos em uma rede MPLS. O roteador P-1 está com

As complicações quanto a sumarização de prefixos em um backbone MPLS, e a possível perda de conectividade de serviços na rede

Por que você deveria sumarizar rotas do seu IGP, mas, lembrando, não fazendo para o bloco que atende os endereços IP das interfaces Loopback dos seus roteadores (ou adotando outras medidas cautelares)?

  • Os LSA "detalhados" (Type 1 - Router, e Type 2 - Network) ficam confinados nas áreas onde são produzidos. Isto é, não cruzam de uma área para outra.
  • Os roteadores ABR, os quais conectam uma ou mais áreas para a Area 0.0.0.0 (backbone), fazem um "resumo" (e não uma sumarização) das redes IP de cada área a anunciam estes resumos para a Area 0.0.0.0, assim como produzem o resumo das redes IP da Area 0.0.0.0 e injetam isto para as demais áreas onde possuírem interfaces configuradas para o OSPF.
    • O resumo definido pelo LSA Type 3 em nada tem a ver com "sumarização": o resumo aqui é a supressão dos detalhamentos topológicos da área onde estes prefixos residirem.
    • Este resumo é definido pelo LSA Type 3 (Summary LSA). Este LSA é gerado somente pelos roteadores ABR.
  • O exposto acima significa que a sumarização de rotas de uma determinada área (ex: Area 1 ou Area 1.1.1.1) não promoverá benefícios exatamente naquela área, mas sim para a Area 0.0.0.0 e, consequentemente, para as demais áreas "plugadas" no backbone.
    • Entenda: não há como sumarizar rotas dentro de uma área. As redes IP e os detalhamentos topológicos destas redes mantidos pelos LSAs detalhados (Type 1 e Type 2) são resumidos num primeiro instante pelos LSA Type 3 (Summary), conforme já comentado, e são então (os LSA Type 3) injetados para a Area 0.0.0.0.
      • No momento em que isto ocorrer, você (administrador da rede), poderá comandar (ou não) a sumarização das redes IP em um único ou em poucos LSA Type 3, ao invés de produzir um LSA Type 3 representando cada rede IP específica da área cujos prefixos devem ser sumarizados.
        • Em outras palavras, isto é a efetiva sumarização das rotas OSPF. A sumarização não é automática, tampouco requerida: você, se desejar sumarizar, deverá configurar a sumarização manualmente.
  • Consequentemente, ao sumarizar, você reduzirá o tamanho do LSDB das áreas da rede OSPF.
    • Ao invés de repassar um LSA Type 3 referente a cada uma das redes IP de uma determinada área (ex: Area 1.1.1.1) para a Area 0.0.0.0 (ex: 50 redes IP na Area 1.1.1.1 resultaria em 50 LSAs Type 3 sendo anunciados para a Area 0.0.0.0), você, por exemplo, alternativamente, poderá sumarizar/agregar todas estas redes IP num único LSA Type 3.
      • Lembrando que a sumarização de rotas de redes IP da Area 1.1.1..1 não resultará em um LSAs Type 3 sumarizado sendo injetado na Area 1.1.1.1, pois estes LSA Type 3 serão injetados na Area 0.0.0.0 e, posteriormente, repassados para as demais áreas, mas nunca a área 1.1.1.1, neste exemplo.
    • Bancos de dados mais enxutos reduzem o esforço de recomputação dos mesmos pelos roteadores OSPF. Ou seja, menor esforço e diminuição do overhead de processamento.
  • Consequentemente, ao termos bancos de dados mais enxutos, com o auxílio da sumarização, teremos tabelas de roteamento menores com relação a rotas IGP/OSPF.
    • Isto se traduz em maior escalabilidade, menor overhead, e melhores tempos de convergência do OSPF.
  • Impactos adversos que por ventura ocorrerem em links de uma determinada área ficarão confinados apenas naquela área.
    • Os roteadores posicionados na área onde ocorrerem oscilações frequentes (flap) de links, por exemplo, deverão propagar/inundar os LSAs detalhados correspondentes a todo instante, assim como realizar as devidas recomputações de seus LSDB.
    • Estes eventos não são percebidos por roteadores posicionados em outras áreas, pois não estão sendo repassados os LSA Type 3 referentes às redes IP específicas; apenas o LSA Type 3 contendo a rede agregada está sendo repassado para a Area 0.0.0.0 e, consequentemente, para as demais áreas.
      • Ganha-se muito na questão de estabilidade geral da rede!

Os benefícios quanto à sumarização de rotas são notórios: diminuição dos tamanho dos bancos de dados do OSPF (LSDB), diminuição das rotas OSPF da tabelas de roteamento (RIB), diminuição da frequência e propagação de mensagens LSU (os quais transportam os LSAs), ou seja, menor "falatório", consequentemente menor overhead de processamento e melhores tempos de convergência para a rede.

7) Saiba quando e onde implementar Áreas especiais do OSPF

8) Evite o uso de Virtual-Links!

9) Sempre que possível, opte por um protocolo IGP que não seja o OSPF para clientes L3VPN MPLS

10) Proteja o seu OSPF contra determinados riscos de segurança

11) Opte por soluções mais apropriadas para engenharia de tráfego, evitando manipulações frequentes da métrica do OSPF

Momento didático: por que o OSPF?

Em primeiro momento, permita-me antecipar que o que comentarei a seguir é válido tanto para IPv4 (OSPFv2) quanto para IPv6 (OSPFv3).

A pergunta pode ser um tanto óbvia, assim como as prováveis respostas. O OSPF não é nenhuma novidade no mercado e está presente nas redes há muitos e muitos anos. Todo mundo ouviu falar que o OSPF é rápido - isto é, converge rapidamente - que é mais escalável, inteligente, etc., mas não é todo mundo que descreve com detalhes as razões pelos quais o OSPF é o protocolo de roteamento de escolha dos operadores de redes de telecomunicações ou ISPs. Que tal então fornecer os argumentos com maiores propriedades?

Principais Características que Favorecem a Adoção do OSPF em Ambientes de ISP
Característica Explicações
Confiabilidade na troca de mensagens Protocolos de roteamento baseados no conceito de vetor de distância (Distance Vector) não implementam quaisquer mecanismos de confiabilidade na troca de mensagens.

Um roteador rodando RIP pode simplesmente enviar toda a sua tabela de rotas RIP para seus (pseudo) vizinhos sem que haja mesmo o conceito de vizinhança/neighbor propriamente dito.

Ou seja, dois roteadores não formam uma vizinhança para, depois, trocarem as suas rotas! Em adição, não há mecanismos de reconhecimento (ack) de recebimento de rotas, dentre muitas fragilidades existentes.

Protocolos Link-State, como é o caso do OSPF e do IS-IS são muito superiores aqui:

  • Antes de trocar as informações sobre as redes, os roteadores OSPF precisam formar uma vizinhança por completo (termo aqui é "adjacência").
  • Para que consigam formar uma adjacência, um conjunto de pré-requisitos é testado durante o procedimento (isto será discutido posteriormente).
  • Ao contrário do RIP, os roteadores OSPF não trocam rotas! Roteadores OSPF trocam informações sobre o estado dos links das interfaces participantes do protocolo (verifiicaremos isto depois).
  • O OSPF emprega PDUs (mensagens próprias em pacotes) para coordenar todo o processo de vizinhança/adjacência, troca de mensagens sobre os links da rede, e reconhecimento (ack) ou confiabilidade quanto à troca destas mensagens.
  • O roteador OSPF suporta mecanismos de retransmissão em caso de não reconhecimento de recebimento de uma informação por parte de um de seus vizinhos.
  • Ao contrário do RIP - um distance vector - que faz envio periódico a cada 30 segundos de toda a sua tabela de rotas, o OSPF é um protocolo, uma vez convergido por completo, não faz envio periódico de informações da rede.
  • Ainda com relação ao bullet anterior, o OSPF, sim, resinncroniza o seu banco de dados a cada 30 minutos e através de um procedimento simplificado com envio resumido apenas das informações.
Escalabilidade e Diâmetro da Rede Talvez seja o argumento mais fácil e conhecido sobre a diferenças entre protocolos Distance Vector e Link-State.
  • A escalabilidade pode ser mesurada de quatro formas: tamanho da rede em termos de quantidade de elementos roteadores ativos, diâmetro da rede, e tamanho das tabelas de roteamento, capacidade da rede de responder a eventos de falhas ou convergência do plano de controle.
  • O protocolo de roteamento é indiscutivelmente mais escalável que os protocolos vetores de distância sobre os quatro pontos discutidos acima.
  • Não somente isto: os protocolos vetores de distância não são recomendados para ambientes de ISP, pelo menos no que diz respeito ao roteamento das redes internas do ISP.
  • O RIP possui diâmetro máximo de 15 saltos, o que é muito pouco para as infraestruturas de rede de muitos anos pra cá. O OSPF não possui limitações tangíveis quanto ao diâmetro da rede, embora haja a necessidade de boas práticas para a construção de uma rede hierárquica e também do projeto com áreas.
  • O OSPF escala muito bem e para redes muito grandes, mas desde que sejam observadas boas práticas, um bom e eficiente projeto de áreas, tuning ("ajuste fino") de temporizadores de mensagens e computação de LSDB, sumarização de rotas, etc.
  • A escalabilidade entre ambos o RIP e OSPF é gritante também no que diz respeito à quantidade de informações (rotas) que podem ser mantidas na tabela de roteamento. Como o RIP obrigatoriamente tem que anunciar todas as suas rotas a cada 30 segundos, o processamento é severamente impactado, o que, consequentemente, limita a escalabilidade da rede.
  • Em ambos os casos (RIP e OSPF), a escalabilidade pode ser maior com o uso adequado da sumarização de rotas, embora que a escalabilidade do OSPF será sempre maior. Para a sumarização efetiva, são fundamentais as boas práticas para a hierarquia da rede (que, no OSPF, é mandatória), e um bom plano de endereçamento IP.
Confiabilidade da Convergência Outra área funcional em que o OSPF aplica uma verdadeira "surra" no RIPv2. Caso você não compreenda bem o termo, a "convergência" pode ser esclarecida da seguinte forma:

"O tempo gasto, além da eficiência do procedimento, com a propagação de um evento na rede (ex: link down ou link up) para todos os roteadores, e até que todos estes tenham concluído a propagação deste evento, assim como concluído todos os procedimentos de reprogramação de suas estruturas de dados (ex: RIB)".

Isto significa que a convergência é qualificada tanto na hora de "difundir" o evento através da rede (remoção de rotas ou adição de rotas) entre todos os roteadores, quanto da conclusão da recomputação de suas estruturas de dados, resultando, consequentemente, em tabelas de roteamento 100% atualizadas quanto aos destinos da rede.

O protocolo RIPv2 é precário neste sentido. Ambientes RIP podem levar até 180 segundos para convergir acerca do entendimento de algumas poucas rotas, e até 240 segundos para reconhecer que uma determinada rede IP não está mais acessível.

O OSPF, por sua vez, é infinitamente mais vezes ágil no que diz respeito a este tão importante procedimento. Por isto citamos que "o OSPF converge rapidamente".

E, para concluir aqui, uma das situações mais conhecidas envolvendo os protocolos Distance Vector e Link-State: protocolos como o RIP não possuem conhecimentos topológicos da rede, e sobrevivem com o recebimento de informações (rotas) de segunda-mão. Por exemplo: "o meu vizinho me contou que tem uma rede 'X' com 'n' saltos de distância".

Ou seja, tudo o que aquele roteador realmente conhece são os seus roteadores "vizinhos" (lembrando que não há vizinhanças de fato no RIP!), que são os roteadores conectados na mesma subrede IP que ele.

O OSPF é completamente diferente disto: cada roteador OSPF possui detalhamentos topológicos de todos os roteadores e interfaces OSPF em uma área! Quem é o mais confiável aqui, um protocolo que vive de "rumores" ou um protocolo que fornece um mapa de toda a topologia de uma área? Acho a pergunta até desnecessária, mas...

Prevenção de Loops de Roteamento Se em alguma ocasião na sua rede você deparou-se com uma mensagem "TTL expired in transit" ou "TTL expirado em trânsito" durante um teste de conectividade com "ping", então você já sabe o que é um loop no roteamento da rede.

Loops L3 em redes são comuns principalmente nas seguintes situações:

  • Configuração incorreta do roteamento estático, mesmo em ambientes onde há um protocolo de roteamento em operação.
  • Falhas na convergência do protocolo de roteamento, geralmente por erros no projeto técnico e/ou configuração nos elementos.
  • Bugs no software de um ou mais equipamentos, um cenário muito raro.

O fato é que o OSPF é absurdamente muito mais seguro nesta questão de prevenção de loops. Resta você saber o "por que"?

Falando (e mal) do RIP aqui. Este protocolo implementa alguns procedimentos para este propósito que são o counting to infinity, split horizon, poison reverse e holddown timers. Estes mecanismos é o que limitam o diâmetro da rede RIP para 15 saltos apenas, assim como provocam a sua convergência bem lenta.

Por sua vez, o OSPF é uma história completamente diferente, e isto será detalhado posteriormente.

A principal razão desta eficiência do OSPF está no seu conceito de solução mesmo, que é o projeto de Áreas OSPF: roteadores posicionados em uma mesma área OSPF possuem rigorosamente as mesmas informações e nas mesmas características e qualidades de detalhes. Isto fornece a noção topológica de todas as redes daquela área.

Como um roteador OSPF poderá errar ou equivocar-se e provocar um loop, se ele sabe ou conhece toda a topologia da área? Só se: a) você configurou alguma coisa de forma incorreta, b) o seu projeto tem falhas de abordagens de roteamento, c) você tem um problema (bug) no seu software.

Em suma, no que diz respeito à questão de prevenção de loop, o OSPF é um protocolo extremamente seguro, e fornece excelente imunidade quanto a este tipo de incidente, ao contrário do RIP, que possui baixa imunidade.

Maior sofisticação e controle de operação do IGP Em termos mais práticos, o protocolo de roteamento OSPF é bem superior ao RIP, ou a qualquer protocolo do IGP do tipo Distance Vector, no que diz respeito a alguns recursos periféricos mas que podem ser importantes e/ou exigidos em projetos de redes de ISPs.

Facilidades tais como ajustes nos temporizadores do protocolo e nos mecanismos de recomputação podem promover ganhos adicionais de confiabilidade e a redução do overhead de processamento.

Em adição, as ferramentas de controle e manipulação das rotas OSPF são mais avançadas e apropriadas do que os mecanismos e recursos suportados por protocolos não Link-State.

Compatibilidade nativa com o MPLS Traffiic Engineering Para poder encerrar os "pros e contras" e justificar de forma definitiva os motivos pelos quais um protocolo Link-State (seja o OSPF ou o IS-IS) deve ser utilizado por operadores de redes de telecomunicações ou ISPs.

Projetos de infraestrutura IP+MPLS que necessitem ou almejem a engenharia de tráfego por MPLS exigem, por obrigação, o suporte a um IGP compatível com as extensões de engenharia de tráfego por MPLS.

A indústria, ao invés de criar um novo protocolo para isto - além do RSVP-TE, que provê a sinalização, controle de admissão de túneis, e o fornecimento do label para TE - resolveu fazer o óbvio, que foi aproveitar os protocolos Link-State existente para que estes acomodassem as extensões de TE.

E, adivinhe? O OSPF e o IS-IS são os únicos protocolos de roteamento IGP que suportam o MPLS TE. Não há como implementar o MPLS TE sem o OSPF ou o IS-IS na sua rede. Ponto final.