HCNA

Routing &
Switching
PT1.0
 Prefácio
Os requisitos de negócios corporativos destacam a necessidade de redes capazes de se
adaptar às demandas de negócios em constante mudança em termos de crescimento de
negócios corporativos e serviços em evolução. É imperativo, portanto, entender os
princípios do que constitui uma rede corporativa e como ela é formada e adaptada para
suportar as demandas de negócios do mundo real.

Objectivos
Após a conclusão desta seção, os formandos serão capazes de:
 Explicar o que constitui uma rede corporativa.
 Descrever os tipos comuns de arquitetura de rede corporativa.
 Descrever algumas das soluções comumente implementadas em uma rede
corporativa para suportar operações comerciais.
 Redes Empresariais do Mundo Real

A rede corporativa representa originalmente a interconexão de sistemas pertencentes a um

determinado grupo funcional ou organização para permitir principalmente o compartilhamento de
recursos, como impressoras e servidores de arquivos, suporte de comunicação por meios como email e
a evolução para aplicativos que permitem a colaboração entre usuários. As redes corporativas podem
ser encontradas hoje em dia em vários setores, desde ambientes de escritórios até grandes indústrias de
energia, finanças e governo, que geralmente compreendem redes corporativas que abrangem vários
locais físicos.
A introdução da Internet como domínio de rede pública permitiu a ampliação da rede corporativa
existente, através da qual redes geograficamente dispersas pertencentes a uma única organização ou
entidade poderiam ser conectadas, trazendo consigo um conjunto de novos desafios para estabelecer a
interconectividade entre redes corporativas geograficamente dispersas, mantendo a privacidade e a
segurança dos dados pertencentes a uma empresa individual.

Redes Remotas Empresariais

Vários desafios impactam as indústrias atuais no fornecimento de soluções para o estabelecimento

de interconectividade entre locais remotos, que geralmente assumem a forma de filiais regionais e
escritórios centrais, bem como funcionários que representam uma entidade não fixa dentro da rede da
empresa, frequentemente presentes em locais além da limites convencionais da empresa existente.
Desafios para as indústrias criaram uma demanda por redes onipresentes que permitem que a rede
corporativa esteja disponível em qualquer local e a qualquer momento, para garantir acesso a recursos
e ferramentas que permitam a entrega efetiva de suporte e serviços para parceiros e clientes do setor.
A evolução das soluções corporativas permitiu que redes IP públicas e de terceiros fornecessem
conectividade a qualquer momento, juntamente com o desenvolvimento de tecnologias que
estabelecessem conexões de rede privada sobre essa infraestrutura de rede pública para estender os
recursos remotos da rede corporativa para além do físico. limites da empresa, permitindo que tanto
escritórios remotos quanto usuários estabeleçam um único domínio corporativo que se estenda por
uma grande extensão geográfica.

Arquitetura básica de uma rede empresarial

As soluções de arquitetura de rede corporativa variam significativamente, dependendo do requisito

do setor e da organização. As pequenas empresas podem muitas vezes ter um requisito muito limitado
em termos de complexidade e demanda, optando por implementar uma forma plana de rede,
principalmente devido ao tamanho da organização que muitas vezes é restrito a uma única localização
geográfica ou dentro de alguns locais, apoiando acesso a recursos comuns, enquanto permite
flexibilidade dentro da organização para suportar um número menor de usuários. O custo para
implementar e manter essas redes é significativamente reduzido, no entanto, a rede é frequentemente
suscetível a falhas devido à falta de redundância, e o desempenho pode variar com base nas operações
diárias e na demanda da rede.
Redes corporativas maiores implementam soluções para garantir falhas mínimas de rede, acesso
controlado e provisionamento para uma variedade de serviços para suportar as operações diárias da
organização. Uma arquitetura multicamadas é definida para otimizar o fluxo de tráfego, aplicar políticas
de gerenciamento de tráfego e controlar o acesso a recursos, bem como manter a disponibilidade da
rede e a operação estável por meio de redundância de rede efetiva. O design multicamadas também
permite uma fácil expansão e, juntamente com um design modular que fornece isolamento e
manutenção eficazes, caso ocorram problemas na rede, sem afetar toda a rede.

Resumo
1-Quais são algumas das diferenças gerais encontradas entre redes de pequenas e médias empresas?
Redes de pequenas empresas que implementam uma arquitetura de rede plana podem limitar a
capacidade de dimensionar a rede no caso de crescimento no número de usuários. Onde é esperado
que um número maior de usuários precise ser suportado, uma abordagem hierárquica para redes
corporativas deve ser considerada. As redes de médio porte geralmente suportam um número maior de
usuários e, portanto, normalmente implementam uma infraestrutura de rede hierárquica para permitir
que a rede cresça e suporte a base de usuários exigida.

2-Quais são algumas das considerações básicas de design que precisam ser levadas em conta para
redes corporativas de pequeno e médio porte?
As redes de pequenas e médias empresas devem levar em conta o desempenho da rede, bem como
fornecer redundância em caso de falha de rede, a fim de manter a disponibilidade do serviço para todos
os usuários. À medida que a rede cresce, a ameaça à segurança da rede também aumenta, o que
também pode atrapalhar os serviços.
 Prefácio
O estabelecimento de uma rede corporativa requer uma compreensão fundamental
dos conceitos gerais de rede. Esses conceitos incluem o conhecimento do que define uma
rede, bem como os padrões gerais de tecnologia e componentes físicos usados para
estabelecer redes corporativas. Um entendimento das comunicações de rede
subjacentes e o impacto que tal comportamento tem na rede também é fundamental
para garantir a implementação eficaz do desempenho.

Objectivos
Após a conclusão desta seção, os formandos serão capazes de:
 Explicar o que constitui uma rede.
 Identificar os componentes básicos de uma rede.
 Descrever os principais mecanismos de comunicação em uma rede.
 Redes Ethernet ponto-a-ponto simples

Uma rede pode ser entendida como a capacidade de duas ou mais entidades se comunicarem através
de um dado meio. O desenvolvimento de qualquer rede depende do mesmo princípio para estabelecer
comunicação. Comumente, as entidades dentro de uma rede que são responsáveis pela transmissão e
recepção da comunicação são conhecidas como estações finais, enquanto os meios pelos quais a
comunicação é ativada são entendidos como o meio. Dentro de uma rede corporativa, a mídia existe em
uma variedade de formas, desde um cabo físico até ondas de rádio.

Coaxial

O cabo coaxial representa uma forma mais histórica de meio de transmissão que hoje pode ser
limitado em uso dentro da rede da empresa. Como meio de transmissão, o cabo coaxial compreende
geralmente dois padrões, os 10Base2 e 10Base5, que são conhecidos como Thinnet ou Thinwire e
Thicknet ou Thickwire, respectivamente.
Os padrões suportam uma capacidade de transmissão de 10Mbps transmitida como sinal de banda
base para as respetivas distâncias de 185 e 500 metros. Nas redes empresariais de hoje, a capacidade de
transmissão é extremamente limitada para ser de qualquer aplicação significativa. O conector Bayonet
Neill-Concelman (BNC) é a forma comum de conector usado para cabos coaxiais 10Base2 finos,
enquanto um conector tipo N foi aplicado ao meio de transmissão 10Base5 mais espesso.
 Ethernet

O cabeamento Ethernet tornou-se o padrão para muitas redes empresariais que fornecem um meio
de transmissão que suporta uma capacidade de transmissão muito maior. O meio suporta um par de
fios de cobre contido dentro de uma bainha que pode ou não ser protegida contra interferência elétrica
externa. A capacidade de transmissão é determinada principalmente com base na categoria de cabo
com categoria 5 (CAT5) suportando capacidade de transmissão Fast Ethernet de até 100Mbps, enquanto
uma maior capacidade de transmissão Gigabit Ethernet é suportada a partir dos padrões CAT5e
(Categoria 5) e superiores.
A transmissão pela Ethernet como meio físico também é suscetível à atenuação, fazendo com que o
alcance da transmissão seja limitado a 100 metros. O conector RJ-45 é usado para fornecer
conectividade com cabeamento de par de fios que exige a colocação de pinos específicos no conector
RJ-45, para garantir a transmissão e recepção corretas pelas estações finais sobre o meio de
transmissão.

Fiber Optic
 A mídia óptica utiliza a luz como meio de transmissão de sinal, em oposição aos sinais elétricos
encontrados nos tipos de mídia coaxial e Ethernet. O meio de fibra ótica suporta uma gama de padrões
de transmissão de 10Mbps, 100Mbps, 1Gbps e também 10Gbps (10GBASE). Fibra monomodo ou
multimodo define o uso de um meio de transmissão ótica para propagação de luz, onde o modo único
se refere a um único modo de transmissão ótica sendo propagado, e é usado comumente para
transmissão de alta velocidade a longas distâncias.
O modo múltiplo suporta a propagação de múltiplos modos de transmissão ótica que são suscetíveis
à atenuação como resultado da dispersão de luz ao longo do meio óptico e, portanto, não é capaz de
suportar a transmissão por distâncias maiores. Este modo é frequentemente aplicado a redes locais que
abrangem um alcance de transmissão muito menor. Há um grande número de padrões de conectores
de fibra, sendo algumas das formas mais comuns reconhecidas como conector ST, conector LC e SC ou
conector de encaixe.

Serial

Serial representa um padrão inicialmente desenvolvido há mais de 50 anos para suportar a

transmissão confiável entre dispositivos, durante o qual muitas evoluções do padrão ocorreram. A
conexão serial é projetada para suportar a transmissão de dados como um fluxo serial de bits. O padrão
comum implementado é chamado de (Padrão Recomendado) RS-232, mas é limitado tanto pela
distância quanto pela velocidade. Os padrões originais RS-232 definem que as velocidades de
comunicação suportadas não sejam maiores que 20Kbps, com base em um comprimento de cabo de 50
pés (15 metros), no entanto, é improvável que as velocidades de transmissão para serial sejam
inferiores a 115 Kbps. O comportamento geral para serial significa que à medida que o comprimento do
cabo aumenta, a taxa de bits suportada diminui, com uma aproximação de um cabo de cerca de 150
metros, ou 10 vezes os padrões originais, a taxa de bits suportada será reduzida pela metade.
Outros padrões seriais têm a capacidade de atingir faixas de transmissão muito maiores, como é o
caso dos padrões RS-422 e RS-485 que abrangem distâncias de até 1.200 metros (500 pés) e são
geralmente suportados por conectores V.35 que eram tornados obsoletos durante o final dos anos 80,
mas ainda hoje são encontrados e mantidos em apoio a tecnologias como Frame Relay e ATM, quando
implementados. O RS-232 em si não define os padrões de conector, no entanto, duas formas comuns de
conector que suportam o padrão RS-232 incluem os conectores DB-9 e DB-25. Padrões seriais mais
novos foram desenvolvidos para substituir grande parte da tecnologia serial RS-232 existente, incluindo
os padrões FireWire e o barramento serial universal (USB), o último dos quais está se tornando comum
em muitos produtos e dispositivos mais recentes.

Codificação de dados de sinal

Para permitir a comunicação através de enlaces físicos, os sinais devem ser transmitidos entre as
estações de transmissão e recepção. Este sinal irá variar dependendo do meio que está sendo usado,
como no caso da transmissão óptica e sem fio. O objetivo principal do sinal é garantir que a
sincronização (ou clock) entre o emissor e o receptor em um meio físico seja mantida, bem como
suportar a transmissão do sinal de dados em um formato que possa ser interpretado pelo remetente e
pelo receptor.
Uma forma de onda é comumente reconhecida como uma propriedade de codificação de linha, onde
a tensão é convertida em uma representação binária de valores 0 e 1 que podem ser traduzidos pela
estação receptora. Existem vários padrões de codificação de linha, com os padrões 10Base Ethernet
suportando um padrão de codificação de linha conhecido como codificação Manchester. A Fast Ethernet
com um intervalo de frequência de 100 MHz invoca uma frequência mais alta do que a suportada
quando se utiliza a codificação Manchester.
Uma forma alternativa de codificação de linha é usada, portanto, conhecida como NZRI, que por si só
contém variações dependentes da mídia física, suportando MLT-3 para 100Base-TX e 100Base-FX junto
com a codificação de linha estendida conhecida como codificação 4B / 5B para lidar com possíveis
problemas de clock. O 100Base-T4, por exemplo, usa outra forma conhecida como codificação de linha
estendida 8B / 6T. O Gigabit Ethernet suporta codificação de linha 8B / 10B, com exceção do 1000Base-
T, que se baseia em uma codificação de bloco complexa chamada de 4D-PAM5.
 Domínios de colisão

A Ethernet representa o que é entendido como uma rede de múltiplos acessos, na qual duas ou mais
estações finais compartilham um meio de transmissão comum para o encaminhamento de dados. A
rede compartilhada é, no entanto, suscetível a colisões de transmissão em que os dados são
encaminhados pelas estações finais simultaneamente através de um meio comum. Um segmento em
que tais ocorrências são possíveis é chamado de domínio de colisão compartilhado.
As estações finais dentro de tal domínio de colisão dependem da contenção para a transmissão de
dados para um destino pretendido. Este comportamento controverso requer que cada monitor da
estação final forneça dados de entrada no segmento antes de fazer qualquer tentativa de transmissão,
em um processo conhecido como Detecção de Colisão de Acesso Múltiplo da Detecção de Portadora
(CSMA / CD). No entanto, mesmo após tomar tais precauções, o potencial para a ocorrência de colisões
como resultado da transmissão simultânea por duas estações finais permanece altamente provável.

Modos Duplex

Modos de transmissão são definidos na forma de half e full duplex, para determinar o
comportamento envolvido com a transmissão de dados através do meio físico.
Half duplex refere-se à comunicação de dois ou mais dispositivos em um meio físico compartilhado
no qual existe um domínio de colisão e, com ele, o CSMA / CD é necessário para detectar essas colisões.
Isso começa com a estação ouvindo a recepção do tráfego em sua própria interface e, quando fica em
silêncio por um determinado período, continuará transmitindo seus dados. Se uma colisão ocorrer, a
transmissão será interrompida, seguida pelo início de um algoritmo de backoff para evitar novas
transmissões até que um temporizador de valor aleatório expire, após o qual a retransmissão pode ser
tentada novamente.
 Full duplex define a comunicação bidirecional simultânea em pares de fios ponto-a-ponto dedicados,
garantindo que não haja potencial para colisões e, portanto, não há necessidade de CSMA / CD.

Resumo
1-Quais formas de cabeamento podem ser usadas para suportar transmissões Gigabit Ethernet em
uma rede corporativa?
A transmissão Gigabit Ethernet é suportada pelo cabeamento CAT 5e e superior, e também por
qualquer forma de cabeamento de Fibra Ótica 1000Base ou superior.
2-O que é um domínio de colisão?
Um domínio de colisão é um segmento de rede para o qual o mesmo meio físico é usado para
comunicação bidirecional. Os dados transmitidos simultaneamente entre hosts no mesmo meio de rede
compartilhado são suscetíveis a uma colisão de sinais antes que esses sinais cheguem ao destino
pretendido. Isso geralmente resulta em sinais malformados maiores ou menores que o tamanho
aceitável para transmissão (64 bytes - 1500 bytes), também conhecidos como runts e gigantes, sendo
recebidos pelo destinatário.
3-Qual é o objetivo do CSMA / CD?
O CSMA / CD é um mecanismo para detectar e minimizar a possibilidade de eventos de colisão que
possam ocorrer em uma rede compartilhada. O CSMA exige que o host de transmissão primeiro escute
os sinais no meio compartilhado antes da transmissão. No caso de não serem detectadas transmissões,
a transmissão pode prosseguir. Na infeliz circunstância de que os sinais são transmitidos
simultaneamente e ocorre uma colisão, os processos de detecção de colisão são aplicados para
interromper a transmissão por um período de tempo gerado localmente, para permitir que os eventos
de colisão sejam eliminados e evitar novas colisões entre os hosts transmissores.
 Prefácio
A transmissão por meio físico requer regras que definem o comportamento da
comunicação. O gerenciamento do comportamento de encaminhamento de redes
baseadas em Ethernet é controlado através dos padrões IEEE 802 definidos para a
tecnologia de enlace de dados Ethernet. Um conhecimento fundamental desses padrões
é imperativo para entender completamente como a comunicação da camada de enlace é
alcançada em redes baseadas em Ethernet.

Objectivos

Após a conclusão desta seção, os formandos serão capazes de:

 Explicar a aplicação de modelos de referência a redes.
 Descrever como os quadros são construídos.
 Explicar a função do endereçamento MAC na camada de enlace de dados.
 Descrever o comportamento de encaminhamento e processamento de quadros
Ethernet.
 Gerenciando a comunicação de rede

A comunicação através de redes depende da aplicação de regras que governam como os dados são
transmitidos e processados de uma maneira que é entendida pelas entidades emissora e receptora.
Como resultado, vários padrões foram desenvolvidos ao longo do tempo, com alguns padrões sendo
amplamente adotados. Existe, no entanto, uma distinção clara entre os padrões que gerenciam o fluxo
de dados físicos e os padrões responsáveis pelo encaminhamento e entrega lógicos do tráfego.
Os padrões IEEE 802 representam um padrão universal para gerenciar a transmissão física de dados
através da rede física e são compostos de padrões, incluindo o padrão Ethernet 802.3 para transmissão
física em redes locais. Existem padrões alternativos para transmissão em redes de área ampla que
operam em mídia serial, incluindo Frame Relay, HDLC e outros padrões legados, como ATM. O TCP / IP
tem sido amplamente adotado como o conjunto de protocolos que define os padrões da camada
superior, regulando as regras (protocolos) e o comportamento envolvido no gerenciamento do
encaminhamento e entrega lógicos entre as estações finais.

Modelos em camadas - TCP / IP

O modelo de referência TCP / IP refere-se principalmente aos princípios centrais do conjunto de

protocolos, que pode ser entendido como a transmissão lógica e a entrega de tráfego entre as estações
finais. Como tal, o modelo de referência do protocolo TCP / IP fornece uma representação em quatro
camadas da rede, resumindo o comportamento do encaminhamento físico sob a camada de interface de
rede, uma vez que a operação de camada inferior não é preocupação do conjunto de protocolos TCP /
IP.
O foco principal permanece na camada de rede (ou Internet), que lida com a forma como o tráfego é
logicamente encaminhado entre as redes, e a camada de transporte (algumas vezes referida como host
para host) que gerencia a entrega de tráfego end-to-end, garantindo confiabilidade do transporte entre
as estações finais de origem e de destino. A camada de aplicativo representa uma interface por meio de
vários protocolos que permitem que os serviços sejam aplicados aos processos de aplicativos do usuário
final.

Modelos em camadas - OSI

Embora o modelo de referência TCP / IP seja principalmente suportado como o modelo padrão
baseado no conjunto de protocolos TCP / IP, o foco do modelo de referência TCP / IP não separa e
distingue claramente a funcionalidade ao referenciar transmissão física de camada inferior.
Em vista disso, a interconexão de sistemas abertos, ou modelo de referência OSI, é frequentemente
reconhecido como o modelo para referência aos padrões IEEE 802 devido à clara distinção e
representação do comportamento das camadas inferiores, que corresponde aos padrões do modelo de
referência LAN / MAN que são definidos como parte dos padrões IEEE 802-1990 documentados para
redes de área local e metropolitana. Além disso, o modelo que geralmente está em referência ao
conjunto de protocolos ISO fornece uma análise detalhada do processamento da camada superior.
 Encapsulamento

Como os dados de aplicação da camada superior são determinados para transmissão através de uma
rede a partir de um sistema final, uma série de processos e instruções deve ser aplicada aos dados antes
que a transmissão possa ser alcançada com sucesso. Esse processo de anexação e instruções prévias aos
dados é chamado de encapsulamento e para o qual cada camada do modelo de referência é projetada
para representar.
À medida que as instruções são aplicadas aos dados, o tamanho geral dos dados aumenta. As
instruções adicionais representam uma sobrecarga para os dados existentes e são reconhecidas como
instruções para a camada na qual as instruções foram aplicadas. Para outras camadas, as instruções
encapsuladas não são diferenciadas dos dados originais. O acréscimo final de instruções é executado
como parte dos padrões de protocolo de camada inferior (como o padrão Ethernet IEEE 802.3) antes de
ser transportado como um sinal codificado em um meio físico.

Comunicação entre duas estações finais

Como parte do padrão Ethernet IEEE 802.3, os dados são encapsulados com instruções na forma de
um cabeçalho e um trailer antes de poderem ser propagados em mídia física na qual a Ethernet é
suportada. Cada estágio de encapsulamento é referido por uma unidade de dados de protocolo ou PDU,
que na camada de enlace de dados é conhecida como um quadro.
 Os quadros Ethernet contêm instruções que determinam como e se os dados podem ser transmitidos
pelo meio entre dois ou mais pontos. Os quadros Ethernet vêm em dois formatos gerais, cuja seleção é
altamente dependente dos protocolos que foram definidos antes do encapsulamento de
enquadramento.

Formato dos quadros

Dois formatos de quadro são reconhecidos como padrão para redes baseadas em Ethernet. O padrão
de tipo de quadro DIX versão 2 foi desenvolvido originalmente no início dos anos 80, onde hoje é
reconhecido como o tipo de quadro Ethernet II. A Ethernet II acabou sendo aceita e integrada aos
padrões IEEE 802, destacada como parte da seção 3.2.6 da documentação de padrões IEEE 802.3x-1997.
O padrão Ethernet IEEE 802.3 foi originalmente desenvolvido em 1983, com diferenças importantes
entre os formatos de quadro, incluindo uma mudança no campo de tipo que é projetado para identificar
o protocolo para o qual os dados devem ser encaminhados após o processamento das instruções do
quadro. No formato Ethernet IEEE 802.3, isso é representado como um campo de comprimento que
depende de um conjunto estendido de instruções chamadas 802.2 LLC para identificar o protocolo de
encaminhamento.
Ethernet II e IEEE 802.3 associam-se a protocolos de camada superior que são diferenciados por um
intervalo de valores de tipo, onde protocolos que suportam um valor menor ou igual a 1500 (ou 05DC
em hexadecimal) empregarão o tipo de quadro Ethernet IEEE 802.3 na camada de enlace de dados.
Protocolos representados por um valor de tipo maior ou igual a 1536 (ou 0600 em hexadecimal)
empregarão o padrão Ethernet II e que representa a maioria de todos os quadros em redes baseadas
em Ethernet.
Outros campos encontrados no quadro incluem os campos de endereço MAC de destino e origem
que identificam o remetente e o destinatário pretendido, bem como o campo de sequência de
verificação de quadro que é usado para confirmar a integridade do quadro durante a transmissão.
 Quadro Ethernet II

O quadro Ethernet II faz referência a um valor de tipo hexadecimal que identifica o protocolo da
camada superior. Um exemplo comum disso é o protocolo de Internet (IP), que é representado por um
valor hexadecimal de 0x0800. Como esse valor para IP representa um valor maior que 0x0600, é
determinado que o tipo de quadro Ethernet II deve ser aplicado durante o encapsulamento. Outro
protocolo comum que se baseia no tipo de quadro Ethernet II na camada de enlace de dados é ARP e é
representado pelo valor hexadecimal de 0x0806.

Quadro IEEE802.3

Para o tipo de frame IEEE 802.3, o campo type está contido como parte do cabeçalho da extensão
SNAP e não é tão comum aplicar os protocolos nas redes atuais, em parte devido ao requisito de
instruções adicionais que resultam em sobrecarga adicional por quadro. Alguns protocolos antigos que
existem há muitos anos, mas que ainda são aplicados em suporte a redes Ethernet, provavelmente
aplicam o tipo de quadro IEEE 802.3. Um exemplo claro disso é encontrado no caso do Spanning Tree
Protocol (STP) que é representado por um valor de 0x03 dentro do campo type do cabeçalho SNAP.
 Encaminhamento de quadros

As redes baseadas em Ethernet atingem a comunicação entre duas estações finais em uma rede local
usando o endereçamento MAC (Media Access Control), que permite distinguir sistemas finais em uma
rede de múltiplos acessos. O endereço MAC é um endereço físico que é gravado na placa de interface de
rede à qual o meio físico está conectado. Esse mesmo endereço MAC é recuperado e usado como o
endereço MAC de destino do destinatário pretendido pelo remetente, antes que o quadro seja
transferido para a camada física para encaminhamento pela mídia conectada.

O endereço MAC Ethernet

Cada endereço MAC é um valor de 48 bits comumente representado em um formato hexadecimal

(base 16) e consiste em duas partes que tentam garantir que cada endereço MAC seja globalmente
exclusivo. Isso é obtido pela definição de um identificador exclusivo da organização, específico do
fornecedor, com base no qual é possível rastrear a origem de um produto de volta ao seu fornecedor
com base nos primeiros 24 bits do endereço MAC. Os restantes 24 bits do endereço MAC são um valor
que é atribuído de forma incremental e única a cada produto (por exemplo, uma Placa de Interface de
Rede ou um produto similar suportando interfaces de porta para as quais é necessário um MAC).
 Encaminhamento de quadros Unicast

A transmissão de quadros dentro de uma rede local é obtida usando um dos três métodos de
encaminhamento, o primeiro deles é unicast e refere-se à transmissão de um único local de origem para
um único destino. Cada interface do host é representada por um endereço MAC exclusivo, contendo um
identificador organizacional exclusivo, para o qual o oitavo bit do octeto mais significativo (ou primeiro
byte) no campo de endereço MAC identifica o tipo de endereço. Esse 8º bit é sempre definido como 0,
onde o endereço MAC é um endereço MAC do host e significa que qualquer quadro contendo esse
endereço MAC no campo de endereço MAC de destino é destinado apenas a um único destino.
Quando os hosts existirem em um domínio de colisão compartilhado, todos os hosts conectados
receberão a transmissão unicast, mas o quadro será geralmente ignorado por todos os hosts em que o
endereço MAC no campo MAC de destino do quadro não corresponder ao valor MAC do host de
recepção. uma determinada interface, deixando apenas o host pretendido para aceitar e processar os
dados recebidos. As transmissões Unicast são encaminhadas apenas de uma única interface física para o
destino pretendido, mesmo nos casos em que podem existir várias interfaces.

Encaminhamento de quadros de Broadcast

 Transmissão de transmissão representa um método de encaminhamento que permite que quadros
sejam inundados de uma única fonte recebida por todos os destinos dentro de uma rede local. Para
permitir que o tráfego seja transmitido para todos os hosts em uma rede local, o campo de endereço
MAC de destino do quadro é preenchido com um valor definido em hexadecimal como FF: FF: FF: FF: FF:
FF e quais especifica que todos os destinatários de um quadro com esse endereço definido devem
aceitar o recebimento desse quadro e processar o cabeçalho e o trailer do quadro.
As transmissões são usadas por protocolos para facilitar uma série de importantes processos de rede,
incluindo a descoberta e manutenção da operação da rede, mas também geram tráfego excessivo que
freqüentemente causa interrupções nos sistemas finais e utilização de largura de banda que tendem a
reduzir o desempenho geral da rede.

Encaminhamento de quadros multicast

Uma alternativa mais eficiente à transmissão que começou a substituir o uso de transmissões em
muitas tecnologias mais recentes é o tipo de quadro multicast. O encaminhamento multicast pode ser
entendido como uma forma de transmissão seletiva que permite que hosts selecionados escutem um
endereço MAC multicast específico além do endereço MAC unicast que está associado ao host, e
processam quaisquer quadros contendo o endereço MAC multicast no MAC de destino campo do
quadro.
Como não há distinção relativa entre endereços MAC unicast e formatos de endereço MAC multicast,
o endereço multicast é diferenciado usando o oitavo bit do primeiro octeto. Onde esse valor de bit
representa um valor de 1, ele identifica que o endereço faz parte do intervalo de endereços MAC
multicast, em oposição aos endereços MAC unicast em que esse valor é sempre 0.
Em uma rede de área local, a verdadeira capacidade do comportamento de multicast na camada de
enlace de dados é limitada, pois o encaminhamento permanece semelhante ao de um quadro de
broadcast no qual as interrupções ainda prevalecem em toda a rede. A única diferença clara com a
tecnologia de transmissão está no processamento seletivo ao receber estações finais. À medida que as
redes se expandem para suportar várias redes locais, a capacidade real da tecnologia multicast como um
meio eficiente de transmissão se torna mais aparente.
 Carrier Sense

Como o tráfego está preparado para ser encaminhado pela rede física, é necessário que os hosts em
domínios de colisão compartilhada determinem se algum tráfego está ocupando o meio de transmissão
no momento. A mídia de transmissão, como no caso do 10Base2, fornece um meio compartilhado sobre
o qual o CSMA / CD deve ser aplicado para garantir que as colisões sejam tratadas caso ocorram. Se a
transmissão de um quadro for detectada no link, o host atrasará o encaminhamento de seus próprios
quadros até o momento em que a linha estiver disponível, após o qual o host começará a encaminhar os
quadros da interface física para o destino pretendido.
Quando dois hosts são conectados em um meio capaz de suportar transmissão full duplex como no
caso de mídia como 10BaseT, considera-se não possível que quadros transmitidos sofram colisões, pois
a transmissão e o recebimento de quadros ocorrem em fios separados e, portanto, não há requisito
para que o CSMA / CD seja implementado.

Processamento de quadros
 Depois que um quadro é encaminhado da interface física do host, ele é transportado pela mídia até o
destino pretendido. No caso de uma rede compartilhada, o quadro pode ser recebido por vários hosts,
que avaliarão se o quadro é destinado à sua interface, analisando o endereço MAC de destino no
cabeçalho do quadro. Se o endereço MAC de destino e o endereço MAC do host não forem iguais, ou o
endereço MAC de destino não for um endereço de transmissão múltipla ou multicast ao qual o host está
atendendo, o quadro será ignorado e descartado.
Para o destino pretendido, o quadro será recebido e processado, inicialmente confirmando que o
quadro é destinado à interface física do host. O host também deve confirmar que a integridade do
quadro foi mantida durante a transmissão tomando o valor do campo FCS (Frame Check Sequence) e
comparando esse valor com um valor determinado pelo host de recebimento. Se os valores não
corresponderem, o quadro será considerado como corrompido e será descartado posteriormente.
Para quadros válidos, o host precisará determinar o próximo estágio de processamento analisando o
campo de tipo do cabeçalho do quadro e identificar o protocolo ao qual esse quadro é destinado. Neste
exemplo, o campo tipo de quadro contém um valor hexadecimal de 0x0800 que identifica que os dados
obtidos do quadro devem ser encaminhados para o Protocolo da Internet, antes do qual, o cabeçalho do
quadro e o trailer são descartados.

Resumo
Como a Ethernet determina o protocolo para o qual um quadro processado deve ser entregue?
Os quadros da camada de enlace de dados contêm um campo Tipo que referencia o próximo
protocolo para o qual os dados contidos no quadro devem ser encaminhados. Exemplos comuns de
protocolos de encaminhamento incluem IP (0x0800) e ARP (0x0806).
2-Como se determina se um quadro deve ser processado ou descartado ao ser recebido por um
dispositivo final?
O endereço MAC de destino contido no cabeçalho do quadro é analisado pela estação final receptora
e comparado ao endereço MAC associado à interface na qual o quadro foi recebido. Se o endereço MAC
de destino e o endereço MAC da interface não corresponderem, o quadro será descartado.
 Prefácio
O Internet Protocol (IP) é projetado para fornecer um meio de comunicação entre
redes que não é suportado por protocolos de camada inferior, como a Ethernet. A
implementação de endereçamento lógico (IP) permite que o Protocolo Internet seja
empregado por outros protocolos para o encaminhamento de dados na forma de
pacotes entre redes. Um forte conhecimento de endereçamento IP deve ser alcançado
para um projeto de rede eficaz, juntamente com uma clara familiaridade com o
comportamento do protocolo, para apoiar um entendimento claro da implementação do
IP como um protocolo roteado.

Objectivos
Após a conclusão desta seção, os formandos serão capazes de:
 Descrever os campos e características contidos no IP.
 Distinguir entre intervalos de endereços IP públicos, privados e especiais.
 Implementar com sucesso o endereçamento VLSM.
 Explique a função de um gateway IP.
 Processamento do próximo cabeçalho

Antes de descartar o cabeçalho e o trailer do quadro, é necessário que o próximo conjunto de

instruções a ser processado seja determinado a partir do cabeçalho do quadro. Conforme destacado,
isso é identificado determinando o valor do campo no campo de tipo, que, nesse caso, representa um
quadro destinado ao protocolo IP após a conclusão do processo de quadro.
A função chave do quadro é determinar se o destino físico pretendido foi atingido, se a integridade
do quadro permaneceu intacta. O foco desta seção identificará como os dados são processados após o
descarte dos cabeçalhos de quadros e a propagação dos dados restantes para o Protocolo da Internet.

Cabeçalho do pacote IP

O cabeçalho IP é usado para suportar duas operações chave, roteamento e fragmentação. O

roteamento é o mecanismo que permite que o tráfego de uma determinada rede seja encaminhado
para outras redes, já que a camada de enlace de dados representa uma única rede para a qual existem
limites de rede. Fragmentação refere-se à quebra de dados em blocos gerenciáveis que podem ser
transmitidos pela rede.
O cabeçalho IP é transportado como parte dos dados e representa uma sobrecarga de pelo menos 20
bytes que referencia como o tráfego pode ser encaminhado entre redes, onde o destino pretendido
existe dentro de uma rede diferente da rede na qual os dados foram originalmente transmitidos. O
campo de versão identifica a versão do IP que atualmente está sendo suportada; nesse caso, a versão é
conhecida como versão quatro ou IPv4. O campo DS foi originalmente referido como o tipo de campo de
serviço, mas agora funciona como um campo de suporte a serviços diferenciados, usado principalmente
como um mecanismo para aplicar qualidade de serviço (QoS) para otimização de tráfego de rede, e é
considerado fora do campo. âmbito desta formação.
Os endereços IP de origem e de destino são endereços lógicos atribuídos a hosts e usados para
referenciar o remetente e o destinatário pretendido na camada de rede. O endereçamento IP permite
avaliar se existe um destino pretendido na mesma rede ou em uma rede diferente, como forma de
auxiliar o processo de roteamento entre as redes, a fim de alcançar destinos além da rede local.

Endereçamento IP

Cada endereço IPv4 representa um valor de 32 bits que geralmente é exibido em um formato decimal
pontuado, mas o entendimento detalhado do comportamento subjacente também é representado em
um formato binário (Base 2). Os endereços IP atuam como identificadores para os sistemas finais, bem
como para outros dispositivos dentro da rede, como um meio de permitir que esses dispositivos sejam
acessíveis tanto localmente quanto por fontes localizadas remotamente, além dos limites da rede atual.
O endereço IP consiste em dois campos de informações que são usados para especificar claramente a
rede à qual um endereço IP pertence, bem como um identificador de host dentro do intervalo de rede,
que é, na maior parte, exclusivo dentro da rede determinada.

Cada intervalo de rede contém dois endereços importantes que são excluídos do intervalo de rede
atribuível a hosts ou outros dispositivos. O primeiro desses endereços excluídos é o endereço de rede
que representa uma determinada rede em oposição a um host específico dentro da rede. O endereço de
rede é identificável ao se referir ao campo host do endereço de rede, no qual os valores binários dentro
desse intervalo são todos definidos como 0, para os quais também se deve notar que um valor binário
todo 0 nem sempre representa um valor 0 na notação decimal pontuada.
O segundo endereço excluído é o endereço de difusão usado pela camada de rede para se referir a
qualquer transmissão que se espera que seja enviada a todos os destinos dentro de uma determinada
rede. O endereço de broadcast é representado no campo host do endereço IP, onde os valores binários
dentro desse intervalo são todos definidos como 1. Os endereços de host compõem o intervalo que
existe entre a rede e os endereços de broadcast.

Decimal, Binário e Hexadecimal

O uso de notações binárias, decimais e hexadecimais são comumente aplicadas em redes IP para
representar esquemas de endereçamento, protocolos e parâmetros e, portanto, o conhecimento da
construção fundamental dessas formas básicas é importante para entender o comportamento e
aplicação de valores nas redes IP.
Cada sistema de numeração é representado por um valor base diferente que destaca o número de
valores usados como parte do intervalo de notações base. No caso do binário, apenas dois valores são
usados, 0 e 1, que em combinação podem fornecer um número crescente de valores, geralmente
representados como 2 à potência de x, onde x denota o número de valores binários. Hexadecimal
representa uma notação de base 16 com valores que variam de 0 a F, (0-9 e A-F), onde A representa o
próximo valor após 9 e F, portanto, representa um valor equivalente a 15 em decimal, ou 1111 em
binário.

Conversão Binária vs. Decimal

 Entende-se que um byte contém 8 bits e atua como uma notação comum em redes IP, portanto, um
byte representa um valor de bit de 256, variando de 0 a 255. Essas informações são claramente
representadas por tradução de notação decimal para binário e aplicativo da potência base para cada
valor binário, para atingir o intervalo de valores de 256 bits. Uma tradução do sistema de numeração
para binário pode ser vista no exemplo para permitir a familiarização com os padrões de numeração
associados ao binário. O exemplo também demonstra claramente como os valores do endereço de
broadcast em decimal, binário e hexadecimal são representados para permitir que as transmissões
sejam obtidas no endereçamento IP e MAC na rede e nas camadas de enlace de dados.

Conversão Binária

A combinação de 32 bits dentro de um endereço IP está correlacionada a quatro octetos ou bytes

para os quais cada um pode representar um intervalo de valores de 256, fornecendo um número teórico
de 4'294'967'296 endereços IP possíveis, mas na verdade apenas uma fração do O número total de
endereços pode ser atribuído aos hosts. Cada bit dentro de um byte representa uma potência base e,
como tal, cada octeto pode representar uma classe de rede específica, sendo cada classe de rede
baseada em um único octeto ou em uma combinação de octetos. Três octetos foram usados como parte
deste exemplo para representar a rede com o quarto octeto representando o intervalo do host que é
suportado pela rede.

Classes de endereço IP
 O número de octetos suportados por um endereço de rede é determinado por classes de endereço
que dividem o escopo de endereço do IPv4. Classes A, B e C são intervalos de endereços designáveis,
cada um dos quais suporta um número variado de redes e um número de hosts que são designáveis a
uma determinada rede. A classe A, por exemplo, consiste em 126 redes potenciais, cada uma das quais
pode suportar 224 ou 16'777'216 endereços de host potenciais, tendo em mente que os endereços de
rede e de transmissão de um intervalo de classe não podem ser atribuídos a hosts.
Na verdade, uma única rede Ethernet nunca poderia suportar um número tão grande de hosts, já que
a Ethernet não se adapta bem, em parte devido às transmissões que geram tráfego de rede excessivo
em uma única rede local. Os intervalos de endereços de classe C permitem uma rede muito mais
balanceada que se adapta bem a redes Ethernet, fornecendo pouco mais de 2 milhões de redes
potenciais, com cada rede capaz de suportar cerca de 256 endereços, dos quais 254 são atribuíveis a
hosts.
A classe D é um intervalo reservado para multicast, para permitir que os hosts escutem um endereço
específico dentro desse intervalo, e se o endereço de destino de um pacote contiver um endereço
multicast para o qual o host esteja escutando, o pacote será processado da mesma maneira como um
pacote destinado ao endereço IP atribuído aos hosts. Cada classe é facilmente distinguível em binário,
observando o valor de bit dentro do primeiro octeto, onde um endereço de classe A, por exemplo,
sempre começará com um 0 para o bit de alta ordem, enquanto que em uma classe B os dois primeiros
bits de alta ordem são sempre definidos como 1 e 0, permitindo que todas as classes sejam facilmente
determinadas em binário.

Tipos de endereço IP
 No IPv4, endereços específicos e intervalos de endereços foram reservados para propósitos especiais.
Intervalos de endereços privados existem dentro dos intervalos de endereços de classe A, B e C para
prolongar o rápido declínio no número de endereços IP disponíveis. Atualmente, o número de
dispositivos e sistemas finais reais que exigem endereçamento IP no mundo excede os endereços
4'294'967'296 do intervalo de endereços IPv4 de 32 bits e, portanto, uma solução para esse problema
crescente foi alocar intervalos de endereços privados que poderiam ser atribuído a redes privadas, para
permitir a conservação de endereços de redes públicas que facilitem a comunicação através de infra-
estruturas de redes públicas, como a Internet.
As redes privadas se tornaram comuns em toda a rede corporativa, mas os hosts não conseguem
interagir com a rede pública, o que significa que os intervalos de endereços podem ser reutilizados em
muitas redes corporativas diferentes. No entanto, o tráfego vinculado a redes públicas deve passar por
uma tradução de endereços antes que os dados possam chegar ao destino pretendido.
Outros endereços especiais incluem um intervalo de diagnóstico denotado pelo endereço de rede
127.0.0.0, bem como o primeiro e último endereços dentro do intervalo de endereços IPv4, para o qual
0.0.0.0 representa qualquer rede e para o qual sua aplicação deve ser introduzida em mais detalhes com
princípios de roteamento. O endereço 255.255.255.255 representa um endereço de broadcast para a
rede IPv4 (0.0.0.0), no entanto, o escopo de qualquer transmissão em IP é restrito aos limites da rede
local a partir da qual a transmissão é gerada.

Comunicação IP
 Para que um host envie o tráfego para um destino, é necessário que um host tenha conhecimento da
rede de destino. Um host está naturalmente ciente da rede à qual pertence, mas geralmente não está
ciente de outras redes, mesmo quando essas redes podem ser consideradas parte da mesma rede física.
Como tal, os hosts não encaminharão os dados destinados a um determinado destino até que o host
aprenda sobre a rede e, portanto, com ela, a interface pela qual o destino pode ser alcançado.
Para um host encaminhar tráfego para outro host, ele deve primeiro determinar se o destino faz
parte da mesma rede IP. Isso é obtido por meio da comparação da rede de destino com a rede de
origem (endereço IP do host) da qual os dados são originários. Onde os intervalos de rede coincidem, o
pacote pode ser encaminhado para as camadas inferiores onde o enquadramento Ethernet preside,
para processamento. No caso em que a rede de destino pretendida varia da rede de origem, espera-se
que o host tenha conhecimento da rede pretendida e da interface através da qual um pacote / quadro
deve ser encaminhado antes que o pacote possa ser processado pelas camadas inferiores. Sem essa
informação, o host irá abandonar o pacote antes mesmo de chegar à camada de enlace de dados.
 Máscara de sub-rede

A identificação de um segmento de rede exclusivo é governada pela implementação de um valor de

máscara que é usado para distinguir o número de bits que representam o segmento de rede, para o qual
os bits restantes são entendidos como representando o número de hosts suportados em um
determinado segmento de rede . Um administrador de rede pode dividir um endereço de rede em sub-
redes para que os pacotes de transmissão sejam transmitidos dentro dos limites de uma única sub-rede.
A máscara de sub-rede consiste em uma sequência de valores contínuos e ininterruptos, seguidos por
uma sequência ininterrupta de valores 0. Os valores 1 correspondem ao campo de ID da rede, enquanto
os valores 0 correspondem ao campo ID do host.

Máscara de sub-rede padrão

Para cada classe de endereço de rede, uma máscara de sub-rede correspondente é aplicada para
especificar o tamanho padrão do segmento de rede. Qualquer rede considerada como parte do
intervalo de endereços de classe A é fixada com uma máscara de sub-rede padrão pertencente aos 8
bits mais à esquerda que fazem parte do primeiro octeto do endereço IP, permanecendo os três octetos
restantes disponíveis para atribuição do ID de host.
De maneira semelhante, a rede de classe B reflete uma máscara de sub-rede padrão de 16 bits,
permitindo um número maior de redes dentro do intervalo da classe B ao custo do número de hosts que
podem ser atribuídos por rede padrão. A rede de classe C usa como padrão uma máscara de 24 bits que
fornece um grande número de redes potenciais, mas limita muito o número de hosts que podem ser
atribuídos dentro da rede padrão. As redes padrão fornecem um limite comum para intervalos de
endereços, no entanto, no caso de intervalos de endereços de classe A e classe B, não fornecem uma
escala prática para alocação de endereços para redes baseadas em Ethernet.
 Planejamento de Endereços

A aplicação da máscara de sub-rede a um determinado endereço IP permite a identificação da rede à

qual o host pertence. A máscara de sub-rede também identificará o endereço de transmissão da rede,
bem como o número de hosts que podem ser suportados como parte do intervalo da rede. Tais
informações fornecem a base para o planejamento efetivo de endereços de rede. No exemplo dado, um
host foi identificado com o endereço 192.168.1.7 como parte de uma rede com uma máscara de sub-
rede de 24 bits padrão (classe C) aplicada. Ao distinguir qual parte do endereço IP constitui os
segmentos de rede e host, o endereço de rede padrão pode ser determinado para o segmento.
Isso é entendido como o endereço em que todos os valores de bit do host são definidos como 0,
nesse caso, gerando um endereço de rede padrão de 192.168.1.0. Onde os valores do host são
representados por uma cadeia contínua de 1 valores, o endereço de broadcast da rede pode ser
determinado. Onde o último octeto contém uma cadeia de 1 valores, representa um valor decimal de
255, para o qual um endereço de broadcast de 192.168.1.255 pode ser derivado.
Os possíveis endereços de host são calculados com base em uma fórmula de 2n, em que n representa
o número de bits de host definidos pela máscara de sub-rede. Nessa instância, n representa um valor de
8 bits de host, em que 28 fornece um valor resultante de 256. O número de endereços de host
utilizáveis requer, no entanto, que os endereços de rede e transmissão sejam deduzidos desse resultado
para fornecer um número de endereços de host válidos.
 Cenário do caso

O cenário de caso fornece um intervalo de endereço comum de classe B para o qual é necessário
determinar a rede à qual o host especificado pertence, junto com o endereço de broadcast e o número
de hosts válidos que são suportados pela rede especificada. Aplicando os mesmos princípios do
intervalo de endereços de classe C, é possível determinar o endereço de rede do host, juntamente com
o intervalo de hosts dentro da rede determinada.

Limitações de endereçamento

Uma das principais restrições da máscara de sub-rede padrão ocorre quando vários intervalos de
endereços de rede são aplicados a uma determinada empresa para gerar limites lógicos entre os hosts
na rede corporativa física. A aplicação de um esquema de endereçamento básico pode exigir que um
número limitado de hosts seja associado a uma determinada rede, para os quais várias redes são
aplicadas para fornecer a segmentação lógica da rede. Ao fazer isso, no entanto, uma grande
quantidade de espaço de endereçamento permanece sem uso, exibindo a ineficiência do aplicativo de
máscara de sub-rede padrão.
 Cálculo de VLSM

Como forma de resolver as limitações das máscaras de sub-rede padrão, o conceito de máscaras de
sub-rede de tamanho variável é introduzido, o que permite que uma máscara de sub-rede padrão seja
dividida em várias sub-redes, que podem ser de comprimento fixo máscaras ou FLSM) ou de
comprimento variável conhecido comumente pelo termo VLSM. A implementação dessas máscaras de
sub-rede consiste em usar uma rede baseada em classes padrão e dividir a rede através da manipulação
da máscara de sub-rede.
No exemplo dado, uma variação simples foi feita para a rede padrão da classe C, que por padrão é
governada por uma máscara de 24 bits. A variação vem na forma de um bit emprestado do ID do host
que foi aplicado como parte do endereço de rede. Onde o desvio de bits ocorre em comparação com a
rede padrão, os bits adicionais representam o que é conhecido como o ID de sub-rede.
Neste caso, um único bit foi usado para representar a sub-rede para a qual duas sub-redes podem ser
derivadas, já que um único valor de bit pode representar apenas dois estados de 1 ou 0. Onde o bit é
definido como 0, ele representa um valor de 0, onde é definido como 1, representa um valor de 128. Ao
definir os bits de host como 0, o endereço de sub-rede pode ser encontrado para cada sub-rede,
definindo os bits de host como 1, a transmissão endereço para cada sub-rede é identificável. O número
de hosts suportados neste caso representa um valor de 27 menos o endereço de sub-rede e o endereço
de broadcast de cada sub-rede, resultando em cada sub-rede suportando um total de 126 endereços de
host válidos.
 Cenário de Caso VLSM

Em relação ao problema de limitações de endereço em que as redes padrão resultaram em

desperdício de endereço excessivo, o conceito de máscaras de sub-rede de comprimento variável pode
ser aplicado para reduzir o desperdício de endereço e fornecer um esquema de endereçamento mais
eficaz para a rede corporativa.
Um único intervalo de endereços de classe C padrão foi definido, para o qual as máscaras de sub-rede
de tamanho variável são necessárias para acomodar cada uma das redes lógicas em um único intervalo
de endereços padrão. A atribuição efetiva de máscara de sub-rede requer que o número de bits de host
necessários para acomodar o número necessário de hosts seja determinado, para o qual os bits de host
restantes podem ser aplicados como parte do ID de sub-rede, que representa a variação no ID de rede
da rede padrão endereço.

Encaminhamento inter-domínio classless

O roteamento interdomínio sem classe foi inicialmente introduzido como uma solução para lidar com
problemas que estavam ocorrendo como resultado do rápido crescimento do que hoje é conhecido
como Internet. As principais preocupações eram o esgotamento iminente do espaço de endereço de
classe B que era comumente adotado pelas organizações de médio porte como a faixa de endereços
mais adequada, onde a classe C era inadequada e onde a classe A era muito grande e o gerenciamento
dos endereços de host 65534 poderia ser alcançado através de VLSM. Além disso, o crescimento
contínuo significava que os dispositivos de gateway, como os roteadores, estavam começando a se
esforçar para acompanhar o crescente número de redes que esses dispositivos deveriam suportar. A
solução dada envolve a transição para um sistema de endereçamento sem classes, no qual limites de
classes foram substituídos por prefixos de endereço.
Essa notação funciona com base no princípio de que intervalos de endereços de classe como o da
classe C podem ter um prefixo de 24 bits que representa a sub-rede ou o limite da rede principal e para
os quais é possível resumir vários prefixos de rede em uma única rede maior prefixo de endereço que
representa as mesmas redes, mas como um prefixo de endereço único. Isso ajudou a aliviar o número
de rotas contidas, particularmente, em dispositivos de roteamento de larga escala que operam em
escala global e forneceu um meio mais eficaz de gerenciamento de endereços. O resultado do CIDR teve
efeitos de longo alcance e entendeu-se que efetivamente diminuiu a taxa geral de exaustão do espaço
de endereços IPv4.

IP Gateways

O encaminhamento de pacotes requer que o pacote primeiro determine um caminho de

encaminhamento para uma dada rede, e a interface através da qual um pacote deve ser encaminhado,
antes de ser encapsulado como um quadro e encaminhado a partir da interface física. No caso em que a
rede pretendida é diferente da rede de origem, o pacote deve ser encaminhado para um gateway
através do qual o pacote é capaz de alcançar o destino pretendido.
Em todas as redes, o gateway é um dispositivo capaz de manipular pacotes e tomar decisões sobre
como os pacotes devem ser roteados, a fim de alcançar o destino pretendido. O dispositivo em questão,
no entanto, deve estar ciente de uma rota para a rede IP de destino pretendida, antes que o
roteamento de pacotes possa ocorrer. Onde as redes são divididas por um gateway físico, o endereço IP
da interface (na mesma rede ou sub-rede) através do qual esse gateway pode ser alcançado é
considerado o endereço do gateway.
No caso de hosts que pertencem a redes diferentes que não são divididas por um gateway físico, é
responsabilidade do host funcionar como o gateway, para o qual o host deve, em primeiro lugar, estar
ciente da rota para a rede na qual os pacotes são para ser encaminhado, e deve especificar o endereço
IP da própria interface do host como o endereço IP do gateway, através do qual a rede de destino
desejada pode ser alcançada.

Fragmentação IP

Os dados de pacotes encaminhados existem em muitos formatos e consistem em tamanhos variados,

geralmente o tamanho dos dados a serem transmitidos excede o tamanho suportado para transmissão.
Quando isso ocorre, é necessário que o bloco de dados seja dividido em blocos menores de dados antes
que a transmissão possa ocorrer. O processo de decompor esses dados em blocos gerenciáveis é
conhecido como fragmentação.
Os campos de identificação, sinalizadores e deslocamento de fragmento são usados para gerenciar a
remontagem de fragmentos de dados, uma vez recebidos no destino final pretendido. A identificação
distingue entre blocos de dados de fluxos de tráfego que podem ter origem no mesmo host ou em hosts
diferentes. O campo flags determina qual de um número de fragmentos representa o último fragmento
em que o início de um temporizador é iniciado antes da remontagem, e para notificar que a
remontagem do pacote deve começar.
Finalmente, o deslocamento do fragmento rotula o valor do bit para cada fragmento como parte de
um número de fragmentos, o primeiro fragmento é definido com um valor de 0 e fragmentos
subsequentes especificam o valor do primeiro bit após o fragmento anterior, por exemplo, onde o
fragmento inicial contém bits de dados de 0 a 1259, o seguinte fragmento será atribuído a um valor de
deslocamento de 1260.
 Tempo de Vida

À medida que os pacotes são encaminhados entre as redes, é possível que os pacotes caiam em loops
onde as rotas para as redes IP não foram definidas corretamente nos dispositivos responsáveis pelo
roteamento do tráfego entre várias redes. Isso pode resultar na perda de pacotes dentro de um ciclo de
encaminhamento de pacotes que não permite que um pacote alcance seu destino pretendido. Quando
isso ocorre, o congestionamento na rede ocorrerá à medida que mais e mais pacotes destinados ao
mesmo destino se tornarem sujeitos ao mesmo destino, até o momento em que a rede ficar inundada
de pacotes errados.
Para evitar que tal congestionamento ocorra no caso de tais loops, um campo de tempo de vida (TTL)
é definido como parte do cabeçalho IP, que diminui em um valor de 1 cada vez que um pacote atravessa
um dispositivo de camada 3 para alcançar uma determinada rede. O valor TTL inicial pode variar
dependendo da fonte de origem, no entanto, se o valor TTL diminuir para um valor de 0, o pacote será
descartado e uma mensagem de erro (ICMP) será retornada à origem, com base no endereço IP de
origem que pode ser encontrado no cabeçalho IP do pacote errante.
 Campo de Protocolo

Após a verificação de que o pacote atingiu seu destino pretendido, a camada de rede deve
determinar o próximo conjunto de instruções a serem processadas. Isso é determinado analisando o
campo de protocolo do cabeçalho IP. Assim como no campo de tipo do cabeçalho do quadro, um valor
hexadecimal é usado para especificar o próximo conjunto de instruções a serem processadas.
Deve ser entendido que o campo de protocolo pode se referir a protocolos na camada de rede, como
no caso do protocolo ICMP, mas também pode se referir a protocolos de camada superior, como o
protocolo de controle de transmissão (06 / 0x06) ou User Datagram Protocol (17 / 0x11), ambos os quais
existem como parte da camada de transporte nos modelos de referência TCP / IP e OSI.

Resumo
1-Para que serve a máscara de sub-rede IP?
A máscara de sub-rede IP é um valor de 32 bits que descreve a divisão lógica entre os valores de bit
de um endereço IP. O endereço IP é dividido em duas partes para as quais os valores de bits
representam uma rede ou sub-rede e o host em uma determinada rede ou sub-rede.
2-Qual é o objetivo do campo TTL no cabeçalho IP?
Os pacotes IP que não conseguem acessar a rede pretendida são suscetíveis de serem encaminhados
indefinidamente entre redes, na tentativa de descobrir seu destino final. O recurso Time To Live (TTL) é
usado para garantir que uma vida útil seja aplicada a todos os pacotes IP, de modo a garantir que, no
caso de um pacote IP não conseguir chegar ao seu destino, ele será encerrado. O valor de TTL pode
variar dependendo da fonte original.
 3-Como os gateways são usados em uma rede IP?
Os gateways representam pontos de acesso entre redes IP para as quais o tráfego pode ser
redirecionado ou roteado no caso de a rede de destino pretendida variar da rede na qual o pacote foi
originado.
Prefácio
O ICMP é um protocolo que trabalha junto com o IP como uma forma de
protocolo de mensagens para compensar a confiabilidade limitada do IP. A
implementação do ICMP deve ser entendida para se familiarizar com o
comportamento de várias operações e aplicativos que dependem muito do ICMP,
para suportar o sistema de mensagens subjacente, com base no qual processos
adicionais são freqüentemente executados.

Objectivos
Após a conclusão desta seção, os formandos serão capazes de:
 Descrever alguns dos processos aos quais o ICMP é aplicado.
 Identificar os valores comuns de tipo e código usados no ICMP.
 Explicar a função do ICMP nas aplicações ping e traceroute
 ICMP

O Protocolo de Mensagens de Controle da Internet é parte integrante do IP projetado para facilitar a

transmissão de mensagens de notificação entre gateways e hosts de origem, onde são necessárias
solicitações de informações de diagnóstico, suporte de roteamento e como forma de relatar erros no
processamento de datagramas. O objetivo dessas mensagens de controle é fornecer feedback sobre
problemas no ambiente de comunicação e não garante que um datagrama será entregue ou que uma
mensagem de controle será retornada.

ICMP (Routing)

As mensagens de redirecionamento ICMP representam um cenário comum em que o ICMP é usado

como um meio de facilitar as funções de roteamento. No exemplo, um pacote é encaminhado para o
gateway pelo host A com base no endereço de gateway do host A. O gateway identifica que o pacote
recebido está destinado a ser encaminhado para o endereço do próximo gateway que passa a fazer
parte do mesmo rede como o host que originou o pacote, destacando um comportamento de
encaminhamento não ideal entre o host e os gateways.
Para resolver isso, uma mensagem de redirecionamento é enviada ao host. A mensagem de
redirecionamento aconselha o host a enviar seu tráfego para o destino pretendido diretamente ao
gateway com o qual a rede de destino está associada, pois isso representa um caminho mais curto para
o destino. O gateway prossegue, no entanto, para encaminhar os dados do pacote original para o
destino pretendido.
 ICMP (diagnóstico)

ICMP echo messages represent a means of diagnosis for determining primarily connectivity between
a given source and destination, but also provides additional information such as the round trip time for
transmission as a diagnostic for measuring delay. Data that is received in the echo message is returned
as a separate echo reply message.

ICMP (erros)

O ICMP fornece várias mensagens de relatório de erros que geralmente determinam problemas de
alcance e geram relatórios de erro específicos que permitem um entendimento mais claro, do ponto de
vista do host, do motivo pelo qual a transmissão para o destino pretendido falhou.
Exemplos típicos incluem casos em que loops podem ter ocorrido na rede e consequentemente
causaram a expiração do parâmetro time to live no cabeçalho IP, resultando na geração de uma
mensagem de erro “ttl excedido em trânsito”. Outros exemplos incluem um destino pretendido sendo
inacessível, o que poderia estar relacionado a um problema mais específico da rede pretendida que não
é conhecido pelo gateway de recebimento ou que o host pretendido na rede de destino não está sendo
descoberto. Em todos os eventos, uma mensagem ICMP é gerada com um destino com base no
endereço IP de origem localizado no cabeçalho IP, para garantir que a mensagem notifique o host de
envio.
 Formato ICMP

Mensagens ICMP são enviadas usando o cabeçalho IP básico, que funciona em conjunto como parte
integral da mensagem ICMP, como é o caso do parâmetro TTL que é usado para fornecer suporte para
determinar se um destino é alcançável. O formato da mensagem ICMP depende de dois campos para
identificação de mensagem na forma de um formato de tipo / código, em que o campo de tipo fornece
uma descrição geral do tipo de mensagem e o código e um parâmetro mais específico para o tipo de
mensagem.
Uma soma de verificação fornece um meio de validar a integridade da mensagem ICMP. Um adicional
de 32 bits são incluídos para fornecer parâmetros variáveis, muitas vezes não utilizados e, portanto,
definidos como 0 quando a mensagem ICMP é enviada, no entanto, em casos como um
redirecionamento ICMP, o campo contém o endereço IP do gateway para o qual um host deve
redirecionar pacotes. O campo de parâmetro no caso de solicitações de eco conterá um identificador e
um número de sequência, usado para ajudar o associado de origem a enviar solicitações de eco com
respostas de eco recebidas, especialmente no caso de várias solicitações serem encaminhadas para um
determinado destino.
Como meio final de rastrear dados para um processo específico, a mensagem ICMP pode transportar
o cabeçalho IP e uma parte dos dados que contém informações da camada superior que permitem que a
origem identifique o processo para o qual ocorreu um erro, como casos em que O ICMP TTL expira em
trânsito.

Tipo ICMP e campos de código

 Existe um grande número de valores do tipo ICMP para definir claramente as diferentes aplicações do
protocolo de controle ICMP. Em alguns casos, o campo de código não é necessário para fornecer uma
entrada mais específica para o campo type, como é encontrado em solicitações de eco que possuem um
campo de tipo 8 e a resposta correspondente, que é gerada e enviada como uma mensagem ICMP
separada para o endereço de origem do remetente e definido usando um campo de tipo de 0.
Alternativamente, determinados campos de tipos definem um tipo muito geral para o qual a
variância é compreendida através do campo de código, como no caso do parâmetro tipo 3. Um campo
de tipo 3 especifica que um determinado destino é inacessível, enquanto o campo de código reflete a
ausência específica de rede, host, protocolo, porta (TCP / UDP), capacidade de realizar fragmentação
(código 4) ou rota de origem ( código 5) em que um pacote, para o qual um caminho de
encaminhamento através da rede é estrito ou parcialmente definido, não consegue chegar ao seu
destino.

Aplicações ICMP – Ping

A aplicação do ICMP pode ser entendida através do uso de ferramentas como o Ping. O aplicativo
Ping pode ser usado como uma ferramenta para determinar se um destino pode ser acessado, bem
como coletar outras informações relacionadas. Os parâmetros do aplicativo Ping permitem que um
usuário final especifique o comportamento do sistema final na geração de mensagens ICMP, levando em
consideração o tamanho do datagrama ICMP, o número de mensagens ICMP geradas pelo host e
também a duração em que ele ocorre. é esperado que uma resposta seja recebida antes de ocorrer um
tempo limite. Isso é importante quando ocorre um grande atraso, pois um tempo limite pode ser
relatado pelo aplicativo Ping antes que a mensagem ICMP tenha a oportunidade de retornar à origem.
 Resultados do Ping

A saída geral de uma resposta ICMP para uma solicitação ICMP gerada pelo Ping detalha o destino
para o qual o datagrama foi enviado e o tamanho do datagrama gerado. Além disso, o número de
seqüência do campo de seqüência que é transportado como parte da resposta de eco (tipo 0) é exibido
juntamente com o valor TTL que é obtido do cabeçalho IP, bem como o tempo de ida e volta que é
transportado como parte do campo de opções IP no cabeçalho IP.

Aplicação ICMP – Traceroute

Outra aplicação comum ao ICMP é o traceroute, que fornece um meio de medir o caminho de
encaminhamento e o atraso em uma base hop-by-hop entre várias redes, através da associação com o
valor TTL dentro do cabeçalho IP.
Para um determinado destino, a alcançabilidade de cada salto ao longo do caminho é medida
definindo inicialmente um valor TTL no cabeçalho IP de 1, fazendo com que o valor TTL expire antes que
o gateway receptor seja capaz de propagar a mensagem ICMP, gerando assim um TTL expirou em
mensagem de trânsito junto com informações de registro de data e hora, permitindo uma avaliação de
salto a salto do caminho percorrido pela rede pelo datagrama até o destino e uma medição do tempo de
ida e volta. Isso fornece um meio eficaz de identificar o ponto de qualquer perda ou atraso de pacote
que possa ocorrer na rede e também ajuda na descoberta de loops de roteamento.

Resultados do Traceroute

A implementação do traceroute nos roteadores da série Huawei ARG3 adota o uso do protocolo da
camada de transporte UDP para definir uma porta de serviço como o destino. Cada salto envia três
pacotes de sondagem, para os quais o valor de TTL é inicialmente definido para um valor de 1 e
incrementado após cada três pacotes. Além disso, uma porta de destino UDP de 33434 é especificada
para o primeiro pacote e incrementada para cada pacote de sondagem sucessivo enviado. Um resultado
hop-by-hop é gerado, permitindo que o caminho seja determinado, assim como qualquer atraso geral
que possa ocorrer para ser descoberto.
Isso é obtido medindo-se a duração entre o momento em que a mensagem ICMP foi enviada e
quando o erro TTL correspondente expirado em trânsito é recebido. Ao receber um pacote, o destino
final é incapaz de descobrir a porta especificada no pacote e, portanto, retorna um pacote ICMP Tipo 3,
Código 3 (Porta Inacessível) e, após três tentativas, o teste traceroute é finalizado. O resultado do teste
de cada sonda é exibido pela fonte, de acordo com o caminho da origem até o destino. Se ocorrer uma
falha quando o comando de rota de rastreio for usado, as seguintes informações podem ser exibidas:
! H: O host está inacessível.
! N: A rede está inacessível.
!: A porta está inacessível.
! P: O tipo de protocolo está incorreto.
! F: O pacote está fragmentado incorretamente.
! S: a rota de origem está incorreta.
 Resumo

1-Quais são os dois tipos de mensagens ICMP usados como parte de um Ping bem-sucedido?
A aplicação Ping usa a mensagem de solicitação de eco do tipo 8 para tentar descobrir o destino.
Uma mensagem de resposta de eco separada, definida por um campo de tipo 0, é retornada à origem
original com base no endereço IP de origem no campo de cabeçalho IP.

2-No caso de o valor TTL no cabeçalho IP de um datagrama chegar a zero, qual ação será tomada pelo
gateway de recebimento?
No caso de o valor TTL de um datagrama IP atingir 0 antes que o datagrama consiga alcançar o
destino pretendido, o dispositivo de gateway que recebe o datagrama continuará a descartá-lo e
retornará uma mensagem ICMP à fonte para notificar que o datagrama em questão não conseguiu
alcançar o destino pretendido. O motivo específico será definido pelo valor do código para refletir, por
exemplo, se a falha ocorreu devido a uma falha ao descobrir o host, uma porta no host ou se o serviço
para um determinado protocolo não era suportado, etc.
 Prefácio
Para que a transmissão de dados para um destino de rede seja alcançada, é necessário
construir uma associação entre a camada de rede e os protocolos de camada inferior. Os
meios pelos quais o Protocolo de Resolução de Endereços é usado para construir essa
associação e evitar a geração desnecessária de tráfego de broadcast adicional na rede
devem ser claramente compreendidos.

Objectivos
Após a conclusão desta seção, os formandos serão capazes de:
 Explicar como o endereço MAC é resolvido usando o ARP.
 Explicar a função da tabela de cache do ARP.
 ARP

À medida que os dados são encapsulados, o protocolo IP na camada de rede é capaz de especificar o
endereço IP alvo para o qual os dados são destinados, assim como a interface pela qual os dados devem
ser transmitidos, no entanto antes que a transmissão possa ocorrer, deve estar ciente do endereço
Ethernet (MAC) de destino para o qual os dados devem ser transmitidos. O protocolo de resolução de
endereços (ARP) representa uma parte crítica do conjunto de protocolos TCP / IP que permite a
descoberta de endereços de encaminhamento de MAC para facilitar a acessibilidade de IP. O próximo
salto Ethernet deve ser descoberto antes que o encapsulamento de dados possa ser concluído.

Formato ARP

O pacote ARP é gerado como parte do processo de descoberta do endereço de destino físico. A
descoberta inicial conterá informações parciais, pois o endereço de hardware ou endereço MAC de
destino deve ser descoberto. O tipo de hardware refere-se à Ethernet com o tipo de protocolo referente
ao IP, definindo as tecnologias associadas à descoberta do ARP. O comprimento do hardware e do
protocolo identifica o comprimento do endereço para o endereço MAC Ethernet e o endereço IP e é
definido em bytes.
 O código de operação especifica um dos dois estados, onde a descoberta de ARP é definida como
REQUEST para qual recepção da transmissão de ARP pelo destino identificará que uma resposta deve ser
gerada. A resposta gerará REPLY para a qual nenhuma operação adicional é necessária pelo host de
recebimento deste pacote, e após o qual o pacote ARP será descartado. O endereço de hardware de
origem refere-se ao endereço MAC do remetente no segmento físico para o qual o ARP é gerado. O
endereço do protocolo de origem refere-se ao endereço IP do remetente.
O endereço de hardware de destino especifica o endereço físico (Ethernet) para o qual os dados
podem ser encaminhados pelos padrões de protocolo Ethernet, no entanto, essas informações não
estão presentes em uma solicitação ARP, substituídas por um valor 0. O endereço de protocolo de
destino identifica o IP desejado destino para o qual a acessibilidade pela Ethernet deve ser estabelecida.

Processo ARP

A camada de rede representa um caminho lógico entre uma origem e um destino. Atingir um destino
de IP pretendido depende primeiramente de ser possível estabelecer um caminho físico para o destino
pretendido e, para fazer isso, uma associação deve ser feita entre o destino de IP pretendido e a
interface de próximo salto físico para a qual o tráfego pode ser encaminhado.
Para um determinado destino, o host determinará o endereço IP para o qual os dados devem ser
encaminhados, no entanto, antes que o encapsulamento dos dados possa começar, o host deve
determinar se um caminho de encaminhamento físico é conhecido. Se o caminho de encaminhamento é
conhecido, o encapsulamento para o destino pode prosseguir, no entanto, muitas vezes o destino não é
conhecido e o ARP deve ser implementado antes que o encapsulamento de dados possa ser executado.
 Pesquisa de cache ARP

O cache ARP (pronunciado como [kash]) é uma tabela para associação de endereços IP de destino do
host e endereços físicos associados (MAC). Qualquer host que esteja envolvido na comunicação com um
destino local ou remoto precisará primeiro aprender sobre o MAC de destino através do qual a
comunicação pode ser estabelecida.
Endereços aprendidos preencherão a tabela de cache ARP e permanecerão ativos por um período de
tempo fixo, durante o qual o destino pretendido poderá ser descoberto sem a necessidade de processos
adicionais de descoberta de ARP. Após um período fixo, a tabela de cache ARP removerá as entradas
ARP para manter a integridade da tabela de cache ARP, já que qualquer alteração na localização física de
um host de destino pode resultar no host inadvertidamente endereçando dados para um destino no
qual o host de destino não mais reside.
A consulta do cache ARP é a primeira operação que um sistema final executará antes de determinar
se é necessário gerar uma solicitação ARP. Para destinos além dos limites da própria rede de hosts, uma
consulta de cache ARP é realizada para descobrir o endereço de destino físico do gateway, através do
qual a rede de destino pretendida pode ser alcançada.
 Processo de Solicitação ARP

Onde uma entrada de cache ARP não puder ser determinada, o processo de solicitação ARP é
executado. Esse processo envolve a geração de um pacote de solicitação ARP e o preenchimento dos
campos com os endereços de protocolo de origem e destino, bem como o endereço de hardware de
origem. O endereço de hardware de destino é desconhecido. Como tal, o endereço de hardware de
destino é preenchido com um valor equivalente a 0. A solicitação ARP é encapsulada em um cabeçalho
de quadro Ethernet e um trailer como parte do processo de encaminhamento. O endereço MAC de
origem do cabeçalho do quadro é definido como o endereço de origem do host de envio.
O host atualmente não está ciente da localização do destino e, portanto, deve enviar a solicitação
ARP como uma transmissão para todos os destinos dentro do mesmo limite da rede local. Isso significa
que um endereço de broadcast é usado como o endereço MAC de destino. Depois que o quadro é
preenchido, ele é encaminhado para a camada física, onde é propagado ao longo do meio físico ao qual
o host está conectado. O pacote ARP transmitido será inundado em toda a rede para todos os destinos,
incluindo qualquer gateway que possa estar presente, no entanto, o gateway impedirá que essa
transmissão seja encaminhada para qualquer rede além da rede atual.
 Processo de Resposta ARP

Se o destino de rede pretendido existir, o quadro chegará à interface física do destino, no ponto em
que o processamento da camada inferior ocorrerá. As transmissões ARP significam que todos os
destinos dentro do limite da rede receberão o quadro inundado, mas deixarão de processar a solicitação
ARP, uma vez que o endereço do protocolo de destino não corresponde ao endereço IP desses destinos.
Onde o endereço IP de destino corresponde ao host de recebimento, o pacote ARP será processado.
O host receptor primeiro processará o cabeçalho do quadro e, em seguida, processará o pedido ARP. O
host de destino usará as informações do campo de endereço de hardware de origem no cabeçalho ARP
para preencher sua própria tabela de cache ARP, permitindo que um quadro de unicast seja gerado para
qualquer encaminhamento de quadro que possa ser necessário, para a origem da qual o ARP pedido foi
recebido.
 O destino determinará que o pacote ARP recebido é uma solicitação ARP e continuará gerando uma
resposta ARP que será retornada à origem, com base nas informações encontradas no cabeçalho ARP.
Um pacote ARP separado é gerado para a resposta, para o qual os campos de endereço de protocolo de
origem e destino serão preenchidos. No entanto, o endereço de protocolo de destino no pacote de
solicitação ARP agora representa o endereço de protocolo de origem no pacote de resposta ARP e, da
mesma forma, o endereço de protocolo de origem da solicitação ARP se torna o endereço de protocolo
de destino na resposta ARP.
O campo de endereço de hardware de destino é preenchido com o MAC da origem, descoberto como
resultado do recebimento da solicitação ARP. Para o endereço de hardware de destino necessário da
solicitação ARP, ele é incluído como o endereço de hardware de origem da resposta ARP e o código de
operação é configurado para responder, para informar o destino da finalidade do pacote ARP recebido,
após o qual o destino é capaz de descartar o pacote ARP sem qualquer comunicação adicional. A
resposta ARP é encapsulada no cabeçalho e no trailer do quadro Ethernet, com o endereço MAC de
destino do quadro Ethernet contendo a entrada MAC na tabela de cache ARP, permitindo que o quadro
seja encaminhado como um quadro unicast de volta ao host que originou o ARP pedido.

Cache ARP

Ao receber a resposta ARP, o host de origem validará se o destino pretendido está correto com base
no cabeçalho do quadro, identificará que o cabeçalho do pacote é ARP do campo de tipo e descartará os
cabeçalhos do quadro. A resposta ARP será então processada, com o endereço de hardware de origem
da resposta ARP sendo usado para preencher a tabela de cache ARP do host de origem (Host A).
Após o processamento da resposta ARP, o pacote é descartado e as informações MAC de destino são
usadas para facilitar o processo de encapsulamento do aplicativo ou protocolo inicial que originalmente
solicitou a descoberta do destino na camada de enlace de dados.
 Proxy ARP

O protocolo ARP também é aplicado a outros casos, como onde gateways de sub-rede transparentes
devem ser implementados para facilitar a comunicação entre redes físicas, onde os hosts são
considerados parte da mesma sub-rede. Isso é chamado de Proxy ARP, já que o gateway opera como um
proxy para as duas redes físicas. Quando uma solicitação ARP é gerada para um destino que é
considerado parte da mesma sub-rede, a solicitação será eventualmente recebida pelo gateway. O
gateway é capaz de determinar que o destino pretendido existe além da rede física na qual a solicitação
ARP foi gerada.
Como as solicitações ARP não podem ser encaminhadas além dos limites do domínio de broadcast, o
gateway continuará gerando sua própria solicitação ARP para determinar a acessibilidade para o destino
pretendido, usando seus próprios endereços de protocolo e hardware como os endereços de origem da
solicitação ARP gerada. Se o destino pretendido existir, uma resposta ARP deverá ser recebida pelo
gateway para o qual o endereço de hardware de origem de destino será usado para preencher a tabela
de cache ARP do gateway.
O gateway, ao confirmar a acessibilidade ao destino pretendido, gerará uma resposta ARP à fonte
original (Host A) usando o endereço de hardware da interface na qual a resposta ARP foi encaminhada.
O gateway funcionará como um agente entre as duas redes físicas para facilitar a comunicação da
camada de enlace de dados, com ambos os hosts encaminhando o tráfego destinado a destinos em
diferentes redes físicas para o endereço físico relevante do gateway “Proxy”.

ARP gratuito
 No caso em que um novo hardware é introduzido em uma rede, é imperativo que o host determine
se o endereço de protocolo ao qual ele foi atribuído é exclusivo dentro da rede, para evitar conflitos de
endereço duplicados. Uma solicitação ARP é gerada como um meio de determinar se o endereço do
protocolo é exclusivo, definindo o endereço de destino na solicitação ARP como igual ao endereço IP do
host.
A solicitação ARP é inundada em toda a rede para todos os destinos da camada de conexão,
definindo o MAC de destino como broadcast, para garantir que todas as estações finais e gateways
recebam o quadro inundado. Todos os destinos processarão o quadro e, se qualquer destino descobrir
que o endereço IP de destino na solicitação ARP corresponde ao endereço de uma estação final ou
gateway de recebimento, uma resposta ARP será gerada e retornada ao host que gerou a solicitação
ARP.
Por meio desse método, o host de origem é capaz de identificar a duplicação do endereço IP dentro
da rede e sinalizar um conflito de endereço IP para solicitar que um endereço exclusivo seja atribuído.
Esse meio de gerar uma solicitação com base no endereço IP do próprio host define os princípios básicos
do ARP gratuito.

Resumo
1-Antes de gerar uma solicitação ARP, qual ação deve ser tomada por uma estação final?
O host é necessário para determinar inicialmente se já está ciente de um endereço de
encaminhamento da camada de enlace dentro de seu próprio cache ARP (tabela de endereços MAC). Se
uma entrada for descoberta, o sistema final será capaz de criar o quadro para encaminhamento sem a
assistência do protocolo de resolução de endereço. Se uma entrada não puder ser encontrada, o
processo ARP será iniciado e uma solicitação ARP será transmitida na rede local.

2-Quando as mensagens ARP gratuitas são geradas e propagadas na rede local?

Mensagens ARP gratuitas são normalmente geradas no ponto em que um endereço IP é configurado
ou alterado para um dispositivo conectado à rede e a qualquer momento em que um dispositivo é
fisicamente conectado à rede. Em ambos os casos, o processo ARP gratuito deve garantir que o
endereço IP usado permaneça exclusivo
 Prefácio
A camada de transporte está associada ao comportamento de ponta a ponta dos
protocolos da camada de transporte definidos quando os dados chegam ao destino
pretendido. TCP e UDP representam os protocolos geralmente suportados em redes IP.
As características dos dados, como a sensibilidade ao atraso e a necessidade de
confiabilidade, freqüentemente determinam os protocolos usados na camada de
transporte. Esta seção enfoca o conhecimento de como tais características são
suportadas através do comportamento de cada protocolo.

Objectivos
Após a conclusão desta seção, os formandos serão capazes de:
 Descrever as diferenças comuns entre o TCP e o UDP.
 Descrever os formulários de dados aos quais o TCP e o UDP são aplicados.
 Identificar números de porta TCP e UDP bem conhecidos.
 Protocolo de Controle de Transmissão

O TCP é um protocolo de ponta a ponta orientado a conexão que existe como parte da camada de
transporte da pilha de protocolos TCP / IP, para suportar aplicativos que abrangem ambientes de várias
redes. O protocolo de controle de transmissão fornece um meio de comunicação confiável entre
processos entre pares de processos em computadores host que são conectados a redes de comunicação
de computador distintas, mas interconectadas. O TCP depende de protocolos de camada inferior para
fornecer a acessibilidade entre hosts de suporte a processos, sobre os quais um serviço de conexão
confiável é estabelecido entre pares de processos. O comportamento orientado a conexões do TCP
envolve trocas anteriores entre a origem e o destino, por meio das quais uma conexão é estabelecida
antes que os segmentos da camada de transporte sejam comunicados.

Portas TCP

Como um meio de permitir que muitos processos em um único host usem os recursos de
comunicação TCP simultaneamente, o TCP fornece um conjunto de portas lógicas dentro de cada host.
O valor da porta junto com o endereço da camada de rede é referido como um soquete, para o qual um
par de soquetes fornece um identificador exclusivo para cada conexão, em particular quando um
soquete é usado simultaneamente em várias conexões. Ou seja, um processo pode precisar distinguir
entre vários fluxos de comunicação entre si e outro processo (ou processos), para o qual cada processo
pode ter várias portas através das quais se comunica com a porta ou portas de outros processos.
 Certos processos podem possuir portas e esses processos podem iniciar conexões nas portas que eles
possuem. Essas portas são entendidas como portas do sistema atribuídas pela IANA ou portas
conhecidas e existem no intervalo de valores da porta de 0 a 1023. Um intervalo de portas atribuídas ou
de usuário atribuídas pela IANA também existe no intervalo de 1024 - 49151, com portas dinâmicas,
também conhecidas como portas privadas ou efêmeras no intervalo de 49152 - 65535, que não estão
restritas a qualquer aplicação específica. Geralmente, os hosts receberão um valor de porta do usuário
para o qual um soquete é gerado para um determinado aplicativo.
Exemplos comuns de aplicativos baseados em TCP para os quais números de porta conhecidos foram
atribuídos incluem FTP, HTTP, TELNET e SMTP, que geralmente funcionam junto com outros protocolos
de correio conhecidos, como POP3 (porta 110) e IMAP4 (porta 143) .

Cabeçalho TCP

O cabeçalho TCP permite que aplicativos baseados em TCP estabeleçam fluxos de dados orientados à
conexão que sejam entregues com confiabilidade e aos quais o controle de fluxo é aplicado. Um número
de porta de origem é gerado onde um host pretende estabelecer uma conexão com um aplicativo
baseado em TCP, para o qual a porta de destino se relacionará a uma porta conhecida / registrada à qual
um aplicativo conhecido / registrado está associado.
Bits de código representam funções no TCP e incluem um bit urgente (URG) usado junto ao campo de
ponteiro urgente para notificações de dados urgentes direcionadas pelo usuário, reconhecimento de
octetos recebidos em associação com o campo de confirmação (ACK), a função push para
encaminhamento de dados (PSH) ), operações de reinício da ligação (RST), sincronização de números de
sequência (SYN) e indicação de que não é necessário receber mais dados do remetente (FIN). Bits de
código adicionais foram introduzidos na forma de sinalizadores ECN-Echo (ECE) e Redução de Janela de
Congestionamento (CWR), como um meio de suportar a notificação de congestionamento para
aplicativos TCP sensíveis a atrasos.
O nonce sum (NS) de notificação de congestionamento explícito (ECN) foi introduzido como uma
alteração de acompanhamento para eliminar o potencial abuso de ECN em que os dispositivos ao longo
do caminho de transmissão podem remover as marcas de congestionamento de ECN. O campo Opções
contém parâmetros que podem ser incluídos como parte do cabeçalho TCP, geralmente usados durante
o estabelecimento da conexão inicial, como no caso do valor do tamanho máximo do segmento (MSS)
que pode ser usado para definir o tamanho do segmento que o receptor deve usar. O tamanho do
cabeçalho TCP deve ser uma soma de 32 bits e, quando este não for o caso, o preenchimento de valores
0 será executado.

Estabelecimento de conexão TCP

Quando dois processos desejam se comunicar, cada TCP deve primeiro estabelecer uma conexão
(inicializar a sincronização de comunicação em cada lado). Quando a comunicação é concluída, a
conexão é encerrada ou fechada para liberar os recursos para outros usos. Como as conexões devem ser
estabelecidas entre hosts não confiáveis e sobre o domínio não confiável da Internet, um mecanismo de
handshake com números de seqüência baseados em relógio é usado para evitar a inicialização incorreta
das conexões.
Uma conexão progride através de uma série de estados durante o estabelecimento. O estado LISTEN
representa um TCP aguardando uma solicitação de conexão de qualquer TCP e porta remotas. O SYN-
SENT ocorre após o envio de uma solicitação de conexão e antes que uma solicitação correspondente
seja recebida. O estado SYN RECEIVED ocorre enquanto se espera por uma confirmação de confirmação
de solicitação de conexão, depois de ter recebido e enviado uma solicitação de conexão. O estado
ESTABLISHED ocorre após o handshake em que uma conexão aberta é criada e os dados recebidos
podem ser entregues ao usuário.
O mecanismo de handshake de três vias TCP começa com um número de sequência inicial sendo
gerado pelo TCP inicial como parte do processo de sincronização (SYN). O segmento TCP inicial é então
definido com o bit de código SYN e transmitido para o TCP de destino de IP pretendido para obter um
estado SYN-SENT. Como parte do processo de reconhecimento, o TCP emparelhado gerará um número
de sequência inicial próprio para sincronizar o fluxo TCP na outra direção. Este TCP de peering
transmitirá este número de sequência, bem como um número de confirmação que iguala o número de
sequência recebido incrementado por um, juntamente com os bits de código SYN e ACK no cabeçalho
TCP para alcançar um estado SYN RECEIVED.
 A etapa final do handshake de conexão envolve o TCP inicial reconhecendo o número de sequência
do TCP emparelhado, definindo o número de confirmação para igualar o número de sequência recebido
mais um, junto com o bit ACK no cabeçalho TCP, permitindo que um estado ESTABLISHED seja alcançado
.

Processo de Transmissão TCP

Como a transmissão TCP é enviada como um fluxo de dados, cada octeto pode ser sequenciado e,
portanto, cada octeto pode ser reconhecido. O número de confirmação é usado para conseguir isso
respondendo ao remetente como confirmação de recebimento de dados, fornecendo assim
confiabilidade do transporte de dados. No entanto, o processo de reconhecimento é cumulativo, o que
significa que uma cadeia de octetos pode ser reconhecida por uma única confirmação, informando à
fonte o número de sequência que segue imediatamente o número de sequência que foi recebido com
sucesso.
No exemplo, um número de bytes (octetos) são transmitidos juntos antes que a confirmação TCP seja
dada. Se um octeto não for transmitido ao destino, a sequência de octetos transmitidos será apenas
reconhecida até ao ponto em que ocorreu a perda. A confirmação resultante refletirá o octeto que não
foi recebido para reiniciar a transmissão do ponto no fluxo de dados no qual o octeto foi perdido.
A capacidade de acumular múltiplos octetos juntos antes de uma confirmação permite que o TCP
opere com muito mais eficiência, no entanto é necessário um equilíbrio para garantir que o número de
octetos enviados antes de uma confirmação não seja excessivo, pois se um octeto não for recebido,
todo o fluxo de octetos do ponto da perda deve ser retransmitido.
 Controle de Fluxo TCP

O campo da janela TCP fornece um meio de controle de fluxo que controla a quantidade de dados
enviados pelo remetente. Isso é obtido retornando uma "janela" com cada segmento TCP para o qual o
campo ACK está definido, indicando um intervalo de números de seqüência aceitáveis além do último
segmento recebido com êxito. A janela indica o número permitido de octetos que o remetente pode
transmitir antes de receber mais permissão.
No exemplo, a transmissão TCP do host A para o servidor A contém o tamanho atual da janela para o
host A. O tamanho da janela para o servidor A é determinado como parte do handshake, que baseado
na transmissão pode ser assumido como 2048. o tamanho da janela foi recebido, uma confirmação será
retornada, relativa ao número de bytes recebidos, mais um. Depois disso, o host A continuará
transmitindo o próximo lote de dados.
Um tamanho de janela TCP de 0 efetivamente negará o processamento de segmentos, com exceção
dos segmentos em que os bits de código ACK, RST e URG são definidos para segmentos de entrada.
Onde existe um tamanho de janela 0, o remetente ainda deve verificar periodicamente o status do
tamanho da janela do recebimento do TCP para garantir que qualquer alteração no tamanho da janela
seja efetivamente relatada, o período de retransmissão é geralmente de dois minutos. Quando um
remetente envia segmentos periódicos, o TCP receptor ainda deve confirmar com um anúncio de
número de sequência do tamanho atual da janela 0.
 Terminação de Conexão TCP

Como parte do processo de terminação da conexão TCP, vários estados são definidos através dos
quais o TCP fará a transição. Esses estados incluem FIN-WAIT-1, que representa a espera por uma
solicitação de terminação de conexão (FIN) do TCP remoto, ou uma confirmação de uma solicitação de
término de conexão que foi enviada anteriormente. O FIN-WAIT-2 representa a espera por uma
solicitação de término de conexão do TCP remoto, que geralmente fará a transição para um estado
TIME-WAIT. Um estado CLOSE-WAIT indica a espera por uma solicitação de finalização de conexão
definida localmente, geralmente quando o aplicativo de um servidor está em processo de fechamento.
O estado LAST-ACK representa aguardar um reconhecimento da solicitação de término de conexão
enviada anteriormente ao TCP remoto (que inclui uma confirmação de sua solicitação de finalização de
conexão). Finalmente, ocorre um estado TIME-WAIT e aguarda o tempo suficiente para garantir que o
TCP remoto recebeu o reconhecimento de sua solicitação de finalização de conexão. Esse período é
gerenciado pelo timer MSL (Max Segment Lifetime) que define um período de espera de 2 minutos.
Após um período de espera igual a duas vezes o MSL, a conexão TCP é considerada fechada / finalizada.

User Datagram Protocol

O User Datagram Protocol, ou UDP, representa uma alternativa ao TCP e aplicado onde TCP é
encontrado para atuar como um mecanismo de transporte ineficiente, principalmente no caso de
tráfego altamente sensível a atraso. Onde o TCP é considerado um segmento, o UDP é reconhecido
como uma forma de datagrama da Unidade de Dados de Protocolo (PDU), para a qual um datagrama
pode ser entendido como uma entidade independente de dados contendo informação suficiente para
ser roteada a partir da fonte. ao sistema final de destino sem depender de trocas anteriores entre os
sistemas finais de origem e de destino e a rede de transporte, conforme definido na RFC 1594. Com
efeito, isso significa que o tráfego UDP não exige o estabelecimento de uma conexão antes do envio dos
dados.
A estrutura simplificada e a operação do UDP torna-o ideal para programas aplicativos enviarem
mensagens para outros programas, com um mínimo de mecanismo de protocolo, como no caso de
confirmações e janelas, por exemplo, conforme encontrado nos segmentos TCP. Em contrapartida, o
UDP não garante a transmissão de dados nem a proteção contra a duplicação de datagramas.

Formato de Datagrama UDP

O cabeçalho UDP fornece uma abordagem minimalista para a camada de transporte, implementando
apenas uma construção básica para ajudar a identificar a porta de destino para a qual o tráfego baseado
em UDP é destinado, bem como um campo de comprimento e um valor de soma de verificação que
garante a integridade do cabeçalho UDP . Além disso, a sobrecarga mínima atua como um meio ideal
para permitir que mais dados sejam transportados por pacote, favorecendo o tráfego em tempo real,
como comunicações de voz e vídeo, em que o TCP fornece uma sobrecarga de 20 bytes e mecanismos
que influenciam atrasos, como no caso de confirmações , no entanto, a falta de tais campos significa que
a entrega de datagramas não é garantida.

Comportamento de Encaminhamento UDP

Como a transmissão de datagrama UDP não é enviada como um fluxo de dados, a transmissão de
dados é suscetível à duplicação de datagramas. Além disso, a falta de números de sequência dentro do
UDP significa que a entrega de transmissão de dados por vários caminhos provavelmente será recebida
no destino em uma ordem incorreta e não seqüenciada.
 Quando dados de fluxo são transportados por UDP, como no caso de aplicativos de voz e vídeo,
mecanismos adicionais de protocolo podem ser aplicados para aprimorar a capacidade do UDP, como
no caso do protocolo de transporte em tempo real (RTP) que ajuda a suportar a incapacidade do UDP,
fornecendo um mecanismo de sequenciamento usando registros de data e hora para manter a ordem
de tais fluxos de dados de áudio / vídeo, suportando efetivamente o comportamento orientado à
conexão parcial sobre um protocolo de transporte sem conexão.

Comportamento de Encaminhamento UDP

O comportamento geral de encaminhamento de UDP é altamente benéfico para atrasar o tráfego

sensível, como voz e vídeo. Deve ser entendido que, quando se trata de um protocolo de transporte
orientado para conexão, os dados perdidos exigiriam replicação após um período de atraso, durante o
qual é esperada uma confirmação pelo remetente. Caso o reconhecimento não seja recebido, os dados
devem ser retransmitidos.
Para fluxos de dados sensíveis a atrasos, isso resultaria em transmissões de áudio e vídeo
incompreensíveis devido a atraso e duplicação, como resultado da retransmissão do ponto em que os
reconhecimentos são gerados. Nesses casos, a perda mínima do fluxo de dados é preferível à
retransmissão e, como tal, o UDP é selecionado como o mecanismo de transporte, em suporte ao
tráfego sensível a atrasos.

Resumo
1-Qual é o objetivo do campo de confirmação no cabeçalho TCP?
O campo de confirmação no cabeçalho TCP confirma o recebimento do segmento recebido pelo
processo TCP no destino. O número de seqüência no cabeçalho TCP do datagrama IP recebido é obtido e
incrementado por 1. Esse valor se torna o número de confirmação no cabeçalho TCP retornado e é
usado para confirmar o recebimento de todos os dados, antes de ser encaminhado junto com o
conjunto de bits do código ACK para 1, para o remetente original.

2-Quais bits de código TCP estão envolvidos em um handshake de três vias TCP?
O handshake de três vias envolve bits de código SYN e ACK para estabelecer e confirmar a conexão
entre os dois sistemas finais, entre os quais a transmissão de datagramas ocorrerá.
 Prefácio
O conjunto de protocolos TCP / IP opera como uma coleção de regras para suportar o
encaminhamento de dados de ponta a ponta, junto com protocolos de camada inferior,
como aqueles definidos nos padrões IEEE 802. O conhecimento do ciclo de vida do
encaminhamento de dados permite uma compreensão mais profunda do
comportamento da rede IP para uma análise eficaz da operação da rede e a solução de
problemas de falhas de rede. Todo o processo de encapsulamento e decapsulação
representa, portanto, uma parte fundamental de todo o conhecimento do TCP / IP.

Objectivos
Após a conclusão desta seção, os formandos serão capazes de:
 Explicar as etapas do processo para encapsulamento de dados e decapsulation.
 Solucione problemas básicos de encaminhamento de dados.
 Introdução ao cenário

O encaminhamento de dados pode ser definido coletivamente como local ou remoto para o qual o
processo de encaminhamento depende da aplicação da pilha de protocolos para obter transmissão de
ponta a ponta. Os sistemas finais podem fazer parte da mesma rede ou estar localizados em redes
diferentes, no entanto, o princípio geral de encaminhamento para permitir a transmissão entre hosts
segue um conjunto claro de protocolos que foram introduzidos como parte da unidade. O modo como
estes protocolos funcionam em conjunto deve ser reforçado, bem como a construção da relação entre
os protocolos TCP / IP de camada superior e os padrões de protocolo Ethernet baseados na camada de
ligação inferior.

Descoberta de caminho

Um sistema final que pretende encaminhar dados para um determinado destino deve determinar
inicialmente se é possível ou não alcançar o destino pretendido. Para conseguir isso, o sistema final deve
passar por um processo de descoberta de caminhos. Um sistema final deve ser entendido como capaz
de suportar a operação em todas as camadas, uma vez que sua função primária é como um host para
aplicativos. Em relação a isso, ele também deve ser capaz de suportar operações de camada inferior,
como roteamento e encaminhamento de camada de enlace (switching), a fim de ser capaz de
encaminhamento de dados de camada superior / aplicação. O sistema final, portanto, contém uma
tabela que representa a acessibilidade da camada de rede para a rede para a qual os dados da camada
superior são destinados.
 Os sistemas finais geralmente estarão cientes da rede em que residem, mas podem estar sem um
caminho de encaminhamento nos casos em que a descoberta de rede remota não tenha sido alcançada.
No exemplo dado, o host A possui um caminho para a rede destinada através do endereço 'any network'
que foi brevemente introduzido como parte da seção de endereçamento IP. A tabela de
encaminhamento identifica que o tráfego deve ser encaminhado para o gateway como um próximo
salto através da interface associada ao endereço lógico de 10.1.1.1.

ARP

Após a descoberta de uma rota viável em direção à rede de destino pretendida, um próximo salto
físico também deve ser descoberto para facilitar o encaminhamento de quadros. O conjunto de
protocolos TCP / IP é responsável por determinar isso antes que o encapsulamento de pacotes possa
continuar. A etapa inicial envolve determinar se existe um caminho físico para o próximo salto
identificado como parte do processo de descoberta de caminho.
Isso requer que a tabela de cache ARP seja consultada para identificar se uma associação entre o
próximo salto pretendido e o caminho físico é conhecida. A partir do exemplo, pode-se ver que uma
entrada para o endereço de gateway do próximo salto está presente na tabela de cache do ARP. Onde
uma entrada não pode ser encontrada, o protocolo de resolução de endereços (ARP) deve ser iniciado
para executar a descoberta e resolver o caminho físico.

Encapsulamento TCP
 Quando a descoberta de encaminhamento de caminho lógico e físico estiver concluída, é possível
que o encapsulamento de dados seja executado para uma transmissão bem-sucedida em redes
baseadas em IP / Ethernet. Os processos da camada superior em termos de criptografia e compactação
podem ser executados após o encapsulamento da camada de transporte, identificando as portas de
origem e destino pelas quais os dados da camada superior devem ser encaminhados.
No caso do TCP, os campos de seqüência e reconhecimento serão preenchidos, os bits de código
definidos conforme necessário com o bit ACK normalmente aplicado. O campo da janela será
preenchido com o tamanho atual da janela suportada, para o qual o host notificará o buffer de dados
máximo que pode ser suportado antes que os dados sejam reconhecidos.
Os valores que representam os campos TCP são incluídos como parte da soma de verificação, que é
calculada usando um processo de cálculo de elogios, para garantir que a integridade do segmento TCP
seja mantida quando o cabeçalho TCP for recebido e processado no destino final. No caso de operações
básicas de código TCP, os dados da camada superior nem sempre podem ser transportados no
segmento, como no caso de sincronização de conexão e confirmações para dados recebidos.

Encapsulamento IP

Após o encapsulamento da camada de transporte, geralmente é necessário que as instruções sejam

fornecidas, detalhando como a transmissão em uma ou mais redes deve ser alcançada. Isso envolve
listar a fonte de IP, bem como o destino final para o qual o pacote é destinado. Os pacotes IP são
geralmente limitados a um tamanho de 1500 bytes por Ethernet, incluindo os cabeçalhos da camada de
rede e transporte, bem como quaisquer dados da camada superior. O tamanho inicial do pacote será
determinado pela Ethernet como a unidade máxima de transmissão, ou MTU, à qual os pacotes estarão
em conformidade, portanto, a fragmentação não ocorrerá na origem.
No caso em que a MTU muda ao longo do caminho de encaminhamento, somente então a
fragmentação será executada. O campo Tempo de vida será preenchido com um valor definido,
dependendo do sistema, nos roteadores da série ARG3, isso é definido com um valor inicial de 255. O
campo de protocolo é preenchido com base no protocolo encapsulado antes do IP. Nesse caso, o
protocolo em questão é o TCP para o qual o cabeçalho IP preencherá o campo de protocolo com um
valor de 0x06 como instrução para o próximo processamento de cabeçalho. O endereçamento IP de
origem e destino refletirá a origem e o destino final.

Enquadramento Ethernet

O encapsulamento da camada de enlace baseia-se nos padrões Ethernet IEEE 802.3 para transmissão
física de dados de camada superior em redes Ethernet. O encapsulamento nas camadas inferiores é
realizado determinando inicialmente o tipo de quadro que é usado.
Onde o protocolo da camada superior é representado por um valor de tipo maior que 1536 (0x0600)
como é o caso com IP (0x0800), o tipo de quadro Ethernet II é adotado. O campo de tipo do cabeçalho
do quadro Ethernet II é preenchido com o valor do tipo 0x0800 para refletir que o próximo protocolo a
ser processado após o processamento do quadro será IP. O endereço MAC de destino determina o
próximo salto físico, que neste caso representa o gateway de rede.

Encaminhamento de quadros

Como parte da operação da camada de enlace, é imperativo garantir que o meio de transmissão
esteja livre de sinais no domínio de colisão compartilhado. O host primeiro ouvirá qualquer tráfego na
rede como parte do CSMA / CD e, se a linha permanecer limpa, se preparará para transmitir os dados. É
necessário que a interface física de recebimento seja informada do quadro de entrada, de modo a evitar
perda de valores de bit iniciais que tornariam os quadros iniciais incompletos. Os quadros são, portanto,
precedidos por um valor de 64 bits que indica o destino da camada de enlace da chegada iminente do
quadro.
Os 56 bits iniciais representam um padrão alternado de 1, 0 chamado de preâmbulo e são seguidos
imediatamente por um octeto entendido como o Delimitador de Início do Frame (SFD). Os dois bits
finais do SFD se desviam de um padrão alternado para uma combinação de 1,1 bits que notifica que os
bits que seguem representam os primeiros valores de bit do endereço MAC de destino e, portanto, o
início do cabeçalho do quadro.
 Processamento de quadros

Como um quadro é recebido pelo destino da camada de enlace, ele deve passar por várias
verificações para determinar sua integridade e validade. Se o quadro foi transmitido através de uma
rede Ethernet compartilhada, outras estações finais também podem receber uma instância do quadro
transmitido; entretanto, como o endereço MAC de destino do quadro é diferente do endereço MAC da
estação final, o quadro será descartado.
Os quadros recebidos no destino pretendido executarão a verificação de erros calculando os valores
de elogio com base nos campos de quadros atuais e comparando-os com o valor no campo FCS (Frame
Check Sequence). Se os valores não corresponderem, o quadro será descartado. O recebimento de
sistemas intermediários e finais que recebem quadros válidos precisará determinar se o quadro é
destinado à sua interface física comparando o endereço MAC de destino com o endereço MAC da
interface (ou dispositivo em alguns casos).
Se houver uma correspondência, o quadro será processado e o campo de tipo será usado para
determinar o próximo cabeçalho a ser processado. Depois que o próximo cabeçalho é determinado, o
cabeçalho e o trailer do quadro são descartados.

Processamento de Pacotes

O pacote é recebido pela camada de rede e, em particular, por IP, ponto no qual o cabeçalho IP é
processado. Existe um valor de soma de verificação em cada camada da pilha de protocolos para manter
a integridade em todas as camadas para todos os protocolos. O IP de destino é usado para determinar
se o pacote atingiu seu destino final. No entanto, o gateway determina que esse não é o caso, pois o IP
de destino e o IP pertencente ao gateway não correspondem.
 O gateway deve, portanto, determinar o curso de ação a ser tomado com relação ao roteamento do
pacote para uma interface alternativa e encaminhar o pacote para a rede para a qual ele é destinado. O
gateway deve, em primeiro lugar, garantir que o valor TTL não tenha atingido 0 e que o tamanho do
pacote não exceda o valor máximo da unidade de transmissão para o gateway. No caso de o pacote ser
maior que o valor MTU do gateway, a fragmentação geralmente será iniciada.
Uma vez localizado o destino de um pacote na tabela de encaminhamento do gateway, o pacote será
encapsulado em um novo cabeçalho de quadro que consiste em novos endereços MAC de origem e
destino para o segmento da camada de link, sobre os quais o quadro resultante será encaminhado.
sendo mais uma vez transmitido para o próximo salto físico. Quando o próximo salto físico não for
conhecido, o ARP será novamente usado para resolver o endereço MAC.

Decapsulação de quadros

Os quadros recebidos no destino final determinarão inicialmente se o quadro chegou ao local

pretendido. O exemplo mostra dois servidores em uma rede Ethernet compartilhada sobre os quais
ambos recebem uma cópia do quadro.
O quadro é finalmente descartado pelo servidor B, pois o valor MAC de destino e o endereço MAC da
interface do servidor B não coincidem. No entanto, o Servidor A recebe com êxito o quadro e aprende
que os campos MAC são os mesmos, a integridade do quadro com base no FCS também pode ser
entendida como correta. O quadro usará o campo type para identificar 0x0800 como o próximo
cabeçalho, após o qual o cabeçalho e o trailer do quadro são descartados e o pacote é recebido pelo IP.

Decapsulação de Pacotes
 Ao atingir o destino final, o cabeçalho do pacote IP deve facilitar vários processos. O primeiro inclui
validar a integridade do cabeçalho do pacote através do campo de soma de verificação, aplicando
novamente uma comparação de valor de complemento com base em uma soma dos campos de
cabeçalho IP. Onde estiver correto, o cabeçalho IP será usado para determinar se o IP de destino
corresponde ao endereço IP da estação final atual, o que neste caso é verdadeiro.
Se alguma fragmentação ocorreu durante a transmissão entre a origem e o destino, o pacote deve
ser remontado neste momento. O campo de identificação coletará os fragmentos pertencentes a uma
única fonte de dados juntos, o deslocamento determinará a ordem e o campo flags especificará quando
a remontagem deverá começar, uma vez que todos os fragmentos devem ser recebidos primeiro e um
fragmento com um sinalizador 0 será reconhecido como o último fragmento a ser recebido.
Um temporizador irá então prosseguir durante o qual a remontagem deve ser completada, caso a
remontagem falhe neste período de tempo, todos os fragmentos serão descartados. O campo de
protocolo será usado para identificar o próximo cabeçalho para processamento e o cabeçalho do pacote
será descartado. Deve-se notar que o próximo cabeçalho nem sempre pode ser um cabeçalho de
camada de transporte, um exemplo claro de onde isso pode ser entendido é no caso de ICMP, que é
entendido como também um protocolo de camada de rede com um valor de campo de protocolo 0x01 .

Decapsulação do Segmento

No caso em que um cabeçalho de pacote é descartado, o segmento ou datagrama resultante é

passado para a camada de transporte para o processamento baseado em aplicativo para aplicativo. A
informação do cabeçalho é recebida neste caso por TCP (0x06).
No exemplo, pode ser entendido que uma conexão TCP já foi estabelecida e o segmento representa
uma confirmação para a transmissão do tráfego HTTP do servidor HTTP para o host de reconhecimento.
O host é representado pela porta 1027 como um meio de distinguir entre várias conexões HTTP que
podem existir entre o mesmo host de origem e o servidor de destino. Ao receber essa confirmação, o
servidor HTTP continuará encaminhando para o host dentro dos limites do tamanho da janela do host.
 Resumo
1-Quais informações são necessárias antes que os dados possam ser encapsulados?
Antes do encapsulamento e encaminhamento de dados, uma fonte deve ter conhecimento do
destino IP ou de um endereço de encaminhamento equivalente, como um endereço padrão para o qual
os dados podem ser encaminhados. Além disso, é necessário que o endereço de encaminhamento seja
associado a um próximo salto físico para o qual os dados possam ser encaminhados dentro da rede
local.
2-O que acontece quando um quadro é encaminhado para um destino para o qual não é destinado?
Qualquer quadro que é recebido por um gateway ou sistema final (host) para o qual não é destinado,
é descartado posteriormente, após a inspeção do endereço MAC de destino no cabeçalho do quadro.
3-Como os dados no quadro finalmente atingem o aplicativo para o qual são destinados?
A entrega de dados depende do número da porta de destino nos cabeçalhos TCP e UDP para
identificar o aplicativo para o qual os dados são destinados. Após a análise desse valor pelo protocolo
TCP ou UDP, os dados são encaminhados.
4-Quando várias sessões do mesmo aplicativo estão ativas (por exemplo, vários navegadores da
Web), como os dados de retorno alcançam a sessão correta?
A porta de origem do cabeçalho TCP para o tráfego HTTP distingue entre as diferentes sessões do
aplicativo que estão ativas. O retorno do tráfego HTTP do servidor HTTP é capaz de identificar cada
sessão individual do navegador da Web com base nesse número de porta de origem. Por exemplo, a
porta de origem de duas solicitações separadas de tráfego HTTP originadas da origem de IP 10.1.1.1
pode ter origem nas portas de origem 1028 e 1035, no entanto, a porta de destino em ambos os casos
permanece como porta 80, o servidor HTTP.
 Prefácio

À medida que mais e mais estações finais na forma de dispositivos host, impressoras
conectáveis a rede, outros produtos similares são introduzidos na rede local, um
aumento na densidade de dispositivos resulta em uma limitação em termos de interfaces
de porta, juntamente com problemas de colisões em qualquer topologia de rede
compartilhada. A mudança evoluiu como o meio para apoiar esse crescimento. O VRP é
usado nos produtos da Huawei como um meio de configurar e operar esses dispositivos
gerenciados para os quais a familiaridade e as habilidades práticas devem ser
desenvolvidas.

Objectivos
Após a conclusão desta seção, os formandos poderão:
 Explicar o papel que os Switches desempenham nas redes Ethernet.
 Descrever a diferença entre domínios de colisão e broadcast.
 Explicar o funcionamento geral da VRP nos produtos da Huawei.
 Aplicação de dispositivos de comutação (Switches)

A rede Ethernet até agora foi entendida como uma coleção de dispositivos que se comunicam através
de mídia compartilhada, como o 10Base2, através da qual os hosts podem se comunicar com hosts
vizinhos ou sistemas finais. Foi determinado que a rede Ethernet é uma rede contenciosa, o que significa
que os hosts devem competir por acesso à mídia, o que se torna cada vez mais limitado à medida que
mais e mais dispositivos são conectados através dessa mídia compartilhada; o que causa limitações
adicionais na escalabilidade e o potencial crescente de colisões.
Como resultado, a necessidade de detecção de colisão na forma de CSMA / CD está sempre presente
em tais redes Ethernet compartilhadas. Após a adoção de mídia comutada, como a de 100BaseT, a
transmissão e a recepção de dados ficaram isoladas dentro dos canais (pares de fios), permitindo que o
potencial de colisão ocorra e seja eliminado. Esse meio como uma forma de Ethernet não compartilhada
fornece apenas um meio de comunicação ponto-a-ponto, no entanto, usado em conjunto com outros
dispositivos, como hubs, uma rede Ethernet compartilhada é mais uma vez possível, juntamente com o
potencial de colisões.
O switch foi introduzido como parte da evolução da ponte e é capaz de dividir o domínio de colisão
compartilhado em vários domínios de colisão. Os domínios de colisão operam como uma coleção de
links ponto-a-ponto para os quais a ameaça de colisões é removida e o tráfego da camada de enlace é
isolado, para permitir taxas de transmissão mais altas que otimizam o fluxo de tráfego na rede Ethernet.
 Aplicação de Dispositivos de Roteamento (Roteadores)

Um domínio de broadcast é capaz de ser constituído por um único, ou múltiplos domínios de colisão,
e qualquer transmissão de broadcast está contida dentro do limite de um domínio de difusão. A borda
do limite de um domínio de broadcast é tipicamente definida por um gateway que atua como o meio,
através do qual outras redes são alcançáveis, e restringirá o encaminhamento de qualquer tráfego de
broadcast além da interface na qual a transmissão é recebida.
Roteadores são sinônimos do termo gateway para o qual os dois são freqüentemente usados de
forma intercambiável. Uma rede IP única geralmente pode ser entendida como um domínio de
broadcast, que se refere ao escopo de um segmento da camada de enlace. Em geral, os roteadores são
responsáveis pelo roteamento de datagramas da Internet (pacotes IP) para um determinado destino
com base no conhecimento de um endereço de encaminhamento da rede de destino, encontrado em
uma tabela de encaminhamento gerenciada internamente.

Introdução ao VRP

A plataforma de roteamento versátil (VRP) representa a base de muitos produtos da Huawei,

incluindo roteadores e switches. Seu design passou por muitas evoluções para permitir a melhoria
contínua do gerenciamento e encaminhamento de dados. O projeto arquitetônico resultou em
modularidade cada vez maior que permite um maior desempenho geral. A configuração, o
gerenciamento e o monitoramento de dispositivos usando o VRP são baseados em um sistema de linha
de comando padronizado e hierárquico, para o qual uma familiaridade deve ser desenvolvida para
suportar a navegação e a operação de produtos Huawei gerenciados usando o software VRP.

Linha do Tempo VRP

A familiaridade com as versões do sistema operacional de rede (NOS) da VRP ajuda a garantir que a
versão atualmente em uso esteja atualizada e ofereça suporte a determinados recursos que podem ser
necessários em uma rede corporativa. A tendência geral para a maioria dos dispositivos Huawei é operar
usando a versão 5.x do VRP atualmente, onde x pode variar dependendo do produto e da versão do
VRP. A versão 8 da VRP é uma revisão recente da VRP construída com uma arquitetura altamente
refinada para a próxima geração de tecnologias e construída em torno da necessidade de maior
eficiência, mas não está presente em todos os produtos da Huawei.

Estabelecendo Conectividade

Os roteadores corporativos da série AR (AR) incluem o AR150, AR200, AR1200, AR2200 e AR3200.
Eles são a próxima geração de produtos Huawei e oferecem funcionalidade de roteamento, comutação,
sem fio, voz e segurança. As séries AR estão posicionadas entre a rede corporativa e uma rede pública,
funcionando como um gateway de entrada e saída para dados transmitidos entre as duas redes. A
implantação de vários serviços de rede sobre os roteadores da série AR reduz os custos de operação e
manutenção (O & M), bem como os custos associados ao estabelecimento de uma rede corporativa. Os
roteadores da série AR de diferentes especificações podem ser usados como gateways com base na
capacidade do usuário de uma empresa.
O Switch Ethernet da Série Sx7 oferece funcionalidade de transporte de dados e foi desenvolvido pela
Huawei para atender aos requisitos de acesso confiável e transmissão de alta qualidade de múltiplos
serviços na rede da empresa. Essa série de switches está posicionada para a operação de acesso ou de
camada de agregação na rede corporativa e fornece uma grande capacidade de comutação, alta
densidade de portas e recursos de encaminhamento de pacotes econômicos.
O gerenciamento dos roteadores da série ARG3 e da série Sx7 de switches pode ser alcançado
através do estabelecimento de uma conexão com a interface do console e, no caso do AR2200, também
é possível estabelecer uma conexão através de uma interface Mini USB.

Acesso ao dispositivo via console

Um cabo de console é usado para depurar ou manter um dispositivo estabelecido localmente, como
um roteador ou um comutador, e fará a interface com a porta do console de tais dispositivos. A
interface do console do switch da série S5700 e do roteador AR2200 é uma conexão do tipo RJ-45,
enquanto a interface na qual uma conexão de host é feita, representa uma forma RS-232 do conector
serial. Frequentemente, esses conectores seriais não estão mais presentes em dispositivos mais
recentes que podem ser usados para estabelecer conectividade, como laptops e, portanto, uma
conversão de RS-232 para USB é executada. Para a maioria dos dispositivos de desktop, no entanto, uma
conexão de console baseada em RS-232 pode ser estabelecida para uma porta COM no dispositivo host.

Procedimentos de configuração de acesso ao console

 O estabelecimento do console é configurado por meio de um dos vários programas de emulação de
terminal disponíveis. Os usuários do Windows geralmente aplicam o aplicativo HyperTerminal,
conforme mostrado no exemplo, para interagir com o sistema operacional VRP. Após a especificação da
porta COM que deve ser usada para estabelecer a conexão, as configurações de porta devem ser
definidas.
O exemplo define as configurações de porta que devem ser aplicadas, para as quais o botão padrão
de restauração será reatribuído automaticamente caso alguma alteração tenha sido feita nessas
configurações. Uma vez que o botão OK é pressionado, uma sessão será estabelecida com o VRP do
dispositivo. Se o dispositivo estiver operando usando as configurações padrão de fábrica, o usuário será
solicitado a fornecer uma senha, que será designada como a senha de login padrão para futuras
tentativas de conexão.

Acesso ao roteador via mini USB

O roteador Huawei AR2200, suporta adicionalmente os meios para conectividade de terminal através
de uma conexão USB. Existe uma interface mini USB tipo B no painel frontal do roteador da série
AR2200, através da qual os hosts podem estabelecer uma conexão baseada em USB como uma
alternativa serial à da RS-232.

Instalação do Mini Driver USB

 Uma pequena variação no processo de configuração requer que o mini USB estabeleça drivers para
permitir a funcionalidade USB.
O mini driver USB pode ser obtido em http://support.huawei.com/enterprise e sob o caminho
Support> Software> Enterprise Networking> Roteador> Access Router> AR> AR2200, escolha a opção
relevante de versão e patch do VRP e baixe o arquivo rotulado AR & SRG_MiniUSB_driver.zip. Deve-se
notar que o mini-driver USB suporta apenas os sistemas operacionais Windows XP, Windows Vista e
Windows 7.
Ao atualizar o software do dispositivo ou instalar um patch, o valor do hash MD5 pode ser verificado
para confirmar a validade do software. Para evitar que o software seja modificado ou substituído, é
recomendável que você realize essa operação.
A instalação requer que o usuário primeiro clique duas vezes no arquivo de instalação do driver no PC
e clique em Avançar. Em segundo lugar, selecione Aceito os termos do contrato de licença e clique em
Avançar. Clique no botão Alterar para alterar o diretório do driver, se necessário, e clique em Avançar.
Clique em Instalar e descompacte o driver. Quando o sistema concluir a descompactação do driver,
clique em Concluir.
Os usuários devem encontrar a pasta DISK1 no diretório do driver especificado e clicar duas vezes no
arquivo setup.exe. Após a abertura de uma segunda janela de instalação, clique em Avançar. Os usuários
devem selecionar novamente Eu aceito os termos do contrato de licença e clique em Avançar para
instalar o driver. Depois de concluído, clique em Concluir para concluir a instalação do driver. Clique com
o botão direito em Meu Computador e escolha Gerenciar> Gerenciador de Dispositivos> Portas (COM &
LPT). O sistema deve exibir o dispositivo TUSB3410 indicando o driver que foi instalado.

Procedimentos de Configuração de Acesso Mini USB

Assim como na conexão do console RS-232, a conexão serial Mini USB requer o estabelecimento de
um software de emulação de terminal para permitir a interação com a linha de comando do VRP.
 Use o software de emulação de terminal para efetuar login no dispositivo através da porta mini USB
(para a qual o HyperTerminal do Windows é usado como exemplo). No PC host, inicie o aplicativo
HyperTerminal, para o qual o local pode variar para cada versão do Windows, e crie uma conexão
fornecendo um nome de conexão de terminal adequado e clique em OK. Selecione a porta de conexão
relevante (COM) e defina os parâmetros de comunicação para a porta serial do PC. Esses parâmetros
devem corresponder aos valores padrão definidos ao pressionar o botão Restaurar padrões.
Depois de pressionar Enter, as informações do console são exibidas solicitando uma senha de login.
Digite uma senha e uma senha de confirmação relevantes e o sistema salvará a senha.

Resumo

1-Se uma transmissão Ethernet ocorrer, como no caso do ARP, para o qual o destino é local, qual será
a resposta do gateway?
Qualquer transmissão gerada por um sistema final dentro de uma rede local será encaminhada para
todos os destinos. Depois que um quadro é transmitido para um roteador ou dispositivo que atua como
um gateway para a rede, o quadro será analisado e, caso seja determinado que o destino é para um host
definido localmente diferente do gateway, o quadro será eliminado. Isso, como tal, define o limite de
qualquer domínio de broadcast.
2-Quais versões do VRP são atualmente suportadas pelos produtos Huawei?
A versão 5 da VRP é suportada por um grande número de produtos atuais da Huawei, enquanto os
produtos de ponta podem ser suportados pela versão 8 da VRP.
 Prefácio
A implementação de uma técnica de interface gráfica requer um nível de
conhecimento e capacidade na interface da linha de comando do VRP e na configuração
das configurações do sistema. A principal arquitetura de linha de comando é, portanto,
introduzida como parte desta seção, juntamente com a navegação, funções de ajuda e
configurações comuns do sistema devem ser entendidas para uma configuração bem-
sucedida de qualquer outro dispositivo gerenciado por VRP.

Objetivos

Após a conclusão desta seção, os formandos serão capazes de:

 Navegar pela interface de linha de comando do VRP.
 Configurar configurações básicas do sistema VRP.
 Executar a configuração e o gerenciamento básicos da interface do VRP.
 Iniciando um dispositivo

O processo de inicialização é a fase inicial de operação para qualquer administrador ou engenheiro

que acesse produtos baseados na Huawei que operam com VRP. A tela de inicialização informa sobre os
procedimentos de operação de inicialização do sistema, bem como a versão da imagem VRP atualmente
implementada no dispositivo, junto com o local de armazenamento de onde ela está carregada. Após o
procedimento de inicialização inicial, uma opção para configuração automática das configurações
iniciais do sistema solicita uma resposta, para a qual o administrador pode optar por seguir as etapas de
configuração ou configurar manualmente os parâmetros básicos do sistema. O processo de configuração
automática pode ser finalizado selecionando a opção yes no prompt fornecido.

Visualizações de linha de comando da CLI

 A estrutura de comando hierárquico do VRP define várias visualizações de comando que controlam
os comandos para os quais os usuários podem executar operações. A interface da linha de comandos
possui várias visualizações de comandos, das quais exibições comuns foram introduzidas no exemplo.
Cada comando é registrado para ser executado em uma ou mais visualizações de comandos, e tais
comandos podem ser executados somente após a inserção da visualização de comando apropriada. A
visualização de comando inicial da VRP é a Visualização do Usuário, que opera como uma visualização de
comando de observação para observar os status dos parâmetros e informações estatísticas gerais. Para
a aplicação de alterações nos parâmetros do sistema, os usuários devem entrar na Visualização do
sistema. Vários níveis de subcomando também podem ser encontrados, na forma de visualizações de
interface e protocolo, por exemplo, em que tarefas no nível do sub sistema podem ser executadas.
As exibições da linha de comando podem ser determinadas com base nos parênteses e nas
informações contidas nesses parênteses. A presença de divisas identifica que o usuário está atualmente
na Visualização do Usuário, enquanto os colchetes mostram que ocorreu uma transição para a
Visualização do Sistema.

Funções CLI

O exemplo demonstra uma seleção de teclas de atalho comuns definidas pelo sistema que são
amplamente usadas para simplificar o processo de navegação dentro da interface de linha de comando
do VRP. Comandos adicionais são os seguintes:
CTRL + B move o cursor de volta um caractere.
CTRL + D exclui o caractere onde o cursor está localizado.
CTRL + E move o cursor para o final da linha atual.
CTRL + F move o cursor para frente um caractere.
CTRL + H exclui o caractere no lado esquerdo do cursor.
CTRL + N exibe o próximo comando no buffer de comando histórico.
 CTRL + P exibe o comando anterior no buffer de comando histórico.
CTRL + W exclui a palavra no lado esquerdo do cursor.
CTRL + X exclui todos os caracteres no lado esquerdo do cursor.
CTRL + Y exclui todos os caracteres no lado direito do cursor.
ESC + B move o cursor uma palavra de volta.
ESC + D apaga a palavra no lado direito do cursor.
ESC + F move o cursor para frente uma palavra.

Funções de tecla adicionais podem ser usadas para executar operações similares, a operação de
backspace tem o mesmo comportamento que usar CTRL + H para excluir um caractere à esquerda do
cursor. As teclas de cursor à esquerda (←) e à direita (→) podem ser usadas para executar a mesma
operação que as funções das teclas de atalho CTRL + B e CTRL + F. A tecla do cursor para baixo (↓)
funciona da mesma maneira que Ctrl + N, e a tecla do cursor para cima (↑) atua como uma alternativa à
operação CTRL + P.
Além disso, as funções de linha de comando suportam um meio de preenchimento automático em
que uma palavra de comando é exclusiva. O exemplo demonstra como a interface da palavra de
comando pode ser concluída automaticamente pela conclusão parcial da palavra até um ponto em que
o comando é exclusivo, seguido pela tecla tab que fornecerá a conclusão automática da palavra de
comando. Onde a palavra de comando não é única, a função tab irá percorrer as opções de conclusão
possíveis cada vez que a tecla tab for pressionada.
 Recursos da Ajuda do CLI

Existem duas formas de recurso de ajuda que podem ser encontradas no VRP, estas vêm na forma de
ajuda parcial e funções de ajuda completas. Ao inserir uma sequência de caracteres seguida
diretamente por um ponto de interrogação (?), O VRP implementará a função de ajuda parcial para
exibir todos os comandos que começam com essa sequência de caracteres. Um exemplo disso é
demonstrado. No caso do recurso de ajuda completa, um ponto de interrogação (?) Pode ser colocado
na linha de comando em qualquer exibição para exibir todos os nomes de comandos possíveis,
juntamente com as descrições de todos os comandos pertencentes a essa visão. Além disso, o recurso
de ajuda completo oferece suporte à entrada de um comando seguido por um ponto de interrogação (?)
Separado por um espaço. Todas as palavras-chave associadas a esse comando, bem como descrições
simples, são exibidas.

Configuração básica do dispositivo CLI

Para a maioria das indústrias, é provável que existam vários dispositivos, cada um dos quais precisa
ser gerenciado. Como tal, uma das primeiras tarefas importantes do comissionamento do dispositivo
envolve a configuração de nomes de dispositivos para identificar exclusivamente cada dispositivo na
rede. O parâmetro de nome do sistema no roteador da série AR2200 é configurado como Huawei por
padrão, para a série S5720 do switch, o nome do sistema padrão é HUAWEI. A implementação do nome
do sistema entra em vigor imediatamente após a conclusão da configuração.

Configurações do relógio CLI

O relógio do sistema reflete o registro de data e hora do sistema e pode ser configurado para
obedecer às regras de qualquer região. O relógio do sistema deve estar configurado corretamente para
garantir a sincronização com outros dispositivos e é calculado usando a fórmula: Tempo Universal
Coordenado (UTC) + deslocamento do fuso horário + deslocamento do horário de verão. O comando
datetime do clock é usado para definir o clock do sistema seguindo a fórmula HH: MM: SS AAAA-MM-
DD. No entanto, deve-se observar que, se o fuso horário não foi configurado ou está definido como 0, a
data e a hora definidas são consideradas UTC, portanto, recomenda-se que o fuso horário do relógio
seja definido antes de configurar a hora e a data do sistema.
A configuração do fuso horário local é obtida usando o comando timezone do relógio e é
implementada com base no nome do fuso horário {add | menos} a fórmula de deslocamento, em que o
valor de adição indica que a hora do nome do fuso horário é igual à hora UTC mais o deslocamento de
tempo e menos indica que a hora do fuso horário é igual à hora UTC menos a compensação de tempo .
Determinadas regiões exigem que o horário de verão seja implementado para manter a sincronização
do relógio com qualquer alteração no fuso horário do relógio durante períodos específicos do ano. O
VRP é capaz de suportar recursos de horário de verão para datas e datas fixas que são determinadas
com base em um conjunto de regras predeterminadas. Por exemplo, o horário de verão no Reino Unido
ocorre no último domingo de março e no último domingo de outubro, portanto, as regras podem ser
aplicadas para garantir que as alterações ocorram com base nessas datas flutuantes.
 Mensagens do cabeçalho CLI

O comando de cabeçalho fornece um meio para exibir notificações durante a conexão a um

dispositivo. O cabeçalho de login indica um cabeçalho que é exibido quando a conexão do terminal é
ativada e o usuário está sendo autenticado pelo dispositivo. O cabeçalho do shell indica um cabeçalho
que é exibido quando a sessão é configurada, depois que o usuário efetua login no dispositivo. As
informações do cabeçalho podem ser aplicadas como uma cadeia de texto ou recuperadas de um
arquivo especificado. Onde uma cadeia de texto é usada, um caractere inicial e final deve ser definido
como um marcador para identificar a sequência de informações, onde, no exemplo, o “caractere define
a sequência de informações. A string representa um valor no intervalo de 1 a 2000 caracteres, incluindo
espaços. O comando de cabeçalho baseado em informações segue o formato do cabeçalho {login |
shell} texto de informação onde a informação representa a string de informação, incluindo marcadores
de início e fim.
No caso de um cabeçalho baseado em arquivo, o cabeçalho de formato {login | shell} file file-name é
aplicado, em que file-name representa o diretório e o arquivo a partir do qual a string de informações
pode ser recuperada.

Níveis de Comando CLI

 O sistema estrutura o acesso a funções de comando hierarquicamente para proteger a segurança do
sistema. O administrador do sistema define os níveis de acesso do usuário que concedem acesso de
usuários específicos a níveis de comando específicos. O nível de comando de um usuário é um valor que
varia de 0 a 3, enquanto o nível de acesso do usuário é um valor que varia de 0 a 15. O nível 0 define um
nível de acesso para acesso a comandos que executam ferramentas de diagnóstico de rede e
traceroute), bem como comandos como conexões de cliente telnet e selecionar comandos de exibição.
O nível de Monitoramento é definido em um nível de usuário de 1 para o qual os níveis de comando 0
e 1 podem ser aplicados, permitindo que a maioria dos comandos de exibição sejam usados, com
exceção dos comandos mostrando a configuração atual e salva. Um nível de usuário 2 representa o nível
de configuração para o qual os níveis de comando até 2 podem ser definidos, permitindo acesso a
comandos que configuram serviços de rede diretamente aos usuários, incluindo comandos de
roteamento e de camada de rede. O nível final é o nível de Gerenciamento, que representa um nível de
usuário de 3 a 15 e um nível de comando de até 3, permitindo o acesso a comandos que controlam as
operações básicas do sistema e fornecem suporte para serviços.
Esses comandos incluem sistema de arquivos, FTP, TFTP, alternância de arquivos de configuração,
controle da fonte de alimentação, controle da placa de backup, gerenciamento de usuários,
configuração de nível, configuração de parâmetros internos do sistema e comandos de depuração para
diagnóstico de falhas. O exemplo dado demonstra como um privilégio de comando pode ser alterado,
onde, nesse caso, o comando de salvamento encontrado na visualização do usuário requer um nível de
comando 3 antes que o comando possa ser usado.

Interfaces do usuário CLI

 Cada interface do usuário é representada por uma visualização da interface do usuário ou uma
visualização da linha de comandos fornecida pelo sistema. A exibição da linha de comando é usada para
configurar e gerenciar todas as interfaces físicas e lógicas no modo assíncrono. Os usuários que
desejarem interagir com um dispositivo precisarão especificar determinados parâmetros para permitir
que uma interface de usuário se torne acessível. Duas formas comuns de interface de usuário
implementadas são a interface do console (CON) e a interface do terminal de teletipo virtual (VTY).
A porta do console é uma porta serial assíncrona fornecida pela placa de controle principal do
dispositivo e usa um número relativo de 0. VTY é uma linha de terminal lógica que permite que uma
conexão seja configurada quando um dispositivo usa serviços de telnet para conectar-se a um terminal
para acesso local ou remoto a um dispositivo. Um máximo de 15 usuários pode usar a interface de
usuário lógica VTY para efetuar login no dispositivo estendendo o intervalo de 0 a 4 obtido pela
aplicação do comando maximum-vty 15 da interface com o usuário. Se o número máximo de usuários
de login for 0, nenhum usuário poderá efetuar login no roteador por meio de telnet ou SSH. O comando
display user-interface pode ser usado para exibir informações relevantes sobre a interface do usuário.

Atributos do terminal CLI

Para as interfaces de terminal console e VTY, determinados atributos podem ser aplicados para
modificar o comportamento como um meio de estender recursos e melhorar a segurança. Um usuário
permite que uma conexão permaneça ociosa por um determinado período de tempo apresenta um
risco de segurança ao sistema. O sistema aguardará por um período de tempo limite antes de finalizar
automaticamente a conexão. Esse período de tempo limite inativo na interface do usuário é definido
como 10 minutos por padrão.
Onde for necessário aumentar ou reduzir o número de linhas exibidas na tela de um terminal ao usar
o comando de exibição, por exemplo, o comando de comprimento de tela pode ser aplicado. Isso, por
padrão, é definido como 24, mas pode ser aumentado para um máximo de 512 linhas. No entanto, um
comprimento de tela de 0 não é recomendado, pois nenhuma saída será exibida.
Para cada comando que é usado, um registro é armazenado no buffer de comando do histórico, que
pode ser recuperado através da navegação usando as funções das teclas (↑) ou CTRL + P e as teclas (↓)
ou Ctrl + N. O número de comandos gravados no buffer de comando do histórico pode ser aumentado
usando o comando history-command max-size para definir até 256 comandos armazenados. O número
de comandos armazenados por padrão é 10.

Permissões da interface CLI

O acesso a interfaces de terminal de usuário fornece um ponto de entrada claro para usuários não
autorizados acessarem um dispositivo e implementam alterações de configuração. Como tal, a
capacidade de restringir o acesso e limitar as ações que podem ser realizadas é necessária como meio
de segurança do dispositivo. A configuração do privilégio e autenticação do usuário são dois meios pelos
quais a segurança do terminal pode ser melhorada. O privilégio de usuário permite que um nível de
usuário seja definido, o que restringe a capacidade do usuário a um intervalo de comando específico. O
nível de usuário pode ser qualquer valor no intervalo de 0 a 15, em que os valores representam um nível
de visita (0), nível de monitoramento (1), nível de configuração (2) e nível de gerenciamento (3)
respetimente.
A autenticação restringe a capacidade do usuário de acessar uma interface de terminal, solicitando
que o usuário seja autenticado usando uma senha ou uma combinação de nome de usuário e senha
antes que o acesso pela interface do usuário seja concedido. No caso de conexões VTY, todos os
usuários devem ser autenticados antes que o acesso seja possível. Para todas as interfaces de usuário,
existem três modos de autenticação possíveis, na forma de AAA, autenticação de senha e não
autenticação. O AAA fornece autenticação de usuário com alta segurança para a qual um nome de
usuário e senha devem ser digitados para login. A autenticação de senha requer que apenas a senha de
login seja necessária, portanto, uma única senha pode ser aplicada a todos os usuários. O uso de não-
autenticação remove qualquer autenticação aplicada a uma interface de usuário. Deve-se notar que a
interface do console, por padrão, usa o modo de não autenticação.
Geralmente, recomenda-se que, para cada usuário que recebe acesso por telnet, o usuário seja
identificado por meio de nomes de usuário e senhas para permitir a distinção de usuários individuais.
Cada usuário também deve receber níveis de privilégio, com base na função e na responsabilidade de
cada usuário.

Configuração da interface CLI

Para executar serviços IP em uma interface, um endereço IP deve ser configurado para a interface.
Geralmente, uma interface precisa apenas do endereço IP principal. Em casos especiais, é possível que
um endereço IP secundário seja configurado para a interface. Por exemplo, quando uma interface de
um roteador, como o AR2200, se conecta a uma rede física, e os hosts dessa rede física pertencem a
dois segmentos de rede.
 Para permitir que o AR2200 se comunique com todos os hosts na rede física, configure um endereço
IP primário e um endereço IP secundário para a interface. A interface possui apenas um endereço IP
primário. Se um novo endereço IP primário for configurado em uma interface que já tenha um endereço
IP primário, o novo endereço IP substituirá o original. O endereço IP pode ser configurado para uma
interface usando o comando ip address <ip-address> {mask | mask-length} em que mask representa a
máscara de sub-rede de 32 bits, por ex. 255.255.255.0, e comprimento da máscara representa o valor
alternativo de comprimento da máscara, e. 24, ambos os quais podem ser usados de forma
intercambiável.
A interface de loopback representa uma interface lógica que é aplicada para representar uma rede ou
endereço de host IP e é frequentemente usada como uma forma de interface de gerenciamento no
suporte de vários protocolos através dos quais é feita comunicação ao endereço IP da interface de
loopback. ao contrário do endereço IP da interface física na qual os dados estão sendo recebidos.
 Resumo

1-Quantos usuários são capazes de se conectar através da interface do console a qualquer momento?
A interface do console é capaz de suportar apenas um único usuário a qualquer momento; isso é
representado pela exibição da interface de usuário do console 0.
2-Qual é o estado da interface de loopback 0 quando o comando loopback interface 0 é usado?
A interface de loopback representa uma interface lógica que não está presente em um roteador até
que seja criada. Uma vez criada, a interface de loopback é considerada ativa. Nos dispositivos ARG3, as
interfaces de loopback podem, no entanto, ser desligadas.
 Prefácio

O sistema de arquivos representa a plataforma subjacente na qual o VRP opera e onde

os arquivos do sistema são armazenados nos dispositivos de armazenamento físico do
produto. A capacidade de navegar e gerenciar esse sistema de arquivos é necessária para
garantir o gerenciamento eficaz dos arquivos de configuração, atualizações de software
do VRP e garantir que os dispositivos físicos contidos em cada produto sejam bem
mantidos.

Objetivos
Após a conclusão desta seção, os formandos serão capazes de:
 Navegar com sucesso pelo sistema de arquivos do dispositivo
 Manipular os arquivos e pastas do sistema de arquivos.
 Gerenciar o roteador Huawei e troque os dispositivos de armazenamento.
 Visualizando o sistema de arquivos

O sistema de arquivos gerencia arquivos e diretórios nos dispositivos de armazenamento. Ele pode
criar, excluir, modificar ou renomear um arquivo ou diretório ou exibir o conteúdo de um arquivo.
O sistema de arquivos tem duas funções: gerenciar dispositivos de armazenamento e gerenciar os
arquivos armazenados nesses dispositivos. Vários diretórios são definidos dentro dos quais os arquivos
são armazenados em uma hierarquia lógica. Esses arquivos e diretórios podem ser gerenciados por meio
de várias funções que permitem a alteração ou exibição de diretórios, exibindo arquivos nesses
diretórios ou subdiretórios e a criação ou exclusão de diretórios.
Exemplos comuns de comandos do sistema de arquivos para navegação geral incluem o comando cd
usado para alterar o diretório atual, pwd para visualizar o diretório atual e dir para exibir o conteúdo de
um diretório, conforme mostrado no exemplo. O acesso ao sistema de arquivos é obtido a partir da
Visualização do Usuário.
 Manipulando o sistema de arquivos

Fazer alterações nos diretórios do sistema de arquivos existente geralmente se refere à capacidade
de criar e excluir diretórios existentes no sistema de arquivos. Dois comandos comuns que são usados
neste caso. O comando de diretório mkdir é usado para criar uma pasta em um diretório especificado
em um dispositivo de armazenamento designado, em que directory se refere ao nome dado ao diretório
e para o qual o nome do diretório pode ser uma cadeia de 1 a 64 caracteres. Para excluir uma pasta
dentro do sistema de arquivos, o comando rmdir directory é usado, com o diretório novamente
referindo-se ao nome do diretório. Deve-se notar que um diretório só pode ser excluído se não houver
arquivos contidos nesse diretório.

Fazer alterações nos arquivos dentro de um sistema de arquivos inclui copiar, mover, renomear,
compactar, excluir, recuperar, excluir arquivos da lixeira, executar arquivos em lotes e configurar modos
de prompt. A criação de uma duplicada de um arquivo existente pode ser feita usando o comando copy
source-filename destination-filename, em que se o destino-nome do arquivo for o mesmo de um
arquivo existente (source-filename), o sistema exibirá uma mensagem indicando que o arquivo existente
será substituído. Um nome de arquivo de destino não pode ser o mesmo de um arquivo de inicialização,
caso contrário, o sistema exibirá uma mensagem indicando que a operação é inválida e que o arquivo é
um arquivo de inicialização.
O comando move source-filename destination-filename pode ser usado para mover arquivos para
outro diretório. Depois que o comando move for executado com sucesso, o arquivo original é cortado e
movido para o arquivo de destino definido. Deve-se notar, no entanto, que o comando move só pode
mover arquivos no mesmo dispositivo de armazenamento.

Para a remoção de arquivos dentro de um sistema de arquivos, a função delete pode ser aplicada
usando o comando delete [/ unreserved] [/ force] {filename | nome do dispositivo }. Geralmente
arquivos que são excluídos são direcionados para uma lixeira de onde os arquivos podem ser
recuperados usando a undelete {nomedoarquivo | device-name}, no entanto, se o comando /
unreserved for usado, o arquivo será permanentemente excluído. O sistema geralmente exibirá uma
mensagem solicitando a confirmação da exclusão do arquivo, no entanto, se o parâmetro / force estiver
incluído, nenhum aviso será dado. O parâmetro filename refere-se ao arquivo que deve ser excluído,
enquanto o parâmetro device-name define o local de armazenamento.
Quando um arquivo é direcionado para a lixeira, ele não é excluído permanentemente e pode ser
facilmente recuperado. Para garantir que tais arquivos na lixeira sejam excluídos permanentemente, o
comando reset recycle-bin [filename] pode ser aplicado, onde o parâmetro filename pode ser usado
para definir um arquivo específico para exclusão permanente.
 Sistema de gerenciamento de arquivos de configuração

Quando ligado, o dispositivo recupera os arquivos de configuração de um caminho de salvamento

padrão para inicializar a si mesmo, que é armazenado na RAM do dispositivo. Se os arquivos de
configuração não existirem no caminho de salvamento padrão, o roteador usa os parâmetros de
inicialização padrão.
O arquivo de configuração atual indica as configurações em vigor no dispositivo quando ele está
sendo executado. Quando a configuração é salva, a configuração atual é armazenada em um arquivo de
configuração salvo no local de armazenamento do dispositivo. Se o dispositivo carregou o arquivo de
configuração atual com base nos parâmetros de inicialização padrão, um arquivo de configuração salvo
não existirá no local de armazenamento do caminho de salvamento padrão, mas será gerado assim que
a configuração atual for salva.

Exibindo arquivos de configuração

Usando o comando display-configuration atual, os parâmetros do dispositivo que são efetivados

podem ser consultados. Se valores padrão de determinados parâmetros estiverem sendo usados, esses
parâmetros não serão exibidos. O comando de configuração atual inclui vários parâmetros que
permitem a filtragem da lista de comandos durante o uso da função de exibição. A configuração atual do
display | begin {regular-expressão} é um exemplo de como a configuração atual pode ser usada para
exibir parâmetros ativos que começam com uma palavra-chave ou expressão específica. Uma
alternativa para este comando é a configuração atual do display | include {regular-expressão} que
permite parâmetros que incluem uma palavra-chave ou expressão específica no arquivo de configuração
atual.
A exibição salva-configuração [última | time] mostra a saída do arquivo de configuração armazenado
usado na inicialização para gerar a configuração atual. Onde o último parâmetro é usado, exibe o
arquivo de configuração usado na inicialização atual. O arquivo de configuração é exibido apenas
quando está configurado para a inicialização atual. O parâmetro time exibirá a hora em que a
configuração foi salva pela última vez.

Salvando o Arquivo de Configuração

O uso do comando save [configuration-file] salvará as informações de configuração atuais em um

caminho de armazenamento padrão. O parâmetro do arquivo de configuração permite que as
informações de configuração atuais sejam salvas em um arquivo especificado. Executar o comando save
com o parâmetro configuration-file não afeta o arquivo de configuração de inicialização atual do
sistema. Quando o arquivo de configuração é o mesmo que o arquivo de configuração armazenado no
caminho de armazenamento padrão do sistema, a função desse comando é a mesma do comando de
salvamento.
O exemplo demonstra o uso do comando save para salvar a configuração atual, que por padrão será
armazenada no arquivo vrpcfg.zip padrão no local de armazenamento padrão do dispositivo.
 Exibindo os parâmetros de inicialização

O arquivo de configuração de salvamento usado atualmente pode ser descoberto através do uso do
comando de inicialização de exibição. Além disso, o comando de inicialização da tela pode ser usado
para consultar o nome do arquivo atual do software do sistema, o nome do próximo arquivo de
software do sistema, o nome do arquivo do software do sistema de backup, os nomes dos quatro
arquivos de software usados atualmente (se usados) e nomes dos próximos quatro arquivos de software
do sistema. Os quatro arquivos de software do sistema são o arquivo de configuração, o arquivo de voz,
o arquivo de patch e o arquivo de licença mencionados anteriormente.

Alterando os Parâmetros de Inicialização

Após a descoberta do arquivo de configuração salva da inicialização, pode ser necessário definir um
novo arquivo de configuração a ser carregado na próxima inicialização. Se um arquivo de configuração
específico não for especificado, o arquivo de configuração padrão será carregado na próxima
inicialização.
A extensão de nome de arquivo do arquivo de configuração deve ser .cfg ou .zip, e o arquivo deve ser
armazenado no diretório raiz de um dispositivo de armazenamento. Quando o roteador está ligado, ele
lê o arquivo de configuração da memória flash por padrão para inicializar. Os dados neste arquivo de
configuração são a configuração inicial. Se nenhum arquivo de configuração for salvo na memória flash,
o roteador usará os parâmetros padrão para iniciar.
Através do uso da startup saved-configuration [configuration-file] onde o parâmetro configuration-
file é o arquivo de configuração a ser utilizado na inicialização, é possível definir um novo arquivo de
configuração para inicializar na próxima inicialização do sistema.

Comparando Arquivos de Configuração

Quando o comando de configuração de comparação [arquivo de configuração] [número da linha de

operação número da linha de salvamento] for usado, o sistema executará uma comparação linha a linha
da configuração salva com a configuração atual, começando na primeira linha. Se os parâmetros número
da linha de salvamento da linha atual forem especificados, o sistema ignorará a configuração não
relevante antes das linhas comparadas e continuará a encontrar diferenças entre os arquivos de
configuração.
O sistema continuará a emitir as diferenças de configuração entre a configuração salva e os arquivos
de configuração atuais. A informação de saída de comparação é restrita a 150 caracteres por padrão. Se
a comparação exigir menos de 150 caracteres, todas as variações até o final de dois arquivos serão
exibidas.
 Limpar o arquivo de configuração

O comando reset saved-configuration é usado para excluir um arquivo de configuração de

inicialização do dispositivo do dispositivo de armazenamento. Quando executado, o sistema compara os
arquivos de configuração usados na inicialização atual e na próxima inicialização ao excluir o arquivo de
configuração do roteador.
Se os dois arquivos de configuração forem os mesmos, eles serão excluídos ao mesmo tempo após
esse comando ser executado. O arquivo de configuração padrão é usado quando o roteador é iniciado
na próxima vez. Se os dois arquivos de configuração forem diferentes, o arquivo de configuração usado
na inicialização atual será excluído depois que esse comando for executado.
Se nenhum arquivo de configuração estiver configurado para a inicialização atual do dispositivo, o
sistema exibirá uma mensagem indicando que o arquivo de configuração não existe depois que esse
comando é executado. Uma vez que o comando reset-saved-configuration seja usado, um prompt será
dado para confirmar a ação, para a qual o usuário deve confirmar, como mostrado no exemplo.

Tipos de dispositivos de armazenamento

Os dispositivos de armazenamento dependem do produto e incluem memória flash, cartões SD ou

unidades flash USB. O roteador AR2200E, por exemplo, possui uma memória flash interna e um cartão
SD integrado (no slot sd1). O roteador fornece dois slots USB reservados (usb0 e usb1) e um slot para
cartão SD (sd0). Para o S5700, ele inclui uma memória flash integrada com uma capacidade que varia
dependendo do modelo, com 64 MB suportados nos modelos S5700C-HI, S5700-LI, S5700S-LI e S5710-EI
e 32 MB para todos os outros. Os detalhes relacionados aos dispositivos de armazenamento de
produtos da Huawei podem ser detalhados usando o comando de versão de exibição, conforme
mostrado.

Apagando Dispositivos de Armazenamento

É provável que a formatação de um dispositivo de armazenamento resulte na perda de todos os

arquivos no dispositivo de armazenamento e os arquivos não possam ser restaurados; portanto, deve-se
ter muito cuidado ao executar qualquer comando de formatação e deve ser evitado, a menos que seja
absolutamente necessário. O comando format [storage-device] é usado junto com o parâmetro storage-
device para definir o local de armazenamento que deve ser formatado.

Reparando o dispositivo de armazenamento

Quando o dispositivo de terminal exibe que o sistema falhou, o comando fixdisk pode ser usado para
tentar consertar o sistema de arquivos anormal no dispositivo de armazenamento; no entanto, ele não
fornece nenhuma garantia de que o sistema de arquivos possa ser restaurado com êxito. Como o
comando é usado para corrigir problemas, se nenhum problema ocorreu no sistema, não é
recomendado que este comando seja executado. Também deve ser observado que esse comando não
corrige problemas no nível do dispositivo.
 Resumo
1-O que o d no atributo drwx do sistema de arquivos representa?
O atributo do sistema de arquivos d representa que a entrada é um diretório no sistema de arquivos.
Deve-se notar que este diretório só pode ser excluído depois que qualquer arquivo contido no diretório
tiver sido excluído. Os valores restantes do rwx referem-se ao fato de o diretório (ou arquivo) poder ser
lido, gravado e / ou executado.

2-Como um arquivo de configuração armazenado no sistema de arquivos de um dispositivo pode ser

implementado para uso pelo dispositivo?
Uma configuração pode ser salva em um nome separado do nome do arquivo padrão vrpcfg.zip e
armazenada no dispositivo de armazenamento do roteador ou switch. Se esse arquivo precisar ser
usado como o arquivo de configuração ativo no sistema, a configuração salva do comando
<configuration-file-name> deverá ser usada, onde o arquivo configuration-name se refere ao nome do
arquivo e à extensão do arquivo.
 Prefácio

A administração e o gerenciamento de rede eficazes em uma rede corporativa

dependem de todos os dispositivos que mantêm arquivos de backup no caso de falhas do
sistema ou outros eventos que podem resultar na perda de arquivos e dados importantes
do sistema. Os servidores remotos que usam o serviço FTP (File Transfer Protocol)
geralmente são usados para garantir que os arquivos sejam mantidos para fins de backup
e recuperação conforme e quando necessário. Os meios para estabelecer comunicação
com tais serviços de aplicação são introduzidos nesta seção.

Objectivos

Após a conclusão desta seção, os formandos serão capazes de:

 Explicar a importância de manter versões atualizadas do VRP.
 Estabelecer uma relação de cliente com um servidor FTP.
 Atualizar com sucesso uma imagem do sistema VRP.
 Atualizando a imagem do VRP

A plataforma VRP é constantemente atualizada para manter o alinhamento com as mudanças na

tecnologia e suportar novos avanços no hardware. A imagem VRP é geralmente definida por uma versão
VRP e um número de versão do produto. Os produtos das séries Huawei ARG3 e Sx7 geralmente se
alinham com a versão 5 do VRP à qual diferentes versões de produtos estão associadas.
À medida que a versão do produto aumenta, o mesmo acontece com os recursos que são suportados
pela versão. O formato da versão do produto inclui um código de produto Vxxx, Rxxx denota uma versão
principal e Cxx uma versão secundária. Se um service pack for usado para corrigir a versão do produto
VRP, um valor de SPC também poderá ser incluído no número de versão do produto VRP. Exemplos
típicos dos upgrades de versão do VRP para o AR2200E incluem:
Versão 5.90 (AR2200 V200R001C00)
Versão 5.110 (AR2200 V200R002C00)
Versão 5.160 (AR2200 V200R007C00)

Transferência de arquivo

A transferência de arquivos refere-se aos meios pelos quais os arquivos são enviados ou recuperados
de um servidor remoto ou local de armazenamento. Dentro da rede IP, esta aplicação pode ser
implementada para uma ampla gama de propósitos. Como parte da prática efetiva, é comum que
arquivos importantes sejam duplicados e salvos em um local de armazenamento remoto para evitar
qualquer perda que afete as operações críticas dos sistemas. Isso inclui arquivos como a imagem VRP de
produtos que (caso a imagem existente sofra perda por meio do uso do comando format ou outras
formas de erro), podem ser recuperados remotamente e usados para recuperar as operações do
sistema. Princípios semelhantes se aplicam a arquivos de configuração importantes e à manutenção de
registros de atividades em dispositivos armazenados em arquivos de log, que podem ser armazenados a
longo prazo no servidor remoto.
Métodos de Transferência de Arquivos

O FTP é um protocolo de aplicativo padrão baseado no conjunto de protocolos TCP / IP e usado para
transferir arquivos entre clientes locais e servidores remotos. O FTP usa duas conexões TCP para copiar
um arquivo de um sistema para outro. As conexões TCP são geralmente estabelecidas no modo cliente-
servidor, uma para controle (o número da porta do servidor é 21) e a outra para a transmissão de dados
(o número da porta do servidor é 20). FTP como um protocolo de transferência de arquivos é usado para
controlar conexões emitindo comandos do cliente (RTA) para o servidor e transmite respostas do
servidor para o cliente, minimizando o atraso de transmissão. Em termos de transmissão de dados, o
FTP transmite dados entre o cliente e o servidor, maximizando o rendimento.
Trivial File Transfer Protocol (TFTP) é um protocolo simples de transferência de arquivos através do
qual um roteador pode funcionar como um cliente TFTP para acessar arquivos em um servidor TFTP. Ao
contrário do FTP, o TFTP não possui uma interface de acesso interativa complexa e controle de
autenticação. A implementação do TFTP baseia-se no protocolo UDP (User Datagram Protocol). O
cliente inicia a transferência TFTP. Para baixar arquivos, o cliente envia um pacote de solicitação de
leitura para o servidor TFTP, recebe pacotes do servidor e retorna uma confirmação para o servidor.
Para fazer upload de arquivos, o cliente envia um pacote de solicitação de gravação ao servidor TFTP,
envia pacotes para o servidor e recebe confirmação do servidor.
 Processo de atualização de VRP

O exemplo demonstra como a conexão entre um servidor FTP e um cliente é estabelecida para
recuperar uma imagem VRP que pode ser usada como parte do processo de atualização do sistema.
Antes de qualquer transferência de dados, é necessário estabelecer a conectividade subjacente sobre
quais arquivos podem ser transferidos. Isso começa fornecendo o endereçamento IP adequado para o
cliente e o servidor. Onde os dispositivos estão diretamente conectados, podem ser aplicadas interfaces
que pertençam à mesma rede. Onde os dispositivos pertencem a redes localizadas em uma grande área
geográfica, os dispositivos devem estabelecer endereçamento IP relevante dentro de suas redes e ser
capazes de descobrir um caminho de rede relevante sobre IP através do qual a conectividade cliente /
servidor possa ser estabelecida.
Disponibilidade de espaço de armazenamento

Um usuário deve determinar para qualquer atualização do sistema se há espaço de armazenamento

adequado para armazenar o arquivo a ser recuperado. Os comandos do sistema de arquivos podem ser
usados para determinar o status atual do sistema de arquivos, incluindo quais arquivos estão
atualmente presentes no local de armazenamento de arquivos do dispositivo e também a quantidade de
espaço atualmente disponível. Onde o espaço de armazenamento não é adequado para a transferência
de arquivos, certos arquivos podem ser excluídos ou carregados no servidor FTP no caso de ainda serem
necessários para uso futuro.
O exemplo demonstra o uso do comando delete file system para remover o arquivo de imagem
existente. Deve-se observar que a imagem do sistema, embora excluída, não afetará a operação atual
do dispositivo, desde que o dispositivo permaneça operacional; portanto, o dispositivo não deve ser
desligado ou reiniciado antes que um novo arquivo de imagem VRP seja restaurado no local de
armazenamento do dispositivo e definido para ser usado durante a próxima inicialização do sistema.
 Recuperando Arquivos de um Servidor FTP

A recuperação de arquivos de um servidor FTP requer que uma conexão seja estabelecida antes que
qualquer transferência de arquivos possa ocorrer. Dentro do dispositivo cliente, o serviço ftp é iniciado
usando o ftp <ip address>, onde o endereço IP está relacionado ao endereço do servidor FTP ao qual o
cliente deseja se conectar. Conexões FTP serão estabelecidas usando TCP, e requer autenticação na
forma de um nome de usuário e senha que é definido pelo servidor FTP. Uma vez que a autenticação
tenha sido alcançada com sucesso, o cliente terá acesso estabelecido ao servidor FTP e poderá usar uma
variedade de comandos para visualizar os arquivos existentes armazenados no diretório atual local do
servidor.
Antes da transmissão do arquivo, o usuário pode ser solicitado a definir o tipo de arquivo para o qual
existem dois formatos, ASCII e Binary. O modo ASCII é usado para texto, no qual os dados são
convertidos da representação de caracteres do remetente para "ASCII de 8 bits" antes da transmissão e,
em seguida, para a representação de caracteres do receptor. O modo binário, por outro lado, exige que
o remetente envie cada byte de arquivo para byte. Este modo é freqüentemente usado para transferir
arquivos de imagem e arquivos de programas, e deve ser aplicado ao enviar ou recuperar qualquer
arquivo de imagem VRP. No exemplo, o comando get vrp.cc foi emitido para recuperar a nova imagem
VRP localizada no servidor remoto.
Recuperando arquivos de um servidor TFTP
 No caso de o cliente desejar recuperar uma imagem VRP de um servidor TFTP, não é necessário
estabelecer primeiro uma conexão com o servidor. Em vez disso, o cliente deve definir o caminho para o
servidor na linha de comando, juntamente com a operação a ser executada. Também deve ser notado
que os modelos AR2200E e S5720 servem apenas como cliente TFTP e transferem arquivos apenas em
formato binário. Como pode ser visto no exemplo, o comando get é aplicado para a recuperação do
arquivo de imagem VRP do servidor TFTP após a definição do endereço de destino do servidor TFTP.

Processo de gerenciamento de inicialização de VRP

A transferência do arquivo de imagem do VRP para o cliente, uma vez obtida com sucesso, requer
que a imagem seja ativada como o software do sistema de inicialização durante o próximo processo de
inicialização do sistema. Para alterar a versão do software do sistema, o comando startup system-
software deve ser executado e incluir o arquivo de software do sistema a ser usado na próxima
inicialização. Um arquivo de software do sistema deve usar .cc como extensão de nome de arquivo, e o
arquivo de software do sistema usado na próxima inicialização não pode ser aquele usado na
inicialização atual.
Além disso, o diretório de armazenamento de um arquivo de software do sistema deve ser o
diretório raiz, caso contrário, o arquivo não será executado. O comando de inicialização da tela deve ser
usado para verificar se a alteração no software do sistema de inicialização foi executada com sucesso. A
saída para o software do sistema de inicialização deve mostrar a imagem VRP existente, enquanto o
próximo software do sistema de inicialização deve exibir a imagem VRP transferida que agora está
presente no diretório raiz do dispositivo.
 Aplicando as alterações

A confirmação do software do sistema de inicialização permite o início seguro do software do sistema

durante a próxima inicialização do sistema. Para aplicar as alterações e permitir que o novo software do
sistema entre em vigor, o dispositivo deve ser reiniciado. O comando reboot pode ser usado para iniciar
a reinicialização do sistema. Durante o processo de reinicialização, um prompt será exibido solicitando
confirmação sobre se o arquivo de configuração para a próxima inicialização do sistema será salvo.
Em alguns casos, o arquivo de configuração salvo pode ser apagado pelo usuário para permitir que
uma nova configuração seja implementada. Caso isso tenha ocorrido, espera-se que o usuário defina
uma resposta de "não" no aviso "Continuar?". Se o usuário escolher "sim" neste ponto, a configuração
atual será reconfigurada para o arquivo de configuração salvo e aplicada novamente durante a próxima
inicialização. Se o usuário não estiver ciente das alterações para as quais o prompt de salvamento está
fornecendo um aviso, é recomendável que o usuário selecione "não" ou "n" e faça uma comparação das
configurações salvas e atuais para verificar as alterações. Para o prompt de reinicialização, é necessária
uma resposta de "sim" ou "y" para concluir o processo de reinicialização.

Resumo

1-O que deve ser configurado no cliente para estabelecer uma conexão com um servidor FTP?
Um dispositivo cliente deve ter a capacidade de acessar o servidor FTP por IP, exigindo que um
endereço IP seja configurado na interface através da qual o servidor FTP pode ser alcançado. Isso
permitirá que um caminho seja validado para o servidor FTP na camada de rede, se houver um.

2-Como um usuário pode confirmar que as alterações no software de inicialização entrarão em vigor
após a reinicialização do dispositivo?
O usuário pode executar a inicialização da exibição do comando de configuração para validar que o
software de sistema de inicialização atual (VRP) está ativo, identificado pela extensão.
Prefácio
A introdução de um dispositivo de comutação como parte da rede corporativa
demonstra como as redes podem se expandir além das conexões ponto-a-ponto e as
redes compartilhadas nas quais podem ocorrer colisões. O comportamento do switch
corporativo quando introduzido na rede local é detalhado, juntamente com um
entendimento da manipulação de quadros de tipo difusão ponto a ponto e difusão, para
demonstrar como os switches permitem que as redes superem os obstáculos de
desempenho das redes compartilhadas.
Objectivos
Após a conclusão desta seção, os formandos serão capazes de:
 Explicar o processo de tomada de decisão de um switch de camada
de enlace.
 Configurar parâmetros para negociação em um comutador de
camada de link.
 Construindo uma única rede comutada

À medida que a rede corporativa se expande, vários usuários precisam ser estabelecidos como parte
de uma rede de múltiplos acessos. A evolução das tecnologias de rede sofreu uma mudança de redes
locais compartilhadas, para redes que suportam múltiplos domínios de colisão e suportam o uso de
formas de mídia 100BaseT que isolam a transmissão e recepção de dados através de pares de fios
separados, eliminando assim o potencial de colisões ocorrer e permitir taxas de transmissão full duplex
mais altas. O estabelecimento de um switch traz a capacidade de aumentar a densidade de portas para
permitir a conexão de um maior número de dispositivos do sistema final em uma única rede local. Cada
sistema final ou host dentro de uma rede local deve ser conectado como parte da mesma rede IP para
que a comunicação seja facilitada na camada de rede. O endereço IP, no entanto, só é relevante para os
sistemas host, uma vez que os dispositivos de comutação operam dentro do escopo da camada de
enlace e, portanto, dependem do endereçamento MAC para o encaminhamento de quadros.
O estado inicial do switch

Como um dispositivo de camada de enlace, cada comutador depende de uma tabela baseada em
MAC que fornece associação entre um endereço MAC de destino e a interface de porta por meio da qual
um quadro deve ser encaminhado. Isso é comumente chamado de tabela de endereços MAC.
O início de um comutador começa com o comutador sem conhecimento dos sistemas finais e como
os quadros recebidos dos sistemas finais devem ser encaminhados. É necessário que o switch crie
entradas dentro da tabela de endereços MAC para determinar o caminho que cada quadro recebido
deve tomar para alcançar um determinado destino, de modo a limitar o tráfego de broadcast dentro da
rede local. Essas entradas de caminho são preenchidas na tabela de endereços MAC como resultado de
quadros recebidos de sistemas finais. No exemplo, o Host A encaminhou um quadro para o Switch A,
que atualmente não possui entradas em sua tabela de endereços MAC.
Aprendizagem de endereços MAC

O quadro que é encaminhado do host A contém uma entrada de endereço MAC de difusão no campo
de endereço de destino do cabeçalho do quadro. O campo de endereço de origem contém o endereço
MAC do dispositivo de peering, neste caso, Host A. Esse endereço MAC de origem é usado pelo switch
para preencher a tabela de endereços MAC, associando a entrada MAC no campo de endereço de
origem ao comutador. interface de porta na qual o quadro foi recebido. O exemplo demonstra como o
endereço MAC está associado à interface de porta para permitir que qualquer tráfego de retorno para
esse destino MAC seja encaminhado diretamente por meio da interface associada.

Encaminhando os primeiros dados

 O comportamento geral de uma solicitação ARP envolve o quadro sendo inundado para todos os
destinos pretendidos principalmente devido à transmissão MAC (FF-FF-FF-FF-FF-FF) que representa o
destino atual. O comutador é, portanto, responsável por encaminhar esse quadro para fora de cada
interface de porta com exceção da interface de porta na qual o quadro foi recebido, na tentativa de
localizar o destino IP pretendido conforme listado no cabeçalho ARP para o qual uma resposta ARP pode
ser gerada . Como demonstrado no exemplo, os quadros individuais são inundados a partir do
comutador através das interfaces de porta G0 / 0/2 e G0 / 0/3 em direção aos hosts B e host C,
respectivamente.

A resposta do destino

Como resultado do cabeçalho de solicitação ARP, o host de recebimento é capaz de determinar que o
cabeçalho ARP é destinado ao destino IP de 10.1.1.3, juntamente com o endereço de origem local (MAC)
do qual o quadro foi originado e usar essas informações para gerar uma resposta unicast. As
informações relativas ao Host A estão associadas ao endereço IP de 10.1.1.3 e armazenadas na tabela de
endereços MAC do Host C. Ao fazer isso, a geração de tráfego de broadcast é minimizada, reduzindo
assim o número de interrupções para destinos locais, bem como redução do número de quadros
propagando a rede local.
Depois que o quadro é recebido do Host C pelo Comutador A, o comutador preencherá a tabela de
endereços MAC com o endereço MAC de origem do quadro recebido e associará a interface de porta na
qual o quadro foi recebido. O switch usa a tabela de endereços MAC para realizar uma pesquisa, a fim
de descobrir a interface de encaminhamento, com base no endereço MAC de destino do quadro. Neste
caso, o endereço MAC do quadro refere-se ao Host A, para o qual existe agora uma entrada através da
interface G0 / 0/1, permitindo que o quadro seja encaminhado para o destino conhecido.
Configuração básica

Os primeiros sistemas Ethernet operavam com base em um modo half-duplex de 10Mbps e

aplicavam mecanismos como o CSMA / CD para garantir a estabilidade do sistema. A transição para um
meio de par trançado deu origem ao surgimento da Ethernet full-duplex, o que melhorou muito o
desempenho da Ethernet e significou que duas formas de duplex poderiam ser negociadas. A tecnologia
de negociação automática permite que os sistemas Ethernet mais recentes sejam compatíveis com
sistemas Ethernet anteriores.
No modo de negociação automática, as interfaces nas duas extremidades de um link negociam seus
parâmetros operacionais, incluindo o modo duplex, taxa e controle de fluxo. Se a negociação for bem-
sucedida, as duas interfaces funcionam com os mesmos parâmetros operacionais. Em alguns casos, no
entanto, é necessário definir manualmente os parâmetros de negociação, por exemplo, onde as
interfaces Gigabit Ethernet que estão funcionando no modo de negociação automática estão
conectadas por meio de um cabo de rede de 100 Mbps. Nesses casos, a negociação entre as interfaces
falhará.
Devido a diferentes modelos de produto, os switches HUAWEI podem não suportar o modo de
mudança de porta duplex, consulte o manual do produto.
 Verificação Básica da Configuração

No caso de os parâmetros de configuração para negociação serem alterados de usar negociação

automática, os parâmetros definidos devem ser verificados usando o comando <interface> da interface
de exibição para verificar se os parâmetros negociados permitem que a negociação da interface da
camada de link seja bem-sucedida. Isso é verificado pelo estado atual do protocolo de linha sendo
exibido como UP. As informações exibidas refletem as configurações atuais dos parâmetros de uma
interface.

Resumo
1-Se um comutador registrar o endereço MAC de origem de um dispositivo host em uma interface de
porta e a conexão física do host for alterada para outra interface de porta no comutador, qual ação o
comutador executaria?
Quando um host ou outro sistema terminal é conectado a uma interface de porta de switch, é gerado
um ARP gratuito projetado para garantir que os endereços IP permaneçam exclusivos dentro de um
segmento de rede. A mensagem ARP gratuita, no entanto, também fornece ao comutador informações
sobre o endereço MAC do host, que é então incluído na tabela de endereços MAC e associado à
interface de porta na qual o host está conectado.
Se a conexão física de um host conectado a uma interface de porta de switch for removida, o switch
descobrirá que o link físico está inativo e removerá a entrada MAC da tabela de endereços MAC.
Quando a mídia estiver conectada a outra interface de porta, a porta detectará que o link físico está
ativo e um ARP gratuito será gerado pelo host, permitindo que o switch localize e preencha a tabela de
endereços MAC com o endereço MAC do host conectado .
 Prefácio
À medida que a rede corporativa se expande, as redes com comutação múltipla são
introduzidas para fornecer comunicação de camada de enlace entre um número crescente de sistemas
finais. À medida que novas interconexões são formadas entre múltiplos switches corporativos, novas
oportunidades para a construção de redes sempre resilientes são possíveis, no entanto, o potencial de
comutação de falhas como resultado de loops torna-se cada vez mais provável. É necessário que o
protocolo spanning tree (STP) seja entendido em termos de comportamento na prevenção de loops de
comutação e como ele pode ser manipulado para se adequar ao design e desempenho da rede
corporativa.

Objectivos
Após a conclusão desta seção, os formandos serão capazes de:
 Descreva os problemas enfrentados ao usar uma rede comutada.
 Explique o processo de prevenção de loop do protocolo spanning tree.
 Configurar parâmetros para gerenciar o design da rede STP.
 Redundância da Camada 2

O crescimento das empresas resulta no comissionamento de múltiplos switches para suportar a

interconectividade dos sistemas finais e serviços necessários para as operações diárias. A interconexão
de múltiplos switches, no entanto, traz desafios adicionais que precisam ser resolvidos. Os comutadores
podem ser estabelecidos como enlaces ponto-a-ponto únicos através dos quais os sistemas finais são
capazes de encaminhar quadros para destinos localizados através de outros comutadores dentro do
domínio de broadcast. No entanto, a falha de qualquer link de comutador ponto-a-ponto resulta no
isolamento imediato do comutador a jusante e em todos os sistemas finais aos quais o link está
conectado. Para resolver esse problema, a redundância é altamente recomendada em qualquer rede de
comutação.
Portanto, os links redundantes geralmente são usados em uma rede de comutação Ethernet para
fornecer backup de link e aprimorar a confiabilidade da rede. O uso de links redundantes, no entanto,
pode produzir loops que causam uma deterioração drástica da qualidade da comunicação e grandes
interrupções no serviço de comunicação.
 Tempestades de Broadcast

Um dos efeitos iniciais dos loops redundantes de comutação vem na forma de tempestades de
broadcast. Isso ocorre quando um sistema final tenta descobrir um destino para o qual nem ele nem os
comutadores ao longo do caminho de comutação estão cientes. Uma transmissão é, portanto, gerada
pelo sistema final que é inundado pelo comutador de recepção.
O efeito de inundação significa que o quadro é encaminhado por todas as interfaces, com exceção da
interface na qual o quadro foi recebido. No exemplo, o Host A gera um quadro, que é recebido pelo
Switch B, que é subseqüentemente encaminhado para fora de todas as outras interfaces. Uma instância
do quadro é recebida pelos comutadores conectados A e C, que por sua vez inundam o quadro de todas
as outras interfaces. O efeito contínuo de flooding resulta em instâncias de flooding Switch A e Switch C
do quadro de um switch para o outro, que por sua vez é inundado de volta para o Switch B, e assim o
ciclo continua. Além disso, o efeito de inundação repetida resulta em várias instâncias do quadro sendo
recebido pelas estações finais, causando interrupções e degradação extrema do desempenho dos
switches.

Instabilidade MAC

Switches devem manter registros do caminho através do qual um destino é alcançável. Isso é
identificado por meio da associação do endereço MAC de origem de um quadro com a interface na qual
o quadro foi recebido. Apenas uma instância de um endereço MAC pode ser armazenada na tabela de
endereços MAC de um comutador e, quando uma segunda instância do endereço MAC é recebida, as
informações mais recentes têm precedência.
No exemplo, o switch B atualiza a tabela de endereços MAC com o endereço MAC do host A e associa
essa fonte à interface G0 / 0/3, a interface de porta na qual o quadro foi recebido. Como os quadros são
inundados incontrolavelmente dentro da rede de comutação, um quadro é novamente recebido com o
mesmo endereço MAC de origem do Host A, entretanto, desta vez, o quadro é recebido na interface G0
/ 0/2. O switch B deve, portanto, assumir que o host que estava originalmente acessível através da
interface G0 / 0/3 está agora acessível através de G0 / 0/2 e atualizará a tabela de endereços MAC de
acordo. O resultado desse processo leva à instabilidade do MAC e continua a ocorrer indefinidamente
entre as duas interfaces de porta do switch que se conectam ao Switch A e ao Switch C, já que os
quadros são inundados em ambas as direções como parte do efeito de tempestade de broadcast.

Resolvendo Problemas de Redundância de Camada 2

O desafio para a rede de comutação reside na capacidade de manter a redundância de comutação

para evitar o isolamento de sistemas finais no caso de falha no sistema de comutador ou link, e a
capacidade de evitar os efeitos prejudiciais de loops de comutação dentro de uma topologia de
comutação que implemente redundância. A solução resultante por muitos anos tem sido implementar o
protocolo spanning tree (STP) para evitar os efeitos de loops de comutação. A árvore de abrangência
trabalha com o princípio de que os links redundantes sejam logicamente desabilitados para fornecer
uma topologia sem loop, enquanto habilitam dinamicamente links secundários no caso de ocorrer uma
falha ao longo do caminho de comutação primário, cumprindo assim o requisito de redundância de rede
em um loop topologia livre. Os dispositivos de comutação que executam o STP detectam loops na rede,
trocando informações entre si e bloqueando determinadas interfaces para cortar os loops. STP
continuou a ser um protocolo importante para a LAN há mais de 20 anos.

A Ponte Raiz do Spanning Tree

A remoção de qualquer potencial para loops serve como objetivo principal da árvore de abrangência
para a qual é formada uma arquitetura de tipo de árvore invertida. Na base desta árvore lógica está a
bridge / switch raiz. A bridge raiz representa o centro lógico, mas não necessariamente o centro físico da
rede compatível com STP. A ponte raiz designada é capaz de mudar dinamicamente com a topologia da
rede, como no caso em que a ponte raiz existente falha em continuar operando como a bridge raiz.
Considera-se que as pontes não-raiz estão a jusante da ponte-raiz e a comunicação aos fluxos de pontes
não-raiz da ponte-raiz em direção a todas as pontes não-raiz. Somente uma única bridge raiz pode
existir em uma rede convergente compatível com STP a qualquer momento.

Bridge ID

A descoberta da bridge raiz para uma rede STP é uma tarefa principal executada para formar a árvore
de abrangência. O protocolo STP opera com base na eleição, através da qual o papel de todos os
switches é determinado. Um ID de ponte é definido como o meio pelo qual a ponte raiz é descoberta.
Isso compreende duas partes, sendo a primeira uma prioridade de ponte de 16 bits e a segunda um
endereço MAC de 48 bits.
 O dispositivo que é dito conter a prioridade mais alta (menor ID de ponte) é eleito como a bridge raiz
para a rede. A comparação da ID da ponte leva em conta inicialmente a prioridade da ponte e, quando
esse valor de prioridade não consegue identificar exclusivamente uma ponte raiz, o endereço MAC é
usado como desempatador. O ID da bridge pode ser manipulado através da alteração da prioridade da
bridge como um meio de permitir que um determinado switch seja eleito como bridge raiz, muitas vezes
em suporte a um projeto de rede otimizado.

Bridge Protocol Data Unit(BPDU)

 A topologia da árvore de abrangência depende da comunicação de informações específicas para
determinar a função e o status de cada comutador na rede. Uma unidade de dados de protocolo de
ponte (BPDU) facilita a comunicação dentro de uma rede de árvore de abrangência. Duas formas de
BPDU são usadas dentro do STP. Um BPDU de Configuração é criado inicialmente pela raiz e pelo
downstream propagado para garantir que todas as pontes não-raiz permaneçam conscientes do status
da topologia da árvore de abrangência e, o mais importante, da ponte raiz. O TCN BPDU é uma segunda
forma de BPDU, que propaga a informação no sentido ascendente em direção à raiz e deve ser
introduzida em mais detalhes como parte do processo de alteração da topologia.
As Unidades de Dados de Protocolo de Ponte não são diretamente encaminhadas por comutadores,
em vez disso, as informações que são transportadas dentro de um BPDU são frequentemente usadas
para gerar um BPDU próprio de comutadores para transmissão. Um BPDU de Configuração carrega
vários parâmetros usados por uma ponte para determinar principalmente a presença de uma ponte raiz
e garantir que a ponte raiz permaneça como a ponte com a prioridade mais alta. Considera-se que cada
segmento de LAN possui um comutador designado que é responsável pela propagação de BPDU a
jusante para comutadores não designados.
O campo Bridge ID é usado para determinar o comutador designado atual do qual se espera que o
BPDU seja recebido. O BPDU é gerado e encaminhado pela bridge raiz com base em um timer Hello, que
é configurado para 2 segundos por padrão. Como os BPDU são recebidos pelos switches downstream,
um novo BPDU é gerado com parâmetros definidos localmente e encaminhado para todos os switches
não designados para o segmento de LAN.

Custo do caminho

Outra característica do BPDU é a propagação de dois parâmetros relacionados ao custo do caminho.

O custo do caminho da raiz (RPC) é usado para medir o custo do caminho até a raiz da ponte, a fim de
determinar o caminho mais curto da árvore de abrangência e, assim, gerar uma topologia livre de loop.
Quando a bridge é a bridge raiz, o custo do caminho da raiz é 0. O custo do caminho (PC) é um valor
associado à porta raiz, que é a porta em um comutador downstream que se conecta ao segmento da
LAN, no qual um comutador designado ou uma ponte-raiz reside. Esse valor é usado para gerar o custo
do caminho raiz para o comutador, adicionando o custo do caminho ao valor de RPC que é recebido do
comutador designado em um segmento da LAN, para definir um novo valor de custo do caminho raiz.
Esse novo valor de custo do caminho raiz é transportado no BPDU do comutador designado e é usado
para representar o custo do caminho para a raiz.

Padrões de Custo do Caminho

Os switches da série Sx7 da Huawei suportam uma série de padrões de custo de caminho alternativo
que podem ser implementados com base nos requisitos corporativos, como onde uma rede de
comutação de vários fornecedores pode existir. A série de switches Huawei Sx7 usa o padrão de custo
do caminho 802.1t por padrão, fornecendo uma precisão métrica mais forte para o cálculo do custo do
caminho.

Função das Portas no Spanning Tree

Uma rede de árvore de abrangência convergida define que cada interface seja atribuída a uma
função de porta específica. As funções de porta são usadas para definir o comportamento das interfaces
de porta que participam de uma topologia de árvore de abrangência ativa. Para o protocolo spanning
tree, três funções de porta designada, raiz e alternativa são definidas.
 A porta designada está associada a uma ponte raiz ou a uma ponte designada de um segmento da
LAN e define o caminho downstream pelo qual a Configuração BPDU é encaminhada. A bridge raiz é
responsável pela geração de BPDU de configuração para todos os switches downstream e, portanto, as
interfaces de porta de bridge raiz sempre adotam a função de porta designada.
A porta raiz identifica a porta que oferece o caminho de custo mais baixo para a raiz, com base no
custo do caminho da raiz. O exemplo demonstra o caso em que existem dois caminhos possíveis de
volta para a raiz, no entanto, somente a porta que oferece o menor custo do caminho raiz é designada
como a porta raiz. Quando duas ou mais portas oferecem custos de caminho raiz iguais, a decisão de
qual interface de porta será a porta raiz é determinada pela comparação do ID da ponte na configuração
BPDU recebida em cada porta.
Qualquer porta que não tenha uma função de porta designada ou raiz é considerada uma porta
alternativa e pode receber BPDU do comutador designado para o segmento de LAN com a finalidade de
monitorar o status do link redundante, mas não processará o retorno recebido. BPDU. O padrão IEEE
802.1D-1990 para STP originalmente definiu essa função de porta como backup, no entanto, isso foi
corrigido para se tornar a função de porta alternativa dentro da revisão de padrões IEEE 802.1D-1998.

ID da Porta

O ID da porta representa um meio final para determinar as funções de porta ao lado do mecanismo
de custo da ID da ponte e do caminho da raiz. Em cenários em que duas ou mais portas oferecem um
custo de caminho raiz de volta à raiz que é igual e para o qual o switch upstream é considerado como
tendo uma ID de ponte igual, principalmente devido ao switch upstream ser o mesmo comutador para
ambos os caminhos, o ID da porta deve ser aplicado para determinar as funções da porta.
 O ID da porta está vinculado a cada porta e é composto por uma prioridade de porta e um número de
porta que se associa à interface de porta. A prioridade da porta é um valor no intervalo de 0 a 240,
atribuído em incrementos de 16 e representado por um valor de 128 por padrão. Onde ambas as
interfaces de porta oferecem um valor de prioridade de porta igual, o número de porta exclusivo é
usado para determinar as funções de porta. O identificador de porta mais alto (o número de porta mais
baixo) representa a porta atribuída como a porta raiz, com a porta restante assumindo como padrão
uma função de porta alternativa.

Temporizadores

A bridge raiz é responsável pela geração de BPDU de configuração com base em um intervalo BPDU
que é definido por um timer Hello. Este timer Hello por padrão representa um período de 2 segundos.
Uma rede de árvore de abrangência convergida deve garantir que, no caso de uma falha na rede, os
comutadores dentro da rede habilitada para STP estejam cientes da falha. Um temporizador Max Age é
associado a cada BDPU e representa o tempo de vida de um BPDU desde o ponto de concepção até a
ponte-raiz e, por fim, controla o período de validade de um BDPU antes de ser considerado obsoleto.
Este temporizador MAX Age, por padrão, representa um período de 20 segundos.
 Quando uma configuração BPDU é recebida da bridge raiz, considera-se que o switch downstream
leva aproximadamente 1 segundo para gerar um novo BPDU e propaga o downstream do BPDU gerado.
Para compensar esse tempo, um valor de idade da mensagem (Idade MSG) é aplicado a cada BPDU para
representar o deslocamento entre a Idade MÁX e o atraso de propagação, e para cada comutador esse
valor de idade da mensagem é incrementado em 1.
Como o BPDU é propagado da bridge raiz para os switches downstream, o temporizador MAX Age é
atualizado. O temporizador MAX Age diminui e expira quando o valor MAX Age excede o valor da idade
da mensagem, para garantir que a vida útil de um BPDU seja limitada à MAX Age, conforme definido
pela bridge raiz. No caso de uma BPDU não ser recebida antes de expirar o temporizador MAX Age, o
switch considerará as informações do BPDU atualmente consideradas obsoletas e presumirá que
ocorreu uma falha na rede STP.

Processo de eleição da raiz

O processo de convergência da árvore de abrangência é um procedimento automatizado que é

iniciado no ponto de inicialização do comutador. Todos os switches na inicialização assumem o papel de
bridge raiz dentro da rede de comutação. O comportamento padrão de uma bridge raiz é atribuir uma
função de porta designada a todas as interfaces de porta para ativar o encaminhamento de BPDU por
meio de todas as interfaces de porta conectadas. Como BPDU são recebidos por switches de peering, a
ID da ponte será comparada para determinar se existe um candidato melhor para a função de bridge
raiz. No caso em que o BPDU recebido contenha um ID de ponte inferior em relação ao ID de raiz, o
comutador de recebimento continuará a anunciar sua própria configuração BPDU ao comutador vizinho.
Onde o BDPU é superior, o switch reconhecerá a presença de um melhor candidato para o papel de
bridge raiz, deixando de propagar o BPDU na direção da qual o BPDU superior foi recebido. O switch
também alterará o campo de ID da raiz de seu BPDU para anunciar o ID da ponte do candidato da bridge
raiz como a nova bridge raiz atual.

Processo de Estabelecimento da Função de Porta

Uma bridge raiz eleita, uma vez estabelecida, gerará a configuração BPDU para todos os outros
switches não-root. O BPDU carregará um custo do caminho da raiz que informará os comutadores
downstream do custo para a raiz, para permitir que o caminho mais curto seja determinado. O custo do
caminho raiz transportado no BPDU que é gerado pela bridge raiz sempre tem um valor 0. Os switches
recebedores downstream adicionarão esse custo ao custo do caminho das interfaces de porta nas quais
o BPDU foi recebido e a partir do qual um switch é capaz de identificar a porta raiz.
No caso em que existem custos de caminho raiz iguais em dois ou mais segmentos de LAN para o
mesmo comutador de upstream, o ID de porta é usado para descobrir as funções de porta. Onde existe
um custo de caminho de raiz igual entre dois comutadores, como no exemplo dado, o ID de ponte é
usado para determinar qual comutador representa o comutador designado para o segmento de LAN.
Onde a porta do switch não é uma porta raiz nem uma porta designada, a função de porta é atribuída
como alternativa.

Transição do Estado de Porta

 Como parte da criação da função de ponte raiz e porta, cada comutador progredirá por meio de
várias transições de estado da porta. Qualquer porta que seja desativada administrativamente será
considerada como estando no estado desativado. A ativação de uma porta no estado desativado verá
uma transição de estado para o estado de bloqueio ①.
Qualquer porta considerada em estado de bloqueio não pode encaminhar nenhum tráfego de
usuário, mas é capaz de receber quadros de BPDU. Qualquer BPDU recebido em uma interface de porta
no estado de bloqueio não será usado para preencher a tabela de endereços MAC do comutador, mas
para determinar se é necessária uma transição para o estado de atendimento. O estado de escuta
permite a comunicação de informações de BPDU, após a negociação da função de porta no STP ②, mas
mantém a restrição de preenchimento da tabela de endereços MAC com informações vizinhas.
Uma transição para o estado de bloqueio da escuta ou de outros estados ③ pode ocorrer no caso
em que a porta é alterada para uma função de porta alternativa. A transição entre ouvir aprendizado e
aprender nos estados de encaminhamento ④ depende muito do temporizador de atraso de
encaminhamento, que existe para garantir que qualquer propagação de informações de BDPU para
todos os comutadores na topologia da árvore de abrangência seja alcançável antes que ocorra a
transição de estado.
O estado de aprendizado mantém a restrição de encaminhamento de tráfego do usuário para
garantir a prevenção de qualquer loop de comutação, mas permite a população da tabela de endereços
MAC em toda a topologia da árvore de abrangência para assegurar uma rede de comutação estável.
Após um período de atraso de encaminhamento, o estado de encaminhamento é atingido. O estado
desativado é aplicável a qualquer momento durante o período de transição de estado por meio de
intervenção manual (ou seja, o comando de desligamento) ⑤.

Falha da Raiz

Os eventos que causam uma alteração na topologia da árvore de abrangência estabelecida podem
ocorrer de várias maneiras, para os quais o protocolo de árvore de abrangência deve reagir para
restabelecer rapidamente uma topologia estável e livre de loop. A falha da bridge raiz é um exemplo
primário de onde a convergência é necessária. Os switches não-raiz dependem do pulso intermitente do
BPDU da bridge-raiz para manter suas funções individuais como switches não-raiz na topologia do STP.
No caso de a ponte raiz falhar, os switches downstream não receberão um BPDU da bridge raiz e, como
tal, também deixarão de propagar qualquer downstream do BPDU. O temporizador de Idade MÁX
normalmente é redefinido para o valor definido (20 segundos por padrão) após o recebimento de cada
downstream de BPDU.
Com a perda de qualquer BPDU, no entanto, o temporizador MAX Age começa a contar a vida útil das
informações atuais de BPDU de cada switch não raiz, com base na fórmula (Idade máxima - Idade do
MSG). No ponto em que o valor da Idade MSG é maior que o valor do temporizador MAX Age, as
informações do BPDU recebidas da raiz se tornam inválidas e os switches não-raiz começam a assumir o
papel de bridge raiz. A configuração BPDU é novamente enviada de todas as interfaces ativas em uma
tentativa de descobrir uma nova bridge raiz. A falha da bridge raiz invoca uma duração de recuperação
de aproximadamente 50 segundos devido ao período de convergência Max Age + 2x Forward Delay.

Falha de link indireto

No caso de uma falha de link indireto, um switch perde a conexão com a bridge raiz devido a uma
falha da porta ou mídia, ou possivelmente devido à desativação manual da interface que atua como a
porta raiz. O switch em si se tornará imediatamente ciente da falha e, como ele recebe apenas o BPDU
da raiz em uma direção, assumirá a perda imediata da bridge raiz e declarará sua posição como a nova
bridge raiz.
 A partir do exemplo, o comutador B começa a encaminhar o BPDU para o comutador C para notificar
a posição do comutador B como a nova ponte raiz, entretanto o comutador C continua a receber BPDU
da ponte raiz original e, portanto, ignora qualquer BPDU do comutador B. A porta começará a
envelhecer seu estado por meio do temporizador MAX Age, já que a interface não recebe mais o BPDU
contendo o ID raiz da bridge raiz.
Após a expiração do temporizador MAX Age, o switch C mudará a função de porta da porta
alternativa para a de uma porta designada e continuará a encaminhar o BPDU da raiz para o switch B, o
que fará com que o switch conceda sua afirmação como a raiz ponte e converge sua interface de porta
para a função de porta raiz. No entanto, isso representa uma falha de topologia parcial devido à
necessidade de esperar por um período equivalente a MAX Age + 2x de atraso de avanço, a recuperação
completa da topologia de STP requer aproximadamente 50 segundos.

Falha no link direto

Um cenário final envolvendo a recuperação da convergência da árvore de abrangência ocorre quando

vários segmentos da LAN são conectados entre dois dispositivos de comutação para os quais um é
atualmente o link ativo, enquanto o outro fornece um caminho alternativo para a raiz. Se ocorrer um
evento que faça com que o comutador que está recebendo o BPDU detecte uma perda de conexão em
sua porta raiz, como no caso de ocorrer uma falha na porta raiz ou ocorrer uma falha no link, para o qual
o comutador downstream é feito imediatamente ciente, o switch pode fazer a transição instantânea da
porta alternativa.
Isso iniciará a transição pelos estados de escuta, aprendizado e encaminhamento e alcançará a
recuperação dentro de um período de atraso de 2x. No caso de qualquer falha, onde o link que fornece
um caminho melhor é reativado, a topologia da árvore de abrangência deve novamente convergir
novamente para aplicar a topologia de árvore de abrangência ideal.

Alterações na topologia-Instabilidade MAC

Em uma rede de árvore de abrangência convergida, os switches mantêm bancos de dados de filtro ou
tabelas de endereços MAC para gerenciar a propagação de quadros por meio da topologia da árvore de
abrangência. As entradas que fornecem uma associação entre um destino MAC e a interface de porta de
encaminhamento são armazenadas por um período finito de 300 segundos (5 minutos) por padrão. No
entanto, uma alteração na topologia da árvore de abrangência significa que todas as entradas da tabela
de endereços MAC existentes provavelmente se tornarão inválidas devido à alteração no caminho de
comutação e, portanto, devem ser renovadas.
O exemplo demonstra uma topologia de árvore de abrangência existente para a qual o comutador B
possui entradas que permitem que o Host A seja alcançado através da interface Gigabit Ethernet 0/0/3 e
do Host B através da interface Gigabit Ethernet 0/0/2. Uma falha é simulada no switch C para o qual a
porta raiz atual se tornou inativa. Essa falha faz com que um recálculo da topologia da árvore de
abrangência comece e, de maneira previsível, a ativação do link redundante entre o switch C e o switch
B.
Após a re-convergência, no entanto, verifica-se que os quadros do Host A para o Host B não estão
conseguindo chegar ao seu destino. Como as entradas da tabela de endereços MAC ainda precisam
expirar com base na regra de 300 segundos, os quadros que alcançam o comutador B destinados ao
Host B continuam a ser encaminhados pela interface de porta Gigabit Ethernet 0/0/2 e tornam-se
efetivamente negros quando os quadros são encaminhado para a interface de porta inativa do switch C.

Topology Change Process

Um mecanismo adicional deve ser introduzido para lidar com o problema do período de tempo limite
de entradas de MAC que resulta na manutenção de entradas de caminho inválidas após a convergência
da árvore de abrangência. O processo implementado é chamado de processo TCN (Topology Change
Notification) e introduz uma nova forma de BPDU na operação do protocolo spanning tree.
Este novo BPDU é referido como o TCN BPDU e é diferenciado da configuração BPDU original do STP
através da configuração do valor do tipo BPDU para 128 (0x80). A função do TCN BPDU é informar a raiz
raiz upstream de qualquer alteração na topologia atual, permitindo assim que a raiz envie uma
notificação dentro da configuração BPDU para todos os comutadores downstream, para reduzir o
período de tempo limite para entradas da tabela de endereço MAC para o equivalente do temporizador
de atraso de encaminhamento ou 15 segundos por padrão.
O campo de sinalizadores da configuração BPDU contém dois campos para Topologia Change (TC) e
Topologia Change Acknowledgement (TCA). Ao receber um TCN BPDU, a bridge raiz gerará um BPDU
com os bits TC e TCA definidos, para notificar respectivamente a alteração da topologia e para informar
aos switches a jusante que a bridge raiz recebeu o TCN BPDU e, portanto, a transmissão do O TCN BPDU
deve parar.
O bit TCA permanecerá ativo por um período igual ao temporizador Hello (2 segundos), seguindo a
configuração que o BPDU gerado pela bridge raiz manterá somente o bit TC por uma duração de (MAX
Age + forward delay), ou 35 segundos por padrão.

Atualização de topologia Atualização de MAC

 O efeito do TCN BPDU no processo de alteração da topologia garante que a bridge raiz seja notificada
de qualquer falha na topologia da árvore de abrangência, para a qual a bridge raiz é capaz de gerar os
sinalizadores necessários para liberar as entradas da tabela de endereço MAC atual em cada os
interruptores. O exemplo demonstra os resultados do processo de alteração de topologia e o impacto
na tabela de endereços MAC. As entradas pertencentes ao switch B foram liberadas e novas entradas
atualizadas foram descobertas para as quais é determinado que o Host B agora pode ser acessado
através da interface de porta Gigabit Ethernet 0/0/1.

Modos STP

Os switches da série Huawei Sx7, aos quais o modelo da série S5700 pertence, são capazes de
suportar três formas de protocolo spanning tree. Usando o comando stp mode, um usuário pode definir
o modo de STP que deve ser aplicado a um switch individual. O modo STP padrão para comutadores da
série Sx7 é MSTP e, portanto, deve ser reconfigurado antes que o STP possa ser usado.

Atribuindo a raiz
 Como parte da boa prática de design de switch, é recomendável que a bridge raiz seja definida
manualmente. O posicionamento da bridge raiz garante que o fluxo de caminho ideal de tráfego dentro
da rede corporativa possa ser alcançado através da configuração do valor de prioridade da ponte para o
protocolo spanning tree. O comando stp prioridade [prioridade] pode ser usado para definir o valor de
prioridade, onde a prioridade se refere a um valor inteiro entre 0 e 61440, atribuído em incrementos de
4096. Isso permite um total de 16 incrementos, com um valor padrão de 32768. Também é possível
designar a bridge raiz para a árvore de abrangência através do comando principal stp root.

Atribuindo Custo de Caminho

 Entendeu-se que a série de switches Huawei Sx7 suporta três formas de padrão de custo de caminho,
a fim de fornecer compatibilidade, quando necessário, no entanto, o padrão é suportar o padrão de
custo do caminho 802.1t. O padrão de custo do caminho pode ser ajustado para um determinado switch
usando o stc pathcost-standard {dot1d-1998 | dot1t | legacy} comando, em que dot1d-1998, dot1t e
legacy se referem aos padrões de custo do caminho descritos anteriormente nesta seção.
Além disso, o custo do caminho de cada interface também pode ser atribuído manualmente para
suportar um meio de manipulação detalhada do custo do caminho stp. Esse método de manipulação de
custos de caminho deve ser usado com muito cuidado, já que os padrões de custo de caminho são
projetados para implementar a topologia de árvore de abrangência ideal para uma determinada rede de
comutação e a manipulação do custo de stp pode resultar na formação de uma árvore de abrangência
abaixo do ideal topologia.
O comando stp cost [cost] é usado, para o qual o valor de custo deve seguir o intervalo definido pelo
padrão de custo do caminho. Se um padrão herdado da Huawei for usado, o custo do caminho varia de
1 a 200.000. Se o padrão IEEE 802.1D for usado, o custo do caminho varia de 1 a 65535. Se o padrão IEEE
802.1t for usado, o custo do caminho varia de 1 para 200000000.

Proteção de Raiz
 Se o switch raiz em uma rede for configurado ou atacado incorretamente, ele poderá receber um
BPDU com uma prioridade mais alta e, assim, o switch raiz se tornará um switch não raiz, o que causará
uma alteração na topologia da rede. Como resultado, o tráfego pode ser alternado de links de alta
velocidade para links de baixa velocidade, causando congestionamento na rede.
Para resolver esse problema, o switch fornece a função de proteção de raiz. A função de proteção de
raiz protege o papel do switch raiz, mantendo a função da porta designada. Quando a porta recebe um
BPDU com uma prioridade mais alta, a porta pára de encaminhar pacotes e passa para o estado de
escuta, mas ainda retém uma função de porta designada. Se a porta não receber nenhum BPDU com
uma prioridade mais alta por um determinado período, o status da porta será restaurado a partir do
estado de escuta.
A proteção raiz configurada é válida somente quando a porta é a porta designada e a porta mantém a
função. Se uma porta estiver configurada como uma porta de borda ou se um comando conhecido como
proteção de loop estiver ativado na porta, a proteção de raiz não poderá ser ativada na porta.

Verifiação da Configuração
 Usando o comando display stp, a configuração atual do STP pode ser determinada. Existem vários
timers para gerenciar a convergência da árvore de abrangência, incluindo o timer de saudação, o timer
de duração máxima e o atraso de encaminhamento, para os quais os valores exibidos representam as
configurações padrão do timer e são recomendados para manutenção.
O ID da bridge atual pode ser identificado para um determinado switch através da configuração CIST
Bridge, composta pela ID da ponte e pelo endereço MAC do switch. As estatísticas fornecem
informações sobre se o switch sofreu alterações de topologia, principalmente por meio do valor
recebido de TC ou TCN, juntamente com a última ocorrência, conforme mostrado no tempo desde a
última entrada de TC.
Verifiação da Configuração
 Para interfaces individuais em um switch, é possível exibir essas informações através do comando
display stp para listar todas as interfaces, ou usando o comando display interface stp <interface> para
definir uma interface específica. O estado da interface segue os estados da porta MSTP e, portanto, será
exibido como Descartando, Aprendendo ou Encaminhando. Outras informações válidas, como a função
da porta e o custo da porta, também são exibidas, juntamente com os mecanismos de proteção
aplicados.

Resumo
1-No caso de uma bridge raiz (switch) falhar temporariamente na rede STP, o próximo switch viável
assumirá como a bridge raiz. O que ocorrerá quando a bridge raiz com falha voltar a ficar ativa na rede?
Após a falha da bridge raiz para uma rede de árvore de abrangência, o próximo melhor candidato
será eleito como a bridge raiz. No caso em que a ponte-raiz original se torne ativa novamente na rede, o
processo de eleição para a posição da ponte-raiz ocorrerá novamente. Isso efetivamente causa o tempo
de inatividade da rede na rede de comutação conforme a convergência prossegue.

2-Qual é a diferença entre Custo de Caminho e Custo do Caminho Raiz?

O Custo do Caminho Raiz é o custo associado ao caminho de volta à raiz, enquanto o Custo do
Caminho refere-se ao valor de custo definido para uma interface em um comutador, que é adicionado
ao Custo do Caminho Raiz, para definir o Custo do Caminho Raiz para o comutador a jusante.
 Prefácio
O padrão STP original foi definido em 1998, para o qual foram descobertas várias
limitações, particularmente no tempo necessário para a convergência ocorrer. Em vista
disso, o Rapid Spanning Tree Protocol (RSTP) foi introduzido. Entende-se que as
características fundamentais do RSTP seguem a base do STP, portanto, as diferenças
características encontradas no RSTP são enfatizadas nesta seção.
Objectivos
Após a conclusão desta seção, os formandos serão capazes de:
 Descreva as características associadas ao RSTP.
 Configure os parâmetros RSTP.
 Fraqueza STP

O STP garante uma rede sem loop, mas possui uma velocidade de convergência de topologia de rede
lenta, levando à deterioração do serviço. Se a topologia da rede mudar com freqüência, as conexões na
rede compatível com STP serão freqüentemente interrompidas, causando interrupção regular do
serviço.
O RSTP emprega um processo de proposta e acordo que permite a negociação imediata dos links,
eliminando efetivamente o tempo que os timers baseados na convergência vencem antes que a
convergência da árvore de abrangência possa ocorrer. O processo de proposta e concordância tende a
seguir um efeito em cascata do ponto da bridge raiz através da rede de comutação, à medida que cada
switch downstream começa a conhecer a verdadeira ponte-raiz e o caminho pelo qual a bridge-raiz
pode ser alcançada.
 Função de Porta no RSTP

Os comutadores que operam no modo RSTP implementam duas funções de porta separadas para
redundância. A porta alternativa representa um caminho redundante para a ponte raiz no caso de o
caminho atual para a ponte raiz falhar. A função de porta de backup representa um backup para o
caminho do segmento da LAN na direção que leva para longe da ponte raiz. Pode ser entendido que
uma porta de backup representa um método para fornecer redundância à função de porta designada de
uma maneira semelhante que uma porta alternativa fornece um método de redundância para a porta
raiz.
A função de porta de backup é capaz de existir onde um comutador tem duas ou mais conexões com
um dispositivo de mídia compartilhado, como um hub, ou onde um único link ponto-a-ponto é usado
para gerar uma conexão de loopback físico entre portas no mesmo interruptor. Em ambos os casos, no
entanto, o princípio de uma porta de backup existente onde duas ou mais portas em um único switch se
conectam a um único segmento de LAN ainda se aplica.

Portas de borda RSTP

No RSTP, uma porta designada na borda da rede é chamada de porta de borda. Uma porta de borda
se conecta diretamente a um terminal e não se conecta a nenhum outro dispositivo de comutação. Uma
porta de borda não recebe a configuração BPDU, portanto, não participa do cálculo do RSTP.
Ele pode mudar diretamente do estado Desativado para o estado de Encaminhamento sem qualquer
atraso, como uma porta incapaz de STP. Se uma porta de borda receber BPDU de configuração falsa de
invasores, ela será privada dos atributos de porta de borda e se tornará uma porta STP comum. O
cálculo de STP é implementado novamente, causando oscilação de rede.

Estados de Porta no RSTP

O RSTP introduz uma alteração nos estados de porta que são simplificados de cinco para três tipos.
Esses tipos de porta são baseados em se uma porta encaminha o tráfego do usuário e aprende os
endereços MAC. Se uma porta não encaminha o tráfego do usuário nem aprende os endereços MAC, a
porta está no estado Descartando. Considera-se que a porta está em um estado de aprendizado em que
uma porta não encaminha o tráfego do usuário, mas aprende os endereços MAC. Finalmente, quando
uma porta encaminha o tráfego do usuário e aprende os endereços MAC, a porta é considerada no
estado de encaminhamento.

RSTP BPDU

O formato BPDU empregado no STP também é aplicado ao RSTP com variância em alguns dos
parâmetros gerais. Para distinguir o BPDU de configuração de STP de BPDU de árvore de rápida
expansão, conhecido como RST BPDU, o tipo de BPDU é definido. O STP define uma configuração do
tipo BPDU de 0 (0x00) e um BPDU de Notificação de Alteração de Topologia (TCN BPDU) de 128 (0x80),
RST BPDU são identificados pelo valor do tipo BPDU 2 (0x02). Dentro do campo de flags do BPDU RST,
designações de parâmetros adicionais são atribuídas aos campos BPDU.
O campo de sinalizadores no STP implementou apenas o uso dos parâmetros de Alteração de
Topologia (TC) e Reconhecimento (TCA) como parte do processo de Mudança de Topologia enquanto
outros campos foram reservados. O BPDU RST adotou esses campos para suportar novos parâmetros.
Estes incluem sinalizadores indicando o processo de proposta e acordo empregado pelo RSTP para
convergência rápida, a definição da função de porta e o estado da porta.

RST BPDU

No STP, depois que a topologia se torna estável, a bridge raiz envia a configuração BPDU em um
intervalo definido pelo Hello timer. Uma ponte não-raiz não envia a configuração BPDU até receber a
configuração BPDU enviada do dispositivo upstream. Isso torna o cálculo do STP complicado e
demorado. No RSTP, depois que a topologia se torna estável, uma ponte não-raiz envia BPDU de
configuração em intervalos Hello, independentemente de ter recebido a configuração BPDU enviada da
bridge raiz; tais operações são implementadas em cada dispositivo de forma independente.
 Convergência RSTP

A convergência do RSTP segue alguns dos princípios básicos do STP ao determinar inicialmente que
todos os switches durante a inicialização asseveram o papel de bridge raiz e, como tal, atribuem cada
interface de porta a uma função de porta designada. No entanto, o estado da porta é definido para um
estado de descarte até que os comutadores de peering consigam confirmar o estado do link.

Proposta BPDU RST

Cada switch que proclama ser a bridge raiz negociará os estados de porta para um determinado
segmento de LAN, gerando um BPDU de RST com o bit de proposta definido no campo de flags. Quando
uma porta recebe um RST BPDU da ponte designada a montante, a porta compara o RST BPDU recebido
com o seu próprio RST BPDU. Se seu próprio BPDU de RST for superior ao recebido, a porta descartará o
BPDU de RST recebido e responderá imediatamente ao dispositivo de peering com seu próprio BPDU de
RST que inclui um bit de proposta de conjunto.
 Processo de Sincronização RSTP

Como os timers não desempenham um papel importante em grande parte do processo de

convergência da topologia RSTP, conforme encontrado com o STP, é importante que o potencial de
troca de loops durante a negociação da função portuária seja restrito. Isso é gerenciado pela
implementação de um processo de sincronização que determina que, após o recebimento de um BPDU
superior contendo o bit da proposta, a central receptora deve definir todas as portas designadas
downstream como descartáveis como parte do processo de sincronização.
Onde a porta downstream é uma porta alternativa ou uma porta de borda, no entanto, o status da
função de porta permanece inalterado. O exemplo demonstra a transição temporária da porta
designada no segmento de LAN downstream para um estado de descarte e, portanto, bloqueando
qualquer encaminhamento de quadro durante o processo de proposta e contrato upstream.

Contrato BPDU RST

 A transição confirmada da porta designada a jusante para um estado de descarte permite que um
BPDU de RST seja enviado em resposta à proposta enviada pelo comutador a montante. Durante esse
estágio, a função de porta da interface foi determinada como a porta raiz e, portanto, o sinalizador de
acordo e a função de porta da raiz são configurados no campo de sinalizadores do BPDU de RST que é
retornado em resposta à proposta.

Link Convergente RSTP

Durante o estágio final do processo de proposta e acordo, o BPDU do RST contendo o bit de
concordância é recebido pelo comutador upstream, permitindo que a porta designada faça a transição
imediatamente de um estado de descarte para o estado de encaminhamento. Em seguida, o (s)
segmento (s) de LAN a jusante começará a negociar as funções de porta das interfaces usando o mesmo
processo de proposta e acordo.

Falha de link / raiz

No STP, um dispositivo tem que esperar um período Max Age antes de determinar uma falha de
negociação. No RSTP, se uma porta não receber BPDUs de configuração enviados do dispositivo
upstream por três intervalos Hello consecutivos, a comunicação entre o dispositivo local e seu par
falhará, fazendo com que o processo de proposta e acordo seja inicializado para descobrir as funções de
porta para o segmento de LAN.
 Processo de alteração de topologia

Mudanças de topologia afetam o RSTP da mesma forma que o STP é afetado, no entanto, existem
algumas pequenas diferenças entre os dois. No exemplo, uma falha do link ocorreu no switch C. O
switch A e o switch C detectarão a falha do link imediatamente e liberarão as entradas de endereço para
as portas conectadas a esse link. Um BPDU do RST começará a negociar os estados do porto como parte
do processo de proposta e acordo, após o qual uma notificação de Mudança de Topologia ocorrerá,
juntamente com o encaminhamento do BPDU do RST contendo o contrato.
Este BPDU RST terá tanto o bit Agreement como o bit TC definido como 1, para informar os switches
upstream da necessidade de liberar suas entradas MAC em todas as interfaces de porta, exceto a
interface de porta na qual o BPDU RST contendo o bit TC definido foi recebido .
O bit TC será definido no RST BPDU enviado periodicamente e encaminhado para upstream por um
período equivalente a Hello Time + 1 segundo, durante o qual todas as interfaces relevantes serão
liberadas e deverá proceder ao repovoamento de entradas MAC com base na nova topologia RSTP . O
vermelho (mais escuro) "x" no exemplo realça quais interfaces serão liberadas como resultado da
alteração da topologia.
 Interpolação STP

A implementação de STP dentro de uma topologia de comutação baseada em RSTP é possível, no

entanto, não é recomendada, uma vez que qualquer limitação pertencente a STP se torna aparente
dentro do intervalo de comunicação do comutador habilitado para STP. Um porto envolvido no processo
de negociação para estabelecer sua função dentro do STP deve esperar por um período de até 50
segundos antes que a convergência possa ser concluída, de modo que os benefícios do RSTP sejam
perdidos.

Configurando o Modo

A configuração do modo de árvore de abrangência dos comutadores Sx7 requer que o comando do
modo stp seja usado para definir o modo como RSTP. Ao fazer isso, o switch da série Sx7 gerará o BPDU
de RST em relação ao RSTP, em oposição a outras implementações de árvore de abrangência. Esse
comando é configurado a partir da visualização do sistema e deve ser aplicado a todos os comutadores
que participam da topologia da árvore de abrangência rápida.
 Validação de Configuração

O comando display stp fornecerá informações relativas à configuração do RSTP, já que muitos dos
parâmetros seguem a arquitetura principal do STP. A informação do modo determinará se um
comutador está operando atualmente usando o RSTP.

Configurando a porta de borda

Uma interface de borda define uma porta que não participa da topologia da árvore de abrangência.
Essas interfaces são usadas pelos sistemas finais para conectar-se à rede de comutação para o propósito
de encaminhar quadros. Como esses sistemas finais não precisam negociar o status da interface de
porta, é preferível que a porta seja transferida diretamente para um estado de encaminhamento para
permitir que os quadros sejam encaminhados sobre essa interface imediatamente.
 O comando stp edged-port enable é usado para alternar uma porta para se tornar uma porta de
borda, já que todas as portas são consideradas portas sem borda em um switch por padrão. Para
desabilitar a porta de borda, o comando disable stp edged-port é usado. Esses comandos se aplicam
apenas a uma interface de porta única em um determinado switch. É importante observar que o
comportamento da porta de borda está associado ao RSTP conforme definido na documentação de
padrões IEEE 802.1D-2004, porém devido à aplicação específica de VRP da máquina de estado RSTP
subjacente ao STP (que também resulta nos estados de porta RSTP) presente no STP), também é
possível aplicar as configurações da porta de borda do RSTP ao STP dentro dos produtos da série Huawei
Sx7.

No caso de várias portas em um switch serem configuradas como portas de borda, o comando
padrão stp-edge-port é aplicado, o que impõe que todas as interfaces de porta em um switch se tornem
portas de borda. É importante executar o comando disable stp-edged-port nas portas que precisam
participar do cálculo do STP entre os dispositivos, para evitar possíveis loops que possam ser causados
como resultado dos cálculos de topologia do STP.

Proteção BPDU
 A porta que está diretamente conectada a um terminal de usuário, como um PC ou um servidor de
arquivos, é configurada como uma porta de borda para garantir a rápida transição do status da porta.
Geralmente, nenhum BPDU é enviado para as portas de borda, no entanto, se o switch for atacado pelo
pseudo BPDU, o switch definirá as portas de borda como portas sem borda. Depois que essas portas de
borda receberem um BPDU, a topologia da árvore de abrangência será recalculada e, como resultado,
ocorrerá um flapping de rede.
Para se defender contra ataques pseudo-BPDU, o RSTP fornece proteção BPDU. Depois que a
proteção BPDU é ativada, o switch desliga a porta de borda que recebe BPDU e informa qualquer
estação de gerenciamento de rede (NMS) ativa. As portas de borda que são desligadas pelo switch
podem ser iniciadas manualmente apenas pelo administrador da rede. O comando stp bpdu-protection
deve ser usado para ativar a proteção de BPDU e é configurado globalmente dentro da visualização do
sistema.

Proteção de Loop

O switch mantém o status da porta raiz e das portas bloqueadas, recebendo continuamente o BPDU
do switch upstream. Se o comutador raiz não puder receber o BPDU a partir do comutador upstream
devido ao congestionamento de link ou falha de link unidirecional, o comutador selecionará novamente
uma porta raiz. A porta raiz anterior torna-se então uma porta designada e as portas bloqueadas
mudam para o estado de encaminhamento. Como resultado, loops podem ocorrer na rede.
O switch fornece proteção de loop para evitar loops de rede. Depois que a função de proteção de
loop estiver ativada, a porta raiz será bloqueada se não puder receber o BPDU a partir do switch
upstream. A porta bloqueada permanece no estado bloqueado e não encaminha pacotes. Isso evita
loops na rede. Se uma interface estiver configurada como uma interface de borda ou a proteção de raiz
estiver ativada na interface, a proteção de loop não poderá ser ativada na interface. O comando stp
loop-protection deve ser aplicado para ativar esse recurso na visualização da interface.
 Validação de Configuração

A validação da configuração RSTP para uma determinada interface é obtida através do comando
display interface stp <interface>. As informações associadas identificarão o estado da porta da interface
como Descartando, Aprendendo ou Encaminhando. Informações relevantes para a interface de porta,
incluindo a prioridade da porta, o custo da porta, o status da porta como uma porta de borda ou
suporte ponto-a-ponto, etc, são definidas.

Resumo
1-Qual é o propósito da sincronização que ocorre durante a proposta do RSTP e o processo
de acordo?
O sincronismo é um estágio no processo de convergência que envolve o bloqueio de portas
designadas enquanto o BPDU de RST é transmitido contendo mensagens de proposta e acordo para
convergir o segmento de comutador. O processo é projetado para garantir que todas as interfaces
estejam de acordo com suas funções de porta, a fim de garantir que não ocorram loops de comutação
quando a porta designada para qualquer comutador de recebimento de dados for desbloqueada.
 Prefácio
O encaminhamento de quadros e comutação introduziu as operações da camada de enlace de
dados e, em particular, o papel dos padrões baseados em IEEE 802 como o mecanismo subjacente de
comunicação subjacente, sobre o qual as suítes de protocolo de camada superior geralmente operam.
Com a introdução do roteamento, a física que define os protocolos da camada superior e a comunicação
entre redes é estabelecida. Geralmente, um domínio de rede da empresa consiste em várias redes para
as quais são necessárias decisões de roteamento para garantir que as rotas ideais sejam usadas, a fim de
encaminhar pacotes IP (ou datagramas) para os destinos de rede pretendidos. Esta seção apresenta as
bases nas quais o roteamento IP é baseado.

Objectivos
Após a conclusão desta seção, os formandos serão capazes de:
 Explicar os princípios que controlam as decisões de roteamento IP.
 Explicar os requisitos básicos para o encaminhamento de pacotes.
 Sistemas autônomos

Uma rede corporativa geralmente pode ser entendida como uma instância de um sistema autônomo.
Conforme definido no RFC 1030, um sistema autônomo ou AS, como também é comumente conhecido,
é um grupo conectado de um ou mais prefixos IP executados por um ou mais operadores de rede que
possuem uma política de roteamento SINGLE e DEFINIDA CLARAMENTE.
O conceito de sistemas autônomos originalmente considerava a existência de um único protocolo de
roteamento. No entanto, à medida que as redes evoluíram, é possível suportar múltiplos protocolos de
roteamento que interagem através da injeção de rotas de um protocolo para outro. Uma política de
roteamento pode ser entendida como um conjunto de regras que determinam como o tráfego é
gerenciado dentro de um sistema autônomo, ao qual um único ou múltiplos operadores devem aderir.
 Rede local e domínios de broadcast

Os princípios que envolvem a mudança têm lidado principalmente com o encaminhamento de

tráfego dentro do escopo de uma rede local e o gateway, que até agora definiu o limite do domínio de
broadcast. Os roteadores são a forma principal do dispositivo de camada de rede usado para definir o
gateway de cada rede local e ativar a segmentação de rede IP. Os roteadores geralmente funcionam
como um meio de rotear pacotes de uma rede local para a próxima, confiando no endereçamento IP
para definir a rede IP à qual os pacotes são destinados.

Decisões de roteamento

O roteador é responsável por determinar o caminho de encaminhamento através do qual os pacotes

devem ser enviados a rota para um determinado destino. É da responsabilidade de cada roteador tomar
decisões sobre como os dados são encaminhados. Quando um roteador tem vários caminhos para um
determinado destino, as decisões de rota baseadas em cálculos são feitas para determinar o melhor
próximo salto para o destino pretendido. As decisões que governam a rota que deve ser tomada podem
variar dependendo do protocolo de roteamento em uso, confiando em métricas de cada protocolo para
tomar decisões em relação a fatores variáveis, como largura de banda e contagem de saltos.

Tabela de Roteamento IP

Os roteadores encaminham pacotes com base em tabelas de roteamento e uma base de informações
de encaminhamento (FIB) e mantêm pelo menos uma tabela de roteamento e uma FIB. Os roteadores
selecionam rotas com base em tabelas de roteamento e encaminham pacotes com base no FIB. Um
roteador usa uma tabela de roteamento local para armazenar rotas de protocolo e rotas preferenciais.
O roteador envia as rotas preferidas para o FIB para guiar o encaminhamento de pacotes. O roteador
seleciona rotas de acordo com as prioridades de protocolos e custos armazenados na tabela de
roteamento. Uma tabela de roteamento contém dados importantes para cada pacote IP.
O destino e a máscara são usados em combinação para identificar o endereço IP de destino ou o
segmento de rede de destino em que reside o host ou roteador de destino. O campo do protocolo
(Proto) indica o protocolo através do qual as rotas são aprendidas. A preferência (Pre) especifica o valor
de preferência associado ao protocolo e é usado para decidir qual protocolo é aplicado à tabela de
roteamento em que dois protocolos oferecem rotas semelhantes. O roteador seleciona a rota com a
maior preferência (o menor valor) como a rota ideal.
Um valor de custo representa a métrica usada para distinguir quando várias rotas para o mesmo
destino têm a mesma preferência, a rota com o menor custo é selecionada como a rota ideal. Um valor
de próximo salto indica o endereço IP do próximo dispositivo ou gateway da camada de rede pelo qual
passa um pacote IP. No exemplo dado um próximo salto de 127.0.0.1 refere-se à interface local do
dispositivo como sendo o próximo salto. Finalmente, o parâmetro interface indica a interface de saída
através da qual um pacote IP é encaminhado.
 Decisões de roteamento - correspondência mais longa

Para
permitir que os pacotes cheguem ao destino pretendido, os roteadores devem tomar decisões
específicas sobre as rotas aprendidas e quais dessas rotas são aplicadas. É provável que um roteador
aprenda sobre o caminho para um determinado destino de rede por meio de informações de
roteamento anunciadas a partir de roteadores vizinhos; alternativamente, é possível que as rotas
aplicadas estaticamente sejam implementadas manualmente por meio da intervenção do
administrador.
Cada entrada na tabela FIB contém a interface física ou lógica pela qual um pacote é enviado para
alcançar o próximo roteador. Uma entrada também indica se o pacote pode ser enviado diretamente
para um host de destino em uma rede diretamente conectada. O roteador executa uma operação
"AND" no endereço de destino no pacote e na máscara de rede de cada entrada na tabela FIB.
O roteador compara o resultado da operação "AND" com as entradas na tabela FIB para encontrar
uma correspondência. O roteador escolhe a rota ideal para encaminhar pacotes de acordo com a
melhor ou "mais longa" correspondência. No exemplo, existem duas entradas para a rede 10.1.1.0 com
um próximo salto de 20.1.1.2. O encaminhamento para o destino de 10.1.1.1 resultará na aplicação do
maior princípio de correspondência, para o qual o endereço de rede 10.1.1.0/30 fornece a
correspondência mais longa.
 Decisões de roteamento – preferência

Uma tabela de roteamento pode conter as rotas originadas de vários protocolos para um
determinado destino. Nem todos os protocolos de roteamento são considerados iguais, e onde a
correspondência mais longa para várias rotas de protocolos de roteamento diferentes para o mesmo
destino é igual, uma decisão deve ser tomada em relação a qual protocolo de roteamento (incluindo
rotas estáticas) terá precedência.
Somente um protocolo de roteamento determina a rota ideal para um destino. Para selecionar a rota
ideal, cada protocolo de roteamento (incluindo a rota estática) é configurado com uma preferência
(quanto menor o valor, maior a preferência). Quando várias fontes de informações de roteamento
coexistem, a rota com a preferência mais alta é selecionada como a rota ideal e adicionada à tabela de
roteamento local.
No exemplo, dois protocolos são definidos que fornecem um meio de descoberta da rede 10.1.1.0
por meio de dois caminhos diferentes. O caminho definido pelo protocolo RIP parece fornecer uma rota
mais direta para o destino pretendido, no entanto, devido ao valor de preferência, a rota definida pelo
protocolo OSPF é preferida e, portanto, instalada na tabela de roteamento como a rota preferencial. Um
resumo dos valores de preferência padrão de alguns mecanismos de roteamento comuns é fornecido
para fornecer uma compreensão da ordem de preferência padrão.
 Decisões de roteamento – métrica

Quando a rota não pode ser distinguida por um valor de correspondência mais longo ou preferência,
a métrica de custo é tomada como o tomador de decisão na identificação da rota que deve ser instalada
na tabela de roteamento. Custo representa o comprimento de um caminho para uma rede de destino.
Cada segmento fornece um valor de métrica de custo ao longo de um caminho que é combinado para
identificar o custo da rota. Outro fator comum é a largura de banda da rede, na qual o mecanismo de
custo às vezes é baseado. Um link com uma velocidade mais alta (capacidade) representa um valor de
custo mais baixo, permitindo que a preferência de um caminho sobre outro seja feita, enquanto os links
de velocidade igual recebem um custo balanceado para fins de balanceamento de carga eficiente. Uma
métrica mais baixa sempre terá precedência e, portanto, a métrica de 50, conforme mostrado no
exemplo, define a rota ideal para o destino determinado para o qual uma entrada pode ser encontrada
na tabela de roteamento.
 Requisitos de encaminhamento de tabela de roteamento

A capacidade de um roteador para encaminhar um pacote IP para um determinado destino requer

que certas informações de encaminhamento sejam conhecidas. Qualquer roteador que deseje
encaminhar um pacote IP deve, primeiramente, estar ciente de um endereço de destino válido para o
qual o pacote será encaminhado, isso significa que deve existir uma entrada na tabela de roteamento
que o roteador possa consultar. Essa entrada também deve identificar a interface através da qual os
pacotes IP devem ser transmitidos e o próximo salto ao longo do caminho, para o qual o pacote deve ser
recebido antes da consulta para a próxima decisão de encaminhamento ser executada.

Resumo
1-Qual é a ordem na qual as decisões de roteamento são tomadas?
As decisões de roteamento são tomadas inicialmente com base no maior valor de correspondência,
independentemente do valor de preferência atribuído às rotas para a mesma rede. Se o maior valor de
correspondência para duas rotas para o mesmo destino é igual, a preferência deve ser usada, onde a
preferência também é igual, a métrica deve ser usada. Nos casos em que o valor da métrica também é o
mesmo, os protocolos geralmente aplicam uma forma de balanceamento de carga de dados sobre os
links de custo igual.

2-O que a preferência representa?

A preferência é normalmente usada para denotar a confiabilidade de uma rota em rotas que podem
ser consideradas menos confiáveis. Os fornecedores de equipamento de roteamento podem, no
entanto, atribuir diferentes valores de preferência para protocolos suportados dentro do próprio
produto de cada fornecedor. Os valores de preferência de alguns protocolos comuns de roteamento
suportados pelos dispositivos de roteamento da Huawei podem ser encontrados nesta seção.
 Prefácio
A implementação de rotas dentro da tabela de roteamento IP de um roteador pode ser definida
manualmente usando rotas estáticas ou através do uso de protocolos de roteamento dinâmico. A
configuração manual de rotas permite o controle direto da tabela de roteamento, mas pode resultar em
falha na rota caso o próximo salto do roteador falhe. No entanto, a configuração de rotas estáticas é
frequentemente usada para complementar os protocolos de roteamento dinâmico para fornecer rotas
alternativas no caso de rotas descobertas dinamicamente falharem ao fornecer um próximo salto válido.
O conhecimento das várias aplicações de rotas estáticas e configuração é necessário para uma
administração de rede efetiva.

Objectivos
Após a conclusão desta seção, os formandos serão capazes de:
 Explicar os diferentes aplicativos para rotas estáticas.
 Configurar com sucesso rotas estáticas na tabela de roteamento IP.
 Aplicativo para rota estática

Uma rota estática é uma rota especial que é configurada manualmente por um administrador de
rede. A desvantagem das rotas estáticas é que elas não podem se adaptar à mudança em uma rede
automaticamente, portanto, as mudanças na rede exigem uma reconfiguração manual. Rotas estáticas
são adequadas para redes com estruturas comparativamente simples. Não é aconselhável configurar e
manter rotas estáticas para uma rede com uma estrutura complexa. As rotas estáticas, no entanto,
reduzem o efeito da largura de banda e do consumo de recursos da CPU que ocorre quando outros
protocolos são implementados.
 Comportamento de rota estática

As rotas estáticas podem ser aplicadas a redes que usam mídia serial e Ethernet, no entanto, em cada
situação, as condições de aplicação da rota estática variam nas quais a interface de saída ou o endereço
IP do próximo salto deve ser definido.
O meio serial representa uma forma de interface ponto-a-ponto (P2P) para a qual a interface de saída
deve ser configurada. Para uma interface P2P, o endereço do próximo salto é especificado após a
interface de saída ser especificada. Ou seja, o endereço da interface remota (interface no dispositivo de
mesmo nível) conectada a essa interface é o endereço do próximo salto.
Por exemplo, o protocolo usado para encapsular no meio serial é o protocolo ponto a ponto (PPP). O
endereço IP remoto é obtido após a negociação PPP, portanto, é necessário especificar apenas a
interface de saída. O exemplo também define uma forma de conexão Ethernet ponto-a-ponto, no
entanto, a Ethernet representa uma tecnologia de transmissão por natureza e, portanto, os princípios
da tecnologia ponto a ponto não se aplicam.

Comportamento da Rota Estática

 No caso de interfaces de transmissão, como Ethernet, o próximo salto deve ser definido. Onde a
interface Ethernet é especificada como a interface de saída, vários saltos próximos provavelmente
existirão e o sistema não poderá decidir qual próximo salto deve ser usado. Ao determinar o próximo
salto, um roteador é capaz de identificar a conexão local pela qual o pacote deve ser recebido.
No exemplo, os pacotes destinados ao destino 192.168.2.0/24 devem ser encaminhados para o
próximo salto de 10.0.123.2 para garantir a entrega. Como alternativa, alcançar o destino de
192.168.3.0 requer que o próximo salto de 10.0.123.3 seja definido.

Configurando uma rota estática

A configuração da rota estática é obtida usando o ip-static ip-address route {mask | mask-length}
interface-tipo interface-número [nexthop-address] onde o endereço IP se refere ao endereço de destino
da rede ou do host. O campo de máscara pode ser definido como um valor de máscara ou baseado no
número do prefixo. No caso de um meio de transmissão, como Ethernet, o endereço do próximo salto é
usado. Quando uma mídia serial é usada, o tipo de interface e o número da interface são atribuídos (por
exemplo, serial 1/0/0) ao comando para definir a interface de saída.

Balanceamento de carga de rota estática

 Onde existem caminhos de custo igual entre as redes de origem e de destino, o balanceamento de
carga pode ser implementado para permitir que o tráfego seja transportado pelos dois links. Para
conseguir isso usando rotas estáticas, ambas as rotas devem atender aos parâmetros para uma
correspondência, valor de preferência e métrica iguais e mais longos. A configuração de várias rotas
estáticas, uma para cada interface de próximo salto ou saída, no caso de mídia serial, é necessária.
O exemplo demonstra como dois comandos ip route-static são implementados, cada um definindo o
mesmo endereço e máscara de destino IP, mas alternando locais de próximo salto. Isso garante que a
correspondência mais longa (/ 24) seja igual e, naturalmente, o valor de preferência, já que ambas as
rotas são estáticas e têm uma preferência padrão de 60. O custo de ambos os caminhos também é igual
ao balanceamento de carga.

Verificando o balanceamento de carga de rota estática

A tabela de roteamento pode ser consultada para verificar os resultados executando o comando
display ip routing-table após as rotas estáticas serem configuradas. A rota estática é exibida na tabela de
roteamento e os resultados mostram duas entradas para o mesmo destino, com valores
correspondentes de preferência e métrica. Os diferentes endereços do próximo salto e a variação na
interface de saída identificam os dois caminhos tomados e confirmam que o balanceamento de carga foi
alcançado.

Rotas Estáticas Flutuantes

 A aplicação de rotas estáticas permite várias maneiras pelas quais as rotas podem ser manipuladas
para atingir os requisitos de roteamento. É possível alterar a preferência de uma rota estática com a
finalidade de permitir a preferência de uma rota estática sobre outra ou, quando usada com outros
protocolos, para garantir que a rota estática seja preferencial ou a preferência seja dada à rota
alternativa protocolo.
O valor de preferência padrão de uma rota estática é 60, portanto, ajustando esse valor de
preferência, uma determinada rota estática pode ser tratada com preferência desigual sobre qualquer
outra rota, incluindo outras rotas estáticas. No exemplo dado, existem duas rotas estáticas em dois
segmentos de LAN físicos, enquanto normalmente ambas as rotas estáticas seriam consideradas iguais,
a segunda rota recebeu uma menor preferência (maior valor) fazendo com que ela seja removida da
tabela de roteamento. O princípio de uma rota estática flutuante significa que a rota com menor
preferência será aplicada à tabela de roteamento, caso a rota principal falhe.

Verificação da rota estática flutuante

Ao usar o comando display ip routing-table, é possível observar os resultados da alteração no valor

de preferência que resulta na rota estática flutuante. Normalmente, duas rotas de custo iguais seriam
exibidas na tabela de roteamento, definindo o mesmo destino, porém com valores alternativos de
próximo salto e interfaces de saída. Nesse caso, no entanto, apenas uma instância pode ser vista,
contendo o valor de preferência de rota estática padrão de 60. Como a segunda rota estática agora tem
um valor de preferência de 100, ela não é imediatamente incluída na tabela de roteamento, pois não é
mais considerada uma rota ótima.
 No caso em que a rota estática primária deve falhar como resultado de falha no link físico ou através
da desativação de uma interface, a rota estática não poderá mais fornecer uma rota para o destino
pretendido e, portanto, será removida da tabela de roteamento . A rota estática flutuante
provavelmente se tornará a próxima melhor opção para alcançar o destino pretendido e será adicionada
à tabela de roteamento para permitir que os pacotes sejam transmitidos por um segundo caminho
alternativo para o destino pretendido, permitindo a continuidade à luz de qualquer falha.
Quando a conexão física para a rota original for restaurada, a rota estática original também assumirá
a rota estática flutuante atual, para a qual a rota será restaurada na tabela de roteamento, fazendo com
que a rota estática flutuante espere novamente o aplicativo.

Rotas Estáticas Padrão

A rota estática padrão é uma forma especial de rota estática que é aplicada a redes nas quais o
endereço de destino é desconhecido, a fim de permitir que um caminho de encaminhamento seja
disponibilizado. Isso fornece um meio eficaz de rotear o tráfego de um destino desconhecido para um
roteador ou gateway que possa ter conhecimento do caminho de encaminhamento em uma rede
corporativa.
A rota padrão depende do endereço "qualquer rede" de 0.0.0.0 para corresponder a qualquer rede
na qual não foi possível encontrar uma correspondência na tabela de roteamento e fornece um caminho
de encaminhamento padrão para o qual os pacotes de todos os destinos de rede desconhecidos devem
ser roteados. No exemplo, uma rota estática padrão foi implementada no RTA, identificando que
pacotes devem ser enviados para o destino 10.0.12.2.
Em termos de tomada de decisão da tabela de roteamento, como rota estática, a rota padrão
mantém uma preferência de 60 por padrão, mas opera como último recurso em termos da regra de
correspondência mais longa no processo de correspondência de rota.

Verificação de rota estática padrão

A configuração da rota estática, uma vez configurada, aparecerá na tabela de roteamento do

roteador. O comando display ip routing-table é usado para visualizar este detalhe. Como resultado,
todas as rotas no exemplo, quando não associadas a outras rotas na tabela de roteamento, serão
encaminhadas para o destino do próximo salto de 10.0.12.2 através da interface Gigabit Ethernet 0/0/0.

Resumo
1-O que deve ser alterado para permitir que uma rota estática se torne uma rota estática flutuante?
Uma rota estática flutuante pode ser implementada ajustando o valor de preferência de uma rota
estática em que duas rotas estáticas suportam o balanceamento de carga.
 2-Qual endereço de rede deve ser definido para permitir que uma rota estática padrão seja
implementada na tabela de roteamento?
Uma rota estática padrão pode ser implementada na tabela de roteamento, especificando o
endereço 'any network' de 0.0.0.0 como o endereço de destino junto com um endereço de próximo
salto da interface para a qual os pacotes capturados por esta rota estática padrão devem ser
encaminhados.

Prefácio
Os protocolos de roteamento de vetor de distância são uma forma de protocolo de roteamento
dinâmico que funciona com base no princípio do algoritmo de Bellman-Ford para definir a rota que os
pacotes devem seguir para alcançar outros destinos da rede. A aplicação do Routing Information
Protocol (RIP) é frequentemente aplicada em muitas redes pequenas e, portanto, permanece um
protocolo válido e popular, embora o próprio protocolo tenha existido por muito mais tempo do que
outros protocolos de roteamento dinâmico em uso atualmente. As características de tais protocolos de
vetor de distância são representadas nesta seção através do Protocolo de Informações de Roteamento.

Objectivos
Após a conclusão desta seção, os formandos serão capazes de:
 Descrever o comportamento do protocolo de informações de roteamento.
 Configurar com êxito o roteamento RIP e os atributos associados.
 Protocolo de Informação de Roteamento(RIP)

O protocolo de informações de roteamento ou RIP, como é comumente conhecido, representa uma

das formas mais simples de protocolo de roteamento aplicadas às redes corporativas. O RIP funciona
como um protocolo de gateway interno (IGP) baseado nos princípios do algoritmo de Bellman-Ford que
opera com base no vetor de distância, definindo o caminho que o tráfego deve seguir em relação à
distância ótima medida usando um valor métrico fixo .
 O protocolo RIP contém um número mínimo de parâmetros e requer largura de banda, configuração
e tempo de gerenciamento limitados, tornando-o ideal para redes menores. No entanto, o RIP não foi
projetado com a capacidade de manipular sub-redes, suporta a interação com outros protocolos de
roteamento e não fornece nenhum meio de autenticação, já que sua criação antecedeu o período em
que esses princípios foram introduzidos.

Princípio de comportamento

Os roteadores habilitados para RIP participam do anúncio de informações de roteamento para

roteadores vizinhos. São gerados anúncios de rota que contêm informações sobre as redes conhecidas
pelo roteador de envio e a distância para alcançá-las. Os roteadores habilitados para RIP anunciam uns
aos outros, mas quando anunciam, eles carregam apenas as melhores informações de roteamento em
seus anúncios de rota.

Métricas

Cada anúncio de roteador contém várias rotas, cada uma associada a uma determinada métrica. A
métrica é usada para determinar a distância entre um roteador e o destino ao qual o anúncio de rota
está associado. No RIP, a métrica é associada a um mecanismo de contagem de saltos, em que cada
salto entre roteadores representa uma contagem de saltos fixos, geralmente de um. Essa métrica não
leva em consideração nenhum outro fator, como a largura de banda de cada link ou qualquer atraso que
possa ser imposto ao link. No exemplo, o roteador RTB aprende de uma rede por meio de duas
interfaces diferentes, cada uma fornecendo uma métrica de salto através da qual a melhor rota para o
destino pode ser descoberta.

Loops de Roteamento e Limites de Hop

Como cada roteador processa um anúncio de rota, o valor da métrica é incrementado antes de
encaminhar o anúncio para o roteador vizinho. Onde as rotas se tornam inacessíveis, no entanto, existe
um potencial para ocorrências que resulta na contagem de saltos se tornando infinita.
Para resolver o problema com infinitas métricas de rota, foi definido um valor que representaria
infinito que permitia que o número de saltos possíveis fosse restrito a um limite de 15 saltos. Essa
métrica pressupõe um tamanho de rede considerado adequado para acomodar o tamanho das redes
para as quais o protocolo de roteamento RIP é adequado e também além da escala que se espera que
seja esperada para qualquer rede desse tipo.
Uma contagem de saltos de 16 presumiria que a rota estava inacessível e faria com que o status da
rede de determinada rede fosse alterado de acordo. Loops de roteamento podem ocorrer através de
um roteador enviando pacotes para si mesmo, entre roteadores de peering ou como resultado do fluxo
de tráfego entre vários roteadores.

Formação de Loop
 O exemplo demonstra como um loop pode potencialmente formar onde o RIP é o protocolo de
roteamento. Uma rede (10.0.0.0/8) foi aprendida através do envio de anúncios de rota do RTA para o
RTC, para o qual o RTC atualizará sua tabela de roteamento com a rede e a métrica de 1, para chegar ao
destino.
Em caso de falha na conexão entre o roteador RTA e a rede à qual ele está diretamente conectado, o
roteador detectará imediatamente a perda da rota e considerará a rota inacessível. Como o RTC possui
conhecimento da rede, um anúncio de rota é encaminhado contendo informações sobre a rede
10.0.0.0/8. Após a recepção deste, RTA vai aprender de uma nova entrada de rota para 10.0.0.0/8 com
uma métrica de 2. Desde RTC originalmente aprendeu a rota do RTA, qualquer alteração precisará ser
atualizado em RTC também, com um anúncio de rota sendo enviado para RTC com uma métrica de 3.
Isso será repetido por um período infinito de tempo. Uma métrica de 16 permite que um limite seja
colocado no infinito, permitindo assim que qualquer rota que atinja uma contagem de saltos de 16 seja
considerada inalcançável.

Prevenção de Loop -Split Horizon

Os mecanismos foram implementados como parte do protocolo de roteamento RIP para tratar dos
problemas do loop de roteamento que ocorrem quando as rotas se tornam inacessíveis. Um desses
mecanismos é conhecido como split horizon e opera com base no princípio de que uma rota que é
aprendida em uma interface não pode ser anunciada de volta nessa mesma interface. Isso significa que
a rede 10.0.0.0/8 anunciada para o roteador RTC não pode ser anunciada de volta ao RTA sobre a
mesma interface, no entanto, será anunciada para os vizinhos conectados por meio de todas as outras
interfaces.
 Prevenção de Loop -Poisoned Reverse

A implementação do mecanismo de inversão de envenenamento permite que a velocidade na qual as

rotas erradas sejam aumentadas para quase instantaneamente, como resultado de permitir que as rotas
sejam retornadas ao roteador de origem, contendo uma métrica de 16, para uma rota melhor, onde a
rota se torna inválida.
No exemplo, o RTA anuncia uma métrica de 1 para a rede ao RTC, enquanto o RTC anuncia a mesma
rede ao RTA para garantir que, se a rede 10.0.0.0/8 falhar, o RTA não descobrirá um caminho melhor
para essa rede por meio de qualquer outro roteador. Isso envolve, no entanto, um aumento no
tamanho da mensagem de roteamento RIP, já que as rotas contendo as informações de rede recebidas
agora também devem levar a atualização de rede, considerando a rota inacessível, de volta ao roteador
vizinho do qual o anúncio foi originado. Nos roteadores da série AR2200 da Huawei, split horizon e
poisoned reverse não podem ser aplicados ao mesmo tempo, se ambos estiverem configurados,
somente o reverso envenenado será ativado.
Prevenção de Loop -Triggered Updates

O comportamento padrão do RIP envolve atualizações da tabela de roteamento sendo enviadas

periodicamente aos vizinhos como um anúncio de rota, que por padrão é configurado para ocorrer
aproximadamente a cada 30 segundos. No entanto, quando os links falham, também é necessário que
esse período expire antes de informar os roteadores vizinhos da falha.
 As atualizações acionadas ocorrem quando as informações de roteamento locais são alteradas e o
roteador local notifica imediatamente seus vizinhos sobre as alterações nas informações de roteamento,
enviando o pacote de atualização acionado. Atualizações acionadas diminuem o tempo de convergência
da rede. Quando as informações de roteamento locais são alteradas, o roteador local notifica
imediatamente seus vizinhos sobre as alterações nas informações de roteamento, em vez de aguardar
uma atualização periódica.

Mensagens RIP
 O RIP é um protocolo baseado em UDP. Cada roteador que usa o RIP usa um processo de roteamento
que envolve todas as comunicações direcionadas a outro roteador que está sendo enviado para a porta
520, incluindo todas as mensagens de atualização de roteamento. O RIP geralmente transmite
mensagens de atualização de roteamento como mensagens de difusão, destinadas ao endereço de
broadcast de 255.255.255.255, referentes a todas as redes. No entanto, cada roteador gerará sua
própria transmissão de atualizações de roteamento após cada período de atualização.
Os campos de comando e versão são usados uma vez por pacote, com o campo de comando
detalhando se o pacote é uma mensagem de solicitação ou resposta, para a qual todas as mensagens de
atualização são consideradas mensagens de resposta. A versão refere-se à versão do RIP, que neste caso
é a versão 1. Os demais campos são usados para suportar os anúncios de rede para os quais até 25
entradas de rota podem ser anunciadas em uma única mensagem de atualização do RIP.
O identificador da família de endereços lista o tipo de protocolo que está sendo suportado pelo RIP,
que neste exemplo é IP. Os campos restantes são usados para transportar o endereço de rede IP e a
métrica de salto que contém um valor entre 1 e 15 (inclusive) e especifica a métrica atual para o
destino; ou o valor 16 (infinito), que indica que o destino não está acessível.

Extensões RIP

A introdução de uma nova versão do RIP, conhecida como RIP versão 2, não altera o RIP como tal, mas
fornece extensões para o protocolo RIP atual para permitir a resolução de várias ambiguidades. O formato do
datagrama RIP aplica os mesmos princípios do protocolo RIP original com os mesmos parâmetros de comando. O
campo de versão destaca que os campos estendidos fazem parte da versão 2.
 O identificador da família de endereços continua a se referir ao protocolo que está sendo suportado
e também pode ser usado no suporte de informações de autenticação, conforme explicado em breve. A
marca de rota é outro recurso introduzido para resolver limitações que existem com suporte para
interação entre sistemas autônomos no RIP, cujos detalhes, no entanto, estão fora do escopo deste
curso. Extensões de parâmetro adicionais foram feitas como parte da entrada de rota, incluindo o
campo Máscara de sub-rede, que contém a máscara de sub-rede aplicada ao endereço IP, para definir a
parte de rede ou sub-rede do endereço.
O campo Next Hop agora permite o endereço IP imediato do próximo salto, para o qual os pacotes
destinados ao endereço de destino especificado em uma entrada de rota devem ser encaminhados.
Para reduzir a carga desnecessária de hosts que não estão ouvindo os pacotes do RIP versão 2, um
endereço multicast IP é usado para facilitar as transmissões periódicas, para as quais o endereço
multicast IP usado é 224.0.0.9.

Extensões RIP – Autenticação

A autenticação representa um meio pelo qual os pacotes mal-intencionados podem ser filtrados,
garantindo que todos os pacotes recebidos possam ser verificados como originários de um par válido
por meio do uso de um valor de chave. Esse valor de chave representa originalmente uma cadeia de
senha de texto simples que pode ser configurada para cada interface, conforme reconhecido pelo tipo
de autenticação 2. A autenticação configurada entre os pares deve corresponder antes que as
mensagens do RIP possam ser processadas com êxito. Para o processamento de autenticação, se o
roteador não estiver configurado para autenticar as mensagens do RIP versão 2, as mensagens do RIP
versão 1 e do RIP não autenticado versão 2 serão aceitas; mensagens autenticadas do RIP versão 2
devem ser descartadas.
Se o roteador estiver configurado para autenticar as mensagens do RIP versão 2, as mensagens do
RIP versão 1 e as mensagens do RIP versão 2 que passarem no teste de autenticação deverão ser
aceitas; autenticação não autenticada e com falha As mensagens do RIP versão 2 devem ser
descartadas.
O RIP versão 2 originalmente suportava apenas a autenticação simples de texto sem formatação que
fornecia apenas segurança mínima, já que a cadeia de autenticação poderia ser facilmente capturada.
Com a maior necessidade de segurança para o RIP, a autenticação criptográfica foi introduzida,
inicialmente com o suporte para uma autenticação MD5 com chave (RFC 2082) e aprimoramento
adicional com o suporte da autenticação HMAC-SHA-1, lançada a partir da RFC 4822. Enquanto Huawei
Os roteadores da série AR2200 são capazes de suportar todas as formas de autenticação mencionadas,
o exemplo dado demonstra a autenticação original para simplificar.

Balanceamento de carga RIP

Se uma rede tiver vários links redundantes, um número máximo de rotas de custo igual pode ser
configurado para implementar o balanceamento de carga. Dessa maneira, os recursos de rede são mais
amplamente utilizados, situações em que alguns links são sobrecarregados enquanto outros estão
ociosos podem ser evitados, e atrasos longos nas transmissões de pacotes podem ser evitados. O
número padrão e máximo de rotas de custo igual suportadas pelo RIP é de 8 a qualquer momento.
 Anúncio de rede RIP

É necessário que todos os roteadores que suportam o processo de roteamento RIP ativem primeiro o
processo em cada roteador. O comando rip [process-id] é usado para habilitar isso, com o id do
processo identificando um ID de processo específico ao qual o roteador está associado. Se a ID do
processo não estiver configurada, o processo assumirá como padrão um ID de processo igual a 1. Se
houver variação no ID do processo, o roteador local criará entradas separadas da tabela de roteamento
RIP para cada processo definido.
O comando da versão 2 habilita a extensão RIP versão 2 para RIP, permitindo capacidade adicional
para sub-redes, autenticação, comunicação entre sistemas autônomos etc. O comando <network-
address> de rede especifica o endereço de rede para o qual o RIP está habilitado e deve ser o endereço
do segmento de rede natural.

RIP Metricin

O RIP também é capaz de suportar a manipulação de métricas RIP para controlar o fluxo de tráfego
dentro de um domínio de roteamento RIP. Um meio de conseguir isso é ajustar a métrica associada à
entrada da rota quando recebida por um roteador. Quando uma interface recebe uma rota, o RIP
adiciona a métrica adicional da interface à rota e, em seguida, instala a rota na tabela de roteamento,
aumentando assim a métrica de uma interface que também aumenta a métrica da rota RIP recebida
pela interface.
O comando rip metricin <metric value> permite a manipulação da métrica, em que o valor da métrica
se refere à métrica a ser aplicada. Também deve ser notado que, para o comando rip metricin, o valor
da métrica é adicionado ao valor da métrica atualmente associado à rota. No exemplo, a entrada de rota
para a rede 10.0.0.0/8 contém uma métrica de 1 e é manipulada na chegada à interface do RTC,
resultando no valor métrico de 3 associado à rota.

RIP Metricout
 O comando rip metricout permite que a métrica seja manipulada para a rota quando uma rota RIP é
anunciada. Aumentar a métrica de uma interface também aumenta a métrica da rota RIP enviada na
interface, mas não afeta a métrica da rota na tabela de roteamento do roteador para o qual o comando
rip metricout é aplicado.
Em sua forma mais básica, o comando rip metricout define o valor que deve ser adotado pela entrada
de rota encaminhada, mas também é capaz de suportar mecanismos de filtragem para determinar
seletivamente em quais rotas a métrica deve ser aplicada. O comportamento geral do RIP é incrementar
a métrica por um antes de encaminhar a entrada da rota para o próximo salto. Se o comando rip
metricout estiver configurado, somente o valor da métrica referenciado no comando será aplicado.

Split Horizon & Poisoned Reverse

A configuração de split horizon e poisoned reverse é executada por interface, com o comando rip
split-horizon sendo ativado por padrão (com exceção das redes NBMA) para evitar muitos dos
problemas de loop de roteamento que foram abordados esta seção. A implementação de split horizon e
poisoned reverse não é permitida no roteador da série AR2200, portanto, quando o inverso envenenado
é configurado na interface usando o comando rip poison-reverse, o split horizon será desativado.

Validação de Configuração
 A configuração do protocolo de informações de roteamento por interface pode ser verificada através
do comando display <process_id> interface <interface> verbose. Os parâmetros RIP associados podem
ser encontrados na saída exibida, incluindo a versão do RIP aplicada junto com outros parâmetros, como
se o poison-reverse e o split-horizon foram aplicados à interface. Onde o comando display referencia
que tanto o poison-reverse quanto o split-horizon estão ativados, somente o comando poison-reverse
entrará em vigor.

RIP Output

O comando rip output é aplicado à interface de um roteador que participa do roteamento RIP e
permite que o RIP encaminhe as mensagens de atualização da interface. Quando o comando desfazer
saída é aplicado a uma interface, a mensagem de atualização do RIP deixará de ser encaminhada para
fora de uma determinada interface. Sua aplicação é válida em circunstâncias em que uma rede
corporativa deseja não compartilhar suas rotas internas por meio de uma interface que se conecta a
uma rede externa para proteger a rede, geralmente aplicando uma rota padrão a essa interface em vez
de rotas redes.
 RIP Input

O comando undo rip input permite que uma interface rejeite todas as mensagens de atualização RIP
e impeça que as informações RIP sejam adicionadas à tabela de roteamento de uma determinada
interface. Isso pode ser aplicado em situações em que o fluxo de tráfego pode exigir o controle por meio
de determinadas interfaces ou impedir que o RIP seja totalmente recebido pelo roteador. Como tal,
qualquer mensagem de atualização do RIP enviada para a interface será descartada imediatamente. O
comando rip input pode ser usado para reativar uma interface para retomar o recebimento de
atualizações RIP.

Validação de Configuração
 O comando display rip <process_id> interface <interface> verbose também pode ser usado para
confirmar a implementação de restrições à interface. Onde a interface foi configurada com a entrada
desfazer rip, a capacidade de receber rotas RIP será considerada desativada, conforme destacado no
parâmetro Input.

Silent Interface

A interface silenciosa permite que as atualizações de rota RIP sejam recebidas e usadas para atualizar
a tabela de roteamento do roteador, mas não permitirá que uma interface participe do RIP. Em
comparação, o comando silent-interface tem uma precedência mais alta que os comandos rip input e rip
output. Onde o comando silent-interface all é aplicado, o comando assume a prioridade mais alta, o que
significa que nenhuma interface única pode ser ativada. O comando silent-interface deve ser aplicado
por interface para permitir uma combinação de interfaces ativas e silenciosas.
Uma aplicação comum da interface silenciosa é para redes de acesso múltiplo sem difusão. Os
roteadores podem ser solicitados a receber mensagens de atualização RIP, mas desejam não transmitir /
multicast suas próprias atualizações, exigindo, em vez disso, que um relacionamento com o roteador de
peering seja feito através do uso do comando peer <ip address>.
 Validação de Configuração

O comando display rip fornece uma saída baseada em roteador mais abrangente para a qual
parâmetros globais podem ser verificados junto com determinados parâmetros baseados em interface.
A implementação do comando da interface silenciosa em uma determinada interface, por exemplo,
pode ser observada por meio desse comando.

Resumo
1-Em que ponto a métrica é incrementada para rotas anunciadas?
A métrica é incrementada antes do encaminhamento do anúncio de rota da interface de saída.

2-Que configuração é necessária para anunciar rotas RIP?

O anúncio de rotas RIP é obtido através da configuração do comando de rede. Para cada rede que
deve ser anunciada por um roteador, um comando de rede deve ser configurado.
 Prefácio
O OSPF é um protocolo de gateway interno (IGP) projetado para redes IP, que é
baseado nos princípios do roteamento do estado do link. O comportamento do estado do
link fornece muitas vantagens alternativas para redes corporativas médias e grandes. Sua
aplicação como um IGP é introduzida juntamente com informações relevantes para a
compreensão da convergência e implementação do OSPF, para suportar o OSPF em redes
corporativas

Objectivos
Após a conclusão desta seção, os formandos serão capazes de:
 Explicar o processo de convergência do OSPF.
 Descrever os diferentes tipos de rede suportados pelo OSPF.
 Configurar com sucesso redes OSPF de área única.
 Open Shortest Path Firsrt (OSPF)

Open Shortest Path First ou OSPF é considerado um protocolo de estado de link que é capaz de
detectar rapidamente alterações topológicas dentro do sistema autônomo e estabelecer rotas sem loop
em um curto período de tempo, com sobrecarga de comunicação adicional mínima para negociar
alterações de topologia entre roteadores de peering. O OSPF também lida com problemas de
escalabilidade que ocorrem quando a comunicação entre um número crescente de roteadores se torna
tão extrema que começa a levar à instabilidade dentro do sistema autônomo. Isso é gerenciado por
meio do uso de áreas que limitam o escopo da comunicação do roteador a um grupo isolado dentro do
sistema autônomo, permitindo que redes pequenas, médias e até grandes sejam suportadas pelo OSPF.
O protocolo também é capaz de trabalhar sobre outros protocolos, como o MPLS, um protocolo de
troca de etiquetas, para fornecer escalabilidade de rede mesmo em locais geograficamente dispersos.
Em termos de descoberta de caminho ideal, o OSPF fornece métricas de rota avançadas que fornecem
mais precisão do que as métricas de rota aplicadas a protocolos como RIP para garantir que as rotas
sejam otimizadas, com base não apenas na distância, mas também na velocidade do link.
 Comportamento de Convergência OSPF

A convergência do OSPF requer que cada um e todos os roteadores que executam ativamente o
protocolo OSPF tenham conhecimento do estado de todas as interfaces e adjacências (relação entre os
roteadores aos quais estão conectados), a fim de estabelecer o melhor caminho para cada rede. Isso é
inicialmente formado por meio da inundação de anúncios do estado do link (LSA), que são unidades de
dados que contêm informações como redes conhecidas e estados de link para cada interface dentro de
um domínio de roteamento. Cada roteador usará o LSA recebido para construir um banco de dados de
estado de link (LSDB) que fornece a base para estabelecer a árvore de caminho mais curto para cada
rede, cujas rotas são incorporadas à tabela de roteamento IP.

Router ID

O ID do roteador é um valor de 32 bits atribuído a cada roteador que está executando o protocolo
OSPF. Este valor identifica exclusivamente o roteador dentro de um sistema autônomo. O ID do
roteador pode ser atribuído manualmente ou pode ser obtido de um endereço configurado. Se uma
interface lógica (loopback) tiver sido configurada, a ID do roteador será baseada no endereço IP da
interface lógica configurada mais alta, caso existam várias interfaces lógicas.
 Se nenhuma interface lógica tiver sido configurada, o roteador usará o endereço IP mais alto
configurado em uma interface física. Qualquer roteador que esteja executando o OSPF pode ser
reiniciado usando o recurso de reinicialização normal para renovar o ID do roteador, caso um novo ID de
roteador seja configurado. Recomenda-se que a ID do roteador seja configurada manualmente para
evitar alterações inesperadas no ID do roteador no caso de alterações no endereço da interface.

Tipos de Rede Suportados pelo OSPF

O OSPF suporta vários tipos de rede e, em cada caso, aplicará um comportamento diferente em
termos de como os relacionamentos vizinhos são formados e como a comunicação é facilitada. Ethernet
representa uma forma de rede de transmissão que envolve vários roteadores conectados ao mesmo
segmento de rede. Um dos principais problemas enfrentados diz respeito a como a comunicação ocorre
entre os roteadores vizinhos para minimizar a sobrecarga de roteamento OSPF. Se uma rede Ethernet
for estabelecida, o tipo de rede de transmissão será aplicado automaticamente no OSPF.

Quando dois roteadores são estabelecidos em uma topologia ponto-a-ponto, o tipo de rede aplicado
varia de acordo com a tecnologia de camada de mídia e link aplicada. Como mencionado, o uso de um
meio Ethernet resultará no tipo de rede de transmissão para o OSPF ser atribuído automaticamente.
Onde o meio físico é serial, o tipo de rede é considerado ponto-a-ponto. Formas comuns de protocolos
que operam em mídia serial na camada de enlace incluem o protocolo PPP (Point-to-Point Protocol) e o
HDLC (High-level Data Link Control).
 O OSPF pode operar em redes de acesso múltiplo que não suportam transmissões. Tais redes incluem
Frame Relay e ATM que operam normalmente usando topologias de tipo hub e spoke, que dependem
do uso de circuitos virtuais para que a comunicação seja alcançada. O OSPF pode especificar dois tipos
de redes que podem ser aplicadas a links conectados a esses ambientes. O tipo de rede de acesso
múltiplo sem difusão (NBMA) emula uma rede de difusão e, portanto, exige que cada interface de
peering faça parte do mesmo segmento de rede. Ao contrário de uma rede de difusão, o NBMA
encaminha pacotes OSPF como um unicast, exigindo assim que várias instâncias do mesmo pacote
sejam geradas para cada destino.
Ponto-a-Multiponto também pode ser aplicado como o tipo de rede para cada interface, caso em que
um comportamento de tipo ponto-a-ponto é aplicado. Isso significa que cada peering deve estar
associado a diferentes segmentos de rede. Os roteadores designados são associados a redes de
transmissão e, portanto, são implementados por redes NBMA. O mais importante é o posicionamento
de um DR que deve ser atribuído no nó do hub da arquitetura hub e spoke para garantir que todos os
nós possam se comunicar com o DR.

Roteador designado e roteador designado de backup

Para endereçar e otimizar a comunicação do OSPF em redes de broadcast, o OSPF implementa um

Roteador Designado (DR) que atua como um ponto central de comunicação para todos os outros
roteadores associados a uma rede de broadcast em pelo menos uma interface. Em uma rede de
transmissão teórica que não aplica um DR, pode-se entender que a comunicação segue uma fórmula n
(n-1) / 2, onde n representa o número de interfaces de roteadores participantes do OSPF. No exemplo
dado, isso se referiria a 6 adjacências entre todos os roteadores. Quando o DR é aplicado, todos os
roteadores estabelecem um relacionamento com o DR ao qual é responsável por atuar como um ponto
central de comunicação para todos os roteadores vizinhos em uma rede de transmissão.
Um Roteador Designado de Backup (BDR) é um roteador que é escolhido para substituir o DR caso ele
falhe. Como tal, é necessário que o BDR estabeleça um banco de dados de estado de link como o do DR
para garantir a sincronização. Isso significa que todos os roteadores vizinhos também devem se
comunicar com o BDR em uma rede de transmissão. Com a aplicação do DR e do BDR, o número de
associações é reduzido de 6 para 5, pois o RTA e o RTB precisam apenas se comunicar com o DR e o BDR.
Isto pode parecer ter um efeito mínimo, no entanto, quando isto é aplicado a uma rede contendo, por
exemplo, 10 roteadores, ou seja, (10 * 9) / 2, a eficiência de comunicação resultante torna-se aparente.

Estados vizinhos

O OSPF cria adjacências entre roteadores vizinhos com o objetivo de trocar informações de
roteamento. Nem todos os dois roteadores vizinhos se tornarão adjacentes, particularmente quando
um dos dois roteadores que estabelecem uma adjacência for considerado não o DR ou o BDR. Esses
roteadores são conhecidos como DROther e só reconhecem a presença do DROther, mas não
estabelecem comunicação completa; este estado é conhecido como o estado vizinho. DRO Outros
roteadores, no entanto, formam adjacência total com roteadores DR e BDR para permitir a
sincronização do banco de dados de estado de link dos roteadores DR e BDR com cada um dos
roteadores DROther. Essa sincronização é obtida estabelecendo um estado adjacente com cada
DROther.
Uma adjacência está ligada à rede que os dois roteadores têm em comum. Se dois roteadores
tiverem várias redes em comum, eles poderão ter várias adjacências entre eles.
 Estabelecimento do estado do link

Cada roteador que participa do OSPF fará a transição através de vários estados de link para obter um
estado vizinho ou um estado adjacente. Todos os roteadores começam no estado inativo após a
inicialização e passam por um processo de descoberta vizinho, que envolve, primeiramente, tornar uma
presença de roteadores conhecida na rede OSPF por meio de um pacote Hello. Ao executar esta ação, o
roteador fará a transição para um estado inicial.
Quando o roteador recebe uma resposta na forma de um pacote Hello contendo o ID do roteador
que recebe a resposta, um estado bidirecional será alcançado e um relacionamento vizinho será
formado. No caso de redes NBMA, um estado de tentativa é alcançado quando a comunicação com o
vizinho se torna inativa e uma tentativa está sendo feita para restabelecer a comunicação através do
envio periódico de pacotes Hello. Os roteadores que não atingem um relacionamento adjacente
permanecerão em um estado vizinho com um estado bidirecional de comunicação.
Roteadores como DR e BDR criarão um estado vizinho adjacente com todos os outros roteadores
vizinhos e, portanto, deverão trocar informações de estado de link para estabelecer um banco de dados
de estado de link completo. Isso requer que os roteadores de peering que estabelecem uma adjacência
primeiro negociem pela troca de informações de estado de link (ExStart) antes de proceder à troca de
informações resumidas sobre as redes de que estão cientes. Os vizinhos podem identificar rotas de que
não estão cientes ou não possuem informações atualizadas e, portanto, solicitar detalhes adicionais
para essas rotas como parte do estado de carregamento. Um relacionamento totalmente sincronizado
entre vizinhos é determinado pelo estado completo no qual os dois roteadores de peering podem ser
considerados adjacentes.
 Descoberta de vizinho

A descoberta do vizinho é obtida por meio do uso de pacotes Hello gerados em intervalos com base
em um temporizador Hello, que por padrão é a cada 10 segundos para tipos de rede de difusão e ponto
a ponto; enquanto para os tipos de rede NBMA e Ponto-a-Multiponto, o intervalo de saudação é de 30
segundos. O pacote de saudação contém esse período de intervalo, junto com um campo de prioridade
de roteador que permite que os vizinhos determinem o vizinho com o ID de roteador mais alto para
identificação do DR e BDR nas redes de transmissão e NBMA.
Um período especificando quanto tempo um pacote de hello é válido antes que o vizinho seja
considerado perdido também deve ser definido, e isso é transportado como o intervalo morto do
roteador dentro do pacote de saudação. Este intervalo morto é definido por padrão para ser quatro
vezes o intervalo de saudação, sendo 40 segundos para redes de broadcast e ponto a ponto, e 120
segundos para redes NBMA e Point-to-Multipoint. Além disso, o ID do roteador do DR e do BDR são
transportados, quando aplicável, com base na rede para a qual o pacote de saudação é gerado.

Eleição do roteador designado

 Após a descoberta do vizinho, a eleição do DR pode ocorrer dependendo do tipo de rede do
segmento de rede. Redes de transmissão e NMBA realizarão a eleição do DR. A eleição do DR depende
de uma prioridade que é atribuída para cada interface que participa do processo de eleição do DR. Esse
valor de prioridade é definido como 1 por padrão e uma prioridade mais alta representa um melhor
candidato a DR.
Se uma prioridade de 0 for definida, a interface do roteador não participará mais da eleição para se
tornar o DR ou o BDR. Pode ser que, quando conexões ponto-a-ponto (usando Ethernet como meio
físico) sejam configuradas para suportar um tipo de rede de transmissão, ocorrerá uma eleição DR
desnecessária, o que gera tráfego excessivo de protocolo. Portanto, é recomendável que o tipo de rede
seja configurado como um tipo de rede ponto a ponto.

Eleição do roteador designado de backup

Para melhorar a eficiência da transição para um novo Roteador Designado, um Roteador Designado
de Backup é atribuído para cada rede de transmissão e NBMA. O Roteador Designado de Backup
também é adjacente a todos os roteadores na rede e se torna o Roteador Designado quando o Roteador
Designado anterior falha. Se não houvesse roteador designado de backup, novas adjacências teriam que
ser formadas entre o novo roteador designado e todos os outros roteadores conectados à rede.
Parte do processo de formação de adjacências envolve a sincronização de bancos de dados link-state,
que podem levar bastante tempo. Durante esse período, a rede não estaria disponível para o trânsito de
dados. O Roteador Designado de Backup elimina a necessidade de formar essas adjacências, uma vez
que elas já existem. Isso significa que o período de interrupção no tráfego de trânsito dura apenas o
tempo necessário para inundar os novos LSAs (que anunciam o novo Roteador Designado). O Roteador
Designado de Backup também é eleito pelo pacote Hello. Cada pacote Hello possui um campo que
especifica o Roteador Designado de Backup para a rede.
 Sincronização de Banco de Dados

Em um algoritmo de roteamento link-state, é muito importante que todos os bancos de dados de

estado dos roteadores permaneçam sincronizados. O OSPF simplifica isso, exigindo que apenas os
roteadores adjacentes permaneçam sincronizados. O processo de sincronização começa assim que os
roteadores tentam ativar a adjacência. Cada roteador descreve seu banco de dados enviando uma
seqüência de pacotes de Descrição do Banco de Dados para seu vizinho. Cada pacote de descrição do
banco de dados descreve um conjunto de LSAs pertencentes ao banco de dados do roteador.
Quando o vizinho vê um LSA que é mais recente que sua própria cópia de banco de dados, ele
observa que esse LSA mais novo deve ser solicitado. Esse envio e recebimento de pacotes Database
Description é chamado de "Database Exchange Process". Durante esse processo, os dois roteadores
formam uma relação mestre / escravo. Cada pacote de descrição do banco de dados tem um número de
seqüência. Os pacotes de descrição do banco de dados enviados pelo mestre são reconhecidos pelo
escravo por meio do eco do número de seqüência.

Estabelecendo Adjacência Completa

Durante e após o processo de troca de banco de dados, cada roteador tem uma lista desses LSAs para
os quais o vizinho tem instâncias mais atualizadas. O pacote Link State Request é usado para solicitar as
partes do banco de dados do vizinho que estão mais atualizadas. Vários pacotes de solicitação de estado
de link podem precisar ser usados.
Os pacotes de atualização do estado do link implementam a inundação de LSAs. Cada pacote de
atualização do estado do link carrega uma coleção de LSAs um salto mais longe de sua origem. Vários
LSAs podem ser incluídos em um único pacote. Em redes de transmissão, os pacotes de atualização do
estado do link são multicast. O endereço IP de destino especificado para o pacote de atualização do
estado do link depende do estado da interface. Se o estado da interface for DR ou Backup, o endereço
AllSPFRouters (224.0.0.5) deve ser usado. Caso contrário, o endereço AllDRouters (224.0.0.6) deve ser
usado. Em redes de não-difusão, pacotes separados de atualização de estado de link devem ser
enviados, como unicast, para cada vizinho adjacente (ou seja, aqueles em um estado do Exchange ou
superior). Os endereços IP de destino desses pacotes são os endereços IP dos vizinhos.
Quando o Processo de Descrição do Banco de Dados for concluído e todas as Solicitações de Estado
do Link tiverem sido atendidas, os bancos de dados serão considerados sincronizados e os roteadores
serão marcados como totalmente adjacentes. Neste momento, a adjacência é totalmente funcional e é
anunciada nos LSAs do roteador de dois roteadores.

Métrica OSPF

O OSPF calcula o custo de uma interface baseada na largura de banda da interface. A fórmula de
cálculo é: custo da interface = valor de referência de largura de banda / largura de banda. O valor de
referência da largura de banda é configurável para o qual o padrão é 100 Mbps. Com a fórmula
100000000 / Bandwidth, isso fornece uma métrica de custo de 1562 para uma porta Serial de 64 kbit / s,
48 para uma interface E1 (2.048 Mbit / s) e um custo de 1 para Ethernet (100 Mbit / s) ou superior.
Para ser capaz de distinguir entre interfaces de alta velocidade, é imperativo que a métrica de custo
seja ajustada para corresponder às velocidades atualmente suportadas. Os comandos de referência de
largura de banda permitem que a métrica seja alterada alterando o valor de referência da largura de
banda na fórmula de custo. Quanto maior o valor, mais precisa será a métrica. Onde velocidades de
10Gb estão sendo suportadas, é recomendado que o valor de referência de largura de banda seja
aumentado para "10000" ou 1010 / largura de banda para fornecer métricas de 1, 10 e 100 para links de
largura de banda de 10Gb, 1Gb e 100Mb, respectivamente.
 Como alternativa, o custo pode ser configurado manualmente usando o comando ospf cost para
definir um valor de custo para uma determinada interface. O valor de custo varia de 1 a 65535 com um
valor de custo padrão de 1.

Árvore de caminho mais curto

Considera-se que um roteador que atingiu um estado completo recebeu todos os anúncios de estado
de link (LSA) e sincronizou seu banco de dados de estado de link (LSDB) com o dos vizinhos adjacentes.
As informações de estado do link coletadas no banco de dados de estado do link são usadas para
calcular o caminho mais curto para cada rede. Cada roteador depende apenas das informações no LSDB
para calcular independentemente o caminho mais curto para cada destino, em vez de depender de
informações de rota selecionadas dos pares, consideradas como a melhor rota para um destino. O
cálculo da árvore de caminho mais curto, no entanto, significa que cada roteador deve utilizar recursos
adicionais para realizar essa operação.

Áreas do OSPF - Área Única

Redes menores podem envolver um número selecionado de roteadores que operam como parte do
domínio OSPF. Esses roteadores são considerados parte de uma área que é representada por um banco
de dados de estado de link idêntico para todos os roteadores no domínio. Como uma única área, o OSPF
pode receber qualquer número de área, no entanto, para fins de futura implementação de design,
recomenda-se que essa área seja designada como área 0.

Áreas OSPF – Multi-Área

A necessidade de encaminhar anúncios de estado de link e o subsequente cálculo do caminho mais

curto com base no banco de dados de estado de link torna-se cada vez mais complexo à medida que
mais e mais roteadores se tornam parte do domínio OSPF. Dessa forma, o OSPF é capaz de suportar uma
estrutura hierárquica para limitar o tamanho do banco de dados de estado do link e o número de
cálculos que devem ser executados ao determinar o caminho mais curto para uma determinada rede.
A implementação de várias áreas permite que um domínio OSPF compartimentalize o processo de
cálculo com base em um banco de dados de estado de link que seja idêntico apenas para cada área, mas
forneça as informações para alcançar todos os destinos dentro do domínio OSPF. Certos roteadores
conhecidos como roteadores de borda de área (ABR) operam entre áreas e contêm vários bancos de
dados de estado de link para cada área à qual o ABR está conectado. A área 0 deve ser configurada onde
o OSPF de área múltipla existe e para o qual todo o tráfego enviado entre as áreas é geralmente
necessário para atravessar a área 0, para garantir que os loops de roteamento não ocorram.
 Anúncio da Rede OSPF

O estabelecimento do OSPF dentro de um domínio AS requer que cada roteador que participe do
OSPF primeiro habilite o processo OSPF. Isso é obtido usando o comando ospf [process id], onde o ID do
processo pode ser designado e representa o processo ao qual o roteador está associado. Se os
roteadores receberem números de identificação de processo diferentes, os bancos de dados de estado
de link separados serão criados com base em cada ID de processo individual. Onde nenhum ID de
processo é atribuído, o ID de processo padrão de 1 será usado. O ID do roteador também pode ser
atribuído usando o comando ospf [id do processo] [roteador-id <roteador-id>], onde <roteador-id>
refere-se ao ID que deve ser atribuído ao roteador, tendo em mente que valor de ID mais alto
representa o DR em redes de transmissão e NBMA.
As informações de parênteses refletem o processo e nível ospf no qual os parâmetros ospf podem ser
configurados, incluindo a área à qual cada link (ou interface) está associado. Redes que devem ser
anunciadas em uma determinada área são determinadas através do uso do comando de rede. A
máscara é representada como uma máscara curinga para a qual um valor de bit 0 representa os bits que
são fixos (por exemplo, id de rede) e onde os valores de bit na máscara representam um valor de 1, o
endereço pode representar qualquer valor.
 Validação de Configuração

A configuração do relacionamento vizinho entre peers OSPF é verificada por meio do comando
display ospf peer. Os atributos associados à conexão peer são listados para fornecer uma explicação
clara da configuração. Atributos importantes incluem a área na qual a associação peer é estabelecida, o
estado do estabelecimento peer, a associação mestre / escravo para negociação de adjacência para
atingir o estado completo e também as atribuições de DR e BDR que destacam que o link está associado
com um tipo de rede de transmissão.

Autenticação OSPF

O OSPF é capaz de suportar a autenticação para garantir que as rotas sejam protegidas contra ações
maliciosas que podem resultar de manipulação ou danos à topologia e rotas OSPF existentes. O OSPF
permite o uso de autenticação simples, bem como autenticação criptográfica, que fornece proteção
aprimorada contra possíveis ataques.
A autenticação é atribuída por interface com o comando para autenticação simples do modo de
autenticação ospf {simple [[plain] <plain-text> | cifra <texto cifrado>] | null} onde plain aplica uma
senha de texto não criptografado, criptografa uma senha de texto cifrado para ocultar o conteúdo
original e null para indicar uma autenticação nula.
 A autenticação criptográfica é aplicada usando o modo de autenticação ospf {md5 | hmac-md5} [key-
id {simples <texto sem formatação> | comando [cipher] <cipher-text>}]. O MD5 representa um
algoritmo criptográfico para proteger a autenticação através do link, com sua configuração demonstrada
dentro do exemplo dado. A chave identifica um ID de chave de autenticação exclusivo da autenticação
de codificação da interface. O ID da chave deve ser consistente com o do peer.

Validação de Configuração

Onde a autenticação é aplicada, é possível implementar a depuração no terminal para visualizar o

processo de autenticação. Como a depuração pode envolver muitos eventos, o comando debugging ospf
packet deve ser usado para especificar que a depuração só deve ser executada para pacotes específicos
do OSPF. Como resultado, o processo de autenticação pode ser visualizado para validar que a
configuração de autenticação foi implementada com sucesso.

Interface silenciosa do OSPF

Geralmente, é necessário controlar o fluxo de informações de roteamento e limitar o intervalo para o

qual esses protocolos de roteamento podem se estender. Este é particularmente o caso quando se
conecta com redes externas de quem o conhecimento de rotas internas deve ser protegido. Para
conseguir isso, o comando da interface silenciosa pode ser aplicado como um meio de restringir toda a
comunicação do OSPF através da interface na qual o comando é implementado.
 Depois que uma interface OSPF é definida para estar no estado silencioso, a interface ainda pode
anunciar suas rotas diretas. Os pacotes Hello na interface, no entanto, serão bloqueados e nenhum
relacionamento vizinho poderá ser estabelecido na interface. O comando interface-silenciosa [interface-
type interface-number] pode ser usado para definir uma interface específica que restringe a operação
do OSPF ou, alternativamente, o comando silent-interface pode ser usado para garantir que todas as
interfaces sob um processo específico sejam restritas de participar no OSPF.

Validação de Configuração

A implementação da interface silenciosa em uma base por interface significa que a interface
específica deve ser observada para validar a aplicação bem-sucedida do comando da interface
silenciosa. Por meio do comando display ospf <process_id> interface <interface>, em que a interface
representa a interface na qual o comando da interface silenciosa foi aplicado, é possível validar a
implementação da interface silenciosa.

Resumo
1-Qual é o objetivo do intervalo morto no cabeçalho do OSPF?
O intervalo morto é um valor de timer usado para determinar se a propagação de pacotes Hello de
OSPF foi interrompida. Esse valor é equivalente a quatro vezes o intervalo Hello ou 40 segundos por
padrão nas redes de transmissão. No caso de o intervalo morto ser reduzido a zero, o relacionamento
de vizinho do OSPF será encerrado.

2-Em uma rede de difusão, qual é o endereço multicast usado pelo Roteador designado (DR) e pelo
Roteador designado de backup (BDR) para escutar as informações de atualização do estado do link?
O DR e o BDR usam o endereço multicast 224.0.0.6 para escutar as atualizações de estado do link
quando o tipo de rede OSPF é definido como broadcast.
 Prefácio

Uma rede corporativa pode consistir freqüentemente em um número substancial de

dispositivos host, cada um exigindo parâmetros de rede na forma de endereçamento IP e
informações adicionais de configuração de rede. A alocação manual é muitas vezes um
negócio tedioso e impreciso, o que pode levar a que muitas estações finais enfrentem
duplicação de endereço ou falhas no acesso aos serviços necessários para uma operação
de rede suave. DHCP é um protocolo de camada de aplicativo projetado para automatizar
o processo de fornecimento dessas informações de configuração a clientes em uma rede
TCP / IP. Portanto, o DHCP ajuda a garantir que o endereçamento correto seja alocado e
reduz a sobrecarga na administração de todas as redes corporativas. Esta seção
apresenta a aplicação do DHCP dentro da rede corporativa.

Objectivos

Após a conclusão desta seção, os formandos serão capazes de:

 Descrever a função do DHCP na rede corporativa.
 Explicar o processo de leasing do DHCP.
 Configurar pools DHCP para leasing de endereço.
 Aplicativo DHCP na rede corporative

As redes corporativas geralmente são compostas de vários sistemas finais que exigem designação de
endereço IP para se conectar ao segmento de rede ao qual o sistema final está conectado. Para redes
pequenas, um número mínimo de sistemas finais conectados à rede permite o gerenciamento simples
do endereçamento para todos os sistemas finais.
Para redes de médio e grande porte, no entanto, torna-se cada vez mais difícil configurar
manualmente endereços IP com maior probabilidade de duplicação de endereçamento, bem como
erros de configuração devido a erro humano e, portanto, a necessidade de implementar uma solução de
gerenciamento centralizado em toda a rede. cada vez mais proeminente. O protocolo DHCP (Dynamic
Host Configuration Protocol) é implementado como uma solução de gerenciamento para permitir a
alocação dinâmica de endereços para sistemas finais fixos e temporários existentes acessando o
domínio de rede.
Nos casos, também é possível que haja mais hosts do que os endereços IP disponíveis em uma rede.
Alguns hosts não podem receber um endereço IP fixo e precisam obter dinamicamente endereços IP
usando o servidor DHCP. Apenas alguns hosts em uma rede exigem endereços IP fixos.

Mecanismos de alocação de endereços

O DHCP suporta três mecanismos para alocação de endereços IP. O método de alocação automática
envolve a atribuição de um endereço IP permanente a um cliente. O uso de alocação dinâmica emprega
o DHCP para atribuir um endereço IP a um cliente por um período limitado de tempo ou pelo menos até
que o cliente abandone explicitamente o endereço IP.
 O terceiro mecanismo é chamado de alocação manual, para a qual o endereço IP de um cliente é
atribuído pelo administrador da rede e o DHCP é usado apenas para manipular a atribuição do endereço
definido manualmente ao cliente. A alocação dinâmica é o único dos três mecanismos que permite a
reutilização automática de um endereço que não é mais necessário para o cliente ao qual foi atribuído.
Assim, a alocação dinâmica é particularmente útil para atribuir um endereço a um cliente que será
conectado à rede apenas temporariamente ou para compartilhar um conjunto limitado de endereços IP
entre um grupo de clientes que não precisam de endereços IP permanentes.
A alocação dinâmica também pode ser uma boa opção para atribuir um endereço IP a um novo
cliente permanentemente conectado a uma rede, onde os endereços IP são suficientemente escassos
para que os endereços possam ser recuperados quando os clientes antigos forem desativados. A
alocação manual permite que o DHCP seja usado para eliminar o processo propenso a erros de
configurar manualmente os hosts com endereços IP em ambientes em que talvez seja mais desejável
gerenciar meticulosamente a atribuição de endereços IP.
Mensagens DHCP

Um servidor DHCP e um cliente DHCP se comunicam trocando um intervalo de tipos de mensagens. A

comunicação inicial depende da transmissão de uma mensagem DHCP Discover. Isso é transmitido por
um cliente DHCP para localizar um servidor DHCP quando o cliente tenta se conectar a uma rede pela
primeira vez. Uma mensagem de Oferta DHCP é então enviada por um servidor DHCP para responder a
uma mensagem Descoberta DHCP e transporta informações de configuração.
Uma mensagem de solicitação DHCP é enviada depois que um cliente DHCP é inicializado, no qual
transmite uma mensagem de solicitação DHCP para responder à mensagem de oferta DHCP enviada por
um servidor DHCP. Uma mensagem de solicitação também é enviada depois que um cliente DHCP é
reiniciado, momento em que ele transmite uma mensagem de solicitação DHCP para confirmar a
configuração, como o endereço IP atribuído. Uma mensagem de solicitação DHCP também é enviada
depois que um cliente DHCP obtém um endereço IP, para estender a concessão de endereço IP.
Uma mensagem DHCP ACK é enviada por um servidor DHCP para confirmar a mensagem de
solicitação DHCP de um cliente DHCP. Depois de receber uma mensagem DHCP ACK, o cliente DHCP
obtém os parâmetros de configuração, incluindo o endereço IP. Nem todos os casos, no entanto,
resultarão no endereço IP atribuído a um cliente. A mensagem DHCP NAK é enviada por um servidor
DHCP para rejeitar a mensagem de solicitação DHCP de um cliente DHCP quando o endereço IP
atribuído ao cliente DHCP expira, ou no caso em que o cliente DHCP se move para outra rede.
Uma mensagem de recusa DHCP é enviada por um cliente DHCP para notificar o servidor DHCP de
que o endereço IP atribuído está em conflito com outro endereço IP. O cliente DHCP aplicará então ao
servidor DHCP para outro endereço IP.
Uma mensagem de liberação DHCP é enviada por um cliente DHCP para liberar seu endereço IP.
Depois de receber uma mensagem de Liberação DHCP, o servidor DHCP atribui esse endereço IP a outro
cliente DHCP.
Um tipo de mensagem final é a mensagem DHCP Inform e é enviada por um cliente DHCP para obter
outras informações de configuração de rede, como o endereço do gateway e o endereço do servidor
DNS, depois que o cliente DHCP obtiver um endereço IP.
Pools de endereços

Os dispositivos da série AR2200 e S5700 podem operar como um servidor DHCP para atribuir
endereços IP a usuários on-line. Os pools de endereços são usados para definir os endereços que devem
ser alocados aos sistemas finais. Há duas formas gerais de pools de endereços que podem ser usados
para alocar endereços, o pool de endereços global e o pool de endereços da interface.
O uso de um pool de endereços de interface permite que apenas os sistemas finais conectados ao
mesmo segmento de rede que a interface tenha endereços IP alocados desse pool. O pool de endereços
global, uma vez configurado, permite que todos os sistemas finais associados ao servidor obtenham
endereços IP desse pool de endereços e é implementado usando o comando global dhcp select para
identificar o pool de endereços global. No caso do pool de endereços da interface, o comando dhcp
select interface identifica a interface e o segmento de rede ao qual o conjunto de endereços da
interface está associado.
O pool de endereços de interface tem precedência sobre o pool de endereços global. Se um pool de
endereços estiver configurado em uma interface, os clientes conectados à interface obterão endereços
IP do pool de endereços da interface, mesmo se um pool de endereços global estiver configurado. No
comutador S5700, apenas interfaces lógicas VLANIF podem ser configuradas com conjuntos de
endereços de interface.
 Aquisição de endereços DHCP

A aquisição de um endereço IP e outras informações de configuração exigem que o cliente entre em

contato com um servidor DHCP e recupere, por solicitação, as informações de endereçamento para se
tornar parte do domínio IP. Esse processo começa com o processo de descoberta de IP no qual o cliente
DHCP procura por um servidor DHCP. O cliente DHCP transmite uma mensagem de Descoberta DHCP e
os servidores DHCP respondem à mensagem Descoberta.
A descoberta de um ou vários servidores DHCP resulta em cada servidor DHCP oferecendo um
endereço IP ao cliente DHCP. Depois de receber a mensagem Descoberta DHCP, cada servidor DHCP
seleciona um endereço IP não atribuído do pool de endereços IP e envia uma mensagem de Oferta
DHCP com o endereço IP atribuído e outras informações de configuração ao cliente.
Se vários servidores DHCP enviarem mensagens de Oferta DHCP ao cliente, o cliente aceitará a
primeira mensagem de Oferta DHCP recebida. O cliente então transmite uma mensagem de solicitação
DHCP com o endereço IP selecionado. Depois de receber a mensagem de solicitação DHCP, o servidor
DHCP que oferece o endereço IP envia uma mensagem DHCP ACK para o cliente DHCP. A mensagem
DHCP ACK contém o endereço IP oferecido e outras informações de configuração.
Ao receber a mensagem DHCP ACK, o cliente DHCP transmite pacotes ARP gratuitos para detectar se
algum host está usando o endereço IP alocado pelo servidor DHCP. Se nenhuma resposta for recebida
dentro de um tempo especificado, o cliente DHCP usará esse endereço IP. Se um host estiver usando
esse endereço IP, o cliente DHCP enviará o pacote DHCP Decline ao servidor DHCP, informando que o
endereço IP não pode ser usado, após o qual o cliente DHCP se aplica para outro endereço IP.
 Renovação da concessão de DHCP

Depois de obter um endereço IP, o cliente DHCP entra no estado de ligação. Três temporizadores são
definidos no cliente DHCP para controlar a atualização da concessão, a vinculação da concessão e a
expiração da concessão. Ao atribuir um endereço IP a um cliente DHCP, um servidor DHCP especifica
valores para os timers.
Se o servidor DHCP não definir os valores dos cronômetros, o cliente DHCP usará os valores padrão.
Os valores padrão definem que, quando 50% do período de concessão permanecer, o processo de
renovação de versão deve começar, para o qual se espera que um cliente DHCP renove sua concessão
de endereço IP. O cliente DHCP envia automaticamente uma mensagem de solicitação DHCP para o
servidor DHCP que alocou um endereço IP para o cliente DHCP.
Se o endereço IP for válido, o servidor DHCP responderá com uma mensagem DHCP ACK para
conceder ao novo cliente DHCP uma nova concessão e, em seguida, o cliente voltará a inserir o estado
de ligação. Se o cliente DHCP receber uma mensagem DHCP NAK do servidor DHCP, ele entrará no
estado de inicialização.
Expiração de religamento de DHCP

Depois que o cliente DHCP envia uma mensagem de solicitação DHCP para estender a concessão, o
cliente DHCP permanece em um estado de atualização e aguarda uma resposta. Se o cliente DHCP não
receber uma mensagem de resposta DHCP do servidor DHCP após o término do tempo de reativação do
servidor DHCP, que por padrão ocorre quando 12,5% do período de concessão permanece, o cliente
DHCP supõe que o servidor DHCP original não está disponível e começa a transmitir uma mensagem de
solicitação DHCP, para a qual qualquer servidor DHCP na rede pode responder com uma mensagem
DHCP ACK ou NAK.
Se a mensagem recebida for uma mensagem DHCP ACK, o cliente DHCP retornará ao estado de
ligação e redefinirá o cronômetro de renovação de concessão e o cronômetro de ligação do servidor. Se
todas as mensagens recebidas forem mensagens DHCP NAK, o cliente DHCP retornará ao estado de
inicialização. Neste momento, o cliente DHCP deve parar de usar esse endereço IP imediatamente e
solicitar um novo endereço IP.
Liberação de Endereço IP

O cronômetro de concessão é o cronômetro final no processo de expiração e, se o cliente DHCP não

receber uma resposta antes do vencimento do cronômetro de vencimento, o cliente DHCP deverá parar
de usar o endereço IP atual imediatamente e retornar ao estado de inicialização. O cliente DHCP envia
uma mensagem DHCP DISCOVER para solicitar um novo endereço IP, reiniciando assim o ciclo DHCP.
Configuração do pool de interfaces DHCP

Há duas formas de configuração de pool com suporte no DHCP, que incluem definir um pool global
ou um pool baseado em interface. O comando dhcp select interface é usado para associar uma interface
ao pool de endereços da interface para fornecer informações de configuração aos hosts conectados. O
exemplo demonstra como a interface Gigabit Ethernet 0/0/0 foi atribuída como parte de um pool de
endereços de interface.
 Validação de Configuração DHCP

Cada servidor DHCP definirá um ou vários conjuntos que podem estar associados globalmente ou
com uma determinada interface. Para determinar os atributos do conjunto associados a uma interface,
o comando display ip pool interface <interface> é usado. O pool DHCP conterá informações, incluindo o
período de concessão para cada endereço IP concedido, bem como o intervalo do pool que é suportado.
No caso de outros atributos serem suportados para propagação relacionada ao DHCP para clientes,
como com o gateway IP, máscara de sub-rede e servidor DNS, eles também serão exibidos.

Configuração do conjunto global de DHCP

O exemplo demonstra a configuração do DHCP para um pool de endereços global atribuído à rede
10.2.2.0. O comando dhcp enable é o pré-requisito para configurar as funções relacionadas ao DHCP e
entra em vigor somente após o comando dhcp enable ser executado. Um servidor DHCP exige que o
comando ip pool seja configurado na visualização do sistema para criar um pool de endereços IP e
definir parâmetros do pool de endereços IP, incluindo um endereço de gateway, o período de concessão
de endereço IP, etc. Pool de endereços IP para clientes.
 Um servidor DHCP e seu cliente podem residir em diferentes segmentos de rede. Para permitir que o
cliente se comunique com o servidor DHCP, o comando gateway-list é usado para especificar um
endereço de gateway de saída para o pool de endereços global do servidor DHCP. O servidor DHCP pode
então atribuir um endereço IP e o endereço do gateway de saída especificado ao cliente. O endereço é
configurado em notação decimal pontuada para a qual um máximo de oito endereços de gateway,
separados por espaços, pode ser configurado.

Validação de Configuração DHCP

As informações referentes a um pool também podem ser observadas por meio do comando display ip
pool. Esse comando fornecerá uma visão geral dos parâmetros gerais de configuração suportados por
um pool configurado, incluindo o gateway e a máscara de sub-rede do pool, bem como estatísticas
gerais que permitem ao administrador monitorar o uso atual do pool para determinar o número de
endereços alocados. junto com outras estatísticas de uso.

Resumo

1-Quais endereços IP geralmente devem ser excluídos do pool de endereços?

Endereços IP usados para alocação de servidores, como servidores DNS locais, para evitar conflitos de
endereço.

2-Qual é o período de concessão do endereço IP padrão?

O período de concessão padrão para endereços IP atribuídos a DHCP é definido em um período igual
a um dia.
 Prefácio

O desenvolvimento inicial de padrões introduziu as bases de um protocolo de

transferência de arquivos, com o objetivo de promover o compartilhamento de arquivos
entre locais remotos que não foram afetados por variações nos sistemas de
armazenamento de arquivos entre hosts. O aplicativo FTP resultante foi finalmente
adotado como parte do conjunto de protocolos TCP / IP. O serviço FTP continua sendo
parte integrante da rede como um aplicativo para garantir a transferência confiável e
eficiente de dados, comumente implementada para backup e recuperação de arquivos e
logs, melhorando assim o gerenciamento geral da rede da empresa. Esta seção, portanto,
introduz os meios para engenheiros e administradores implementarem serviços de FTP
nos produtos da Huawei.

Objectios

Após a conclusão desta seção, os formandos serão capazes de:

 Explicar o processo de transferência de arquivos do FTP.
 Configurar o serviço FTP no suporte a dispositivos Huawei.
 Aplicativo FTP na rede corporative

A implementação de um servidor FTP dentro da rede da empresa permite o backup e a recuperação

de arquivos importantes do sistema e do usuário, que podem ser usados para manter a operação diária
de uma rede corporativa. Exemplos típicos de como um servidor FTP pode ser aplicado incluem o
backup e a recuperação de arquivos de imagem e configuração do VRP. Isso também pode incluir a
recuperação de arquivos de log do servidor FTP para monitorar a atividade de FTP que ocorreu.

Processo de transferência de arquivos por FTP

A transferência de arquivos FTP depende de duas conexões TCP. A primeira delas é uma conexão de
controle que é configurada entre o cliente FTP e o servidor FTP. O servidor ativa a porta comum 21 e
aguarda uma solicitação de conexão do cliente. O cliente envia uma solicitação para configurar uma
conexão com o servidor. Uma conexão de controle sempre aguarda a comunicação entre o cliente e o
servidor, transmite comandos relacionados do cliente para o servidor, bem como respostas do servidor
para o cliente.
O servidor usa a porta TCP 20 para conexões de dados. Geralmente, o servidor pode abrir ou fechar
uma conexão de dados ativamente. Para arquivos enviados do cliente para o servidor na forma de
fluxos, no entanto, somente o cliente pode fechar uma conexão de dados. O FTP transfere cada arquivo
em fluxos, usando um indicador End of File (EOF) para identificar o final de um arquivo. Portanto, é
necessária uma nova conexão de dados para cada arquivo ou lista de diretórios a ser transferido.
Quando um arquivo está sendo transferido entre o cliente e o servidor, isso indica que uma conexão de
dados está configurada.

Conceitos Básicos do FTP

Existem dois modos de transmissão FTP que são suportados pela Huawei, são o modo ASCII e o modo
binário. O modo ASCII é usado para texto, no qual os dados são convertidos da representação de
caracteres do remetente para "ASCII de 8 bits" antes da transmissão. Simplificando, os caracteres ASCII
são usados para separar retornos de linha de feeds de linha. No modo binário, o emissor envia cada byte
de arquivo para byte. Este modo é freqüentemente usado para transferir arquivos de imagem e
arquivos de programas para os quais os caracteres podem ser transferidos sem conversão de formato.

Estabelecimento de serviço FTP

A implementação do serviço FTP é possível tanto no roteador da série AR2200 quanto no switch da
série S5700, para a qual o serviço pode ser ativado através do comando ftp server enable. Depois que a
função do servidor FTP é ativada, os usuários podem gerenciar arquivos no modo FTP. O comando set
default ftp-directory define o diretório de trabalho padrão para usuários de FTP. Onde nenhum diretório
de trabalho FTP padrão estiver configurado, o usuário não conseguirá efetuar login no roteador e, em
vez disso, será avisado com uma mensagem notificando que o usuário não tem autoridade para acessar
qualquer diretório de trabalho.

Estabelecimento de usuários do serviço FTP

O acesso ao serviço FTP pode ser obtido atribuindo-se login de usuário individual para gerenciar o
acesso por usuário. O AAA é usado para configurar autenticação e autorização local. Depois que a
visualização AAA é inserida, o usuário local pode ser criado definindo uma conta de usuário e uma
senha. A conta é capaz de se associar a uma variedade de serviços, que são especificados usando o
comando service-type, para permitir que o tipo de serviço ftp seja suportado pelo AAA.
Se o diretório ftp do usuário deve variar do diretório padrão, o comando ftp-directory pode ser usado
para especificar o diretório para o usuário. Se o número de conexões ativas possíveis com uma conta de
usuário local for limitado, o comando de limite de acesso poderá ser aplicado. Isso pode variar de 1 a
800 ou ilimitado quando um limite de acesso não é aplicado.
A configuração de um tempo limite inativo ajuda a impedir o acesso não autorizado no caso de uma
janela de sessão ficar inativa por um período de tempo por um usuário. O comando de tempo limite
inativo é definido em termos de minutos e segundos, com um tempo limite inativo de 0 0
representando que nenhum período de tempo limite é aplicado. Finalmente, o nível de privilégio define
o nível autorizado do usuário em termos dos comandos que podem ser aplicados durante o
estabelecimento da sessão ftp. Isso pode ser definido para qualquer nível de 0 a 15, com um valor maior
indicando um nível mais alto do usuário.
 Configuração do usuário de FTP

Após a configuração do serviço FTP no servidor FTP, é possível que os usuários estabeleçam uma
conexão entre o cliente e o servidor. O uso do comando ftp no cliente estabelecerá uma sessão através
da qual a autenticação AAA será usada para validar o usuário usando autenticação de senha AAA. Se
autenticado corretamente, o cliente poderá configurar, bem como enviar / recuperar arquivos para e do
servidor FTP.

Resumo

1-Quais portas precisam estar abertas para permitir que o serviço FTP funcione?
Para que a conexão de controle e conexão de dados do serviço FTP seja estabelecida com sucesso, as
portas TCP 20 e 21 devem estar habilitadas.

2-Considera-se que um usuário não possui autoridade para acessar qualquer diretório de trabalho.
Quais etapas são necessárias para resolver isso?
Quando um usuário é considerado sem autoridade para acessar qualquer diretório de trabalho, um
diretório de FTP padrão precisa ser definido. Isso é feito usando o comando set default ftp-directory
<diretório local>, onde o nome do diretório pode ser, por exemplo, o sistema flash.
 Prefácio
À medida que a rede corporativa se expande, dispositivos suportados podem existir
em uma distância geográfica maior devido à presença de filiais consideradas parte do
domínio corporativo e que requerem administração remota. Além disso, a administração
da rede é geralmente gerenciada a partir de um local de gerenciamento central, do qual
todos os dispositivos são monitorados e administrados. Para facilitar essa administração,
o protocolo telnet, um dos primeiros protocolos a serem desenvolvidos, é aplicado para
gerenciar dispositivos. Os princípios que envolvem o protocolo e sua implementação são
apresentados nesta seção.

Objectivos
Após a conclusão desta seção, os formandos serão capazes de:
 Explicar a aplicação e os princípios que envolvem o telnet.
 Estabelecer o serviço de telnet no suporte a dispositivos Huawei.
 Aplicativo de Telnet

O Protocolo de Rede de Telecomunicações (Telnet) permite que um terminal faça o login

remotamente em qualquer dispositivo que seja capaz de operar como um servidor telnet e fornece uma
interface operacional interativa através da qual o usuário pode executar operações, da mesma maneira
uma conexão do console. Os hosts remotos não precisam ser conectados diretamente a um terminal de
hardware, permitindo que os usuários aproveitem os recursos onipresentes do IP para gerenciar
remotamente dispositivos de praticamente qualquer local do mundo.

Modelo de cliente / servidor de Telnet

O Telnet opera em um princípio de modelo cliente / servidor para o qual uma conexão TCP telnet é
estabelecida entre uma porta de usuário e a porta telnet do servidor, que por padrão é atribuída como
porta 23. O servidor atende a essa porta conhecida para tais conexões. Uma conexão TCP é full duplex e
identificada pelas portas de origem e de destino. O servidor pode envolver-se em muitas conexões
simultâneas envolvendo suas portas conhecidas e portas de usuário que são atribuídas a partir de um
intervalo de portas não conhecido.
Os drivers de terminal de telnet interpretam os pressionamentos de tecla dos usuários e os
convertem em um padrão universal de caracteres, baseado em um terminal virtual de rede (NVT) que
opera como intermediário virtual entre sistemas, após o qual a transmissão via conexão TCP / IP ao
servidor é executado. O servidor decodifica os caracteres NVT e transmite os caracteres decodificados
para um driver pseudo-terminal que existe para permitir que o sistema operacional receba os caracteres
decodificados.

Modo de autenticação

O acesso ao serviço de telnet geralmente envolve a autenticação do usuário antes que o acesso seja
concedido. Existem três modos principais definidos para a autenticação de telnet.

Configuração Telnet

O estabelecimento de um dispositivo que funciona como um servidor telnet geralmente usa um

esquema de autenticação de senha geral, usado para todos os usuários que se conectam à interface vty
do usuário. Depois que a conectividade IP é estabelecida por meio da implementação de um esquema
de endereçamento adequado, o conjunto de comandos de senha do modo de autenticação é
implementado para o intervalo vty, junto com a senha a ser usada.
 Configuração Telnet

Após a configuração do dispositivo remoto que deve operar como um servidor telnet, o cliente pode
estabelecer uma conexão telnet através do comando telnet e receber o prompt para autenticação. A
senha de autenticação deve corresponder à senha implementada no servidor de telnet como parte da
configuração de autenticação de senha anterior. O usuário será então capaz de estabelecer uma
conexão remota via telnet para o dispositivo remoto operando como um servidor telnet e emular a
interface de comando no cliente telnet local.

Resumo
1-Se o serviço de telnet foi ativado, mas um usuário não consegue estabelecer uma conexão telnet,
quais são as possíveis razões para isso?
Se um usuário não conseguir estabelecer uma conexão telnet, o usuário deve verificar se o
dispositivo que suporta o serviço telnet está acessível. Se o dispositivo puder ser acessado, a senha
deverá ser verificada. Se a senha for considerada correta, o número de usuários que atualmente
acessam o dispositivo via telnet deve ser verificado. Se for necessário estender o número de usuários
que acessam o dispositivo por meio do telnet, o comando maximum-vty <0-15> da interface do usuário
deve ser usado, onde 0-15 indica o número de usuários suportados.