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

De MediaWiki do Campus São José
Ir para: navegação, pesquisa
(Aula 6 - Continuação)
(Material de Referência para o IP Móvel)
 
(39 revisões intermediárias por 6 usuários não estão sendo mostradas)
Linha 283: Linha 283:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
= Aula 7 - 18/8/2013 =
+
=Aula 7 - 25/8/14 (PARTE 2)-  =
 +
 
 +
==Objetivos==
 +
 
 +
Implementação Desafio/Defesa do Desafio 1
 +
 
 +
= Aula 8 - 1/9/2013 =
  
 
==Objetivos==
 
==Objetivos==
Linha 291: Linha 297:
 
-Discutir problema de contagem infinita e uma solução: reverso envenenado;
 
-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:
 +
* [[Media:Aula2-DistanceVector.pdf]]
 +
 
 +
Desafio a ser entregue: tabela de cálculo de vetor de distância do exercício proposto no doc acima.
 +
 
 +
= Aula 9 - 8/9/2013 (continuação) =
 +
 
 +
==Objetivos==
 +
 
 +
-Apresentar o algoritmo vetor de distância;
 +
 
 +
-Discutir problema de contagem infinita e uma solução: reverso envenenado;
  
 
== Desenvolvimento da Aula ==
 
== Desenvolvimento da Aula ==
Linha 299: Linha 318:
  
 
Desafio a ser entregue: tabela de cálculo de vetor de distância do exercício proposto no doc acima.
 
Desafio a ser entregue: tabela de cálculo de vetor de distância do exercício proposto no doc acima.
 +
 +
= Aula 9A - Esta aula não repassada =
 +
 +
==OBJETIVOS DA AULA==
 +
 +
#Apresentar o software Quagga;
 +
#Explorar a forma como a a tabela de roteamento é atualizada no Linux;
 +
#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.
 +
 +
[[imagem:EstruturaZebra.png|300px]]
 +
 +
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
 +
 +
* [http://www.quagga.net Link para a página do Quagga]
 +
 +
Confira aqui com amis detalhes como o zebra trabalha com o Linux e as diferenças entre os termos RIB e FIB:
 +
 +
* [http://etutorials.org/Networking/Integrated+cisco+and+unix+network+architectures/Chapter+8.+Static+Routing+Concepts/Route+Caches+Routing+Tables+Forwarding+Tables+and+the+ISO+Context/ Cap.8 do Guia de Integração de Roteamento das Arquiteturas Linux-Cisco]
 +
 +
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:
 +
 +
* [http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094702.shtml ICMP redirects]
 +
 +
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!
 +
* [http://www.sj.ifsc.edu.br/~eraldo/RCO3/LabQuaggaRotasEstaticas.tar.gz 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:
 +
 +
[[imagem:Fig1Lab3.png|800px]]
 +
 +
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
 +
 +
[[Image: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 10 - 15/09/2014 - 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.
 +
 +
 +
[[Image: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 : [http://www.sj.ifsc.edu.br/~eraldo/RCO3/LabRipBasico.tar.gz Laboratório RIP básico]
 +
 +
 +
[[Image: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. Force através de rota estática, uma rota de H2 para H1 passando por SN6, SN5 e SN2.
 +
 +
[[Image: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
 +
 +
=AULA 10 -  - 15/09/2014  - Preparação para Avaliação 1=
 +
 +
==Exercícios==
 +
 +
Fazer em dupla:
 +
 +
* [[Media:Aula6-ExerciciosAvaliacao1.pdf | Lista de Exercícios]]
 +
 +
=AULA 11 - 22/9/2014 - Avaliação 1=
 +
 +
=AULA 12 - 29/9/2014 - (7h30) - Desenvolvimento Desafio RIP=
 +
 +
=AULA 13 - 29/9/2014 - (9h40) - Desenvolvimento Desafio RIP (cont)=
 +
 +
=AULA 14 - 6/10/2014 - (7h30) - Laboratório Avançado RIP=
 +
 +
===OBJETIVOS DA AULA===
 +
 +
*Explorar características avançadas do RIP;
 +
 +
===CARACTERÍSTICAS AVANÇADAS DO RIP===
 +
 +
====''Timers''====
 +
 +
Na prática existem 4 ''timers'':
 +
 +
{| border="1" cellpadding="2"
 +
!''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.
 +
 +
[[Image: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'' [http://en.wikipedia.org/wiki/Split_horizon_route_advertisement][http://technet.microsoft.com/en-us/library/cc940478.aspx]====
 +
 +
É 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).
 +
 +
=== Observando Tabelas de Roteamento, Métricas e Publicações de Rota ===
 +
 +
Seja a seguinte Rede:
 +
 +
[[Image:RedeRIP.png]]
 +
 +
Durante o experimento estaremos focando a rede X de prefixo 172.10.10.0/24.
 +
 +
 +
*Baixe o [http://www.sj.ifsc.edu.br/~eraldo/RCO3/LabAvancadoRIP.tar.gz 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 (ver flags [http://www.thegeekstuff.com/2012/05/route-flags/]):
 +
 +
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
 +
 +
OBS: é possível capturar pacotes para o wireshark:
 +
 +
tcpdump -i eth0 -v -s 1000 src 172.60.60.2 -w capture.cap
 +
 +
*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.
 +
 +
==Aula 15==
 +
 +
==Aula 16==
 +
 +
==Objetivos==
 +
 +
Após a aula, o aluno deverá ser capaz de:
 +
 +
*Enumerar as características básicas do protocolo OSPF;
 +
*Configurar uma rede simples com uma única área usando o protocolo OSPF.
 +
 +
==Características do OSPF==
 +
 +
*Projetado para uso intradomínio (''Interior Gateway Protocol''), em domínios de grande tamanho;
 +
*Descrito na rfc 2328;
 +
* Detecta mudanças na topologia, tais como falhas em ''links'', de forma muito rápida e converge para um roteamento livre de ''loops'' em segundos;
 +
*Permite a construção de hierarquia de subdomínios (áreas);
 +
*Usa o algoritmo de estado de enlace de Dijkstra. Cada roteador possui o mapa completo da rede;
 +
*Suporta VLSM e CIDR;
 +
*Possui dois sub protocolos: o protocolo ''Hello'' para estabelecimento de relações de vizinhança e um protocolo para sincronização de base de dados de roteamento;
 +
*Não utiliza a camada de transporte. Usa diretamente a camada IP (protocolo 89);
 +
*Usa ''multicast'' no processo de ''flooding'';
 +
*Segurança: todas mensagens OSPF autenticadas (para impedir intrusão maliciosa);
 +
 +
==Princípios do Protocolo==
 +
 +
O protocolo OSPF segue o funcionamento básico de um protocolo ''link state'' que é:
 +
*Cada roteador em uma rede (subnet) envia mensagens de ''Hello'' para seus ''links'' locais e escuta por ''Hellos'' para descobrir quem são os seus roteadores vizinhos;
 +
*Cada roteador envia um anúncio identificando a si próprio, os ''links'' a ele diretamente conectados e os roteadores vizinhos a ele conectados diretamente;
 +
*Cada roteador recebe os anúncios e mantém uma cópia dos mesmos em uma base de dados (RIB). Ele também  encaminha o anúncio para seus vizinhos nos outros enlaces (''flooding'');
 +
*Quando um roteador possui uma cópia dos anúncios de cada um dos roteadores de toda a rede então ele pode calcular as rotas para os vários destinos, escolher as melhores rotas e estabelecê-las na FIB (''Forwarding Information Database'').
 +
 +
Quando o protocolo atinge a estabilidade, cada roteador possui a informação completa da topologia da rede. Ter o conhecimento da rede implica em poder evitar ''loops'' que podem acontecer nos protocolos de vetor de distância.
 +
 +
Os mecanismos básicos envolvidos no OSPF são:
 +
*Adjacências: dois roteadores ''link state'' se autodescobrem e entram em acordo para a troca de informações de roteamento. Nem todos os vizinhos formam adjacências.
 +
*''Flooding'': a informação de estado de enlace é encaminhada de forma confiável para todos os roteadores da rede;
 +
*A base de dados ''link state'' (LSDB): onde a informação de roteamento é armazenada e mantidada de forma acurada;
 +
*O cálculo do SPF: usando a RIB o algoritmo determina quais rotas serão estabelecidas.
 +
 +
==Custo no OSPF==
 +
 +
O custo ou métrica de uma interface no OSPF é o custo para enviar pacotes através da interface, Este custo é inversamente proporcional a banda disponibilizada pela interface e é dado por:
 +
 +
<math>Custo=10^8/banda(bps)</math>
 +
 +
Exemplo: Para ethernet 10Mbps é <math>10^8/10^7</math>.
 +
 +
Nota: É possível forçar um valor de custo para um determinado enlace.
 +
 +
==LSA-Link State Advertisement==
 +
 +
  Você pode imaginar um enlace como uma interface do roteador.
 +
  O estado de enlace é uma descrição da interface e de como ela está ligada com roteadores vizinhos.
 +
  A descrição pode incluir, por exemplo, o endereço e máscara da interface, o tipo de rede na qual ela está
 +
  conectada, os roteadores que estão conectados a esta rede etc.
 +
  O conjunto de todos os estados de enlace formam a base de dados de estado de enlace.
 +
 +
Os anúncios realizados pelos roteadores envolvem 5 tipos de mensagens de anúncio de estado de ''link'', chamados de LSAs.
 +
 +
De forma geral um ''header'' de um LSA contém as seguintes informações:
 +
*LS Type: Define o tipo de LSA. Existem cinco mais comuns:
 +
**Router LSA (code = 1)
 +
**Network LSA (code = 2)
 +
**Network Summary LSA (code = 3)
 +
**AS Border Router (ASBR) Summary LSA (code = 4)
 +
**AS External LSA (code = 5);
 +
 +
*Link State ID: Identificador do Link State. Seu valor depende do campo ''LS Type'':
 +
 +
{| border="1" cellpadding="2"
 +
!LS Type
 +
!Link State ID
 +
|-
 +
|1 (router LSA)
 +
|O Router ID do roteador que origina o LSA.
 +
|-
 +
|2 (network LSA)
 +
|Endereço IP da interface do Roteadore Designado;
 +
|-
 +
|3
 +
|Endereço IP da rede de destino;
 +
|-
 +
|4
 +
|O Router ID do roteador de borda descrito;
 +
|-
 +
|5
 +
|Endereço IP da rede de destino.
 +
|}
 +
 +
*''Advertising Router'': Especifica o  ''Router ID'' do roteador originador. Igual ao ''Link State ID'' no caso do ''LSA Router'';
 +
*''LS sequence number'': número de 32 bits usado para deteccar duplicações de ''LSA''. Incrementado cada vez que um roteador gera uma nova instância de LSA;
 +
 +
Nesta primeira aula vamos focar na mensagem ''Router LSA'' e ''Network LSA''. Esta mensagem é enviada por cada um dos roteadores de uma área de um domínio OSPF. Estas mensagens são retransmitidas pelos roteadores vizinhos de forma que se propagam por toda a área.
 +
 +
Um ''Router LSA'' traz informações sobre os vários ''links'' conectados ao roteador e seus respectivos custos. Ele é composto pelo ''header'' identificando o roteador que gera o ''LSA'' e uma sequência de descritores de ''link''. Um ''Router LSA'' é único para um roteador dentro de uma área específica.
 +
 +
Um ''Network LSA'' é gerado por uma rede trânsito, dentro de uma área. O roteador responsável pela geração destes ''LSA'' é um roteador designado. A idéia do ''Network LSA'' é de que se existem N roteadores ligados a uma rede com múltiplo acesso (exemplo, ''ethernet'') então N-1 roteadores da rede trocam informações somente com um roteador, o roteador designado e este por sua vez divulga a rede com todos os roteadores que estão ligados a ela.
 +
 +
Uma rede trânsito é aquela por onde circulam pacotes cuja origem E destino não são endereços da rede.
 +
Uma rede trânsito possui múltiplos roteadores ligados a ela.
 +
 +
Uma rede stub é aquela por onde circulam pacotes que se originam ou destinam a ela. Possui um único roteador
 +
ligado a ela (a não ser em casos particulares onde links ponto a ponto são virtualmente criados).
 +
 +
==Base de Dados de Roteamento==
 +
 +
Um roteador mantém uma base de dados de estado de enlace separada para cada área a que pertence. TODOS os roteadores que pertencem a uma mesma área possuem a mesma base de dados. O cálculo de caminho mais curto é realizado por área.
 +
 +
==Laboratório ETAPA 1 - Configuração Básica do OSPF no QUAGGA/Zebra==
 +
 +
Da mesma forma que o ''ripd'', o ''ospfd'' é iniciado após o ''zebra'' e um arquivo de configuração é repassado para o mesmo.
 +
 +
Os passos a seguir são:
 +
 +
*Baixe o [http://www.sj.ifsc.edu.br/~eraldo/RCO3/LabOSPFbasico.tar.gz cenário]  e descompacte-o:
 +
*Execute o cenário e teste a conectividade:
 +
 +
[[imagem:Fig1Lab3.png|800px]]
 +
Cenário do exercício
 +
 +
obs: ERRO NA FIGURA: endereço do roteador R1 é 200.10.10.3/24 na eth0
 +
 +
*Entre no roteador R1 e verifique a tabela de roteamento para a rede 200.10.20.0. Qual é a métrica e por que?
 +
*Faça um vtysh em R1 e verifique quantos router LSA e network LSA existem na base de dados. Explique estes números. Identifique também qual é o Router ID de R1:
 +
 +
show ip ospf database
 +
 +
*Observe os routers LSAs de R1.  observe o cabeçalho do router LSA associado ao R1 e identifique: o LS type, Link State ID o LS sequence.
 +
 +
show ip ospf database router
 +
 +
*Ainda no router LSA associado a R1 identifique o número de links informados e quais são os (Link ID e Link Data) de cada um deles.
 +
 +
*Ainda em R1 identifique a network LSA. Verifique o header deste LSA: identifique o LSA type, o Link State ID e o Advertising Router;
 +
 +
*Ainda olhando a network LSA diga quais roteadores estão ligados na rede;
 +
 +
*Usando o tcpdump identique o número do protocolo usado para identificar o OSPF. Qual protocolo de transporte o OSPF utiliza?
 +
 +
==Desafio==
 +
 +
Implemente a rede abaixo usando o OSPF.
 +
 +
[[imagem:RCO3-RedeSimplesOSPF.jpg|800px]]
 +
 +
 +
* Compare as bases de dados de todos os roteadores. Elas são iguais? Por que?
 +
* Examine cada ''Router ID'' de cada roteador da rede. É possível inferir um critério foi usado para escolha deste ID?
 +
* Foque em um roteador e responda quantos ''router LSAs'' existem? Quem os originou?
 +
* Quantos ''network LSA'' existem? Quem os originou?
 +
* Acrescente um roteador ligado a uma rede stub na rede 200.200.2.0/29. Configure o OSPF e veja o que é alterado na base de dados do OSPF;
 +
 +
==Material de apoio==
 +
 +
* [http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml Link para Material da CISCO]
 +
* [http://blog.initialdraft.com/archives/1046/]
 +
* [http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094202.shtml#topic1]
 +
* [http://openmaniak.com/quagga_case2.php]
 +
* [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=7&ved=0CGsQFjAG&url=http%3A%2F%2Fwww.nanog.org%2Fmeetings%2Fnanog17%2Fpresentations%2Fospf.ppt&ei=qdX1T73rCIrZ6wH0z4zLBg&usg=AFQjCNEuiWk44DlBuK1_L4IKNQiIpvNtlw&sig2=SNAYktuc_VVZ-PrwIVQtHQ]
 +
* [http://wiki.mikrotik.com/wiki/Manual:OSPF-examples]
 +
* [http://pktmaniac.info/2010/10/understanding-the-ospf-network-lsa-type-2-2/]
 +
* [http://fengnet.com/book]
 +
* https://supportforums.cisco.com/community/netpro/network-infrastructure/switching/blog/2013/06/19/how-to-build-the-topology-of-an-ospf-area
 +
 +
 +
==Aula 17 -  13/10/2015 (10h) ==
 +
 +
===OBJETIVOS===
 +
 +
*Revisar o protocolo RIP
 +
*Dividir e distribuir trabalhos de roteamento em redes Adhoc.
 +
 +
===Questionário RIP===
 +
 +
1. Qual o tipo de algoritmo implementado pelo RIP. Qual é a idéia básica deste algoritmo?
 +
 +
2. O RIPv1 não suporta VLSM enquanto a versão 2 suporta. O que é VLSM e o que o RIPv2
 +
deve transportar adicionalmente ao prefixo da rede publicada?
 +
 +
3. Qual é a métrica utilizada pelo RIP?
 +
 +
4. Qual protocolo é utilizado para o transporte da informação RIP?
 +
 +
5. O pacote RIP possui um campo de comando. Qual o significado dos comandos RQ e RP?  Explique.
 +
 +
6. O pacote RIPv2 possui um conjunto de campo de 20 bytes para a definição de rota. Explique o significado dos campos desta área, exemplificando o uso do campo NEXT HOP.
 +
 +
7. Quantas rotas podem ser colocadas em um pacote RIPv2.
 +
 +
8. Explique o que é o problema de convergência lenta (ou count to infinity) nos protocolos de vetor de distância e a solução parcial através do split horizon. Como é possível habilitar/desabilitar o split horizon no RIP/Quagga?
 +
 +
9. Explique o que é o holdown timer? É possível modificar o valor deste timer no RIP/Quagga?
 +
 +
10. O RIPv1 não suporta autenticação enquanto o RIPv2 suporta. Explique qual o problema que pode  ocorrer  no  RIPv1  pelo  fato  de  ele  não  possuir  autenticação  e  como  funciona  o  mecanismo de autenticação no RIPv2?
 +
 +
11. O RIPv1 se utiliza de broadcast para divulgação de rotas enquanto o RIPv2 usa ''multicast''. Qual a vantagem deste último sobre o primeiro? Explique.
 +
 +
===Referências===
 +
 +
* [http://www.sj.ifsc.edu.br/~eraldo/RCO3/RIP.pdf Slides RIP de Portugal]
 +
* [http://www.sj.ifsc.edu.br/~eraldo/RCO3/nt01100.pdf Material Profa.Tarouco]
 +
* [http://tools.ietf.org/html/rfc2453 rfc2453]
 +
 +
==Aula 18 -  20/10/2015 (7h30) ==
 +
 +
===Objetivos===
 +
 +
Finalização e Avaliação de desafios anteriores
 +
 +
==Aula 19 -  21/10/2015 (10h) ==
 +
 +
Continuação desafio OSPF
 +
 +
==Aula 20 - 03/11/2014 - 7h30 ==
 +
 +
===Objetivos===
 +
 +
*Apresentar o conceito de áreas com OSPF;
 +
*Construir um domínio (sistema autônomo) OSPF com áreas;
 +
*Apresentar os LSAs do tipo ''summary''.
 +
 +
===OSPF Hierárquico===
 +
 +
No OSPF é possível dividir um domínio em '''áreas'''. Todo o domínio deve ter, no entanto, um ''backbone'' que é a '''área 0'''. Todas as demais áreas são conectadas somente a área 0. Esta é uma regra geral de projeto da rede: uma topologia livre de ''loops''.
 +
  O papel do ''backbone'' é retransmitir um ''resumo'' (sumário) das redes de uma área para outra.
 +
 +
Uma área possui um identificador de 32 bits com representação semelhante a um endereço IP.
 +
 +
A construção de áreas permite reduzir o tamanho das bases de dados de estado de enlace, reduzindo o impacto do processo de ''flooding'' bem como o peso de processamento do algoritmo ''Shortest Path''.
 +
 +
====Classificação de Roteadores====
 +
 +
Os tipos de roteadores no OSPF são:
 +
*'''Roteadores de Borda de Área''': sumariza distâncias às redes na sua própria área e anuncia a outros roteadores de fronteira de área;
 +
*'''Roteadores Internos''': são roteadores internos a uma área;
 +
*'''Roteadores de ''backbone''''': pertencem a área 0 (''backbone'') e realizam roteamento OSPF limitado ao ''backbone''.
 +
*'''Roteador de Borda de AS''' (Sistema Autônomo):localizados na área 0 com conectividade a outros ASs. Usados para troca de informações com outros ASs, por exempĺo, com o protocolo BGP;
 +
 +
OS roteadores de borda de área geram ''Network Summary LSAs'' para dentro de suas áreas. Estes LSAs permitem divulgar redes de destino externas (prefixos de redes IPs) a uma área.
 +
 +
 +
[[imagem:RCO3-TiposRoteadores.png|800px]]
 +
 +
Network Routing - Deepankar Medhi
 +
 +
Hierarquia OSPF e tipo de roteadores
 +
 +
====Considerações sobre Network LSAs em uma área====
 +
 +
É importante lembrar que o ''network LSA'' é um estado de enlace associado a uma rede multiponto da rede. Quem representa esta rede é o '''roteador designado''' (DR). As seguintes considerações devem ser observadas:
 +
 +
*Um ''network LSA'' associado a uma determinada rede é originado por um roteador designado (DR). O formato deste LSA é mostrado na figura abaixo;
 +
*O prefixo da rede IP indicado pelo ''network LSA'' é determinado da seguinte forma. O campo ''Link State ID'' indica o endereço IP do DR na rede. O campo ''network mask'' informa a máscara da rede. Estas duas informações determinam o endereço IP da rede;
 +
Um network SLA é propagado (''flooding'') somente na área onde se encontra a rede multi-acesso.
 +
 +
[[imagem:RCO3-NetworkSLA.png|600px]]
 +
Formato de um Network LSA
 +
 +
====Considerações sobre os ''Summary LSAs''====
 +
 +
Estes LSAs podem ser do tipo 3 e 4. O tipo 3 descreve rotas para redes de uma determinada área e são propagados pelo ''backbone'' 0. O tipo 4 descreve rotas para roteadores ASBRs. As seguintes considerações se aplicam:
 +
 +
*Os ''summary LSAs'' são originados por roteadores de borda de área. Um LSA é criado para cada rede da área e propagado pelo ''backbone'';
 +
*Somente rotas intra-área são divulgados no ''backbone'';
 +
*Os roteadores de borda de área repassam os ''summary LSAs'' recebidos através do ''backbone'' e os repassam para dentro das áreas as quais estão conectados;
 +
*O Link State ID do ''Summary LSA'' tipo 3 é o endereço IP da rede publicada.
 +
 +
O formato do ''summary LSA'' é mostrado na Figura a seguir:
 +
 +
[[imagem:RCO3-SummarySLA.png|600px]]
 +
Formato de um ''Summary SLA''
 +
 +
===Laboratório - Construção de um domínio OSPF com áreas===
 +
 +
====PARTE 1 – Construindo o cenário====
 +
 +
Considere a rede indicada na Fig.abaixo. Baixe o [http://www.sj.ifsc.edu.br/~eraldo/RCO3/LabOSPFareas.tar.gz laboratorio]. Este cenário coloca em execução as áreas 0 e 1 e parte da área 2 (somente R4). Teste a conectividade das redes envolvidas.
 +
 +
[[imagem:RCO3-RedeOSPFcomAreas.png|600px]]
 +
 +
Domínio OSPF
 +
 +
====PARTE 2 – Colocando o  OSPF em operação em todas as áreas====
 +
 +
* Observe os arquivos de configuração ospf.conf  e zebra.conf das áreas 0 e 1 e
 +
configure a área 2. Por exemplo, fazendo um vtysh no R1, podemos olhar os arquivos de configuração do zebra e do ospf para
 +
R1. O ospfd.R1.conf deve se apresentar da forma:
 +
 +
  hostname R1
 +
  password R1
 +
  enable password R1
 +
  router ospf
 +
  network 30.0.0.0/8 area 0
 +
  network 11.0.0.0/8 area 1
 +
  log file ospfd.log
 +
 +
NOTA: O comando '''network <endereço IP> area''' habilita o OSPF na interface com o endereço indicado!
 +
 +
 +
*Construa um arquivo de configuração do zebra e do ''ospf'' para cada roteador da área 2, armazenado-o no diretório correspondente a cada roteador.. Exemplo: para o roteador R3 chamar de ospfd.R3.conf. Em cada arquivo coloque a informação, adaptando-a ao roteador:
 +
 +
 +
* Colocar nos arquivos de startup a execução dos deamons dos roteadores:
 +
zebra -d
 +
ospfd -d -f nome_arquivo_configuração
 +
 +
*Teste com o ping a conectividade em toda a rede.
 +
 +
====PARTE 3 – Examinando os estados dos roteadores internos na área 1====
 +
 +
* Entre no roteador R3 verifique o estado da tabela de roteamento. Como estão colocadas as rotas para as redes na área 0 e 1? Qual a métrica para a rede 21.0.0.0/24?
 +
* Ainda no roteador R3, entre com vtysh e verifique quais tipos de LSAs estão aparecendo.
 +
show ip ospf database
 +
*Ainda em R3 liste com detalhes os summary LSAs .
 +
show ip ospf database summary
 +
 +
Quem divulga os summary LSAs na área 1? A que corresponde cada um dos summary LSA?
 +
 +
* Verifique a ''database'' do OSPF no roteador R2. Ela é igual ao R3? Por que?
 +
 +
Observe que o LINK STATE ID em cada LSA é:
 +
 +
* No '''Router LSA''': o Router ID do roteador que originou o LSA;
 +
* No '''Network LSA''': o endereço IP do roteador designado associado a rede divulgada (pseudo-nó);
 +
* No '''Summary LSA''': Prefixo da rede divulgada, portanto deve existir um LSA para cada rede divulgada;
 +
 +
====PARTE 4 – Examinando os estados dos roteadores de borda de área====
 +
 +
* Entre no roteador R1 com ''vtysh'' e verifique a base de dados do OSPF. Qual é a diferença em relação ao roteador R3?
 +
* Compare as bases de dados de R1 e de R4 e verifique quais são as diferenças.
 +
 +
===DESAFIO===
 +
 +
Implemente um roteador de borda de área adicional entre a  área 0 e 1. Conecte-o de um lado na área 0 e no outro a rede 12.0.0.0/24.  Analise as bases de dados do OSPF nos roteadores internos da área 1 e, se houve alguma alteração, explique. Enviar o cenário e um pequeno relatório para o professor. Mostre através do traceroute qual a rota seguida para a fonte H1 e destino H2.
 +
 +
==Aula 21 03/11/2014 ==
 +
 +
===OBJETIVOS===
 +
 +
*Implementar o desafio;
 +
*Distribuição de Trabalhos;
 +
*Questionário de fixação sobre o protocolo OSPF.
 +
 +
===Questionário OSPF===
 +
 +
1.Quais são os tipos de roteadores no ponto de vista do OSPF? (pg.28 RFC, pg.29 slides)
 +
 +
2.Qual a definição de redes ''broadcast'' e ''não broadcast'' apresentado pela RFC do OSPF? (pg.9 RFC)
 +
 +
3.O que é o router ID, como ele é escolhido e qual é o seu escopo? (pg.8 RFC, pg.13 slides)
 +
 +
4.Faça um sumário da execução do OSPF (pg. 40 da RFC, pg. 37 slides);
 +
 +
5.Quais os 3 subprotocolos do OSPF? (pg.35 slides);
 +
 +
6.Como é calculado o custo nos links das redes OSPF? (material da CISCO);
 +
 +
7.Explique a diferença entre vizinhança e adjacência (material da CISCO);
 +
 +
8.Explique o que é um roteador designado, um roteador designado de backup e como é o processo para eleição deste roteador;(material da CISCO);
 +
 +
9.O que é o processo de sincronização de base de dados no OSPF e quando ela ocorre? (pg 53 RFC, pg 37 slides)
 +
 +
10.Quais as mensagens que são utilizadas no OSPF. Explique brevemente cada uma delas. (pg 38);
 +
 +
11.O que é o processo de flooding? (pg.16 e 37 slides)
 +
 +
12.Enumere e explique os 5 principais tipos de LSAs no OSPF. (pg. 44 RFC, slides 64 e 65)
 +
 +
13.Explique o que é a base de dados de estado de enlace do OSPF? (pg 17 slides)
 +
 +
14.Qual protocolo de transporte que é utilizado pelo OSPF?
 +
 +
15.Explique o que é um link virtual no OSPF? (material da CISCO)
 +
 +
16.Explique o que é um Link ID no contexto do Router LSA. (pg.208 RFC)
 +
 +
17.Explique o que é uma área, um área ID no contexto OSPF e quais as vantagens na divisão de um sistema autônomo em área; (pg 11 slides)
 +
 +
18.Explique como se dá o processo de sumarização de rotas entre áreas. Dê um exemplo. (Material da CISCO);
 +
 +
19.Diferencie áreas stub de áreas trânsito? (pg 67 slides)
 +
 +
===Material de Referência===
 +
 +
* [http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml Link para Material da CISCO]
 +
* [http://tools.ietf.org/pdf/rfc2328.pdf  RFC2228 ]
 +
* [http://www.deetc.isel.ipl.pt/redesdecomunic/disciplinas/RI/acetatos/Routing%20OSPFv2.pdf Slides Portugal]
 +
* [http://www.inf.ufes.br/~zegonc/material/S.O.%20II/Protocolo%20OSPF.pdf Slides Prof.José Gonçalves]
 +
* [http://blog.ccna.com.br/2008/06/27/tutorial-ospf-parte-5/ Blog ccna]
 +
 +
 +
Respostas
 +
<!--
 +
1.
 +
*roteador interno: está diretamente conectado somente a redes de uma mesma área.
 +
*roteador de borda de área: está diretamente conectados a redes que pertencem a diferentes áreas.
 +
*roteador de backbone: está diretamente conectado ao backbone (a uma rede do backbone). Note que por esta classificação, inclui também os roteadores de borda de área.
 +
*roteador de borda de domínio: um roteador que troca informações de roteamento com outros domínios. Note que por esta definição, este roteador pode ser interno e nem mesmo estar ligado ao backbone.
 +
 +
2.
 +
*redes broadcast: são redes cuja tecnologia permite interligar mais do que dois roteadores e que possui capacidade de realizar broadcast de mensagens. Exemplo: rede ethernet. O protocolo Hello funciona perfeitamente nestas redes.
 +
*redes não broadcast:são redes cuja tecnologia permite interligar mais do que dois roteadores mas que não possui capacidade de realizar broadcast de mensagens. Exemplo: X.25, frame-relay. ATM. Neste caso, o OSPF deve ser informado para que possa executar o protocolo Hello de forma correta. Dois modos de funcionamento são previstos para estas redes: NBMA (non broadcast multiple access) e ponto-para-multiponto. No primeiro, o OSPF simula a execução do broadcast enquanto no segundo ele trata o enlace como múltiplos ponto-a-ponto.
 +
 +
3.
 +
*É um número de 32 bits atribuído a cada roteador de um domínio OSPF (AS) e que é único no sistema autônomo.
 +
 +
4. Sendo um protocolo de estado de enlace, cada roteador OSPF enxerga a topologia de toda a área a qual pertence e executa uma instância do algoritmo de menor custo para esta topologia. Se o roteador pertence a várias áreas então ele executa o algoritmo para cada topologia de cada área.
 +
Quando ligado,  o protocolo inicia suas estruturas de dados e aguarda que os protocolos de níveis inferiores informem que as interfaces estejam operacionais.
 +
 +
O roteador passa então a executar o protocolo Hello para reconhecer os seus vizinhos. Em redes broadcast ou enlaces ponto a ponto este reconhecimento é dinâmico.
 +
através do uso de mensagens broadcast. Nas demais redes é necessário configuração adicional. Em redes broadcast e NBMA são eleitos roteadores designados.
 +
 +
Os roteadores conhecendo seus vizinhos, tentam formar adjacências. Roteadores adjacentes trocam informações de atualização de rotas. Em redes broadcast e NBMA, os roteadores designados determinam quem forma adjacência.
 +
 +
-->
 +
 +
==Aula Dia 13/11/2014==
 +
 +
===OBJETIVOS===
 +
 +
#Iniciar o estudo do protocolo BGP, apresentando as suas características básicas;
 +
#Realizar um laboratório de BGP focando o anúncio simples de redes e a verificação do atributo AS_PATH.
 +
 +
===ROTEIRO DA AULA===
 +
 +
* [http://www.sj.ifsc.edu.br/~eraldo/RCO3/Aula13-LabProtocoloBGP.pdf Roteiro da Aula BGP]
 +
 +
===SLIDES NETKIT DO LABORATÓRIO DE ANÚNCIOS DE ROTA DO BGP===
 +
 +
* [http://www.netkit.org/netkit-labs/netkit-labs_interdomain-routing/netkit-lab_bgp-announcement/netkit-lab_bgp-announcement.pdf Slides Anúncio Rota BGP]
 +
 +
===DOWNLOAD DO LABORATÓRIO NETKIT DE ANÚNCIOS DE ROTA===
 +
 +
* [http://www.netkit.org/netkit-labs/netkit-labs_interdomain-routing/netkit-lab_bgp-announcement/netkit-lab_bgp-announcement.tar.gz Download Lab.Anúncios Rota]
 +
 +
===MATERIAL DA CISCO SOBRE BGP===
 +
 +
* [http://docwiki.cisco.com/wiki/Border_Gateway_Protocol BGP-Material Cisco]
 +
* http://mdbrasil.com.br/en/downloads/BGP_Brasil_2010_Maia.pdf
 +
 +
===MANUAL DO QUAGGA SOBRE BGP===
 +
 +
* [http://www.quagga.net/docs/docs-info.php#SEC72 Manual Quagga BGP]
 +
 +
==Aula 17/11/2014 - PARTE 1==
 +
 +
===OBJETIVOS===
 +
 +
*apresentar filtros de anúncio no envio e na recepção;
 +
*Apresentar filtros por prefixo e por as-path no BGP;
 +
 +
===SLIDES DA AULA (experimento netkit) e experimento ===
 +
 +
*[http://www.netkit.org/netkit-labs/netkit-labs_interdomain-routing/netkit-lab_bgp-prefix-filtering/netkit-lab_bgp-prefix-filtering.pdf Slides Experimento Filtros]
 +
 +
*[http://www.netkit.org/netkit-labs/netkit-labs_interdomain-routing/netkit-lab_bgp-prefix-filtering/netkit-lab_bgp-prefix-filtering.tar.gz Link para experimento de Filtro com Netkit]
 +
 +
===Exemplos de filtros de caminhos com expressões regulares===
 +
 +
^200$  // refere-se a rotas originadas pelo 200 e que não passe por nenhum outro AS
 +
_200_  // refere-se a rotas que tenham passado pelo AS 200
 +
_300$  // refere-se a rotas que começam no AS 300
 +
.*    // Qualquer rota
 +
^200_[0-9]*$  // rotas originadas do AS 200 e provindas de um (e somente um) vizinho.
 +
 +
===DESAFIO===
 +
 +
#Considere o desafio da aula passada, em que foram inseridos os ASes 3,4 e 5. Acrescente uma interface adicional no roteador do AS1, configurando-a para acesso a uma rede 195.11.15.0/24. Publique esta rede através do BGP. Confira se o AS2 instala corretamente rota para esta rede.
 +
#Coloque um filtro por prefixo no AS2, na sua relação de peering com AS3, de forma a filtrar a rede 195.11.15.0/24. Em termos de rotas, o que muda no lado do AS2?
 +
#Retire o filtro por prefixo no AS2 e coloque um filtro por caminho, na relação de ''peering'' com AS3, para filtrar todas as redes anunciadas por AS3 e provindas de AS1.
 +
 +
===Bibliografia adicional===
 +
 +
http://raabadnetworking.blogspot.com.br/2011/05/bgp-regular-expressions-for-as-path.html
 +
 +
http://blog.ipspace.net/2008/02/as-path-based-filter-of-customer-bgp.html
 +
 +
 +
==Aula 17/11/2014 - PARTE 2==
 +
 +
===Desenvolvimento do Desafio===
 +
 +
==Aula 24/11/2014 - PARTE 1==
 +
 +
===Objetivos===
 +
 +
*Distribuição e início do projeto final;
 +
*Criação das wikis para os projetos;
 +
 +
===Topologias a serem Implementadas===
 +
 +
[[imagem:RCO3-TopologiasProjetoFinal-2014-2A.png|600px]]
 +
 +
[[imagem:RCO3-TopologiasProjetoFinal-2014-2B.png|600px]]
 +
 +
===Wikis dos Projetos===
 +
 +
[[Trabalho 1 - RCO3 - 2014-2 | Renato ]]
 +
 +
[[Trabalho 2 - RCO3 - 2014-2 | Giovanni ]]
 +
 +
[[Trabalho 3 - RCO3 - 2014-2 | Maciel ]]
 +
 +
[[Trabalho 4 - RCO3 - 2014-2 | Vinícius ]]
 +
 +
===Links de ferramentas e tutoriais===
 +
 +
[http://hostnet.com.br/wiki/index.php/Tutorial_MediaWiki  Tutorial wiki]
 +
 +
[http://www.vivaolinux.com.br/artigo/Dia-O-Editor-de-diagrama-%28Microsoft-Visio%29-para-Linux Instalação-Uso Editor Dia]
 +
 +
[http://lartc.org/howto/lartc.tunnel.gre.html Túneis GRE]
 +
 +
===Links adicionais sobre filtros com BGP===
 +
 +
[http://www.google.com.br/url?sa=t&rct=j&q=&esrc=s&source=web&cd=10&ved=0CG8QFjAJ&url=http%3A%2F%2Fpages.au.int%2Fsites%2Fdefault%2Ffiles%2Fmodule%252007%2520-%2520bgp%2520route%2520filtering%2520and%2520advanced%2520features.doc&ei=Zw9zVIjsNoScgwTr-4O4Aw&usg=AFQjCNEmzesWsZaa3YPXLerpiJnFe_lDfA&sig2=uooqGhYX9UBYqwJf2Ga6Hw&bvm=bv.80185997,d.eXY]
 +
 +
[http://www.networkgalaxy.org/2013/07/filtering-routes-in-bgp-using-route.html]
 +
 +
==Aula 24/11/2014 - PARTE 2==
 +
 +
Desenvolvimento do Projeto
 +
 +
==Aula 1/12/2014 - PARTE 1==
 +
 +
===Objetivos===
 +
 +
*Roteamento Multicast
 +
*IP Móvel
 +
 +
===Material de Referência para o Multicast===
 +
 +
*[http://www.cs.virginia.edu/~cs458/slides/module21-mcast.pdf Slides]
 +
*[http://www.comm.utoronto.ca/~jorg/teaching/itlab/pdf/Ch10_v1.pdf IP Multicast]
 +
*[http://www4.ncsu.edu/~rhee/export/papers/multi1.pdf Mbone]
 +
 +
===Material de Referência para o IP Móvel===
 +
 +
* [http://www.sj.ifsc.edu.br/~eraldo/RCO3/Aula22-IPmovel.pdf Roteiro da Aula IP Móvel]
 +
 +
* [http://www.sj.ifsc.edu.br/~eraldo/RCO3/Aula23-QuestionárioMIP.pdf Questionário MIP]
 +
 +
* [http://www.cisco.com/en/US/docs/ios/solutions_docs/mobile_ip/mobil_ip.html#wp1029197]

Edição atual tal como às 07h10min de 1 de dezembro de 2014

Índice

Cronograma

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

Aula 1 - 4/8/2014

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.

Lembrete:escolha de rota pelo prefixo mais longo

Prefixo Mais Longo

Calculador IP

Referências

Aula 2 - 4/8/2014 (Parte 2)

Desafio

Aula 3 -11/8/2014 (Parte 2)

Reapresentação da aula para os que haviam faltado


Aula 4 - 12/8/2014 (Parte 2)

Aula 5 - 18/8/2014

  • 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 6 - 25/8/14 - Continuação Estado Enlace

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 7 - 25/8/14 (PARTE 2)-

Objetivos

Implementação Desafio/Defesa do Desafio 1

Aula 8 - 1/9/2013

Objetivos

-Apresentar o algoritmo vetor de distância;

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

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 9 - 8/9/2013 (continuação)

Objetivos

-Apresentar o algoritmo vetor de distância;

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

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 9A - Esta aula não repassada

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 10 - 15/09/2014 - 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. Force através de rota estática, uma rota de H2 para H1 passando por SN6, SN5 e SN2.

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

AULA 10 - - 15/09/2014 - Preparação para Avaliação 1

Exercícios

Fazer em dupla:

AULA 11 - 22/9/2014 - Avaliação 1

AULA 12 - 29/9/2014 - (7h30) - Desenvolvimento Desafio RIP

AULA 13 - 29/9/2014 - (9h40) - Desenvolvimento Desafio RIP (cont)

AULA 14 - 6/10/2014 - (7h30) - Laboratório Avançado RIP

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][2]

É 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).

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 (ver flags [3]):
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

OBS: é possível capturar pacotes para o wireshark:

tcpdump -i eth0 -v -s 1000 src 172.60.60.2 -w capture.cap
  • 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.

Aula 15

Aula 16

Objetivos

Após a aula, o aluno deverá ser capaz de:

  • Enumerar as características básicas do protocolo OSPF;
  • Configurar uma rede simples com uma única área usando o protocolo OSPF.

Características do OSPF

  • Projetado para uso intradomínio (Interior Gateway Protocol), em domínios de grande tamanho;
  • Descrito na rfc 2328;
  • Detecta mudanças na topologia, tais como falhas em links, de forma muito rápida e converge para um roteamento livre de loops em segundos;
  • Permite a construção de hierarquia de subdomínios (áreas);
  • Usa o algoritmo de estado de enlace de Dijkstra. Cada roteador possui o mapa completo da rede;
  • Suporta VLSM e CIDR;
  • Possui dois sub protocolos: o protocolo Hello para estabelecimento de relações de vizinhança e um protocolo para sincronização de base de dados de roteamento;
  • Não utiliza a camada de transporte. Usa diretamente a camada IP (protocolo 89);
  • Usa multicast no processo de flooding;
  • Segurança: todas mensagens OSPF autenticadas (para impedir intrusão maliciosa);

Princípios do Protocolo

O protocolo OSPF segue o funcionamento básico de um protocolo link state que é:

  • Cada roteador em uma rede (subnet) envia mensagens de Hello para seus links locais e escuta por Hellos para descobrir quem são os seus roteadores vizinhos;
  • Cada roteador envia um anúncio identificando a si próprio, os links a ele diretamente conectados e os roteadores vizinhos a ele conectados diretamente;
  • Cada roteador recebe os anúncios e mantém uma cópia dos mesmos em uma base de dados (RIB). Ele também encaminha o anúncio para seus vizinhos nos outros enlaces (flooding);
  • Quando um roteador possui uma cópia dos anúncios de cada um dos roteadores de toda a rede então ele pode calcular as rotas para os vários destinos, escolher as melhores rotas e estabelecê-las na FIB (Forwarding Information Database).

Quando o protocolo atinge a estabilidade, cada roteador possui a informação completa da topologia da rede. Ter o conhecimento da rede implica em poder evitar loops que podem acontecer nos protocolos de vetor de distância.

Os mecanismos básicos envolvidos no OSPF são:

  • Adjacências: dois roteadores link state se autodescobrem e entram em acordo para a troca de informações de roteamento. Nem todos os vizinhos formam adjacências.
  • Flooding: a informação de estado de enlace é encaminhada de forma confiável para todos os roteadores da rede;
  • A base de dados link state (LSDB): onde a informação de roteamento é armazenada e mantidada de forma acurada;
  • O cálculo do SPF: usando a RIB o algoritmo determina quais rotas serão estabelecidas.

Custo no OSPF

O custo ou métrica de uma interface no OSPF é o custo para enviar pacotes através da interface, Este custo é inversamente proporcional a banda disponibilizada pela interface e é dado por:

Exemplo: Para ethernet 10Mbps é .

Nota: É possível forçar um valor de custo para um determinado enlace.

LSA-Link State Advertisement

 Você pode imaginar um enlace como uma interface do roteador. 
 O estado de enlace é uma descrição da interface e de como ela está ligada com roteadores vizinhos. 
 A descrição pode incluir, por exemplo, o endereço e máscara da interface, o tipo de rede na qual ela está
 conectada, os roteadores que estão conectados a esta rede etc. 
 O conjunto de todos os estados de enlace formam a base de dados de estado de enlace.

Os anúncios realizados pelos roteadores envolvem 5 tipos de mensagens de anúncio de estado de link, chamados de LSAs.

De forma geral um header de um LSA contém as seguintes informações:

  • LS Type: Define o tipo de LSA. Existem cinco mais comuns:
    • Router LSA (code = 1)
    • Network LSA (code = 2)
    • Network Summary LSA (code = 3)
    • AS Border Router (ASBR) Summary LSA (code = 4)
    • AS External LSA (code = 5);
  • Link State ID: Identificador do Link State. Seu valor depende do campo LS Type:
LS Type Link State ID
1 (router LSA) O Router ID do roteador que origina o LSA.
2 (network LSA) Endereço IP da interface do Roteadore Designado;
3 Endereço IP da rede de destino;
4 O Router ID do roteador de borda descrito;
5 Endereço IP da rede de destino.
  • Advertising Router: Especifica o Router ID do roteador originador. Igual ao Link State ID no caso do LSA Router;
  • LS sequence number: número de 32 bits usado para deteccar duplicações de LSA. Incrementado cada vez que um roteador gera uma nova instância de LSA;

Nesta primeira aula vamos focar na mensagem Router LSA e Network LSA. Esta mensagem é enviada por cada um dos roteadores de uma área de um domínio OSPF. Estas mensagens são retransmitidas pelos roteadores vizinhos de forma que se propagam por toda a área.

Um Router LSA traz informações sobre os vários links conectados ao roteador e seus respectivos custos. Ele é composto pelo header identificando o roteador que gera o LSA e uma sequência de descritores de link. Um Router LSA é único para um roteador dentro de uma área específica.

Um Network LSA é gerado por uma rede trânsito, dentro de uma área. O roteador responsável pela geração destes LSA é um roteador designado. A idéia do Network LSA é de que se existem N roteadores ligados a uma rede com múltiplo acesso (exemplo, ethernet) então N-1 roteadores da rede trocam informações somente com um roteador, o roteador designado e este por sua vez divulga a rede com todos os roteadores que estão ligados a ela.

Uma rede trânsito é aquela por onde circulam pacotes cuja origem E destino não são endereços da rede.
Uma rede trânsito possui múltiplos roteadores ligados a ela.
Uma rede stub é aquela por onde circulam pacotes que se originam ou destinam a ela. Possui um único roteador
ligado a ela (a não ser em casos particulares onde links ponto a ponto são virtualmente criados).

Base de Dados de Roteamento

Um roteador mantém uma base de dados de estado de enlace separada para cada área a que pertence. TODOS os roteadores que pertencem a uma mesma área possuem a mesma base de dados. O cálculo de caminho mais curto é realizado por área.

Laboratório ETAPA 1 - Configuração Básica do OSPF no QUAGGA/Zebra

Da mesma forma que o ripd, o ospfd é iniciado após o zebra e um arquivo de configuração é repassado para o mesmo.

Os passos a seguir são:

  • Baixe o cenário e descompacte-o:
  • Execute o cenário e teste a conectividade:

Fig1Lab3.png Cenário do exercício

obs: ERRO NA FIGURA: endereço do roteador R1 é 200.10.10.3/24 na eth0
  • Entre no roteador R1 e verifique a tabela de roteamento para a rede 200.10.20.0. Qual é a métrica e por que?
  • Faça um vtysh em R1 e verifique quantos router LSA e network LSA existem na base de dados. Explique estes números. Identifique também qual é o Router ID de R1:
show ip ospf database
  • Observe os routers LSAs de R1. observe o cabeçalho do router LSA associado ao R1 e identifique: o LS type, Link State ID o LS sequence.
show ip ospf database router
  • Ainda no router LSA associado a R1 identifique o número de links informados e quais são os (Link ID e Link Data) de cada um deles.
  • Ainda em R1 identifique a network LSA. Verifique o header deste LSA: identifique o LSA type, o Link State ID e o Advertising Router;
  • Ainda olhando a network LSA diga quais roteadores estão ligados na rede;
  • Usando o tcpdump identique o número do protocolo usado para identificar o OSPF. Qual protocolo de transporte o OSPF utiliza?

Desafio

Implemente a rede abaixo usando o OSPF.

RCO3-RedeSimplesOSPF.jpg


  • Compare as bases de dados de todos os roteadores. Elas são iguais? Por que?
  • Examine cada Router ID de cada roteador da rede. É possível inferir um critério foi usado para escolha deste ID?
  • Foque em um roteador e responda quantos router LSAs existem? Quem os originou?
  • Quantos network LSA existem? Quem os originou?
  • Acrescente um roteador ligado a uma rede stub na rede 200.200.2.0/29. Configure o OSPF e veja o que é alterado na base de dados do OSPF;

Material de apoio


Aula 17 - 13/10/2015 (10h)

OBJETIVOS

  • Revisar o protocolo RIP
  • Dividir e distribuir trabalhos de roteamento em redes Adhoc.

Questionário RIP

1. Qual o tipo de algoritmo implementado pelo RIP. Qual é a idéia básica deste algoritmo?

2. O RIPv1 não suporta VLSM enquanto a versão 2 suporta. O que é VLSM e o que o RIPv2 deve transportar adicionalmente ao prefixo da rede publicada?

3. Qual é a métrica utilizada pelo RIP?

4. Qual protocolo é utilizado para o transporte da informação RIP?

5. O pacote RIP possui um campo de comando. Qual o significado dos comandos RQ e RP? Explique.

6. O pacote RIPv2 possui um conjunto de campo de 20 bytes para a definição de rota. Explique o significado dos campos desta área, exemplificando o uso do campo NEXT HOP.

7. Quantas rotas podem ser colocadas em um pacote RIPv2.

8. Explique o que é o problema de convergência lenta (ou count to infinity) nos protocolos de vetor de distância e a solução parcial através do split horizon. Como é possível habilitar/desabilitar o split horizon no RIP/Quagga?

9. Explique o que é o holdown timer? É possível modificar o valor deste timer no RIP/Quagga?

10. O RIPv1 não suporta autenticação enquanto o RIPv2 suporta. Explique qual o problema que pode ocorrer no RIPv1 pelo fato de ele não possuir autenticação e como funciona o mecanismo de autenticação no RIPv2?

11. O RIPv1 se utiliza de broadcast para divulgação de rotas enquanto o RIPv2 usa multicast. Qual a vantagem deste último sobre o primeiro? Explique.

Referências

Aula 18 - 20/10/2015 (7h30)

Objetivos

Finalização e Avaliação de desafios anteriores

Aula 19 - 21/10/2015 (10h)

Continuação desafio OSPF

Aula 20 - 03/11/2014 - 7h30

Objetivos

  • Apresentar o conceito de áreas com OSPF;
  • Construir um domínio (sistema autônomo) OSPF com áreas;
  • Apresentar os LSAs do tipo summary.

OSPF Hierárquico

No OSPF é possível dividir um domínio em áreas. Todo o domínio deve ter, no entanto, um backbone que é a área 0. Todas as demais áreas são conectadas somente a área 0. Esta é uma regra geral de projeto da rede: uma topologia livre de loops.

 O papel do backbone é retransmitir um resumo (sumário) das redes de uma área para outra.

Uma área possui um identificador de 32 bits com representação semelhante a um endereço IP.

A construção de áreas permite reduzir o tamanho das bases de dados de estado de enlace, reduzindo o impacto do processo de flooding bem como o peso de processamento do algoritmo Shortest Path.

Classificação de Roteadores

Os tipos de roteadores no OSPF são:

  • Roteadores de Borda de Área: sumariza distâncias às redes na sua própria área e anuncia a outros roteadores de fronteira de área;
  • Roteadores Internos: são roteadores internos a uma área;
  • Roteadores de backbone: pertencem a área 0 (backbone) e realizam roteamento OSPF limitado ao backbone.
  • Roteador de Borda de AS (Sistema Autônomo):localizados na área 0 com conectividade a outros ASs. Usados para troca de informações com outros ASs, por exempĺo, com o protocolo BGP;

OS roteadores de borda de área geram Network Summary LSAs para dentro de suas áreas. Estes LSAs permitem divulgar redes de destino externas (prefixos de redes IPs) a uma área.


800px

Network Routing - Deepankar Medhi

Hierarquia OSPF e tipo de roteadores

Considerações sobre Network LSAs em uma área

É importante lembrar que o network LSA é um estado de enlace associado a uma rede multiponto da rede. Quem representa esta rede é o roteador designado (DR). As seguintes considerações devem ser observadas:

  • Um network LSA associado a uma determinada rede é originado por um roteador designado (DR). O formato deste LSA é mostrado na figura abaixo;
  • O prefixo da rede IP indicado pelo network LSA é determinado da seguinte forma. O campo Link State ID indica o endereço IP do DR na rede. O campo network mask informa a máscara da rede. Estas duas informações determinam o endereço IP da rede;
Um network SLA é propagado (flooding) somente na área onde se encontra a rede multi-acesso.

RCO3-NetworkSLA.png Formato de um Network LSA

Considerações sobre os Summary LSAs

Estes LSAs podem ser do tipo 3 e 4. O tipo 3 descreve rotas para redes de uma determinada área e são propagados pelo backbone 0. O tipo 4 descreve rotas para roteadores ASBRs. As seguintes considerações se aplicam:

  • Os summary LSAs são originados por roteadores de borda de área. Um LSA é criado para cada rede da área e propagado pelo backbone;
  • Somente rotas intra-área são divulgados no backbone;
  • Os roteadores de borda de área repassam os summary LSAs recebidos através do backbone e os repassam para dentro das áreas as quais estão conectados;
  • O Link State ID do Summary LSA tipo 3 é o endereço IP da rede publicada.

O formato do summary LSA é mostrado na Figura a seguir:

RCO3-SummarySLA.png Formato de um Summary SLA

Laboratório - Construção de um domínio OSPF com áreas

PARTE 1 – Construindo o cenário

Considere a rede indicada na Fig.abaixo. Baixe o laboratorio. Este cenário coloca em execução as áreas 0 e 1 e parte da área 2 (somente R4). Teste a conectividade das redes envolvidas.

600px

Domínio OSPF

PARTE 2 – Colocando o OSPF em operação em todas as áreas

  • Observe os arquivos de configuração ospf.conf e zebra.conf das áreas 0 e 1 e

configure a área 2. Por exemplo, fazendo um vtysh no R1, podemos olhar os arquivos de configuração do zebra e do ospf para R1. O ospfd.R1.conf deve se apresentar da forma:

 hostname R1
 password R1 
 enable password R1 
 router ospf 
 network 30.0.0.0/8 area 0
 network 11.0.0.0/8 area 1 
 log file ospfd.log 
NOTA: O comando network <endereço IP> area habilita o OSPF na interface com o endereço indicado! 


  • Construa um arquivo de configuração do zebra e do ospf para cada roteador da área 2, armazenado-o no diretório correspondente a cada roteador.. Exemplo: para o roteador R3 chamar de ospfd.R3.conf. Em cada arquivo coloque a informação, adaptando-a ao roteador:


  • Colocar nos arquivos de startup a execução dos deamons dos roteadores:
zebra -d
ospfd -d -f nome_arquivo_configuração

  • Teste com o ping a conectividade em toda a rede.

PARTE 3 – Examinando os estados dos roteadores internos na área 1

  • Entre no roteador R3 verifique o estado da tabela de roteamento. Como estão colocadas as rotas para as redes na área 0 e 1? Qual a métrica para a rede 21.0.0.0/24?
  • Ainda no roteador R3, entre com vtysh e verifique quais tipos de LSAs estão aparecendo.
show ip ospf database
  • Ainda em R3 liste com detalhes os summary LSAs .
show ip ospf database summary
Quem divulga os summary LSAs na área 1? A que corresponde cada um dos summary LSA? 
  • Verifique a database do OSPF no roteador R2. Ela é igual ao R3? Por que?

Observe que o LINK STATE ID em cada LSA é:

  • No Router LSA: o Router ID do roteador que originou o LSA;
  • No Network LSA: o endereço IP do roteador designado associado a rede divulgada (pseudo-nó);
  • No Summary LSA: Prefixo da rede divulgada, portanto deve existir um LSA para cada rede divulgada;

PARTE 4 – Examinando os estados dos roteadores de borda de área

  • Entre no roteador R1 com vtysh e verifique a base de dados do OSPF. Qual é a diferença em relação ao roteador R3?
  • Compare as bases de dados de R1 e de R4 e verifique quais são as diferenças.

DESAFIO

Implemente um roteador de borda de área adicional entre a área 0 e 1. Conecte-o de um lado na área 0 e no outro a rede 12.0.0.0/24. Analise as bases de dados do OSPF nos roteadores internos da área 1 e, se houve alguma alteração, explique. Enviar o cenário e um pequeno relatório para o professor. Mostre através do traceroute qual a rota seguida para a fonte H1 e destino H2.

Aula 21 03/11/2014

OBJETIVOS

  • Implementar o desafio;
  • Distribuição de Trabalhos;
  • Questionário de fixação sobre o protocolo OSPF.

Questionário OSPF

1.Quais são os tipos de roteadores no ponto de vista do OSPF? (pg.28 RFC, pg.29 slides)

2.Qual a definição de redes broadcast e não broadcast apresentado pela RFC do OSPF? (pg.9 RFC)

3.O que é o router ID, como ele é escolhido e qual é o seu escopo? (pg.8 RFC, pg.13 slides)

4.Faça um sumário da execução do OSPF (pg. 40 da RFC, pg. 37 slides);

5.Quais os 3 subprotocolos do OSPF? (pg.35 slides);

6.Como é calculado o custo nos links das redes OSPF? (material da CISCO);

7.Explique a diferença entre vizinhança e adjacência (material da CISCO);

8.Explique o que é um roteador designado, um roteador designado de backup e como é o processo para eleição deste roteador;(material da CISCO);

9.O que é o processo de sincronização de base de dados no OSPF e quando ela ocorre? (pg 53 RFC, pg 37 slides)

10.Quais as mensagens que são utilizadas no OSPF. Explique brevemente cada uma delas. (pg 38);

11.O que é o processo de flooding? (pg.16 e 37 slides)

12.Enumere e explique os 5 principais tipos de LSAs no OSPF. (pg. 44 RFC, slides 64 e 65)

13.Explique o que é a base de dados de estado de enlace do OSPF? (pg 17 slides)

14.Qual protocolo de transporte que é utilizado pelo OSPF?

15.Explique o que é um link virtual no OSPF? (material da CISCO)

16.Explique o que é um Link ID no contexto do Router LSA. (pg.208 RFC)

17.Explique o que é uma área, um área ID no contexto OSPF e quais as vantagens na divisão de um sistema autônomo em área; (pg 11 slides)

18.Explique como se dá o processo de sumarização de rotas entre áreas. Dê um exemplo. (Material da CISCO);

19.Diferencie áreas stub de áreas trânsito? (pg 67 slides)

Material de Referência


Respostas

Aula Dia 13/11/2014

OBJETIVOS

  1. Iniciar o estudo do protocolo BGP, apresentando as suas características básicas;
  2. Realizar um laboratório de BGP focando o anúncio simples de redes e a verificação do atributo AS_PATH.

ROTEIRO DA AULA

SLIDES NETKIT DO LABORATÓRIO DE ANÚNCIOS DE ROTA DO BGP

DOWNLOAD DO LABORATÓRIO NETKIT DE ANÚNCIOS DE ROTA

MATERIAL DA CISCO SOBRE BGP

MANUAL DO QUAGGA SOBRE BGP

Aula 17/11/2014 - PARTE 1

OBJETIVOS

  • apresentar filtros de anúncio no envio e na recepção;
  • Apresentar filtros por prefixo e por as-path no BGP;

SLIDES DA AULA (experimento netkit) e experimento

Exemplos de filtros de caminhos com expressões regulares

^200$  // refere-se a rotas originadas pelo 200 e que não passe por nenhum outro AS
_200_  // refere-se a rotas que tenham passado pelo AS 200
_300$  // refere-se a rotas que começam no AS 300
.*     // Qualquer rota
^200_[0-9]*$   // rotas originadas do AS 200 e provindas de um (e somente um) vizinho.

DESAFIO

  1. Considere o desafio da aula passada, em que foram inseridos os ASes 3,4 e 5. Acrescente uma interface adicional no roteador do AS1, configurando-a para acesso a uma rede 195.11.15.0/24. Publique esta rede através do BGP. Confira se o AS2 instala corretamente rota para esta rede.
  2. Coloque um filtro por prefixo no AS2, na sua relação de peering com AS3, de forma a filtrar a rede 195.11.15.0/24. Em termos de rotas, o que muda no lado do AS2?
  3. Retire o filtro por prefixo no AS2 e coloque um filtro por caminho, na relação de peering com AS3, para filtrar todas as redes anunciadas por AS3 e provindas de AS1.

Bibliografia adicional

http://raabadnetworking.blogspot.com.br/2011/05/bgp-regular-expressions-for-as-path.html

http://blog.ipspace.net/2008/02/as-path-based-filter-of-customer-bgp.html


Aula 17/11/2014 - PARTE 2

Desenvolvimento do Desafio

Aula 24/11/2014 - PARTE 1

Objetivos

  • Distribuição e início do projeto final;
  • Criação das wikis para os projetos;

Topologias a serem Implementadas

RCO3-TopologiasProjetoFinal-2014-2A.png

RCO3-TopologiasProjetoFinal-2014-2B.png

Wikis dos Projetos

Renato

Giovanni

Maciel

Vinícius

Links de ferramentas e tutoriais

Tutorial wiki

Instalação-Uso Editor Dia

Túneis GRE

Links adicionais sobre filtros com BGP

[11]

[12]

Aula 24/11/2014 - PARTE 2

Desenvolvimento do Projeto

Aula 1/12/2014 - PARTE 1

Objetivos

  • Roteamento Multicast
  • IP Móvel

Material de Referência para o Multicast

Material de Referência para o IP Móvel