Minha jornada até o CCIE RS — OSPF
Continuo esta série de artigos compartilhando minhas anotações acumuladas durante anos de estudos até passar no lab de CCIE RS anos atrás. Somando quase 400 páginas de caderno com informações e observações que considerei importantes ao trabalhar com Routing and Switching quase 15 anos.
Espero que estas informações ajudem não somente a passar em certificações, mas no dia-a-dia de outros profissionais (assim como eu) ao lidar com infraestrutura Cisco. Inclusive, o Medium permite que vocês destaquem ou adicionem observações no próprio texto.
Para quem não leu os artigos anteriores, seguem os links sobre “Switching”, “PPP”, “IP Routing”, “RIP” e “EIGRP”. Abaixo segue a parte sobre OSPF e uma lista de comandos show + filtros que considero eficiente.
Fique a vontade para comentar e entrar em contato comigo no LinkedIn. Se gostou do que leu, incentivo a compartilhar com colegas do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow lá em cima :)
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):
- (O) Intra-area
- (O IA) Inter-area
- (E1) Extenal type 1
- (E2) Extenal type 2
- (N1) NSSSA type 1
- (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
Sumarização
Ponto chave no processo de sumarização é lembrar que devido ao comportamento do link-state do OSPF, todos os roteadores dentro da mesma área devem ter a mesma LSDB. Isto implica que a sumarização só pode ocorrer entre áreas (ABR) ou durante a redistribuição (ASBR).
Independente do resumo criado, o processo OSPF sempre gera uma discard route. Portanto, para encaminhar o tráfego para outro prefixo mais curto precisa desabilitar a discard-route.
Implementar Engenharia de Tráfego em IGP é complicado porque não pode ser implementada “por prefixo” e se alterarmos o custo de um link, podemos alterar todas as rotas que passam por este link.
Portanto o melhor modo de implementar engenharia de tráfego no OSPF é usar prefixos mais longos e mais curtos.
OBS: Tráfego encaminhado para discard-route retorna como ICMP UNREACHABLE. Interessante desabilitar este comportamento para evitar ataques de mapeamento.
OBS: Ao analisar uma rota, metric é a métrica redistribuída pelo ASBR enquanto forward metric é a métrica até o ASBR. A forward metric é usada por default entre rotas com mesma metric.
OBS: Forward address com valor 0.0.0.0 significa que a rota a ser utilizada é aquela para o advertising router.
Filtering
Principal problema em filtrar rotas no OSPF é que por ser link-state, todos os routers na mesma área precisam ter a mesma LSDB (mesmo problema da sumarização). Isso implica que os filtros só podem ser configurados na borda de uma área e não dentro da área.
Área STUB
Áreas STUB filtram baseado no tipo de LSA.
Remove rotas externas (LSA 5) e rota para ASBR (LSA 4), afinal não precisa mais dele. ABR então origina default route inter-area (LSA 3) para substituir LSA 4 e 5.
OBS: Todos os routers dentro de uma área devem concordar com o tipo da área: normal, STUB ou NSSA. Porém cada router pode diferir quanto aos parâmetros configurados nessa área.
Totally Stub
Possui o mesmo comportamento de uma área STUB, além de remover também todas as rotas inter-área (LSA 3).
Esse modo reduz drasticamente a tabela de roteamento porque remove todas as rotas para outras áreas.
Not-so-Stubby
Assim como área STUB remove rotas externas (LSA 5) e propagação de ASBR (LSA 4), porém permite a geração de rotas externas NSSA (LSA 7) (N1 ou N2).
OBS: ABR de uma área NSSA não origina uma rota default (LSA 3) por default. A razão é que isso iria prevenir o ASBR de redistribuir uma rota default (LSA 7) por causa da precedência (independente da métrica).
Rotas NSSA (N1 e N2) são convertidas pelos ABRs em Externas (E1 e E2), porém mantém por default o forwarding address apontando para o ASBR. Portanto, é possível que um prefixo divulgado por um ABR seja roteado através de outro ABR com um caminho melhor até o ASBR.
Not-so-Totally-Stubby
Possui o mesmo comportamento de uma área Totally-Stubby, porém aceita a geração de rotas externas NSSA (LSA 7).
Engenharia de tráfego no OSPF pode ser alcançada misturando áreas STUB, prefixos mais curtos ou longos, rotas default de diferentes LSAs (prioridades).
Redistribuição na NSSA
Numa situação onde o ABR também é ASBR, a redistribuição gera um LSA 5 na área 0 e LSA 7 na área NSSA. Neste caso podemos desabilitar a redistribuição para a NSSA (nada de LSA 7).
Eleição de tradutor NSSA
Como o LSA 7 transita somente na NSSA, o ABR NSSA converte os LSAs 7 em LSAs 5 para propagar na área 0. Somente um ABR pode realizar essa tradução e caso exista mais de um, irão realizar uma eleição baseada no router-id mais alto.
Neste caso, se o forwarding address é não-zero, o ABR que divulgar pode não ser aquele que roteará o tráfego porque outro ABR pode ter um caminho melhor até o ASBR. Neste caso podemos suprimir o forward-address (0.0.0.0) para que o forward-address seja o advertising router (ABR).
Filtro LSA 3
Lembrando que todos os routers que participam de uma área precisam compartilhar (concordar) a mesma LSBD, os routers de uma área STUB só podem filtrar baseados no tipo de LSA (e não por prefixo).
ABRs podem filtrar quais prefixos LSA 3 eles geram entre as áreas através de prefix-lists.
Cuidado ao filtrar endereços que são forward-address para rotas externas NSSA. Se não houver rotas para o forward address de uma rota externa, esta rota também não é instalada na tabela de roteamento (é um cenário bem específico). Uma solução para este problema é suprimir o forward-address (0.0.0.0) para que o tráfego seja encaminhar direto para o ABR (advertising router).
Comandos Show para OSPF
sh ip os
sh ip prot | se os
sh ip os int
sh ip os int bri
sh ip os nei
sh ip os nei det
sh ip os data
sh ip os data self
sh ip os data router x.x.x.x
sh ip os data sum x.x.x.x
sh ip os data ext x.x.x.x
sh ip os data nssa x.x.x.x
sh ip os border
sh ip route os
sh ip rib route os
sh ip cef x.x.x.x
sh ip nhrp
sh ip nhrp bri
sh ip os ev
deb ip os adj
Esse resumão sobre OSPF te ajudará no dia-a-dia?
Faltou algum ponto chave?
Fala pra gente nos comentários?
Se gostou do conteúdo, peço para compartilhar com outros do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow aí embaixo :)
Sobre o autor:
Giuliano Barros é Network Consultant & Founder da Control Plane — Network Services.
Graduado em Ciência da Computação, certificado CCIE RS pela Cisco Systems e trabalha há 15 anos em projetos para grandes e médias empresas. linkedin.com/in/giulianobarros