Minha jornada até o CCIE RS — OSPF

[giuks]

Olá possoal, tudo bem?

Vamos seguindo com mais um artigo nessa série compartilhando anotações acumuladas durante os anos de estudos até o CCIE Routing and Switching. Continuamos com centenas de páginas anotadas com muitas informações e observações que considero importantes depois de 15 anos trabalhando com R&S.

O objetivo é ajudar não apenas quem está estudando para certificações, mas no dia-a-dia de outros network engineers a lidar com infraestrutura Cisco. Para quem perdeu, seguem os links dos artigos anteriores sobre Switching, PPP e Roteamento IP, RIP e EIGRP. Abaixo segue a parte sobre “OSPF” e uma lista de comandos “show” básicos. Neste segundo artigo vamos explorar “Roteamento IP” 😉

Estejam a vontade para comentar e entrar em contato comigo no LinkedIn. Se gostou do conteúdo, incentivo a informar que o conteúdo foi útil aqui na Comunidade Cisco, clicando "útil" ao final do post.

---

OSPF

Protocolo de roteamento open standard baseado na RFC 2328 “OSPF Version 2”.

O principal arquiteto do OSPF e autor da RFC foi John T. Moy. Ele escreveu o livro “OSPF: Anatomy of an Internet Routing Protocol” onde explica os problemas que o OSPF tenta resolver.

OSPF é um protocolo de roteamento link-state, portanto todos os nós do domínio OSPF devem compartilhar as mesmas informações. Utiliza algoritmo SPF “Dijkstra” para determinar o melhor caminho no grafo.

• Curiosidade: Edsger Dijkstra foi um cientista da computação holandês e pronuncia “daikstra”.

OSPF é classless e portanto suporta VLSM.

Suporta NLRI summarization (network layer reachability information), agregando prefixos mais longos através de prefixos mais curtos (como no RIP e EIGRP).

OSPF suporta múltiplos processos no mesmo roteador baseados em process-IDs, onde os process-IDs são localmente significativos (não são enviados em nenhum update).

Ao habilitar OSPF, pelo menos uma interface IP deve estar UP/UP, porque OSPF utiliza um IP como router-id (interfaces loopback tem preferência).

• OBS: Todas as interfaces unnumbered atreladas a uma loopback, fazem parte da mesma área da loopback.

OBS: É importante garantir que o OSPF router-id seja único no domínio porque é este identificador que cada roteador usa na base de dados link-state. Se dois ou mais routers utilizarem o mesmo router-id, eles terão problemas para aceitar seus LSAs e computar o SPF.

O algoritmo SPF é computado para cada área, mas não entre áreas. Neste caso, o SPF computa caminho para os ABRs.

Neighbor Discovery

OSPF utiliza pacotes Hellos para descobrir neighbors, assim como EIGRP.

Utiliza protocolo de transporte IP 89 (OSPF).

Utiliza multicast 224.0.0.5, 224.0.0.6 ou unicast para enviar hellos, dependendo do meio. Por default, OSPF se comporta de forma diferente para cada meio L2 e, portanto, a topologia L2 pode ter um forte impacto na operação do OSPF.

Pacotes Hellos contém diversos atributos que os neighbors devem concordar para forma adjacência (bem mais que no EIGRP). Somente após a formação da adjacência os routers trocam LSDB (link-state database) entre si.

Adjacências

Os neighbors devem concordar com uma série de atributos para formar adjacência entre si. Por causa disso, é nesta fase que ocorrem a maioria dos problemas de configuração com OSPF.

Neighbors também devem possuir atributos únicos: router-id e endereço IP das interfaces.

O router-id é o que identifica o router na base de dados link-state. O SPF constrói um grafo onde os nós são os router-ids e as conexões entre os nós são os links.

OBS: OSPF parte do princípio que os endereços IPs são únicos. Porém se estivermos implementando anycast e os roteadores pegarem os mesmos router-ids, eles não irão estabelecer adjacência ou não trocarão LSA entre si.

Atributos comuns incluem:

• Area-ID (flooding domain)
• Hello and Dead interval
• Endereço de rede da interface (precisam estar na mesma rede)
• MTU
• Network type — controla comportamento do OSPF no link. Não precisam ser iguais, mas precisam ser compatíveis.
• Autenticação — Null Authentication (type 0) por default.
• Stub flag — controla que tipos de LSA são aceitos para cada área.
• Capacidades opcionais — utilizado para extensões de diferentes aplicações (Ex: MPLS traffic engineering)(ex: Nonstop Forwarding para Graceful Restart).

Depois que a adjacência é formada, os roteadores começam a trocar informação sobre a topologia e devem possuir a mesma cópia da Link-state Database.

OBS: Fazer troubleshooting baseado nos resultados, comportamento e saídas é mais fácil que debuggar a configuração. OSPF é bem complexo, portanto realizar troubleshooting olhando a config é menos eficiente.

LSA

LSA 1 — Cada router na topologia gera um Router LSA (LSA 1) se identificando e informando todos os links conectados. ABRs geram um LSA 1 por área que participam.

LSA 2 — Todo DR gera um Network LSA (LSA 2) representando um domínio de broadcast. O DR é um Pseudo Node Virtual com objetivo de diminuir o flooding de LSAs (que seria N(N-1)/2 devido ao full mesh). O LSA informa todos os neighbors deste segmento (anexos ao DR) incluindo o próprio DR.

Diferentes comportamentos para meios L2

O comportamento do OSPF muda baseado no meio L2. Por default, cada meio L2 usa diferentes network types para controlar:

• Como updates são enviados
• Como as adjacências são formadas entre neighbors
• Como o next-hop é calculado

Network Types

• Broadcast
• Non-broadcast
• Point-to-point
• Point-to-multipoint
• Point-to-multipoint non-broadcast
• Loopback

Broadcast

É o modo default para meios broadcast multi-acesso (ex: ethernet, token-ring e FDDI).

Hellos e Updates são enviados como multicast utilizando endereços 224.0.0.5 (AllSFPRouters) e 224.0.0.6 (AllDRouters).

Roteadores conectados ao meio realizam eleição para DR (Designated Router) e BDR (Backup Designated Router) com objetivo de diminuir o número de adjacências e flooding de LSAs. O DR representa um Pseudo Node Virtual utilizado recursivamente pelo SPF durante a computação do grafo.

Todos os neighbors formam adjacência com o DR e o BDR.

Designated Router (DR) é responsável por receber os LSUs dos neighbors no segmento e encaminhá-los aos demais neighbors. Neighbors encaminham LSUs para 224.0.0.6 (AllDRoutes) e DR reencaminha as LSUs para 224.0.0.5 (AllSPFRouters).

Backup Designated Router (DR) apenas escuta/recebe pacotes enviados para AllDRouters mas não encaminha e é utilizado somente como redundância.

DROthers são todos os outros neighbors do segmento. Os DROthers formam adjacência completa com DR e BDR, porém permanecem no estado 2way com todos os outros neighbors do segmento.

Eleição DR/BDR

• A eleição é baseada na prioridade e router-id (em caso de empate).
• A prioridade pode ser configurada de 0 a 255:
• — 0 — não participa da eleição
• — 255 — melhor prioridade
• O router-id é herdado da interface loopback com endereço IP mais alto ou de outra interface (se não houver loopback). Router-id também pode ser estaticamente ajustado.

OBS: Assim como BGP, MPLS, etc, é uma best practice configurar o router-id estaticamente evitando falhas na topologia devido a router-ids duplicados (geralmente ao configurar anycast).

Na eleição de DR/BDR não há preemption e ela ocorre de certa forma imprevisível baseada na ordem que os processos OSPF carregam. No caso de 2 DRs serem conectados ao mesmo segmento, ocorre uma nova eleição entre eles.

OBS: A única forma de garantir 100% qual router vai ganhar a eleição é desabilitando a eleição para todos os demais neighbors do segmento (priority 0), mesmo que temporariamente.

Em um segmento ethernet não importa muito quem é o DR porque todos os neighbors tem conectividade full mesh. Porém em uma rede partial mesh (ex: hub and spoke) é preciso garantir que o neighbor com conectividade para todos os outros seja eleito o DR (ex: o hub). Caso contrário, o hub não poderá replicar as LSUs recebidas do DR (um spoke) e portanto não haverá comunicação entre os outros spokes porque eles não receberão LSUs.

Non-broadcast

É o modo default para meios NBMA (ex: ATM e Frelay).

Hellos são enviados como unicast para neighbors configurados estaticamente no DR e BDR. Quando os neighbors detectam os hellos, responderão para o neighbor que iniciou a tentativa de adjacência.

Non-broadcast realiza eleição para DR/BDR. Em redes partial mesh precisamos garantir que o HUB seja o DR. Caso contrário, se um spoke for o DR, o HUB não irá reencaminhar as LSUs recebidas do hub para os demais spokes e portanto não haverá comunicação entre eles.

O DR não altera o next-hop dos LSAs recebidos de DROthers e reencaminhados para outros DROthers em redes “broadcast” e “non-broadcast”. Portanto, para garantir conectividade em topologias partial mesh podemos:

• Em cada spoke, mapear endereço L3 -> L2 de todos os demais spokes apontando para o circuito do HUB (essa solução não escala).
• Usar subinterfaces P2P eliminando necessidade de tradução L3 -> L2 (é a melhor maneira).

Point-to-multipoint

• Este modo trata a rede como uma coleção de links P2P e portanto elimina a necessidade de eleição DR/BDR.
• Hellos são enviados para 224.0.0.5 (AllSPFRouters).
• Neighbor utilizando este modo altera o next-hop dos LSAs replicados apontando para si mesmo.
• A database apresenta adjacências P2P separadas para cada neighbor (por isso altera next-hop) e apresenta os links point-to-multipoint como redes STUB (/32).
• Geralmente é a melhor opção de design para redes NBMA partial mesh.

Point-to-point

• Modo default para qualquer meio P2P (ex: PPP, HDLC).
• Hellos são enviados para 224.0.0.5 (AllSPFRouters)
• Não há eleição para DR/BDR porque assume que só há 2 neighbors no link.

OBS: Se uma rede broadcast possui somente 1 adjacência é interessante configurar como P2P, diminuindo o número de procuras durante a computação do SPF dispensando LSA 2 (interessante para redes grandes).

• Eleição DR/BDR:
• — Broadcast
• — Non-broadcast
• Não suportam eleição:
• — P2P
• — P2M
• — P2M-NB

Geralmente quando há mismatch entre os network types os neighbors se enxergam mas não estabelecem adj.

OBS: Quando os network types não são compatíveis mas os atributos são, os neighbors podem formar adjacência e trocar SLA. Porém devido a discordância na topologia o SPF não consegue gerar o grafo corretamente e portanto não instala as rotas corretas na tabela de roteamento. O troubleshooting desse cenário é muito complicado porque tudo parece estar OK e mesmo assim as rotas não aparecem na tabela.

OBS: Interfaces loopback aparecem como redes STUB na database e são divulgadas como /32 nas tabelas de roteamento. Para que a divulgação seja alterada (ex: para /24) é necessário declarar a interface como P2P.

Point-to-multipoint non-broadcast

Similar ao point-to-multipoint, porém hellos são enviados como unicast.

Este modo permite ajustar custo OSPF per-VC e é geralmente utilizado quando temos topologia partial mesh composta de VCs com BW diferentes (era típico em ambientes Frelay e ATM). Tratamos o cenário como uma coleção de links P2P, porém aplicamos o custo por neighbor (per-VC), porque no mundo real as BWs nunca são iguais.

OBS: Também é interessante utilizar custo por neighbor em ambientes ethernet com diferentes BW entre os neighbors no mesmo segmento.

Loopback

Caso especial utilizado para interfaces loopback e looped-back que propaga o link como uma rota stub host /32.

OBS: Para desabilitar este comportamento precisa declarar a interface como point-to-point propagando a máscara especificada na interface.

Path Selection

Uma vez que as bases de dados estejam sincronizadas, o processamento do SPF e seleção de caminho começa.

Assim como RIP ou EIGRP, o melhor caminho é baseado no menor custo fim-a-fim. Pela RFC, o custo do OSPF pode ser baseado de forma arbitrária (BW, hops, etc).

A implementação da Cisco usa BW, com BW de referência default de 100 Mbps. Hoje em dia obviamente faz sentido alterar a BW de referência para valores como 10 Gbps evitando que todos os links tenham custo 1.

Pela RFC, a seleção OSPF tem a seguinte ordem de preferência entre rotas para o mesmo prefixo (independente da métrica ou distância):

1. (O) Intra-area
2. (O IA) Inter-area
3. (E1) Extenal type 1
4. (E2) Extenal type 2
5. (N1) NSSSA type 1
6. (N2) NSSSA type 2

OSPF possui comportamento distance vector porque pesquisas inter-area não tem informação fim-a-fim, porque são recebidas de forma resumida através dos ABRs (no caso, apenas custos). O custo da rota fim-a-fim é calculado somando o custo informado pelo ABR e o custo do caminho intra area até o ASBR (ABR cost + Inter Area cost).

OBS: LSA 3 é chamado Network Summary não porque resume prefixos, mas porque resume informação sobre a topologia em outras áreas.

Alterações na topologia entre áreas diferentes resultam em recálculo parcial da topologia visto que o caminho até os ABRs se mantém.

Custo = BW Reference/BW Interface

Manipular a seleção de caminhos no OSPF é mais direto que no EIGRP porque pode trabalhar o custo numa base hop-by-hop.

Timers

Tempo de convergência no OSPF é basicamente o tempo para detertar que o neighbor está DOWN, trocar LSUs e recalcular o SPF.

Utilizar hellos OSPF muito curtos (1 seg ou menos) é um processo muito intenso para o OSPF. A solução mais recomendada nessa situação é usar BFD (Bidirectional Forwarding Detection). Porém BFD só é utilizado em equipamentos high-end ou mais novos.

Autenticação OSPF

OSPF suporta 3 tipos de autenticação:

• 0 = Null (sem autenticação)
• 1 = Clear Text
• 2 = Criptografada
• — SHA
• — Key chain (suporta rotação de key automática)
• — MD5
• Cada mensagem do OSPF é autenticada
• OSPF suporta autenticação da adjacência para proteger o control plane
• Todo cabeçalho de pacote OSPF inclui informação de autenticação
• — Hello, LSU, LSR…
• Autenticação não significa criptografia
• — Payload do OSPF v2 ainda é clear text
• — OSPF v3 suporta criptografia

Do ponto de vista do pacote OSPF, não há diferença entre habilitar autenticação por interface ou por área no processo. Obviamente, habilitar por área significa habilitar em todos os links daquela área.

Nova implementação de OSPF ainda é compatível com versões antigas. A única diferença é que possui novos algoritmos de criptografia tipo 2.

Usando Key chain:

• Na key chain precisa definir o algoritmo de criptografia.
• Usando key chain, OSPF se comporta parecido com EIGRP:
• — Múltiplas keys
• — Automatic key rotation
• — Uso de única key para múltiplas interfaces (antes cada interface tinha uma key)
• — Ainda existe a compatibilidade com modo MD5 desde que a key number e key string batam.

No modo novo, usa apenas um comando para habilitar autenticação e aplicar a key (modo antigo usa 2).

• <(int)#ip ospf authentication key-chain KEY>

Mismatch na autenticação pode ocorrer por tipo (mesmo sem password) ou por password.

OBS: Ao habilitar autenticação na área 0, lembrar que virtual-links sempre fazem parte da área 0.

OBS: Novamente, espaços em branco contam como caracter na senha.

OBS: Key number da senha deve ser igual, porque assim como no EIGRP, o key number é enviado no pacote.

OBS: Para testar autenticação <clear ip os proc> para restabelecer as adjs.

DOC: OSPFv2 Cryptographic Authentication

---

Leia o resto do artigo no link abaixo:

https://medium.com/techrebels/jornada-ccie-ospf-d181f108ec06

Se gostou do conteúdo, peço que informe que o conteúdo foi útil aqui na Comunidade Cisco, clicando em "útil" ao final do post.