TUTORIAL OSPF

Introdução

O protocolo OSPF (Open Shortest Path First), definido pela RFC 2328, é um protocolo IGP (Interior Gateway Protocol), ou seja, desenhado para uso intra-As (Sistema Autônomo). O protocolo OSPF foi desenvolvido para atender às necessidades colocadas pelas comunidades da Internet, que demandavam um protocolo IGP eficiente, não-proprietário e inter-operável com outros protocolos de roteamento.

OSPF baseia-se na tecnologia “link-state”, que é bastante diferente e bem mais avançada que a tecnologia utilizada em protocolos puramente vetoriais, como o RIP, que utiliza o algoritmo Bellman-Ford para cálculo da melhor rota.

OSPF x RIP

Como já sabemos, o protocolo RIP possui certas características que o tornam bastante limitado para aplicação em redes mais complexas, como:

Limite de 15 saltos (roteadores) até a rede destino

RIP não oferece suporte a VLSM

RIP não suporta autenticação

RIP adota o procedimento de enviar broadcasts periódicos contendo a totalidade da tabela de roteamento para a rede. Em redes de grande porte, especialmente em redes com links WAN mais limitados, isso pode gerar um consumo excessivo de largura de banda e causar problemas mais sérios

O processo de convergência de uma rede rodando RIP é mais lento e ineficiente do que redes rodando OSPF

RIP não leva em consideração dados como custo dos links ou atrasos na rede, baseando-se exclusivamente na contagem de saltos para definição da melhor rota.

Redes baseadas no protocolo RIP são redes planas. Não existe o conceito de fronteiras, ou áreas. A introdução de redes classless e de conceitos como agregation e sumarização tornam redes RIP bastante ultrapassadas, já que não são compatíveis com tais conceitos.

Algumas limitações, como o não-suporte a VLSM, autenticação e anúncios multicast, foram amenizadas com a introdução da versão 2 do protocolo RIP (RIPv2). Entretanto, o restante das limitações permaneceram inalteradas.

OSPF

O protocolo OSPF, por sua vez, resolve todas as limitações apresentadas anteriormente:

Não existe limite de saltos com OSPF

OSPF suporta VLSM

OSPF utiliza anúncios multicast, e as atualizações apenas são disparadas quando existe alguma alteração na rede (anúncios incrementais)

Redes OSPF convergem mais eficientemente do que redes RIP

OSPF permite um meio mais eficaz de balanceamento de carga

OSPF permite a implementação de hierarquia às redes, por meio das áreas. Isso facilita o planejamento da rede, assim como tarefas de agregação e sumarização de rotas.

OSPF permite a transferência e marcações de rotas externas, injetadas em um ASN (Sistema Autônomo). Isso permite que se rastreie rotas injetadas por protocolos EGP, como o BGP.

É claro que isso tudo tem um preço. OSPF é mais complexo de ser planejado, configurado e suportado, se comparado com RIP. Além disso, os processos OSPF consomem mais CPU que processos RIP, uma vez que o algoritmo e a estrutura utilizados pelo OSPF são muito mais complexos.

Afinal, o que significa “Link State”?

OSPF é um protocolo classificado como “Link-State”. Isso significa que o protocolo utiliza um algoritmo link-state para tomada de decisões sobre qual o melhor caminho a ser tomado. A operação do algoritmo utilizado pelo OSPF - chamado de algoritmo de Dijkstra - já foi explicado no Fórum do blog pelo ilustre Petry, mas abaixo eu passo um resumo:

Assim que o processo OSPF é inicializado - ou assim que ocorra alguma alteração na informação de roteamento de uma rede OSPF - o roteador gera um anúncio link-state (LSA - Link State Advertisement). Este anúncio é composto pelo status de todos os links neste roteador.

Todos os roteadores trocam mensagens link-state entre si via multicast. Cada roteador que recebe um update deve armazenar uma cópia em sua base de dados e, então, propaga-lo para os roteadores vizinhos.

Uma vez que a base de dados de cada roteador encontre-se atualizada, o roteador calcula a topologia lógica da rede (Shortest Path Tree) para cada um dos destinos. O algoritmo Dijkstra é utilizado no cálculo. Os destinos e respectivos custos e next-hops, finalmente, formarão a tabela de roteamento.

Caso nenhuma alteração na rede OSPF ocorra, o protocolo OSPF praticamente não tem ação. Em caso de alterações, updates são gerados e o algoritmo Dijkstra recalcula o melhor caminho para cada destino.

OSPF consome mais CPU que protocolos mais simples, como o RIP, exatamente pelos cálculos que ele realiza.

O Algoritmo SPF

Como vimos, em uma rede OSPF, o melhor caminho (o mais “curto”) é calculado aplicando-se o algoritmo Dijkstra. O modo como o algoritmo opera é colocando o roteador na raiz da topologia, e então calcula o melhor caminho para um destino baseando-se no custo cumulativo até o destino em questão. Cada roteador na rede terá uma visão única da topologia lógica, ainda que todos os roteadores utilizem a mesma base de dados link-state (link-state database). Algumas terminologias pertinentes:

Custo

O custo (também conhecido como métrica) de uma interface OSPF é uma indicação do overhead necessário para o envio de pacotes através desta interface. O custo de uma interface é inversamente proporcional a largura de banda desta interface. Uma largura de banda maior indica um custo menor. Custo = 1.000.000.000/Banda (bps). Por este motivo, é importante a correta configuração do parâmetro Bandwidth em interfaces rodando OSPF.

Árvore (ou topologia) de caminho mais curto (SP Tree)



Observe a topologia física ilustrada na figura abaixo (1a figura). A topologia SP é apresentada na figura imediatamente inferior. Observe a diferença entre a topologia física e a topologia lógica gerada pelo algoritmo, considerando-se os custos associados a cada interface. O roteador RTA é o ponto focal da topologia, como foi dito anteriormente. No exemplo ilustrado, o custo do roteador RTA para a rede 222.211.10.0 pode ser 20 (10+5+5), se considerarmos o caminho via roteador RTB e RTD, mas será 20 também (10+10), se considerarmos o caminho via RTC. Em caso de caminhos com igual custo, OSPF balanceia a carga (para até 6 caminhos, na implementação do OSPF segundo a Cisco).


Roteadores de fronteira (Area ou Borda)

Como vimos, OSPF utiliza multicast para propagar os anúncios pela rede. O conceito de areas foi criado para criar fronteiras de propagação destes anúncios. A propagação de updates e o cálculo da topologia pelo algoritmo Dijkstra são restritos à área. Todos os roteadores em uma mesma área terão a mesma base de dados topológica. Roteadores que pertencem a mais de uma área terão as bases de dados de cada área a qual pertencem. Este é o caso dos roteadores de fronteira, como os ABRs (Area Border Routers) e os ASBRs (Autonomous System Border Routers). A figura abaixo ilustra a aplicação destes roteadores.



Pacotes Link-State

Existem diferentes tipos de pacotes Link-State. Estes pacotes são ilustrados no diagrama abaixo.



Configuração do OSPF em um router Cisco

A configuração do protocolo OSPF em routers Cisco é bastante direta, e realizada em apenas 2 passos:

Habilitar o processo OSPF no router via comando “router ospf {ID do processo OSPF}”
Associar areas OSPF às interfaces, via comando “network {rede ou endereço IP} {wildcard} {area}”
O ID do processo OSPF não precisa ser o mesmo em roteadores distintos, e o mais interessante, vários processos OSPF podem ser executados em um mesmo router. Este procedimento não é recomendado, entretanto, já que cada instância consome grandes porções de CPU e memória. Em suma, um bom design não utilizaria mais de um processo OSPF em um mesmo router.

O parâmetro “network”, diferentemente do que ocorre na configuração de outros protocolos de roteamento, serve, no OSPF, para indicar quais interfaces participarão do processo, e quais as áreas OSPF a que pertencem. Esta é uma particularidade do protocolo. Devemos nos lembrar que, em uma rede OSPF, a fronteira é o link, e este é definido pela interface. Até aproveitando este gancho para responder a uma pergunta postada no blog: “Por que os parâmetros de sumarização, em redes OSPF, devem ser configurados na interface?”. Resposta: Pelo motivo anteriormente mencionado: As áreas.

O ID da área é definido por um número inteiro compreendido entre 0 e 4294967295, e também pode assumir a forma de um endereço IP (ex: área 0 = 0.0.0.0).

Autenticação OSPF

OSPF permite a autenticação de pacotes de forma que routers podem participar de domínios de roteamento baseados em senhas pré-definidas. Por default, OSPF não utiliza esquemas de autenticação. Basicamente, existem 2 métodos de autenticação que podem ser utilizados:

1) Autenticação Simples - Este método permite que chaves sejam configuradas por área OSPF. Routers em uma mesma área que desejem participar do processo de roteamento devem ser configurados com a mesma chave. A desvantagem deste método é que as chaves são trocadas pela rede, e podem ser facilmente interceptadas.

Exemplo:

interface Ethernet0
ip address 10.10.10.10 255.255.255.0
ip ospf authentication-key minhasenha

router ospf 10
network 10.10.0.0 0.0.255.255 area 0
area 0 authentication

2) Autenticação Forte (MD-5) - Neste método, uma chave e uma senha são configurados em cada router. O router usa, então, um algoritmo baseado no próprio pacote OSPF, na chave e no ID da chave para gerar um “message digest”, que é inserido no pacote. Este método permite a troca de senha sem a interrupção da comunicação.

Exemplo de aplicação:

interface Ethernet0
ip address 10.10.10.10 255.255.255.0
ip ospf message-digest-key 10 md5 mypassword

router ospf 10
network 10.10.0.0 0.0.255.255 area 0
area 0 authentication message-digest

OSPF Multi-area

O protocolo OSPF possui algumas restrições quando mais de uma área é configurada. Se apenas uma área existe, esta área é SEMPRE a área 0, chamada de “backbone area”. Quando múltiplas áreas existem, uma destas áreas tem que ser a área 0. Uma das boas práticas ao se desenhar redes com o protocolo OSPF é começar pela área 0 e expandir a rede criando outras áreas (ou segmentando a área 0).

A área 0 deve ser o centro lógico da rede, ou seja, todas as outras áreas devem ter uma conexão física com o backbone (área 0). O motivo disso é que OSPF espera que todas as áreas encaminhem informações de roteamento para o backbone, e este, por sua vez, se encarrega de disseminar estas informações para as outras áreas. O diagrama abaixo ilustra o fluxo de informações em uma rede OSPF.



No diagrama acima, todas as áreas possuem uma conexão direta com o backbone. Em situações raras, nas quais não é possível estabelecer uma conexão direta com a área 0, um link virtual (virtual link) deve ser estabelecido. O link virtual OSPF é como uma “VPN” que integra uma área que não tem como se conectar diretamente ao backbone, através de uma área diretamente conectada a ele. É importante ressaltar que o artifício de “virtual links” é paliativo, ou seja, ele resolve um erro de design, e deve ser encarado como uma solução temporária.

Seguindo o diagrama, observem os diferentes tipos de informações que são trafegadas. Informações sobre rotas que são geradas e utilizadas dentro de uma mesma área são chamadas de “intra-area routes”, e são precedidas pela letra “O” na tabela de roteamento. Rotas que são originadas em outras áreas são chamadas de “inter-area routes”, ou “summary-routes”. Estas são precedidas por “O IA”, na tabela de roteamento. Rotas originadas por outros protocolos de roteamento e redistribuídas em uma rede OSPF são conhecidas por “external-routes”. Estas são precedidas pelas letras “O E1″ ou “O E2″, na tabela de roteamento. Quando temos múltiplas rotas para um mesmo destino, o critério de desempate em uma rede OSPF obedece a seguinte ordem: intra-area, inter-area, external E1, external E2. Falarei das 2 últimas (E1 e E2) mais adiante.

Virtual Links

Como já foi mencionado, links virtuais são artifícios utilizados para conectar áreas discontíguas ao backbone. A figura abaixo ilustra um exemplo.



No exemplo acima, a área 1 não tem conexão direta com o backbone (area 0). Um link virtual foi então estabelecido para criar uma conexão virtua entre as áreas 1 e 0, através da área 2. A configuração de um link virtual é relativamente simples, e é ilustrada abaixo:

RTA(config)#router ospf 10
RTA(config-router)#area 2 virtual-link 2.2.2.2

RTB(config)#router ospf 10
RTB(config-router)#area 2 virtual-link 1.1.1.1

Considere que 2.2.2.2 e 1.1.1.1 sejam os endereços IP de interfaces loopback configuradas nos routers RTA e RTB, respectivamente. Lembrando que, em uma rede OSPF, endereços IP em loopbacks são preferidos para a definição do RID (router ID).

Um outro uso para links virtuais em uma rede OSPF é conectar 2 backbones discontíguos, como ilustra a figura abaixo.



A situação acima pode ocorrer, por exemplo, no processo de integração de redes entre 2 empresas que acabaram se fundindo, por exemplo. No exemplo, duas áreas 0 (backbones) são interligados por meio de um link virtual.

Basicamente, routers que compartilham um mesmo segmento tornam-se neighbors neste segmento. O estabelecimento de uma relação de vizinhança ocorre por meio da mensagem “Hello”. Routers tornam-se vizinhos assim que conseguem ver eles mesmos listados como vizinho no pacote Hello do router vizinho. Desta forma, uma comunicação de 2 vias é garantida. É importante ressaltar que a negociação de vizinhança utiliza apenas o endereço IP primário da interface. Ou seja, se a mesma estiver configurada com endereços secundários, estes não serão utilizados no processo. Outro porém é que, se endereços secundários forem configurados, estes devem pertencer à mesma área OSPF do endereço primário.


Dois routers não estabelecem uma relação de vizinhança até que os seguintes pontos sejam verificados:

Area-ID: Para 2 routers que possuem interfaces em um mesmo segmento, estas interfaces devem pertencer à mesma área OSPF, pertencer à mesma subrede e possuir a mesma máscara de rede.

Autenticação: Se autenticação estiver sendo utilizada, routers vizinhos devem trocar a mesma senha em um dado segmento.

Hello e “Dead Intervals”: Routers OSPF trocam mensagens Hello em cada segmento. O Keepalive HELLO configurado deve ser consistente em um mesmo segmento. O “Dead Interval” seria o intervalo de tempo entre o último pacote HELLO recebido e o router considerar o neighbor como “down”. Este intervalo também deve ser o mesmo em um mesmo segmento OSPF. Os comandos para configuração destes intervalos nas interfaces são: “ip ospf hello-interval seconds” e “ip ospf dead-interval seconds”

“Stub Area Flag”: Dois routers devem também possuir o mesmo valor no campo “Stub Area Flag”, no pacote Hello, para formarem uma relação de vizinhança. Basicamente, por hora, você deve ter em mente que a definição de áreas “STUB” afetam a relação de vizinhança entre os routers. Falaremos mais de áreas STUB mais adiante.

MTU Size: Finalmente, temos o MTU Size das interfaces. Se estes valores forem diferentes em cada ponta, a adjacência não será formada. Se por algum motivo existir a necessidade de estabelecer a adjacência mantendo-se MTUs distintas em cada ponta, o comando “ip ospf mtu-ignore” configurado em cada interface envolvida no processo resolve o problema.

Adjacências

O processo de formação de adjacências ocorre imediatamente após a definição das relações de vizinhança. Routers adjacentes são aqueles que foram além da simples troca de pacotes HELLO, e iniciaram o processo de sincronismo da base de dados. Objetivando reduzir a quantidade de informação trocada em um dado segmento, OSPF elege um router para ser o router designado (Designated Router - DR), e outro para assumir o papel de backup dele (Backup Designated Router - BDR), em cada segmento multi-acesso (como segmentos Ethernet, por exemplo). A idéia por trás deste princípio é criar um ponto central na rede multi-acesso para troca de informações. A figura abaixo ilustra o processo.



A eleição do router DR é feita pelo pacote HELLO. Pacotes HELLO são trocados entre os routers via multicast, em cada segmento. O router que tiver o maior OID (OSPF ID) em um segmento é eleito o DR para aquele segmento. O mesmo processo é realizado para a eleição do BDR. Em caso de empate, o router com maior RID (Router ID) vence a disputa. A prioridade default para uma interface OSPF é 1. Este valor pode ser alterado pelo comando: “ip ospf priority “. Uma prioridade “0″ significa que a interface em questão não será considerada no processo de eleição do DR / BDR.

O RID é definido pelo maior endereço IP configurado no router. Entretanto, se interfaces Loopbacks existirem, o RID é definido pelo maior IP configurado em uma interface Loopback. É interessante utilizar Loopbacks para definição do RID pois, com elas, é possível “garantir” que este endereço IP se manterá, e não será trocado em uma eventual alteração na rede.

Na figura abaixo, as interfaces de RTA e RTB possuem a mesma prioridade, mas RTB tem um RID maior e, por isso, será eleito o DR no segmento. RTC tem uma prioridade maior que RTB e, por isso, RTC será eleito o DR naquele segmento.



O processo de formação de adjacência consiste de 7 estágios:

1-Down
2-Init
3-Two-way
4-Exstart
5-Exchange
6-Loading
7-Full

O comando “show ip ospf interface ” é uma forma rápida de verificar se todas as interfaces encontram-se configuradas nas áreas em que deveriam.

Um ponto importante a ser lembrado é que a ordem em que os comandos são digitados no router é muito importante. Por exemplo, se o comando “network 203.250.0.0 0.0.255.255 area 0.0.0.0″ for digitado ANTES do comando “network 203.250.13.41 0.0.0.0 area 1″, todas as interfaces seriam colocadas na área 0 (0.0.0.0), o que é incorreto, já que desejamos que a loopback (203.250.13.41) seja colocada na área 1.

Exemplos de comandos SHOW:

RTB#show ip ospf interface e0
Ethernet0 is up, line protocol is up
Internet Address 203.250.14.3 255.255.255.0, Area 0.0.0.0
Process ID 10, Router ID 203.250.12.1, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State DROTHER, Priority 1
Designated Router (ID) 203.250.15.1, Interface address 203.250.14.2
Backup Designated router (ID) 203.250.13.41, Interface address
203.250.14.1
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 0:00:03
Neighbor Count is 3, Adjacent neighbor count is 2
Adjacent with neighbor 203.250.15.1 (Designated Router)
Adjacent with neighbor 203.250.13.41 (Backup Designated Router)

RTD#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
203.250.12.1 1 2WAY/DROTHER 0:00:37 203.250.14.3 Ethernet0
203.250.15.1 1 FULL/DR 0:00:36 203.250.14.2 Ethernet0
203.250.13.41 1 FULL/BDR 0:00:34 203.250.14.1 Ethernet0

Adjacências em links ponto-a-ponto

OSPF sempre formará adjacências em links ponto-a-ponto sem a necessidade de eleger um DR e BDR.

Adjacências em links Non-Broadcast Multi-Access (NBMA)

Um cuidado especial é necessário quando configuramos OSPF em redes NBMA, como Frame Relay, X.25 ou ATM. Por default, OSPF considera estes redes como Broadcast (assim como uma rede Ethernet). No entanto, redes NBMA geralmente são arquitetadas sob uma topologia “hub & spoke”, e não provê o tipo de acesso full mesh que OSPF acredita existir. Neste caso, a seleção do DR e BDR torna-se um problema, já que o DR e o BDR precisam ter uma conexão física entre eles. Além disso, devido à limitação de broadcast existente em redes deste tipo, o DR e o BDR precisam possuir uma lista estática de todos os roteadores pertencentes à rede frame relay.

Evitando a eleição de DR e BDR em redes NBMA

Existem algumas maneiras de evitar a eleição de DR e BDR em redes NBMA.

a) Adoção de subinterfaces point-to-point: A configuração de subinterfaces point-to-point faz com que OSPF as trate como qualquer interface física P-2-P. Lemabrando que OSPF sempre formará uma adjacência entre 2 interfaces P2P, não teríamos aqui a eleição do DR ou BDR.Ex:

RTA#
interface Serial 0
no ip address
encapsulation frame-relay
interface Serial0.1 point-to-point
ip address 128.213.63.6 255.255.252.0
frame-relay interface-dlci 20
interface Serial0.2 point-to-point
ip address 128.213.64.6 255.255.252.0
frame-relay interface-dlci 30
router ospf 10
network 128.213.0.0 0.0.255.255 area 1

b) Seleção do tipo de interface: O comando que permite a indicação do tipo de interface em uma rede OSPF é: ip ospf network {broadcast | non-broadcast | point-to-multipoint}

Ex:

RTA#
interface Loopback0
ip address 200.200.10.1 255.255.255.0
interface Serial0
ip address 128.213.10.1 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint
router ospf 10
network 128.213.0.0 0.0.255.255 area 1



Sumarização de rotas com OSPF

Sumarização de rotas consiste na consolidação de múltiplas rotas em um único anúncio. Em uma rede OSPF, esta tarefa normalmente é realizada por um router de borda (ABR). Ainda que sumarização possa ser configurada entre quaisquer 2 áreas, a boa prática rege que a sumarização deve ocorrer preferenciamente no sentido do backbone (Area 0). Desta forma, o backbone recebe todas as rotas agregadas e, por sua vez, pode anuncia-las - já sumarizadas - para outras áreas.


Em uma rede OSPF, existem basicamente 2 tipos de sumarização:

1-Inter-area route summarization
2-External route summarization

O primeiro caso (Inter-area route summarization) é realizado nos ABRs, e aplica-se a rotas internas ao AS. Neste caso, rotas externas, aprendidas via redistribuição, não são consideradas. O comando para criar este tipo de rota é “area [area-id] range [address] [mask]”.

Exemplo:



Na figura acima, RTB está sumarizando o intervalo de subredes de 128.213.64.0 até 128.213.95.0 em apenas um endereço: 128.213.64.0 255.255.224.0. Seguindo o mesmo princípio, RTC gera o endereço sumarizado 128.213.96.0 255.255.224.0, englobando o intervalo de 128.213.96.0 a 128.213.127.0.

O processo de sumarização seria comprometido se tivéssemos subredes sobrepostas entre as áreas 1 e 2. Para efeito de exemplificação, as configurações do router RTB são ilustradas:

RTB(config)#router ospf 100
RTB(config-router)#area 1 range 128.213.64.0 255.255.224.0

O segundo caso (External route summarization) é específico às rotas externas, injetadas na rede OSPF via redistribuição. Aqui também é importante nos certificarmos que os intervalos sendo sumarizados são contíguos. O comando para realizar a sumarização de rotas externas é “summary-address [ip-address] [mask]”.

Este comando apenas deve ser utilizado em ASBRs realizando redistribuição para OSPF.

Exemplo:



Na figura acima, RTA e RTD estão anunciando rotas externas na rede OSPF via redistribuição. RTA está injetando as subredes no intervalo 128.213.64-95, enquanto RTD faz o mesmo para subredes no intervalo 128.213.96-127. Abaixo, exemplos de configuração para ambos os routers:

RTA#
router ospf 100
summary-address 128.213.64.0 255.255.224.0
redistribute bgp 50 metric 1000 subnets

RTD#
router ospf 100
summary-address 128.213.96.0 255.255.224.0
redistribute bgp 20 metric 1000 subnets

É importante mencionar que o comando “summary-address” não teria efeito algum se aplicado ao router RTB, já que este não está realizando redistribuição para o OSPF.

Por: Marco Filippetti