Mudanças entre as edições de "RED29004-2014-2"

Slides do Prof. Emerson - DNS, FTP, Web, Email...

Slides do Kurose referentes ao capítulo 3, 6a. Ed.

Slides do Kurose referentes ao capítulo 4, 6a. Ed.

Slides do Kurose referentes ao capítulo 5, 6a. Ed.

Roteiros para laboratório

Laboratório 1 -- Ping, traceroute, Web e HTTP

Laboratório 2 -- Wireshark e HTTP

Laboratório 3 - Serviço de Nomes (DNS)

Usando o programa host ou dig, descubra os endereços IP associados aos seguintes nomes de domínios:
- mail.ifsc.edu.br
- www.sj.ifsc.edu.br
- www.google.com
- www.gmail.com
- www.amazon.co.uk
- www.gov.za
- www.sls.com.au
Agora descubra quem é o servidor DNS responsável por cada um dos domínios dos nomes acima. Para isso consulte o valor do registro NS associado a esses domínios. Por exemplo, com o programa host isso pode ser feito assim:
```
host -t ns ifsc.edu.br
```
Descubra qual o servidor DNS usado pelo seu computador. Para isso é mais fácil usar o programa nslookup:
```
# Use o nslookup para consultar o endereço IP de um nome qualquer ...
nslookup www.ifsc.edu.br
```
Agora que já está ficando claro como funcionam as consultas DNS, deve-se investigar como se dá a comunicação entre seu computador e seu servidor DNS. Portanto, execute o wireshark:
```
sudo wireshark
```
... e em seguida faça uma consulta DNS qualquer. Com base nisso identifique o seguinte:
1. Quantas mensagens são trocadas entre cliente e servidor DNS para cada consulta?
2. Que protocolo de transporte é usado? E que porta?
3. Qual o formato das mensagens DNS? Elas são textuais como as mensagens HTTP ou SMTP?
4. Qual o tipo de registro DNS acessado em cada consulta ?
5. Que informações estão contidas nas respostas DNS? Há algo além do que foi pedido?
6. Qual o tamanho das mensagens DNS?
O serviço DNS fornece outras informações além do endereço IP associado a cada nome de domínio. Por exemplo, como ele se pode descobrir que host recebe emails em um determinado domínio. Isso é utilizado pelos MTA mundo afora para entregarem emails para seus destinatários (lembre que isso se faz com o protocolo SMTP). Para descobrir essa informação, deve-se consultar o registro MX de um domínio. Por exemplo:
```
host -t mx ifsc.edu.br
```
Descubra quem é o servidor que recebe emails nos seguintes domínios:
- gmail.com
- hotmail.com
- uol.com.br
- ufsc.br
Outra informação útil guardada por servidores DNS é a tradução de endereço IP para nome de domínio. Isso é chamado de tradução reversa (ou DNS reverso). Usando os programas de diagnóstico já vistos, isso pode ser feito assim:
```
dig -x 200.180.10.13
```
... o dig tem um resultado um pouco mais carregado que os outros utilitários (host e nslookup), porém neste caso é mais prático. Veja o resultado da consulta logo após a linha ;; ANSWER SECTION:. Experimente fazer a resolução reversa para cada um dos IP obtidos nas consultas realizadas no primeiro exercício desta atividade.
Como explicado durante a aula, DNS é um banco de dados distribuído. Isso quer dizer que suas informações estão espalhadas em milhares (ou milhões?) de servidores DNS mundo afora. Cada servidor DNS mantém os dados dos domínios por que é responsável. Será que é possível rastrear todos os servidores DNS que devem ser consultados até chegar ao servidor do domínio procurado?
1. Descubra quem são os servidores raiz (topo de hierarquia DNS):
```
host -t ns .
```
  ou
```
dig -t ns .
```
2. Escolha um dos servidores listados, e use-o para fazer as consultas. Por exemplo:
```
host -v -t a www.sj.ifsc.edu.br. j.root-servers.net.
```
  ... e observe a seção ;; AUTHORITY SECTION:. Ele contém a listagem de servidores DNS que podem atender sua consulta.
3. Continue fazendo as consultas aos servidores DNS listados, até conseguir traduzir o nome requisitado. Quantos servidores DNS foi necessário consultar no total?
4. Repita esse exercício para os seguintes nomes de domínio:
  - www.bbc.co.uk
  - www.amazon.com
  - www.thepiratebay.org
  - www.reeec.illinois.edu
  - www.inm.ras.ru
Outros tipos de consulta usando o dig:
1. explícita a um determinado servidor (@)
```
dig @j.root-servers.net. +trace www.sj.ifsc.edu.br.
```
2. mostra a consulta recursiva:
```
dig +trace www.sj.ifsc.edu.br.
```

Laboratório 4 - Programação de sockets

Material original: Slides do Kurose referentes ao capítulo 2, 6a. Ed., pags 54 à 58

Programação de sockets: criando aplicações de rede

Há dois tipos de aplicações de rede:
- Uma delas é uma execução cuja operação é especificada em um padrão de protocolo.
- O outro tipo de aplicação de rede é uma aplicação de rede proprietária.

Descrição da aplicação a ser desenvolvida em UDP e TCP

Usaremos a aplicação cliente-servidor simples a seguir para demonstrar a programação de socket:

Um cliente lê uma linha de caracteres (dados) do teclado e a envia para o servidor.
O servidor recebe os dados e converte os caracteres para maiúsculas.
O servidor envia os dados modificados ao cliente.
O cliente recebe os dados modificados e apresenta a linha em sua tela.

Programação de sockets com UDP

A aplicação cliente-servidor usando UDP tem a estrutura apresentada na Figura baixo. Utilizamos a linguagem Python por expor com clareza os principais conceitos de sockets. Quem desejar pode implementar em outras linguagens, por exemplo um modelo para programação de sockets utilizando a API Posix encontra-se aqui.

Como fica evidente na Figura acima, os processos cliente e servidor rodam em máquinas distintas e se comunicam justamente enviando mensagens vis sockets, que abstrai qualquer necessidade de conhecimento das camadas subjacentes.

Um exemplo de código bem simples para o lado Cliente:

UDPClient.py


Esta linha define que pode-se utilizar sockets dentro do programa
from socket import *

Define o endereco ip do servidor ao qual o cliente contactara
serverName = 'ip_do_servidor'

Define a porta de acesso ao servidor
serverPort = 22222

Cria o socket do cliente, denominado clientSocket. O primeiro parametro indica a familia do endereco,
em particular, AF_INET indica que a rede subjacente esta usando IPv4. O segundo parametro indica que
o socket eh do tipo SOCK_DGRAM, o que significa que eh um socket UDP.
clientSocket = socket(AF_INET, SOCK_DGRAM)

raw_input eh uma funcao interna da linguagem Python que permite a solicitacao de entrada de dados que
sera armazenada em message.
message = raw_input('Entre com a sentanca em minuculas: ')

O metodo sendto() acrescenta o endereco (e porta) de destino a mensagem e envia o pacote resultante
pelo socket aberto.
clientSocket.sendto(message,(serverName, serverPort))

Apos o envio do pacote, o cliente aguarda a resposta do servidor armazenando esta na variavel
modifiedMessage e o endereço de origem eh armazenado em serverAddress. 2048 representa o tamanho do buffer.
modifiedMessage, serverAddress = clientSocket.recvfrom(2048)

Imprime a mensagem recebida na tela.
print modifiedMessage

Fecha o socket.
clientSocket.close() </syntaxhighlight>
O código do lado do Servidor (comentários somente nas linhas inéditas):
UDPServer.py 
from socket import *
serverPort = 22222
serverSocket = socket(AF_INET, SOCK_DGRAM)

Vincula o numero da porta, nesse caso 22222, ao socket do servidor e "abre a porta".
serverSocket.bind((, serverPort))
print "O servidor esta pronto para recepcao"

Aguarda indefinidamente contatos por clientes
while 1:
	message, clientAddress = serverSocket.recvfrom(2048)

       #Ao receber a mensagem do cliente converte todos os caracteres para maiusculas.

	modifiedMessage = message.upper()
	serverSocket.sendto(modifiedMessage, clientAddress) </syntaxhighlight>


Para testar se o servidor está com a "porta aberta" podemos utilizar o aplicativo nmap, que procura por portas abertas. Como exemplo vamos verificar somente se a porta 22222 UDP (-sU) está aberta:

sudo nmap -p22222 -sU numero_do_ip_do_servidor

Programação de sockets com TCP
Diferentemente do UDP, o TCP é um protocolo orientado a conexão. Isso significa que, antes que cliente e servidor possam enviar dados uma ao outro, ele primeiramente devem se apresentar, o primeiro socket da Figura abaixo, e estabelecer uma conexão TCP, o segundo socket da Figura abaixo. Todos os dados trafegarão pelo segundo socket.
O processo TCPServer tem dois sockets:

A aplicação cliente-servidor usando TCP:

Um exemplo de código bem simples para o lado Cliente (comentários somente nas linhas inéditas):
TCPClient.py 
from socket import *
serverName = 'ip_do_servidor'
serverPort = 33333

SOCK_STREAM habilita uso do TCP
clientSocket = socket(AF_INET, SOCK_STREAM)

Representa o estabelecimento da conexao. E o "aperto de maos", onde o cliente e servidor trocam
informacoes da portas que serao utilizadas pela conexao (socket) propriamente dito
clientSocket.connect((serverName,serverPort))
message = raw_input('Entre com a sentanca em minuculas: ')

Diferentemente do UDP, aqui nao e necessario encaminhar o endereco do servidor, ja que este socket
eh uma "tubulacao" direta entre ambos, basta empurrar dados
clientSocket.send(message)
modifiedMessage = clientSocket.recv(1024)
print 'Mensagem do servidor: ', modifiedMessage
clientSocket.close() </syntaxhighlight>
O código do lado do Servidor (comentários somente nas linhas inéditas):
TCPServer.py 
from socket import *
serverPort = 33333
serverSocket = socket(AF_INET, SOCK_STREAM)
serverSocket.bind((,serverPort))

Escuta as requisicoes do TCP do cliente. Numero maximo de conexoes em fila = 1
serverSocket.listen(1)
print 'O servidor esta pronto'
while 1:
	#Quando o cliente bate a essa porta, o programa chama o metodo accept() para serverSocket,

       #que cria um novo socket no servidor, chamado connectionSocket, dedicado a esse cliente
       #especifico. Cliente e servidor, entao, completam a apresentacaoo, criando uma conexao TCP
       #entre o clientSocket do cliente e o connectionSocket do servidor.

	connectionSocket, addr = serverSocket.accept()
	message = connectionSocket.recv(1024)
	messageMaiuscula = message.upper()
	connectionSocket.send(messageMaiuscula)
	connectionSocket.close() </syntaxhighlight>
Teste do servidor:

nmap -sT -p33333 ip_do_servidor

Roteiro de atividades
Ligue a máquina virtual ARC-2-server
Logue com: aluno - ARC-2-ser
Configure a interface de rede 

sudo ifconfig eth0 192.168.2.X # onde X=102, 103, ..., 114, para, respectivamente M2, M3, ..., M14
sudo route add -net default gw 192.168.2.1 # Adicionando o roteador padrão
sudo vi /etc/resolv.conf # adicionar o DNS

 nameserver 200.135.37.65 </syntaxhighlight>

Escreva o programa UDPServer.py nessa máquina e execute-o: 

python UDPServer.py </syntaxhighlight>

Se apresentar erros de sintaxe corrija-os
Teste com o nmap para verificar se a porta está aberta.
Abra um terminal da máquina real e escreva o programa UDPClient.py. Não se esqueça de adequar o endereço IP. Execute-o.
Sucesso na execução do programa?
Rode o WireShark, seguindo o modelo apresentado no Laboratório 2
Execute novamente o cliente e servidor e capture os pacotes com o WireShark. Use um filtro do tipo: ip.addr == ip_do_servidor, assim captura-se somente os pacotes originados/destinados ao servidor.
Repita os passos 4 a 10, só que agora para o protocolo TCP.
Discuta com os colegas as diferenças observadas entre os protocolos UDP e TCP.
Com seu cliente conecte o servidor de seu colega e vice-versa. Alguma diferença?
Desafios
Modifique uma das aplicações cliente-servidor, seja UDP ou TCP, para fazer um pingue-pongue com a mensagem, ou seja, o cliente gera e envia a mensagem, o servidor a devolve, o cliente reenvia a mesma mensagem, o servidor a devolve e assim sucessivamente.
Faça a "Tarefa 1: Servidor Web" do livro do Kurose, página 131, 6a ed.

Laboratório 5 - TCP x UDP

Tempo aproximado: 1h

Problemas observados: No experimento 2 diminuir o tamanho do arquivo: máximo 200 MB.

O objetivo desses experimentos é evidenciar as diferenças entre os protocolos TCP e UDP.

Experimento 1

Ambos protocolos de transporte podem ser usados por aplicações que precisem se comunicar. Porém cada um deles têm certas propriedades, então a escolha precisa ser feita dependendo do tipo de comunicação a ser feita pela aplicação. Por exemplo, o que aconteceria se um arquivo fosse transferido de um computador a outro com ambos protocolos ?

Abra um terminal e execute o seguinte comando para fazer o download de um arquivo a ser usado no experimento:
```
wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/ubuntu.iso
```
Observe o tamanho do arquivo transferido ... ele deve ter exatamente 1028653056 bytes (cerca de 981 MB). Você pode fazer isso com o comando ls -l ubuntu.iso, ou executando o gerenciador de arquivos e visualizando as propriedades desse arquivo.
Escolha um colega para fazer o experimento, em que o arquivo será transferido de um computador para o outro.
A primeira transferência será feita usando o protocolo TCP da seguinte forma:
- No computador receptor execute o netcat que abrirá uma conexão TCP na porta, por exemplo, 5555 e salvará os dados transferidos em arquivo:
```
nc -l 5555 > arquivoTCP
```
- No computador transmissor execute (X é o número do computador do seu vizinho, visível na etiqueta):
```
time nc 192.168.2.X 5555 < ubuntu.iso
```
- Quando completar a transferência, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo?
A segunda transferência será feita usando o protocolo UDP:
- No computador receptor baixe o programa receptor, acrescente a ele permissão de execução e o execute, conforme a sequência de comandos abaixo:
```
wget http://tele.sj.ifsc.edu.br/~tisemp/RES/receptor
chmod +x receptor
./receptor 5555 > arquivoUDP
```
- No computador transmissor baixe o programa transmissor, acrescente a ele permissão de execução e o execute, conforme a sequência de comandos abaixo (X é o número do seu computador, visível em sua etiqueta):
```
wget http://tele.sj.ifsc.edu.br/~tisemp/RES/transmissor
chmod +x transmissor
./transmissor 192.168.2.X 5555 < ubuntu.iso
```
- Quando completar a transferência, no receptor digite <CTRL + C>, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo?
Compare as transferências feitas com TCP e UDP. O que eles têm em comum? Que diferenças lhe pareceram mais pronunciadas? Como isso deve afetar as aplicações que usam esses protocolos?

Experimento 2

Transferências usando cada um desses protocolos podem apresentar características bem distintas. Neste segundo experimento, serão feitas transferências simultâneas de arquivos a partir de um mesmo servidor, comparando-se o resultado obtido com TCP e UDP. Essas transferência ocorrerão entre os computadores do laboratório e um servidor externo ao laboratório, como mostrado na figura abaixo:

172.18.16.38

Abra um terminal em seu computador, e nele execute este comando:
```
wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/ubuntu.iso
```
Observe a taxa de transferência (velocidade do download) obtida. Que valores ela apresenta? Quanto tempo levou para o arquivo ser transferido?
Após todos terem copiado o arquivo, o professor irá repetir a transferência a partir de uma máquina virtual. Porém desta vez ele irá fazê-la sozinho. Que taxas ele obteve, e quanto tempo levou?
O professor irá repetir a transferência novamente, mas desta vez ele irá pedir que um aluno também a inicie logo em seguida. Qual foi a taxa obtida por ambos?
Finalmente, o professor irá repetir a transferência porém com três alunos fazendo-a ao mesmo tempo. Que se pode concluir quanto a taxa de transferência obtida?
Para poder fazer uma comparação, as transferências serão feitas novamente porém usando UDP como protocolo de transporte. Para isso siga estes passos:
1. Abra dois terminais. Em um deles execute este comando:
```
watch -n 1 ls -l arquivo
```
  ... e no outro execute:
```
./receptor 5555 > arquivo
```
2. Fique observando o primeiro terminal (watch...). O professor irá transmitir o arquivo a partir do servidor remoto, um processo para cada aluno. No terminal observe o tamanho do arquivo, que deverá aumentar gradativamente. Monitore manualmente o tempo em segundos (relógio, celular ou relógio do computador), o tamanho e quando o tamanho do arquivo parou de crescer.
3. Em que valor o tamanho do arquivo parou de crescer? Quanto tempo isso levou, aproximadamente? E esse tamanho final é o mesmo do arquivo original?
4. Como se comparam as transferências usando TCP e UDP?

Experimento 3

Repita os experimentos 1 e 3 mas agora com o arquivo minimo.txt, anotando todos os tempos.

Os resultados foram os esperados? Discuta sobre as possíveis diferenças de comportamento.

Tarefa extra

Use o aplicativo NetCat (nc) para fazer transferências UDP e responda:

Qual o procedimento no lado transmissor e receptor?
Consegue-se medir o tempo de maneira automática?
Por que os processos não param ao final da transferência?

Laboratório 6 - Protocolos de roteamento

Analisar o funcionamento de protocolos de roteamento estático e dinâmico da Internet, em particular as tabelas estáticas de roteamento, o protocolo RIP e OSPF, a partir de uma estrutura física formada por roteadores e redes locais. Para isto utilizaremos o Netkit2. Leia aqui como o Netkit2 trabalha com roteadores.

Em todos os experimentos será utilizado como base a seguinte arquitetura de rede:

Experimento 1: tabelas estáticas de roteamento

Tempo aproximado para execução e conferência: 1h

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.
Testes de conectividade de enlace
Por exemplo, no pc1 execute o comando:  ping 192.168.0.254 </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, 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.2 </syntaxhighlight> Obteve sucesso? O comportamento foi o mesmo do item 4.2? Sim ou não e por quê?

Com o ping do item anterior ativo rode o wireshark no r1 (clique na aba r1 e em seguida no menu wireshark any). Qual a origem e destino dos pacotes? Por quê?
Repita o procedimento 4.3 para todos os PCs.

Iniciando o roteamento
Deixe o ping do item 4.4 e o wireshark do item 4.5 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ê?

Em todos os roteadores crie rotas para todas as redes. Se tudo estiver correto, todos os PCs devem pingar entre si. Teste!

Testando a queda de enalce.
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?

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.

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.
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 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 e releia o arquivo de configuração.
Repita o item 4.3 do experimento anterior para todos os PCs.
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 "lab/r1/". Em seguida, adapte o arquivo para os roteadores r2 e r3.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. 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 a partir dos arquivos criados. Os arquivos que estão na pasta "/home/USUARIO/lab" são montados na pasta "/homelab/" 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
$ ripd -d -f /hostlab/r1/ripd.conf

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

exit </syntaxhighlight>
Olhe o terminal do pc1, o que ocorreu com o ping? Por quê?
Teste as demais conectividades entre os PCs com ping 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 show ip route verifique a anote as rotas de cada roteador.
Execute o WireShark (ou tcpdump -n -vvv -i any) no r1 por pelo menos 1 min e tente compreender as mensagens RIPv2 (UDP 17) trocadas. Olhe com atenção os IPs e as métricas apresentadas. O que dizem essas mensagens?
Com o WireShark rodando em r1, desative um dos enlaces entre os roteadores e acompanhe a troca de mensagens. Por questões de compatibilidade vamos desativar uma interface de um modo especial. Por exemplo, para "derrubar" o enlace r1-r2, execute no r1: 

vtysh 2061            entra no zebrad
conf t                entra no mode de configuração
interface eth1        entra na referida interface a ser operada
shutdown              desativa a interface, se desejado
no shutdown           restaura a interface, se desejado </syntaxhighlight>

Permaneça monitorando o ping e o Wireshark, a recuperação das rotas leva em torno de 1 min. Quais as mensagens trocadas no WireShark?
Teste as conectividades. O que aconteceu?
Retrace as rotas com show ip route nos roteadores e com o traceroute a partir dos PCs. São diferentes do caso original (todos enlaces ativos)? 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/USUARIO/lab" são montados na pasta "/homelab/" 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>

Quais as conclusões?
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 7 - LANs: HUBs vs. Switches

Conceituação sobre Redes Locais (LAN)

Características e pontos-chaves

Obs: obtido de STALLINGS, 2005:

Uma LAN consiste de um meio de transmissão compartilhado e um conjunto de hardware e software para servir de interface entre dispositivos e o meio de transmissão, além de regular o acesso ao meio de forma ordenada.
As topologias usadas em LANs são anel (ring), barramento (bus), árvore (tree) e estrela (star). Uma LAN em anel consiste de um laço fechado formado por repetidores que possibilitam que dados circulem ao redor do anel. Um repetidor pode funcionar também como um ponto de acesso de um dispositivo. Transmissão geralmente se dá na forma de quadros (frames). As topologias barramento e árvore são segmentos de cabos passivos a que os dispositivos são acoplados. A transmissão de um quadro por um dispositivo (chamado de estação) pode ser escutada por qualquer outra estação. Uma LAN em estrela inclui um nó central onde as estações são acopladas.
Um conjunto de padrões definido para LANs especifica uma faixa de taxas de dados e abrange uma variedade de topologias e meios de transmissão.
Na maioria dos casos, uma organização possui múltiplas LANs que precisam ser interconectadas. A abordagem mais simples para esse problema se vale de equipamentos chamados de pontes (bridges). Os conhecidos switches Ethernet são exemplos de pontes.
Switches formam os blocos de montagem básicos da maioria das LANs (não muito tempo atrás hubs também eram usados).

Algumas tecnologias

Ethernet (IEEE 802.3): largamente utilizada hoje em dia, na prática domina amplamente o cenário de redes locais.
Token Ring (IEEE 802.5): foi usada nos anos 80 e início dos anos 90, mas está em desuso ... muito difícil de encontrar uma rede local deste tipo hoje em dia.
Myrinet: criada especificamente para interligar servidores de alta capacidade de processamento em clusters. Atualmente pouco usada, pois redes ethernet as substituíram em clusters e data centers.
Infiniband: especificamente criada para interligar equipamentos para fins de computação de alto-desempenho. Mantém-se na ativa nesse nicho específico.

Topologias

Uma topologia de rede diz respeito a como os equipamentos estão interligados. No caso da rede local, a topologia tem forte influência sobre seu funcionamento e sobre a tecnologia adotada. Dependendo de como se desenha a rede, diferentes mecanismos de comunicação são necessários (em particular o que se chama de acesso ao meio). A eficiência da rede (aproveitamento da capacidade de canal, vazão) e sua escalabilidade (quantidade de computadores e equipamentos que podem se comunicar com qualidade aceitável) também possuem relação com a topologia. A tabela abaixo exemplifica topologias conhecidas de redes locais.

Topologia	Exemplo	Tecnologias
Estrela		Ethernet (IEEE 802.3) com hubs e switches
Anel (em desuso)		Token-ring (IEEE 802.5), FDDI
Barramento (em desuso)		Ethernet (IEEE 802.3)
Árvore		Ethernet (IEEE 802.3) com hubs e switches
Árvore-gorda (Fat-tree)		Ethernet (IEEE 802.3) com hubs e switches

Exemplos de uso de redes locais

Exemplos de redes locais são fáceis de apresentar. Praticamente toda rede que interconecta computadores de usuários é uma rede local - mesmo no caso de redes sem-fio, um caso especial a ser estudado mais a frente. A rede do laboratório de Redes 1, onde temos nossas aulas, é uma rede local. Os demais computadores da escola formam outra rede local. Quando em casa se instala um roteador ADSL e se conectam a ele um ou mais computadores, cria-se também uma rede local. Portanto, redes locais são extremamente comuns e largamente utilizadas. Ainda assim, cabem alguns outros exemplos de possíveis redes locais, mostrados abaixo:

Uma LAN típica com um link para Internet

Experimento 1: HUBs

Tempo aproximado para execução e conferência: 30 min.

Neste experimento vamos testar a taxa de transferência simultânea entre várias máquinas interligadas por meio de um HUB. Para tal utilizaremos o NetKit como ferramenta base (formação da rede) e o iperf como gerador de tráfego.

Salve em seu PC o arquivo abaixo com nome 10hostsHub.conf:


Hosts definitions


pc1[type]=generic
pc2[type]=generic
pc3[type]=generic
pc4[type]=generic
pc5[type]=generic
pc6[type]=generic
pc7[type]=generic
pc8[type]=generic
pc9[type]=generic
pc10[type]=generic

Hosts' interfaces to HUB
pc1[eth0]=lan0:ip=192.168.0.1/24
pc2[eth0]=lan0:ip=192.168.0.2/24
pc3[eth0]=lan0:ip=192.168.0.3/24
pc4[eth0]=lan0:ip=192.168.0.4/24
pc5[eth0]=lan0:ip=192.168.0.5/24
pc6[eth0]=lan0:ip=192.168.0.6/24
pc7[eth0]=lan0:ip=192.168.0.7/24
pc8[eth0]=lan0:ip=192.168.0.8/24
pc9[eth0]=lan0:ip=192.168.0.9/24
pc10[eth0]=lan0:ip=192.168.0.10/24</syntaxhighlight>

Com o NetKit2 execute (Load and Run) a rede criada acima. Verifique o diagrama da rede formada (Graph).
Ajuste o pc1 para ser um servidor de rede e ficar ouvindo em uma determinada porta TCP:  iperf -s </syntaxhighlight>

Use o pc2 como cliente fazendo uma transmissão a taxa máxima durante 100 s:  iperf -c 192.168.0.1 -t 100 </syntaxhighlight> Fique monitorando o pc2, quando terminar a transmissão pare o servidor (pc1).

Qual a taxa média conseguida? Anote.
Agora, inicie dois servidores, o pc1 e pc3, e, em seguida, dois clientes "simultaneamente" (pc2 e pc4).
Qual a taxa média conseguida em cada par comunicante? Explique a diferença. Anote.
Vá aumentando um a um os pares comunicantes até os 10 PCs (5 pares) estarem em uso.
Qual a taxa média conseguida em cada par comunicante? Explique a diferença. Anote.
Faça um gráfico das taxas médias obtidas por par comunicante em relação a variação do número de pares comunicantes.

Experimento 2: Switchs
Tempo aproximado para execução e conferência: 20 min.
Vamos repetir o experimento 1 com a única diferença proporcionada pela troca de um HUB por um Switch.

Salve em seu PC o arquivo abaixo com nome 10hostsSwitch.conf: 

Hosts definitions

pc1[type]=generic
pc2[type]=generic
pc3[type]=generic
pc4[type]=generic
pc5[type]=generic
pc6[type]=generic
pc7[type]=generic
pc8[type]=generic
pc9[type]=generic
pc10[type]=generic

Switch definitions
sw[type]=switch
sw[eth0]=port0
sw[eth1]=port1
sw[eth2]=port2
sw[eth3]=port3
sw[eth4]=port4
sw[eth5]=port5
sw[eth6]=port6
sw[eth7]=port7
sw[eth8]=port8
sw[eth9]=port9

Hosts' interfaces to sw
pc1[eth0]=port0:ip=192.168.0.1/24
pc2[eth0]=port1:ip=192.168.0.2/24
pc3[eth0]=port2:ip=192.168.0.3/24
pc4[eth0]=port3:ip=192.168.0.4/24
pc5[eth0]=port4:ip=192.168.0.5/24
pc6[eth0]=port5:ip=192.168.0.6/24
pc7[eth0]=port6:ip=192.168.0.7/24
pc8[eth0]=port7:ip=192.168.0.8/24
pc9[eth0]=port8:ip=192.168.0.9/24
pc10[eth0]=port9:ip=192.168.0.10/24 </syntaxhighlight>

Com o NetKit2 execute (Load and Run) a rede criada acima. Verifique o diagrama da rede formada (Graph).
Ajuste o pc1 para ser um servidor de rede e ficar ouvindo em uma determinada porta TCP:  iperf -s </syntaxhighlight>

Use o pc2 como cliente fazendo uma transmissão a taxa máxima durante 100 s:  iperf -c 192.168.0.1 -t 100 </syntaxhighlight> Fique monitorando o pc2, quando terminar a transmissão pare o servidor (pc1).

Qual a taxa média conseguida? Anote.
Agora, inicie dois servidores, o pc1 e pc3, e, em seguida, dois clientes "simultaneamente" (pc2 e pc4).
Qual a taxa média conseguida em cada par comunicante? Explique a diferença. Anote.
Vá aumentando um a um os pares comunicantes até os 10 PCs (5 pares) estarem em uso.
Qual a taxa média conseguida em cada par comunicante? Explique a diferença. Anote.
Faça um gráfico das taxas médias obtidas por par comunicante em relação a variação do número de pares comunicantes.

Softwares

Netkit2: possibilita criar experimentos com redes compostas por máquinas virtuais Linux

[1] Nesta página você pode encontrar vários laboratórios virtuais do NetKit, prontos para uso, que focam em serviços específicos de redes de computadores.

Curiosidades

Seminários

Recomenda-se a confecção do relatório na própria Wiki. O professor criará a página para cada projeto que assim o desejar. Na página do projeto, os membros da equipe podem editar a qualquer hora, sem preocupação com a versão do mesmo. Também facilita o acompanhamento por parte do professor. Utilizando ou não a Wiki, usem esse modelo de relatório.

Grupos e Temas para 2014-2:
- Gustavo e Walter: 4G - 9/12
- Gabriel e Lucas: WiMax - 9/12
- Diego e Giulio: PLC - 9/12
- Fernando e Stephany: Zigbee - 5/12
- Vinícius e Clarice: ADSL - 9/12
- João e Marcos: IoT - 5/12
- Adalvir e Fabiano: NGN - 5/12
- Ronaldo: IEEE_802.11n - 5/12

Avaliação
- Nota: 0,5 x Documento + 0,5 x Seminário
- Nota final individual. Será dada uma nota por equipe (máximo = número_de_alunos_da_equipe * 10) e a equipe decide qual será a nota individual por aluno, sendo que a soma das notas dos alunos deverá ser igual a nota da equipe. O professor pode interferir na distribuição das notas dentro da equipe.
- Avaliação final dos seminários.

Instruções sobre o Seminário de Redes I:
- Data para definição de grupos e temas: 8/8/14.
- 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.
- Data de entrega do documento: 21/11/14 (impreterivelmente).
- O relatório pode ser redigido como uma página da wiki.
- Duração da apresentação: 20 minutos + 5 minutos de perguntas.
- As apresentações podem ser realizadas seguindo o conteúdo do relatório (use bastante figuras no relatório, isto facilita a apresentação).
- Se preferirem usar slides, usem esse modelo.

Diário de aulas

Aula 1 - 1/8/14: Apresentação da disciplina

Apresentação da disciplina, plano de aula, trabalhos e métodos de avaliação.

Auto apresentação
Apresentação da Wiki
Ementa
Plano de Ensino
Apresentação do modelo de aulas a ser adotado
1. Laboratórios
2. Kurose
Avaliações
1. 3 avaliações (P1, P2 e P3)
2. Seminários (S)
3. Reavaliações (P1, P2 e P3)
4. Nota final: NF = (P1 + P2 + P3 + S) / 4
5. Conceito final: Se NF < 6,0 = D --> Reprovado


Se  6,0 =< NF < 7,5  = C --> Aprovado
Se  7,5 =< NF < 9,0  = B --> Aprovado
Se  NF >= 9,0 = A --> Aprovado </syntaxhighlight>

Qual o grande objetivo das redes de computadores?
Relação com outras disciplinas do curso

Aula 2 - 5/8/14: Introdução a Redes de Computadores

Breve histórico sobre o surgimento das redes de computadores e a Internet
- Vídeo sobre surgimento da Internet

Vídeo sobre o funcionamento das fibras ópticas
- Vídeo sobre fibra óptica

Mapas de rede dorsais (Backbones)
- Mapa da rede Ipê (Internet acadêmica pública no Brasil)
- POP SC (ponto de presença de SC)

Uma representação artística das interligações na Internet

Aula 3 - 8/8/14: Introdução a Redes de Computadores
Slides do Kurose referentes ao capítulo 1

Aula 4 - 12/8/14: Comutação de circuitos vs comutação de pacotes
Slides do Kurose referentes ao capítulo 1

Aula 5 - 15/8/14: Modelo de serviços
Slides do Kurose referentes ao capítulo 1

Aula 6 - 19/8/14: Arquitetura em camadas - Exercícios
Slides do Kurose referentes ao capítulo 1

Aula 7 - 22/8/14: Laboratório 1: Uso de aplicações da Internet
Laboratório 1 -- Ping, traceroute, Web e HTTP

Aula 8 - 26/8/14: Comunicação entre processos

Aula 9 - 29/8/14: Protocolos da camada de aplicação - Laboratório 2: Wireshark e HTTP

Laboratório 2 -- Wireshark e HTTP

Aula 10 - 2/9/14: HTTP - FTP - SMTP

Slides do Prof. Emerson - DNS, FTP, Web, Email...

Aula 11 - 5/9/14: DNS - Laboratório 3: Serviço de nomes

Laboratório 3

Aula 12 - 9/9/14: Laboratório 3 (revisão) - P2P

Laboratório 3

Aula 13 - 12/9/14: Aulas de dúvidas e listas de exercício
Listas de exercício

Aula 14 - 16/9/14: Avaliação 1: conceitos básicos e camada de aplicação
Sala 12

Aula 15 - 19/9/14: Laboratório 4 - Programação de sockets
Laboratório 4

Aula 16 - 23/9/14: Camada de transporte

Faça uma rápida pesquisa e descubra que protocolos de transporte (e que portas) são usados por estas aplicações:

SSH
FTP
BitTorrent
emule
WINS
Compartilhamento de arquivos do Windows
Windows Terminal Service
NFS
Openvpn
RADIUS
DHCP
SNMP
NTP
LDAP
Mysql
Postgresql
Oracle RDBMS
Syslog
CUPS

Que protocolo de transporte predomina nesse conjunto? Qual a sua justificativa para isso?

Aula 17 - 26/9/14: Camada de transporte - Princípios da comunicação confiável de dados

Execute o applet GbN no site do Kurose. Faça alguns testes e tente entender os processos envolvidos.

Aula 18 - 30/9/14: Camada de transporte - Princípios da comunicação confiável de dados e TCP
Slides Capitulo 3

Aula 19 - 3/10/14: Aula suspensa - Defesa de tese

Aula 20 - 7/10/14: Camada de transporte - TCP e Laboratório TCP x UDP

Laboratório 5

Aula 21 - 10/10/14: Camada de transporte - Controle de fluxo e controle de congestionamento
Slides Capitulo 3

Aula 22 - 14/10/14: Aulas suspensas - Seminário de avaliação do curso de Engenharia de Telecomunicações
Slides Capitulo 3

Aula 23 - 17/10/14: Aulas de dúvidas e listas de exercício

Listas de exercício

Aula 24 - 21/10/14: Avaliação 2: Camada de transporte
Sala 12

Aula 25 - 24/10/14: Introdução a Camada de rede
Slides Capitulo 4

Aula 26 - 31/10/14: Camada de rede

Reforço para preparação dos seminários

Applet IP Fragmentation

Aula 27 - 4/1/14: Camada de rede
Slides Capitulo 4

Aula 28 - 7/11/14: Camada de rede - Protocolos de roteamento. Lab. tabelas estáticas de roteamento com NetKit2

Laboratório 6

Aula 29 - 11/11/14: Camada de rede - Protocolos de roteamento. Lab. protocolos de roteamento RIP e OSPF com NetKit2

Laboratório 6

Aula 30 - 14/11/14: Camada de rede - Protocolos de roteamento. Lab. protocolos de roteamento RIP e OSPF com NetKit2