RED1-EngTel (página)
MURAL DE AVISOS E OPORTUNIDADES DA ÁREA DE TELECOMUNICAÇÕES
Carga horária, Ementas, Bibliografia
Cronograma de atividades
Plano de Ensino
Edições
- RED29004 2018-1 - Prof. Odilson T. Valle
- RED29004 2017-2 - Prof. Odilson T. Valle
- RED29004 2017-1 - Prof. Odilson T. Valle
- RED29004 2016-2 - Prof. Odilson T. Valle
- RED29004 2016-1 - Prof. Odilson T. Valle
- RED29004 2015-2 - Prof. Odilson T. Valle
- RED29004 2015-1 - Prof. Odilson T. Valle
- RED29004 2014-2 - Prof. Odilson T. Valle
- RED29004 2014-1 - Prof. Arliones Hoeller
- RED29004 2013-2 - Prof. Tiago Semprebom
Material de apoio
Applets do Kurose
Vários aplicativos com representação dinâmica de características das redes de computadores.
Listas de exercícios
Lista de exercícios 1 - Introdução |
---|
|
Lista de exercícios 2 - Camada de Aplicação |
---|
ADICIONAIS PARTE 2 - HTTP
ADICIONAIS PARTE 3 - DNS
|
Lista de exercícios 3 - Camada de Transporte |
---|
|
Lista de exercícios 4 - Camada de Rede | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Lista de exercícios 5 - Camada de Enlace e Redes Multimídia |
---|
|
Transparências utilizadas durante as aulas
Slides do Kurose referentes ao capítulo 1
Slides do Kurose referentes ao capítulo 2
Slides do Prof. Emerson - DNS, FTP, Web, Email...
Slides do Kurose referentes ao capítulo 7
Slides do Kurose referentes ao capítulo 3 e versão antiga
Slides do Kurose referentes ao capítulo 4
Slides do Kurose referentes ao capítulo 5
Experimento 1: tabelas estáticas de roteamento
- Crie em seu computador um arquivo com nome /home/aluno/exp1.conf, com o seguinte conteúdo:
# Hosts definitions
pc1[type]=generic
pc2[type]=generic
pc3[type]=generic
- Routers definitions
r1[type]=gateway
r2[type]=gateway
r3[type]=gateway
- Hosts' interfaces to local routers
pc1[eth0]=link0:ip=192.168.0.1/24
pc2[eth0]=link1:ip=192.168.1.1/24
pc3[eth0]=link2:ip=192.168.2.1/24
- Routers' interfaces to local networks
r1[eth0]=link0:ip=192.168.0.254/24
r2[eth0]=link1:ip=192.168.1.254/24
r3[eth0]=link2:ip=192.168.2.254/24
- Network "backbone" links
r1[eth1]=backbone0:ip=10.0.0.1/30
r1[eth2]=backbone1:ip=10.0.1.1/30
r2[eth1]=backbone0:ip=10.0.0.2/30
r2[eth2]=backbone2:ip=10.0.2.1/30
r3[eth1]=backbone1:ip=10.0.1.2/30
r3[eth2]=backbone2:ip=10.0.2.2/30 </syntaxhighlight>
- Rode o netKit em seu computador. Em um terminal digite:
netkit2 & </syntaxhighlight>
- No menu File - Load and Run, procure o arquivo /home/aluno/exp1.conf e clique em OK. Abrirá uma janela com 6 abas, onde cada uma delas é um terminal de configuração do respectivo equipamento: PC1-3 ou R1-3.
- Ao clicar no menu File - Graph, pode-se ter uma visão da rede a ser simulada e conferir se é equivalente ao diagrama proposto.
- Nos três roteadores rode os seguintes comandos para inibir a filtragem de pacotes com rotas incompletas (copie o texto abaixo e cole nos respectivos terminas, com um click sobre a rodinha do mouse):
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter </syntaxhighlight>
- Testes de conectividade de enlace e configuração do default gateway.
- Por exemplo, no pc1 execute o comando:
ping 192.168.0.254 </syntaxhighlight> Obteve sucesso? Sim ou não e por quê?
- Teste a conectividade do pc1 executando o comando:
ping 10.0.0.1 </syntaxhighlight> Obteve sucesso? Sim ou não e por quê?
- Por exemplo, no pc1 execute o comando:
ping 10.0.0.2 </syntaxhighlight> Obteve sucesso? Sim ou não e por quê?
- Configure o roteador padrão em todos os PCs, por exemplo no pc1:
route add -net default gw 192.168.0.254 </syntaxhighlight>
- Teste novamente a conectividade, no pc1 execute o comando:
ping 10.0.0.1 </syntaxhighlight> e ping 10.0.0.2 </syntaxhighlight> Obteve sucesso? O comportamento foi o mesmo dos iten 6.2 e 6.3? Sim ou não e por quê?
- Com os ping do item anterior ativos (um a cada tempo) rode o wireshark no r1 (clique na aba r1 e em seguida no menu wireshark any. Observe que ao usar o wireshark com o Netkit, o wireshark não é dinâmico, ou seja, de tempos em tempos deves recarregar (reload <CTRL>+<R>) a captura de pacotes).
- Qual a origem e destino dos pacotes? Por quê?
- Qual a diferença no ping entre os dois itens?
- Obs: Uma opção ao wireshark é o tcpdump que permite que se grave todo o tráfego de pacotes para posterior análise, sem influenciar no funcionamento dos experimentos. O arquivo gravado é compatível com o wireshark, ou seja, pode-se abrir um arquivo gravado com o tcpdump no wireshark. Por exemplo, para iniciar a captura de pacotes em todas as interfaces de r1, utilize o seguinte comando (atenção ao "&" no final que envia o tcpdump para background, permitindo o uso normal do terminal):
tcpdump -i any -w /hostlab/r1.pcap & </syntaxhighlight> Ao final do experimento, antes de fechar o Netkit, use o comando fg tcpdump para trazer o tcpdump para o primeiro plano. Em seguida encerre a captura com Ctrl + C. Os arquivos .pcaps gerados ficam na pasta /home/aluno/lab, no exemplo r1.pcap. Ao clicar sobre o mesmo, automaticamente será aberto o wireshark.
- Iniciando o roteamento.
- Deixe o ping do item 6.3 e o wireshark (ou tcpdump) do item 6.6 rodando e estabeleça uma rota no roteador r2 com o comando:
route add -net 192.168.0.0/24 gw 10.0.0.1 </syntaxhighlight> O que ocorreu com o ping e o wireshark? Por quê?
- Interpretando o comando: route add (adiciona rota) -net 192.168.0.0/24 (para a rede 192.168.0.0/24) gw 10.0.0.1 (utilizando a interface 10.0.0.1, enlace direto, do roteador r1).
- Em todos os roteadores crie rotas para todas as redes. Em cada roteador deve-se criar 3 rotas, para as sub-redes "distantes". Lembre-se que os enlaces diretos já criam automaticamente rotas para as respectivas sub-redes, diretamente conectadas ao equipamento. Se tudo estiver correto, todos os PCs devem pingar entre si. Teste!
- Testando a queda de enlace.
- Com todas as rotas em perfeito funcionamento, gere um ping do pc1 para o pc3 e execute wireshark any no r1 , em seguida "derrube" o enlace entre o r1 e r3. Por exemplo, no r3 execute o comando:
ifconfig eth1 down </syntaxhighlight> O que ocorreu com o ping e o wireshark? Por quê? Com este enlace comprometido qual seria a solução para a continuidade de funcionamento de toda a rede?
Testando campo TTL com loop na rede
- No arquivo abaixo as tabelas de roteamento geram um loop. Copie o conteúdo abaixo e crie um arquivo loop.conf
- Hosts definitions
pc1[type]=generic
pc2[type]=generic
pc3[type]=generic
- Default gateways definitions
pc1[default_gateway]=192.168.0.254
pc2[default_gateway]=192.168.1.254
pc3[default_gateway]=192.168.2.254
- Routers definitions
r1[type]=gateway
r2[type]=gateway
r3[type]=gateway
- Hosts' interfaces to local routers
pc1[eth0]=link0:ip=192.168.0.1/24
pc2[eth0]=link1:ip=192.168.1.1/24
pc3[eth0]=link2:ip=192.168.2.1/24
- Routers' interfaces to local networks
r1[eth0]=link0:ip=192.168.0.254/24
r2[eth0]=link1:ip=192.168.1.254/24
r3[eth0]=link2:ip=192.168.2.254/24
- Network "backbone" links
r1[eth1]=backbone0:ip=10.0.0.1/30
r1[eth2]=backbone1:ip=10.0.1.1/30
r2[eth1]=backbone0:ip=10.0.0.2/30
r2[eth2]=backbone2:ip=10.0.2.1/30
r3[eth1]=backbone1:ip=10.0.1.2/30
r3[eth2]=backbone2:ip=10.0.2.2/30
- Routes definition
r1[route]=192.168.2.0/24:gateway=10.0.0.2
r2[route]=192.168.2.0/24:gateway=10.0.2.2
r3[route]=192.168.2.0/24:gateway=10.0.1.1 </syntaxhighlight>
- Lembre-se de rodar os comandos para evitar filtros de pacotes nos três roteadores:
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter </syntaxhighlight>
- Configure os roteadores para salvar os dados coletados, com os seguintes comandos:
- No r1:
tcpdump -i any -w /hostlab/r1.pcap & </syntaxhighlight>
- No r2:
tcpdump -i any -w /hostlab/r2.pcap & </syntaxhighlight>
- No r3:
tcpdump -i any -w /hostlab/r3.pcap & </syntaxhighlight>
- Gere um tráfego controlado a partir do pc1:
ping -c2 192.168.2.1 </syntaxhighlight>
- Pare (Ctrl + C) todas as coletas de dados nos roteadores.
- Com o Wireshark abra os três arquivos de pacotes capturados: /home/aluno/lab/r1.pcap...r3.pcap. Deixe as três janelas do Wireshark lado a lado e responda:
- Em qual roteador os pacotes são descartados? Observe os pacotes de número de sequência 1 e explique sua resposta.
- Qual o significado da linha com o seguinte conteúdo parcial: 192.168.0.1 ICMP 128 Time-to-live exceeded (Time to live exceeded in transit)?
O Pacote Quagga -- Breve introdução
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 pacote Zebra. O esquema abaixo mostra a
estrutura do Quagga.
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. É possível executar
vários protocolos de roteamento dinâmico simultaneamente.
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);
- ospfd (acesso pela porta 2604 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, em nossos laboratórios, fazendo uso do Netkit, será comum usarmos arquivos de configuração fornecidos na linha de
comando:
#zebra -d -f /hostlab/r1/zebra.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.
Experimento 2: protocolo de roteamento RIP
Tempo aproximado para execução e conferência: 40 min
Baseado no mesmo diagrama do experimento anterior, usaremos serviços para rodar os protocolos de roteamento RIP e OSPF a partir do Quagga, de tal modo que as tabelas estáticas de roteamento não mais serão necessárias e o sistema se auto recuperará da queda de um único enlace (nesse caso).
- Reinicie o NetKit2 para limpar todas as configurações.
- Crie em seu computador um arquivo com nome /home/aluno/exp2.conf. Observe que nessa configuração já está inserida a definição dos default gateway de cada pc. O conteúdo do arquivo é o seguinte:
- Hosts definitions
pc1[type]=generic
pc2[type]=generic
pc3[type]=generic
- Default gateways definitions
pc1[default_gateway]=192.168.0.254
pc2[default_gateway]=192.168.1.254
pc3[default_gateway]=192.168.2.254
- Routers definitions
r1[type]=gateway
r2[type]=gateway
r3[type]=gateway
- Hosts' interfaces to local routers
pc1[eth0]=link0:ip=192.168.0.1/24
pc2[eth0]=link1:ip=192.168.1.1/24
pc3[eth0]=link2:ip=192.168.2.1/24
- Routers' interfaces to local networks
r1[eth0]=link0:ip=192.168.0.254/24
r2[eth0]=link1:ip=192.168.1.254/24
r3[eth0]=link2:ip=192.168.2.254/24
- Network "backbone" links
r1[eth1]=backbone0:ip=10.0.0.1/30
r1[eth2]=backbone1:ip=10.0.1.1/30
r2[eth1]=backbone0:ip=10.0.0.2/30
r2[eth2]=backbone2:ip=10.0.2.1/30
r3[eth1]=backbone1:ip=10.0.1.2/30
r3[eth2]=backbone2:ip=10.0.2.2/30 </syntaxhighlight>
- Em cada roteador, configure o serviço RIP para que que os testes da próxima etapa possam ser executados. O Netkit cria no home do usuário uma pasta chamada "lab". Nesta pasta, há uma pasta para cada equipamento da rede em teste. Neste diretório podem ser colocados arquivos de configuração de serviços a serem executados nas máquinas virtuais do Netkit. É por ali que será configurado, primeiramente, o Quagga, software de roteamento que implementa RIP, OSPF e BGP. O arquivo de configuração abaixo mostra a configuração do Quagga para o roteador r1. Salve este arquivo com o nome zebra.conf no diretório /home/aluno/lab/r1/. Em seguida, adapte o arquivo para os roteadores r2 e r3 observando a figura do diagrama da rede para não errar os IPs.
hostname r1
interface eth0
ip address 192.168.0.254/24
interface eth1
ip address 10.0.0.1/30
interface eth2
ip address 10.0.1.1/30
log stdout
- Crie os arquivos de configuração para o RIP em cada roteador, colocando-os dentro dos diretórios dos mesmos, por exemplo, para r1 no diretório /home/aluno/lab/r1/. O nome destes arquivos deve ser ripd.conf e o conteúdo deve ser o abaixo.
router rip
redistribute connected
redistribute static
network eth1
network eth2
- No pc1 execute:
ping 192.168.2.1 </syntaxhighlight> O ping está funcionando? Por quê?
- Deixe o ping rodando!
- Inicie o daemon quagga em todos os roteadores (r1, r2 e r3).
service quagga start </syntaxhighlight>
- Execute o Quagga e o RIP em todos os roteadores (r1, r2 e r3), a partir dos arquivos criados. Os arquivos que estão na pasta "/home/aluno/lab" são montados na pasta "/hostlab/" de todas as máquinas virtuais do Netkit, ou seja, "/home/aluno/lab" na máquina real é a mesma pasta que "/hostlab/" nas máquinas virtuais do Netkit. Para iniciar os serviços no r1, faça algo como o que está no exemplo abaixo. Repita o procedimento para r2 e r3 utilizando os arquivos corretos.
zebra -d -f /hostlab/r1/zebra.conf
ripd -d -f /hostlab/r1/ripd.conf
- Olhe o terminal do pc1, o que ocorreu com o ping? Por quê?
- Observando o estado do sistema. Vamos usar comandos para verificar o estado dos roteadores.
- Solicitar uma sessão com o vtysh no zebrad:
vtysh </syntaxhighlight>
- Verifique o estado das interfaces usando o comando:
show interface </syntaxhighlight>
- Verifique se o roteador está habilitado para roteamento:
show ip forwarding </syntaxhighlight>
- Verifique o estado da tabela de roteamento usando o comando:
show ip route </syntaxhighlight> Interprete detalhadamente essa tabela! Você consegue visualizar o mapa da rede a partir dessa tabela?
- Verifique a configuração atual do roteador:
show run </syntaxhighlight>
- Sair do vtysh:
exit </syntaxhighlight>
- Teste as demais conectividades entre os PCs com pings mútuos. Tudo funcionando?
- A partir de cada PC trace a rota (traceroute) para os demais PC e anote-as.
- Com o route -n e/ou netstat -r verifique a anote as rotas de cada roteador.
- Pare todos os pings.
- Execute tcpdump -i any -w /hostlab/ripr1.pcap & no r1, aguarde uns 2 minutos para capturar pacotes específicos do protocolo de roteamento RIP.
- Com o navegador de arquivos entre na pasta /home/aluno/lab/ e dê um duplo click no arquivo ripr1.pcap e tente compreender as mensagens RIPv2 (UDP 17) trocadas. As mensagens são trocadas aproximadamente a cada minuto, se não aparecer nenhuma no Wireshark faça um reload: <Ctrl+r> até susrgir alguma mensagem. Olhe com atenção os IPs e as métricas apresentadas.
- O que dizem essas mensagens?
- Pesquise o significado do endereço 224.0.0.9.
- A partir do pc1 deixe rodando o ping
ping 192.168.2.1</syntaxhighlight>
- Com o tcpdump rodando em r1, desative um dos enlaces entre os roteadores e acompanhe a troca de mensagens no Wireshark (dê um reload). Por questões de compatibilidade vamos desativar uma interface de um modo especial. Por exemplo, para "derrubar" o enlace r1-r3, execute no r1:
vtysh 2061 entra no zebrad
conf t entra no mode de configuração
interface eth2 entra na referida interface a ser operada
shutdown desativa a interface, se desejado </syntaxhighlight>
- Permaneça monitorando o ping e o Wireshark (reload: <Ctrl+r>), a recuperação das rotas leva em torno de 1-3 min:
- Quais as mensagens trocadas pelo protocolo RIP observadas no WireShark? Observe o trecho de mensagens onde não houve respostas ao ping.
- Qual o tempo aproximado para a total recuperação das rotas? (Isso seja observável pela diferença de tempos (timestamp) na sequência de mensagens observadas no Wireshark).
- Teste as conectividades. O que aconteceu?
- Retrace as rotas com nos roteadores
vtysh 2061
show ip route </syntaxhighlight> e com o traceroute </syntaxhighlight> a partir dos PCs.
- São diferentes do caso original (todos enlaces ativos)? Por quê?
- Quais os caminhos/rotas que foram reescritos? Por quê?
Experimento 3: protocolos e roteamento OSPF
Tempo aproximado para execução e conferência: 30 min
- Reinicie o NetKit2 para limpar todas as configurações.
- Crie em seu computador um arquivo com nome /home/aluno/exp2.conf. Observe que nessa configuração já está inserida a definição dos default gateway de cada pc. O conteúdo do arquivo é o seguinte:
- Hosts definitions
pc1[type]=generic
pc2[type]=generic
pc3[type]=generic
- Default gateways definitions
pc1[default_gateway]=192.168.0.254
pc2[default_gateway]=192.168.1.254
pc3[default_gateway]=192.168.2.254
- Routers definitions
r1[type]=gateway
r2[type]=gateway
r3[type]=gateway
- Hosts' interfaces to local routers
pc1[eth0]=link0:ip=192.168.0.1/24
pc2[eth0]=link1:ip=192.168.1.1/24
pc3[eth0]=link2:ip=192.168.2.1/24
- Routers' interfaces to local networks
r1[eth0]=link0:ip=192.168.0.254/24
r2[eth0]=link1:ip=192.168.1.254/24
r3[eth0]=link2:ip=192.168.2.254/24
- Network "backbone" links
r1[eth1]=backbone0:ip=10.0.0.1/30
r1[eth2]=backbone1:ip=10.0.1.1/30
r2[eth1]=backbone0:ip=10.0.0.2/30
r2[eth2]=backbone2:ip=10.0.2.1/30
r3[eth1]=backbone1:ip=10.0.1.2/30
r3[eth2]=backbone2:ip=10.0.2.2/30 </syntaxhighlight>
- Crie os arquivos de configuração para o OSPF em cada roteador, colocando-os dentro dos diretórios dos mesmos (p. ex: /home/aluno/lab/r1). O nome destes arquivos deve ser ospfd.conf e o conteúdo deve ser conforme o modelo abaixo para o r1. Para o r2 e r3 faça as adaptações necessárias.
#Router r1
#
hostname r1
password r1
enable password r1
#
interface eth0
interface eth1
interface eth2
!ip ospf network point-to-point
router ospf
passive-interface eth0
network 192.168.0.0/24 area 0
network 10.0.0.0/30 area 0
network 10.0.1.0/30 area 0
#
log stdout
- Os arquivos zebra.conf são os mesmos utilizados no experimento 2.
- Inicie o daemon quagga em todos os roteadores (r1, r2 e r3).
service quagga start </syntaxhighlight>
- Execute o Quagga e o OSPF a partir dos arquivos criados. Os arquivos que estão na pasta "/home/aluno/lab" são montados na pasta "/hostlab/" de todas as máquinas virtuais do NetKit. Para iniciar os serviços no r1, faça algo como o que está no exemplo abaixo. Repita o procedimento para r2 e r3 utilizando os arquivos corretos.
zebra -d -f /hostlab/r1/zebra.conf
ospfd -d -f /hostlab/r1/ospfd.conf </syntaxhighlight>
- Repita, na medida do possível e fazendo os devidos ajustes, as atividades 11 a 21 do experimento anterior e responda, além das respectivas questões desses itens:
- As mensagens trocadas pelos roteadores são distintas quando comparadas ao uso do RIP?
- Houve diferença no tempo de atualização das rotas quando comparado ao RIP? Por quê?
|}
Laboratório 8 - Neighbor Discovery e roteamento estático no IPv6
Este roteiro foi baseado no material disponível no Livro - Laboratório de IPv6.
Slides de endereçamento IPv6.
Guia didático de endereçamento IPv6 obtido de http://ipv6.br/.
Objetivos do laboratório:
- Um primeiro contato com o protocolo IPv6
- Compreender o funcionando do Neighbor Discovery, o equivalente ao ARP (Address Resolution Protocol) do IPv4, que em resumo é uma tabela contendo a relação ente IPs e MACs.
- Aprender configurações básicas de interfaces IPv6 no Linux
- Aprender configurações básicas de rotas IPv6
Introdução teórica
Obs.: texto copiado literalmente de: Laboratório de IPv6.
A descoberta de vizinhança por meio do protocolo Neighbor Discovery no
IPv6 é um procedimento realizado pelos nós de uma rede para descobrir endereços físicos dos dispositivos vizinhos presentes no mesmo enlace. A função deste protocolo se assemelha à função do ARP e do RARP no IPv4.
- O procedimento é iniciado quando um dispositivo tenta enviar um pacote cujo endereço físico de destino é desconhecido. O nó solicitante envia uma mensagem Neighbor Solicitation (NS) para todos os nós do enlace pertencentes ao grupo multicast solicited-node (ff02::1:ffXX:XXXX), de modo que XX:XXXX são os últimos 24 bits do endereço IPv6 em que está interessado.
- É possível notar que, por uma coincidência dos últimos 24 bits, é bastante provável que apenas o nó de destino faça realmente parte deste grupo. Isto é um truque interessante do IPv6 para diminuir o tráfego deste tipo de pacote na rede.
- Na mensagem NS, o endereço IPv6 a ser resolvido é informado no campo Target. O campo Source link-layer address informa ao nó de destino o endereço MAC do nó de origem, poupando-o de ter que fazer o mesmo procedimento no sentido inverso.
- O nó de destino, dono do IPv6 requisitado, ao receber este pacote, envia uma mensagem Neighbor Advertisement (NA) como resposta diretamente ao nó requisitante. O seu endereço físico será informado no campo Target link-layer address.
- A informação de mapeamento entre endereços IP e endereços físicos é armazenada em uma tabela chamada neighbor cache. Nela também fica registrado o status de cada destino, informando se o mesmo é alcançável ou não.
Roteiro de atividades:
A figura abaixo apresenta o diagrama esquemático da rede a ser montada/analisada. Observe que todos os IPv6 Global Unicast já estão definidos na mesma, são esses IPs que utilizaremos em nosso experimento.
- Crie em seu computador um arquivo com nome /home/aluno/IPv6.conf, com o seguinte conteúdo:
- Ligacao das maquinas nos dominios de colisao
- Duas pequenas redes interligadas pelo backbone
- Hosts definitions
pc1[type]=generic
pc2[type]=generic
pc3[type]=generic
pc4[type]=generic
- Routers definitions
r1[type]=gateway
r2[type]=gateway
- Hosts' interfaces to local routers
pc1[eth0]=link0
pc2[eth0]=link1
r1[eth0]=backbone0
r1[eth1]=link0
r1[eth2]=link1
r2[eth0]=backbone0
r2[eth1]=HUB1
pc3[eth0]=HUB1
pc4[eth0]=HUB1 </syntaxhighlight>
- Rode o NetKit em seu computador. Em um terminal digite:
netkit2 & </syntaxhighlight>
- No menu File - Load and Run, procure o arquivo /home/aluno/IPv6.conf e clique em OK. Abrirá uma janela com 6 abas, onde cada uma delas é um terminal de configuração do respectivo equipamento: pc1-4 ou r1-2.
- Ao clicar no menu File - Graph, pode-se ter uma visão da rede a ser simulada e conferir se é equivalente ao diagrama proposto.
- Em todos os equipamentos, iremos iniciar a captura de pacotes em uma das interfaces que será gravado em um arquivo para estudo posterior. Utilize os seguintes comandos (atenção ao "&" no final que envia o tcpdump para background):
- pc1: tcpdump -i eth0 -w /hostlab/ipv6_pc1.pcap &
- pc2: tcpdump -i eth0 -w /hostlab/ipv6_pc2.pcap &
- pc3: tcpdump -i eth0 -w /hostlab/ipv6_pc3.pcap &
- pc4: tcpdump -i eth0 -w /hostlab/ipv6_pc4.pcap &
- r1: tcpdump -i eth0 -w /hostlab/ipv6_r1.pcap &
- r2: tcpdump -i eth0 -w /hostlab/ipv6_r2.pcap &
- No pc1 use o seguinte comando para adicionar o endereço IPv6 à interface de rede:
ip addr add 2001:bcc:faca:1::101/64 dev eth0 </syntaxhighlight>
- No pc1 use o seguinte comando para verificar como ficou a configuração dos endereços da interface de rede. O resultado é similar ao apresentado pelo comando ifconfig:
ip addr show dev eth0 </syntaxhighlight>
- Configure os IPv6s de todas as interfaces dos demais equipamentos de acordo com o diagrama da rede (adapte os números de IPs), seguindo o exemplo do item 6.
- Faça um ping6 entre o pc3 ao pc4. Por exemplo do pc3 ao pc4:
ping6 -c4 2001:bcc:1f0:1::104 </syntaxhighlight>
- Se tudo estiver devidamente configurado, deve-se obter sucesso no ping entre o pc3 e pc4. Explique o por quê?
- Faça um ping6 entre o pc1 ao pc2.
- Não deve ter obtido sucesso, por quê?
- Nos computadores pc3 e pc4, acrescente o default gateway com o seguinte comando:
ip -6 route add default via 2001:bcc:1f0:1::1 dev eth0 </syntaxhighlight>
- Nos computadores pc1 e pc2, acrescente o default gateway analisando o diagrama da rede e adaptando o comando acima.
- Faça novamente o ping6 entre o pc1 ao pc2.
- Agora deve ter obtido sucesso, por quê?
- Faça um ping6 entre o pc1 ao pc4.
- Obteve sucesso? Sim ou não e por quê?
- No r1, adicione uma rota estática para a rede dos pc3 e pc4 através do seguinte comando:
ip -6 route add 2001:bcc:1f0:1::/64 via 2001:db8:dead:1::2 dev eth0 </syntaxhighlight>
- No r2, adicione uma rota estática para a rede dos pc1 e pc2 através dos seguintes comandos:
ip -6 route add 2001:bcc:faca:1::/64 via 2001:db8:dead:1::1 dev eth0
ip -6 route add 2001:bcc:cafe:1::/64 via 2001:db8:dead:1::1 dev eth0 </syntaxhighlight>
- Pode-se conferir se as rotas foram corretamente configuradas com o comando:
ip -6 route show </syntaxhighlight>
- Faça novamente o ping6 entre o pc1 ao pc4.
- Obteve sucesso? Sim ou não e por quê?
- Use os comandos traceroute6 2001:bcc:1f0:1::103 e traceroute6 2001:bcc:1f0:1::104 a partir do computador pc1.
- Anote as rotas.
- Use o comando ip -6 route show para consultar a tabela de roteamento de cada um dos roteadores. São coerentes com os dados das rotas obtidas acima?
- Em cada uma das máquinas virtuais, use o comando fg tcpdump para trazer o tcpdump para o primeiro plano. Em seguida encerre a captura com Ctrl + C.
- Estude os .pcaps gerados utilizando o wireshark: abra o wireshark, File/Open e procure os arquivo na pasta /home/aluno/lab. Clique sobre cada um deles e faça a análise.
- Explique o processo de descoberta de vizinhança (neighbor discovery / Neighbor Solicitation - NS e Neighbor Advertisement - NA), citando os endereços de multicast e link local utilizados.
- Alguns exemplos de campos visualizáveis para uma mensagem do tipo Neighbor Advertisement:
- Destination (camada Ethernet)
- O endereço MAC do nó requisitante que foi obtido por meio da mensagem NS enviada anteriormente.
- Source (camada Ethernet)
- A origem é o endereço MAC da interface do dispositivo que enviou a resposta.
- Type (camada Ethernet)
- Indica que a mensagem utiliza IPv6.
- Next header (camada IPv6)
- Indica qual é o próximo cabeçalho. Neste caso, o valor 58 (0x3a) refere-se a uma mensagem ICMPv6.
- Source (camada IPv6)
- A origem é o endereço IP da interface diretamente ligada ao enlace em que a requisição foi recebida.
- Destination (camada IPv6)
- Diferentemente da mensagem NS, a mensagem NA possui como destino o endereço IPv6 global do nó requisitante.
- Type (camada ICMPv6)
- Indica que a mensagem é do tipo 136 (Neighbor Advertisement).
- Flags (camada ICMPv6)
- Uma mensagem NA possui três flags:
- Indica se quem está enviando é um roteador. Neste caso, o valor marcado é 0, pois não é um roteador.
- Indica se a mensagem é uma resposta a um NS. Neste caso, o valor marcado é 1, pois é uma resposta.
- Indica se a informação carregada na mensagem é uma atualização de endereço de algum nó da rede. Neste caso, o valor marcado é 1, pois está informando o endereço pela primeira vez.
- Target Address (camada ICMPv6)
- Indica o endereço IP associado às informações das flags. Neste caso, é o próprio endereço da interface do dispositivo em questão.
- ICMPv6 option (camada ICMPv6)
- Indica as opções do pacote ICMPv6:
- Target link-layer address
- Type
- Indica o tipo de opção. Neste caso, Target link-layer address.
- Link-layer address
- Indica o endereço MAC da interface do dispositivo em questão.
- Numa mensagem do tipo Neighbor Solicitation qual é o endereço IPv6 de origem e destino? Explique/defina ambos.
- Analisando o tráfego gerado no pc1, identifique aproximadamente quais os números (No.) de troca de pacotes nas ocorrência de ping6. Quais dais ocorrências obtiveram sucesso e quais não obtiveram? Quando não houve sucesso, qual é a causa listada no WireShark? Relacione esses dados com o itens do roteiro executado.
- Em todos os hosts rode o comando
ip -6 neighbor show </syntaxhighlight>
- Qual é a funcionalidade desse comando?
- Qual é o significado do conteúdo dessa tabela?
- A tabela mostrada em cada um dos casos é compatível com o diagrama da rede montado?
- Por que, por exemplo, na tabela do pc3 não há uma referência explícita ao pc1?
- Explique sucintamente as diferenças na comunicação baseada em IPv4 e IPv6.
Softwares
- Netkit2: possibilita criar experimentos com redes compostas por máquinas virtuais Linux.
- Vários laboratórios virtuais do NetKit, prontos para uso, que focam em serviços específicos de redes de computadores.
- CORE Network Emulator.
- Laboratório de IPv6 baseado no CORE
Curiosidades
- Monitoramento do tráfego RNP - PoP-SC
- Monitoramento do tráfego RNP - Nacional
- Rede Clara Internacional
- Futura infraestrutura de rede da RNP
- Animated map shows the undersea cables that power the internet
- Submarine Cable Map 2017
- Redes WiFi no mundo
- History of the Internet
- History of the Internet - legendado
- Warriors of the Net
- Warriors of the Net - legendado
- Browser Wars
- Browser Wars - legendado
- Browser Wars - dublado
- Localização geográfica de IPs
- IPv6 no Brasil
- Fragmentação no IPv4 e IPv6
- Laboratório de IPv6 - Livro didático contendo vários roteiros para entendimento do IPv6
- Estatísticas Google sobre IPv6
- HTTP/2 Frequently Asked Questions
- Iniciação à máquinas de estados
Seminários
- Objetivos:
- Aprofundamento teórico em algum tema atual e relevante.
- Confecção de um relatório de trabalho no estilo científico.
- Apresentação de um trabalho científico.
- Avaliação
- Conceito: 0,5 x Nota atribuída ao relatório + 0,5 x Nota atribuída a apresentação do seminário
- Critérios de avaliação
- Instruções sobre o Seminário de Redes I:
- 2 alunos por equipe.
- Os temas devem ser propostos pelas equipes em comum acordo com o professor ou então na data limite o professor apresenta alguns temas e as equipes escolhem.
- O relatório pode ser redigido como uma página da wiki ou em PDF gerado por editores/diagramadores de texto do tipo LaTeX (Online LaTeX Editor ShareLaTeX) ou outro editor qualquer.
- Detalhes e conteúdo mínimo exigido baseado no modelo de relatório.
- Se desejar fazer em LaTeX siga o modelo de trabalho acadêmico.
- Um exemplo de bom relatório [1].
- Duração da apresentação: 20 minutos (limitantes: 15 a 25 minutos) + 5 minutos de perguntas.
- As apresentações devem obrigatoriamente ser preparadas em formato de slides ou equivalente e podem conter demonstrações, filmes, acesso a sites etc.
- Semestre 2018/2
- Semestre 2018/1
- Data de definição dos temas: 15/05/2018.
- Data de entrega do relatório: 11/06/2018.
- Data das apresentações: 25/06/2018 e 26/06/2018.
- Tecnologia LoRaWAN: Augusto da Silveira Willemann, Andre Luiz Faraco Mazucheli e Victor Cesconetto De Pieri
- Proxy reverso: Jennifer e João
- 6LowPAN: Felipe Cardoso
- Li-Fi: Gabriel Santos de Souza
- Internet via satélite: Guilherme, Alisson e Alexandre
- 5G: Luiza Alves da Silva