Projeto de Redes IIIII

Prévia do material em texto

PROJETOS DE REDES I - 
ANÁLISE DE DESEMPENHO DE 
REDE 
AULA 5 
 
 
 
 
 
 
 
 
 
 
 
Prof. Luis José Rohling 
 
 
2 
CONVERSA INICIAL 
Para que possamos realizar o processo de análise do desempenho das 
redes é necessário que tenhamos conhecimento de quais serão os protocolos 
trafegados, bem como o comportamento dos protocolos empregados nos 
processos de comunicação pela rede. Assim, nesta aula estudaremos o 
comportamento dos principais protocolos utilizados nas redes de dados, bem 
como as especificações destes protocolos, o que nos permitirá determinar qual 
deverá ser o desempenho esperado da rede, bem como permitirá avaliarmos se 
a rede foi dimensionada adequadamente para suportar este tráfego. 
E para esta análise podemos empregar o modelo OSI de referência, para 
identificarmos as relações entre os protocolos das diversas camadas e como 
estas relações irão impactar no desempenho da rede. Um exemplo disto é o 
processo comunicação em Broadcast, empregado por muitos protocolos, e que 
afeta significativamente a rede. E a forma como cada um dos protocolos 
implementa estes mecanismos de comunicação em Broadcast irá afetar o 
desempenho da rede, bem como a integração entre os protocolos para este 
processo de comunicação. 
Figura 1 – O modelo OSI 
 
Fonte: Rohling, 2021. 
O estudo do comportamento dos protocolos nos auxiliará também na 
utilização das ferramentas de simulação, tais como o NS3, pois para a execução 
APRESENTAÇÃO 
APLICAÇÃO 
SESSÃO 
REDE 
TRANSPORTE 
ENLACE DE DADOS 
FÍSICA 
6 
7 
5 
3 
4 
2 
1 
 
 
3 
dos projetos de simulação é necessário que façamos a parametrização do 
processo de comunicação, tal como a quantidade de pacotes enviados e o 
intervalo de tempo de envio, conforme vimos anteriormente. Assim, 
considerando-se a utilização do NS3 ao especificarmos as aplicações, que são 
as classes identificadas como “Application”, será necessário definirmos os 
parâmetros da classe utilizada, inerentes de cada uma dessas. E como estas 
classes visam representar o comportamento dos protocolos reais, é necessário 
conhecermos o comportamento do protocolo empregado, para que possamos 
efetivamente criar um ambiente de simulação que seja semelhante ao ambiente 
real da rede. Caso contrário, podermos validar o projeto, obtendo o desempenho 
desejado no ambiente de simulação, porém, ao implementarmos o projeto no 
ambiente real, poderemos não obter o desempenho esperado, em função da 
parametrização incorreta dos protocolos no ambiente do simulador. 
Inclusive, para aprimorarmos o processo de análise, podemos empregar 
mais de uma ferramenta de simulação, obtendo o melhor resultado de cada uma 
delas. Assim, por exemplo, poderíamos utilizar o Packet Tracer para 
visualizarmos as informações dos cabeçalhos dos pacotes, de uma maneira 
mais abrangente, e utilizarmos o NS3 para simularmos e avaliarmos o 
desempenho mais detalhado dos protocolos, de uma maneira mais pontual. 
Além disso, podemos também utilizar a ferramenta de captura e análise de 
protocolos que é o Wireshark, para obtermos uma amostragem de uma rede real. 
Assim, poderemos verificarmos se foram incluídos todos os protocolos que estão 
sendo trafegados na rede, bem como para verificarmos quais são os parâmetros 
empregados por estes protocolos, para realizarmos a parametrização completa 
dos mesmos no ambiente de simulação. 
TEMA 1 – O PROTOCOLO TCP/IP 
Nas redes de dados atuais temos o predomínio do protocolo TCP/IP, e 
certamente o ponto de partida para o estudo dos protocolos que impactam no 
desempenho da rede é o protocolo IP, que é empregado por praticamente todas 
as aplicações que estão trafegando em nossas redes. E o protocolo IP é descrito 
pelo IETF, e está incluído em um modelo de rede chamado de TCP/IP, conforme 
mostrado na figura abaixo. 
 
 
 
4 
Figura 2 – As camadas do modelo TCP/IP 
 
Fonte: Rohling, 2021. 
Assim, teremos o protocolo IP, que é o “Internet Protocol”, sendo 
executado na camada chamada de Internet, coincidindo com o nome da própria 
camada. E esta camada de Internet no modelo TCP/IP é equivalente à camada 
de Rede do modelo OSI, que é a camada três, conforme mostrado na figura 1. 
Para que ocorra a comunicação entre os dispositivos, através do 
Protocolo IP, é necessário que cada terminal tenha um endereço exclusivo. 
Porém, como a versão atual do protocolo IP, que é o IPv4, já praticamente 
esgotou todos os endereços disponíveis para a comunicação utilizando a 
Internet, uma mudança que está ocorrendo é a migração para a nova versão do 
protocolo IP, que é o IPv6. E uma das mudanças implementadas pelo IPv6 é o 
aumento da quantidade de endereços, pois o endereço IPv4 é um valor de 24 
bits e o IPv6 utiliza endereços de 128 bits. Com esta mudança, a quantidade de 
endereços deverá suprir toda a expansão possível da Internet, inclusive com a 
implementação da chamada Internet das Coisas (IoT – Internet of Things). 
Assim, já teremos um impacto no desempenho da rede, em relação ao cabeçalho 
dos pacotes IP, como veremos adiante. 
E o outro protocolo amplamente utilizado nas redes TCP/IP é o protocolo 
TCP – Transport Control Protocol, que implementa as funcionalidades de 
camada quatro do modelo OSI, que é a camada de transporte, e que tem a 
mesma designação no modelo TCP/IP. A camada de transporte tem como 
Acesso à rede 
Internet 
Transporte 
Aplicação 
 
 
5 
responsabilidade o controle do tráfego das diversas sessões, de modo que 
possam ser tratadas pela camada de rede. Como podemos ter diversas sessões 
abertas simultaneamente, a camada de transporte terá que identificar cada uma 
delas, de modo que quando as respostas retornarem, ela possa entregar os 
dados para a aplicação correta. E esta identificação é feita com o uso do 
chamado número de porta. Neste processo de comunicação, teremos um 
número de porta tanto do lado do emissor quando do receptor. Além da 
identificação das sessões, por meio do número de porta, a camada de transporte 
também deverá adequar os dados a serem transmitidos à capacidade de 
transmissão da rede. Este processo exige duas tarefas adicionais para os 
protocolos de transporte, que são a segmentação e o controle de fluxo. E estas 
duas funcionalidades é que impactarão significativamente no desempenho da 
rede, como veremos adiante. 
1.1 O comportamento do protocolo DHCP 
Conforme vimos anteriormente, para que ocorra a comunicação entre os 
dispositivos, com a utilização do Protocolo IP, é necessário que cada terminal 
tenha um identificador exclusivo, que é o seu endereço IP. E para facilitar o 
processo de configuração deste endereçamento, é utilizado o protocolo DHCP, 
cujo mecanismo de operação irá impactar significativamente as redes, em 
função da quantidade de dispositivos conectados na rede. 
O processo de comunicação baseado no protocolo IP poderá ser 
monitorado na rede com a filtragem dos endereços desejados, normalmente 
visando a determinação da quantidade de tráfego que está sendo demandada 
por um determinado terminal de usuário ou de um servidor. Assim, o critério 
básico será a filtragem do endereço de origem ou de destino, de acordo com a 
direção do tráfego associado ao terminal que estamos analisando. Portanto, em 
relação ao protocolo IP em si, não teremos nenhuma análise mais complexa que 
possa ser realizada, para avaliarmos o desempenho da rede LAN, pois os 
demais cabeçalhos do protocolo IP estão associados aos processos intrínsecos 
do processo de comunicação, e que, eventualmente, podem ser utilizados para 
avaliação da rede WAN, ou seja, pelos profissionais que atuam nos provedores 
de serviço de Internet. 
Assim, o processo associado ao protocolo IP que certamente causa um 
grande impacto em nossas redes é processo de configuração inicial dos hosts, 
 
 
6 
que é realizado pelo protocolo DHCP. O DHCP, que é a sigla para “Dynamic Host 
Configuration Protocol”,é um protocolo de rede que fornece o endereçamento 
IP de forma automática, além de outras informações para os clientes DHCP. 
Assim, as informações básicas fornecidas são: o endereço IP; a máscara de 
Sub-rede, para o protocolo IPv4, ou tamanho do prefixo, para o protocolo IPv6; 
o endereço de gateway padrão e o endereço do servidor DNS. E o protocolo 
DHCP pode ser utilizado tanto para o protocolo IPv4 quanto para o protocolo 
IPv6. 
Para o processo de configuração dos hosts, temos a troca de mensagens 
entre o cliente e o servidor, conforme mostrado na figura abaixo. 
Figura 3 – As mensagens do protocolo DHCP 
 
Fonte: Rohling, 2021. 
Ao inicializarmos um terminal de usuário, caso a configuração do 
protocolo IP esteja definida como automática - DHCP, no sistema operacional, 
teremos o envio da mensagem inicial do processo, que é a mensagem 
DHCPDISCOVER. E como o host não tem nenhuma informação sobre o 
servidor, é necessário que ele faça o envio desta mensagem utilizando o 
mecanismo de broadcast. Desta forma, todos os terminais de usuários irão gerar 
um tráfego de broadcast cada vez que são inicializados ou conectados à rede, o 
que poderá afetar o desempenho da rede, caso tenhamos muitos terminais 
conectados à rede. E este processo de comunicação será realizado com o 
mecanismo de envio de broadcast de camada dois e de camada três, para as 
 
 
7 
quatro mensagens trocadas entre cliente e servidor. Portanto, para realizarmos 
a filtragem deste tráfego, a partir do endereço de rede, deveremos especificar o 
endereço IP de destino igual a 255.255.255.255, ou o endereço MAC de destino 
o endereço FF:FF:FF:FF:FF:FF. 
No exemplo de captura mostrado na figura abaixo, realizado com o 
Wireshark e aplicado o filtro para o protocolo DHCP, podemos visualizar este 
processo de envio de mensagens. Para esta geração das mensagens foi 
realizada inicialmente uma liberação do endereço IP que já havia sido 
configurado, na inicialização do host, e para isto foi utilizado o comando 
“ipconfig/release”. Em seguida foi utilizado o comando “ipconfig/renew” para 
forçar a realização de um novo processo de configuração automática do 
endereço IP, forçando a execução do protocolo DHCP. 
Figura 4 – Captura das mensagens do protocolo DHCP 
 
Fonte: Rohling, 2021. 
Na figura podemos observar que todas as mensagens são enviadas em 
broadcast de camada três e que o endereço de origem utilizado pelo cliente é o 
endereço 0.0.0.0 pois o host não tem um endereço IP configurado. 
1.2 O impacto do protocolo DHCP na rede 
Para avaliarmos o impacto do tráfego na rede é necessário verificarmos 
se o processo de comunicação está ocorrendo efetivamente por meio de um 
broadcast de camada dois, pois isto fará com que os quadros Ethernet, que 
encapsulam as mensagens do processo de DHCP, sejam enviados pelos 
switches da rede para todas as portas onde tivermos equipamentos conectados. 
Ou seja, as quatro mensagens trocadas entre o cliente e servidor serão enviadas 
para todos os hosts e servidores conectados na rede LAN. 
 
 
8 
Assim, a partir da captura efetuada, e mostrada na figura abaixo, podemos 
verificar, no detalhamento do pacote referente à mensagem DHCP Discover, que 
esta mensagem foi enviada para o endereço de destino que equivale ao 
endereço MAC de broadcast, que é o ff:ff:ff:ff:ff:ff. 
Figura 5 – Mensagem DHCP Discover 
 
Fonte: Rohling, 2021. 
Portanto, este quadro Ethernet será enviado por toda a rede, e entregue 
a todos os dispositivos conectados à rede LAN, ocupando todas as conexões da 
rede e todos os dispositivos de rede. E como o endereço de camada três também 
é um endereço de broadcast, todos os hosts processarão este pacote IP, o que 
também ocupará o processamento de todos os computadores conectados na 
rede. Portanto, estas mensagens irão impactar não apenas as conexões de rede, 
mas o processamento de todos os dispositivos terminais de usuário conectados 
na rede. 
E para minimizarmos este impacto na rede, já que o processo de DHCP 
é uma funcionalidade básica do protocolo de rede, para a correta configuração 
dos hosts, e não pode ser desabilitado, a solução será a segmentação da rede, 
com a configuração de VLANs. Assim, o tráfego de broadcast gerado por um 
 
 
9 
host, ao executar o protocolo DHCP, irá impactar em uma quantidade menor de 
hosts, na VLAN onde está conectado. 
Outro critério que pode ser empregado para a filtragem deste protocolo 
são as informações associadas às portas empregadas, bem como o protocolo 
de transporte utilizado pelo processo DHCP. E estas informações também 
podem ser verificadas na captura dos pacotes realizada, conforme mostrado 
abaixo. 
Figura 6 – Portas do protocolo DHCP 
 
Fonte: Rohling, 2021. 
Na figura acima podemos verificar que o protocolo de transporte utilizado 
pelo protocolo DHCP é o protocolo UDP – User Datagram Protocol, e que as 
portas utilizadas são a porta 68, como porta de origem, no lado do cliente, e a 
porta 67 como porta de destino, no lado do servidor. Assim, para filtrarmos o 
tráfego já no processo de captura, capturando apenas as mensagens do 
protocolo DHCP poderemos utilizar como critério as portas UDP de destino, que 
deverão ser as portas 67 e 68. 
TEMA 2 – O PROTOCOLO TCP 
No modelo TCP/IP temos basicamente dois protocolos distintos para a 
camada de transporte, que são o TCP e o UDP, que empregam mecanismos de 
comunicação diferentes, sendo que o protocolo TCP é chamado de protocolo 
orientado à conexão. E além do estabelecimento da sessão, outro mecanismo 
 
 
10 
implementado pelo TCP é o controle de fluxo das sessões. Assim, estes dois 
processos, que são o estabelecimento de conexão e o controle de fluxo, é que 
irão impactar no desempenho da rede. Portanto, para avaliarmos o impacto na 
rede é necessário conhecermos estes processos em detalhes, o que faremos 
neste capítulo. 
Outra tarefa dos protocolos da camada de transporte é a chamada 
multiplexação das aplicações das camadas superiores, o que é realizado com a 
utilização dos identificadores, que são os números de portas. E este processo 
de identificação das sessões já foi abordado anteriormente, cujo conhecimento 
é essencial para a elaboração do processo de filtragem do tráfego, para a análise 
do tráfego capturado ou para o processo de captura, com ferramentas tais como 
o Wireshark. Porém, em relação ao desempenho da rede, estes números de 
porta não terão nenhum impacto, sendo importante o seu conhecimento apenas 
para o processo de filtragem do tráfego. 
Para o processo de estabelecimento das sessões, conforme vimos 
anteriormente, o protocolo TCP realiza o chamado Handshake triplo, cujas 
etapas são identificadas pelos valores contidos no cabeçalho do protocolo TCP, 
no campo de flags, mostrado na figura abaixo. 
Figura 7 – O cabeçalho do protocolo TCP 
 
Fonte: Rohling, 2021. 
Os flags envolvidos no processo de inicialização da sessão são os flags 
de SYN e de ACK. E para esta inicialização das sessões, os terminais irão trocar 
as informações sobre as portas de origem e de destino, bem como os valores 
para os números de sequência e de confirmação, que são utilizados no processo 
de controle de fluxo, que é chamado de janelamento. 
Número de sequência 
Porta de Origem Porta de Destino 
Número de confirmação 
Tam. Tamanho de janela 
Checksum Ponteiro urgente 
Opções 
Reserv. Flags 
 
 
11 
2.1 O controle de fluxo 
Certamente o processo de controle de fluxo, implementado pelo protocolo 
TCP, apresenta um impacto significativo no desempenho das redes. Assim, é de 
fundamental importância que o profissional envolvido com a análise de 
desempenho de rede conheça profundamente este processo, que é baseado no 
estabelecimento de uma janela de transmissão, cuja operação veremos a seguir. 
Para garantir a confiabilidade do processo de comunicação, o mecanismo 
empregado pelos protocolos é a confirmação dorecebimento dos dados, o que 
permite a retransmissão, caso ocorra a perda de dados no processo de 
transmissão por meio da rede. Assim, sendo detectadas a perda de pacotes, 
poderá ser realizada e retransmissão dos dados perdidos, garantindo a 
confiabilidade do processo. E no modelo TCP/IP o protocolo responsável por 
implementar este processo, para garantir a confiabilidade da comunicação, é o 
protocolo TCP, que irá enviar as confirmações dos dados recebidos, utilizando o 
flag de ACK, contido no cabeçalho TCP. 
Figura 8 – Confirmação de recebimento 
 
Fonte: Rohling, 2021. 
A confiabilidade será implementada pelo servidor, realizando a verificação 
dos dados recebidos pelas confirmações, e fazendo o envio dos segmentos 
perdidos. Assim, caso alguns dos segmentos sejam perdidos no processo de 
Cliente 
Servidor 
Pacote/segmento enviado 
Confirmação (ACK) 
 
 
12 
transmissão da rede, estes segmentos serão retransmitidos pelo servidor, 
garantindo a entrega de todos os segmentos. 
2.2 A segmentação dos dados 
No processo de comunicação com o protocolo TCP, o servidor irá dividir 
os dados a serem transmitidos para o cliente, em segmentos, empregando o 
mecanismo chamado de segmentação. Este processo visa garantir que os 
segmentos possuam o tamanho máximo suportado pelo protocolo da camada 
inferior, e que assim possam ser transportados pelos pacotes IP. A cada 
segmento criado, o protocolo TCP irá anexar um identificador, que são os 
números de sequência. A partir destes números de sequência, o cliente poderá 
verificar se todos os segmentos foram recebidos, identificando eventuais pacotes 
que tenham sido perdidos no processo de transmissão usando a rede. Além 
disso, o cliente também poderá utilizar os números de sequência para reagrupar 
os segmentos recebidos, caso sejam recebidos fora de ordem. Assim, no 
processo de recebimento, o cliente TCP armazena os segmentos recebidos em 
um buffer, até que todos os segmentos sejam recebidos e reagrupados. E os 
dados são entregues à camada da aplicação somente quando todos os 
segmentos forem recebidos e reagrupados. 
Figura 9 – O processo de segmentação 
 
Fonte: Rohling, 2021. 
 
 
13 
Porém, se o servidor tiver que aguardar a confirmação do cliente, para 
cada segmento transmitido, o processo de comunicação poderá se tornar muito 
lento. Assim, o protocolo TCP utiliza um processo chamado de janelamento, 
onde é definida uma janela de transmissão, que representa a quantidade de 
bytes, ou de blocos, enviados pelo servidor até que ele aguarde o recebimento 
de uma confirmação do cliente. Por exemplo, se tivermos uma janela igual à 10, 
o servidor enviará os 10 segmentos e aguardará o recebimento de uma 
confirmação, para então enviar os demais segmentos. 
Figura 10 – Exemplo de tamanho de janela 10 
 
Fonte: Rohling, 2021. 
 
O tamanho de janela é informado no cabeçalho do protocolo do TCP, onde 
temos um campo chamado de janela, que irá informar ao cliente qual será o 
número de segmentos que o servidor irá enviar, para então aguardar uma 
confirmação. E quanto maior o tamanho da janela, maior será o desempenho do 
processo de transmissão, pois o servidor irá utilizar toda a capacidade de 
transmissão de sua conexão com a rede. Porém, o desempenho da rede e a 
capacidade de recepção e de processamento do cliente poderão ser inferiores à 
capacidade do servidor, quando teremos efetivamente o mecanismo de controle 
de fluxo do TCP, ajustando a velocidade de transmissão do cliente. 
Cliente 
Servidor 
Segmento #1 
Segmento #2 
... 
Segmento #10 
ACK 
 
 
14 
TEMA 3 – O PROTOCOLO IPV6 
O protocolo IPv6 apresenta diversas mudanças em relação ao protocolo 
IPv4, principalmente em relação ao modelo de endereçamento, incluindo o 
tamanho do identificador, que é o endereço IPv6. Para atender à demanda de 
endereçamento das redes, o tamanho do identificador dos hosts na camada de 
rede, que é o endereço IP, foi alterado dos 24 bits empregados no IPv4 para 128 
bits na versão IPv6. E para a representação deste identificador, outra alteração 
foi ao formato de representação do endereço IP, que era no modelo decimal 
separado por pontos, na versão IPv4, para a representação em hexadecimal, 
que pode ser separada por dois pontos ou por traços. 
Uma das mudanças significativas, que afetam o desempenho das redes, 
é que no protocolo IPv6 não temos mais o processo de comunicação em 
broadcast, ou seja, a versão IPv6 não possui mais um endereço de broadcast. 
No protocolo IPv6 temos três tipos de endereços, que são os endereços de 
unicast, de multicast e de anycast. E esta mudança nos tipos de endereços, na 
versão IPv6, representa uma evolução em relação ao processo de broadcast que 
era empregado pelo IPv4, para a configuração dos hosts, com o protocolo DHCP. 
Portanto, para realizarmos a análise do tráfego que esteja utilizando o 
protocolo IPv6, é necessária a configuração dos filtros do endereço de origem e 
destino no formato hexadecimal, o que apresenta uma complexidade maior do 
que no protocolo IPv4. Assim, é necessário identificarmos o endereço do host 
cujo tráfego desejamos analisar, aplicando o filtro corretamente, conforme o 
exemplo mostrado na figura a seguir. 
 
 
 
15 
Figura 11 – Filtro baseado em endereço IPv6 
 
Fonte: Rohling, 2021. 
No exemplo acima foi empregado como critério de filtragem o campo 
“ipv6.addr”, que deverá conter o endereço do host cujo endereço IPv6 é igual a 
2804:7f4:308a:d12b:9c36:c87c:ea6d:1546, tanto como endereço de origem 
quanto como endereço de destino. Assim, com a aplicação do filtro podemos 
verificar que o tráfego empregando o protocolo IPv6 representa 23% do total do 
tráfego capturado. 
3.1 Endereços ipv6 de link local 
Uma das classes de endereçamento definida pelo protocolo IPv6 são os 
endereços identificados como endereços de Link Local. Estes endereços são 
utilizados para a comunicação entre os dispositivos que estão no mesmo 
domínio de broadcast, ou seja, no mesmo enlace, que é chamado também de 
Link local. E para o endereçamento de link local o protocolo IPv6 define a 
utilização da rede fe80::/64. Assim, para filtrarmos o tráfego que utiliza este 
endereçamento, com o Wireshark, deveremos utilizar a expressão: “ipv6.addr == 
fe80::/64”. E o resultado da aplicação deste filtro é mostrado na figura abaixo. 
 
 
16 
Figura 12 – Filtragem do tráfego de Link Local. 
 
Fonte: Rohling, 2021. 
No exemplo acima podemos verificar que este tipo de tráfego corresponde 
à 19,1% do tráfego total capturado. E a partir da aplicação do filtro, definindo 
como critério o endereçamento de Link Local, poderemos identificar quais são 
os serviços e protocolos que estão efetivamente utilizando este endereçamento. 
E neste exemplo de captura podemos identificar que os protocolos que 
estão utilizando o endereçamento de Link Local são: 
• DNS – Domain Name System 
• MDNS - Multicast Domain Name System 
• LLMNR - Link-local Multicast Name Resolution 
• ICMPv6 – Internet Control Message Protocolol v6 
• SSDP - Simple Service Discovery Protocol 
3.2 O tráfego do protocolo DNS 
Um dos protocolos que utilizam o endereçamento de link local, que pode 
ser viso no exemplo anterior, é o protocolo de resolução de nomes, que é o DNS. 
E este serviço será executado quando o usuário fizer o acesso à internet, por 
 
 
17 
meio do protocolo HTTP, sendo utilizado para obtenção do endereço IPv6 do 
servidor solicitado. 
No exemplo abaixo podemos verificar os detalhes de uma solicitação DNS 
enviada para o servidor. 
Figura 13 – Consulta do protocolo DNS 
 
Fonte: Rohling, 2021. 
Neste exemplo podemos verificar que a consulta realizada foi feita para a 
resolução do nome outlook.office365.com, tendo sido enviada para o endereço 
IPv6 fe80::80c6:f1e7:60fc:8b7e, que é o endereço de lLink Local do serviço de 
DNS. 
E para visualizarmos o tráfego específico do protocoloDNS, após 
aplicação do filtro para endereços de Link Local, podemos então inserir o 
protocolo DNS na linha de digitação de filtragem do Wireshark, obtendo-se o 
resultado mostrado na figura abaixo. 
 
 
 
18 
Figura 14 – Filtragem do protocolo DNS 
 
 Fonte: Rohling, 2021. 
Neste exemplo podemos verificar que o tráfego do protocolo DNS, 
utilizando o endereçamento de Link Local do IPv6, equivale a 4,3% do tráfego 
total capturado, observado na última linha da interface do aplicativo, apresentado 
na figura acima. 
TEMA 4 – O PROTOCOLO ICMP 
Um dos protocolos que no as auxiliam no processo de diagnóstico do 
desempenho das redes é o ICMP – Internet Control Message Protocol. que é 
definido pelo IETF na RFC 792 (IETF, 1981). O protocolo ICMP estabelece as 
regras para a troca de mensagens que fornecem as informações sobre o 
processo de roteamento da rede IP. 
Uma das aplicações mais usuais do protocolo ICMP é o teste da 
conectividade pelas redes, que é realizado com a utilização das mensagens de 
“Echo Request” e “Echo Reply”. Estas mensagens são utilizadas para testar o 
acesso à um determinado destino, sendo enviada uma mensagem do tipo “Echo 
 
 
19 
Request” para o destino a ser testado o alcance, e que é respondida com uma 
mensagem de “Echo Reply”, indicando que o destino pode ser alcançado. 
Porém, além das mensagens de “Echo” que implementam um teste para 
a comunicação com um endereço específico, temos as demais mensagens do 
protocolo ICMP, que são enviadas pelos dispositivos de redes indicando 
problemas no processo de encaminhamento do tráfego. E a RFC 792 especifica 
mais de trinta mensagens que poderão ser usadas para testar ou indicar o estado 
do processo de roteamento da rede. Assim, realizando a captura/filtragem do 
protocolo ICMP, poderemos avaliar o desempenho da rede, identificando 
eventuais problemas no processo de roteamento, seja na rede interna ou na rede 
externa. 
As principais mensagens do protocolo ICMP, especificadas na RFC792, 
são mostradas na tabela abaixo, sendo que algumas destas mensagens foram 
descontinuadas (deprecated) em RFCs posteriores, conforme indicado na 
tabela. 
 
 
 
20 
Tabela 1 – Tipos de mensagens ICMP 
TIPO MENSAGEM Descontinuadas 
(deprecated) pela 
0 Echo Reply 
1 Não definida/atribuída 
2 Não definida/atribuída 
3 Destination Unreachable 
4 Source Quench RFC6633 
5 Redirect 
6 Alternate Host Address RFC6918 
7 Não definida/atribuída 
8 Echo 
9 Router Advertisement [RFC1256] 
10 Router Solicitation [RFC1256] 
11 Time Exceeded 
12 Parameter Problem 
13 Timestamp 
14 Timestamp Reply 
15 Information Request RFC6918 
16 Information Reply RFC6918 
17 Address Mask Request RFC6918 
18 Address Mask Reply RFC6918 
19 Reservada (para Security) 
20-29 Reservada (para Robustness Experiment) 
30 Traceroute RFC1393 e 
RFC6918 
31 Datagram Conversion Error RFC1475 e 
RFC6918 
32 Mobile Host Redirect RFC6918 
33 IPv6 Where-Are-You RFC6918 
34 IPv6 I-Am-Here RFC6918 
35 Mobile Registration Request RFC6918 
36 Mobile Registration Reply RFC6918 
37 Domain Name Request RFC1788 e 
RFC6918 
38 Domain Name Reply RFC1788 e 
RFC6918 
39 SKIP RFC6918 
40 Photuris[RFC2521] 
41 ICMP messages utilized by experimental mobility 
protocols such as Seamoby [RFC4065] 
 
42 Extended Echo Request [RFC8335] 
43 Extended Echo Reply [RFC8335] 
44 - 252 Não definida/atribuída 
253 RFC3692-style Experiment 1 [RFC4727] 
254 RFC3692-style Experiment 2 [RFC4727] 
255 Reservada 
 
Fonte: Rohling, 2021, 
 
 
 
 
 
21 
4.1 O ICMPV4 
Para realizarmos o teste de conectividade, entre hosts que esteja 
utilizando o protocolo IPv4, o comando a ser utilizado é o ping <endereço>. 
Assim, para testar a resposta do servidor que está utilizando o endereço 
186.192.90.12, o comando a ser utilizado é o ping 186.192.90.12. E ao executar 
o comando de ping serão enviadas quatro mensagens de “Echo Request”, sendo 
que as respostas de “Echo Reply” também incluirão a informação de tempo de 
resposta das mensagens, conforme mostrado abaixo. 
Figura 15 – Mensagens de Echo do protocolo ICMP 
 
Fonte: Rohling, 2021. 
Além da resposta de “Echo Reply”, pode ser recebida também uma 
mensagem de “Destination Unreachable” como resposta, que será enviada por 
um roteador quando ele não tiver uma rota para o destino. E temos também a 
mensagem de “Time Exceeded”, que será enviada por um roteador quando o 
contador de saltos do pacote atingir o seu limite. 
Outro uso do protocolo ICMP é a utilização do comando tracert, que 
permite identificar todos os dispositivos de roteamento até um determinado 
>ping 186.192.90.12 
 
Disparando 186.192.90.12 com 32 bytes de dados: 
Resposta de 186.192.90.12: bytes=32 tempo=9ms TTL=248 
Resposta de 186.192.90.12: bytes=32 tempo=7ms TTL=248 
Resposta de 186.192.90.12: bytes=32 tempo=9ms TTL=248 
Resposta de 186.192.90.12: bytes=32 tempo=8ms TTL=248 
 
Estatísticas do Ping para 186.192.90.12: 
Pacotes: Enviados = 4, Recebidos = 4, Perdidos = 0 (0% de 
 perda), 
Aproximar um número redondo de vezes em milissegundos: 
 Mínimo = 7ms, Máximo = 9ms, Média = 8ms 
 
 
22 
destino. E a resposta do comando de tracert listará todos os nós de rede entre o 
usuário e o destino, bem como o tempo de resposta de cada um deles. A 
resultado de um teste de tracert para o Google, cujo um dos endereços é o 
8.8.8.8, é mostrado abaixo: 
Figura 15 – Mensagens de Echo do protocolo ICMP 
 
Fonte: Rohling, 2021. 
4.2 O ICMPV6 
Entre as diversas implementações adicionais do protocolo ICMPv6 temos 
a inclusão das mensagens do protocolo ICMPv6 que permitem a configuração 
inicial dos hosts nas redes IPv6, inclusive sem a necessidade de um servidor 
DHCPv6. Assim, para analisarmos o desempenho da rede em relação ao 
protocolo IPv6, é necessário conhecermos este mecanismo de maneira 
detalhada, para avaliarmos se as mensagens do ICMPv6 estão sendo 
trafegadas corretamente. 
>tracert 8.8.8.8 
 
Rastreando a rota para dns.google [8.8.8.8] 
com no máximo 30 saltos: 
 
 1 <1 ms <1 ms <1 ms GPT-2731GN2A4P-N2.GPT-2731GN2A4P-N2 
[192.168.15.1] 
 2 3 ms 2 ms 1 ms 179.184.120.12 
 3 3 ms 2 ms 1 ms 177.16.40.45 
 4 * * * Esgotado o tempo limite do pedido. 
 5 10 ms 9 ms 8 ms 74.125.52.64 
 6 11 ms 12 ms 9 ms 172.253.66.139 
 7 10 ms 10 ms 8 ms 216.239.50.111 
 8 9 ms 10 ms 9 ms dns.google [8.8.8.8] 
 
Rastreamento concluído. 
 
 
23 
Para a configuração dos hosts em uma rede IPv6, temos um processo 
chamado de SLAAC - Stateless Address Autoconfiguration, que utiliza a 
mensagem ICMPv6 de solicitação de roteador, que é a mensagem chamada de 
RS – Router Solicitation, e as mensagens de anúncio do roteador, chamada de 
RA – Router Announcement, para fornecer as informações de endereçamento e 
as demais informações de configuração de host, que eram normalmente 
fornecidas por um servidor DHCP, nas redes IPv4. 
E estas mensagens são enviadas empregando o mecanismo de 
comunicação em multicast do protocolo IPv6, onde a mensagem do cliente é 
enviada para o endereço de multicast de todos os roteadores, que é o endereço 
IPv6 ff02::2, e a resposta é enviada para o endereço de multicast de todos os 
nós, conforme mostrado na figura abaixo. 
Figura 17 – O método SLAAC do protocolo IPv6 
 
Fonte: Rohling, 2021. 
Assim, para filtrarmos o tráfego referente a este processo de 
autoconfiguração do SLAAC, poderemos utilizar como critério as mensagens do 
protocolo ICMPv6 e os endereços de multicast. A partir desta filtragem 
poderemos então avaliar o desempenho da rede em relação à inicialização dos 
hosts que estão utilizando o protocolo IPv6. 
TEMA 5 – CONFIGURANDO OS SWITCHES 
Para que possamos realizar a captura do tráfego da rede, para a análise 
dos protocolos e avaliação dodesempenho da rede, é necessário configurarmos 
os switches da rede para que realizem o encaminhamento do tráfego para a 
RS – Solicitação de roteador 
Multicast de todos os roteadores 
RA – Anúncio de roteador 
Multicast de todos os nós 
 
 
24 
interface onde está conectado o equipamento que fará a captura e 
armazenamento dos pacotes. 
Considerando-se a arquitetura hierárquica, conforme mostrada na figura 
abaixo, como recomendada em norma, teremos alguns pontos de concentração 
do tráfego da rede, que poderão ser copiados para a porta do equipamento de 
captura do tráfego. 
Figura 18 – A arquitetura da rede comutada 
 
Fonte: Rohling, 2021. 
Fazendo-se a análise da topologia podemos verificar que o switch que 
terá a maior concentração do tráfego é o switch Core da rede. Assim, 
poderíamos conectar o equipamento da captura neste switch, fazendo o 
“espelhamento” das portas de conexão com os demais switches para esta porta. 
Porém, se utilizarmos o espelhamento das portas do switch core, teremos 
apenas uma cópia do tráfego que passa pelo mesmo, e não teremos 
efetivamente uma cópia de todo o tráfego da rede. Para obtermos esta cópia de 
todo o tráfego da rede podemos empregar o recurso de espelhamento remoto, 
porém isto poderá impactar significativamente no tráfego da rede. 
Desta forma, a definição da forma de conexão do equipamento de captura 
deverá levar em consideração o perfil do tráfego desejado e o impacto na 
SW CORE 
SW de Distribuição 
SW de Acesso 
 
 
25 
configuração da rede, e, principalmente, no volume de tráfego, pois a 
configuração do espelhamento remoto poderá dobrar o volume de tráfego nos 
links de trunk entre os switches. 
5.1 O espelhamento de portas 
O recurso de espelhamento de portas em switches Cisco é chamado de 
SPAN - Switch Port Analyzer, onde temos a cópia do tráfego entre as portas de 
um switch, e que pode ser configurado também para o espelhamento remoto, 
que é chamado de RSPAN –Remote Switch Port Analyzer. 
Figura 18 – O espelhamento de portas 
 
Fonte: Rohling, 2021. 
Para a configuração do espelhamento de portas devermos criar uma 
sessão de monitoração do tráfego, definindo qual será a porta de origem e qual 
será a porta de destino do tráfego capturado. 
Para a definição da sessão e da porta de origem do tráfego, o comando a 
ser utilizado será: 
Switch(config)#monitor session 1 source interface fa 0/1 
Neste exemplo, foi criada a sessão de monitoração identificada como 
sessão número um, tendo como origem da captura a interface FastEthernet 0/1. 
Além da interface, também é possível definirmos o espelhamento apenas do 
tráfego recebido ou enviado nesta interface. 
E para definirmos a porta de destino, para onde será copiado o tráfego da 
interface a 0/1, o comando a ser utilizado será: 
Cópia do tráfego 
Estação de captura 
de tráfego 
Tráfego da rede 
 
 
26 
Switch(config)#monitor session 1 destination interface Fa 0/24 
Neste exemplo, o tráfego da sessão de número um será copiado para a 
interface FastEthernet 0/24. 
Podemos também utilizar como origem ou destino do SPAN uma interface 
do tipo VLAN. Desta forma, podemos criar uma sessão de SPAN para cada uma 
das VLANs, realizando o espelhamento para destinos diferentes. 
5.2 O espelhamento remoto 
A configuração dos switches Cisco para o SPAN remoto, ou seja, o 
RSPAN, é semelhante à configuração do SPAN, porém, o destino deverá ser 
uma VLAN, e deverá ser configurada uma porta que fará a reflexão do tráfego 
para a VLAN, que é chamada de reflector-port. E a VLAN de destino deverá ser 
corretamente configurada, o que inclui a criação da VLAN e sua permissão de 
tráfego nas portas tronco, devendo ser criada uma VLAN específica para o 
tráfego de espelhamento remoto. 
Assim, por exemplo, para configurarmos uma sessão de RSPAN, 
identificada como 20, para o espelhamento das interfaces FastEthernet 0/1 até 
0/23, utilizando a interface FastEthernet 0/24 como reflector-port, e direcionando 
o tráfego para a VLAN 99, teremos a seguinte configuração: 
#monitor session 20 source interface fa 0/1 - 23 
#monitor session 20 destination remote vlan 99 
reflector-port Fa 0/24 
Desta forma, uma cópia de todo o tráfego, de entrada e de saída, das 
interfaces do switch será encaminhada para a VLAN 99. 
Além disso, quando configuramos o RSPAN, a interface definida como 
reflector-port não poderá ser utilizada para a conexão de equipamentos de 
usuário, pois esta interface não aceitará nenhum outro tráfego a não ser o tráfego 
da sessão associada à esta interface. Portanto, deveremos considerar que será 
necessário alocarmos uma das interfaces físicas do switch para a operação do 
RSPAN, além da interface do tipo Trunk, por onde será enviado o tráfego 
espelhado para a VLAN do RSPAN. 
Um outro cuidado a ser tomado é que a conexão de trunk terá um aumento 
significativo do tráfego, praticamente dobrando o uso de largura de banda. E isto 
ocorrerá mais significativamente nos switches de acesso, pois, além do tráfego 
que seria enviado para a camada superior, teremos o envio de uma cópia deste 
 
 
27 
tráfego por meio da VLAN do RSPAN. Porém, se praticamente a totalidade do 
tráfego enviado para um switch de acesso é enviado para o switch da camada 
superior, de distribuição ou switch core, é muito mais eficiente realizarmos o 
espelhamento das portas na camada superior, e não na camada de acesso. 
Porém, como o recurso do RSPAN também é utilizado pelos sistemas de 
segurança, tal como os sistemas de detecção de intrusão, que é chamado de 
IDS – Intrusion Detection System. Como estes sistemas de IDS necessitam de 
uma cópia de todo o tráfego, para a monitoração e detecção das ameaças, 
também poderíamos utilizar esta cópia de tráfego para realizarmos a captura e 
análise, sem necessitar de uma configuração adicional, otimizando o impacto 
deste tráfego na rede, já que ele será gerado para garantir a segurança da rede. 
FINALIZANDO 
Para que possamos efetivamente analisar os protocolos que estão 
trafegando na rede, é necessário conhecermos em detalhes a sua dinâmica de 
operação, conhecendo as mensagens enviadas e recebidas, para que possamos 
estimar o seu impacto na rede, e verificarmos o seu correto funcionamento após 
a sua implementação na rede. 
O protocolo base das nossas redes é o protocolo IP, que é utilizado por 
praticamente todas as aplicações que estão trafegando na rede. E em relação 
ao protocolo IP a informação básica empregada na análise do tráfego da rede é 
basicamente o endereço de origem e de destino do tráfego, para que possamos 
analisar o impacto do volume de tráfego gerado por um determinado host na 
rede, que poderia ser o computador de um usuário ou por um servidor. E para 
este tipo de análise, além da captura do tráfego por um determinado período de 
tempo, que poderia ser realizado com a utilização do Wireshark, podemos utilizar 
uma ferramenta que permita esta monitoração em tempo real, e de maneira 
gráfica. Assim, veremos em conteúdos futuros este tipo de monitoração, para 
que, em relação ao volume de tráfego na rede e nas interfaces dos switches, 
possamos realizar uma análise do desempenho em tempo real, visualizando 
esta utilização das conexões com painéis gráficos. 
Para a configuração básica dos hosts temos os protocolos DHCPv4 e o 
ICMPv6, vistos nesta aula, que poderão impactar no desempenho da rede, em 
função das mensagens de broadcast e de multicast enviados pela rede LAN. 
Assim, estes protocolos deverão sempre ser considerados para a estimativa de 
 
 
28 
desempenho das redes, pois como praticamente todos os hosts utilizam o 
protocolo IP na camada de rede, eles sempre estarão presentes nas redes. 
E o outro protocolo associado à camada de rede é o protocolo ICMPv4, 
onde poderemos ter este tipo de mensagens sendo recebidas pelos hosts, caso 
ocorra algum problema no encaminhamento do tráfego até o destino. Porém,provavelmente o tráfego de mensagens ICMPv4 não deverá causar nenhum 
impacto significativo no tráfego da rede local. Além disso, como estas 
mensagens provavelmente serão geradas pelos rotadores da rede WAN, não 
seria possível estimar a quantidade de tráfego deste tipo de mensagens, sendo 
utilizadas apenas para a detecção de problemas com as redes externas. 
Na camada de transporte teremos os protocolos TCP ou UDP, sendo que 
o protocolo que causará maior impacto no desempenho das redes é o TCP, que 
implementa os mecanismos de estabelecimento de sessão, com o “Handshake” 
inicial, e de controle de fluxo, com o janelamento. Assim, é necessário 
estimarmos o tráfego adicional, gerado pelo Handshake inicial, que ocorrerá para 
todas as novas sessões TCP que sejam abertas. E quanto ao janelamento, em 
conteúdos futuros analisaremos o impacto deste mecanismo nas redes, para que 
possamos efetivamente analisar o desempenho deste mecanismo em relação 
ao seu impacto no desempenho da rede. E esta análise somente será necessária 
apenas para o protocolo TCP, pois o protocolo UDP é um protocolo mais simples, 
que não implementa estes recursos, fazendo basicamente a identificação das 
sessões, com os números de porta, não implementando os demais recursos do 
TCP. 
Portanto, a partir do comportamento estimado para os protocolos básicos 
que encontramos em nossas redes, nos próximos conteúdos faremos a análise 
dos mecanismos utilizados por estes protocolos, no processo de comunicação 
por meio das redes, de forma que possamos realizar, efetivamente, a análise de 
desempenho da rede, que é nosso principal objetivo. 
 
 
 
29 
REFERÊNCIAS 
CISCO. Networking Academy. Disponível em: <https://www.netacad.com/pt-
br>. Acesso em: 19 jul 2021. 
NSAM. NS-3 Network Simulator. Disponível em: <https://www.nsnam.org/>. 
Acesso em: 19 jul 2021. 
RFC 1700 - ASSIGNED NUMBERS. Internet Engineering Task Force – IETF, 
outubro 1994. Disponível em https: <//datatracker.ietf.org/doc/html/rfc1700>. 
Acesso em: 19 jul 2021. 
RFC 3232 - ASSIGNED NUMBERS. Internet Engineering Task Force – IETF, 
janeiro 2002. Disponível em: <https://datatracker.ietf.org/doc/html/rfc3232>. 
Acesso em: 19 jul 2021. 
RFC 792 - INTERNET CONTROL MESSAGE PROTOCOL. Internet 
Engineering Task Force – IETF, setembro 1981. Disponível em: 
<https://datatracker.ietf.org/doc/html/rfc792>. Acesso em: 19 jul 2021. 
Tanembaum, A. S. Redes de computadores. São Paulo, Pearson Education do 
Brasil, 2011.