RED29004-2016-2
Diário de aula de RED29004 - 2016-2 - Prof. Odilson T. Valle
Dados Importantes
Professor: Odilson Tadeu Valle
Email: odilson@ifsc.edu.br
Atendimento paralelo: 3ª das 15h40 às 16h35 e 6ª das 9h40 às 10h35. Local: Lab. de Desenvolvimento.
- Avaliações
- 3 avaliações (A1, A2 e A3) mais um seminário (S).
- Conceito mínimo para não necessitar reavaliação: 6.
- Conceito final obtido pela "média" das avaliações.
- Reavaliação única a ser realizada no último dia de aula.
IMPORTANTE: o direito de recuperar uma avaliação em que se faltou somente existe mediante justificativa reconhecida pela coordenação. Assim, deve-se protocolar a justificativa no prazo de 48 horas, contando da data e horário da avaliação e aguardar o parecer da coordenação.
Plano de Ensino
Cronograma de Atividades
RED29004 2016-2 - Prof. Odilson T. Valle
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 |
---|
|
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
Roteiros para laboratório
Laboratório 1 - Ping, Traceroute e Wireshark |
---|
Objetivos
Conceitos introdutórios para uso do laboratórioA rede do laboratório em uso segue o modelo apresentado no diagrama da Figura 1. Máquinas virtuaisEventualmente serão utilizadas nessa disciplina. Os Laboratórios de Redes de Computadores estão equipados com N+1 (N = número de computadores para alunos) computadores conectados em rede e com acesso a Internet, Figura 1. A rede local do laboratório tem endereço IP 192.168.1.0/24. A máscara de rede /24 indica que o último byte do endereço é utilizado para identificar cada máquina, por exemplo 192.168.1.1, 192.168.1.2, etc. O sistema operacional hospedeiro é o Linux Ubuntu. Como os laboratórios são utilizados por várias disciplinas/alunos/professores, os usuários não tem acesso a senha de root (administrador). Para possibilitar a execução de comandos exclusivos do administrador (usuário root), cada computador tem instaladas máquinas virtuais, as quais podem ser lançadas a partir do aplicativo VirtualBox. As máquinas virtuais pertencem a mesma rede local do laboratório e tem endereçamento 192.168.1.x, sendo o byte que identifica a máquina (x) deverá ser manualmente configurado com a seguinte regra: M1 – 101, M2 – 102,..., M9 – 109, M10 – 110,..., M14 – 114 . Por exemplo:, M1 ficará com o endereço 192.168.1.101. Roteiro de atividadesifconfigO aplicativo ifconfig pode ser utilizado para visualizar a configuração ou configurar uma interface de host em redes TCP/IP. Se nenhum argumento for passado na chamada do ifconfig, o comando mostra a configuração atual de cada interface de rede. Consultar as páginas man ifconfig do Linux para maiores detalhes sobre o funcionamento deste aplicativo, o qual permite ativar/desativar a interface, configurar o endereço IP, definir o tamanho da MTU, redefinir o endereço de hardware se a interface suporta, redefinir a interrupção utilizada pelo dispositivo, entre outros.
|
Laboratório 2 - Desvendando o HTTP com Wireshark |
---|
Fonte base: Wireshark - HTTP Objetivos
A Interação Básica GET/Resposta do HTTPVamos iniciar a nossa exploração do HTTP baixando um arquivo em HTML simples - bastante pequeno, que não contém objetos incluídos. Faça o seguinte:
O exemplo da figura 1 mostra na janela de listagem de pacotes duas mensagens HTTP capturadas:
Responda às seguintes perguntas e imprima as mensagens GET e a resposta e indique em que parte da mensagem você encontrou a informação que responde às questões.
A Interação HTTP GET Condicional/RespostaA maioria dos navegadores web tem um cache (seção 2.2.6 do livro) e, desta forma, realizam GET condicional quando baixam um objeto HTTP. Execute os seguintes passos:
Responda às seguintes questões:
Baixando Documentos LongosNos exemplos até agora, os documentos baixados foram simples e pequenos arquivos em HTML. Vamos ver o que acontece quando baixamos um arquivo em HTML grande. Faça o seguinte:
Na janela de listagem de pacotes, você deve ver a sua mensagem HTTP GET, seguida por uma reposta em vários pacotes. Esta resposta em vários pacotes merece uma explicação. Lembre-se da seção 2.2 do livro (veja a figura 2.9) que a mensagem de resposta HTTP consiste de uma linha de status, seguida por zero ou mais linhas de cabeçalhos, seguida por uma linha em branco, seguida pela carga útil (Content-Length). No caso do nossa HTTP GET, a carga útil na resposta é o arquivo HTTP completo. No nosso caso aqui, o arquivo em HTML é bastante longo, e a informação de 11747 bytes é muito grande para caber em um segmento TCP. A resposta HTTP simples é então quebrada em vários pedaços pelo TCP, com cada pedaço sendo contido dentro de um segmento TCP separado. Cada segmento TCP é capturado em um pacote separado pelo Wireshark, clique sobre o nono "Reassembled TCP Segments" no Wireshark. Responda às seguintes questões:
Documentos HTML com Objetos IncluídosAgora que vimos como o Wireshark mostra o tráfego capturado para arquivos em HTML grandes, nós podemos observar o que acontece quando o seu browser baixa um arquivo com objetos incluídos, no nosso exemplo, imagens que estão armazenadas em outros servidores. Faça o seguinte:
Responda às seguintes questões:
HTTPSPara finalizar, vamos capturar sequências de mensagens HTTPS, somente a título de comparação. Execute os seguintes procedimentos:
Responda:
|
Laboratório 3 - Serviço de Nomes (DNS) |
---|
ObjetivosO Domain Name System (DNS) traduz nomes de hosts em endereços Internet Protocol (IP), preenchendo uma lacuna crítica na infraestrutura da Internet. Neste laboratório, observaremos mais de perto:
Lembre-se de que o papel do cliente no DNS é relativamente simples - um cliente envia uma consulta ao seu DNS, e obtém uma resposta. Muito pode acontecer “por baixo dos panos”, de forma invisível aos clientes DNS, enquanto os servidores DNS, organizados hierarquicamente, comunicam-se entre si para, ou recursivamente ou iterativamente, resolver uma consulta DNS de um cliente. Do ponto de vista do cliente DNS, contudo, o protocolo é bastante simples - uma consulta é feita ao seu servidor DNS e uma resposta é recebida deste servidor. Consultas DNS por meio de ferramentas especializadas
|
Exemplos de arquivos DNS
/etc/bind/db.redes
$TTL 86400
@ IN SOA ns.redes.edu.br. root (
2016090900 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
@ IN NS ns.redes.edu.br.
@ IN MX 10 mail.redes.edu.br.
$ORIGIN redes.edu.br.
ns A 192.168.1.101
www A 192.168.1.102
ftp A 192.168.1.103
mail A 192.168.1.104 </syntaxhighlight>
/etc/bind/db.2.168.192 (Zona reversa)
$TTL 86400
@ IN SOA ns.redes.edu.br. root (
2016090900 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
IN NS ns.redes.edu.br.
101 IN PTR ns.redes.edu.br.
102 IN PTR www.redes.edu.br.
103 IN PTR ftp.redes.edu.br.
104 IN PTR mail.redes.edu.br. </syntaxhighlight>
Laboratório 4 - Entendendo sockets
Objetivos
Entender o conceito de sockets.
Processos que rodam em máquinas diferentes se comunicam entre si enviando mensagens para sockets. Um processo é semelhante a uma casa e o socket do processo é semelhante a uma porta. A aplicação reside dentro da casa e o protocolo da camada de transporte reside no mundo externo. Um programador de aplicação controla o interior da casa mas tem pouco (ou nenhum) controle sobre o exterior.
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 via sockets, que abstrai qualquer necessidade de conhecimento das camadas subjacentes.
Roteiro
- Observe que uma mesma máquina pode fazer o papel de cliente e servidor simultaneamente.
- Escreva o programa UDPServer.py
- Esta linha define que pode-se utilizar sockets dentro do programa
from socket import *
- Define explicitamente a porta aberta servidor
serverPort = 22222
- Cria o socket do servidor, denominado serverSocket. 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, ou seja, eh um socket UDP.
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 por contatos (mensagens) de 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>
- No terminal da máquina execute o programa:
python UDPServer.py </syntaxhighlight> Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza eh sintaxe. Deixe o programa rodando nesse terminal.
- Abra um novo terminal e escreva o programa 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.
- Lembre-se de ajustar ip_do_servidor para o numero adequado, ou seja, o IP de sua maquina ou de seu vizinho.
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 endereco 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>
- No terminal da máquina execute o programa:
python UDPClient.py </syntaxhighlight> Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza é sintaxe.
- Digite a mensagem que deseja e espere a resposta do servidor. Funcionou?
- Rode o WireShark.
- Execute novamente o cliente e servidor, se necessário, 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. Outra possibilidade de filtro é o filtro por número de porta: udp.port == 22222
- É possível capturar toda a troca de mensagens e inclusive capturar o texto passado do cliente para o servidor?
- Qual é o protocolo nessa troca de mensagens?
- Qual são os dois números de porta e os dois IPs utilizados?
- Quem definiu o número de porta do cliente?
- Combine com um colega e faça testes entre a sua máquina e dele. Num momento você é o servidor e noutro você é o cliente.
- Capture todos os pacotes trocados, entre você e seu vizinho, e responda as mesmas questões anteriores. Os números de portas e IPs são ou não iguais? Explique.
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, primeiramente eles 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:
Roteiro
- Escreva o código do programa servidor. 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>
- No terminal da máquina execute o programa:
python TCPServer.py </syntaxhighlight> Caso dê uma mensagem de erro, tente entende-la e corrija o problema. Com certeza é sintaxe. Deixe o programa rodando nesse terminal.
- Pode-se testar se a porta está aberta:
nmap -p33333 ip_do_servidor </syntaxhighlight>
- Abra um novo terminal e escreva o programa cliente. 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>
- Digite a mensagem que deseja e espere a resposta do servidor. Funcionou?
- Rode o WireShark.
- Execute novamente o cliente e servidor, se necessário, 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. Ou um filtro por número de porta.
- É possível capturar toda a troca de mensagens e inclusive capturar o texto passado do cliente para o servidor?
- Qual é o protocolo nessa troca de mensagens?
- Qual são os números de porta e os IPs utilizados?
- Quem definiu o número de porta do cliente?
- Combine com um colega e faça testes entre a sua máquina e dele. Num momento você é o servidor e noutro você é o cliente.
- Capture todos os pacotes trocados, entre você e seu vizinho, e responda as mesmas questões anteriores. Os números de portas e IPs são ou não iguais? Explique.
- Discuta: diferenças observadas entre os protocolos UDP e TCP?
Desafios para casa
- 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
Objetivos
O objetivo desses experimentos é evidenciar as diferenças entre os protocolos TCP e UDP.
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 realizada baseada no tipo de comunicação a ser feita pela aplicação.
Experimento 1
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.
- Em ambos os experimentos deixe o WireShark capturando pacotes somente durante a transferência do arquivoTCP e arquivoUDP.
- A primeira transferência será feita usando o protocolo TCP da seguinte forma:
- No computador receptor execute o netcat (utilize man nc para saber os detalhes das flags utilizadas) que abrirá uma conexão TCP na porta, por exemplo, 5555 e salvará os dados transferidos em arquivo:
nc -vvnl 5555 > arquivoTCP
- No computador transmissor execute:
time nc -vvn ip_do_receptor 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?
- Analisando a captura de pacotes do WireShark responda:
- Qual é o identificar do primeiro e do último pacote?
- É possível calcular o tamanho do arquivo pela análise dos pacotes? Qual é a maneira mais fácil? Apresente os cálculos.
- 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/~odilson/RED29004/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:
wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/transmissor
chmod +x transmissor
./transmissor ip_do_receptor 5555 < ubuntu.iso
- Quando completar a transferência (vai aparecer a mensagem no transmissor "Levou XXXXX segundos para transmitir XXXXX bytes), no receptor digite <CTRL + C>, verifique o tamanho do arquivo recebido. Ele é igual ao arquivo original? E quanto tempo levou para transmiti-lo?
- Analisando a captura de pacotes do WireShark responda:
- Qual é o identificar do primeiro e do último pacote? Existe?
- É possível calcular o tamanho do arquivo pela análise dos pacotes? É mais fácil ou difícil que no caso da transferência via TCP?
- 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.
- Todos devem executar este procedimento ao mesmo tempo. Abra um terminal em seu computador, e nele execute este comando, só tecle <Enter> quando o professor determinar:
wget http://tele.sj.ifsc.edu.br/~odilson/RED29004/arq2.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, 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:
- Abra dois terminais. No terminal 1 execute este comando:
watch -n 1 ls -l arquivo
... e no terminal 2: ./receptor 5555 > arquivo
- Fique observando o terminal 1. O professor irá transmitir o arquivo a partir do servidor remoto, um processo para cada aluno. No terminal 1 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.
- Em que valor o tamanho do arquivo parou de crescer? Quanto tempo isso levou, aproximadamente? E esse tamanho final é o mesmo do arquivo original?
- Como se comportaram as transferências usando TCP e UDP?
Experimento 3
Repita os passos 1 e 3 do experimento 2 (anterior) 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 (pode ser em casa)
Use o aplicativo NetCat (nc) para fazer transferências UDP e responda (utilize o man para os comandos, boa parte da respostas estão lá):
- Qual o procedimento no lado transmissor e receptor?
- Consegue-se medir o tempo de maneira automática? Por que sim ou por que não?
- Por que os processos não param ao final da transferência como no experimento 1?
Laboratórios 6 e 7 - Protocolos de roteamento
Objetivos
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 atingir tais objetivos utilizaremos o netkit2. Leia o tutorial de 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: 1 h
- 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.
- 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 5.2 e 5.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) 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 5.3 e o wireshark (ou tcpdump) do item 5.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ê?
- 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 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?
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 e releia o arquivo de configuração exp1.conf.
- Repita o item 5.4 do Experimento 1.
- 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 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 rela é a mesmoa 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 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 netstat -r verifique a anote as rotas de cada roteador.
- Pare todos os pings.
- Execute tcpdump -i any -w /hostlab/ripr1.pcap & no r1
- 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. Olhe com atenção os IPs e as métricas apresentadas. O que dizem essas mensagens?
- 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-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 (reload), a recuperação das rotas leva em torno de 1 min:
- Quais as mensagens trocadas pelo protocolo RIP observadas no WireShark?
- Qual o tempo aproximado para a total recuperação das rotas?
- 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 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 19 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 no IPv6
Este roteiro foi baseado no material disponível em [1].
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 IP 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
- Definicao da quantidade de memoria disponivel para cada pc.
pc1[mem]=32
pc2[mem]=32
pc3[mem]=32
pc4[mem]=32
r1[mem]=64
r2[mem]=64 </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 2001:bcc:1f0:1::104 </syntaxhighlight>
- Obteve sucesso? Sim ou não e por quê?
- Faça um ping6 entre o pc1 ao pc2.
- Obteve sucesso? Sim ou não e 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.
- Configure os roteadores para habilitar o repasse de pacotes entre as interfaces utilizando os seguintes comandos:
- r1: echo 1 > /proc/sys/net/ipv6/conf/eth0/forwarding
- r1: echo 1 > /proc/sys/net/ipv6/conf/eth1/forwarding
- r1: echo 1 > /proc/sys/net/ipv6/conf/eth2/forwarding
- r2: echo 1 > /proc/sys/net/ipv6/conf/eth0/forwarding
- r2: echo 1 > /proc/sys/net/ipv6/conf/eth1/forwarding
- 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>
- 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.
- Verifique as diferenças dos cabeçalhos de um pacote IPv4 e de um pacote Ipv6, comparando capturas do wireshark.
- A partir das capturas obtidas, explique o processo de descoberta de vizinhança (neighbor discovery / request e reply), citando os endereços de multicast e link local utilizados.
- Explique a tabela de roteamento do r1, em especial os endereços de link local. Porque não há confusão dos prefixos? Explique também o uso dos prefixos diferentes para os pc1 e pc2. Por que não foi utilizado o mesmo prefixo?
- É possível utilizar os comandos route e ifconfig para configurar redes IPv6? Pesquise rapidamente no google e tente realizar a configuração do pc4 utilizando estes comandos. Para isso, use o comando ip addr flush dev eth0 no pc4 para limpar toda a configuração de endereços e rotas da interface. Depois disso configure o endereço com ifconfig e as rotas com o comando route.
- 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.
- CORE Network Emulator
- Vários laboratórios virtuais do NetKit, prontos para uso, que focam em serviços específicos de redes de computadores.
Curiosidades
- Monitoramento do tráfego RNP - PoP-SC
- Monitoramento do tráfego RNP - Nacional
- Rede Clara Internacional
- Animated map shows the undersea cables that power the internet
- Submarine Cable Map 2015
- 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
- IPv6 no Brasil
- Laboratório de IPv6 - Livro didático contendo vários roteiros para entendimento do IPv6
- HTTP/2 Frequently Asked Questions
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
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 2016-2:
- ????
- Avaliação
- Nota: 0,5 x Documento + 0,5 x Seminário
- Critérios de avaliação
- Instruções sobre o Seminário de Redes I:
- Data para definição de grupos e temas: ????.
- 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: ???? (impreterivelmente).
- O relatório pode ser redigido como uma página da wiki.
- Duração da apresentação: 20 minutos (limitantes: 15 a 25 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 - 11/08/2016: 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
- Plano de Ensino, Ementa, Estratégia de Ensino e Bibliografia
- 3 avaliações (A1, A2 e A3) mais um Seminário de tema livre (S)
- Conceito mínimo final para não necessitar reavaliação: 6.
- Conceito final obtido pela "média" das avaliações.
- Reavaliação única no último dia de aula.
- Cronograma de atividades com datas de avaliações
- Relação com outras disciplinas do curso
- Apresentação do Seminário
- Definição datas assim que o calendário estiver divulgado
- Definição de temas é livre, pensem sobre o assunto.
- Qual o grande objetivo das redes de computadores?
- Como é formada uma rede de computadores?
- Curiosidades
- Introdução às redes de computadores
Aula 2 - 16/08/2016: Aula suspensa devido a participação no Treinamento em Tecnologia FPGA Altera.
Aula 3 - 18/08/2016: Aula suspensa devido a participação no Treinamento em Tecnologia FPGA Altera.
Aula 4 - 23/08/16: Redes de Computadores e a Internet
Aula 5 - 25/08/16: Redes de Computadores e a Internet e Visita ao PoP São José da RNP
Aula 6 - 30/08/16: Laboratório 1: Ping, Traceroute e Wireshark
Aula 7 - 01/09/16: Redes de Computadores e a Internet e Camada de Aplicação
Aula 8 - 06/09/16: Camada de Aplicação
Aula 9 - 08/09/16: Laboratório 2: Desvendando o HTTP com Wireshark
Aula 10 - 13/09/16: Camada de Aplicação
Aula 11 - 15/09/16: Laboratório 3: Serviço de Nomes (DNS)
Aula 12 - 20/09/16: Camada de Aplicação e dúvidas para a primeira avaliação.
Aula 13 - 21/09/16: Primeira avaliação