Módulo 3: Protocolos de Roteamento IGP

RIP

O Routing Information Protocol foi um dos primeiros protocolos IGP e foi muito popularizado pela implementação da ferramenta routed, muito usada em sistemas UNIX 4BSD. Basicamente, este protocolo trata da implementação direta do algoritmo de vetor distância.

A métrica utilizada para o cálculo do melhor caminho baseia-se no número de roteadores que um pacote iria percorrer até chegar a seu destino, definido pelo termo HOP. A cada unidade pré definida de tempo, cada roteador RIP envia atualizações contendo todos os prefixos de sua tabela de rotas aos demais roteadores. Esse tempo por default é 30 segundos. Cada mensagem de atualização (update) possui as seguintes informações:

• Endereço de destino da rede/host
• Endereço IP do gateway que está enviando a mensagem
• A métrica atual, que por ser única, indica o número de HOPs para a rede/host destino

Na recepção de atualizações, os roteadores RIP analisam e comparam a informação recebida com a informações que está na tabela de rotas e caso esta tenha novos prefixos ou métricas menores para prefixos já existentes, a tabela de rotas será modificada.

No caso de um prefixo não ser divulgado durante 180 segundos, o roteador enviará uma mensagem a seus vizinhos declarando que a rota não está mais disponível, marcando-a como indisponível. Aos 270 segundos, a rota é removida da tabela.

Alguns mecanismos são implementados no protocolo RIP, afim de sanar determinados problemas no roteamento. Tais mecanismos serão apresentados abaixo:

• Hop count limit: O valor máximo de TTL (Time to live) no protocolo RIP é inicialmente setado em 16. Esse valor é decrementado a cada roteador que o pacote passar e ao chegar em 0, o pacote é descartado. Isso de um lado limita o tamanho da rede, mas evita que em problemas de loops, um pacote permaneça na rede infinitamente.
• Split Horizon: Recurso que evita que um roteador RIP propague rotas para a mesma interface que ele aprendeu, evitando laços de 2 nodos. Uma ligeira modificação neste procedimento é chamada de Poison Reverse Update, fazendo com que a propagação de rotas seja também feita, inclusive, na interface onde foi recebida, mas com métrica 16. Dessa forma, a rota será ignorada. Isso fará que com a atualização seja feita mais rapidamente.
• Triggered Updates e Hold down timer: Em redes maiores, baseado no sistema de atualizações utilizado pelo RIP, nota-se que o tempo de convergência torna-se um problema. Sendo assim, o recurso de Triggered Updates faz com que no caso de uma rota se tornar indisponível, o roteador não aguardar pela próxima atualização (geralmente a cada 30 segundos) para comunicar a seus viznhos, mas envia-la imediatamente. No entanto, depois de uma rota ser removida, o recurso de Hold down timer faz com que não sejam aceitos anúncios desta rota por determinado tempo, evitando que algum vizinho mais lento divulgue informações inconsistentes.

Existem, no entanto, algumas limitações deste protocolo. Algumas delas são apresentados abaixo:

• O número máximo de HOPs em 15 compromete seu uso em redes maiores;
• Em sua versão 1, o RIP não carrega informações de máscara de rede, ou seja, somente propaga rotas de redes classfull (classes A, B ou C).
• A unica métrica utilizada é o número de HOPs, fazendo com que nem sempre o melhor caminho seja contemplado. Um exemplo mais claro é mostrado pela Figura 1, onde de A para C existem dois caminhos. Um deles é pelo roteador B, tendo custo em 2 HOPs e o outro seria diretamente com custo 1. Mesmo que os links pelo roteador B sejam muito superiores em capacidade, ou ainda, mesmo que o link de 64 Kbps esteja totalmente utilizado, o melhor caminho sempre será pelo link de 64 Kbps já que a única métrica é o número de HOPs.

Figura 1 - Decisão de melhor caminho segundo RIP

Por fim, vale lembrar que em 1993 surgiu a versão 2 do protocolo RIP, propondo algumas melhoras no protocolo como autenticação e inclusão de informações de máscara no anúncio de rotas (suporte a VLSM e CIDR).