Protocolo de encaminhamento dinâmico RIP (Continuação)

Neste protocolo de 30 em 30 segundos cada router envia para os seus vizinhos actualizações. Um router que não receba informação do outro router (vizinho) durante 90 segundos marca essa rede com inacessível. Ao fim de 3 minutos sem dar notícias” os routers vizinhos apagam a linha da tabela

de routing que continha essa rede. Entretanto, durante esses períodos de espera o que acontece se existirem alterações na topologia da rede? Muito provavelmente loops. Este é outro dos problemas do RIP, a sua incapacidade de detectar loops na rede. A lentidão com que converge aliada à falta de sincronismo dos nós propicia a formação de loops que podem ser um problema grave.

Vejamos o exemplo:

Imaginem que o router A comunica com o C através do B.

Entretanto o link entre B e C cai (ver figura seguinte). O router B altera o valor do número de saltos para C, na sua tabela, para infinito (valor quando o destino não se encontra acessível)

Até aqui tudo bem. No entanto, imaginem que A ainda não recebeu nenhuma actualização por parte de B relativamente ao router C e envia a sua tabela para B (devido à comunicação ser assíncrona). O router B compara o número de salte que A lhe deu para chegar a C com o valor que tem na sua tabela, que neste caso é infinito. Como esse número é menor ele actualiza a sua tabela para chegar a C (2+1) porque acha que A encontrou outro caminho para lá chegar (ver figura seguinte).

Supondo que nesse momento o router A tenta enviar um pacote de dados para C, envia-o através de B, pensando que ainda pode fazer o trajecto A-B-C. Chegado o pacote B, ele reenvia-o para A, já que o caminho para C continua em baixo.

Quando esta informação chega de novo a A ele continua a ter na sua tabela que o caminho para C é por B. Assim, pensando que o router B teve de alterar o caminho para C por algum motivo, actualiza a sua tabela com a nova distância que recebeu de B (3) adicionando uma unidade (salto a dar entre A e B).

A próxima actualização será por parte de A (temporizador de 30 segundos) que irá actualizar a tabela de B (4+1) novamente e assim sucessivamente criando-se um loop infinito.

Como é possível solucionar este problema?

Para “tentar resolver” o problema da contagem para o infinito, introduziu-se um limite de números de saltos máximos possíveis. Estipulou-se 16 saltos (infinito). Assim, o loop somente se prolonga até aos 16 saltos onde o nó será removido da tabela de encaminhamento. Contudo, outro problema emergiu devido a esse limite. Se, por um lado, limitou-se a distância entre routers a 15 saltos deixa de ser atingível. Diz-se nesses casos que a rede não teve capacidade para convergir.

Todavia, a solução dos 16 saltos não evita que o loop se mantenha, por vezes, bastante tempo (pode demorar alguns minutos) sendo possível perder-se informação de encaminhamento relativa a outras redes. A resposta a este problema residia então no período de latência entre actualização periódica criou-se outra técnica chamada Triggered Updates. A implementação desta técnica permitia que, imediatamente após a alteração de uma métrica num router, a informação seguisse para os routers vizinhos. No entanto, tem de ser usada com cuidado pois em alguns casos existe a possibilidade de se criarem broadcast storms.

Broadcast storm

Quando uma mensagem enviada em broadcast gera mais resposta em broadcast e estas por sua ves ainda mais, levando a um efeito de bola de neve e consequente

Na tentativa de evitar as Broadcast Storm e os loops desenvolveu-se ainda outra técnica denominada de Split Horizom. O protocolo de RIP v.1 foi o primeiro a utilizá-lo. Este protocolo garante que os routers não anunciam as rotas através das interfaces por onde as aprenderam. Assim, no exemplo anterior, se A actualizasse B antes de B actualizar A não haveria problema pois este não mencionaria o custo para C a B já que aprendeu essa rota através do próprio. Na próxima actualização, B comunicaria a A que C estava inacessível. Assim, o router A teria de escolher outro caminho para chegar a C (caso existisse).

Está técnica é porém falível pois não evita loops quando eles são independentes e ocorrem em mais de duas máquinas em simultâneo.

Na versão 2 do protocolo RIP, usa-se outra técnica denominada de Split Horizon With Poisen Reverse que em vez de omitir as rotas.

Na versão 2 do protocolo RIP, usa-se outra técnica denominada de Split Horizon With Poisen Reverse que em vez de omitir as rotas aprendidas através de uma certa interface, inclui essa rota nas trocas de informação, mas colocando o seu valor em 16 (infinito). Desta forma, muito dificilmente há probabilidade de ocorrer um loop na rede.

RIP 1.0

•Envio de mensagens por broadcast; qInterrompem todas as maquinas (mesmo que não tenha RIP);

•Não existe autenticação das mensagens;

•Suporte muito imcompleto a máscaras de rede. RIP 2.0 •Envio em multicast 224.0.0.0; •Autenticação das mensagens (maior segurança); •Campo para indicar máscaras de rede com suporte para mascaras estáticas e variáveis (sub-redes).

mente ao bloqueio as comunicações numa rede.