Mudanças entre as edições de "RCO3-2013-2-CST Redes de Computadores 3 - CST"

De MediaWiki do Campus São José
Ir para navegação Ir para pesquisar
Linha 679: Linha 679:
 
==== ''Split Horizon'' com ''Poison Reverse'' [http://en.wikipedia.org/wiki/Split_horizon_route_advertisement]====
 
==== ''Split Horizon'' com ''Poison Reverse'' [http://en.wikipedia.org/wiki/Split_horizon_route_advertisement]====
  
−
É uma variante do Split Horizon em que o roteador divulga as totas aprendidas por um dataerminada interface, pela própria interface, mas com métrica infinita (16).
+
É uma variante do Split Horizon em que o roteador divulga as rotas aprendidas por um determinada interface, pela própria interface, mas com métrica infinita (16).
  
 
=== Envenenamento de Rota [http://en.wikipedia.org/wiki/Route_poisoning] ===
 
=== Envenenamento de Rota [http://en.wikipedia.org/wiki/Route_poisoning] ===

Edição das 08h11min de 23 de setembro de 2013

Professor

Eraldo Silveira e Silva

email: eraldo.silveira@gmail.com

COMUNICAÇÂO: emails sempre devem conter assunto RCO3-2013-2 senão serão jogados na lixeira.

Cronograma de Aulas

Aula Data Horas Conteúdo Recursos
1 16/8 2 Revisão de conceitos em redes. Plano de Ensino. Experimento de Rota Estática dos Labs do NETKIT. Lab. Redes 2
2 23/8 2 Caracterizar as funcionalidades da camada de rede. Protocolos de Roteamento. Protocolo de Estado de Enlace Lab. Redes 2
3 24/8 2 Continuação experimento de rota estática - desafio. Lab. Redes 2
4 26/8 2 Laboratório de Estado de Enlace. Lab. Redes 2
5 30/8 2 Protocolo de Vetor de Distância. Lab. Redes 2
6 6/9 2 Roteamento em Redes Adhoc Lab. Redes 2
7 9/9 2 Revisão para a avaliação. Lab. Redes 2
8 13/9 2 Avaliação I Lab. Redes 2
9 20/9 2 Experimento de Rota Estática com Quagga Lab. Redes 2
10 23/9 2 Introdução ao Protocolo RIP. Laboratótio Básico Lab. Redes 2
11 27/9 2 Protocolo RIP. Laboratório Avançado. Lab. Redes 2
12 4/10 2 Introdução ao Protocolo OSPF. Laboratório Básico Lab. Redes 2
13 7/10 2 LAboratório de Estado de Enlace. Lab. Redes 2
14 11/10 2 Laboratório de Àreas no OSPF Lab. Redes 2
15 18/10 2 Desafio OSPF Lab. Redes 2
16 19/10 2 Introdução ao Protocolo BGP. Roteamento na Internet. Lab. Redes 2
17 21/10 2 Laboratório 1 de BGP Lab. Redes 2
18 25/10 2 Laboratório 2 de BGP Lab. Redes 2
19 1/11 2 Roteamento Multicast Lab. Redes 2
20 4/11 2 Roteamento Multicast Lab. Redes 2
21 8/11 2 Mobilidade IP Lab. Redes 2
22 18/11 2 Mobilidade IP Lab. Redes 2
23 22/11 2 Apresentação Projeto Final Lab. Redes 2
24 29/11 2 Desenvolvimento Projeto Lab. Redes 2
25 2/12 2 Desenvolvimento Projeto Lab. Redes 2
26 6/12 2 Desenvolvimento Projeto Lab. Redes 2
27 13/12 2 Apresentação Projeto Final Lab. Redes 2
28 16/12 2 Recuperação Lab. Redes 2
TOTAL 56

Aula 1 - 16/8/2013

OBJETIVOS DA AULA

  • Apresentar o plano de Ensino;
  • Rever conceitos de rede;
  • Instalar o NETKIT;
  • Aprender a utilizar o NETKIT;
  • Realizar o experimento de Rota Estática dos Labs do NETKIT;
  • Implementar o laboratório desafio despertando para o problema de loops em roteamento.

Plano de Ensino

Apresentação do cronograma. Avaliações: Avaliação I e II (escritas), Desafios (enviados por email), Projeto Final e Recuperação (prova escrita).

Conceitos em rede

Discussão informal com os alunos.

Instalação do NETKIT

O NETKIT deve estar instalado no lab de redes II. O procedimento a seguir é para quem quiser instalar em casa.

1.Baixar os seguintes arquivos para este diretorio:

2.Descompactá-los usando: 

tar xvfj netkit-2.8.tar.bz2
tar xvfj netkit-filesystem-i386-F5.2.tar.bz2
tar xvfj netkit-kernel-i386-K2.8.tar.bz2

3.Editar ~/.bashrc ou ~/.profile e inserir as variáveis 

export NETKIT_HOME=~/netkit
export PATH=$PATH:$NETKIT_HOME/bin
export MANPATH=:$MANPATH:$NETKIT_HOME/man

4,Testar a instalação 

. ~/.profile
cd $NETKIT_HOME
./check_configuration.sh

Aprendendo a utilizar o NETKIT

Laboratório de Rota Estática do NETKIT

Baixar o laboratório daqui e descompactá-lo:

    • Para executar o laboratório, basta entrar no diretório e fazer:
lstart

NOTA: para iniciar as máquinas em paralelo use lstart -p
    • Para parar o laboratório:
lhalt

Note que este comando não remove as imagens dos discos das 
máquinas (.disk). Para remover use lcrash


Desafio

Seja a rede abaixo com os seguintes prefixos:

  • SN1 : 200.10.1.0/24
  • SN2 : 200.10.2.0/24
  • SN3 : 200.10.3.0/24
  • SN4 : 200.10.4.0/24
  • SN5 : 200.10.5.0/24
  • SN6 : 200.10.6.0/24
  • SN7 : 200.10.7.0/24
  • SN8 : 200.10.8.0/24

ExercicioConfEstaticaZebra.png

  1. Configure estaticamente os roteadores, usando o Netkit, de forma que a rota entre H1 e H2 passe pelas subnets SN2,SN5 e SN6 na transmissão de pacotes de H1 para H2 e passe por SN6 e SN3 para transmissão de pacotes de H2 para H1. Teste a configuração com um ping de H1 para H2. Capture pacotes com o tcpdump em R3 e R4 de forma a demonstrar a passagem de pacotes ICMP do ping por estas rotas.
  2. Monte um pequeno relatório mostrando as capturas da tela da execução do tcpdump e explicando o sucesso dos resultados. Coloque também as tabelas de roteamento dos roteadores envolvidos (use route -n) e explique cada uma das linhas das tabelas de roteamento.
  3. Na configuração anterior, acrescente um hospedeiro H3 na rede SN1, mas com endereçamento da rede SN8. Faça este hospedeiro ser "pingável" a partir de H2. A rota de H2 para H3 deve passar por SN4.
  4. Adicione os resultados ao relatório demonstrando que H3 é alcançado. Para isto use o tcpdump e as tabelas de roteamento de interesse.
  5. Prepare um exemplo de roteamento mostrando a formação de um loop quando H1 transmite para H2. Para testar use um ping que gere um TIME TO LIVE de tamanho 10.

PROBLEMAS COMUNS:

  • Esquecer de rota reversa. O ping REPLY não voltará;
  • Usar como IP de um gateway de encaminhamento, o próprio endereço do roteador;
  • Usar como IP de um gateway de encaminhamento um endereço IP não pingável;
  • Interfaces não estão configuradas com endereço IP ou não estão UP (ativas);
  • Netkit não funciona porque o diretório do netkit não está em ~/netkit. Ajustar o caminho nas variáveis;
  • As interfaces do roteador ou host não aparecem ou não estão com IP configurados: problema no lab.conf. O nome da máquina no lab.conf é o mesmo do .startup? O arquivo .startup configura corretamente a interface?
  • Você está em dúvida se uma máquina linux está configurada para ser roteador? Faça:
 cat /proc/sys/net/ipv4/ip_forward

Se resultar em 1 está configurada. Se quiser configurar, fazer: 

 echo 1 > /proc/sys/net/ipv4/ip_forward
NOTA: as máquinas UML do netkit já estão configuradas para roteador.

Referências

Aula 2 - 23/8/2013

OBJETIVOS DA AULA

  • Finalizar apresentações da aula anterior;
  • Caracterizar as funcionalidades da camada de rede;
  • Compreender a necessidade de algoritmos de roteamento para construção dinâmica de tabelas de roteamento.
  • Compreender o funcionamento de um algoritmo de estado de enlace;
  • Construir a tabela de custos manualmente de um algoritmo de estado de enalce.

Media:Aula1-CamadaRede-EstadoEnlace.pdf

Aula 3 - 26/8/2013

OBJETIVOS DA AULA

  • Revisar o algoritmo de estado de enlace;
  • Repassar um exercício para os alunos implementar;
  • Implementar o laboratório
  • Conferir resultados com o exercício
  • Implementar o desafio
  • Verificação dos resultados em sala.


Programa C do livro do Tanenbaum com o algoritmo link-state: 

#include <stdio.h>             //  Network from Tanenbaum text
#define MAX_NODES 6            //  Distance from i to j node
#define INFINITY 1000000000    //  0 if i=j or not connected

int n;
int dist[MAX_NODES][MAX_NODES] =    
{ //     A  B  C  D  E  F  
	{0, 2, 5, 1, 0, 0 }, 
	{2, 0, 3, 2, 0, 0 },
	{5, 3, 0, 3, 1, 1 },
	{1, 2, 3, 0, 1, 0 },
	{0, 0, 1, 1, 0, 2 },
	{0, 0, 1, 0, 2, 0 }};

typedef enum {permanent, tentative} labelID;


int num_perm=1;
struct state {
	int predecessor;
        int length;
        labelID label;
} state[MAX_NODES];

void shortest_path(int s){
 int i, k, min;
 n = MAX_NODES;
 for(i=0; i<n; i++) {
        if (dist[s][i]!=0) {
                state[i].predecessor = s;
                state[i].length = dist[s][i];
        }else {
                state[i].predecessor = -1;
                state[i].length = INFINITY;
        } 
        state[i].label = tentative;
 }
 state[s].length = 0;
 state[s].label=permanent;       
 do {
        min = INFINITY;
        for (i=0; i<n; i++) {
                if( state[i].label == tentative && state[i].length < min) {
                        min=state[i].length;
                        k=i;
                }
        }
        state[k].label = permanent; // No de menor custo se torna permanente
        num_perm++;
        for(i=0; i<n; i++) {
                if(dist[k][i] != 0 && state[i].label == tentative) 
                        if(state[k].length+dist[k][i] < state[i].length) {
                                state[i].predecessor = k;
                                state[i].length = state[k].length+dist[k][i];
                        }
        }
 } while(num_perm!=MAX_NODES);
}

main()
{
  int i,dest;
  printf("entre com o destino => ");
  scanf("%d", &dest);
  shortest_path(0);
  i=dest;
  printf("CAMINHO REVERSO\n");
  do {
     printf("\n%d ",state[i].predecessor);
     i=state[i].predecessor;
  } while (state[i].predecessor!=-1);
  printf("\nFIM\n");
}

Aula 4 - 30/8/2013

Objetivos

-Apresentar o algoritmo vetor de distância;

-Discutir problema de contagem infinita e uma solução: reverso envenenado;

-Apresentar um java applet para calcular rotas com algoritmos SP e VD;

Desenvolvimento da Aula

Ver material em:

Desafio a ser entregue: tabela de cálculo de vetor de distância do exercício proposto no doc acima.

Aula 5 - dia 06/09/2012

OBJETIVOS DA AULA

  1. Apresentar o software Quagga;
  2. Explorar a forma como a a tabela de roteamento é atualizada no Linux;
  3. Realizar gerenciamento de interfaces e roteamento estático com o Quagga usando o Netkit;

O Pacote Quagga

O pacote Quagga fornece um conjunto de processos (daemons) com facilidades para a construção da tabela de roteamento de um sistema. O projeto Quagga é derivado do conhecido pacote Zebra. O esquema abaixo mostra a estrutura do Quagga.

EstruturaZebra.png

Acima do kernel se executam processos especializados para a configuração da tabela de roteamento. Note que a tabela de roteamento é mantida pelo kernel do Sistema Operacional Linux/Unix e qualquer modificação será realizada a partir da API (Application Programming Interface) do sistema. O processo Zebra centraliza todo o gerenciamento da tabela recebendo e repassando informações para outros processos que executam um determinado protocolo de roteamento. Por exemplo, no esquema mostrado existem 3 processos responsáveis pela execução dos protocolos BGP, RIP e OSPF. Como será visto posteriormente, é possível executar vários protocolos de roteamento dinâmico simultaneamente. 

 Nota: Configurações estáticas também deverão ser realizadas pelo QUAGGA!

Cada processo do Quagga possui o seu próprio arquivo de configuração e um terminal para receber comandos (um processo shell chamado vtysh). Cada terminal se comunica com seu deamon por uma porta específica. No arquivo do Zebra deverão constar as configurações estáticas.

Os deamons do sistema são chamados pelos seguintes nomes:

  • zebra (acesso pela porta 2601 no vty);
  • ripd (acesso pela porta 2602 no vty);
  • ripngd (acesso pela porta 2603 no vty);
  • ospfd (acesso pela porta 2604 no vty);
  • ospf6d (acesso pela porta 2606 no vty);
  • bgpd (acesso pela porta 2605 no vty);

Os deamons possuem arquivos de configuração por default localizados normalmente no diretório /etc/quagga e possuindo a terminação conf: por exemplo: zebra.conf para o processo zebra. Entretanto será comum usarmos arquivos de configuração fornecidos na linha de comando: 

#zebra -d -f zebra_custom.conf.

Nos arquivos de configuração podemos colocar informações tais como senhas para o terminal vty, configurações de depuração, de roteamento e de log. O que segue aos pontos de exclamação (vale também \#) são comentários.

Através do Zebra (e seu arquivo de configuração) é possível ligar/desligar interfaces e atribuir endereços as mesmas. Também pode-se acrescentar rotas:

Exemplo de arquivo de configuração para o deamon zebra: 


!
! Zebra configuration file
!
hostname Router
%password zebra
%enable password zebra
! Wired interface
interface eth0
ip address 10.10.10.3/24  

! Wired interface
interface eth1 
ip address 10.10.30.1/24 

ip route 10.10.20.0/24 10.10.30.2
!
log stdout
!poderia ser, por exemplo, log file /var/log/quagga/zebra.log
!


Confira aqui o item 4 do manual do Quagga

Confira aqui com amis detalhes como o zebra trabalha com o Linux e as diferenças entre os termos RIB e FIB:

Olhando o tutorial acima observa-se que a tabela de roteamento (encaminhamento) pode ser modificada manualmente (via route e ifconfig), via protocolos de roteamento (através do Zebra) ou ainda via redireções ICMP. Este último caso pode ser verificado aqui:

Pra listar o cache de rotas: 

route -Cen

O ROTEIRO DO EXPERIMENTO

ETAPA 1 - Construindo rotas estáticas usando o QUAGGA

OBS: Esta etapa já está implementada no laboratório a ser baixado!

Para fins de ilustração segue os passos de montagem do laboratório. Conforme comentado anteriormente, quando o QUAGGA for utilizado para roteamento dinâmico, as rotas estáticas e possíveis manipulações nas interfaces devem ser realizadas pelo próprio \textit{zebra}. Neste sentido vamos trabalhar como colocar rotas e ativar/desativar interfaces pelo Zebra.

  • Construir, usando o netkit, um cenário conforme a figura abaixo:

Fig1Lab3.png

Para tanto faça o seguinte:

  • Criar um diretório chamado LabQuaggaRotaEstatica. Todas as operações

deverão ser realizadas a partir deste diretório;

  • Criar o lab.conf com a configuração desejada;
  • Criar os subdiretórios para cada roteador e hospedeiro;
  • Construir normalmente os arquivos de configuração para os

hospedeiros: H1.startup etc. Coloque os comandos para a configuração das interfaces e do roteador default. O zebra não se executará nos hospedeiros;

  • Cada roteador deverá executar o deamon zebra da forma:
zebra -d -f /hostlab/R1/zebra.conf

Para tanto, configure os arquivos de startup dos roteadores para que executem o zebra desta forma;

  • Dentro de cada subdiretório de roteador (no diretório do laboratório)

coloque o arquivo de configuração do zebra.conf; Lembre-se que este diretório estará mapeado em /hostlab das máquinas virtuais;

  • No arquivo zebra.conf deverão ser configuradas as interfaces do

roteador usando os comandos de interface conforme colocado acima;

  • Ainda no arquivo de configuração do zebra, deve-se estabelecer as rotas

estáticas. Baseando-se nas configurações mostradas como exemplo, configure devidamente cada roteador;

  • Coloque o cenário em execução e teste a conectividade dos hospedeiros;


ETAPA 2 - Observando o estado do sistema

Usando o vtysh (ou o telnet) podemos logar no zebra. A patir desta sessão podemos visualizar o estado do sistema e alterar configurações previamente estabelecidas. Vamos ao procedimento:

  • Solicitar uma sessão com o vtysh em um roteador do laboratório;
  • Verifique o estado das interfaces usando o comando:
show interface
  • Verifique se o roteador está habilitado para roteamento:
show ip forwarding
  • Verifique o estado da tabela de roteamento usando o comando:
show ip route
  • Verifique a configuração atual do roteador:
show run
  • Sair do vtysh com quit
#exit
#quit



NOTA: O termo FIB é associado a tabela de encaminhamento de um sistema
sendo que na listagem mostrada as rotas marcadas com \* foram instaladas na FIB
do kernel do linux. A FIB possui uma entrada para cada rede de destino. O Zebra
mantém a RIB que pode conter várias rotas para um mesmo destino. É a partir da
RIB que é montada a FIB.}


As rotas indicadas foram ``aprendidas a partir de redes diretamente conectadas (C) ou instaladas estaticamente (S). As rotas poderiam ainda ter sido apreendidas por protocolos de roteamento dinâmico ou ainda rotas estabelecidas pelo próprio kernel.

ETAPA 3 - Modificando a configuração do terminal

Quando logamos no zebra entramos em um modo que permite apenas observar o estado do sistema. Para modificar a configuração temos que entrar em um modo

  • Entrar em H1 e deixar o terminal pingando em H3:
ping 200.10.20.1
  • Entrar no zebra em R1 com vtysh
vtysh
  • Entrar com o comando para alterar configuração do terminal:
conf t
  • Entrar com a interface a ser operada:
interface eth0
  • Desative a interface
 shutdown
  • Verifique o ping em H1;
  • Restaure a interface:
no shutdown
  • Sair do modo configuração
 quit
  • Sair do modo enable
quit
  • Listar novamente a tabela de roteamento e verificar se retornou a

normalidade: 

show ip route

Desafio

Considere a rede abaixo com os seguintes prefixos:

  • SN1 : 200.10.1.0/24
  • SN2 : 200.10.2.0/24
  • SN3 : 200.10.3.0/24
  • SN4 : 200.10.4.0/24
  • SN5 : 200.10.5.0/24
  • SN6 : 200.10.6.0/24
  • SN7 : 200.10.7.0/24
  • SN8 : 200.10.8.0/24

ExercicioConfEstaticaZebra.png

Configure estaticamente os roteadores, usando o zebra, de forma que a rota de H1 para H2 passe pelas subnets 1,4 e 8, e o retorno, pelas subnets 8,6,5,2 e 1.

Aula 5 - dia 09/09/2012

OBJETIVOS DA AULA

  • preparação para avaliação;
  • distribuição de trabalhos de roteamento de redes adhoc.

Exercícios

Fazer em dupla:

Distribuição de trabalhos de Roteamento em Redes Adhoc

13/09/2013 - Aula de Introdução ao Protocolo RIP

OBJETIVOS DA AULA

  • Apresentar as características básicas do protocolo RIP;
  • Configurar uma rede simples com o Protocolo RIP.

Características do Protocolo RIP

  • Protocolo de vetor de distâncias: uma evolução do Gateway Information Protocol da Xerox;
  • No começo da década de 80 os sistemas UNIX o incluiram em servidores para que estes atuassem como roteadores;
  • Descrito nas RFCs 1058 (RIPv1) e RFCs 1388, 1723, e 2453 (RIPv2);
  • O RIP é baseado no algoritmo de vetor de distância e utiliza como métrica o número de hops ou saltos entre roteadores. Uma rede diretamente conectada tem hop 0. Uma rede ligada diretamente a um roteador vizinho tem contador 1. Um destino com contador de hop 16 é considerado inalcançável;
  • O RIPv1 é um protocolo de roteamento classfull (redes classe A,B,C);
  • O RIPv2 possui as seguintes características adicionais:
    • Suporte para máscaras de tamanho variável (VLSM);
    • As mensagens de atualização de rota (updates) são realizadas via multicast no endereço 224.0.0.9;
    • As atualizações de rota podem ser autenticadas com senhas criptografadas;
  • Suporta anuncio de rotas por roteadores sem RIP: campo next-hop router na mensagem;
  • Se utiliza da porta UDP 520 para toda a troca de pacotes;
  • O protocolo RIP é interessante para uso em pequenas redes;

Funcionamento Básico do RIP

  • Um roteador RIP envia, a cada 30s, toda a sua tabela de roteamento para todos os roteadores diretamente conectados a ele, mesmo que não exista nenhuma mudança nesta tabela! Desperdício de banda...
O RIP classifica os roteadores em ativos e passivos. Os roteadores ativos enviam normalmente suas tabelas de roteamento para seus vizinhos enquanto os passivos somente escutam e atualizam suas rotas.
  • A operação típica do RIP usa dois pacotes: requisição e resposta. Ao ser iniciado, um roteador envia pacotes de requisição por todas as suas interfaces (a versão 1 usa endereço broadcast 255.255.255.255 e a versão usa multicast no endereço 224.0.0.9).
  • Pacotes de requisição serão sempre respondidos por pacotes de resposta. Um pacote de resposta pode conter até 25 rotas. Estes pacotes nunca serão encaminhados para outros roteadores, ou seja, um roteador sempre aprende através de seus vizinhos}.
  • O roteador agrupa a informação das várias tabelas de roteamento recebidas para construir a sua própria tabela, escolhendo os caminhos com menor distância ou hops. Uma rota que não é atualizada durante 3 min é removida ou colocada com custo infinito (poisened reverse).
Um roteador, analisando um pacote de resposta, deve incluir eventuais novas redes a sua tabela de roteamento ou trocar rotas de redes existentes se as rotas recebidas possuem menores métricas


Exemplo de funcionamento

Considere o exemplo da figura abaixo. O roteador C publica a rede 192.168.5.0 para o roteador B. O roteador B adiciona a rede a sua tabela de roteamento com métrica 1 e next hop 192.168.4.2. O roteador B publica a sua própria tabela de roteamento para o roteador A e para o roteador C. O roteador A aprende do roteador B sobre as redes 192.168.3.0 e 192.168.5.0. O roteador A adiciona a rede 192.168.3.0 com métrica 1 e a rede 192.168.5.0 com métrica 2. O endereço next hop para ambas as redes é 192.168.2.2. O roteador A agora sabe que ele pode enviar pacotes destinados para a rede B ou C através de B.


Arquivo:Fig1RIP.png

Exemplo de Funcionamento do RIP

Laboratório: Configuração básica do RIP com o Zebra

ETAPA 1

 Esta etapa já está implementada no link : Laboratório RIP básico


Fig5RIP.png

  • Construa um cenário conforme a rede da Figura acima, usando o netkit. Coloque endereços em todos os hospedeiros bem como as

rotas default nas tabelas de roteamento dos mesmos; 

NOTE que o RIP não se executa nos hospedeiros.
  • Faça um zebra.conf para configurar os endereços dos roteadores, tal como no laboratório anterior;
  • Crie os arquivos de configuração para o RIP em cada roteador, colocando-os dentro dos diretórios dos mesmos. Edite o arquivo ripd.conf para cada roteador, acrescentando as linhas:
router rip
redistribute connected
redistribute static
network eth0
network eth1


  • Execute o zebra e o rip, nos arquivos de startup dos roteadores:
zebra -d -f /hostlab/EUA/zebra.conf

ripd -d -f /hostlab/EUA/ripd.conf

ETAPA 2

  • Verifique as tabelas de roteamento usando o vtysh no zebra;
  • Use o ping e o traceroute para testar todos os caminhos percorridos pelos

pacotes, tanto entre roteadores como entre máquinas clientes. Baseado nesta observação qual métrica você acha que o RIP utiliza para computar as rotas?

  • “Derrube” o enlace BRASIL-ITÁLIA (desative uma interfaces tal como no laboratório anterior) e volte a testar a conectividade;
  • Religue a interface e volte a verificar as tabelas de roteamento.

ETAPA 2 - DESAFIO

Configurar o RIP na rede abaixo. Use os endereços indicados.

ExercicioConfEstaticaZebra.png

  • SN1: 200.10.1.0/24
  • SN2: 200.10.2.0/24
  • SN3: 200.10.3.0/24
  • SN4: 200.10.4.0/24
  • SN5: 200.10.5.0/24
  • SN6: 200.10.6.0/24
  • SN7: 200.10.7.0/24
  • SN8: 200.10.8.0/24

21/09/2013 - Aula da Avaliação I

23/09/2013 - Aula de Laboratório RIP Avançado

OBJETIVOS DA AULA

  • Explorar características avançadas do RIP;

CARACTERÍSTICAS AVANÇADAS DO RIP

Timers

Na prática existem 4 timers:

Timer Valor Cisco Valor RFC 1058 default
Update 30s 30s
Invalid 180s 180s
Flush 60s 120s
Hold Down ? ?

Route Update Timer: Controla o período de envio das atualizações de tabela;

Route Timeout(Invalid) Timer: Controla o tempo necessário para que um roteador coloque uma rota como inválida (16) sendo normalmente três vezes o valor do Route Update Timer. Este estouro de tempo ocorre, por exemplo, quando um roteador deixa de ouvir sobre uma rota de qualquer outro roteador.

Route Flush Timer: Após ter sido marcada como inválida, a rota somente será retirada após este tempo. Isto permite dar tempo aos demais roteadores para aprender que a rota é inválida.

Holdown Timer: É um quarto temporizador que permite que um roteador, durante um certo tempo (tipicamente 60s), ignore toda a informação sobre novos caminhos para um destino que foi classificado de inatingível. O holdown timer evita informações inconsistentes. Por exemplo, considere a rede abaixo. Caso o link entre A e B apresente problemas então a rede 192.168.1.0 fica inacessível a B. O roteador B detecta este fato (pela ausência dos updates vindo de A, por exemplo) e coloca a rede como inacessível. O roteador B informa este fato no próximo envio da tabela de roteamento para C e D. Se D receber esta informação e, por questões de uma pequena diferença de tempo, C enviar suas tabelas para D antes de receber a informação de B, o roteador D pode colocar a rede 192.168.1.0 como indisponível e logo em seguida vir a atualizar erroneamente a sua tabela devida a mensagem de C, acabando por a encaminhar pacotes para a rede 192.168.0.1 através de C. Se o uso do holdown timer estiver habilitado, D não altera altera o estado de indisponibilidade da rede até que o temporizador se expire.

Arquivo:Fig2RIP.png

Trigger Update

Este mecanismo faz com que na ocorrência de uma falha o roteador envie imediatamente para os vizinhos uma nova rota para uma rede cuja métrica tenha sido alterada, sem esperar pelo próximo envio periódico. Por exemplo, se o roteador detectou que uma rede se tornou indisponível, ele coloca métrica 16 para esta rede e divulga imediatamente para seus vizinhos. Esta técnica pode provocar uma avalanche de broadcasts em redes com vários roteadores mas, por outro lado, melhora o tempo de convergência na rede RIP.

Split Horizon

Este mecanismo foi implementado na v2 do RIP. Um roteador não envia para uma interface informação de caminhos que tenha sido aprendida por esta mesma interface.

Split Horizon com Poison Reverse [1]

É uma variante do Split Horizon em que o roteador divulga as rotas aprendidas por um determinada interface, pela própria interface, mas com métrica infinita (16).

Envenenamento de Rota [2]

Este mecanismo funciona da seguinte forma: quando um roteador detecta uma falha numa ligação ele coloca as entradas correspondentes a infinito (custo 16), e publica esse caminho durante algum tempo. Aumenta a dimensão das mensagens de update.

Quando um roteador recebe a indicação de que uma rota passou repentinamente para uma distância infinita (Route Poisoning), publica essa rota “infinita” no sentido de onde aprendeu (sobrepondo-se ao Split Horizon) durante algum tempo

Observando Tabelas de Roteamento, Métricas e Publicações de Rota

Seja a seguinte Rede:

RedeRIP.png

Durante o experimento estaremos focando a rede X de prefixo 172.10.10.0/24.


  • Baixe o cenário do laboratório. Este cenário implementa a rede acima.
  • Execute o cenário;
  • Entre no roteador C e faça um teste básico de conectividade:
traceroute 172.10.10.1
  • Entre em A e observe a tabela de roteamento com:
route -n

Qual a métrica colocada para rede X?

  • Observe a saída de pacote pelas interface eth1 de A:
tcpdump -i eth1 -v -s 1000 src 172.20.20.2

Qual métrica é divulgada para a rede X? Quem é o next-hop? Para qual endereço IP é divulgada a rota?

  • Entre no roteador E e observe como ele instala a rota para X. Qual a

métrica instalada e qual o gateway de encaminhamento?

  • Observe a saída de pacotes na interface eth0 de E:
tcpdump -i eth0 -v -s 1000 src 172.20.20.1

Por que X NÃO é divulgada nesta interface?

  • Verifique com tcpdump como X é divulgado na interface eth1 de E. Qual

métrica?

  • Entre em B. Teste a conectividade e rota para X e verifique a tabela de

roteamento e a métrica para X;

  • Escute os pacotes em eth1 com src B (172.40.40.1);

Qual métrica é divulgada para X?

  • Entre em C e escute pacotes recebidos e transmitidos na interface 1.

Observe pacotes que saem para B e que chegam de B. Qual a métrica que B publica X?

Observando o envenenamento de rota e o trigger update

  • Coloque o tcpdump na interface eth0 de B. Fique observando as divulgações da rede X.
tcpdump -i eth0 -v -s 1000 src 172.60.60.2
  • Entre no roteador E se posicione para a realização de shutdown da interface eth0:
vtysh
conf t
interface eth0

Observe que E vai sentir a queda de eth0 e envenenar a rota de imediato
  • Realize o shutdown:
shutdown

Observe que existe um envenemamento de rota e a informação se propaga quase que imediatamente (trigger update). Olhe em particular para B e C;

  • Restaure a interface novamente e observe novamente:
no shutdown
  • Refaça o shutdown em E mas agora na interface eth1. Observe que a restauração de rotas deve demorar mais neste caso. Por que?
  • Finalmente, observe que em /var/tmp/ripd.log ficam armazenados eventos e mensagens trocadas no RIP.

DESAFIO

Com relação a rede dos exercícios anteriores faça a seguinte:

  • Acrescente um roteador entre D4 e D5. Este roteador ficará a meia distância de X com relação as duas opções de caminho. Faça um tcpdump de cada interface e mostre que este roteador recebe rota para X dos dois lados (por que?). Qual rota é escolhida e por que?
  • Desligue e ligue a interface que conecta X ao roteador A. Olhando nos arquivos de log mostre qual foi o último roteador que aprendeu a rota para X e quanto tempo isto demorou;
  • Discuta o que acontece se a interface eth1 de E for passiva;

Envie o cenário para o professor e documente as repostas aos exercícios através de um breve relatório mostrando saídas de log, tcpdump e tabelas de roteamento.

Disponível em “https://wiki.sj.ifsc.edu.br/index.php?title=RCO3-2013-2-CST_Redes_de_Computadores_3_-_CST&oldid=60051”