Boas praticas para a implantacao do ospf em ambientes de isp

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

Nota sobre direitos autorais, termo de uso e isenção de responsabilidade

Consulte os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional.

Autor: Leonardo Furtado

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, 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, e para não aborrecer-se mais!

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 12 (doze) situações envolvendo o OSPF em ambientes de ISP:

1. Mantenha o OSPF dedicado apenas para os prefixos internos da rede do ISP: recomenda-se que toda e qualquer rota representando redes externas ou redes de cliente sejam mantidas pelo BGP, e não pelo IGP.
2. Opte por um projeto de rede Ethernet/IP hierárquico, estruturado e modular: por inúmeras razões, incluindo o melhor funcionamento do OSPF, recomendamos esta prática.
3. Elabore um plano de endereçamento IPv4 e IPv6 adequado para acomodar as interfaces Loopback e os links internos da sua rede: por diversas razões e não somente por causa do OSPF!
4. Configure os enlace físicos ponto a ponto como redes OSPF ponto-a-ponto: uma simples e boa prática que traz benefícios para a formação de adjacências e manutenção de LSDBs mais enxutos.
5. Configure corretamente a banda de referência do OSPF para evitar problemas com a derivação de custos de interfaces OSPF: uma boa prática para evitarmos problemas com roteamento subótimo no AS.
6. A sumarização de rotas OSPF é um recurso, mas tenha cuidado com os problemas quanto a esta prática em redes MPLS: a sumarização de rotas OSPF tem prós e contras, dependendo do tipo de ambiente.
7. Saiba quando e onde implementar Áreas especiais do OSPF: conhecer com mais detalhes as áreas especiais poderá viabilizar projetos com necessidades mais específicas.
8. Evite o uso de Virtual-Links: embora historicamente exigido em alguns projetos e ocasiões, recomenda-se evitar este recurso nos projetos de infraestrutura, principalmente quando a rede foi bem construída.
9. Sempre que possível, opte por um protocolo IGP que não seja o OSPF para clientes L3VPN MPLS: o OSPF é maravilhoso para o roteamento IGP do AS, mas muito burocrático quando operando na relação PE-CE.
10. Proteja o seu OSPF contra determinados riscos de segurança: recomenda-se a adoção de boas práticas para proteger o seu OSPF, assim como os demais componentes do plano de controle.
11. Opte por soluções mais apropriadas para engenharia de tráfego, evitando manipulações frequentes da métrica do OSPF: há formas mais interessantes, flexíveis e bem menos engessadas para estas necessidades.
12. Ferramentas adicionais para o "ajuste fino" do OSPF (IP Event Dampening, LSA/SPF Throttling, BFD): o OSPF poderá receber auxílio de recursos adicionais para maior estabilidade e escalabilidade.

Aprecie a leitura sem moderação!

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

Dissertação sobre as boas práticas para o OSPF em infraestruturas de redes de ISPs

Esta seção do artigo destacará cada uma das 12 situações ou áreas de interesse sobre o tema de boas práticas para o OSPF em ambientes de ISP.

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 unicast 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. Isso será discutido mais a frente.

De antemão já condeno uma prática que vejo muito por aí em ambientes ISP:

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. Não faça isso! Aliás, para que injetar milhares de prefixos /32, sabendo que autenticações ocorrem a todo o instante e que isto provocará recomputações incessantes sobre o LSDB de seus roteadores? 

O que você poderia fazer ou considerar neste caso:

1) 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 sobre esta rota estática, indicando uma ação para fins de redistribuição, e, em seguida, redistribuir esta rota estática que contém este tag para o OSPF como External Type-1, sem complicações.

2) Ou, alternativamente, fazendo a mesma coisa, só que redistribuindo para o BGP ao invés do OSPF. Isto é, se o seu concentrador estiver rodando BGP em adição ao serviço BNG (PPPoE).

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 certas dificuldades quanto a convergência da rede. Em adição, o inconveniente elevado aumento de processamento decorrente de computações frequentes e excessivas do LSDB dos roteadores. E, por último, o excesso de rotas IGP que poderá estourar os limites estabelecidos pelas arquiteturas dos seus equipamentos.

Só para constar: protocolos de roteamento interiores (IGP) não escalam massivamente como o BGP. O limite máximo recomendado pela indústria é de 40 mil rotas IGP na tabela de roteamento, mesmo que o seu roteador suporte 10 milhões de prefixos numa FIB em hardware.

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

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

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 aqui, 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 para o seu funcionamento. 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 em cada uma destas camadas.

Dependendo do tamanho do seu ISP, uma única área OSPF poderá 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 e estruturaçã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

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, dentre outras necessidades e situações.

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, pois este protocolo de roteamento é um tanto burocrático em alguns de seus recursos e facilidades. Para exemplificar, no OSPF é possível sumarizar rotas somente 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 roteador 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, então, será completamente incapaz de fazê-lo.

Recomenda-se equipar o seu ISP com um bom 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! O "encaixe" precisa ser próximo do perfeito!
• 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.

Mesmo que você não vá implementar a sumarização de suas rotas de sua infraestrutura, pois prefere optar por outros mecanismos para a atenuação da inundação frequente de LSAs e ciclos de processamento SPF sobre o LSDB, algo que será discutido posteriormente, neste artigo, é extremamente recomendado que você tenha um eficiente e bem alocado plano de endereçamento IP.

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 e similares) como "point-to-point" (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 mais de dois 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) completa. 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, em caso de redes grandes! • 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 o volume de 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 (consulte o seu vendor sobre o que é suportado aqui): • 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.

OBS: algumas plataformas mencionam a rede OSPF de uma interface Loopback como "LOOPBACK". Recomenda-se não modificar isto.

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

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 óbvias, mas um tanto negligenciadas por alguns ISPs: muitos profissionais com os quais já interagi simplesmente esqueceram-se de definir a banda de referência do OSPF em suas redes!

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, e de forma mais abrangente, o OSPF determina os custos das interfaces dos roteadores 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, 25 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, equivocadamente, 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, de 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 25, 40, 100, e até mesmo o recente 400 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/ou 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), evitando ter que intervir com a configuração dos custos manualmente nas interfaces.

A sumarização de rotas OSPF é um recurso, mas tenha cuidado com os problemas quanto a esta prática em 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 fim-a-fim, transportando serviços tais como L2VPN e L3VPN, pois a sumarização de rotas OSPF internas no seu ISP poderá provocar não somente a "quebra" destes LSP, mas a consequente perda de conectividade destes serviços também. Em adição, 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 duas alternativas para evitarmos este problema com a sumarização de prefixos em uma rede MPLS.

Demonstração de uma possível complicação quanto a sumarização de rotas IGP em ambientes MPLS

Aqui vivemos um dilema: por um lado, a sumarização de rotas IGP é uma boa prática. Por outro lado, isto trará problemas em ambientes MPLS. Em tese, é viável realizar a sumarização de rotas num backbone MPLS, desde que não sumarizando os prefixos referentes aos endereços IP das interfaces Loopback dos roteadores ISP, além de outras medidas cautelares.

Citemos aqui os benefícios gerais que a sumarização de rotas OSPF pode promover:

• 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 de rotas!) 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.
  • Este resumo é definido pelo LSA Type 3 (Summary LSA) em nada tem a ver com "sumarização de rotas" referentes aos prefixos: o resumo aqui trata-se da supressão dos detalhamentos topológicos da área onde estes prefixos residirem (os quais existem ou são ditados pelos LSA Type 1 e 2, e cujos os quais não são propagados para fora da área onde residem ou foram originados).
  • 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 de uma determinada área para dentro desta mesma área. As redes IP e os detalhamentos topológicos destas, mantidos pelos LSAs detalhados (Type 1 e Type 2), são resumidos num primeiro instante pelos LSA Type 3 (Summary LSA), 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 de rotas referentes a estas 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 desta área.
      • 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 esta 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. Isto é, se o seu plano de endereçamento assim o permitir.
  • 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. E isto não é uma exclusividade apenas de redes de ISP.
• 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 para dentro da área, assim como realizar as devidas recomputações de seus LSDB.
  • Estes eventos de instabilidades 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. E este anúncio sumarizado obviamente não é modificado ou não sofre alterações quando ocorrem falhas nos links representando as redes específicas contidas nesta rota sumarizada.
    • Ganha-se muito na questão de estabilidade geral da rede!

Os benefícios quanto à sumarização de rotas são conhecidos: 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.

No entanto, vem aqui o ponto de divergência e reflexão quanto à sumarização de rotas OSPF em ambientes MPLS. Acompanhe comigo.

As complicações quanto a sumarização de rotas OSPF em ambientes MPLS

• A prática de sumarização de rotas IGP em backbones MPLS sempre acompanhou diversos casos envolvendo problemas.
  • As duas alternativas sugeridas anteriormente são válidas e podem ser consideradas para a mitigação destes problemas.
• No entanto, no que diz respeito à "educar" o OSPF nas questões de "falatório" e diminuição de overhead de processamento, diversos roteadores embarcam recursos adicionais para melhorarmos os padrões de estabilidade e convergência do OSPF.
  • Em muitos projetos, talvez, ao invés de você sumarizar rotas OSPF no backbone MPLS, você deva considerar ferramentas tais como:
    • IP Event Dampening: para reduzir muito substancialmente os overheads de processamento envolvendo o OSPF quando ocorrerem oscilações de interfaces (flapping) muito frequentes.
    • OSPF SPF e LSA Throttling: para reduzir muito substancialmente os overheads de processamento com a propagação de LSAs e recomputações frequentes do LSDB.
    • Estas situações serão discutidas posteriormente neste artigo.

Saiba quando e onde implementar Áreas especiais do OSPF

Como provavelmente já é de seu conhecimento, há duas abordagens com relação aos projetos com o OSPF: single area (uma única área OSPF), e multiarea (múltiplas áreas OSPF).

Quanto a considerar uma abordagem single area ou multiarea, isto dependerá de algumas características de seu projeto técnico, mas, no entanto, os três argumentos principais são:

• Tamanho da rede, fatorando a quantidade de roteadores presentes assim como a quantidade de links internos, quantidade de adjacências a serem estabelecidas por roteador e, ultimamente, a quantidade de rotas OSPF que deverão ser publicadas na tabela de roteamento (RIB). E, mais importante ainda, o tamanho do LSDB de um projeto single area.
• Locais da rede onde rompimentos de enlaces ou oscilações da disponibilidade de roteadores poderiam provocar algum tipo de impacto no processamento do plano de controle ou algum tipo de inconveniente na ações de convergência deste.
• Onde, de acordo com o seu projeto técnico, for necessário sumarizar rotas OSPF.

Considerando aqui apenas o conceito de projeto multiarea, a título de compreensão do título desta seção do artigo.

O OSPF apresenta alguns recursos diferenciados relacionados aos projetos com áreas, e o principal deles são as chamadas áreas especiais. Quando configuramos uma área normalmente, ela é tida como uma área regular, e isto significa que o LSDB desta área poderá acomodar todo e qualquer tipo de LSA suportado pelo software de seu equipamento. No entanto, em diversos projetos de redes, os analistas optam por práticas que promovam resultados mais específicos e objetivos.

Vejamos os tipos de áreas do OSPF:

Tipos de Áreas OSPF e as Situações onde são Empregadas

Tipo de Área	Descrição	LSAs suportados
Área Regular ou Padrão	Uma área regular ou área padrão, como o nome sugere, é uma área comum. Quando configuramos uma área OSPF é exatamente este tipo de área, exceto quando definimos alguma propriedade que a tipifica como uma área especial.	Todos os LSAs são suportados numa área padrão.
Área Backbone	Praticamente a mesma coisa, exceto que trata-se da Área 0 ou Área 0.0.0.0 do seu projeto OSPF. Em termos funcionais, uma Área Backbone e uma Área Regular são praticamente a mesma coisa, só que, no entanto, alguns recursos OSPF são exigidos com o envolvimento da Área Backbone, assim como outros não são permitidos, ao oposto de uma Área Regular. Por exemplo: Num projeto multiarea, todas as demais áreas precisam se conectar diretamente à Área Backbone. A exceção à regra é o recurso Virtual Link. A Área Backbone não pode ser definida como Stuby, NSSA, Totally Stubby ou Totally NSSA.	Todos os LSAs são suportados numa área padrão.
Área Stub	É o tipo mais conhecido de área especial. O objetivo da Área Stub é preservar recursos dos roteadores posicionados nesta área, em especial o tamanho do LSDB e, consequentemente, o tamanho da tabela de roteamento (RIB). Quando usar uma área Stub? Normalmente fazemos isto quando temos um roteador posicionado num local remoto da rede e com apenas um único link conectando-o para o restante da rede, e há muitas rotas externas redistribuídas para o OSPF. Não fará muito sentido se você definir uma área como Stub e, na sua tabela de roteamento, houver poucas rotas OSPF externas que tiverem sido redistribuídas de outros processos de roteamento. Portanto, o uso de áreas Stub faz muito sentido em partes da rede (observando as áreas aqui) que conectam dispositivos roteadores mais "modestos" e numa rede onde há muitas rotas OSPF externas, as quais serão suprimidas tanto do LSDB desta área Stub quanto da tabela de roteamento dos roteadores desta área. Ao definirmos uma Área como Stub, é importante defini-la desta forma, também, em todos os roteadores que estiverem posicionados nesta área, do contrário você não será capaz sequer de formar as adjacências ali. Outra característica é que o roteador ABR desta área produzirá/gerará uma rota padrão (default) para os roteadores desta área, para que eles consigam se comunicar com as redes representadas pelas rotas OSPF externas contida na Área 0.0.0.0 e demais áreas.	Todos os LSAs são permitidos, exceto o LSA Type 5 (AS External LSA)
Área Not-So-Stubby (NSSA)	Uma Área Stub proibe ou não aceita LSAs Type 5 (External). E sabemos que a configuração de uma redistribuição de rotas de outros protocolos de roteamento para o OSPF, em um roteador, automaticamente ativa a função de Autonomous System Boundary Router (ASBR), certo? Isto significa que roteadores numa Área Stub não recebem LSAs Type 5 (External) e, consequentemente, não terão quaisquer rotas OSPF externas em suas tabelas de roteamento e que, para poderem rotear tráfego até a estas redes externas, os roteadores da Area Stub precisarão utilizar a rota padrão (default) gerada automaticamente pelo roteador ABR desta Área Stub. Até aí creio que o entendimento esteja claro. Agora vejamos aqui um cenário hipotético: e se, no seu projeto técnico, você precisar redistribuir rotas externas para o OSPF em um roteador que está posicionado numa Área definida como Stub? Este tipo de setup não seria suportado, pois, novamente, uma Área Stub recusa os LSAs Type 5, os quais são gerados pelos roteadores ASBR. Caso você precise de uma solução que reúna os benefícios de uma Area Stub e que ao mesmo tempo permita a presença de um roteador ASBR, ou seja, com redistribuição de rotas externas para o OSPF dentro daquela Área, então a sua solução deverá ser com uma Área Not-So-Stubby (NSSA). Numa Área NSSA, ocorrem os seguintes: Você precisará definir todas interfaces de roteadores desejadas para aquela área como NSSA. A Área NSSA, assim como a Área Stub, não aceita LSAs Type 5 (External). Isto prevalece. Ao redistribuir rotas externas para o OSPF em um roteador desta Área NSSA, este roteador passará a ser um ASBR. O ASBR de uma Área NSSA não gera LSA Type 5 (External), e sim LSA Type 7 (NSSA External LSA). Cada rota externa redistribuída pelo roteador ASBR de uma Área NSSA produzirá um LSA Type 7. O LSA Type 7 (NSSA External LSA) existirá somente nesta Área NSSA! O roteador de borda de área (ABR) da Área NSSA converterá cada LSA Type 7 para um LSA Type 5 quando repassando o LSA para a Área 0.0.0.0. Basicamente isto é governado pelo bit "P" (propagation), descrito no campo Options (1 byte) contido no pacote Link-State Update (LSU). Se o roteador ABR da Área NSSA for ao mesmo tempo um roteador ASBR, este bit "P" não é assinalado Numa Área NSSA, o roteador ABR não gera uma rota padrão (default) automaticamente, portanto você deverá configurar isto de forma apropriada (via um "area xxx nssa default-information-originate", ou procedimento similar em seu equipamento). Faz muito sentido usar áreas NSSA em projetos onde há roteadores mais modestos e numa rede onde há muitas rotas externas em toda a rede NSSA e, ao mesmo tempo, a necessidade de redistribuir rotas externas para a Área NSSA.	Todos os LSAs são permitidos, exceto o LSA Type 5 (AS External LSA). O LSA Type 7 (NSSA External LSA), por sua vez, reside apenas na própria Área NSSA, e é convertido para LSA Type 5 pelo roteador ABR da área.
Área Totally Stubby	É essencialmente uma área Stub, só que bem mais agressiva no sentido de quais tipos de LSA podem existir naquela área. Numa Área definida como Totally Stubby, obviamente, são permitidos todos os LSAs detalhados (Type 1 - Router, Type 2 - Network) que são produzidos pelos roteadores posicionados naquela área. Mas aí vem a grande diferença entre Totally Stubby e Stub: numa área definida como Tottaly Stubby, mais nenhum LSA é permitido, e isto inclui o LSA que descreve as redes OSPF contidas em outras áreas (LSA Type 3 (Summary LSA)), assim como o LSA Type 4 (Summary ASBR), além do LSA que representa as redes OSPF externas (LSA Type 5 (External LSA)). Para constar, num setup Totally Stubby, o roteador ABR desta área gera uma rota padrão (default) automaticamente. A configuração é idêntica daquela que devemos fazer para uma Área Stub, sendo a única diferença um parâmetro ("no-summary") que deverá ser definido apenas no roteador ABR desta área. Faz muito sentido uma Totally Stubby em roteadores em uma área que só possui um único enlace de comunicação para o restante da rede, e por onde apenas uma rota padrão (default) é necessária para conectar aquele roteador com o restante da rede. Afinal de contas, para que manter um LSDB gigante e um montão de rotas em roteadores de uma área que só possui um link com o restante da rede, especialmente quando estes roteadores são mais modestos em termos de poder de processamento?	Apenas os LSA que descrevem detalhadamente a topologia e redes OSPF da referida área, ou seja, LSA Type 1 (Router), LSA Type 2 (Network). Todos os demais LSAs são suprimidos.
Área Totally NSSA	Resumindo, é uma Área NSSA que: Não aceita quaisquer LSAs que representem rotas de redes OSPF de outras áreas (LSA Type 3) Não aceita quaisquer LSAs que representem rotas de redes externas ao OSPF (LSA Type 5). Consequentemente, não aceita LSAs para a conectividade com roteadores ASBR de outras áreas (LSA Type 4). Permite que haja roteadores ASBR em sua área, redistribuindo rotas de redes externas para o OSPF e, portanto, produzindo LSA Type 7. O ABR desta área gerará automaticamente uma rota padrão para que os roteadores desta área possam rotear tráfego para redes OSPF e rotas OSPF externas existentes em outras áreas. A configuração é idêntica daquela que devemos fazer para uma Área NSSA, sendo a única diferença um parâmetro que deverá ser definido apenas no roteador ABR desta área.	Apenas os LSA que descrevem detalhadamente a topologia e redes OSPF da referida área, ou seja, LSA Type 1 (Router), LSA Type 2 (Network). Os LSA Type 7 gerados por roteadores ASBR desta área são obviamente permitidos. Todos os demais LSAs são suprimidos.

Talvez seja prudente de minha parte dissertar um pouco, mesmo que de forma resumida e objetiva, os tipos de roteadores OSPF, até mesmo para que haja um melhor esclarecimento e associação com os conceitos de Áreas.

É necessário frisar aqui que o conceito de áreas do OSPF é definido em nível interface, ou seja, ao contrário do protocolo de roteamento IS-IS, onde todas as interfaces (o roteador como um todo) ficam posicionadas numa única área, no caso do OSPF, por sua vez, definimos/configuramos as áreas por interface.

Tipos de Roteadores OSPF

Tipo de Roteador	Descrição
Roteador Interno	Um rotador é chamado de "interno" quando todas as suas interfaces são configuradas para participar de uma mesma área.
Roteador de Backbone	É essencialmente um roteador interno, sendo que a diferença é que todas as suas interfaces são definidas para participar da Área 0.0.0.0.
Roteador de Borda de Área (ABR)	Um roteador que possui pelo menos uma interface configurada para a Área 0.0.0.0, e uma ou mais interfaces configuradas para outra(s) área(s).
Roteador de Borda de Sistema Autônomo (ASBR)	Um roteador que esteja realizando a redistribuição de rotas de redes externas ao OSPF..
Roteador Designado (DR)	Não é exatamente um tipo de roteador OSPF, e sim uma função. Toda e qualquer interface OSPF de um roteador que estiver conectada a um dos tipos de redes OSPF (network types) que exijam a eleição de um roteador DR, sendo que, neste caso, o próprio roteador em questão é o DR do referido segmento.
Roteador Designado de Backup (BDR)	Idem, com relação exposto acima sobre o DR.

O diagrama a seguir ilustra alguns dos tipos de áreas e de roteadores OSPF:

Exemplos de alguns tipos de roteadores e de áreas do OSPF

Para concluir com o tema sobre áreas especiais, fique atento quanto as explicações fornecidas na tabela anterior. Você deverá ser capaz de identificar quais situações melhor aplicam-se para cada um dos tipos de áreas indicadas.

Evite o uso de Virtual-Links!

Não entrarei em muitos detalhes aqui, tais como diagramas e afins, apenas dissertarei brevemente sobre o recurso Virtual Link. Este recurso foi projetado para as seguintes necessidades:

• Fusão de duas redes OSPF distintas, onde há duas Áreas de backbone (0.0.0.0) OSPF separadas por uma área regular. Ou seja, quando precisamos interconectar as duas Áreas 0.0.0.0 deste cenário através de uma área não-backbone.
• O projeto com OSPF em múltiplas áreas obriga que toda e qualquer área esteja diretamente conectada à Área 0.0.0.0. Suponhamos que em um determinado momento isto não seja viável no seu projeto técnico, onde uma Área (ex: 2.2.2.2) conecta-se à outra área (ex: 1.1.1.1), que por sua vez conecta-se ao backbone (Area 0.0.0.0), algo que não funcionaria por não ser suportado. O mecanismo Virtual Link poderia ser usado nestas situações para conectar a Área 2.2.2.2 para a Área 0.0.0.0, através da Área 1.1.1.1.
• Quando, numa área não-backbone, você precisa construir uma rota de backup (caminho alternativo) via outro roteador que não esteja plugado na Área 0.0.0.0.

Nestas três situações discutidas acima, o recurso Virtual Link pode ser considerado.

No entanto, procure não implementá-lo. Busque formas de aprimorar o seu projeto técnico para que o Virtual Link jamais seja necessário ou exigido. O Virtual Link introduz limitações e agrega maior complexidade para o projeto lógico do OSPF!

É nestas horas que você deverá aplaudir todo e qualquer esforço que tenha tido lá no início por construir uma rede hierárquica, modular e estruturada!

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

Não será coberto detalhadamente, pois isto será discutido com boa profundidade de detalhes em outros artigos aqui na Wiki do BPF, especialmente sobre o tema L3VPN MPLS.

No que diz respeito aos serviços L3VPN MPLS em um operador de redes, sabemos que os roteadores PE devem trocar rotas com seus assinantes em suas respectivas VRFs, o que significa que precisamos rodar um protocolo de roteamento nesta relação "ISP x Cliente", ou seja, o "PE-CE". Você tem a total liberdade para escolher o protocolo que quiser, pois sabemos que toda e qualquer rota IGP trocada com clientes L3VPN fica completamente segregada das rotas IGP do backbone do ISP. É por esta razão que a tecnologia implementa VRFs, sendo uma VRF para cada assinante e, assim, não compartilhamos rotas IGP com os clientes.

Quanto aos protocolos ou procedimentos, uma L3VPN poderá considerar:

• Rotas conectadas
• Rotas estáticas
• RIP
• OSPF
• EIGRP
• IS-IS
• BGP

Agora, com as minhas palavras, de todas as opções acima o OSPF é indiscutivelmente o mais burocrático, e pelas seguintes razões:

1. Num roteador PE, cada cliente L3VPN que você ou ele optar por usar o OSPF na relação PE-CE, será exigido um processo dedicado do OSPF por cliente. Algumas plataformas de roteadores possuem limites nada confortáveis quanto a isto, particularmente no caso de roteadores "jurássicos".
2. O processo OSPF dedicado para o assinante lá na VRF do roteador PE deverá aparentar ser uma Área 0.0.0.0 ou um Superbackbone. Quando o OSPF é usado na relação PE-CE de uma L3VPN MPLS, nos roteadores PE, diversos procedimentos são exigidos para viabilizar a redistribuição da rota OSPF para o BGP, a conversão desta rota OSPF que foi redistribuída para BGP IPv4 para um endereço VPNv4, e a inclusão de communities estendidas específicas para viabilizar o OSPF na relação PE-CE dos sites remotos daquele assinante. Em alguns setups isto agrega maior complexidade. Mas não é o que complica as coisas aqui, no meu entendimento.
3. O OSPF precisa do auxílio de alguns mecanismos para a prevenção de loops de roteamento, tais como Down Bit e Route Tags, e, tanto o ISP quanto o cliente, deverão trabalhar juntos para que o serviço não seja impactado e que loops não possam ocorrer.
4. Talvez a pior parte: problemas com cenários onde há links contratados com duas operadoras distintas, sendo um deles L3VPN MPLS e o outro não, num cenário chamado de "OSPF Backdoor Link":
   1. Numa rede OSPF tradicional (e não numa L3VPN), toda e qualquer rota redistribuída para o OSPF torna-se uma rota externa (LSA Type 5).
   2. Numa rede L3VPN MPLS, no entanto, para evitar que isto pudesse ser um problema em sites remotos eventualmente configurados como áreas Stub, as rotas redistribuídas do BGP para o OSPF são tidas como rotas inter-area, ou seja, produzindo LSA Type 3, e não rotas externas (LSA Type 5).
   3. O problema está no processo de seleção de rotas do OSPF. Acompanhe:
      1. Rotas Intra-Area (LSA Type 1 e 2) são preferidas, independentemente do custo da rota.
         1. Ex: uma rota Intra-Area tem um custo de 500, e uma rota Inter-Area tem um custo de 100. O OSPF preferirá sempre a rota Intra-Area!
      2. Rotas Inter-Area são preferidas somente após as rotas Intra-Area.
      3. Rotas Externas Tipo 1 (LSA Type 5 - External Type 1) são preferidas sobre rotas Externas Tipo 2 (LSA Type 5 - External Type 2), independentemente do custo.
   4. Portanto, imaginemos um cliente com dois sites remotos estendendo uma área OSPF qualquer entre estes dois sites:
      1. Se o cliente tem um link de 1 Gbps com serviço L3VPN via o ISP "A", e tem, também, um link de 100 Mbps comum, não-L3VPN, com o ISP "B".
         1. Rotas OSPF aprendidas pelo link não-L3VPN MPS (ISP "B") serão tratadas como rotas Intra-Area.
         2. Rotas OSPF aprendidas pelo link L3VPN MPLS (ISP "A") serão tratadas como rotas Inter-Area.
         3. Sabemos que em termos de custos, o link pelo ISP "A" é indiscutivelmente melhor que o link pelo ISP "B".
            1. É... no entanto, o OSPF optará encaminhar tráfego pelo link de 100 Mbps, ao invés do link de 1 Gbps!
               1. Rotas Intra-Area tem preferência sobre rotas Inter-Area.
   5. Este problema pode ser resolvido com um recurso chamado OSPF Sham-Link. O problema é que isto não é uma ação executada pelo cliente, e sim por você, ISP! E não é um procedimento pequeno, ou seja, agregará esforço e complexidade para o seu time de ativação e suporte!

Por estes motivos que eu não curto o OSPF para atuar como PE-CE. Mas, atenção, é uma recomendação ou preferência de cenário apenas! Na verdade, quem ditará se você deverá usar ou não o OSPF neste tipo de situação será o tipo de acordo que você possui com o seu cliente! Em muitos casos, o uso do OSPF para o PE-CE é inevitável por conta disso.

Em tempo, estas situações discutidas acima podem ser consultadas no draft OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VPNs (draft-ietf-l3vpn-ospf-2547-05.txt)

Caso você tenha curiosidade, verifique este tipo de setup na ilustração a seguir:

Uma L3VPN MPLS com protocolo de roteamento OSPF na relação PE-CE

Proteja o seu OSPF contra determinados riscos de segurança

Um dos temas mais importantes: a segurança da infraestrutura de redes e de tudo aquilo que roda no topo desta. A segurança da informação precisa ser observada fim-a-fim, e cada elemento ativo de rede precisa fornecer a sua parcela de contribuição.

Felizmente isto já foi previsto e bem documentado em um artigo aqui na Wiki do BPF. Confira: Boas Práticas para Proteção de Roteadores e Switches. Há uma seção exclusiva sobre a proteção do protocolo de roteamento OSPF!

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

Nos "primórdios" das redes IP, toda a vez que necessitávamos realizar alguma engenharia de tráfego, tínhamos que lançar diversas "gambiarras", incluindo rotas estáticas, ferramentas de políticas de roteamento, filtros, PBR, etc. Além de outras práticas/recursos, tais como a manipulação de Distância Administrativa (AD) sobre uma ou mais rotas, manipulação das métricas (no caso do OSPF, o custo das interfaces), dentre outras iniciativas.

Não que não funcionem, a questão não é essa. A questão é que toda a vez que manipulamos alguma coisa neste sentido diretamente nas configurações do protocolo de roteamento IGP, corremos o risco de "errarmos a mão", ou seja, podemos até conseguir resolver o problema daquele cenário, mas ao preço de provocar outros distúrbios até então imprevistos, ou então o cenário acabar ficando desnecessariamente completo ou engessado.

Ao invés de você manipular o IGP para fazer a engenharia de tráfego, que tal estudar e considerar tecnologias mais sofisticadas e flexíveis para este propósito? Dê uma conferida sobre em nosso artigo Engenharia de Tráfego com MPLS TE, disponível em nossa Wiki, e veja se isto não faria maior sentido para o seu projeto!

Futuramente, ou em breve, disponibilizarei alguns artigos sobre a evolução do MPLS TE clássico, com títulos tais como Transição de Infraestruturas MPLS Tradicionais para o SRTILFA e Migração de Túneis de Engenharia de Tráfego (MPLS-TE) para o SR-TE, e potencialmente outros artigos sobre este tema.

Ferramentas adicionais para o "ajuste fino" do OSPF (IP Event Dampening, LSA/SPF Throttling, Timers)

Redes OSPF muito grandes precisam de bastante cuidados, especialmente nas questões de hierarquia e modularidade das topologias física e lógica, bom arranjo hierárquico também para o plano de endereçamento IP, além de um bom projeto de múltiplas áreas com o OSPF. Só que em alguns ou muitos casos, especialmente nos grandes operadores de redes, para destravar o crescimento da rede como um todo em níveis próximos dos "colossais", outras iniciativas precisam ser projetadas para a infraestrutura.

Uma destas iniciativas em termos de abordagens de projeto IGP com MPLS é o Unified MPLS, tema já disponibilizado na forma de um artigo aqui na nossa Wiki do BPF. Confira: Introdução ao Unified MPLS.

Agora tiremos o Unified MPLS da jogada e foquemos em alguns recursos que podem fazer o seu OSPF fluir melhor na sua rede!

Em alguns momentos, o OSPF pode ser um protocolo um tanto "tagarela", particularmente quando ocorrem oscilações frequentes acerca da disponibilidade de enlaces (links) e roteadores. Ou seja, toda a vez que um evento "up/down" ocorrer na sua rede, a prioridade do roteador que percebeu o evento é adicionar esta mudança (ex: novo LSA, atualização de LSA, remoção de LSA) no seu LSDB, comunicar isto para as suas adjacências, receber a confirmação de recebimento do evento por parte de seus vizinhos, e realizar a computação de seu LSDB (procedimento denominado Shortest-Path First, com seu algoritmo Dijkstra), derivando consequentemente a sua árvore de caminhos de menor custo (SPT), e publicar estes melhores caminhos como rotas OSPF em sua tabela de roteamento.

O que ocorre na verdade é o que chamamos de "inundação de LSA" ou "LSA flooding", pois uma das principais propostas do OSPF é a de convergir o mais rapidamente possível. Uma vez a rede estando completamente convergida, isto é, todos os roteadores participantes estão cientes do evento e já concluíram a computação de seus bancos de dados (LSDB), o OSPF voltará a ficar "quieto", ou seja, trocando apenas mensagens Hello (OSPF Packet Type 1) e nada mais, e, a cada 30 minutos, uma breve troca de resumos para confirmar que todos os roteadores possuem as informações completas e mais vigentes.

Em outras palavras, o OSPF é um protocolo quase que "calado" apenas em redes estáveis, onde ocorrem poucos eventos de modificações topológicas.

No entanto, em redes grandes, onde frequentemente ocorrem eventos de rompimento de fibras, entrada/remoção de redes IP, etc., o OSPF passa a ser bastante "falante", pois, novamente, o LSA flooding ocorre para assegurar a mas rápida convergência possível. Mas este não é o maior dos problemas.

O maior dos problema ocorre em ambientes que são vítimas de sucessivos e frequentes eventos de falhas, mesmo aquelas que sejam isoladas para um ponto específico da rede. Cada vez que um LSA novo ou atualizado é recebido por um roteador, novamente, ele precisa incorporar aquele LSA em seu LSDB, repassar via pacote Link-State Update (LSU) para seus vizinhos, receber um pacote Link-State Acknowledgement (LSAck) de cada um deles, e recomputar o seu LSDB, com a execução do SPF, produzir efetivamente a sua SPT, e posteriormente publicar as melhores rotas OSPF em sua tabela de roteamento (RIB). Antigamente isto era bem mais problemático, porque o OSPF, de certa forma, é um protocolo que desprende um bom ciclo de processamento e consume recursos substancialmente quando fazendo isto. Agora imagine isto acontecendo frequentemente, a todo instante! Os roteadores há alguns anos realmente podiam sentir os impactos desse overhead de processamento!

Sendo bem honesto aqui, os roteadores carrier grade dos dias atuais dão conta disto com "um pé nas costas", devido as suas excepcionais capacidades de processamento. Mas isto não significa que não devemos "tunar" o OSPF para que ele se comporte melhor, com mais fluidez, e até mesmo para evitarmos surpresas desagradáveis em nossas redes. O que é o foco dessa seção aqui.

Como normalmente mitigamos este tipo de situação:

1. Projeto de rede bem hierárquica e modularizada.
2. Plano de endereçamento IP compatível com esta hierarquia da rede.
3. Bom projeto com múltiplas áreas OSPF.
4. Sumarização de rotas.
   1. Eventos de falhas com graves e frequentes oscilações ficam confinados nas áreas onde ocorrerem, e não são propagados para outras áreas, ou seja, limitamos o diâmetro do impacto aqui.
   2. O problema com a sumarização de rotas em ambientes ISP: qual operador de redes hoje em dia não possui o MPLS? Sumarização de rotas IGP e MPLS não combinam.
   3. E sumarização por si só não mitiga todos as situações discutidas previamente.
5. Adotamos mecanismos bem interessantes para limitar o montante de dano envolvendo o "falatório" excessivo do OSPF assim como as recomputações recorrentes e muito frequentes.
   1. É aqui que consideramos o IP Event Dampening e os ajustes nos diversos temporizadores (Throttling de LSA e de SPF do OSPF).

Sobre o IP Event Dampening

O recurso IP Event Dampening apresenta um mecanismo de decaimento exponencial configurável para suprimir o efeitos de eventos excessivos de alteração de interface em protocolos de roteamento e de entradas nas tabelas de roteamento na rede. Este recurso permite que o operador de rede configure um roteador para identificar automaticamente e reduzir seletivamente um interface local que está oscilando frequentemente.

O objetivo do recurso: vale a pena propagar LSAs referentes a links que falham incessantemente, "on and off"? Não seria mais inteligente suprimir a propagação de eventos sobre interfaces que oscilam frequentemente em um determinado período de tempo?

Muitos administradores simplesmente colocariam interfaces assim em modo "shutdown" e, após um período, reativariam a interface para verificar se o problema teria sido resolvido. Eu diria que isto é até viável, mas, sem dúvidas, o recurso IP Event Dampening acaba sendo mais inteligente.

O IP Event Dampening é mais inteligente e indicado porque permite que você configure um roteador para identificar automaticamente e reduzir seletivamente as interfaces locais daquele roteador que estão oscilando. Este amortecimento que ocorre removerá a interface da rede até que a referida interface cesse a sua oscilação e possa ter a sua rede retornada para a tabela de roteamento. Isto assegurará e melhorará os tempos de convergência da rede, promoverá o isolamento de falhas para que estas perturbações não sejam propagadas, culminando na redução da utilização de recursos de processamento dos roteadores e contribuindo para uma boa melhora da estabilidade geral da rede.

Sobre o OSPF Link-State Advertisement Throttling

O outro mecanismo que prometi discutir aqui é o OSPF Link-State Advertisement Throttling. Esse recurso fornece um mecanismo dinâmico para desacelerar as atualizações dos Link-State Advertisements (LSA) do OSPF durante períodos de instabilidade da rede, e viabiliza também uma convergência OSPF mais rápida, fornecendo limitação de taxa LSA em milissegundos.

Para se ter uma noção, antes do advento do recurso OSPF LSA Throttling, a geração de LSA era limitada por uma taxa típica de 5 segundos. Isso significava que as alterações em um LSA não podiam ser propagadas em milissegundos, portanto a rede OSPF não conseguia alcançar a convergência de milissegundos, algo que é bastante desejado por muitos tipos de ambientes mais críticos. O recurso de limitação dos LSAs do OSPF (o throttling) é na verdade ativado por padrão em muitas plataforma de roteadores, possibilitando naturalmente uma convergência mais rápida do OSPF, preferencialmente, mas nem sempre, em milissegundos.

Mesmo que seja um recurso ativo por padrão em muitos roteadores, é passível de customizações, e é aqui onde você, engenheiro da rede, entra em ação. Você poderá personalizar o comando que controla a geração (envio) de LSAs, ou o comando que controlará o intervalo de recebimento de LSAs. Esse recurso também fornece um mecanismo dinâmico para diminuir a frequência das atualizações do LSA no OSPF durante momentos de instabilidade da rede.

Como o recurso funciona:

Os timers padrão ou customizados por você controlam a geração (envio) de LSAs. Na prática, o primeiro LSA é sempre gerado imediatamente após uma alteração na topologia do OSPF, e o próximo LSA gerado é controlado pelo intervalo mínimo de início. Os LSAs subsequentes gerados para ou sobre o mesmo LSA têm taxa limitada até o intervalo máximo ser atingido. O "mesmo LSA" é definido como uma instância LSA que contém o mesmo número de ID LSA, tipo de LSA e Router ID do roteador. Outro comando pode ser usado para controlar o intervalo mínimo para a aceitação de um mesmo LSA. Se uma instância do mesmo LSA chegar antes do intervalo definido, o LSA será descartado. Na prática, recomenda-se que o intervalo de chegada seja menor ou igual ao intervalo de tempo de espera (hold-time) dos temporizadores de throttling de LSA.

Este recurso permite reduzir os impactos relacionados às inundações de LSAs em redes sofrendo instabilidades e ao mesmo tempo em que promovendo ótimos tempos de convergência.

Sobre o recurso OSPF Shortest Path First Throttling

O recurso OSPF Shortest Path First Throttling possibilita customizar o cálculo do procedimento SPF em intervalos de milissegundos e atrasar potencialmente estes cálculos de SPF durante eventos de instabilidade da rede. Normalmente, no OSPF, e sem considerar aqui este recurso, o procedimento SPF é programado para calcular a árvore do caminho mais curto (SPT) quando houver uma alteração na topologia, e sabendo que uma execução do SPF poderá incluir vários eventos de alteração de topologia.

A vantagem do recurso OSPF Shortest Path First Throttling aqui é que o intervalo no qual os cálculos do SPF deverão ocorrer é escolhido dinamicamente e baseado na frequência das alterações de topologia na rede. Este intervalo a ser escolhido deverá estar dentro dos limites dos intervalos de valores especificados por você, o administrador. Se a topologia de rede estiver instável, a otimização do SPF calculará os intervalos de agendamento do SPF como mais longos, até que a topologia se torne estável novamente.

O que você ganha com isto? Diminui o impacto no plano de controle de seus roteadores quando a rede estiver instável!

Sobre os Bidirectional Forwarding Detection (BFD)

Muitos não sabem, mas os temporizadores Hello e Dead precisam ser idênticos entre dois roteadores que devam formar uma adjacência OSPF. Se forem diferentes, os roteadores não conseguirão concluir o procedimento de formação de adjacência.

Visando acelerar a convergência da rede, em especial quando há um rompimento de um enlace de fibra entre dois roteadores, os administradores modificam ou customizam estes roteadores. Apesar de ser uma inciativa válida, a recomendação é que isto não seja feito com este propósito, pois poderá onerar ainda mais o processamento do OSPF.

Ao invés de fazer isto, considere a "terceirização" da checagem por disponibilidade de adjacência para outro serviço, prestado por um protocolo bastante confiável, eficiente, e bem lightweight (leve): o Bidirectional Forwarding Detection (BFD) ou "Detecção de Encaminhamento Bidirecional". Além de ser bem rápido em termos de detecção de falhas, podendo ser nível milissegundo, é um protocolo mais esperto do que este procedimento que o próprio OSPF utiliza. Explico melhor.

Quando um roteador OSPF percebe que uma interface "caiu" (o estado do protocolo IP da porta entrou em "down"), ele aciona rapidamente a convergência da rede. O desafio é quando ocorre uma falha de comunicação bidirecional neste link e o OSPF fica incapaz de perceber isto. O que ocorrerá: o OSPF deverá aguardar a expiração do Dead Interval (por exemplo, 40 segundos em redes Broadcast) para, somente depois, descobrir que o seu vizinho não está mais "vivo", e, portanto, acionando a convergência logo em seguida. Ou seja, percebe-se que os protocolos de roteamento não são muito espertos quanto à detecção destes tipos de incidente envolvendo a comunicação bidirecional.

Felizmente, o BFD suporta isto, e o faz muito bem. Consegue muito rapidamente identificar problemas de comunicação bidirecional em um link e imediatamente comunica este problema para o protocolo de roteamento poder tomar a ação.

A minha sugestão é que você estude e, se viável para o seu projeto técnico, adote o BFD para a rápida detecção de falhas de comunicação bidirecional nos links, ao invés de manipular os timers de Hello e Dead do OSPF. No geral, e em termos de processamento, é menos oneroso lidar com o BFD em segmentos críticos de sua rede do que ajustar os temporizadores de Hello e Dead nos roteadores OSPF. Note que não estou sugerindo para que você adote o BFD imediatamente: você precisa estudar e determinar onde, ao invés de modificar os timers do OSPF, fica melhor lidar com o BFD.

Por que você, como engenheiro de redes de um ISP, opta por usar o protocolo de roteamento OSPF em sua rede?

Um tanto óbvio, não? Mas encerraremos este artigo com uma proposta mais didática.

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 já 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?

A propósito, eu poderia ter mudado o título desta pergunta para citar "por que adotar um protocolo de roteamento Link-State?" ao invés de "OSPF" apenas, pois isto traria muita justiça ao protocolo de roteamento IS-IS!

Apesar de haver algumas semelhanças entre o OSPF e o IS-IS, são protocolos com características e propriedades bastante únicas na perspectiva de cada um. Eu particularmente prefiro o IS-IS, mas reconheço que o OSPF é muito mais difundido aqui no Brasil.

Não será desta vez que dissertarei sobre o IS-IS, pois o foco do artigo é o protocolo de roteamento OSPF, que é amplamente difundido entre os operadores de redes. Mas, fique tranquilo, falar (e muito bem!) de IS-IS está no meu radar aqui para a Wiki do BPF, assim como compará-lo com o OSPF.

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 e validado durante o procedimento. 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, em estruturas de dados denominadas Link-State Advertisements (LSA). 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 (LSA) 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 um tanto "quieto", principalmente em rede estáveis, pois, uma vez convergido por completo, não faz envio periódico de informações da rede. Ou seja, realiza apenas o chamado "triggered updates". Ainda com relação ao bullet anterior, o OSPF, sim, resincroniza 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: quantidade de elementos roteadores ativos, diâmetro da rede, 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 OSPF é 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, mas podem atuar (RIPv2) numa relação PE-CE em um serviço L3VPN MPLS. 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 muito 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 conhecidos 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 sobrevive 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 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 em outra ocasião. 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, um 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 existentes para que estes pudessem acomodar 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.
Compatibilidade nativa com o Segment Routing	Mesmo com o advento do Segment Routing como tecnologia que se propõe a substituir gradualmente as redes MPLS clássicas, novamente, isto só é viável com protocolos de roteamento Link-State, ou seja, o OSPF ou o IS-IS. No caso do Segment Routing, todas as funções de label switching e de engenharia de tráfego fluem diretamente pelos componentes destes protocolos de roteamento IGP. Portanto, sem OSPF ou IS-IS, não há como adotar o SR em sua rede.

O OSPF não morreu!

Não estou acreditando que tive que editar este artigo (edição: 30-05-2020) e gastar o meu tempo para ter que explicar alguma coisa sobre esta falácia de que o OSPF morreu ou que as empresas estão deixando de usá-lo. Vamos a alguns fatos rápidos:

• Se você possui uma rede de médio porte e o seu Core/backbone ainda for L2, principalmente no caso de ISP, tem alguma coisa muito errada com... VOCÊ. Aparentemente você não entende muito das coisas, mas fique a vontade para refutar. Numa rede corporativa/LAN, o L2 é aceitável, embora haja soluções melhores (SD-Access, SD-LAN, e outras). No ISP, jamais. No data center, a recomendação é por VXLAN, com ou sem o EVPN (recomendado).
• Você pode construir e manter redes de Acesso no ISP baseadas no L2, mas, por que você faria isto? Certamente não seria por motivos de maior eficiência, disponibilidade, resiliência ou confiabilidade, pois, redes L2 nativas, independentemente do protocolo de resiliência e de como funciona a arquitetura L2 do equipamento que você usa, jamais serão mais confiáveis, flexíveis e escaláveis que redes L3 onde o OSPF for o IGP. Então só me restam três argumentos possíveis:
  • Custos. A classe de equipamento que você usa na sua rede não suporta os recursos necessários para um projeto com tecnologias mais apropriadas, então você é obrigado a recorrer ao L2 e recursos complementares.
  • Falta de conhecimento do MPLS. Mesmo que o foco aqui seja o OSPF, por se tratar de uma rede de Acesso, você eventualmente precisará transportar serviços Ethernet/L2 sobre esta rede, em adição a outros serviços. Se a rede de Acesso e/ou backbone for baseado no OSPF, você precisará do MPLS para poder acomodar no topo deste uma emulação e transporte de serviço Ethernet, ou seja, fazendo isto por meios das tecnologias clássicas de L2VPN (VPLS, VPWS), ou partindo já para o Ethernet VPN (EVPN)
  • Há uma terceira sugestão aqui: você pode ter redes de Acesso com diâmetro adequado (não excessivamente extensas) contando com um bom protocolo de resiliência (ex: EAPS, G.8032, REP) interconectadas por um backbone MPLS, talvez isto fosse promover o melhor equilíbrio entre funcionalidades, KPIs como a disponibilidade + confiabilidade, e custos. E isto é tido como um bom projeto. Mas isto não seria melhor do que uma rede inteiramente MPLS com serviços L2VPN no topo, e tendo como o IGP para viabilizar isso tudo o OSPF ou o IS-IS.

Tendo dito tudo isto, informo ainda que o OSPF não só não morreu como cada vez mais as empresas o utilizam. Há muitos anos, e cada vez mais, redes inteiras dos maiores operadores de redes do mundo tem sido migradas para arquiteturas baseadas no MPLS, e, por esta e outras razões, o OSPF passa a ser uma exigência incondicional nestes projetos por conta das necessidades por engenharia e proteção de tráfego com o MPLS-TE + FRR. Ou então com o IS-IS.

Para concluir, mais recentemente, operadores tem aos poucos migrado as suas infraestruturas para a nova geração de arquiteturas baseadas no MPLS, neste caso para o Segment Routing. O que os "terraplanistas da telecom" não sabem é que o Segment Routing é uma tecnologia viabilizada integralmente por um protocolo IGP do tipo Link-State, ou seja, funciona diretamente pelo OSPF ou IS-IS. Sem OSPF (ou o IS-IS), simplesmente não há Segment Routing.

Os desafios de redes L2 nativas em ambientes de ISP são apresentados de forma bastante objetiva e didática neste video aqui:

Arquiteturas Carrier Ethernet Para Operadoras de Pequeno e Médio Porte - Leonardo Furtado

E, outra revisão disto, mas já mirando a adoção do Segment Routing e do Ethernet VPN, também aqui, neste vídeo:

Adoção de Tecnologias Cisco - Leonardo Furtado

Agora, voltemos à programação normal! Assunto encerrado.

Conclusão do artigo

Espero que este artigo tenha cumprido com a sua missão, que foi, ao mesmo tempo, disseminar boas práticas para a configuração do OSPF em redes de ISPs, assim como esclarecer um pouco mais sobre os fundamentos do OSPF para os "mais leigos".

Até o próximo artigo!

Autor: Leonardo Furtado