O OSPF usa o algoritmo SPF – Shortest Path First, para encontrar o melhor caminho para cada nó (roteador) no gráfico (rede), e consequentemente o melhor caminho para cada rede. Diferente dos protocolos Distance Vector, cada nó (roteador) anuncia o estado de seus links, e após receber a informação de todos os links cada roteador cria a sua visão da topologia da rede (roteadores na mesma área, apesar de fazerem o cálculo de forma independente, tem a mesma visão da rede).
Para divulgar o estado de seus links os roteadores usam LSAs – Link State Advertisement. E aqui a coisa começa a complicar, pois existem vários tipos de LSAs.
Chamado Router LSA, o tipo 1 é gerado por todos os roteadores e é enviado para todos os roteadores na mesma área (não passa de uma área para outra). Neste LSA temos a lista de todos os links conectados no roteador.
Se um roteador tem interfaces em mais de uma área, ele gera LSAs tipo 1 para cada área (bem como mantém LSDB – Link State Data Base, para cada área).
Network LSA (tipo 2) é gerado apenas pelo DR – Designed Router. Ou seja, só existe em redes do tipo multi-access (broadcast ou não broadcast), onde temos a figura do DR. Lembre-se que o DR é um nó virtual (como o pseudonode no ISIS), e logicamente todos os roteadores estão conectados nele. No Network LSA temos todos os roteadores que estão conectados ao DR (conectados à rede multi-access), o próprio DR e prefixos e máscaras de rede. O LSA tipo 2 não passa de uma área para outra.
Note que até o momento, considerando os LSAs 1 e 2, as redes que estão em áreas diferentes não se falariam.
E é ai que entra o LSA tipo 3, o Summary LSA. Este LSA é gerado pelos ABRs – Area Border Router (R2 e R5 no nosso exemplo), representando os LSAs tipo 1 e 2, e é injetado na área vizinha.
Quando olhamos a tabela de roteamento e vemos rotas com a indicação “O IA” (OSPF Inter Área), estas são as rotas de outras áreas aprendidas através dos LSAs tipo 3.
Apesar do nome, o LSA tipo 3 não sumariza nenhuma rede quando estas são anunciadas entre áreas (há como fazer a sumarização de redes, justamente no ABR, mas este é outro assunto).
O nome Summary LSA tem a ver com o fato do ABR esconder os detalhes da rota quando ela é anunciada para outra área. Por exemplo, o R2 executa o cálculo SPF para saber o custo para chegar à interface loopback do R1 (que também está na área 10). Então o R2 anuncia na área 0 “meu custo para loopback do R1 é X, quem quiser chegar à esta rede, fale comigo”. Os roteadores da área 0, sem conhecer a topologia da área 10, executam o SPF para achar o custo para chegar ao R2, e então somam este custo à X.
Interessante notar que neste caso (roteamento entre áreas) o OSPF age como um protocolo Distance Vector.
Além das rotas inter e entre áreas, podemos ter rotas externas. Na nossa topologia temos R6 redistribuindo EIGRP no OSPF, o que torna R6 um ASBR – Autonomous System Boundary Router. E neste caso passamos a ter os LSAs 4 e 5.
O R6 muda seu LSA tipo 1, de maneira que o R5 passa a identificá-lo como um ASBR. Por conta disso o R5 (ABR) passa a gerar o LSA tipo 4, Summary ASBR LSA, divulgando para a área 0 (e desta para as demais áreas), como chegar ao ASBR.
Além disso, o próprio R6 (ASBR) passa a enviar LSAs tipo 5, Autonomous system external LSA, informando que ele conhece redes/rotas “externas”.
Notamos redes externas na tabela de roteamento através dos indicadores “O E1” e “O E2” (rotas OSPF externas, tipo 1 e tipo 2).
Custo para rotas E1 e E2: Por padrão, quando fazemos redistribuição, as rotas são inseridas no domínio OSPF como rotas tipo E2. Rotas deste tipo tem custo fixo, anunciado pelo ASBR. Já o custo para rotas E1 é calculado com a soma do custo anunciado pelo ASBR mais a custo para chegar ao ASBR. Se o ASBR estiver em outra área, o custo para uma rota tipo E1 é a soma do custo para chegar ao ABR + custo para chegar ao ASBR + custo anunciado pelo ASBR.
O LSA tipo 6, Multicast OSPF LSA, como o nome sugere, é utilizado pelo MOSPF – Multicast OSPF, extensão do OSPF pouco utilizada e não é suportada por roteadores Cisco.
E então chegamos no LSA tipo 7, Not-so-stubby area LSA. Mas antes de falar dele precisamos falar dos tipos de áreas que temos no OSPF.
Tipos de Área no OSPF
Note que até agora o exemplo considerava o uso de áreas “normais” (aquelas que permitem LSAs 3, 4 e 5 fluírem entre elas), onde todos os roteadores tem visibilidade de todos os links/rotas do domínio OSPF.
Porém este tipo de cenário impacta diretamente no processamento e tempo de convergência (LSDB fica maior, mudanças em uma área podem requerer o recálculo SPF em outras áreas,…), e por isso temos outras opções de áreas, que podem ser interessantes e muito recomendadas em alguns casos.
Área Stubby: Configurada com o comando area “x” stub, este tipo de área não permite a entrada de LSAs tipo 4 e 5. Ou seja, um roteador em uma área Stubby não conhece redes fora do domínio OSPF (injetadas pelo ASBR). Para continuar com acesso à estas redes o ABR passa a injetar uma rota default na área Stubby ao invés de divulgar os LSAs 4 e 5.
Área Totally Stubby: Além de não aceitar LSAs tipo 4 e 5, áreas Totally Stubby também não aceitam LSAs tipo 3. Configurada com o comando area “x” stub no-summary. O ABR divulga rota default para este tipo de área.
Área NSSA: Temos a opção também de área No So Stubby Area (configurada com o comando area “x” nssa), que é semelhante a área Stubby (filtra LSAs 4 e 5), mas permite a existência de ASBR na área, e a criação de LSA tipo 7 (falaremos abaixo). Nesta caso o ABR não injeta rota default.
Área Totally NSSA: Por fim temos o tipo Totally NSSA (ou Not So Totally Stubby Area), que como vocês já devem ter deduzido, é parecida com a área Totally Stubby (não permite a entrada de LSAs tipo 3, 4 e 5), mas permite a criação de LSA tipo 7, como na área NSSA. Configurada com o comando area “x” nssa no-summary, este tipo de área recebe rota default do ABR por padrão.
Importante ressaltar que os roteadores na mesma área precisam estar configurados com o mesmo tipo de área (normal, stubby ou nssa, a variação com ou sem no-summary épermitida), caso contrário eles não formam adjacência.
Voltando aos LSAs
O Not-so-stubby area LSA (tipo 7) é criado quando temos ASBR em áreas NSSA ou Totally NSSA. Isto porque estas áreas não permitem LSA tipo 5, então o ASBR passa a gerar o LSA tipo 7, que é convertido em tipo 5 pelo ABR e então encaminhado para a área 0, e de lá para as demais áreas normais.
Neste último exemplo a redistribuição é feita em uma área NSSA, e neste caso as rotas geradas são identificadas como “O N1” e “O N2” na tabela de roteamento. O cálculo do custo para rotas N1 é igual para rotas E1, enquanto temos rotas N2 análogas às rotas E2.
Temos (teoricamente) também o LSA tipo 8, External-Attributes-LSA, que foi concebido para ser utilizado sistemas autónomos de trânsito onde OSPF poderia substituir o iBGP. Nessas redes, os destinos BGP seriam transportados em LSA Tipo 5, enquanto seus atributos BGP seriam inseridos no LSA Tipo 8. A maioria das implementações OSPF nunca suportou esse recurso, e ele nunca foi padronizado.
Por fim temos os LSAs 9 (link-local “opaque” LSA), 10 (area-local “opaque” LSA) e 11 (AS “opaque” LSA). Estes LSAs foram criados para expansão futura e para servir a fins específicos de outras aplicações (exemplo: OSPF-TE, utilizado pelo RSVP-TE em redes MPLS, que utiliza o LSA tipo 10), e são bem incomuns.
Na prática (e para as provas Cisco da carreira Routing & Switching) os LSAs 1,2,3,4,5 e 7 é que são importantes e precisam ser bem entendidos.
OSPFv3
No OSPFv3, utilizado em redes IPv6, temos os mesmos tipos de LSA descritos aqui, mas alguns deles mudam de nome. E ainda LSAs tipo 8 (Link LSA) e LSA tipo 9 (Intra-Area-Prefix LSA) funcionais.
O Link LSA anuncia o endereço link local (endereço e prefixo do roteador) para todos os outros roteadores no link. Enviado somente se houver mais de um roteador no segmento.
Já o tipo 9 associa um lista de prefixos IPv6 à uma rede de trânsito, apontando para um Network LSA (tipo 2), e associa uma lista de prefixo IPv6 com um roteador, apontando um Router LSA (Tipo 1).
Fonte: http://brainwork.com.br/2017/02/23/tipos-de-lsas-e-reas-ospf/,
ANDRÉ ORTEGA/ QUINTA-FEIRA, 23 FEVEREIRO 2017/ PUBLISHED IN CISCO, IOS, ROUTERS