1) O Open Shortest Path First (OSPF) é um protocolo de roteamento interior do tipo link-state que fornece rápida convergência e escalabilidade em redes grandes. 2) O OSPF utiliza diferentes tipos de mensagens (pacotes), incluindo Hello, Database Description, Link-State Request e Link-State Update, para descobrir vizinhos, trocar informações sobre links e manter a sincronia entre bancos de dados de roteamento. 3) O protocolo implementa o algoritmo Dijkstra para calcular a árvore de caminhos mais curtos

1. ResumodasPrincipaisCaracterísticaserecursos FormatosdosPacotesdoOSPF
O Open Shortest Path First (OSPF) é um protocolo de roteamento de gateway interior (IGP), e do tipo específico
denominado Link-State. Surgiu como proposta de substituição aos protocolos de roteamento Distance-Vector
, tais como
o RIPv1 e v2, e IGRP
, já que apresenta mecanismos mais sofisticados e que agregam em maiores índices de confiabilidade
na troca de mensagens, prevenção de routing loops, e escalabilidade, permitindo acomodar redes bem maiores e ao mesmo
tempo em que promovendo rápida convergência de caminhos.
AlgunsdospadrõeseRFCsestabelecidosparaoOSPF:
RFC 1583, OSPF Version 2
RFC 1765, OSPF Database Overflow
RFC 1793, Extending OSPF to Support Demand Circuits
RFC 1850, OSPF Version 2 Management Information Base
RFC 2154, OSPF with Digital Signatures
RFC 2328, OSPF Version 2
RFC 2370, The OSPF Opaque LSA Option
RFC 3101, The OSPF Not-So-Stubby Area (NSSA) Option
RFC 3623, Graceful OSPF Restart
RFC 4915, Multi-T
opology (MT) Routing in OSPF
OpenShortestPathFirst
OSPF
CabeçalhodoPacoteOSPF(24bytes)
Version Type PacketLength
RouterID
AreaID
AuthenticationType
Checksum
Authentication
Authentication
LeonardoFurtado,2022
Type1-Hello
Options
NetworkMask
RtrPriority
HelloInterval
DesignatedRouter
BackupDesignatedRouter
ListadeNeighbors
...
Type2-DatabaseDescription(DBD)
Interf.MTU Options
DDSequenceNumber
Um(01)Link-StateAdvertisementHeader
0 0 0 0 0 I M MS
...
+
+
Type3-Link-StateRequest(LSR)
LSType
Link-StateID
AdvertisingRouter
Type4-Link-StateUpdate(LSU)
#LSAs(quantidadedeLSAs)
Um(01)Link-StateAdvertisements(LSA)
+Type5-Link-StateAcknowledgement(LSAck)
Um(01)Link-StateAdvertisementHeader
+ +
...
DN O DC L N/P MC E MT
RouterDeadInterval
RTR-1 RTR-2
Gig0/0/1 Gig0/0/2
172.16.1.0/30
DownState
AttemptState
InitState
Two-WayState
ExstartState
ExchangeState
LoadingState
FullState
...
Olá,souoRouterID172.16.1.1.Temmaisalguémnesselink?
Hello
Olá!SouoRouterID172.16.1.2,evejoo172.16.1.1
UnicastdoRTR-2paraoRTR-1
ListadevizinhosdoRTR-2:
172.16.1.1,interfaceGig0/0/2
ListadevizinhosdoRTR-1:
172.16.1.2,interfaceGig0/0/1
Eucomeçareiatroca,poispossuooRouterID172.16.1.1
Hello
Negativo!Eucomeçarei,poisomeuRouterIDémaior;172.16.1.2
AquisegueoresumodomeuLink-StateDatabase(LSDB)
Hello
DBD
AquiestáoresumodomeuLink-StateDatabase(LSDB)
DBD
EstadosdeFormaçãodeAdjacências
Euprecisodemaioresdetalhamentossobrearede172.16.5.0/24
LSR
AquiestáoLSAdetalhadoreferentearede172.16.5.0/24
LSU
Obrigadopelainformação!
LSAck
Link-StateDatabases(LSDBs)sincronizadosecálculosconcluídos
DescobertadeVizinhos
SincronismodeBancodeDados
Conclusãodaconvergência
Hello
Master
Slave
1 3
4
PacotesdoOSPF
2
T
ype 1 - Hello: utilizado para descobrir vizinhos, iniciar o processo de formação de adjacências, e para a eleição de roteadores
Designated Router e Backup Designated Router em segmentos multiacesso. Em adição, serve como mecanismo de manutenção
das adjacências
T
ype 2 - Database Description (DBD): utilizado para a troca inicial de informações resumidas sobre os bancos de dados de
roteadores OSPF durante o estabelecimento de uma adjacência.
T
ype 3 - Link-State Request (LSR): utilizado durante a formação de vizinhanças entre roteadores OSPF
, logo após ambos os
roteadores terem trocados informações resumidas sobre os conteúdos de seus respectivos LSDB. O roteador
, precisando dos
LSAs detalhados referentes a redes citadas nos pacotes DBD recebidos, solicita ao seu vizinho estes LSAs detalhados com o uso
deste pacote LSR.
T
ype 4 - Link-State Update (LSU): invocado em duas circunstâncias, sendo a primeira como resposta aos pacotes LSR recebidos
de vizinhos, e, depois, com a rede já convergida e com adjacências em estado Full, para informar os roteadores adjacentes, para
comunicar novas informações sobre links da rede.
T
ype 5 - Link-State Acknowledgement (LSAck) para fornecer a confiabilidade requerida para o funcionamento do OSPF no que diz
respeito aos mecanismos de troca de mensagens, os LSAs inundados em uma área OSPF precisam ser explicitamente reconheci-
dos pelo roteador que os recebeu. O pacote LSAck é utilizado para este procedimento. Múltiplos LSAs podem ser reconhecidos
com um único pacote LSAck, seja via procedimento delayed por multicast, ou diretamente para o vizinho, dependendo das
circunstâncias acerca do recebimento do LSA.
RFC 3630, T
raffic Engineering (TE) Extensions to OSPF Version 2
RFC 4136, OSPF Refresh and Flooding Reduction in Stable T
opologies
RFC 4203, OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
RFC 4552, Authentication/Confidentiality for OSPFv3
RFC 4576, Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)
RFC 4577, OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)
RFC 4811, OSPF Out-of-Band Link State Database (LSDB) Resynchronization
RFC 4812, OSPF Restart Signaling
RFC 4813, OSPF Link-Local Signaling
RFC 5185, OSPF Multi-Area Adjacency
RFC 5187, OSPFv3 Graceful Restart
RFC 5250, The OSPF Opaque LSA Option
RFC 5286, Basic Specification for IP Fast Reroute: Loop-Free Alternates
RFC 5340, OSPF for IPv6 (RFC 2740 is obsoleted by RFC 5340)
RFC 5838, Support of Address Families in OSPFv3
RFC 3137, OSPF Stub Router Advertisement
RFC 3509, Alternative Implementations of OSPF Area Border Routers
RFC 5309, Point-to-Point Operation over LAN in Link State Routing Protocols
Internet draft draft-ietf-ospf-af-alt-10.txt, Support of address families in OSPFv3
Internet draft draft-katz-ward-bfd-02.txt, Bidirectional Forwarding Detection
Protocolo de roteamento interior (IGP).
Protocolo de roteamento IGP do tipo Link-State.
Escalável para redes grandes.
Rápida convergência e recuperação de falhas de links e nós da rede, se comparados aos recursos de protocolos Distance-Vector
.
Ótima “imunidade” natural contra o surgimento de routing loops.
Suporte a VLSM. e Classless Inter-Domain Routing (CIDR) como modelo de endereçamento.
Implantado sobre conceito de Áreas OSPF
, cujos os projetos podem considerar uma única área (single area) ou múltiplas áreas (multiarea).
Roteadores não trocam “rotas” especificamente, e sim informações sobre o estado dos links e roteadores
habilitados nas áreas OSPF
, ou seja, os chamados Link-State Advertisements (LSA), com o auxílio de pacotes OSPF
.
Diversos tipos de LSA são empregados, cada qual com uma função específica.
As mensagens do OSPF são transportadas por pacotes OSPF
, os quais, por sua vez, são transportados
diretamente sobre o protocolo IP (protocolo IP número 89), sem o emprego de protocolos de transporte de Camada 4 (TCP ou UDP).
Os pacotes OSPF são transportados por comunicações multicast para os endereços IP 224.0.0.5 (AllSPFRouters)
e 224.0.0.6 (AllDRouters), dependendo do regime de adjacências entre os roteadores, sendo que isto está condicionado ao tipo de rede OSPF
..
O TTL do cabeçalho IP destas transmissões é definido para “1”, ou seja, são pacotes não roteáveis, sendo, portanto, de Link-Local Scope,
e não exigindo a configuração de roteamento multicast (ex: PIM) para a sua implementação.
O OSPF implementa o algoritmo Dijkstra's Shortest Path First (SPF). Este algoritmo foi concebido pelo cientista holandês Edsger Dijkstra
em 1956 como medida para solucinarmos o problema do caminho mais curto num grafo dirigido ou não.
Cada LSA descreve informações sobre o estado dos links e roteadores da rede. Para que a troca de LSAs possa ocorrer
, os roteadores
precisam primeiro possuir uma adjacência completa (”Full”) entre si.
O OSPF não faz anúncios periódicos de seus LSAs. Após a inundação de LSAs em uma área, procedimento conhecido por “flooding”,
os únicos pacotes OSPF transmitidos na rede são os pacotes Hello. O OSPF implementa um mecanismo denominado “triggered updates”,
que são inundações de LSAs via pacotes LSU para os endereços 224.0.0.5 ou 224.0.0.6 (caso o segmento em questão seja uma rede OSPF
Broadcast ou NBMA), apenas quando ocorrem mudanças na topologia da rede (ex: link up, link down). No entanto, a cada 30 minutos,
vizinhos OSPF completamente adjacentes resincronizam os seus LSDB por intermédio de troca de pacotes DBD, apenas para
certificarem-se que, de fato, ambos possuem os mesmos detalhamentos topológicos em termos de LSAs.
Roteadores OSPF em uma determinada Area OSPF precisam possuir seus respectivos LSDB rigorosamente idênticos!
O algoritmo Dijkstra é executado sobre o LSDB por cada roteador
, sendo que os conteúdos dos LSDB de roteadores de uma mesma
área são idênticos. No entanto, o produto resultante desta computação, denominado Shortest Path T
ree (SPT), será único para cada
roteador
.
O SPT de cada roteador
, sendo único, fará com que estes melhores caminhos sejam ofertados para o processo que gerencia a tabela
de roteamento (ex: RIB Manager) à título de rotas OSPF
, as quais poderão ser ou não instaladas na RIB como rotas OSPF (dependendo da
presença de outras alternativas não-OSPF (melhor distância Distância Administrativa) para estes mesmos destinos) e, posteriormente,
ocorrendo a programação destes prefixos na FIB do plano de dados do equipamento, juntamente com as adjacências pré-computadas.
O OSPF mantém três estruturas de dados (”tabelas”): Adjacency T
able (tabe;la de adjacências/vizinhos), Link-State Database (LSDB),
e tabela de rotas OSPF (as mesmas que foram ofertadas para a tabela de roteamento (RIB), refletindo o seu conceito SPT).
As adjacências entre os roteadores OSPF são ditadas pelo tipo de rede OSPF (Network T
ype) definida nas interfaces participantes.
A eleição de roteadores chamados Designated Router e Backup Designated Router ocorre em redes OSPF do tipo Broadcast e NBMA,
e há diferenças em termos de temporizadores de Hello e Dead entre redes OSPF Broadcast e Point-to-Point, e NBMA.
Ethernet Header IP Header (n* 89) OSPF Header OSPF Data Ethernet FCS
T
ype 1 - Hello
T
ype 2 - DBD
T
ype 3 - LSR
T
ype 4 - LSU
T
ype 5 - LSAck
14 bytes 20 bytes 24 bytes T
amanho Variável 4 bytes
1) Down - o roteador não recebe pacotes Hello, inicia a transmissão de pacotes Hello para o
endereço 224.0.0.5 (AllSPFRouters), e transita para o estado Init.
Attempt - O estado Attempt é válido apenas para redes OSPF denominadas Non-Broadcast
Multi-Access (NBMA), significando que um pacote Hello não foi recebido do vizinho e que o
roteador local enviará um pacote Hello em unicast para aquele vizinho. Redes NBMA
apresentam desafios para o funcionamento das mensagens do OSPF por multicast, exigindo a
configuração manual das vizinhanças.
2) Init - o roteador transmite pacotes Hello para 224.0.0.5 e, ao receber um pacote Hello de um
vizinho, via transmissão unicast, e, se em seu campo de lista de vizinhos estiver listado o seu
próprio Router ID, o roteador entenderáentão que estágio Init está concluído, ou seja, que há
comunicação bidirecional, e, portanto, promoverá a transição para o estado T
wo-Way.
3) T
wo-Way - estabelecimento da comunicação bidirecional entre os dois roteadores vizinhos.
Em adição, em redes multiacesso (Broadcast e NBMA), ocorre a eleição de roteadores DR e
BDR, caso não existam naquele segmento por onde a adjacência está sendo estabelecida.
4) Exstart - negociação da relação temporária em regime master / slave entre ambos os
roteadores, em adição à comunicação do número de sequência dos pacotes DBD, o qual é
coordenado pelo roteador master
.
5) Exchange - pacotes DBD são trocados descrevendo o resumo dos LSDB de cada roteador
.
Cada pacote DBD contém apenas os cabeçalhos dos LSAs existentes no LSDB daquele
roteador
. O reconhecimento da troca dos pacotes DBD se dá com o uso dos próprios pacotes
DBD, onde o roteador simplesmente encaminha um pacote DBD contendo o número de
sequência informado pelo roteador vizinho, fazendo o seu reconhecimento de recebimento.
6) Loading - informações detalhadas destes dados são requisitadas com auxílio de pacotes
LSR, na medida em que os roteadores envolvidos na formação da adjacência necessitarem, e
respostas são fornecidas com o uso de pacotes LSU. O roteador deverá reconhecer explicita-
mente cada LSA mencionado nos pacotes LSU com o uso de pacotes LSAck.
7) Full - ambos os roteadores concluem a formação da adjacência, possuíndo seus LSDB
devidamente sincronizados.
O OSPF não define uma forma de fragmentação para seus pacotes, e depende da framentação IP quando transmitindo pacotes
maiores que o MTU das interfaces de saída. Se necessário, o comprimento do tamanho dos pacotes OSPF poderá ser de até
65.535 bytes (incluindo o cabeçalho IP). Dependendo do tamanho de uma área OSPF
, os pacotes DBD, LSR, LSU e LSACK
poderão ser substancialmente grandes, e, consequentemente, estes pacotes contendo muitas informações poderão exigir transmis-
sões por vários pacotes IP
, sem que isto vá provocar perda de funcionalidades dos pacotes OSPF
. . Este é o método recomendado
para quando necessário enviar pacotes OSPF grandes, ou seja, dividir os pacotes OSPF em múltiplos pacotes IP
, evitando-se
assim implementar quaisquer mecanismos de fragmentação de pacotes IP que excedam o MTU das interfaces. A fragmentação de
pacotes OSPF não é recomendada.
ComumatodosostiposdepacotesOSPF
...
ExigênciasparaaFormaçãodeAdjacências
5
Interfaces na mesma subrede IP - os roteadores vizinhos precisam estar na mesma subrede IP (máscara) para poderem concluir a formação da adjacência OSPF .
Interfaces na mesma Area OSPF (*) - as interfaces dos roteadores vizinhos envolvidos precisam estar na mesma Area OSPF .
Tipo de autenticação (*) - o OSPFv2 originalmente implementa três métodos de autenticação em seu cabeçalho: AuT
ype 0 (null), AuT
ype 1 (simple password), AuT
ype 2 (MD5). A
partir do RFC 5709 (OSPFv2 HMAC-SHA Cryptographic Authentication), para o AuT
ype 2, o OSPFv2 passou a suportar também o HMAC-SHA (1, 256, 384, e 512, em adição
ao Keyed-MD5), como resposta ao ataques passivos conforme descritos no RFC 1704. Roteadores vizinhos e em estágio de formação de adjacência OSPF precisam ter suas
respectivas interfaces envolvidas configuradas para o mesmo tipo de autenticação naquela Area OSPF .
String de autenticação (*) - em adição ao AuT
ype, os roteadores vizinhos envolvidos numa tentativa de formação de vizinhança precisam possuir a mesma string de autenticação,
seja a senha “clear text” (AuT
ype 1) ou hash (MD5) ou HMAC.
T
emporizadores de Hello e Dead Interval (*) - os timers de Hello e Dead precisam ser rigorosamente idênticos entre dois roteadores, em particular no que concerne às suas
respectivas interfaces em uma área OSPF
, para que a adjacência seja formada com êxito.
Sinalizador de Stub Area (*) - roteadores vizinhos em processo de formação de adjacência precisam concordar se ambos possuem suas respectivas interfaces definidas na
mesma área OSPF
, e se esta área em questão foi configurada ou não como Stub Area ou Not-So-Stubby (NSSA).
Maximum T
ransmission Unit (MTU) do IP - o IP MTU das interfaces de ambos os vizinhos deverá possuir o mesmo valor
.. A discordância quanto ao IP MTU, conforme o
campo Interface MTU dos pacotes Database Description Packets (OSPF packet type 2), fará com que o roteador que possuir o menor valor de IP MTU entenda que os
pacotes a serem recebidos possuirão um tamanho superior àquele que pode receber sem fragmentação. Isto fará com que estes pacotes DBD sejam descartados, e, consequen-
temente, ambos os roteadores não conseguirão fluir adiante no processo de formação da adjacência, ficando ambos travados no estado EXSTART por um longo tempo, e
alternando continuamente entre este estado e o DOWN.
TiposdeÁreasOSPF
7
RTR-1 RTR-2
Gig0/0/1 Gig0/0/2
172.16.1.0/30
RTR-1 Hello Packet:
Area ID: 0.0.0.0
Authentication T
ype: 2
Authentication: xpto123
Hello: 10 seconds
Dead: 40 seconds
Stub Area Flag (Options): E-bit
RTR-2 Hello Packet:
Area ID: 0.0.0.0
Authentication T
ype: 2
Authentication: xpto123
Hello: 10 seconds
Dead: 40 seconds
Stub Area Flag (Options): E-bit
Hello Hello
OSPFArea0.0.0.0
NetworkType
Point-to-Point
NetworkType
Point-to-Point
* parâmetros acima deverão ser idênticos,
o que é exigido para a formação de
adjacências entre dois vizinhos OSPF
* parâmetros acima deverão ser idênticos,
o que é exigido para a formação de
adjacências entre dois vizinhos OSPF
* parâmetros idênticos exigidos para a formação da adjacência
conforme campos específicos do pacote Hello
1) Backbone Area (0.0.0.0) - representa a área de backbone para projetos OSPF com múltiplas áreas. Neste tipo de projeto, toda
e qualquer Area OSPF precisa obrigatoriamente estar diretamente conectada à Area 0.0.0.0 (Backbone). Em projetos com uma
única Area OSPF
, esta área não precisa ser necessariamente a área 0.0.0.0, podendo, inclusive, ser qualquer número de área (32
bits). No entanto, por questões de padronização e boas práticas, recomenda-se que projetos com uma única área OSPF utilizem o
Area ID 0.0.0.0. Quando não for possível conectar uma área OSPF qualquer diretamente para a Area 0.0.0.0, um Virtual-Link poderá
ser construído para viabilizar a conexão entre as duas áreas utilizando-se uma terceira área como trânsito. Este cenário poderá ser
encontrado em outra seção deste material.
RTR-1 RTR-2
Gig0/0/1 Gig0/0/1
172.16.1.0/30
OSPFArea0.0.0.0
NetworkType
Point-to-Point
NetworkType
Point-to-Point
RTR-3 RTR-4
SW-1(L2)
172.16.1.16 /29
NetworkType
Broadcast
NetworkType
Broadcast
172.16.1.16 /29
RTR-5
NetworkType
Broadcast
Gig0/0/2
Gig0/0/2
Gig0/0/2
Gig0/0/2
Gig0/0/3 Gig0/0/3
Gig0/0/3
172.16.1.16 /29
172.16.1.4/30 172.16.1.8/30
2) Regular Area - como o próprio nome sugere, trata-se de uma área OSPF convencional, ou seja, não definida como área especial
(stub ou NSSA), mas que, ao mesmo tempo, não sendo a própria Area 0.0.0.0 (Backbone).
RTR-1 RTR-2
Gig0/0/1 Gig0/0/1
172.16.1.0/30
OSPFArea1.1.1.1
NetworkType
Point-to-Point
NetworkType
Point-to-Point
RTR-3
ABR
RTR-4
ABR
SW-1(L2)
NetworkType
Broadcast
NetworkType
Broadcast
RTR-5
NetworkType
Broadcast
Gig0/0/2
Gig0/0/2
Gig0/0/2
Gig0/0/2
Gig0/0/3 Gig0/0/3
Gig0/0/3
172.16.1.16 /29
172.16.1.4/30 172.16.1.8/30
OSPFArea0.0.0.0(Backbone)
3) Stub Area - a área Stub é um tipo de área especial do OSPF . Concebida originalmente para conectar roteadores menores /
de pequeno porte em regiões mais distantes da rede, e onde há apenas uma única conexão daquele roteador para o restante da
rede OSPF , mas que, ao mesmo tempo, é desejado que as subredes IP daquele site remoto sejam propagadas para os
demais roteadores da rede OSPF
. . Antigamente roteadores de pequeno porte tinham problemas em escalar para tabelas de
roteamento grandes com rotas IGP / OSPF , devido à limitações de CPU e memória. Portanto, a solução via uma área Stub é
permitir com que estes sites remotos, equipados com roteadores com restrições de processamento (CPU e memória), possam
participar de uma rede OSPF grande sem que ocorram problemas de processamento com estes equipamentos mais limitados.
Atualmente o uso de áreas Stub para este propósito de aliviar o processamento não tem sido uma exigência comum, graças à
evolução das arquiteturas de roteadores, mesmo os de pequeno porte, que tem dado conta do recado.
Uma área Stub permite a troca de LSAs detalhados da própria área (LSA T
ypes 1 e 2), além de LSAs que resumem as subredes
IP de outras áreas OSPF (LSA T
ype 3). No entanto, redes externas que tenham sido redistribuídas para o OSPF (representadas
pelos LSA T
ype 5) não são autorizadas em uma área Stub. O roteador ABR de uma área Stub gera automaticamente uma rota
padrão/default (0.0.0.0/0) para permitir a conectividade de computadores daquela área Stub para redes externas OSPF presentes
em outras áreas da rede OSPF
. . Em suma, o LSDB do OSPF e, consequentemente, a tabela de roteamento (RIB) de roteadores
numa área Stub não possuem LSAs externos (LSDB) e rotas OSPF externas (RIB), e a conectividade para estas redes externas
se dá com o auxílio de uma rota padrão, gerada automaticamente pelo roteador ABR da área Stub..
RTR-1 RTR-2
OSPFArea2.2.2.2
RTR-3
ABR
RTR-4
ABR
SW-1(L2)
NetworkType
Broadcast
NetworkType
Broadcast
RTR-5
NetworkType
Broadcast
Gig0/0/2
Gig0/0/2
Gig0/0/2
Gig0/0/2
Gig0/0/3 Gig0/0/3
Gig0/0/3
172.16.1.16 /29
172.16.1.0/30 172.16.1.4/30
OSPFArea0.0.0.0(Backbone)
OSPFArea1.1.1.1
(Stub)
http://leonardofurtado.wiki.br/
https://www.youtube.com/c/LeonardoFurtadoNYC
LeonardoFurtado
3) T
otally-Stybby Stubby - uma área T
otally Stubby é essencialmente uma área Stub cujo seu roteador ABR (Area Border Router)
tenha sido configurado para não permitir a entrada de quaisquer LSAs inter-area (LSA T
ype 3), Summary ASBR (LSA T
ype 4) ou
Externos (LSA T
ype 5). A proposta deste tipo de área épreservar o máximo de recursos de processamento possíveis de seus
roteadores internos, já que os bancos de dados (LSDB) e, consequentemente, suas tabelas de roteamento deverão manter
apenas as redes oriundas da própria área. Para que os roteadores internos de uma área T
otally Stubby possam se comunicar
com destinos IP localizados em outras áreas, o roteador ABR deverá gerar a devida rota padrão (0.0.0.0/0).
RTR-1 RTR-2
OSPFArea2.2.2.2
RTR-3
ABR
RTR-4
ABR
SW-1(L2)
NetworkType
Broadcast
NetworkType
Broadcast
RTR-5
NetworkType
Broadcast
Gig0/0/2
Gig0/0/2
Gig0/0/2
Gig0/0/2
Gig0/0/3 Gig0/0/3
Gig0/0/3
172.16.1.16 /29
172.16.1.0/30 172.16.1.4/30
OSPFArea0.0.0.0(Backbone)
OSPFArea1.1.1.1
(TotallyStubby)
4) Not-So-Stubby (NSSA) Area - uma área Stub / T
otally Stubby não permite LSAs externos, certo? Imagine que, numa área
Stub, você precisasse acomodar um cenário de redistribuição de rotas externas para o OSPF: você conseguiria manter um
roteador ASBR (Autonomous System Boundary Router) num área Stub? Certamente, não! E éaí que a área NSSA!
Numa área NSSA, as regras são basicamente as mesmas de uma área Stub: não são permitidos ou aceitos LSAs Externos (T
ype
5) e Summary ASB (T
ype 4). Mas, no entanto, é possível posicionar um ASBR para a realização da redistribuição de rotas
externas para o OSPF
. . Para que isto funcione, os LSAs "Externos" são gerados como LSA T
ype 7 (AS External LSA) ao invés
de LSA T
ype 5. Os roteadores em uma área NSSA precisam concordar com o bit "N" para a formação das adjacências, e o
roteador ASBR posicionado nesta área, ao redistribuir as rotas externas para o OSPF
, geram os devidos LSA T
ype 7, e, no
cabeçalho destes LSAs, um bit ("P-bit") indica que deverá ocorrer a propagação (conversão de LSA T
ype 7 para T
ype 5) pelo
roteador ABR. Este bit não éassinalado quando o roteador ASBR for
, ao mesmo tempo, o próprio roteador ABR desta área.
Dentro desta área OSPF NSSA, as redes externas são identificadas por LSAs T
ype 7. No entanto, o roteador ABR (Area Border
Router) da área NSSA converterá esses LSA T
ype 7 para LSA T
ype 5 quando repassando-os para a Area 0.0.0.0 (Backbone
Area), juntamente como a geração do devido LSA T
ype 4 (Summary ASBR) para o Backbone. Você precisará gerar a rota padrão
(0.0.0.0/0) no roteador ABR para que os roteadores internos da área NSSA possam se comunicar com destinos representados
por rotas externas, localizados em outras áreas.
RTR-1 RTR-2
OSPFArea2.2.2.2
RTR-3
ABR
RTR-4
ABR
SW-1(L2)
NetworkType
Broadcast
NetworkType
Broadcast
RTR-5
NetworkType
Broadcast
Gig0/0/2
Gig0/0/2
Gig0/0/2
Gig0/0/2
Gig0/0/3 Gig0/0/3
Gig0/0/3
172.16.1.16 /29
172.16.1.0/30 172.16.1.8/30
OSPFArea0.0.0.0(Backbone)
OSPFArea1.1.1.1
(NSSA)
172.16.1.4/30
EIGRP
RTR-6
ASBR
Gig0/0/1
Gig0/0/1
5) T
otally Not-So-Stubby (NSSA) Area - uma área T
otally NSSA éessencialmente uma área NSSA que não aceita quaisquer
LSAs referentes a outras áreas do domínio OSPF (LSA T
ype 3 (Summary)), ou LSAs Externos (LSA T
ype 5), e sem a entrada,
também, de LSAs T
ype 4 (Summary ASBR). No entanto, obviamente, uma área T
otally NSSA permite o posicionamento de um
roteador ASBR, com redistribuição de rotas externas para o OSPF nos mesmos moldes discutidos previamente, no caso das
áreas NSSA. E, assim como numa área NSSA, o roteador ABR da área T
otally NSSA precisarágerar uma rota padrão (0.0.0.0/0)
para que os roteadores internos desta área possam se comunicar com destinos localizados em outras áreas OSPF (destinos
inter-area) e redes externas cujos respectivos roteadores ASBR estiverem localizados em outras áreas.
VizinhançasOSPFemredesmultiacesso
6
Numa subrede IP
, onde houver vários roteadores OSPF , tecnicamente ocorreria uma tentativa de formação de adjacências em
todos os roteadores presentes, o que seria tecnicamente ruim: excesso de adjacências/vizinhanças em estado Full, e excesso de
"falatório" durante as trocas de LSAs entre os roteadores. Éo que chamamos de adjacências "Full Mesh". Dez (10) roteadores
numa subrede + VLAN, na mesma área, resultariam em quarenta e cinco (45) adjacências (vide fórmula N (N - 1) / 2). Em
ambientes "ocupados", e com eventos frequentes, estas condições seriam desfavoráveis.
Para evitar isto, numa rede multiacesso, o OSPF apresenta uma facilidade nativa denominada Designated Router (DR). Numa
rede multiacesso, todos os roteadores reconhecem uma comunicação bidirecional (T
wo-Way) entre si, mas completam as
adjacências (Full) somente com os roteadores designados: Designated Router (DR) e Backup Designated Router (BDR), permane-
cendo o estado das adjacências com os demais roteadores em "DRother". As regras:
1) Cada interface e de cada roteador plugado numa rede multiacesso (ex: numa mesma VLAN) possui um valor de prioridade
(Priority), cujo padrão de fábrica é "1". Este valor de prioridade é configurável e por interface. A configuração de valor "zero" (0) numa
interface implica que aquele roteador não participará da eleição de DR/BDR.
2) Numa rede multiacesso, roteadores OSPF só podem fechar adjacência com o roteador designado (DR), o que émandatório.
Não é mandatório, no entanto, a presença de um roteador BDR, embora isto seja recomendado.
3) Os pacotes Hello mencionam os roteadores DR e BDR presentes no segmento. Caso já exista um roteador DR, o roteador
OSPF recém-inserido no segmento concluirá a adjacência com este DR. Havendo, também, um roteador BDR, idem.
4) Não havendo um roteador DR, o roteador que possuir a interface com melhor valor de Priority será eleito como DR. A
segunda maior prioridade será eleito como BDR. Caso haja empate nos valores de prioridades das interfaces dos roteadores
participantes, aquele que possuir o maior Router ID será eleito o DR, e a segunda maior prioridade será o BDR.
5) Caso já haja um roteador DR no segmento, a inserção de um roteador com uma interface de valor Priority maior ou apresen-
tando um Router ID maior NÃO ocupará o lugar do DR existente (não ocorrerátakeover!). A queda/indisponibilidade do roteador
DR fará com que o roteador BDR seja promovido para DR, e uma ocorrerá uma eleição para roteador BDR.
6) T
oda a comunicação (inundação ou "flooding" de LSAs num segment multiacesso é feita para o endereço IP multicast reservado
para os roteadores DR e BDR: 224.0.0.6. O roteador DR, ao receber um pacote LSU vindo deste endereço 224.0.0.6 inundará os
LSAs para os demais roteadores via o endereço IP 224.0.0.5.
172.16.1.0/25
BDR
DR
Pri255 Pri200
Pri1 Pri1 Pri1 Pri0
TiposdeLSAs
7
Projetos OSPF podem ser single-area ou multi-area. Quando desejamos escalar bem com as redes OSPF , um projeto com
múltiplas áreas é recomendado. E sabemos que roteadores OSPF não trocam "rotas" exatamente, e sim estruturas de dados
denominadas Link-State Advertisements (LSA). E, para completar a linha de raciocínio, você já deve ter ouvido falar que
roteadores OSPF "mantém uma topologia completa da rede!". Esta afirmação está parcialmente correta: na verdade, roteadores
OSPF mantém topologias completas por área, e não da rede "toda"! E lembrando que o projeto de áreas do OSPF é definido por
interface de cada roteador
, e não por roteadores inteiros. Cada roteador numa área OSPF possui informações completas de
todos os links e demais roteadores presentes naquela mesma área em que uma de suas interfaces tiver sido definida, além de
meros "resumos" sobre outras redes IP
, presentes em outras áreas OSPF ou de redes IP externas que tenham sido redistribuídas
para o OSPF
.
O que descreve os detalhes topológicos do OSPF e os "resumos" de redes presentes em outras áreas e demais redes externas
são justamente os LSAs mantidos nos bancos de dados (LSDB) de cada área! Há diversos tipos de LSAs, comentados a seguir:
1) LSA T
ype 1 - Router LSA: cada roteador se apresentará para aquela área, basicamente "eu sou o roteador X, possuo estas
interfaces, nestas redes IP , com estes custos, e possuo vizinhanças com os roteadores Y e Z". As estruturas ADV Router ID e
LSA ID basicamente apontam para aquele próprio roteador
. É um LSA "detalhado", e não é repassado para outras áreas, ficando
confinado na área em que foi gerado. Se numa área OSPF há 10 roteadores, haverá 10 LSAs T
ype 1 no banco de dados (LSDB)
daquela área.
2) LSA T
ype 2 - Network LSA: roteadores OSPF em um segmento multiacesso só podem concluir suas adjacências (Full) com os
roteadores DR e BDR daquele segmento. Quem comanda as comunicações em um segmento multiacesso é o roteador DR,
ficando o BDR apenas como "backup", em caso de indisponibilidade/falha do roteador DR. Sendo assim, um LSA específico é
necessário para comunicar na área OSPF sobre segmentos/redes multiacesso, e esta é a justamente a função do LSA T
ype 2.
Este LSA é gerado somente pelos roteadores DR, sendo também um LSA "detalhado", e não repassado para outras áreas OSPF
.
, ou seja, ficando confinado na área em que foi gerado. O LSA ID é a própria subrede IP em que governa o DR, e o ADV Router
ID éo Router ID do roteador DR daquele segmento. Em áreas OSPF onde não há segmentos multiacesso mantidos por
roteadores DR, não haverá, no LSDB daquela área, qualquer LSA T
ype 2.
3) LSA T
ype 3 - Summary LSA: a proposta de um projeto multi-area do OSPF é escalarmos para redes bem grandes, certo?
Mas, sabemos que os detalhamentos topológicos são confinados "por área", ou seja, os LSA detalhados (T
ype 1 e T
ype 2) ficam
restritos em suas respectivas áreas em que foram gerados. Como, então, um roteador
, numa área, conseguirá conhecer redes IP
presentes em outras áreas de sua rede OSPF? É aí que entra o LSA T
ype 3 (Summary LSA). Um projeto multi-areas do OSPF é
hierárquico por natureza, obrigando uma hierarquia de dois níveis: toda área OSPF obrigatóriamente precisa estar conectada à
área 0.0.0.0 (Backbone), desconsiderando aqui o caso dos Virtual Links. Quando um roteador possui uma ou mais interfaces na
área 0.0.0.0 e uma ou mais interfaces em outra(s) área(s), ele se tornará automaticamente um roteador de borda de área (Area
Border Router ou ABR). Roteadores ABR produzem um resumo (lista mesmo, e não "sumarização de rotas") das redes IP
identificadas pela computação SPF realizada sobre o LSDB da área, e gerando, para cada uma destas redes IP , um LSA T
ype 3.
Este LSA T
ype 3 é então repassado para a área 0.0.0.0 (Backbone) informando que aquela rede IP (LSA ID) é acessível a partir
daquele ADV Router ID (RID do roteador ABR que produziu o LSA T
ype 3). Os roteadores do Backone (área 0) conseguem fazer
a computação SPF para aquela rede IP , pois, o roteador ABR, obviamente, também participa da área 0, e o LSDB desta área 0
descreve os LSAs detalhados (1 e 2 (se houver)) sobre como chegar até o roteador ABR. Os demais roteadores ABR presentes
na área 0, ao receberem o LSA T
ype 3, modificam o ADV Router ID para si próprios (seus respectivos Router ID) antes de
repassarem este LSA para as suas respectivas áreas OSPF . E, para concluir
, somente roteadores ABR é que podem efetivamen-
te sumarizar (agregar) rotas OSPF!
4) LSA T
ype 4 - Summary ASBR: para você entender a função e o funcionamento do LSA T
ype 4, você precisa entender primeiro
o LSA T
ype 5. Roteadores que redistribuem rotas externas (ex: RIPv2, EIGRP , rotas estáticas, conectadas, etc.) para o OSPF
são identificados como Autonomous System Boundary Router (ASBR). Cada rede externa redistribu'ída para o OSPF é
identificada por um LSA T
ype 5 (External) contendo o LSA ID (o prefixo externo) e o ADV Router ID (que, neste caso, é o Router
ID do roteador ASBR, que fez a redistribuição daquela rede). O problema é que o ADV Router ID de um LSA T
ype 5 (External) é
imutável, ou seja, não muda ou não é modificado, quando repassado para outras áreas OSPF! Roteadores internos numa mesma
área OSPF onde estiver um ASBR não enfrentam qualquer dificuldade em computar os caminhos até o ASBR, pois, naquela
área, eles possuem acesso ao LSA T
ype 1 referente ao roteador ASBR. Mas, e quanto aos demais roteadores, presentes em
outras áreas, como eles computariam o melhor custo até o ASBR, já que LSAs T
ype 1 (neste caso, aquele referente ao ASBR)
não podem ser inundados para outras áreas, ficando confinados àpenas nas áreas em que são gerados? É aí que entra o LSA
T
ype 4. Roteadores ABR de áreas onde há roteadores ASBR repassam os LSA T
ype 5 (as redes externas) preservando o ADV
Router ID (ASBR) para a área 0.0.0.0 (Backbone), mas, na ocasião, aproveitam uma oportunidade para gerar e inundar na área
backbone um LSA T
ype 4 contendo como LSA ID o RID do ASBR e o ADV Router ID o RID do próprio ABR. Isto permite que
roteadores fora da área onde está o ABSR consigam "juntar as peças" e computar
, simultâneamente, o LSA T
ype 5 (rede externa)
+ T
ype 4 (ASBR + ABR) + T
ype 1 (ABR), resolvendo o problema. É importante frisar que apenas roteadores ABR geram LSAs
T
ype 4, que os demais roteadores fazem a modificação de ADV Router ID dos LSA T
ype 4 recebidos antes de repassarem estes
mesmos LSAs T
ype 4 para as suas respectivas áreas, e que, em uma dada área OSPF , não há LSAs T
ype 4 referentes a
roteadores ASBR presentes naquela mesma área.
5) LSA T
ype 5 (External): quando um roteador redistribui uma rede externa para o OSPF , ele é automaticamente identificado
como roteador Autonomous System Boundary Router (ASBR). Cada rede IP externa é representado por um LSA T
ype 5
(External LSA) separado, contendo, como Link-State ID (LSA ID) o prefixo da rede externa e, como ADV Router ID, o Router ID
do ASBR (nos moldes discutidos previamente). Qualquer roteador pode ser um ASBR, exceto em áreas Stub/T
otally Stubby. Há
dois tipos de LSA T
ype 5: External T
ype-1 (E1) e External T
ype-2 (E2). As diferenças: no caso do E1 (e do N1, o equivalente nas
áreas NSSA), os roteadores da rede OSPF computam o custo da rede externa + os custos dos caminhos internos/OSPF até o
roteador ASBR. Já nas rotas E1 ou N2 (T
ype 7 NSSA), os roteadores computam somente o custo da rede externa, desprezando
os custos dos links internos até o roteador ASBR, ou seja, um custo padrão (ou customizado) é atribuído para aquele LSA T
ype 5
(o prefixo, rede externa) e este custo será preservado, sem modificações quaisquer
, em toda a rede OSPF .
6) LSA T
ype 6 (Group Membership LSA): usado pelo Multicast OSPF
, ou seja, quando o OSPF é usado para roteamento IP
Multicast. Não é suportado por vários vendors, dentre eles a Cisco, pois, sem dúvidas, projetos IP Multicast com PIM ou BIER
são muito mais interessantes, escaláveis, flexíveis e atraentes.
7) LSA T
ype 7 (AS External LSA): numa área NSSA ou T
otally NSSA não são permitidos LSAs T
ype 5, lembra? Portanto,
entenda que o LSA T
ype 7 tem o mesmo propósito dos LSA T
ype 5 gerados nas áreas não-NSSA, inclusive com definições de
T
ype 1 (N1) e T
ype 2 (N2).
8) LSA T
ype 8 (OSPF External Attributes LSA): pensado para que o OSPFv2 pudesse transportar os atributos do BGP em um
domínio OSPF de um Autonomous System (AS). Imagine uma "gambiarra" pensada para substituir
, onde viável, sessões IBGP .
Obviamente, a ideia não deu muito certo e, portanto, sequer foi padronizado para o OSPFv2. Não é usado pelo OSPFv2 (IPv4).
9) LSA T
ype 9 (Link-Local Opaque): os LSA Opaque (9, 10, 11) foram originalmente pensados para transitar capacidades
adicionais pelo OSPF . O T
ype 9, especificamente, não é usado pelo OSPFv2.
10) LSA T
ype 10 (OSPF Area Scope Opaque LSA): o único LSA Opaque relevante para o OSPFv2, pois é usado pelas
implementações de MPLS T
raffic Engineering para codificar os atributos e métricas de engenharia de tráfego.
11) LSA T
ype 11 (OSPF AS Scope Opaque LSA): LSAs para fins de MPLS TE, assim como o T
ype 10, mas que não devam ser
inundados para áreas especiais (Stub).
"T
o-Do": este material foi produzido "às pressas" para uma instrução OSPF para uma turma do curso ENSA (CCNA). Será editado posteriormente para incluir o OSPFv3
(para ambos IPv6 e IPv4), as diferenças entre ambos o OSPFv2 e OSPFv3, além de comentar a respeito de recursos e funcionalidades avançadas para o OSPF , tais como:
Virtual-Link, Sham-Link, OSPF Overload, SPF Throttling, LSA Throttling, e outros.
Para maiores dicas sobre o OSPF , confira: https://wiki.brasilpeeringforum.org/w/Boas_praticas_para_a_implantacao_do_ospf_em_ambientes_de_isp