Que tipo de rota permite que um roteador envia pacotes Mesmo que sua tabela de roteamento não contenha nenhuma rota para a rede de destino?

RIP

O RIP (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. Este protocolo � derivado de um protocolo da Xerox para redes locais. Basicamente, ele trata da implementa��o direta do algoritmo de vetor dist�ncia. A RFC do RIP, saiu em 1988 (RFC 1058).

Por ser baseado no algoritmo de vetor dist�ncia, este protocolo envia copias peri�dicas de sua tabela de roteamento para seus vizinhos diretamente conectados (utiliza o endere�o broadcast de cada rede diretamente conectada). Roteadores que est�o utilizando esse protocolo enviam atualiza��es peri�dicas mesmo que n�o ocorram altera��es na rede.
As mensagens peri�dicas do RIP s�o c�pias da tabela de roteamento completa de cada roteador. Quando um roteador recebe a tabela de roteamento completa de seu vizinho, ele verifica cada rota, acrescentando as que ele ainda n�o conhecia em sua tabela e comparando as j� existentes para escolher aquela com o menor n�mero de saltos para colocar em sua tabela ou atualizar entradas j� existentes.

Por�m existem situa��es onde ocorre a transmiss�o de informa��es erradas. A seguir vamos mostrar um caso destes, assim como as ferramentas utilizadas pelo RIP para tentar evitar tais inconsist�ncias.

Temos o ambiente abaixo.

Ocorre, por�m, uma falha e a rede 10.4.0.0 n�o est� mais dispon�vel. O roteador C, diretamente conectado a esta rede, detecta a falha e para de enviar pacotes para ela. Por�m, os roteadores A e B ainda n�o receberam o aviso de que a rede 10.4.0.0 caiu. O roteador A, ainda acredita que pode acessar esta rede atrav�s do roteador B (sua tabela de roteamento continua a marcar uma distancia de 2 saltos at� ela).

Quando o roteador B envia a copia peri�dica de sua tabela de roteamento para o roteador C, este acredita que agora ele consegue novamente alcan�ar a rede 10.4.0.0, por�m, agora, a partir do roteador B. O roteador C atualiza sua tabela de roteamento com a rota de destino a rede 10.4.0.0 via roteador B com n�mero de saltos igual a 2.

Agora, o roteador B recebe a atualiza��o vinda do roteador C. Como o roteador B j� possui em sua tabela uma entrada para a rede 10.4.0.0 aprendida a partir da sua interface serial 1, ao receber esta atualiza��o (tamb�m vinda via serial 1), ela ir� atualizar a dist�ncia para esta entrada. Logo, o roteador B ir� atualizar sua tabela com o novo custo, agora de 3, para alcan�ar esta rede. O mesmo ir� ocorrer com o roteador A, ao receber a tabela do roteador B. O roteador A tamb�m detecta uma altera��o na dist�ncia da rede 10.4.0.0 e atualiza sua tabela, colocando como 4 a dist�ncia at� esta rede.

Neste momento, temos todas as 3 tabelas de roteamento incorretas. Todas prometem alcan�ar a rede 10.4.0.0 por caminhos inexistentes. Estas atualiza��es erradas v�o se repetir e a contagem de saltos vai crescer cada vez mais. Este problema � conhecido como contagem para o infinito (count to infinity). Pacotes destinados a rede 10.4.0.0 nunca alcan�aram o destino mas v�o ficar trafegando continuamente na rede (loop de roteamento) desperdi�ando banda.

A seguir ser�o apresentadas algumas solu��es para minimizar os problemas apresentados pelo algoritmo de vetor dist�ncia.

Este problema apresentado como contagem para o infinito acontece, como vimos, sempre que as tabelas de roteamento continuam a aumentar a m�trica para um destino que n�o pode ser alcan�ado, ao inv�s de marcar este destino como inalcan��vel. Para que isto n�o ocorra, o protocolo define um n�mero m�ximo de saltos, este n�mero m�ximo, no caso do RIP, � 16. Agora, o protocolo de roteamento ir� permitir que, no caso de ocorr�ncia de loop de atualiza��o, este ir� ocorrer at� a m�trica alcan�ar este valor m�ximo permitido. Quando a m�trica exceder o valor m�ximo permitido a rede � considerada inalcan��vel, parando a prolifera��o de atualiza��es de roteamento que aumentem esta m�trica. Isso de um lado limita o tamanho da rede, mas evita que um pacote permane�a na rede infinitamente.

Temos ainda solu��es para eliminar estes loops de roteamento. Loops de roteamento ocorrem quando dois ou mais roteadores tem informa��es erradas de roteamento indicando um caminho v�lido para uma rede inalcan��vel passando pelo outro.

Exemplo:

Neste exemplo, um pacote destinado a rede 10.4.0.0 chega ao roteador A. Este olha na sua tabela de roteamento e manda o pacote pela sua interface serial 0. Ao chegar no roteador B, este manda o pacote pela sua interface serial 1, como indicado na sua tabela de roteamento. O roteador C recebe o pacote e checa sua tabela de roteamento, a qual especifica que o pacote deve ser enviado pela interface serial 0. O pacote ent�o, acaba voltando ao roteador B que novamente o envia para o roteador C. O pacote ficar� ent�o trafegando de B para C.

Existem algumas t�cnicas dispon�veis para eliminar loop de roteamento como: estreitamento de horizontes (split horizon), envenenamento de rotas (route poisoning), envenenamento reverso (poison reverse), tempo de espera ( holddown timers) e atualiza��es imediatas (triggered updates). A seguir tem-se uma explica��o de cada uma destas t�cnicas.


Estreitamento de horizontes (Split Horizon)

Uma maneira de se eliminar os loops de roteamento a aumentar a velocidade de converg�ncia � utilizando a t�cnica de estreitamento de horizontes. Esta t�cnica diz que n�o � �til mandar informa��es sobre uma rota de volta na mesma dire��o por onde a informa��o original chegou. Ou seja, evita que um roteador RIP propague rotas para a mesma interface que ele aprendeu, evitando loop entre estes n�s.


Envenenamento de rotas (Route Poisoning)

Esta t�cnica � uma ligeira modifica��o daquela utilizada no estreitamento de horizontes. Seu objetivo tamb�m � a preven��o de loops de roteamento causados por atualiza��es inconsistentes. Com essa t�cnica, o roteador seta a entrada da tabela que mant�m o estado da rede consistente, enquanto os demais roteadores gradativamente convergem corretamente ap�s a ocorr�ncia de uma mudan�a na topologia. Utilizado juntamente com o tempo de espera, uma outra t�cnica que ser� mostrada mais a frente, o envenenamento de rotas � uma solu��o para loops longos. Ou seja, no caso estudado, quando o enlace 10.4.0.0 fica indispon�vel, o roteador C (diretamente conectado a ele) envenena este enlace. Em sua tabela, ele coloca esta rede como inalcan��vel ou de m�trica infinita (n�mero de saltos igual a 16). Tendo envenenado a rota para este enlace, o roteador C n�o fica sujeito a atualiza��es incorretas a respeito deste enlace, vindas de roteadores vizinhos que acreditam ter rotas alternativas para ele.


Envenenamento Reverso (Poison Reverse)

Estreitamento de horizontes com envenenamento reverso faz com que a rede consiga convergir em menos tempo. Quando o roteador B recebe uma atualiza��o mostrando que a m�trica para se atingir a rede 10.4.0.0 foi alterada para infinito, ele manda uma atualiza��o, chamada de envenenamento reverso, de volta para o roteador C avisando que a rede est� inalcan��vel. E ainda coloca este enlace como possivelmente inalcan��vel em sua tabela de roteamento. Essa � uma situa��o espec�fica que se sobrep�e ao estreitamento de horizontes. Isso ocorre para ter certeza que o roteador C n�o ficar� sujeito a atualiza��es erradas a respeito desta rede.


Tempo de Espera (Holddown Timers)

O tempo de espera � utilizado para evitar que atualiza��es inapropriadas ensinem caminhos inexistentes para enlaces que n�o est�o dispon�veis. Com esta t�cnica, os roteadores esperam por mudan�as que devem afetar rotas, por algum per�odo de tempo. Esse per�odo, por padr�o do RIP, � de 3 vezes o tempo da atualiza��o peri�dica (por padr�o, o RIP manda atualiza��es tempor�rias a cada 30s).

Situa��es onde este tempo � utilizado:

- Quando um roteador recebe uma atualiza��o de um vizinho indicando que uma rede que era acess�vel agora n�o est� mais. O roteador ent�o, marca a rota como possivelmente inalcan��vel (possible down) e come�a a marcar seu tempo de espera.

- Se a atualiza��o de algum vizinho chegar com m�trica melhor do que aquela que est� na tabela de roteamento do enlace possivelmente inalcan��vel, o roteador marca o enlace como alcan��vel e retira o tempo de espera.

- Se em qualquer momento, antes do tempo de espera estourar, o roteador receber uma atualiza��o de um vizinho diferente, com uma m�trica mais fraca ou igual aquela da rede possivelmente inalcan��vel, esta ser� descartada. Ignorando estas atualiza��es de m�tricas piores enquanto estiver em tempo de espera, o roteador que percebeu a mudan�a d� mais tempo aos demais roteadores para que estes sejam avisados de uma mudan�a na rede.

- Durante este tempo de espera, as rotas aparecem como possivelmente inalcan��veis nas tabelas de roteamento. Mesmo com a rota estando no estado de possivelmente inalcan��veis, os roteadores continuam tentando encaminhar os pacotes para essa rede (talvez esta rede s� esteja tendo um problema de conex�o intermedi�ria, oscila��o...)


Atualiza��es Imediatas (Triggered Updates)

Nos exemplos anteriores, os loops de roteamento foram causados gra�as as informa��es erradas obtidas como resultado de atualiza��es inconsistentes, converg�ncia lenta e temporiza��o. O fato dos roteadores esperarem por suas atualiza��es peri�dicas para notificar aos demais uma altera��o na rede, faz com que a rede tenha um tempo de converg�ncia mais lento.
Normalmente, as atualiza��es nas tabelas de roteamento s�o passadas aos demais em um intervalo de tempo constante. Essa ferramenta prop�e que sejam mandadas atualiza��es imediatas assim que um roteador perceber uma altera��o na rede. O roteador que percebe a mudan�a passa ent�o imediatamente aos seus vizinhos esta atualiza��o, estes ao receberem a atualiza��o, tamb�m a passar�o imediatamente para seus demais vizinhos e assim a atualiza��o chega mais rapidamente aos roteadores envolvidos.
Essa id�ia de atualiza��o imediata seria suficiente se pudesse garantir que cada uma destas atualiza��es chegasse imediatamente aos roteadores apropriados. Por�m, podem ocorrer dois problemas:

- Os pacotes de atualiza��o podem ser descartados ou corrompidos ao longo de sua trajet�ria.

- As atualiza��es imediatas n�o ocorrem instantaneamente. � poss�vel que um roteador que ainda n�o recebeu esta atualiza��o imediata envie sua atualiza��o peri�dica, fazendo com que seu vizinho que acabara de atualizar sua tabela devido a atualiza��o imediata que ele recebeu, coloque a rota novamente em sua tabela.

Agora, juntando as atualiza��es imediatas com o tempo de espera o problema � solucionado. Por que com o tempo de espera, mesmo que o algu�m envie uma atualiza��o tempor�ria antes de receber a atualiza��o imediata, os demais roteadores que j� haviam recebido as atualiza��es imediatas e haviam posto tal rota como possivelmente inalcan��vel, ao receberem um caminho alternativo com m�trica pior ou igual a que eles conheciam, n�o atualizem suas tabelas enquanto o tempo n�o houver estourado. Isso faz com que a atualiza��o imediata tenha mais tempo para percorrer todos os roteadores envolvidos antes destes tentarem divulgar um novo caminho at� a rede que foi modificada.

Caracter�sticas

A seguir temos algumas das principais caracter�sticas do RIP:

- � um protocolo relativamente antigo mais ainda � bastante utilizado em redes pequenas.

- Por se tratar de um protocolo antigo e simples, quase todos os roteadores podem utilizar o RIP.

- � de f�cil configura��o (pouca complexidade).

- � um protocolo baseado no algoritmo de vetor distancia.

- Contagem de saltos � utilizada como a �nica m�trica para a sele��o de caminhos. Isso faz com que nem sempre o melhor caminho seja armazenado na tabela de roteamento. Um exemplo dessa situa��o � mostrado abaixo, onde de A para C existem dois caminhos. Um deles � pelo roteador B, tendo custo em 2 saltos 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 escolhido pelo RIP sempre ser� pelo link de 64 Kbps j� que a �nica m�trica � o n�mero de saltos.

- O n�mero m�ximo de saltos permitidos � 15. Isso limita o uso deste protocolo a redes n�o muito grandes, mas como ele � um IGP, este n�mero parece razo�vel. O RIP � projetado para intercambiar informa��es de roteamento em uma rede de tamanho pequeno para m�dio.

- Atualiza��es peri�dicas de roteamento a cada 30 segundos por padr�o. Mesmo que n�o exista nenhuma altera��o nas rotas da rede, os roteadores baseados em RIP, continuar�o a trocar mensagens de atualiza��o nestes intervalos regulares. Dentre outros, este � mais um dos motivos pelos quais o RIP n�o � indicado para redes maiores, pois nestas situa��es o volume de tr�fego gerado pelo RIP, poderia consumir boa parte da banda dispon�vel. Al�m disso, cada mensagem do protocolo RIP comporta, no m�ximo, informa��es sobre 25 rotas diferentes, o que para grandes redes, faria com que fosse necess�ria a troca de v�rias mensagens, entre dois roteadores, para atualizar suas respectivas tabelas, com um grande n�mero de rotas.

- RIP � capaz de fazer balanceamento de carga em at� 6 caminhos por�m estes devem ser de custo iguais. Basta definir o n�mero m�ximo de caminhos paralelos permitidos na tabela de roteamento. Com o RIP, estes caminhos devem ser de custo iguais. Caso n�o seja do interesse trabalhar com balanceamento de cargas, basta escolher esse n�mero m�ximo de caminhos paralelos como 1.

- A primeira vers�o do RIP, o RIPv1 criada em 1988, que ainda � utilizada atualmente, � implementada como sendo um protocolo de roteamento classful, isso significa que ele n�o manda a m�scara de rede das rotas que ele divulga em suas atualiza��es. Devido a essa caracter�stica, n�o podemos trabalhar com redes de tamanho de mascara variado. (Variable Lenght Subnet Mask- VLSM). O RIPv1 foi desenvolvido para trabalhar com redes baseadas nas classes padr�o A, B e C, ou seja, pelo n�mero IP da rota, deduzia-as a respectiva classe. Com o uso da Internet e o uso de um n�mero vari�vel de bits para a m�scara de sub-rede (n�mero diferente do n�mero de bits padr�o para cada classe), esta fato tornou-se um problema s�rio do protocolo RIP v1. O protocolo RIP v1, utiliza a seguinte l�gica, para "descobrir" qual a m�scara de sub-rede associada com determinada rota:

1. Se a identifica��o de rede coincide com uma das classes padr�o A, B ou C, � assumida a m�scara de sub-rede padr�o da respectiva classe.

2. Se a identifica��o de rede n�o coincide com uma das classes padr�o, duas situa��es podem acontecer.

2.1 Se a identifica��o de rede coincide com a identifica��o de rede da interface na qual o an�ncio foi recebido, a m�scara de sub-rede da interface na qual o an�ncio foi recebido, ser� assumida.

2.2 Se a identifica��o de rede n�o coincide com a identifica��o de rede da interface na qual o an�ncio foi recebido, o destino ser� considerado um host (e n�o uma rede) e a m�scara de sub-rede 255.255.255.255, ser� assumida.


- As atualiza��es peri�dicas do RIPv1 utilizam o endere�o de broadcast. Com isto, todos os hosts da rede receber�o os pacotes RIP e n�o somente os hosts habilitados ao RIP.


- O RIPv2, a vers�o 2 do RIP que surgiu em 1993, j� � um protocolo de roteamento classless , ou seja, envia a mascara das redes divulgadas em suas atualiza��es. J� permitindo trabalhar com redes de tamanho de m�scara variado.

- Outra melhora do RIPv2, � que este � mais seguro pois utiliza autentica��o, o que visa proteger a rede contra utiliza��o de roteadores n�o autorizados. Com o RIPv2 � poss�vel implementar um mecanismo de autentica��o, de tal maneira que os roteadores somente aceitem os an�ncios de roteadores autenticados, isto �, identificados na rede. A autentica��o pode ser configurada atrav�s da defini��o de uma senha ou de mecanismos mais sofisticados como o MD5 (Message Digest 5). Por exemplo, com a autentica��o por senha, quando um roteador envia um an�ncio, ele envia juntamente a senha de autentica��o. Outros roteadores da rede, que recebem o an�ncio, verificam se a senha est� correta e somente depois da verifica��o, alimentam suas tabelas de roteamento com as informa��es recebidas.

- Os an�ncios de atualiza��o do protocolo RIPv2 s�o baseados em tr�fego multicast e n�o mais broadcast como no caso do protocolo RIPv1. O protocolo RIPv2 utiliza o endere�o de multicast 224.0.0.9. Com isso os roteadores habilitados ao RIPv2 atuam como um grupo multicast, registrado para "escutar" os an�ncios do protocolo. Outros hosts da rede, n�o habilitados ao RIPv2, n�o ser�o "importunados" pelos pacotes deste protocolo. Por quest�es de compatibilidade (em casos onde parte da rede ainda usa o RIP v1), � poss�vel utilizar broadcast com roteadores baseados em RIP v2. Mas esta solu��o somente deve ser adotada durante um per�odo de migra��o, assim que poss�vel, todos os roteadores devem ser migrados para o RIPv2 e o an�ncio via broadcast deve ser desabilitado.

- � importante mencionar que tanto redes baseadas no RIPv1 quanto no RIPv2 s�o redes chamadas planas (flat). Ou seja, n�o � poss�vel formar uma hierarquia de roteamento, baseada no protocolo RIP. Mais um motivo para o RIP n�o ser utilizado em grandes redes. A tend�ncia natural do RIP, � que todos os roteadores sejam alimentados com todas as rotas poss�veis (isto � um espa�o plano, sem hierarquia de roteadores). Imagine como seria utilizar o RIP em uma rede como a Internet, com milh�es e milh�es de rotas poss�veis, com links caindo e voltando frequentemente? Imposs�vel. Por isso que o uso do RIP (v1 ou v2) somente � indicado para pequenas redes.

- O RIPv1 � descrito na RFC 1058 e a vers�o 2 (RIPv2) nas RFCs 1721 e 1722.

Como um roteador determina se um pacote deve ser enviado para outra rede ou não?

Como ocorre o roteamento de pacotes?

Quais são os tipos de roteamento?

Qual o tipo de protocolo de roteamento dinâmico que envia suas tabelas completas para os seus vizinhos?