Antes de começarmos, nesse artigo uso de forma aleatória os termos LSA types e tipos de LSA, mas estou sempre me referindo a mesma coisa.
OSPF é um protocolo de roteamento não proprietário definido na RFC 2328, quando um protocolo é não proprietário e definido em RFC, qualquer fabricante pode implementar esse protocolo em seus equipamentos (de acordo com as regras e padrões definidos na RFC).
Devido interoperabilidade e por ser um protocolo aberto, é comum rodarmos OSPF em redes com fabricantes mistos, mas conheço muito analista (eu inclusive 😐) que por trabalhar em uma rede majoritariamente Cisco, prefere rodar EIGRP ou simplesmente acha OSPF muito complexo e o evita, Tipos de LSA e redes OSPF são dois dos tópicos que mais geram dúvidas e são eles que iremos abordar nesse artigo.
Primeiramente precisamos entender o que é um LSA...Um Link State Acknowledgment (LSA) é nada mais que um pedaço de informação sobre a topologia e é com essas informações que o roteador monta a base de dados OSPF em que é rodado o algoritmo Dijkstra para cálculo de melhor caminho, em outro artigo falaremos um pouco mais como tudo isso acontece.
Vamos considerar a topologia abaixo:
R1 e R2 fazem parte da Area 0 (backbone area) e R2 e R3 fazer parte da Area 1, nessa topologia R2 faz o papel de Area Border Router (ABR).
O primeiro LSA que iremos abordar é LSA Type 1 (Router LSA), esse LSA é gerado por todos os roteadores em uma área e dentro de cada LSA há informações de cada rede sendo anunciada pelo roteador. Esse tipo de LSA só existe dentro de sua própria área, não sendo repassado de uma área para outra.
O exemplo abaixo é o LSA sendo aberto através do Wireshark:
- Tipo de LSA, nesse caso LSA Type 1 (Router LSA)
- Roteador que gerou o LSA, nesse caso R1
- Redes sendo anunciadas na area 0
Voltando a topologia, podemos visualizar então os LSA Type 1, eles são trocados entre os roteadores dentro de sua própria área.
Avançando, temos os LSAs Type 2 (Network LSA). LSAs de tipo 2 são gerados apenas pelo Designated Router da topologia, dentro do LSA é enviado informações de todos os roteadores que existem dentro de uma área.
Esse LSA é gerado pelo DR e enviado a todos os roteadores da topologia, abaixo temos um exemplo dele:
- Tipo do LSA
- Roteador que está anunciando o LSA (sempre pelo DR)
- Roteadores na topologia
Nossa topologia então até o momento está da seguinte forma:
- LSAs tipo 1 sendo trocados entre os roteadores na área
- LSAs tipo 2 sendo gerados e enviados pelo DR de cada área, para cada roteador dentro dela
Sabemos que é necessário a troca de informações/rotas entre as áreas, em caso negativo, redes na área 0 não conseguiriam alcançar redes na área 1 (o mesmo se aplica inversamente) e sabendo que as informações de prefixo são trocadas em LSAs (tipo 1) que ficam apenas dentro da sua própria área, temos um problema, como enviar rotas entre as áreas? Para isso é utilizado LSAs type 3 (summary LSA).
LSAs type 3 são gerados por ABRs, as informações recebidas de uma área através de LSAs tipo 1 são encaminhadas para outra área através de LSAs tipo 3.
Abaixo temos um exemplo de LSA tipo 3, as informações principais que podemos mencionar são:
- Tipo do LSA
- Prefixo anunciado, no caso 192.168.61.0 (loopback 0 do R3)
- Roteador que está anunciando essa rota, no caso é o ABR (R2)
- Máscara do prefixo anunciado
- Métrica/custo
Voltando a nossa topologia, estamos da seguinte forma:
Temos mais 3 tipos de SLA a serem abordados (LSA type 4, type 5 e type 7), mas antes de falarmos sobre eles, precisamos falar sobre tipos de áreas.
Vamos olhar a topologia abaixo. Todos os recursos corporativos e serviços estão hospedados dentro da área 0, para a área 1 conseguir acessar esses recursos precisará atravessar a área 0, então não seria mais prático R3 encaminhar todo seu tráfego diretamente para R2 que o encaminharia em seguida a seu destino, ao invés de precisar injetar cada novo prefixo na área 1?
É para esse tipo de topologia/situação que utilizamos redes/áreas STUB, nesse tipo de área é injetada uma rota default no roteador e ele utiliza esse rota para encaminhar tráfego para tudo que ele não possui uma rota mais específica. STUB em inglês quer dizer ‘toco’ (tradução livre) e visualizando a imagem abaixo podemos entender o porque esse tipo de área possui esse nome, não há outro lugar por onde R3 posso encaminhar tráfego a não ser via R2. Não há ‘galhos’ em R3 que permitem ele ir para qualquer outro lugar.
Em nossa topologia a área 1 foi alterada para área do tipo STUB (em outro artigo falaremos como configurar, mas nesse momento vamos focar na teoria), olhando a tabela de roteamento de R3 temos:
- A rota default injetada pelo R2, conforme esperado de uma rede Stub
- Rota para 192.168.50.0/30
- Rota para 192.168.60.0/24
Se já recebemos uma rota default, porque então ainda recebemos outras rotas especificas? Redes STUB recebem a rota default, mas ainda permitem a entrada de LSAs de tipo 3, por isso ainda temos esses prefixos específicos sendo recebidos.
Mas e se não quisermos receber esses prefixos e apenas a rota default? Nesse caso, a área que é necessário é Totally Stub, que não permite a entrada de LSAs tipo 3, logo, prefixos específicos não são injetados na área.
O exemplo abaixo mostra isso, a área 1 foi alterada para Totally stub e agora apenas uma rota default é injetada nela.
A utilização de uma rede stub ou totally stub vai depender da topologia, se por exemplo existissem outros roteadores na área 1 que levassem a outros prefixos, uma área totally stub talvez não fosse a melhor opção, pois apenas o roteador utilizaria a rota default do roteador mais próximo.
No próximo exemplo a área 1 foi revertida para normal area.
Vamos considerar que R1 que está na área 0, possui redistribuição de outro protocolo de roteamento, no exemplo abaixo R1 está fazendo redistribuição de EIGRP para OSPF.
Podemos ver dois novos SLAs na topologia, sendo eles LSAs tipo 4 (Summary ASBR LSA) e LSA tipo 5 (AS External LSA).
O LSA type 5 possui informações dos prefixos sendo redistribuídos dentro do OSPF, é dentro desse LSA que estão as rotas injetadas na área. O R2 pega essas informações e a redistribui para a área 1 (importante citar que ele só faz isso porque a área 1 foi revertida para normal area, áreas Stub de qualquer tipo não aceitam LSAs tipo 5), mas uma informação adicional precisa ser enviada para a área 1, é a informação de quem é o ASBR (Autonomous System Boundary Router), no caso o R1, é dentro do LSA 4 que está essa informação. Vamos olhar numa captura exatamente o que é enviado dentro do LSA 4 e 5.
Abaixo temos um exemplo de LSA 4, nele podemos ver:
- Tipo do LSA
- IP do ASBR (R1)
- IP do roteador da área local que deve ser usado para alcançar o ASBR
Abaixo temos um exemplo de LSA 5, nele podemos ver:
- Tipo do LSA
- Rede sendo recebida
- IP do roteador que está anunciando a rota, no caso o ASBR (informações dele no LSA 4)
- Máscara do prefixo recebido
Temos um último LSA a ser abordado, o LSA type 7 (NSSA LSA).
Vamos voltar a situação em que a área 1 está configurada com Stub, o R3 está recebendo uma rota default de R2, portando mesmo que LSAs tipo 5 não sejam aceitas em redes stub, o R3 ainda consegue alcançar os prefixos devido a rota default, mas e se for necessário estabelecer uma sessão com outro protocolo de roteamento na área 1 e redistribuir essas rotas para área 0? Nesse caso a área precisa ser configurada para NOT-SO-STUBBY AREA (NSSA). Podemos olhar isso na topologia abaixo.
Da mesma forma que nosso último exemplo, podemos ver que temos um novo (e último SLA que iremos abordar) LSA, o LSA de tipo 7. Lembra que áreas Stub não permitem LSAs tipo 5? Para dar uma volta sobre essa limitação o R3 encaminha os dados (equivalentes a LSAs 4 e 5) num LSA de tipo 7, quando esse LSA alcança o R2 ele converte esse LSA para LSAs de tipo 4 e 5 e o injeta na área 0.
Áreas NSSA aceitam LSA de tipo 3, então da mesma forma que áreas Stub, rotas especificas são injetadas na área 1 em conjunto com uma rota default. Para injetarmos apenas a rota default, a área precisa ser configurada como Totally NSSA.
Podemos entender então que a diferença principal entre as áreas Stub/Totally Stub e NSSA/Totally NSSA é que nas áreas NSSA existe redistribuição de rota de outro AS/protocolo.
Informações sobre LSAs podem ser visualizadas no roteador com o comando ‘show ip ospf database’.
No exemplo abaixo temos a saída do comando em R2, podemos ver LSAs de tipo 1, 2, 3 e 7 para a área 1.
Vamos então para o resumo:
LSA Type 1 (Router LSA): Gerado por cada roteador na área, possui informações sobre os prefixos que está anunciando
LSA Type 2 (Network LSA): Gerado pelo DR, possui informações sobre todos os roteadores e prefixos da área
LSA Type 3 (Summary LSA): LSA enviado de uma área para outra
LSA Type 4 (Summary ASBR LSA): Enviado com informações de como alcançar um ASBR
LSA Type 5 (AS External LSA): Prefixos gerados por redistribuição via ASBR
LSA Type 7 (NSSA LSA): Gerado por um ASBR dentro de uma área NSSA
Area Stub: Recebe uma rota default, mas ainda aprende rotas especificas
Area Totally Stub: Recebe apenas uma rota default
Area NSSA: Recebe uma rota default e rotas especificas, porém se conecta a um AS externo e redistribui essas rotas localmente.
Area Totally NSSA: Recebe apenas uma rota default, possui conexão com um AS externo e redistribui essas rotas localmente.
Bom...era isso que queria compartilhar nesse artigo. OSPF é um protocolo bem complexo, cheio de detalhes e é importante possuirmos uma visão clara de cada aspecto dele para podermos utilizá-lo com segurança. Alguns outros LSAs existem, mas não foram abordados, pois não são comuns.
Em outro artigo espero podermos verificarmos como esses SLAs são tratados pelos roteadores e falarmos um pouco mais sobre OSPF e seu funcionamento.