Recomendações

• Site de aprendizagem da Huawei

• http://learning.huawei.com/en

• Huawei e-Learning

• https://ilearningx.huawei.com/portal/#/portal/EBG/51

• Certificação Huawei

• http://support.huawei.com/learning/NavigationAction!createNavi?navId=_31 & lang = en

• Encontre treinamento

• http://support.huawei.com/learning/NavigationAction!createNavi?navId=_trai ningsearch & lang =

en

Mais Informações

• APP de aprendizagem Huawei

版权所有 © 201 9 华为 技术 有限公司

 Certificação Huawei

HCIA-

Roteamento e comutação

INTERMEDIÁRIO

Dispositivo e tecnologia de rede Huawei

Huawei Technologies Co., Ltd.

Copyright © Huawei Technologies Co., Ltd. 2019.

Todos os direitos reservados.

A Huawei possui todos os direitos autorais, exceto referências a outras partes. Nenhuma parte deste documento pode ser

reproduzida ou transmitida de qualquer forma ou por qualquer meio sem o consentimento prévio por escrito da Huawei

Technologies Co., Ltd.

Marcas registradas e permissões

e outras marcas registradas da Huawei são marcas registradas da Huawei Technologies Co., Ltd.

Todas as outras marcas e nomes comerciais mencionados neste documento são propriedade de seus respectivos

proprietários.

Aviso prévio

As informações neste manual estão sujeitas a alterações sem aviso prévio. Todos os esforços foram feitos na

preparação deste manual para garantir a precisão do conteúdo, mas todas as declarações, informações e

recomendações neste manual não constituem garantia de qualquer tipo, expressa ou implícita.

Certificação Huawei

HCIA-Routing & Switching Huawei Networking Technology

e dispositivo

Intermediário

Versão 2.5
 Sistema de Certificação Huawei

Baseando-se em seu forte sistema de certificação e treinamento técnico e profissional e de acordo com os clientes

de diferentes níveis de tecnologia de ICT, a certificação da Huawei está comprometida em fornecer aos clientes uma

certificação profissional autêntica e atende à necessidade de desenvolvimento de engenheiros de qualidade capazes

de apoiar Redes corporativas em face de uma indústria de TIC em constante mudança. O portfólio de certificação da

Huawei para roteamento e comutação (R&S) é composto de três níveis para apoiar e validar o crescimento e o valor

das habilidades e conhecimento do cliente em tecnologias de roteamento e comutação.

O nível de certificação Huawei Certified Network Associate (HCIA) valida as habilidades e o conhecimento dos

engenheiros de rede IP para implementar e oferecer suporte a redes corporativas de pequeno e médio porte. A

certificação HCIA fornece uma base rica de habilidades e conhecimentos para o estabelecimento de tais redes

empresariais, junto com a capacidade de implementar serviços e recursos dentro das redes empresariais existentes,

para apoiar efetivamente as verdadeiras operações da indústria.

A certificação HCIA abrange habilidades básicas para TCP / IP, roteamento, comutação e tecnologias de rede IP

relacionadas, juntamente com produtos de comunicação de dados Huawei, e habilidades para operação e

gerenciamento de plataforma de roteamento versátil (VRP).

A certificação Huawei Certified Network Professional (HCIP-R & S) é destinada a engenheiros de rede corporativa

envolvidos em projeto e manutenção, bem como a profissionais que desejam desenvolver um conhecimento

profundo de roteamento, comutação, eficiência de rede e tecnologias de otimização. HCIP-R & S consiste em três

unidades, incluindo implementação de roteamento empresarial e rede de comutação (IERS), melhoria do

desempenho de rede empresarial (IENP) e implementação de projeto de engenharia de rede empresarial (IEEP), que

inclui roteamento IPv4 avançado e princípios de tecnologia de comutação, segurança de rede, alta disponibilidade e

QoS, bem como aplicação das tecnologias cobertas nos produtos Huawei.

A certificação Huawei Certified Internet Expert (HCIE-R & S) é projetada para imbuir engenheiros com uma variedade

de tecnologias de rede IP e proficiência em manutenção, para o diagnóstico e solução de problemas de produtos

Huawei, para equipar engenheiros com competência profunda em planejamento, design e otimização de redes IP de

grande escala.
 CONTEÚDO

Link de agregação ................................................ .................................................. . 1

Princípios de VLAN ................................................ .................................................. ..14

Roteamento de VLAN ................................................ .................................................. ..... 43

Princípio e configuração de HDLC e PPP ........................................... .... 57

Princípio e configuração do PPPoE ............................................. ................. 85

Tradução do Endereço da Rede............................................... ........................... 105

Listas de controle de acesso ............................................... ............................................ 125

AAA ................................................. .................................................. ................... 139

Protegendo dados com VPN IPSec ............................................. ............................ 151

Encapsulamento de roteamento genérico ............................................... ........................ 168

Protocolo de gerenciamento de rede simples .............................................. .......... 184

Apresentando redes IPv6 ............................................... ............................... 197

Tecnologias de roteamento IPv6 ............................................... ............................... 214

Serviços de aplicativos IPv6-DHCPv6 ............................................. .................... 225

Princípio Básico MPLS ............................................... .......................................... 240

Princípio Básico SR ............................................... ................................................ 266

• A agregação de link refere-se à implementação de um link de tronco que atua como um link ponto a ponto direto,
entre dois dispositivos, como roteadores de peering, switches ou uma combinação de roteador e switch em cada
extremidade do link. A agregação de link consiste em links considerados membros de um tronco Ethernet e
constroem uma associação que permite que os links físicos operem como um único link lógico. O recurso de
agregação de link suporta alta disponibilidade, permitindo que o link físico de uma interface de membro alterne o
tráfego para outro link de membro no caso de falha de uma interface específica. Ao agregar os links, a largura de
banda de uma interface de tronco é combinada, igualando a soma da largura de banda de todas as interfaces
membros, para permitir um aumento efetivo da largura de banda para o tráfego no link lógico. A agregação de link
também pode implementar balanceamento de carga em uma interface de tronco. Isso permite que a interface de
tronco disperse o tráfego entre suas interfaces de membro e, em seguida, transmita o tráfego pelos links de
membro para o mesmo destino, minimizando assim a probabilidade de congestionamento da rede.
• A agregação de link é frequentemente aplicada em áreas da rede corporativa onde a conectividade de alta
velocidade e o potencial de congestionamento podem ocorrer. Isso geralmente equivale à rede central, onde
reside a responsabilidade pela comutação de alta velocidade e onde o tráfego de todas as partes da rede
corporativa geralmente se reúne antes de ser encaminhado para destinos em outras partes da rede ou para
destinos remotos além dos limites da rede corporativa . O exemplo demonstra como os switches centrais (SWA
e SWB) suportam a agregação de link sobre links membros que interconectam os dois dispositivos de switch
centrais, como um meio de garantir que o congestionamento não se acumule em um ponto crítico da rede.
• A agregação de links suporta dois modos de implementação, um modo de balanceamento de carga manual e modo LACP

estático. No modo de balanceamento de carga, as interfaces de membro são adicionadas manualmente a um grupo de

agregação de link (LAG). Todas as interfaces configuradas com balanceamento de carga são definidas em um estado de

encaminhamento. O AR2200 pode realizar o balanceamento de carga com base em endereços MAC de destino, endereços

MAC de origem, OR exclusivo dos endereços MAC de origem e destino, endereços IP de origem, endereços IP de destino

ou OR exclusivo de endereços IP de origem e destino. O modo de balanceamento de carga manual não usa o protocolo de

controle de agregação de link (LACP), portanto, o AR2200 pode usar esse modo se o dispositivo de mesmo nível não

suportar o LACP.

• No modo LACP estático, os dispositivos nas duas extremidades de um link negociam os parâmetros de
agregação trocando pacotes LACP. Após a conclusão da negociação, os dois dispositivos determinam a
interface ativa e a interface inativa. Neste modo, é necessário criar manualmente um Eth-Trunk e adicionar
membros a ele. A negociação LACP determina quais interfaces estão ativas e quais estão inativas. O modo
LACP estático também é conhecido como modo M: N, onde M significa os links de membros ativos que
encaminham dados em um modo de balanceamento de carga, e N representa esses links inativos, mas
fornecendo redundância. Se um link ativo falhar, o encaminhamento de dados é alternado para o link de backup
com a prioridade mais alta e o status do link de backup muda para ativo. No modo LACP estático, alguns links
podem funcionar como links de backup,
• Como uma interface lógica para vincular várias interfaces físicas e retransmitir dados da camada superior, uma
interface de tronco deve garantir que todos os parâmetros das interfaces físicas (interfaces de membro) em
ambas as extremidades do link de tronco sejam consistentes. Isso inclui o número de interfaces físicas, as taxas
de transmissão e modos duplex das interfaces físicas e os modos de controle de tráfego das interfaces físicas,
para as quais deve ser observado que as interfaces de membro podem ser interfaces de camada 2 ou camada 3.
Onde a velocidade da interface não é consistente, ainda é possível para o link de tronco operar, no entanto, as
interfaces que operam em uma taxa mais baixa provavelmente experimentarão perda de quadros.

• Além disso, a sequência do fluxo de dados deve permanecer inalterada. Um fluxo de dados pode ser
considerado um grupo de frames com o mesmo endereço MAC e endereço IP. Por exemplo, a conexão telnet
ou FTP entre dois dispositivos pode ser considerada como um fluxo de dados. Se a interface do tronco não
estiver configurada, os quadros que pertencem a um fluxo de dados ainda podem alcançar seu destino na
ordem correta porque os fluxos de dados são transmitidos por um único link físico. Quando a tecnologia de
tronco é usada, vários links físicos são vinculados ao mesmo link de tronco e os quadros são transmitidos ao
longo desses links físicos. Se o primeiro quadro for transmitido por um link físico e o segundo quadro for
transmitido por outro link físico, é possível que o segundo quadro alcance o destino antes do primeiro quadro.
• Para evitar a desordem de quadros, um mecanismo de encaminhamento de quadros é usado para garantir que os
quadros no mesmo fluxo de dados cheguem ao destino na sequência correta. Esse mecanismo diferencia os fluxos
de dados com base em seus endereços MAC ou endereços IP. Desse modo, os quadros pertencentes ao mesmo
fluxo de dados são transmitidos pelo mesmo link físico. Depois que o mecanismo de encaminhamento de quadros é
usado, os quadros são transmitidos com base nas seguintes regras:

• Quadros com os mesmos endereços MAC de origem são transmitidos pelo mesmo link físico.

• Quadros com os mesmos endereços MAC de destino são transmitidos pelo mesmo link físico.

• Quadros com os mesmos endereços IP de origem são transmitidos pelo mesmo link físico.

• Os quadros com os mesmos endereços IP de destino são transmitidos pelo mesmo link físico.

• Quadros com os mesmos endereços MAC de origem e destino são transmitidos pelo mesmo link físico.

• Quadros com os mesmos endereços IP de origem e destino são transmitidos pelo mesmo link físico.
• O estabelecimento da agregação de links é obtido usando o comando interface Eth-trunk <trunk-id>. Este
comando cria uma interface Eth-Trunk e permite que a visualização da interface Eth-Trunk seja acessada. O
tronco-id é um valor usado para identificar exclusivamente o Eth-trunk e pode ser qualquer valor inteiro de 0 a 63.
Se o Eth-Trunk especificado já existir, é possível entrar diretamente na visualização da interface EthTrunk usando
o comando interface Eth-trunk. Um Eth-Trunk só pode ser excluído se o Eth-Trunk não contiver nenhuma interface
de membro. Ao adicionar uma interface a um Eth-Trunk, as interfaces membro de um Eth-Trunk da camada 2
devem ser interfaces da camada 2 e as interfaces membro de um Eth-Trunk da camada 3 devem ser interfaces da
camada 3. Um Eth-Trunk pode suportar no máximo oito interfaces de membros. Uma interface de membro não
pode ter nenhum serviço ou endereço MAC estático configurado. As interfaces adicionadas a um Eth-Trunk devem
ser interfaces híbridas (o tipo de interface padrão). Uma interface Eth-Trunk não pode ter outras interfaces
Eth-Trunk como interfaces de membro. Uma interface Ethernet pode ser adicionada a apenas uma interface
Eth-trunk.

• Para adicionar a interface Ethernet a outro tronco Eth, a interface Ethernet deve ser excluída do tronco Eth atual

primeiro. As interfaces dos membros de um tronco Eth devem ser do mesmo tipo, por exemplo, uma interface Fast

Ethernet e uma interface Gigabit Ethernet não podem ser adicionadas à mesma interface Eth-trunk. A interface de par

diretamente conectada a uma interface de membro do Eth-Trunk local também deve ser adicionada a um Eth-Trunk,

caso contrário, as duas extremidades não podem se comunicar. Quando as interfaces de membro têm taxas

diferentes, as interfaces com taxas mais baixas podem ficar congestionadas e pode ocorrer perda de pacotes. Depois

que uma interface é adicionada a um Eth-Trunk, o aprendizado do endereço MAC é realizado pelo Eth-Trunk em vez

das interfaces dos membros.

• Para configurar a agregação de link da camada 3 em um link de tronco Ethernet, é necessário fazer a transição do
tronco da camada 2 para a camada 3 usando o desfazer a mudança de porta

comando sob a interface lógica Eth-trunk. Uma vez o desfazer a mudança de porta
tiver sido executado, um endereço IP pode ser atribuído à interface lógica e as interfaces de membro físico que
devem ser associadas ao link de tronco Ethernet podem ser adicionadas.
• Usando o exibir interface eth-trunk <trunk-id> É possível confirmar a implementação bem-sucedida da
Agregação de Link entre os dois dispositivos de peering. O comando também pode ser usado para coletar
estatísticas de tráfego e localizar falhas na interface.

• O estado atual do tronco Eth é definido como UP, sinalizando que a interface está operando normalmente. Onde
a interface mostra como inativo, isso sinaliza que ocorreu um erro na camada física, enquanto um erro
administrativamente inativo reflete que o desligar comando foi usado na interface. O erro específico em caso de
falha pode ser descoberto verificando o status das portas, para as quais todas as portas devem mostrar um
status UP. O balanceamento de carga é suportado quando o peso de todos os links é considerado igual.
• Uma interface Fast Ethernet e uma interface Gigabit Ethernet não podem ser adicionadas à mesma interface
Eth-trunk; qualquer tentativa de estabelecer links de membros de diferentes tipos resultará em um erro
especificando que o tronco adicionou um membro de outro tipo de porta. Deve-se observar que o switch da série
S5700 suporta apenas interfaces Gigabit Ethernet; no entanto, esse comportamento pode ser aplicado a outros
modelos, incluindo o switch S3700.

• Apenas o modo LACP é capaz de suportar links de membros de backup e, portanto, deve ser usado se os links de
backup forem necessários.
• À medida que as redes locais se expandem, o tráfego aumenta e as transmissões se tornam mais comuns. Não há
limites reais dentro de uma rede em expansão, causando interrupções e aumento da utilização do tráfego.
Tradicionalmente, a opção alternativa era implementar um dispositivo de camada três dentro da rede local para gerar
domínios de broadcast, no entanto, ao fazer isso, despesas adicionais foram incorridas e o comportamento de
encaminhamento de tais dispositivos não forneceu um rendimento tão eficiente quanto encontrado com switches,
levando a gargalos em pontos de trânsito entre domínios de broadcast.
• O princípio da tecnologia VLAN foi introduzido, permitindo o isolamento do tráfego na camada de enlace de
dados. A tecnologia VLAN tem a vantagem adicional de isolamento de tráfego sem a limitação de limites físicos.
Os usuários podem estar fisicamente dispersos
mas ainda ser associado como parte de um único domínio de broadcast, isolando logicamente usuários de outros grupos de

usuários na camada de enlace de dados. Hoje, a tecnologia VLAN é aplicada como uma solução para uma variedade de desafios.
• Os quadros de VLAN são identificados usando um cabeçalho de tag que é inserido no quadro Ethernet como um
meio de distinguir um quadro associado a uma VLAN de quadros de outra. O formato da tag VLAN contém um Tag
Protocol Identifier (TPID) e informações de controle de tag (TCI) associadas. O TPID é usado para identificar o
quadro como um quadro marcado, que atualmente se refere apenas ao formato de marca IEEE 802.1Q, para o qual
um valor de 0x8100 é usado para identificar esse formato. O TCI contém campos que estão associados ao tipo de
formato de tag.

• O ponto de código de prioridade (PCP) é uma forma de campo de classificação de tráfego que é usado para diferenciar

uma forma de tráfego de outra, de modo a priorizar o tráfego geralmente com base em uma classificação como voz,

vídeo, dados etc. Isso é representado por um três valor de bit que permite um intervalo de 0-7 e pode ser compreendido

com base nos princípios gerais de classe de serviço (CoS) 802.1p. O indicador de elegibilidade de descarte (DEI)

representa um valor de bit único que existe em um estado Verdadeiro ou Falso para determinar a elegibilidade de um

quadro para descarte em caso de congestionamento.

• O ID da VLAN indica a VLAN à qual o quadro está associado, representada

como um valor de 12 bits. Os valores de ID de VLAN variam de 0x000 a 0xFFF e para os quais os dois valores
superior e inferior são reservados, permitindo 4094 combinações de VLAN possíveis. A implementação de VLANs
da Huawei VRP usa VLAN 1 como VLAN padrão (PVID) com base nos padrões IEEE802.1Q.
• Os links de VLAN podem ser classificados em dois tipos, um tipo de link de acesso e um tipo de link de tronco. O link de

acesso refere-se ao link entre um sistema final e um dispositivo de switch que participa da marcação de VLAN, o link

entre terminais host e switches são todos links de acesso. Um link de tronco refere-se ao link pelo qual os quadros

marcados com VLAN provavelmente serão transportados. Os links entre switches são geralmente entendidos como links

de tronco.
• Cada interface de um dispositivo que participa da marcação de VLAN será associada a uma VLAN. A VLAN
padrão para a interface é reconhecida como o ID da VLAN da porta (PVID). Este valor determina o
comportamento que é aplicado a todos os quadros recebidos ou transmitidos pela interface.
• As portas de acesso associadas aos links de acesso e os quadros recebidos serão atribuídos a uma tag VLAN
igual ao ID da porta VLAN (PVID) da interface. Os quadros transmitidos de uma interface normalmente
removerão a etiqueta VLAN antes de encaminhá-la para um sistema final que não reconhece VLAN. Se a tag
e o PVID variarem, o quadro não será encaminhado e, portanto, descartado. No exemplo, um quadro (não
marcado) é encaminhado para a interface do switch, que pode ser entendido como encaminhamento para
todos os outros destinos.

• Ao receber o quadro, o switch irá associar o quadro à VLAN 10 com base no PVID da interface. O switch é
capaz de identificar na interface da porta o PVID e decidir se o quadro pode ser encaminhado. No caso do
Host C, o PVID corresponde ao VLAN ID na tag VLAN, para a qual a tag é removida e o quadro encaminhado.
No entanto, para o Host B, o quadro e o PVID são diferentes e, portanto, o quadro não pode ser encaminhado
para este destino.
• Para portas de tronco que estão associadas a links de tronco, o Port VLAN ID (PVID) identificará quais quadros de VLAN

são necessários para transportar uma etiqueta de VLAN antes do encaminhamento e quais não são. O exemplo

demonstra uma interface de tronco atribuída com um PVID de 10, para a qual deve ser assumido que todas as VLANs

têm permissão para atravessar o link de tronco. Apenas os quadros associados à VLAN 10 serão encaminhados sem a

tag VLAN, com base no PVID. Para todos os outros quadros de VLAN, uma etiqueta de VLAN deve ser incluída com o

quadro e ser permitida pela porta antes que o quadro possa ser transmitido pelo link de tronco. Os quadros associados à

VLAN 20 são transportados como quadros marcados pelo link de tronco.

• Hybrid representa o tipo de porta padrão para dispositivos Huawei que suportam operação VLAN e fornece um
meio de gerenciar o processo de troca de tag associado a todas as interfaces. Cada porta pode ser considerada
uma porta com ou sem etiqueta. Portas que operam como portas de acesso (não marcadas) e portas que
operam como portas de tronco (marcadas).

• As portas que são consideradas não marcadas geralmente receberão quadros não marcados dos sistemas finais e
serão responsáveis por adicionar uma etiqueta ao quadro com base no ID de VLAN da porta (PVID) da porta. Uma
das principais diferenças está na capacidade da porta híbrida de executar seletivamente a remoção de tags VLAN
de quadros que diferem do PVID da interface da porta. No exemplo, o Host D está conectado a uma porta que
especifica um Port VLAN ID de 20, enquanto ao mesmo tempo está configurado para permitir a remoção da etiqueta
dos quadros recebidos da VLAN 10, permitindo assim que o Host D receba o tráfego de ambas as VLANs 10 e 20.

• As portas híbridas marcadas funcionarão de maneira semelhante a uma interface de tronco regular, mas existe
uma grande diferença. Os quadros de VLAN que correspondem ao PVID e são permitidos pela porta continuarão
a ser marcados quando encaminhados.
• A atribuição de VLAN pode ser implementada com base em um de cinco métodos diferentes, incluindo implementações

baseadas em porta, MAC, IP sub-rede, protocolo e políticas. O método baseado em porta representa o método padrão e

mais comum para atribuição de VLAN. Usando este método, as VLANs são classificadas com base nos números das

portas em um dispositivo de comutação. O administrador da rede configura um ID de VLAN de porta (PVID), que

representa o ID de VLAN padrão para cada porta no dispositivo de comutação. Quando um quadro de dados atinge uma

porta, ele é marcado com o PVID se o quadro de dados não transporta nenhuma etiqueta VLAN e a porta está

configurada com um PVID. Se o quadro de dados transportar uma tag VLAN, o dispositivo de comutação não adicionará

uma tag VLAN ao quadro de dados, mesmo se a porta estiver configurada com um PVID.

• Usando o método de atribuição de endereço MAC, as VLANs são classificadas com base nos endereços MAC das
placas de interface de rede (NICs). O administrador da rede configura os mapeamentos entre endereços MAC e IDs
de VLAN. Nesse caso, quando um dispositivo de comutação recebe um quadro não marcado, ele procura na tabela
MAC-VLAN uma etiqueta VLAN a ser adicionada ao quadro de acordo com o endereço MAC do quadro. Para
atribuição baseada em sub-rede IP, ao receber um quadro não marcado, o dispositivo de comutação adiciona uma
etiqueta VLAN ao quadro com base no endereço IP do cabeçalho do pacote.

• Onde a classificação de VLAN é baseada no protocolo, os IDs de VLAN são alocados para pacotes recebidos em
uma interface de acordo com o tipo de protocolo (suíte) e formato de encapsulamento dos pacotes. O administrador
da rede configura os mapeamentos entre os tipos de protocolos e IDs de VLAN. A atribuição baseada em política
implementa uma combinação de critérios para atribuição da etiqueta VLAN, incluindo a sub-rede IP, porta e
endereço MAC, em que todos os critérios devem corresponder antes que a VLAN seja atribuída.
• A implementação de VLANs começa com a criação da VLAN no switch. O comando vlan <vlan-id> é usado para
criar inicialmente a VLAN no switch que pode ser considerada existente uma vez que o usuário entra na
visualização da VLAN para a vlan fornecida, conforme demonstrado no exemplo de configuração. O ID de
VLAN varia de 1 a 4094 e onde é necessário criar várias VLANs para um switch, o comando vlan batch
<vlan-id1 to vlan-id2> pode ser usado onde intervalos de VLAN contíguos precisam ser criados e vlan batch & <
1-4094> comando usado onde “& '” representa um espaço entre intervalos de VLAN não contíguos. Todas as
portas são associadas à VLAN 1 como a VLAN padrão por padrão e, portanto, o encaminhamento é irrestrito.
• Depois que as VLANs foram criadas, a criação pode ser verificada usando o comando display vlan. O
comando permite que informações sobre todas as VLANs sejam especificadas e, se nenhum parâmetro for
especificado, uma breve informação sobre todas as VLANs será exibida. Parâmetros adicionais incluem o
comando display vlan <vlan-id> verbose, usado para exibir informações detalhadas sobre uma VLAN
especificada, incluindo o ID, tipo, descrição e status da VLAN, status da função de estatísticas de tráfego,
interfaces na VLAN e modo no qual as interfaces são adicionadas à VLAN. O comando display vlan <vlan-id>
statistics permite a exibição de estatísticas de tráfego em interfaces para uma VLAN especificada. O comando
display vlan summary fornece um resumo de todas as VLANs no sistema.
• A configuração do tipo de link de porta é realizada na visualização da interface para cada interface em um
switch VLAN ativo. O tipo de link de porta padrão em dispositivos de switch Huawei é híbrido. o tipo de link de
porta <tipo> O comando é usado para configurar o tipo de link de porta da interface onde o tipo pode ser
definido como acesso, tronco ou híbrido. Existe uma quarta opção do QinQ, mas ela está fora do escopo deste
curso. Também deve ser observado que, na configuração exibida, se nenhum tipo de porta for exibido, o tipo de
link de porta híbrida padrão é configurado. Antes de alterar o tipo de interface, também é necessário restaurar a
configuração de VLAN padrão da interface para que a interface pertença apenas à VLAN 1 padrão.
• A associação de uma porta com uma VLAN criada pode ser conseguida usando dois métodos de configuração,
o primeiro deles é entrar na visualização da VLAN e configurar a interface a ser associada à VLAN usando o porta
<interface> comando. O segundo meio de atribuir portas a VLANs envolve acessar a visualização da interface
para a interface a ser adicionada a uma VLAN e implementar o comando porta padrão <vlan-id> onde o vlan-id refere-se
à VLAN à qual a porta deve ser adicionada.
• O comando display vlan pode ser usado para verificar as alterações feitas na configuração e confirmar a
associação das interfaces de porta com as VLANs às quais as portas foram atribuídas. No exemplo de exibição,
as interfaces de porta Gigabit Ethernet 0/0/5 e Gigabit Ethernet 0/0/7 podem ser identificadas como associadas
às VLANs 2 e 3, respectivamente. O valor UT identifica que a porta é considerada não marcada por meio da
atribuição do tipo de link de porta como uma porta de acesso ou como uma porta híbrida não marcada. O
estado atual do link também pode ser determinado como ativo (U) ou inativo (D).
• A atribuição do tipo de link de porta de interfaces de tronco permite que o tronco suporte o encaminhamento de
quadros de VLAN para VLANs múltiplas entre switches; no entanto, para que os quadros sejam transportados
pela interface de tronco, as permissões devem ser aplicadas. O comando port trunk allow-pass vlan <vlan-id> é
usado para definir a permissão para cada VLAN, onde vlan-id se refere às VLANs a serem permitidas. Também é
necessário que o PVID para a interface de tronco seja incluído no comando para permitir que o tráfego não
marcado seja transportado pelo link de tronco. O exemplo demonstra a alteração do padrão da porta VLAN ID
(PVID) da interface para 10 e a aplicação da permissão para as VLANs 2 e 3 no link de tronco. Nesse caso,
quaisquer quadros associados à VLAN 10 não serão transportados pelo tronco, embora a VLAN 10 agora seja a
VLAN padrão para a porta do tronco. O comando porta trunk allow-pass vlan all pode ser usado para permitir que
todas as VLANs atravessem o link do tronco.
• As alterações nas permissões de VLAN podem ser monitoradas novamente por meio do comando display vlan,
para o qual a aplicação de VLANs no link de tronco é refletida. O valor TG identifica que as VLANs foram
associadas a uma interface marcada em um tronco ou interface de porta híbrida marcada. No exemplo de
exibição, as VLANs 2 e 3 receberam permissão para atravessar a interface marcada Gigabit Ethernet 0/0/1, uma
interface que está atualmente ativa.
• A configuração de porta híbrida representa o tipo de porta padrão nas interfaces de porta do switch e, portanto, o
tipo de link de porta de comando híbrido geralmente só é necessário ao converter o tipo de link de porta de um
acesso ou tipo de link de porta de tronco. Cada porta, entretanto, pode precisar ser associada a uma porta VLAN
ID (PVID) padrão sobre a qual os quadros devem ser marcados ou não marcados. O comando port hybrid pvid
vlan <vlan-id> permite que o PVID padrão seja atribuído em uma base de porta a partir do qual também é
necessário associar o comportamento de encaminhamento para uma determinada porta.

• Para portas que devem operar como portas de acesso, isso é obtido usando o comando port hybrid untagged
vlan <vlan-id>. Deve-se notar claramente que o uso desse comando várias vezes na mesma visualização de
interface deve resultar na interface sendo associada a todas as VLANs especificadas, com os quadros VLAN
associados sendo desmarcados antes do encaminhamento. O comando undo port hybrid vlan pode ser usado
para restaurar a configuração de VLAN padrão de VLAN1 e retornar ao modo não marcado padrão.
• Para portas que operam como portas de tronco, o porta híbrida marcada com vlan <vlan-id>
comando é usado. Deve ser claramente observado que o uso desse comando várias vezes na mesma
visualização de interface deve resultar na interface sendo associada a todas as VLANs especificadas, com os
quadros de VLAN associados sendo marcados antes do encaminhamento. No exemplo, a interface de porta
híbrida Gigabit Ethernet 0/0/1 deve marcar todos os quadros que estão associados às VLANs 2 e 3 antes que
esses quadros sejam encaminhados pela interface.
• Através de exibir vlan , os resultados da configuração da porta híbrida marcada e não marcada podem ser
verificados. A interface Gigabit Ethernet 0/0/7 foi estabelecida como uma interface VLAN 2 não marcada,
enquanto a interface Gigabit Ethernet 0/0/5 foi estabelecida como uma interface não marcada associada à VLAN
3. Em termos de VLAN 2 e VLAN 3, quadros associado a qualquer VLAN será transportado como um quadro
marcado na interface Gigabit Ethernet 0/0/1.
• Interfaces de porta de switch podem usar o porta híbrida não marcada vlan <vlan-id> [para <vlanid>] comando
para aplicar o comportamento não marcado em uma interface de porta para várias VLANs em um único comando
de lote. Esse comportamento permite que interfaces híbridas permitam o encaminhamento não marcado de tráfego
de várias VLANs para um determinado sistema final. Todo o tráfego encaminhado do sistema final é associado ao
PVID atribuído à porta e marcado respectivamente.
• O comando porta híbrida não marcada vlan 2 a 3 na interface Gigabit Ethernet 0/0/4 resulta na interface
aplicando comportamento não marcado para VLAN 2 e VLAN 3. Isso significa que qualquer tráfego
encaminhado de um host associado a qualquer VLAN, para um sistema final associado à interface Gigabit
Ethernet 0/0 / 4, pode ser recebido com sucesso.
• O crescimento da convergência de IP viu a integração de várias tecnologias que permitem que serviços de
Internet de alta velocidade (HSI), serviços de voz sobre IP (VoIP) e serviços de televisão por protocolo de Internet
(IPTV) sejam transmitidos por uma rede Ethernet e TCP / IP comum . Essas tecnologias se originam de redes
que consistem em diferentes formas de comportamento. VoIP se origina de tecnologias de rede comutada por
circuito que envolvem o estabelecimento de um circuito fixo entre a origem e o destino, através do qual um
caminho dedicado é criado, garantindo que os sinais de voz cheguem com pouco atraso e em uma ordem de
sinal primeiro a entrar, primeiro a sair.

• A Internet de alta velocidade opera em uma rede comutada por pacotes envolvendo contenção e
encaminhamento de pacotes sem garantia de entrega ordenada, para a qual o novo sequenciamento de pacotes
é freqüentemente necessário. Garantir que as tecnologias originadas de um conceito de rede comutada por
circuito sejam capazes de funcionar em redes comutadas por pacotes tem trazido novos desafios. Esse desafio
se concentra em garantir que os serviços sejam capazes de diferenciar os dados de voz de outros dados. A
solução envolve o tráfego de VoIP isolado por meio de diferentes VLANs e a atribuição de uma prioridade mais
alta para garantir o rendimento da qualidade de voz. VLANs de voz especiais podem ser configuradas no switch,
o que permite que o switch atribua um ID de VLAN pré-configurado e uma prioridade mais alta para o tráfego
VoIP.
• A configuração da VLAN de voz envolve a configuração de uma VLAN especificada usando o voice-vlan
<vlan-id> ativar comando. A VLAN de voz pode ser associada a qualquer VLAN entre 2 e 4094. O modo
voice-vlan <modo>
comando especifica o modo de trabalho, pelo qual uma interface de porta é adicionada a uma VLAN de voz.
Isso é definido por padrão para ocorrer automaticamente, mas também pode ser feito manualmente. o voice-vlan
mac-address <mac-address> mask <mask>
O comando permite que os pacotes de voz originados de um telefone IP sejam identificados e associados à
VLAN de voz, com base no Organizationally Unique Identifier (OUI), para permitir que uma prioridade mais alta
seja dada ao tráfego de voz.
• O comando display voice-vlan status permite que as informações de VLAN de voz sejam visualizadas, incluindo
o status, modo de segurança, tempo de envelhecimento e a interface na qual a função de VLAN de voz está
ativada. O status determina se a VLAN de voz está habilitada ou desabilitada. O modo de segurança pode existir
em um dos dois modos, normal ou de segurança. O modo normal permite que a interface habilitada com VLAN
de voz transmita dados de voz e dados de serviço, mas permanece vulnerável a ataques de pacotes inválidos.
Geralmente é usado quando vários serviços (HSI, VoIP e IPTV) são transmitidos para uma rede da Camada 2
por meio de uma interface, e a interface transmite dados de voz e dados de serviço. O modo de segurança
aplicado em uma interface habilitada com VLAN de voz verifica se o endereço MAC de origem de cada pacote
que entra na VLAN de voz corresponde ao OUI. É aplicado onde a interface de VLAN de voz transmite
SOMENTE dados de voz. O modo de segurança pode proteger a VLAN de voz contra ataques de pacotes
inválidos, porém a verificação de pacotes ocupa certos recursos do sistema.

• A opção Legacy determina se a interface pode se comunicar com dispositivos de voz de outros fornecedores,
onde uma interface habilitada permite essa comunicação. O Add-Mode determina o modo de trabalho da VLAN
de voz. No modo VLAN de voz automática, uma interface pode ser adicionada automaticamente à VLAN de
voz após a função de VLAN de voz ser habilitada na interface e adiciona a interface conectada a um
dispositivo de voz à VLAN de voz se o endereço MAC de origem dos pacotes enviados do dispositivo de voz
corresponde ao OUI. A interface é excluída automaticamente se não receber nenhum pacote de dados de voz
do dispositivo de voz dentro do tempo de envelhecimento. No modo VLAN de voz manual, uma interface deve
ser adicionada à VLAN de voz manualmente após a função de VLAN de voz ser habilitada na interface.
• O PVID em um link de tronco define apenas o comportamento de marcação que será aplicado na interface de
tronco. Se o comando port trunk allow-pass vlan 2 3 for usado, apenas os quadros associados à VLAN 2 e
VLAN 3 serão encaminhados pelo link de tronco.

• Uma porta de acesso configurada com um PVID de 2 marcará todos os quadros não marcados recebidos com uma etiqueta

VLAN 2. Isso será usado pelo switch para determinar se um quadro pode ser encaminhado por meio de outras interfaces de

acesso ou transportado por um link de tronco.

• O princípio geral da implementação de VLAN é isolar redes como um meio de minimizar o tamanho do domínio de
transmissão existente, no entanto, ao fazer isso, muitos usuários são desligados de outros usuários em outros
domínios de VLAN e exigem que a comunicação da camada três (IP) seja estabelecido para que esses domínios de
broadcast restabeleçam a comunicação por meio de rotas alcançáveis. A implementação de um switch de camada
três oferece um meio ideal para suportar o roteamento de VLAN enquanto reduz os custos operacionais. No
entanto, uma das restrições do roteamento VLAN é a necessidade de gerenciamento estrito do endereço IP.

• Geralmente, entretanto, o princípio de roteamento VLAN é aplicável a redes de pequena escala nas quais os usuários

pertencem a diferentes segmentos de rede e os endereços IP dos usuários raramente são alterados.
• Depois que as VLANs são configuradas, os hosts em diferentes VLANs não conseguem se comunicar
diretamente entre si na camada 2. Portanto, é necessário facilitar a comunicação por meio da criação de rotas
entre as VLANs. Em geral, existem dois métodos principais pelos quais isso é feito; o primeiro depende da
implementação de um roteador conectado ao switch da camada 2. A comunicação da VLAN é então roteada
através do roteador antes de ser encaminhada ao destino pretendido. Isso pode ser feito por meio de links
físicos separados, o que leva ao desperdício de portas e à utilização extra de links, ou por meio da mesma
interface física mostrada no exemplo.

• O segundo método depende do uso de um switch da camada 3 que é capaz de realizar a operação do switch e
do roteador em um único dispositivo como um mecanismo mais econômico.
• Para permitir a comunicação em uma única interface de tronco, é necessário segmentar logicamente o link
físico usando subinterfaces. Cada subinterface representa um link lógico para o encaminhamento do tráfego
VLAN antes de ser roteado pelo roteador por meio de outras subinterfaces lógicas para outros destinos VLAN.
Cada subinterface deve receber um endereço IP no mesmo segmento de rede que a VLAN para a qual foi
criada, bem como o encapsulamento 802.1Q para permitir a associação de VLAN conforme o tráfego é
roteado entre VLANs.

• Também é necessário configurar o tipo de porta Ethernet do switch que se conecta ao roteador como um
tipo de link Tronco ou Híbrido e permitir que os quadros das VLANs associadas (VLAN 2 e VLAN 3 neste
caso) passem.
• O link de tronco entre o switch e o roteador deve ser estabelecido para suporte de tráfego para VLANs
múltiplas, por meio do comando port link-type trunk ou port link-type hybrid, bem como o port trunk allow-pass
vlan 2 3 ou port hybrid vlan 2 3 comando respectivamente. Depois que o tronco é estabelecido, as
subinterfaces de VLAN devem ser implementadas para permitir o encaminhamento lógico de tráfego entre
VLANs no link de tronco.
• A subinterface em um roteador é definida na visualização da interface usando o comando interface
<interface-type interface-number.sub-interface number> em que o número da subinterface representa o canal
de interface lógica dentro da interface física. O comando dot1q termination vid <vlan-id> é usado para executar
duas funções específicas. Quando uma porta recebe um pacote VLAN, ela inicialmente removerá a etiqueta
VLAN do quadro e encaminhará esse pacote por meio do roteamento da camada três.

• Para os pacotes que estão sendo enviados, a porta adiciona uma tag ao quadro antes de enviá-lo, de acordo com as
respectivas configurações de VLAN e IP para a interface lógica do roteador. Finalmente, o comando arp-broadcast
enable é aplicado a cada interface lógica. Isso é necessário porque a capacidade do ARP de transmitir em
subinterfaces não está habilitada por padrão. Se as transmissões ARP permanecerem desabilitadas na subinterface,
o roteador descartará os pacotes diretamente. A rota para a subinterface geralmente é considerada como uma rota
de buraco negro nesses casos, uma vez que o pacote é efetivamente perdido sem deixar rastros. Se as
transmissões ARP estiverem ativadas na subinterface, o sistema poderá construir um pacote de broadcast ARP
marcado e enviar o pacote da subinterface.
• Seguindo a configuração do roteamento de VLAN entre VLAN 2 e VLAN 3, o aplicativo ping pode ser usado
para verificar a acessibilidade. O exemplo demonstra como o Host A (192.168.2.2) na VLAN 2 é capaz de
alcançar o Host B (192.168.3.2) na VLAN
3. O TTL reflete que o pacote atravessou o roteador para alcançar o destino na VLAN 2.
• A implementação de switches L3 traz benefícios ao processo de roteamento de VLAN que não são possíveis com o uso

de um roteador. Um desses recursos é a capacidade de encaminhar o tráfego de VLAN com muito pouco atraso devido

ao suporte do que é conhecido como encaminhamento de velocidade de linha, como resultado de chips ASIC de

camada inferior que permitem que o tráfego seja encaminhado com base em hardware em vez de software. Junto com

isso está o fato de que um único dispositivo é usado sem nenhum link de tronco que pode enfrentar congestionamento

sob cargas de tráfego pesadas. O roteamento VLAN ao usar um switch da camada 3 depende da implementação de

interfaces VLAN (VLANIF). Se vários usuários em uma rede pertencerem a VLANs diferentes, cada VLAN exigirá uma

VLANIF que atue como o gateway da VLAN e, portanto, deverá se associar a um endereço IP relevante para a rede da

VLAN. No entanto, se houver um grande número de VLANs, isso pode corresponder a um grande número de endereços

IP necessários para dar suporte a cada VLANIF, bem como aos hosts que fazem parte da VLAN com a qual a VLANIF

está associada. Por meio da VLANIF, o roteamento entre diferentes VLANs pode ser suportado.
• A configuração do roteamento de VLAN em um switch operando na camada 3 requer que as VLANs sejam
inicialmente criadas e as interfaces sejam atribuídas às respectivas VLANS. A configuração segue os princípios
de configuração de VLANs cobertos como parte dos princípios de VLAN. Isso envolve a definição do tipo de link
de porta para cada porta e o PVID associado a cada interface de porta.
• A configuração do roteamento de VLAN é implementada criando interfaces VLAN que devem operar como
interfaces de gateway para cada VLAN dentro do switch da camada 3. A entrada na visualização VLANIF é feita
por meio do interface vlanif <vlan-id> comando, onde o vlan-id refere-se à VLAN associada. O endereço IP da
interface deve estar no mesmo segmento de rede dos hosts. Este endereço IP deve obrigatoriamente
representar o gateway para os hosts e suportar a comunicação entre VLANs.
• O comando dot1q termination vid <vlan-id> é usado para executar duas funções específicas. Quando uma porta
recebe um pacote VLAN, ela inicialmente removerá a etiqueta VLAN do quadro e encaminhará esse pacote por
meio do roteamento da camada 3. Para os pacotes enviados, a porta adiciona uma etiqueta ao pacote antes de
enviá-lo, de acordo com as respectivas configurações de VLAN e IP da interface lógica do roteador.

• O switch deve ser configurado para permitir que os quadros transportados pelo meio do switch / roteador sejam
marcados, seja por meio do uso do comando trunk ou usando interfaces híbridas marcadas. Além disso, o
tráfego de VLAN deve ser permitido neste link usando o comando port trunk allow-pass vlan <vlan> ou port
hybrid tagged vlan <vlan>.
• As conexões seriais representam uma forma de tecnologia legada que tem sido comumente usada para o suporte de transmissões de rede remota

(WAN). A transmissão de dados como sinais elétricos por meio de um link serial novamente requer uma forma de sinalização para controlar o envio e

o recebimento de quadros como encontrado na Ethernet. As conexões seriais definem duas formas de sinalização que podem ser utilizadas para a

sincronização das transmissões, conhecidas como comunicação assíncrona e síncrona. A sinalização assíncrona funciona com base no princípio de

enviar bits adicionais denominados bits de início e parada com cada byte ou quadro para permitir que o nó receptor esteja ciente do quadro de

entrada e, assim, redefina periodicamente o tempo entre os quadros para garantir que as taxas entre a transmissão e a recepção são mantidas. O bit

inicial é sempre representado como um valor de bit 0, enquanto o bit de parada representa um valor de 1 bit. Uma das principais preocupações com

esse método de sinalização é a sobrecarga adicional como resultado de cada quadro entregue, com os bits de início e parada representando uma

grande porcentagem do quadro geral. Esse método, entretanto, é comumente associado a tecnologias como o Modo de transferência assíncrona

(ATM), uma forma de tecnologia de comutação de células que gera quadros de tamanho fixo (células) de 53 bytes como meio de suportar jitter

inferior por meio da minimização dos tempos de processamento da fila, tornando-o ideal para comunicação em tempo real, como voz, mas começou

a abrir caminho para tecnologias mais novas, como comutação MPLS e devido à perda de sua vantagem sobre as velocidades de processamento de

quadros que agora são possíveis com roteadores e switches. Uma das principais preocupações com esse método de sinalização é a sobrecarga

adicional como resultado de cada quadro entregue, com os bits de início e parada representando uma grande porcentagem do quadro geral. Esse

método, entretanto, é comumente associado a tecnologias como o Modo de transferência assíncrona (ATM), uma forma de tecnologia de comutação

de células que gera quadros de tamanho fixo (células) de 53 bytes como meio de suportar jitter inferior por meio da minimização dos tempos de

processamento da fila, tornando-o ideal para comunicação em tempo real, como voz, mas começou a abrir caminho para tecnologias mais novas,

como comutação MPLS e devido à perda de sua vantagem sobre as velocidades de processamento de quadros que agora são possíveis com

roteadores e switches. Uma das principais preocupações com esse método de sinalização é a sobrecarga adicional como resultado de cada quadro

entregue, com os bits de início e parada representando uma grande porcentagem do quadro geral. Esse método, entretanto, é comumente associado

a tecnologias como o Modo de transferência assíncrona (ATM), uma forma de tecnologia de comutação de células que gera quadros de tamanho fixo (células) de 53 by

• As conexões seriais síncronas dependem de um mecanismo de relógio entre os dispositivos de peering em que
um lado (DCE) fornece o relógio para sincronizar a comunicação. Esse relógio é mantido por meio do transporte
de informações de relógio entre o emissor e o receptor como parte do sinal de dados.
• O controle de link de dados de alto nível (HDLC) é um protocolo de link de dados orientado a bits que é capaz de

suportar transmissões de dados síncronas e assíncronas. Um quadro HDLC completo consiste nos campos

Sinalizadores que são usados para marcar o início e o fim de um quadro HDLC, frequentemente como 01111110 ou

01111111 quando um quadro deve ser abortado e descartado repentinamente. Um campo de endereço oferece

suporte a situações multiponto em que um ou vários terminais secundários se comunicam com um terminal primário

em uma topologia multiponto (multidrop) conhecida como conexões não balanceadas, em oposição às conexões

balanceadas mais comumente aplicadas (ponto a ponto). O campo de controle define o tipo de quadro como

informação, supervisório ou não numerado, e o campo de sequência de verificação de quadro (FCS) para garantir a

integridade do quadro.

• Dos tipos de quadro de campo de controle, apenas o tipo de quadro de informação é compatível com os roteadores da série

Huawei ARG3 e é usado para transportar dados. O tipo de quadro de informação transporta números de sequência de envio N

(S) e recebimento de N (R), bem como bits de pesquisa e final (P / F) para o status de comunicação entre as estações primárias

e secundárias. Os tipos de quadro de supervisão em HDLC são usados para controle de erro e fluxo e os tipos de quadro não

numerados são usados para gerenciar o estabelecimento do link, por exemplo, entre as estações primárias e secundárias.
• O estabelecimento de HDLC como o protocolo da camada de link em conexões seriais requer simplesmente que
o protocolo de link seja atribuído usando o comando hdlc do protocolo de link na visualização da interface para a
interface serial configurada para usar o protocolo. A configuração do protocolo de link deve ser realizada em
ambas as interfaces de peering que estão conectadas à rede ponto a ponto antes que a comunicação possa ser
alcançada.
• Quando uma interface não tem endereço IP, ela não pode gerar rotas ou encaminhar pacotes. O mecanismo
não numerado de endereço IP permite que uma interface sem um endereço IP peça emprestado um endereço
IP de outra interface. O mecanismo não numerado de endereço IP permite efetivamente a conservação de
endereços IP e não exige que uma interface ocupe um endereço IP exclusivo o tempo todo. Recomenda-se que
a interface atribuída como a interface da qual o endereço IP não numerado é emprestado seja uma interface de
loopback, pois é mais provável que esse tipo de interface esteja sempre ativa e, como tal, forneça um endereço
disponível.

• Ao usar um endereço não numerado, uma rota estática ou protocolo de roteamento dinâmico deve ser configurado para

que a interface que toma emprestado o endereço IP possa gerar uma rota entre os dispositivos. Se um protocolo de

roteamento dinâmico for usado, o comprimento da máscara de rota aprendida deve ser maior do que a máscara de

endereço IP do credor, porque os roteadores da série ARG3 usam a regra de correspondência mais longa ao pesquisar

rotas. Se uma rota estática for usada e o endereço IP do credor usar uma máscara de 32 bits, o comprimento da

máscara de rota estática deve ser menor que 32 bits. Se uma rota estática for usada e o endereço IP do credor usar uma

máscara menor que 32 bits, o comprimento da máscara de rota estática deve ser maior do que o da máscara de

endereço IP do credor.
• Por meio do comando display ip interface brief, um resumo da atribuição de endereço é gerado. No caso de
atribuição de um endereço não numerado, o valor do endereço será exibido como estando presente em várias
interfaces, mostrando que o endereço IP foi emprestado com êxito da interface de loopback lógica para uso na
interface serial física.
• O protocolo ponto a ponto (PPP) é um protocolo da camada de enlace que encapsula e transmite pacotes da
camada de rede em enlaces ponto a ponto (P2P). O PPP suporta transmissão de dados ponto a ponto em
links full-duplex síncronos e assíncronos.

• O PPP é baseado no protocolo SLIP (Serial Line Internet Protocol). O PPP oferece suporte a links síncronos e
assíncronos, enquanto outros protocolos de camada de link de dados, como Frame Relay (FR), oferecem suporte
apenas a links síncronos. O PPP é um protocolo extensível, facilitando a extensão não só do IP, mas também de
outros protocolos e é capaz de suportar a negociação de atributos da camada de enlace. O PPP oferece suporte a
vários protocolos de controle de rede (NCP), como o protocolo de controle IP (IPCP) e o protocolo de controle de
intercâmbio de pacotes entre redes (IPXCP) para negociar os diferentes atributos da camada de rede. O PPP fornece
o protocolo de autenticação de senha (PAP) e o protocolo de autenticação de handshake de desafio (CHAP) para
autenticação de segurança de rede. O PPP não possui mecanismo de retransmissão, reduzindo o custo da rede e
agilizando a transmissão de pacotes.
• O encapsulamento PPP fornece multiplexação de diferentes protocolos da camada de rede simultaneamente no
mesmo link, entretanto, nas redes atuais, a capacidade do PPP geralmente requer uma solução apenas IP. A
versatilidade do PPP para acomodar uma variedade de ambientes é bem suportada pelo Link Control Protocol
(LCP). Para estabelecer comunicações por meio de um link ponto a ponto, cada extremidade do link PPP deve
primeiro enviar pacotes LCP para configurar e testar o link de dados. Mais especificamente, o LCP é usado para
negociar e estabelecer acordo para opções de formato de encapsulamento, gerenciar o MRU de pacotes,
detectar um link de retorno por meio de números mágicos e determinar erros em termos de configurações
incorretas de parâmetro, bem como encerrar um link estabelecido. Autenticação de pares no link,

• Depois que o link foi estabelecido e os recursos opcionais foram negociados conforme exigido pelo componente
LCP do PPP, os pacotes NCP devem ser enviados para escolher e configurar um ou mais protocolos da camada
de rede. Os protocolos de controle de rede baseados em IP típicos permitem recursos como configuração de
endereço (IPCP) e TCP / IP compactado (van Jacobson).
• Este início e término de um link PPP começa e termina com a fase morta. Quando dois dispositivos de
comunicação detectam que o link físico entre eles está ativado (por exemplo, sinais de portadora são
detectados no link físico), o PPP fará a transição da fase Morto para a fase Estabelecer. Na fase Estabelecer,
os dois dispositivos realizam uma negociação LCP para negociar o modo de trabalho como link único (SP) ou
multi-link (MP), a Unidade de Recepção Máxima (MRU), modo de autenticação etc.

• Se o modo de autenticação for definido, a fase opcional de autenticação será iniciada. O PPP fornece dois
modos de autenticação de senha: autenticação PAP e autenticação CHAP. Dois modos de autenticação
CHAP estão disponíveis: autenticação CHAP unidirecional e autenticação CHAP bidirecional. Na
autenticação CHAP unidirecional, o dispositivo em uma extremidade funciona como o dispositivo de
autenticação e o dispositivo na outra extremidade funciona como o dispositivo autenticado. Na autenticação
CHAP bidirecional, cada dispositivo funciona como dispositivo de autenticação e dispositivo autenticado. Na
prática, entretanto, apenas a autenticação CHAP unidirecional é usada. Após a autenticação bem-sucedida, a
fase de rede é iniciada, por meio da qual a negociação NCP é realizada para selecionar e configurar um
protocolo de rede e negociar a camada de rede.

• Parâmetros. Cada NCP pode estar em um estado Aberto ou Fechado a qualquer momento. Depois que um NCP entra no

estado Aberto, os dados da camada de rede podem ser transmitidos pelo link PPP.

• O PPP pode encerrar um link a qualquer momento. Um link pode ser encerrado manualmente por um
administrador ou devido à perda da operadora, falha de autenticação ou outras causas.
• O PPP geralmente adota uma arquitetura de quadro semelhante ao HDLC para a transmissão em conexões
seriais. Os campos de bandeira são adotados para denotar o início e o fim de um quadro PPP que é identificável a
partir da seqüência binária 01111110 (0x7E). O campo de endereço, embora presente, não se aplica ao PPP como
é o caso do HDLC e, portanto, deve sempre conter um valor 11111111 (0xFF), que representa um endereço
'AllStations'. O campo de controle também é fixado com um valor de 00000011 (0x03) representando o comando
de informação não numerado.

• A sequência de verificação de quadro (FCS) é geralmente um valor de 16 bits usado para manter a integridade do
quadro PPP. O PPP define adicionalmente um campo de protocolo de 8 ou 16 bits que identifica o datagrama
encapsulado no campo de informação do pacote. Exemplos típicos podem incluir 0xc021 para protocolo de controle
de link, 0xc023 para protocolo de autenticação de senha e 0xc223 para protocolo de autenticação de handshake de
desafio. O campo Informações contém o datagrama para o protocolo especificado no campo Protocolo.

• O comprimento máximo do campo Informações (sem incluir o campo Protocolo) é definido pela Unidade
Máxima de Recebimento (MRU), cujo padrão é 1500 bytes. Onde o valor 0xc021 é implementado, os
dispositivos de comunicação negociam trocando pacotes LCP para estabelecer um link PPP.

• O formato do pacote LCP carrega um campo de tipo de código que faz referência a vários tipos de pacote durante a
negociação PPP, para os quais exemplos comuns incluem ConfigureRequest (0x01), Configure-Ack (0x02),
Terminate-Request (0x05) etc. O campo Data carrega vários tipos de suporte / comprimento / valor (TLV) opções
para negociação, incluindo MRU, protocolos de autenticação etc.
• Como parte da negociação LCP, vários tipos de pacote são definidos que permitem que os parâmetros sejam
acordados antes que um link de dados PPP seja estabelecido. É necessário que os dois dispositivos de
comunicação negociem os atributos da camada de enlace, como MRU e modo de autenticação. Para conseguir
isso, vários tipos de pacotes são comunicados.

• O tipo de pacote Configure-Request permite o início da negociação LCP entre dispositivos de peering e deve ser
transmitido nessas ocasiões. Qualquer tipo de pacote Configure-Request enviado deve ser respondido, e isso
pode ser feito por meio de um dos vários tipos de pacote de resposta. Onde todas as opções de configuração
recebidas em um Configure-Request são reconhecíveis e todos os valores são aceitáveis, um tipo de pacote
Configure-Ack será transmitido.

• Onde todas as opções de configuração recebidas no tipo de pacote Configure-Request são reconhecidas, mas
alguns valores não são aceitos, um tipo de pacote Configure-Nak será transmitido e contém apenas as opções de
configuração não aceitas originalmente recebidas no tipo de pacote Configure-Request. Um Configure-Reject é
usado quando certas opções de configuração recebidas em um Configure-Request não são reconhecíveis e,
portanto, não são aceitas para negociação.
• Algumas das opções de configuração comuns que são negociadas e transportadas como parte do pacote LCP
incluem o MRU, o protocolo de autenticação suportado pelo par de envio, bem como o número mágico.

• O número mágico fornece um método para detectar links em loop e outras anomalias na camada de link de
dados. No caso em que um Configure-Request é recebido contendo um Magic-Number como uma opção de
configuração, o MagicNumber recebido é usado para comparar várias mensagens Configure-Request recebidas
enviadas ao par por comparação com o Magic-Number. Se os dois números mágicos das mensagens de
solicitação de configuração recebidas forem diferentes, então o link é entendido como um link sem loop para o
qual uma confirmação de solicitação pode ser fornecida em resposta. Se os dois números mágicos forem iguais,
no entanto, existe a possibilidade de que o link seja retornado e que mais verificações devem ser realizadas para
este pedido de configuração, e é feito enviando um configurar-Nak para efetivamente solicitar um mágico
diferente - Valor numérico.
• A seqüência de eventos que leva ao estabelecimento do PPP entre dois pares é iniciada pelo envio de um
pacote Configurar-Solicitação ao dispositivo de peering. Ao receber este pacote, o receptor deve avaliar as
opções de configuração para determinar o formato do pacote para responder. No caso de todas as opções de
configuração recebidas serem aceitáveis e reconhecidas, o receptor responderá com um pacote
Configure-Ack.
• Após a transmissão inicial do Configure-Request como parte da negociação PPP, também é possível que um
Configure-Nak seja retornado, em particular onde todas as opções de configuração são reconhecidas, mas
alguns valores não são aceitos. Na recepção do pacote Configure-Nak, um novo Configure-Request é gerado
e enviado, no entanto, as opções de configuração geralmente podem ser modificadas para as especificações
no pacote Configure-Nak recebido.

• Várias instâncias de uma opção de configuração podem ser especificadas pelo pacote ConfigureNak para o
qual o par deve selecionar um único valor para incluir no próximo pacote Configure-Request.
• Para a negociação PPP LCP na qual uma ou várias opções de configuração recebidas em um Configure-Request
não são reconhecidas ou são consideradas não aceitáveis para negociação, um pacote Configure-Reject é
transmitido. A recepção de um Configure-Reject válido indica que quando um novo Configure-Request for enviado,
e todas as opções de configuração que são transportadas junto com o pacote Configure-Reject devem ser
removidas das opções de configuração a serem enviadas como parte do seguinte Configure-Request pacote.
• O estabelecimento do PPP requer que o protocolo da camada de enlace na interface serial seja especificado.
Para a série de roteadores ARG3, o PPP é habilitado por padrão na interface serial. No caso em que a interface
não está suportando PPP, o comando linkprotocol ppp é usado para habilitar o PPP na camada de enlace. A
confirmação da mudança do protocolo de encapsulamento será solicitada, para a qual a aprovação deve ser
dada conforme demonstrado no exemplo de configuração.
• O protocolo de autenticação de senha (PAP) é um protocolo de autenticação de handshake bidirecional que
transmite senhas em texto simples. A autenticação PAP é executada durante o estabelecimento do link inicial.
Depois que a fase de estabelecimento do link for concluída, o nome do usuário e a senha são enviados
repetidamente pelo par para o autenticador até que a autenticação seja confirmada ou a conexão seja encerrada.
A autenticação PAP simula efetivamente as operações de login nas quais as senhas em texto simples são usadas
para estabelecer o acesso a um host remoto. O dispositivo autenticado envia o nome de usuário local e a senha
para o autenticador. O autenticador verifica o nome do usuário e a senha do dispositivo autenticado em uma
tabela de usuário local e envia uma resposta apropriada ao dispositivo autenticado para confirmar ou rejeitar a
autenticação.
• O protocolo de autenticação de handshake de desafio (CHAP) é usado para verificar periodicamente a
identidade do par usando um handshake de três vias. Isso é feito no estabelecimento do link inicial e pode ser
repetido periodicamente. O princípio distintivo do CHAP está na proteção fornecida ao evitar a transmissão de
qualquer senha pelo link, em vez de depender de um processo de desafio e resposta que só pode ser
bem-sucedido se o autenticador e os dispositivos autenticados oferecerem suporte a um valor conhecido como
segredo. Um algoritmo como o MD5 é comumente usado para fazer hash de qualquer desafio e resposta, para
garantir a integridade do valor e do valor hash resultante, e é comparado a um resultado gerado pelo
autenticador. Se a resposta e o valor criado pelo autenticador corresponderem, o par autenticado será
aprovado.
• O IP Control Protocol (IPCP) é responsável por configurar, habilitar e desabilitar os módulos do protocolo IP em
ambas as extremidades do link ponto a ponto. O IPCP usa o mesmo mecanismo de troca de pacotes que o Link
Control Protocol (LCP). Os pacotes IPCP não podem ser trocados até que o PPP alcance a fase de rede.
Espera-se que os pacotes IPCP recebidos antes que esta fase seja alcançada sejam descartados silenciosamente.
A opção de configuração de negociação de endereço fornece uma maneira de negociar o endereço IP a ser usado
na extremidade local do link, para o qual um método definido estaticamente permite que o remetente da solicitação
de configuração indique qual endereço IP é desejado. Após a configuração do endereço IP, uma mensagem
ConfigureRequest é enviada contendo o endereço IP solicitado para ser usado, seguido por um Configure-Ack do
dispositivo de peering para afirmar que o endereço IP é aceito.
• Um dispositivo local operando como um cliente e precisando ser atribuído um endereço IP na faixa do
dispositivo remoto (servidor) deve fazer uma solicitação de um endereço válido, aplicando o comando ip
address-ppp negociate na interface física com a qual o cliente peers com o servidor. Por meio desse método,
um cliente pode recuperar um endereço válido. Isso é aplicável em cenários em que um cliente acessa a
Internet por meio de uma rede do Provedor de Servidor da Internet (ISP) e por meio da qual pode obter um
endereço IP do ISP. Um endereço é proposto ao cliente ao receber uma solicitação de configuração para a qual
nenhum endereço IP foi definido. O servidor PPP (RTB) responderá com um Configure-Nak que contém os
parâmetros de endereço IP sugeridos para RTA.
• O estabelecimento da autenticação PAP requer que um peer opere como autenticador para autenticar um
peer autenticado. Espera-se que o autenticador PPP PAP defina o modo de autenticação, um nome de
usuário e senha locais e o tipo de serviço. Se for definido um domínio ao qual o usuário local pertence
(conforme definido pelo AAA), o domínio de autenticação também deverá ser especificado no modo de
autenticação PAP.

• Um par autenticado requer que um nome de usuário de autenticação e uma senha de autenticação sejam
especificados em relação ao nome de usuário e senha definidos pelo autenticador. A senha do usuário local do
ppp pap <nome do usuário> {cipher | O comando simples} <password> é configurado no dispositivo autenticado
para conseguir isso.
• Por meio de comandos de depuração que fornecem uma saída em tempo real de eventos em relação a protocolos

específicos, o processo de solicitação de autenticação pode ser visualizado. Conforme exibido no exemplo, uma solicitação

de autenticação PAP é executada para a qual o estabelecimento de autenticação é considerado bem-sucedido.

• Na autenticação CHAP, o dispositivo autenticado envia apenas o nome do usuário ao dispositivo de autenticação.
O CHAP é conhecido por oferecer maior segurança, já que as senhas não são transmitidas pelo link, em vez disso,
depende de valores hash para fornecer desafios ao dispositivo autenticado com base no valor de senha
configurado em ambos os dispositivos de peering. Em sua forma mais simples, o CHAP pode ser implementado
com base nas atribuições do usuário local como no PAP, ou pode envolver formas mais rigorosas de autenticação
e contabilidade obtidas através de AAA e

servidores de autenticação / contabilidade.

• As demonstrated, the configuration of CHAP based on locally defined users requires limited configuration of
local user parameters and the enablement of PPP CHAP authentication mode on the authenticator device.
Where domains exist, the authenticator may also be required to define the domain being used if different from
the default domain.
• A depuração dos processos de autenticação CHAP exibe os estágios envolvidos com a autenticação CHAP,
originando-se da escuta na interface de quaisquer desafios recebidos após a negociação LCP. No caso de um
desafio ser enviado, o dispositivo autenticado deve fornecer uma resposta para a qual um valor hash é gerado,
envolvendo os parâmetros de autenticação definidos no par autenticado (senha), que o autenticador irá validar
prontamente e fornecer uma resposta de sucesso ou falha para.
• Um pacote Configure-Ack é necessário para permitir que a camada de link seja estabelecida com sucesso ao

usar PPP como o modo de encapsulamento da camada de link.

• O Internet Protocol Control Protocol (IPCP) é usado para negociar os módulos do protocolo IP como parte do
processo de negociação do NCP. Isso ocorre durante a fase de estabelecimento da rede PPP.
• DSL representa uma forma de tecnologia de banda larga que utiliza as redes de telefonia existentes para permitir a
comunicação de dados. A comunicação é facilitada por meio de uma unidade transceptora remota ou modem nas
instalações do cliente, que se comunica através das linhas telefônicas existentes para uma unidade transceptora de
escritório central que assume a forma de Digital Subscriber Line Access Multiplexer (DSLAM), onde o tráfego é
multiplexado em um alto velocidade ATM ou rede Ethernet antes de chegar ao servidor de acesso remoto de banda
larga (BRAS) ou servidor PPPoA / PPPoE dentro da rede do provedor de serviços.

• A distância entre os dois transceptores pode variar dependendo da tecnologia DSL específica aplicada. No caso
de uma Linha Assíncrona de Assinante Digital (ADSL), a distância se expande até cerca de 18.000 pés ou 5.460
metros tradicionalmente em uma rede ATM, enquanto com uma Linha de Assinante Digital de Muito Alta
Velocidade (VDSL2), distâncias de loop local de apenas cerca de 1500 metros são suportados com tecnologia de
fibra (FTTx) aplicada para fornecer transmissão back-end baseada em Ethernet para o BRAS (servidor PPPoE).
• PPPoE refere-se ao encapsulamento de PPP em frames Ethernet para suportar uma conexão por tecnologias
de banda larga a um servidor de acesso remoto de banda larga PPPoE (BRAS), localizado dentro da rede do
provedor de serviços. Isso é usado para oferecer suporte ao processo de autenticação e contabilidade antes
que o acesso à rede remota, como a Internet, seja fornecido. O roteador RTA opera como o cliente para o
estabelecimento da sessão PPPoE com o servidor PPPoE por meio do qual uma conexão autorizada é
estabelecida para acesso a redes e recursos remotos. O modem DSL fornece a modulação e demodulação de
sinais através da infraestrutura de fio telefônico de cobre que tradicionalmente existe em residências e
escritórios.
• O PPPoE tem dois estágios distintos, inicialmente há um estágio de Descoberta seguido por um estágio de Sessão
PPP. Quando um cliente deseja iniciar uma sessão PPPoE, ele deve primeiro realizar a descoberta, para a qual
estão envolvidos quatro estágios, e contar com quatro tipos de pacotes individuais para o processo de descoberta.
Estes incluem os tipos de pacote de protocolo PPPoE Active Discovery Initiation (PADI), PPPoE Active Discovery
Offer (PADO), PPPoE Active Discovery Request (PADR) e PPPoE Active Discovery Session-confirmation (PADS). O
processo de término da sessão PPPoE utiliza um pacote PPPoE Active Discovery Terminate (PADT) para o
fechamento da sessão PPPoE.
• No estágio de descoberta, quando um cliente (RTA) acessa um servidor usando PPPoE, o cliente deve
identificar o endereço MAC Ethernet do servidor e estabelecer um ID de sessão PPPoE. Quando o estágio de
descoberta é concluído, ambos os pares conhecem o PPPoE Session_ID e o endereço Ethernet do par. O
PPPoE Session_ID e o endereço Ethernet do par definem a sessão PPPoE exclusiva. O cliente transmitirá um
pacote PPPoE Active Discovery Initiation (PADI). Este pacote contém as informações de serviço exigidas pelo
cliente. Depois de receber esse pacote PADI, todos os servidores no intervalo comparam os serviços solicitados
aos serviços que podem fornecer. No pacote PADI, o Destination_address é um endereço de broadcast, o
campo Code é definido como 0x09 e o campo Session_ID é definido como 0x0000.
• Os servidores que podem fornecer os serviços solicitados devolvem pacotes PPPoE Active Discovery Offer
(PADO). O cliente (RTA) pode receber mais de um pacote PADO de servidores. O endereço de destino é o
endereço unicast do cliente que enviou o pacote PADI. O campo Código é definido como 0x07 e o campo
Session_ID deve ser definido como 0x0000.
• Como o pacote PADI é transmitido, o cliente pode receber mais de um pacote PADO. Ele examina todos os
pacotes PADO recebidos e escolhe um baseado no AC-Name (que significa o nome do Access Concentrator, e
geralmente se refere a um valor que distingue exclusivamente um servidor de outro), ou os serviços oferecidos
pelo pacote PADO. O cliente verifica os pacotes PADO para escolher um servidor e envia um pacote PPPoE
Active Discovery Request (PADR) para o servidor escolhido. O endereço de destino é definido como o
endereço unicast do servidor de acesso que enviou o pacote PADO selecionado. O campo de código é definido
como 0x19 e o campo de ID da sessão é definido como 0x0000.
• Ao receber um pacote PADR, o servidor de acesso se prepara para iniciar uma sessão PPPoE. Ele gera um ID de
sessão exclusivo para a sessão PPPoE e responde ao cliente com um pacote de confirmação de sessão de
descoberta ativa PPPoE (PADS). O campo de endereço de destino é o endereço Ethernet unicast do cliente que
envia o pacote PADR. O campo de código é definido como 0x65 e o ID da sessão deve ser definido como o valor
criado para esta sessão PPPoE. O servidor gera um identificador de sessão único para identificar a sessão
PPPoE com o cliente e envia esse identificador de sessão ao cliente com o pacote PADS. Se nenhum erro
ocorrer, o servidor e o cliente entram no estágio de Sessão PPPoE.
• Assim que a sessão PPPoE começa, os dados PPP são enviados como em qualquer outro encapsulamento PPP. Todos os

pacotes Ethernet são unicast. O campo ETHER_TYPE é definido como 0x8864. O código PPPoE deve ser definido como

0x00. O SESSION_ID não deve ser alterado para aquela sessão PPPoE e deve ser o valor atribuído no estágio de

descoberta. A carga útil PPPoE contém um quadro PPP. O quadro começa com o ID do protocolo PPP.
• No processo de estabelecimento da sessão PPPoE, a negociação PPP LCP é realizada, no ponto em que a unidade

máxima de recepção (MRU) é negociada. A Ethernet normalmente tem um tamanho máximo de carga útil de 1500

bytes, em que o cabeçalho PPPoE tem 6 bytes e o ID do protocolo PPP tem 2 bytes, a unidade máxima de recepção

PPP (MRU) não pode ser maior que 1492 bytes, pois isso provavelmente causará fragmentação do pacote. Quando o

LCP é encerrado, o cliente e o concentrador de acesso (servidor) param de usar essa sessão PPPoE. Se o cliente

precisar iniciar outra sessão PPP, ele retornará ao estágio de Descoberta.

• O pacote PPPoE Active Discovery Terminate (PADT) pode ser enviado a qualquer momento após uma sessão ser

configurada para indicar que uma sessão PPPoE foi encerrada. Pode ser enviado pelo cliente ou servidor de acesso. O

campo de endereço de destino é um endereço Ethernet unicast. O campo Código é definido como 0xA7 e o ID da sessão

deve ser definido para indicar a sessão a ser encerrada. Nenhuma tag é necessária no pacote PADT. Quando um pacote

PADT é recebido, nenhum tráfego PPP pode ser enviado nesta sessão PPPoE. Depois que um pacote PADT é enviado ou

recebido, mesmo os pacotes de terminação PPP normais não podem ser enviados. Um par PPP deve usar o protocolo PPP

para encerrar uma sessão PPPoE, mas o pacote PADT pode ser usado quando o PPP não pode ser usado.
• Três etapas individuais são necessárias na configuração de um cliente PPPoE, começando com a configuração
de uma interface de discador. Isso permite que a conexão seja estabelecida sob demanda e uma conexão de
sessão seja desconectada após permanecer ociosa por um período de tempo. O comando dialer-rule permite que
a visão dialerrule seja acessada a partir da qual a regra dialer pode ser configurada para definir as condições
para iniciar a conexão PPPoE.

• O usuário discador escolhe uma interface discadora na qual receberá uma chamada de acordo com o nome do
usuário remoto negociado pelo PPP. O usuário discador ativa o centro de controle de discagem e indica o nome do
usuário final remoto, que deve ser igual ao nome do usuário PPP no servidor final remoto. Se o parâmetro de nome
de usuário não for especificado ao usar o comando undo dialer user, a função dial control center será desabilitada e
todos os nomes de usuários remotos serão excluídos. Se este parâmetro for especificado, apenas o nome de usuário
especificado será excluído. O comando dialer bundle <number> no AR2200E é usado para vincular interfaces físicas
e interfaces de discador.

• Os parâmetros de autenticação PPP são definidos para autenticação da conexão do cliente com o servidor
junto com o comando ip address ppp-negotte para negociação em uma interface, para permitir que a interface
obtenha um endereço IP do dispositivo remoto.
• A segunda etapa envolve o estabelecimento da ligação de sessão PPPoE do pacote do discador à interface
sobre a qual a negociação deve ocorrer para os parâmetros do discador configurados. O comando
pppoe-client dial-bundle-number <number> é usado para fazer isso, onde o número se refere ao número do
bundle configurado como parte dos parâmetros do discador.

• Se on-demand não for especificado, a sessão PPPoE funcionará no modo online permanente. Se este
parâmetro for especificado, a sessão PPPoE funcionará no modo de discagem sob demanda. O AR2200
suporta o modo de disparo de pacote para discagem sob demanda. No modo online permanente, o AR2200
inicia uma sessão PPPoE imediatamente após o link físico ser ativado. A sessão PPPoE persiste até que o
comando undo pppoe-client dial-bundle-number seja usado para excluí-la. No modo online acionado, o AR2200
não inicia uma sessão PPPoE imediatamente após o link físico ser ativado. Em vez disso, o AR2200 inicia uma
sessão PPPoE apenas quando os dados precisam ser transmitidos no link. Se nenhum dado for transmitido no
link PPPoE dentro do intervalo especificado pelo dialer timer idle <seconds>, o AR2200 encerrará a sessão
PPPoE.

• A etapa final requer que uma rota estática padrão seja configurada para permitir que qualquer tráfego para o qual um destino

de rede não esteja definido como uma correspondência mais longa na tabela de roteamento inicie a sessão PPPoE por meio

da interface do discador.
• O comando display interface dialer é usado para verificar o status atual da configuração do discador e permite a
localização de falhas em uma interface do discador. O estado atual do discador UP identifica que o status físico da
interface está ativo, enquanto um estado DOWN confirmaria que uma falha existe atualmente. O estado do
protocolo de linha se refere ao status do protocolo da camada de enlace para o qual um status UP confirma a
conexão ativa.

• Um link que não tem endereço IP atribuído à interface ou está suprimido mostrará estar em um estado DOWN, onde a

supressão pode ser identificada pelo amortecimento da interface principalmente devido a uma oscilação persistente da

interface. Os temporizadores de retenção representam a pulsação da conexão do discador PPP após as transições de

negociação PPP LCP para Aberto. O endereço da Internet é negociado a partir do pool de IP que existe dentro do servidor

PPPoE, onde nenhum endereço está presente, o sistema exibirá "Processamento do protocolo da Internet: desativado". O

endereço IP é atribuído quando uma conexão é negociada, ou seja, por meio de uma solicitação de ping em o intervalo da

piscina.

• O status de negociação do LCP define o estado atual, onde “inicial” indica que a camada física está com
defeito ou nenhuma negociação foi iniciada. Um estado “Aberto” indica que o sistema enviou um pacote
Configure-Ack para o dispositivo peer e recebeu um pacote Configure-Ack do dispositivo peer, confirmando
que a camada de link está operando corretamente.
• O comando display pppoe-client session summary fornece informações sobre as sessões PPPoE no cliente
protocolo ponto a ponto sobre Ethernet (PPPoE), incluindo o status da sessão e estatísticas. Dois exemplos são
dados para destacar a diferença entre os estados de sessão PPPoE. O ID representa o PPPoE ID, enquanto o
ID do pacote e o ID do discador estão relacionados aos valores na configuração do parâmetro do discador.

• A interface define a interface na qual a negociação do lado do cliente é executada. O endereço MAC do
cliente PPPoE e do servidor também são definidos, porém o MAC do servidor só é determinado após o
estabelecimento da negociação. O PPPoE tem quatro estados possíveis. Um estado IDLE indica que a
sessão PPPoE não foi estabelecida no momento e nenhuma tentativa de estabelecer a conexão PPPoE foi
feita.

• Se o estado for PADI, isso indica que a sessão PPPoE está no estágio de descoberta e um pacote PPPoE
Active Discovery Initiation (PADI) foi enviado. Um estado PADR indica que a sessão PPPoE está no estágio de
descoberta e um pacote PPPoE Active Discovery Request (PADR) foi enviado. Finalmente, um estado UP
indica que a sessão PPPoE foi estabelecida com sucesso.
• Grande parte da implementação do PPPoE se concentrou em uma conexão ponto a ponto geral que reflete
um ambiente de laboratório típico, no entanto, em aplicações do mundo real, o cliente PPPoE muitas vezes
representa o gateway entre uma rede corporativa e a Wide Area Network (WAN), para a qual destinos e
recursos externos são acessados.

• A rede interna de uma empresa geralmente emprega um esquema de rede privada para conservar
endereços e esses endereços não podem ser usados para estabelecer comunicação IP na infraestrutura
de rede pública. Isso requer que o AR2200 forneça a função de tradução de endereço de rede (NAT) para
converter endereços IP privados em endereços IP públicos e é um recurso comumente aplicado para
facilitar as comunicações de rede interna sobre PPPoE.
• Os pacotes IP têm um tamanho de carga útil máximo de 1500 bytes, no entanto, quando usados em conjunto
com PPPoE, exigem 6 bytes adicionais, bem como outros 2 bytes para o ID do protocolo PPP, que faz com que o
tamanho do pacote exceda a carga útil máxima suportada Tamanho. Como tal, o MRU negociado LCP de um
pacote que suporta PPPoE não deve ser maior do que 1492 bytes.

• O comando dialer bundle liga a interface física à interface do discador que é usada para estabelecer a conexão
PPPoE.
• Um dos principais problemas enfrentados pela rede em expansão foi o esgotamento progressivo dos
endereços IP como resultado da demanda crescente. O esquema de endereçamento IPv4 existente tem se
esforçado para acompanhar o crescimento constante do número de dispositivos que continuam a constituir a
rede IP pública, comumente reconhecida como Internet. O endereçamento IPv4 já enfrentou o esgotamento da
IANA, o órgão da indústria responsável pela alocação de endereçamento global.

• Uma solução improvisada foi alocar um intervalo de endereços privados com base nas classes de endereço IP
existentes que poderiam ser reutilizadas. Essa solução permitiu que os domínios da rede implementassem
esses esquemas de endereçamento com base na faixa de endereços privados e em relação à escala do
domínio da rede. Isso permite que o tráfego que se origina e se destina a locais no mesmo domínio se
comunique sem consumo de endereços públicos valiosos.

• No entanto, surge um problema em facilitar a comunicação além do domínio da rede privada, onde os destinos
para o tráfego existem dentro do domínio público ou em outro domínio privado além desse domínio público. A
tradução de endereços de rede se tornou a solução padrão para esse problema, permitindo que as estações
finais encaminhem o tráfego por meio do domínio de rede pública de uma rede privada.
• O Network Address Translation (NAT) usa o limite geralmente estabelecido do roteador do gateway para
identificar os domínios da rede para tradução. Os domínios são considerados redes privadas internas ou redes
públicas externas entre as quais o NAT é executado. O princípio fundamental reside na recepção do tráfego
com um endereço de origem que está na rede privada e um endereço de destino que representa uma
localização fora do domínio da rede privada.

• Espera-se que o roteador implemente o NAT para traduzir o endereço privado em um endereço público para permitir

que o endereço de destino público receba um endereço público de retorno válido por meio do qual os pacotes recebidos

podem ser respondidos. O NAT também deve criar uma tabela de mapeamento dentro do gateway para permitir que o

gateway determine para qual endereço de destino da rede privada um pacote recebido da rede pública deve ser

enviado, novamente exigindo que a tradução do endereço seja executada ao longo do caminho de retorno.
• Várias implementações de NAT são possíveis e podem ser aplicadas a uma variedade de situações diferentes.
O NAT estático representa um mapeamento direto um a um que permite que o endereço IP de um sistema final
específico seja traduzido para um endereço público específico. Em grande escala, o mapeamento um-para-um
do NAT estático não faz nada para aliviar a falta de endereços, no entanto, é aplicável em casos como quando
um host pode desejar ter certos privilégios associados a um endereço ao qual o host está estaticamente
associados. Este mesmo princípio também pode ser aplicado a servidores que desejam ser contatados da rede
externa por um endereço público específico.

• No exemplo dado, os pacotes originados da fonte 192.168.1.1 são destinados ao endereço de rede pública de
1.1.1.1. O RTA do gateway de rede constrói um mapeamento entre o endereço privado de 192.168.1.1 e um
endereço público de 200.10.10.5 que é atribuído como o endereço de origem do pacote antes de ser
encaminhado pelo gateway ao destino pretendido. Qualquer pacote de retorno será enviado como uma resposta
com o endereço de destino de 200.10.10.5 para o qual o gateway receberá e executará a tradução estática, antes
de encaminhar o pacote para o host associado de 192.168.1.1. O mapeamento estático de endereços não requer
gerenciamento real de alocação de endereços para usuários, uma vez que o endereçamento é atribuído
manualmente.
• O NAT dinâmico funciona com base no princípio de pools de endereços pelos quais os sistemas finais internos que

desejam encaminhar o tráfego pela rede pública são capazes de se associar a um endereço público de um pool de

endereços. Os sistemas finais que requerem comunicação com destinos no domínio da rede pública devem se

associar a um endereço público exclusivo que pode ser obtido a partir do intervalo de endereços públicos do pool.

• Um endereço é atribuído do pool de endereços do servidor NAT conforme cada sistema final tenta encaminhar o
tráfego para um destino de rede pública. O número de endereços IP pertencentes ao servidor NAT é muito
menor do que o número de hosts internos porque nem todos os hosts internos acessam redes externas ao
mesmo tempo. Isso geralmente é determinado de acordo com o número de hosts internos que acessam redes
externas nos horários de pico.

• O exemplo demonstra um caso em que dois hosts internos geram pacotes destinados ao destino 1.1.1.1/24,
em que cada host interno recebe um endereço único do pool de endereços, para permitir que cada host seja
diferenciado na rede pública do outro . Assim que a comunicação não for mais necessária na rede pública, o
mapeamento de endereço será removido para permitir que o endereço público seja retornado ao pool de
endereços.
• Além da tradução de endereço muitos para muitos encontrada no NAT dinâmico, a tradução de porta de endereço de

rede (NAPT) pode ser usada para implementar a tradução de endereço simultânea. O NAPT permite que vários

endereços internos sejam mapeados para o mesmo endereço público. É também chamada de tradução de endereços

muitos para um ou multiplexação de endereços. O NAPT mapeia endereços IP e interfaces. Os datagramas de

diferentes endereços internos são mapeados para interfaces com o mesmo endereço público e diferentes números de

porta, ou seja, os datagramas compartilham o mesmo endereço público.

• O roteador recebe um pacote de solicitação enviado do host na rede privada para acessar o servidor na rede
pública. O endereço IP de origem do pacote é
192.168.1.1 e seu número de porta é 1025. O roteador seleciona um endereço IP público ocioso e um número de
porta ocioso do pool de endereços IP, e configura as entradas NAPT de encaminhamento e reverso que
especificam o mapeamento entre o endereço IP de origem e o número da porta do pacote e o endereço IP
público e o número da porta. O roteador converte o endereço IP de origem do pacote e o número da porta no
endereço IP público e no número da porta com base na entrada NAPT de encaminhamento e envia o pacote ao
servidor na rede pública. Após a tradução, o endereço IP de origem do pacote é 200.10.10.11 e seu número de
porta é 2843.
• O IP fácil é aplicado onde os hosts em redes locais de pequena escala requerem acesso à rede pública ou Internet. LANs
de pequena escala são geralmente implantadas onde apenas alguns hosts internos são usados e a interface de saída
obtém um endereço IP público temporário por meio de discagem. O endereço IP público temporário é usado pelos hosts
internos para acessar a Internet. O Easy IP permite que os hosts acessem a Internet usando esse endereço público
temporário.

• O exemplo demonstra o processo Easy IP. O roteador recebe um pacote de solicitação enviado do host na rede privada
para acessar um servidor na rede pública. O endereço IP de origem do pacote, neste caso, é 192.168.1.1, e seu número
de porta é 1025. O roteador configura as entradas de Easy IP para frente e para trás que especificam o mapeamento entre
o endereço IP de origem e o número da porta do pacote e o endereço IP público e o número da porta da interface
conectada à rede pública. O roteador converte o endereço IP de origem e o número da porta do pacote para o endereço
IP público e o número da porta, e envia o pacote ao servidor na rede pública. Após a tradução, o endereço IP de origem
do pacote é 200.10.10.1 e seu número de porta é 2843.

• Depois de receber uma resposta do servidor, o roteador consulta a entrada Easy IP reversa com base no endereço IP de
destino do pacote e no número da porta. O roteador traduz o endereço IP de destino do pacote e o número da porta para o
endereço IP privado e o número da porta do host na rede privada e envia o pacote ao host. Após a tradução, o endereço
IP de destino do pacote é 192.168.1.1, e seu número de porta é

1025.
• O NAT pode proteger hosts em redes privadas de usuários de redes públicas. Quando uma rede privada precisa
fornecer serviços como serviços da Web e FTP para usuários da rede pública, os servidores da rede privada devem
estar acessíveis aos usuários da rede pública a qualquer momento.

• O servidor NAT pode resolver o problema anterior traduzindo o endereço IP público e o número da porta em
endereço IP privado e o número da porta com base no mapeamento pré-configurado.

• As entradas de tradução de endereço do servidor NAT são configuradas no roteador, após o que o roteador recebe uma solicitação de acesso

enviada de um host na rede pública. O roteador consulta a entrada de tradução de endereço com base no endereço IP de destino do pacote e no

número da porta. O roteador traduz o endereço IP de destino do pacote e o número da porta para o endereço IP privado e o número da porta com

base na entrada de conversão de endereço e envia o pacote para o servidor na rede privada. O endereço IP de destino do pacote enviado pelo host

na rede pública é 200.10.10.5 e o número da porta de destino 80. Depois que a tradução é realizada pelo roteador, o endereço IP de destino do

pacote é 192.168.1.1 e seu o número da porta é 8080. Depois de receber um pacote de resposta enviado do servidor na rede privada, o roteador

consulta a entrada de tradução de endereço com base no endereço IP de origem do pacote e no número da porta. O roteador traduz o endereço IP de

origem do pacote e o número da porta para o endereço IP público e o número da porta com base na entrada de conversão de endereço e envia o

pacote para o host na rede pública. A origem do pacote de resposta enviado do host na rede privada é 192.168.1.1 e seu número de porta é 8080.

Após a tradução pelo roteador, o endereço IP de origem do pacote é 200.10.10.5 e o número da porta é novamente porta 80. e envia o pacote para o

host na rede pública. A origem do pacote de resposta enviado do host na rede privada é 192.168.1.1 e seu número de porta é 8080. Após a tradução

pelo roteador, o endereço IP de origem do pacote é 200.10.10.5 e o número da porta é novamente porta 80. e envia o pacote para o host na rede

pública. A origem do pacote de resposta enviado do host na rede privada é 192.168.1.1 e seu número de porta é 8080. Após a tradução pelo roteador,

o endereço IP de origem do pacote é 200.10.10.5 e o número da porta é novamente porta 80.

• O NAT estático indica que um endereço privado está estaticamente vinculado a um endereço público quando o
NAT é executado. O endereço IP público no NAT estático é usado apenas para a tradução do endereço IP
privado único e fixo de um host. O nat static [protocolo {<tcp> | <udp>} global {<global-address> |
current-interface <globalport>} dentro de {<host-address> <host-port>} vpn-instance <vpn-instance-name>
netmask <mask> acl <acl-number> description <description>] comando é usado para criar o NAT estático e
definir os parâmetros para a tradução.

• Os principais parâmetros aplicados como no exemplo são o parâmetro global para configurar as informações de
NAT externo, especificamente o endereço externo, e o parâmetro interno que permite que as informações de
NAT interno sejam configuradas. Em ambos os casos, o endereço e o número da porta podem ser definidos
para tradução. A porta global especifica o número da porta do serviço fornecido para acesso externo. Se este
parâmetro não for especificado, o valor de global-port é 0. Ou seja, qualquer tipo de serviço pode ser fornecido.
A porta do host especifica o número da porta de serviço fornecido pelo servidor interno. Se este parâmetro não
for especificado, o valor de host-port é igual ao valor de global-port.
• A configuração do NAT estático pode ser visualizada por meio do comando display nat static. O comando
exibe as informações de tradução do endereço de rede com relação à interface através da qual a tradução do
endereço é realizada, os endereços globais e internos que são traduzidos junto com as portas usadas. Onde
as portas não estão definidas, um resultado nulo será exibido. A configuração para tradução pode ser um
protocolo específico para o tráfego do protocolo TCP ou UDP, caso em que a entrada do protocolo será
definida.
• A configuração de traduções de endereços de rede dinâmicos envolve a implementação do comando nat outbound. Ele se

baseia na configuração anterior de uma lista de controle de acesso à rede que é usada para especificar uma regra para

identificar o tráfego específico ao qual um evento ou operação será aplicado. Os detalhes relativos às listas de controle de

acesso são abordados em uma unidade posterior. Uma associação é feita entre essas regras da lista de controle de

acesso e o pool de endereços NAT. Dessa maneira, os endereços especificados na lista de controle de acesso podem ser

traduzidos usando o pool de endereços NAT.

• O exemplo demonstra como o comando nat outbound foi associado a uma lista de controle de acesso com um
identificador de 2000 para permitir o tráfego do
192.168.1.0/24 intervalo de rede a ser traduzido como parte de um grupo de endereços referido como grupo
de endereços 1. Isso define um intervalo de pool de 200.10.10.11 a 200.10.10.16 que os endereços internos
empregarão para a tradução de endereços. O parâmetro no-pat no comando significa que nenhuma tradução
de endereço de porta ocorrerá para os endereços no pool, portanto, cada host deve ser convertido em um
endereço global exclusivo.
• Dois comandos de exibição específicos permitirão que as informações detalhadas sobre a tradução dinâmica de
endereços sejam verificadas. O comando display nat address-group <groupindex> permite que o intervalo geral
do pool de tradução de endereços de rede seja determinado. Além disso, o comando display nat outbound
fornecerá detalhes específicos para qualquer configuração de tradução de endereço de rede dinâmica aplicada a
uma determinada interface. No exemplo, pode ser entendido que a interface Serial1 / 0/0 está associada a uma
regra de lista de controle de acesso junto com o grupo de endereço 1 para tradução de endereço na interface
dada. A saída no-pat confirma que a tradução de endereço de porta não está em vigor nesta tradução de
endereço de rede.
• A configuração do Easy IP é muito semelhante à configuração da tradução dinâmica de endereços de rede,
contando com a criação de uma regra de lista de controle de acesso para definir a faixa de endereços para a
qual a tradução deve ser realizada e a aplicação do comando nat outbound. A principal diferença está na
ausência do comando address group, uma vez que nenhum pool de endereços é usado na configuração do
Easy IP. Em vez disso, o endereço da interface de saída é usado para representar o endereço externo, neste
caso sendo o endereço externo 200.10.10.1 da interface serial1 / 0/0. Além disso, é necessário que a tradução
do endereço da porta seja realizada e, como tal, o parâmetro no-pat não pode ser implementado onde um
grupo de endereço não existe.
• O mesmo comando display nat outbound pode ser usado para observar os resultados da configuração do
nat outbound e verificar sua correta implementação. A ligação da interface e da lista de controle de acesso
(ACL) pode ser determinada, bem como a interface (neste caso) para a tradução de saída. A lista de tipos
de easyip torna-o claramente compreendido quando o Easy IP foi configurado com sucesso.
• Onde for necessário fornecer acesso interno a usuários externos, como no caso de um servidor público que
faz parte de uma rede interna, a configuração do servidor NAT pode ser realizada para permitir que o
tráfego destinado a um endereço de destino externo e número de porta seja traduzido para um endereço
de destino interno e número de porta.

• O servidor nat [protocolo {<tcp> | <udp>} global {<endereço global> | currentinterface <global port>} dentro de
{<host-address> <host-port> vpn-instance <vpninstance-name> acl <acl-number> descrição <descrição>]
comando permite que a tradução interna externa seja realizada, onde o protocolo identifica um protocolo
específico (TCP ou UDP dependendo do serviço) a ser permitido para tradução junto com o endereço global,
indicando o endereço externo para tradução e o endereço interno relacionado ao endereço do servidor interno.

• O número da porta para o endereço externo deve ser definido e comumente relacionado a um serviço
específico, como http (www) na porta 80. Como meio de melhorar ainda mais a proteção geral dos números
das portas internas contra ameaças externas, um número de porta alternativo pode ser aplicado à rede interna
e traduzido pelos mesmos meios que são usados para a tradução de endereços.
• O comando display nat server detalha os resultados da configuração para verificar a implementação correta do
servidor NAT. A interface define o ponto em que a tradução ocorrerá. Os endereços IP globais e internos e os
números de porta associados podem ser verificados. Neste caso, o endereço global de 202.10.10.5 com um
número de porta de 80 (www) será traduzido para um endereço de servidor interno de 192.168.1.1 com um
número de porta de 8080 como segurança adicional contra ataques baseados em portas em potencial. Apenas o
tráfego TCP destinado a este endereço e porta será traduzido.
• A configuração do servidor interno NAT permitirá que um endereço público exclusivo seja associado a um
destino de servidor de rede privada, permitindo o fluxo de tráfego de entrada da rede externa após a tradução.
Os usuários internos podem acessar o local do servidor com base no endereço privado do servidor.

• O recurso PAT executará a tradução com base no número da porta e também nos endereços IP. É usado como
uma forma de conservação de endereço onde o número de endereços públicos disponíveis para tradução é
limitado ou insuficiente para suportar o número de endereços privados que requerem uma possível tradução.
• Uma Lista de Controle de Acesso (ACL) é um mecanismo que implementa o controle de acesso para um recurso
do sistema listando as entidades com base em parâmetros específicos que têm permissão para acessar o recurso,
bem como o modo de acesso que é concedido. Em geral, uma ACL pode ser entendida como um meio de
filtragem, e pode ser aplicada para controlar o fluxo de tráfego, bem como identificar o tráfego para o qual
operações especiais devem ser realizadas.

• Um aplicativo comum envolve um gateway que pode ter um destino de encaminhamento para várias redes; no
entanto, pode conter uma ACL que gerencia qual tráfego pode fluir para qual destino. No exemplo dado, a rede
192.168.1.0/24 é geralmente vista como capaz de acessar a rede externa, neste caso a Internet, enquanto os
hosts representados pela rede 192.168.2.0/24 são incapazes de encaminhar tráfego na mesma forma e,
portanto, resultando em uma falha de transmissão. No caso do Servidor A, o inverso se aplica com a permissão
de acesso concedida pelo gateway à rede 192.168.2.0/24, mas restrita a todos os hosts que fazem parte da
rede 192.168.1.0/24.
• Onde a filtragem é realizada com base no tráfego interessante, não há nenhuma restrição geral feita, mas, em vez
disso, é provável que sejam realizadas operações adicionais que afetam os dados atuais. O exemplo demonstra
um cenário onde os dados de entrada são filtrados com base em determinados critérios, como neste caso, o
endereço IP de origem e onde uma lista de controle de acesso é encontrada para ser aplicada aos dados, ações
associadas são executadas. Ações comuns podem envolver a alteração de parâmetros no tráfego IP roteado para
protocolos, como as métricas de rota em RIP e OSPF, e também na inicialização de comunicações de rede
criptografadas para o tráfego interessante, como muitas vezes é aplicado como parte de tecnologias como Redes
Privadas Virtuais ( VPN).
• Existem três tipos gerais de ACL que são definidos como parte da série ARG3, incluindo os tipos de lista de
controle de acesso básico, avançado e camada 2. Uma ACL básica faz a correspondência de pacotes com base
em informações como endereços IP de origem, sinalizadores de fragmento e intervalos de tempo e é definida por
um valor no intervalo de 2000-2999. Uma ACL avançada fornece um meio maior de precisão na associação de
parâmetros e combina pacotes com base em informações como endereços IP de origem e destino, números de
porta de origem e destino e tipos de protocolo.

• ACL avançado está associado a um intervalo de valores de 3000-3999. Por último, está a ACL da camada 2 que
combina os pacotes com base nas informações da Camada 2 baseadas em pacotes, como endereços MAC de origem,
endereços MAC de destino e tipos de protocolo da Camada 2. O tráfego é filtrado com base em regras que contêm os
parâmetros definidos por cada tipo de ACL.
• Listas de controle de acesso funcionam com o princípio de regras ordenadas. Cada regra contém uma cláusula de

permissão ou negação. Essas regras podem se sobrepor ou entrar em conflito. Uma regra pode conter outra regra, mas as

duas regras devem ser diferentes. O AR2200 oferece suporte a dois tipos de pedido de correspondência: pedido de

configuração e pedido automático. A ordem de configuração indica que as regras ACL são correspondidas em ordem

crescente de identificadores de regra, enquanto a ordem automática segue o princípio de profundidade primeiro que

permite que regras mais precisas sejam correspondidas primeiro. A ordem de configuração é usada por padrão e

determina as prioridades das regras em uma ACL com base em um ID de regra. As prioridades da regra são, portanto,

capazes de resolver qualquer conflito entre regras sobrepostas. Para cada ID de regra, a ACL determinará se a regra se

aplica. Se a regra não se aplicar, a próxima regra será considerada. Assim que uma correspondência de regra for

encontrada, a ação da regra será implementada e o processo ACL será interrompido. Se nenhuma regra corresponder ao

pacote, o sistema não processará o pacote.

• No exemplo, os pacotes originados de duas redes estão sujeitos a uma ACL dentro do RTA. Os pacotes das
redes 172.16.0.0 e 172.17.0.0 serão avaliados com base na ordem de ID da regra (configuração) por padrão.
Quando a regra descobrir uma correspondência para a rede com base em uma máscara curinga, a regra será
aplicada. Para a rede 172.16.0.0, a regra 15 corresponderá a todos os pacotes com o endereço 172.16.0.X, onde
X pode se referir a qualquer valor binário no octeto. Nenhuma regra específica correspondente à rede 172.17.0.0
foi encontrada na lista de controle de acesso e, portanto, não será submetida ao processo de ACL, no entanto, no
interesse da boa prática de design de ACL, uma regra geral foi definida na regra 20 para garantir que todas as
redes para as quais não existe uma regra especificamente definida podem ser encaminhadas.
• A criação de uma lista de controle de acesso básica requer que o administrador primeiro identifique a origem do
tráfego à qual a ACL deve ser aplicada. No exemplo dado, isso se refere aos locais de origem contendo um
endereço IP no intervalo 192.168.1.0/24 para os quais todos os pacotes contendo um endereço IP de origem
neste intervalo serão descartados pelo gateway. No caso de hosts que compõem o intervalo de rede
192.168.2.0/24, o tráfego é permitido e nenhuma ação adicional é executada para esses pacotes. A ACL básica
é aplicada à interface Gigabit Ethernet 0/0/0 na direção de saída, portanto, apenas os pacotes que atendem aos
critérios de interface e direção serão submetidos ao processamento de ACL.
• A validação da ACL básica configurada pode ser alcançada por meio do display acl <acl-number> onde o
acl-number se refere ao número ACL básico que foi atribuído à ACL configurada. A saída resultante confirma
as regras que foram criadas para negar (descartar) quaisquer pacotes IP com o endereço IP de origem no
intervalo 192.168.1.0/24 e permitir o endereçamento no intervalo 192.168.2.0/24.

• Também deve ser observado que cada regra recebe automaticamente um número de regra como parte da criação da lista

de controle de acesso. O número da regra define a ordem em que as regras são processadas e definidas em incrementos

de 5 por padrão nos roteadores da série Huawei ARG3. Há uma etapa ACL entre os números da regra. Por exemplo, se

uma etapa ACL for definida como 5, as regras serão numeradas 5, 10, 15 e assim por diante. Se uma etapa de ACL for

definida como 2 e os números de regra forem configurados para serem gerados automaticamente, o sistema gerará IDs de

regra automaticamente a partir de 2. A etapa torna possível adicionar uma nova regra entre as regras existentes. É possível

configurar o número da regra como parte da ACL básica quando necessário.

• Listas de controle de acesso avançadas permitem a filtragem com base em vários parâmetros para oferecer suporte
a um processo de seleção de rota mais detalhado. Enquanto uma ACL básica fornece filtragem com base no
endereço IP de origem, as ACL avançadas são capazes de filtrar com base no IP de origem e de destino, números
de porta de origem e destino, protocolos da camada de rede e transporte e parâmetros encontrados em cada
camada, como IP classificadores de tráfego e valores de sinalizadores TCP (SYN | ACK | FIN etc.).

• Uma ACL avançada é definida por um valor de ACL no intervalo de 3000-3999, conforme exibido no exemplo, para
o qual as regras são definidas para especificar a restrição de pacotes baseados em TCP que se originam de todos
os endereços de origem no intervalo de 192.168.1.1 a 192.168 .1.255 onde o IP de destino é 172.16.10.1 e a porta
de destino é a porta 21. Uma regra semelhante segue para definir a restrição de todos os pacotes baseados em IP
originados de fontes no intervalo 192.168.2.0/24 de alcançar o único destino de 172.16.10.2 . Uma regra catch all
geralmente pode ser aplicada para garantir que todo o outro tráfego seja processado pela ACL, geralmente por
meio de uma declaração de permissão ou negação para todos os pacotes baseados em IP.
• A validação da ACL avançada configurada pode ser obtida por meio do display acl <acl-number>, onde o
acl-number se refere ao número ACL avançado que foi atribuído à ACL configurada. A saída resultante
confirma que três regras foram criadas para negar qualquer pacote TCP com o endereço IP de origem
no intervalo 192.168.1.0/24 destinado a 172.16.10.1 de alcançar a porta 21 (ftp) e de qualquer endereço
IP de origem no intervalo do

192.168.2.0/24 de alcançar o endereço IP de destino de 172.16.10.2, enquanto permite todo o outro

tráfego IP.
• A ACL também pode ser aplicada à operação Network Address Translation (NAT) para permitir a filtragem de
hosts com base em endereços IP para determinar quais redes internas são convertidas por meio de quais pools
de endereços externos específicos, caso existam vários pools. Isso pode ocorrer quando uma rede corporativa é
um cliente para conexões de vários provedores de serviços para os quais vários usuários internos que são
considerados parte de diferentes redes / sub-redes desejam ser traduzidos e encaminhados com base em um
grupo de endereços específico, ocorrendo potencialmente em um roteador alternativo interfaces de uplink para as
diferentes redes de provedores de serviços.

• No exemplo dado, um exemplo simplificado disso é recriado onde os hosts dentro da rede interna devem ser
filtrados com base nas regras ACL básicas para as quais uma solução de NAT dinâmica é aplicada que permite
a tradução para um determinado endereço público de um determinado grupo de endereços. Em particular, os
hosts originados da rede 192.168.1.0/24 serão traduzidos usando endereços públicos no pool associado ao
grupo de endereços 1, enquanto os hosts na rede 192.168.2.0/24 serão filtrados com base no pool associado ao
grupo de endereços 2. o nat outbound <acl-number> address-group <address-group number> O comando é
implementado na visualização da interface Gigabit Ethernet para vincular o NAT na direção de saída com a ACL,
e o intervalo de endereços IP relacionado é referenciado pelo grupo de endereços especificado.
• As ACL avançadas são capazes de filtrar com base no IP de origem e de destino, números de porta de origem e
destino, protocolos da camada de rede e transporte e parâmetros encontrados em cada camada, como
classificadores de tráfego IP e valores de sinalizadores TCP (SYN | ACK | FIN etc .).

• Depois que uma correspondência de regra for encontrada na lista de controle de acesso para uma condição testada, a ação da

regra será implementada e o processo ACL restante não continuará.

• Autenticação, autorização e contabilidade (AAA) é uma tecnologia usada para verificar se um usuário tem
permissão para acessar uma rede, autoriza exatamente o que um usuário tem permissão para acessar e faz
registros sobre os recursos de rede usados por um usuário. VRP é capaz de suportar a autenticação AAA e
serviços de autorização localmente dentro da série ARG3 de roteadores, que é comumente referido como
Servidor de Acesso à Rede ou NAS, entretanto os serviços de contabilidade são geralmente suportados por um
servidor de contabilidade AAA externo. O exemplo aqui demonstra como os usuários considerados parte do
domínio Huawei podem obter acesso aos recursos localizados na rede de destino exibida. O Network Access
Server (NAS) opera como o dispositivo de gateway que pode realizar autenticação e autorização de usuários,
ou suporte a autenticação do servidor AAA e autorização de usuários. No caso do servidor AAA, os usuários
autenticados e autorizados a acessar a rede de destino também podem iniciar a contabilização no servidor AAA
durante a sessão ativa dos usuários.
• AAA oferece suporte a três modos de autenticação. A não autenticação confia totalmente nos usuários e não
verifica sua validade. Isso raramente é usado por razões de segurança óbvias. A autenticação local configura as
informações do usuário, incluindo o nome do usuário, a senha e os atributos dos usuários locais, em um servidor
de acesso à rede (NAS). A autenticação local tem vantagens como processamento rápido e baixos custos
operacionais. A desvantagem da autenticação local é o armazenamento de informações limitado devido ao
hardware. A autenticação remota configura as informações do usuário, incluindo nome de usuário, senha e
atributos no servidor de autenticação. O AAA pode autenticar usuários remotamente usando o protocolo RADIUS
(Remote Authentication Dial In User Service) ou o protocolo HWTACACS (Sistema de Controle de Acesso do
Controlador de Acesso ao Terminal Huawei). Como cliente,

• Se vários modos de autenticação forem usados em um esquema de autenticação, esses modos de

autenticação entram em vigor na sequência em que os modos de configuração foram configurados. Se a
autenticação remota foi configurada antes da autenticação local e se uma conta de login existe no dispositivo
local, mas não está disponível no servidor remoto, o AR2200 considera o usuário que usa esta conta como
tendo falhado ao ser autenticado pela autenticação remota e, portanto, a autenticação local é não realizado. A
autenticação local seria usada apenas quando o servidor de autenticação remota não respondesse. Se a não
autenticação for configurada, ela deve ser configurada como o último modo a ter efeito.
• A função de autorização AAA é usada para determinar a permissão para os usuários obterem acesso a redes ou

dispositivos específicos, já que o AAA oferece suporte a vários modos de autorização. No modo de não autorização, os

usuários não são autorizados. A autorização local, entretanto, autoriza os usuários de acordo com os atributos

relacionados das contas de usuários locais configuradas no NAS. Como alternativa, o HWTACACS pode ser usado para

autorizar usuários por meio de um servidor TACACS.

• Um modo de autorização If-authenticated pode ser usado onde os usuários são considerados autorizados caso
esses usuários possam ser autenticados no modo de autenticação local ou remoto. A autorização RADIUS
autoriza os usuários depois que eles são autenticados usando um servidor de autenticação RADIUS. A
autenticação e a autorização do protocolo RADIUS são vinculadas, portanto, o RADIUS não pode ser usado
para executar apenas a autorização. Se vários modos de autorização forem configurados em um esquema de
autorização, a autorização será executada na sequência em que os modos de configuração foram configurados.
Se configurado, a não autorização deve ser o último modo a ter efeito.
• O processo de contabilidade pode ser usado para monitorar a atividade e o uso de usuários autorizados que obtiveram

acesso aos recursos da rede. A contabilidade AAA oferece suporte a dois modos de contabilidade específicos. A não

contabilidade pode ser usada e fornece serviços gratuitos para usuários sem qualquer registro de usuários ou logs de

atividades.

• Remote accounting on the other hand supports accounting using the RADIUS server or the HWTACACS
server. These servers must be used in order to support accounting due to the requirement for additional
storage capacity necessary to store information regarding access and activity logs of each authorized user.
The example demonstrates a very general representation of some of the typical information that is commonly
recorded within user accounting logs.
• O dispositivo usa domínios para gerenciar usuários. Os esquemas de autenticação, autorização e contabilidade
podem ser aplicados a um domínio para que o dispositivo possa autenticar, autorizar ou cobrar os usuários no
domínio usando os esquemas. Cada usuário do dispositivo pertence a um domínio. O domínio ao qual um usuário
pertence é determinado pela cadeia de caracteres com sufixo no delimitador do nome de domínio que pode ser @, |
ou%.

• Por exemplo, se o nome de usuário for user @ huawei , o usuário pertence ao domínio huawei. Se o nome do
usuário não contiver um @, o usuário pertence ao domínio padrão denominado default no sistema. O dispositivo
tem dois domínios padrão: default (domínio padrão global para usuários de acesso comum) e default_admin
(domínio padrão global para administradores). Os dois domínios podem ser modificados, mas não podem ser
excluídos.

• Se o domínio de um usuário de acesso não puder ser obtido, o domínio padrão será usado. O domínio padrão é
usado para usuários de acesso, como usuários de acesso NAC. A autenticação local é executada por padrão
para usuários neste domínio. O domínio default_admin é usado para administradores como os administradores
que fazem login usando HTTP, SSH, Telnet, FTP e terminais. A autenticação local é executada por padrão para
usuários neste domínio. O dispositivo suporta no máximo 32 domínios, incluindo os dois domínios padrão.
• O roteador AR2200 pode ser usado como um servidor de acesso à rede (NAS) para implementar esquemas
de autenticação e autorização. O exemplo demonstra o processo típico que é necessário para implementar o
AAA local com sucesso. Os usuários para autenticação devem ser criados usando o comando local-user
<nome do usuário> senha [cipher \ simples] <senha> nível de privilégio <nível>. Este comando especifica um
nome de usuário. Se o nome de usuário contiver um delimitador de nome de domínio como @, o caractere
antes de @ é o nome do usuário e o caractere atrás de @ é o nome de domínio. Se o valor não contiver @,
toda a sequência de caracteres será o nome do usuário e o nome do domínio será o domínio padrão.

• Um esquema de autenticação é criado para autenticar usuários e deve ser criado antes que a configuração
adicional relevante para autenticação possa ser realizada. O esquema de autenticação deve ser definido como
local, radius, hwtacacs ou nenhum. Com exceção do parâmetro nenhum, os outros modos de autenticação
podem ser listados na ordem em que a autenticação deve ser tentada, por exemplo, se o comando local
hwtacacs do modo de autenticação for usado, e se a autenticação HWTACACS falhar, o roteador AR2200E
será iniciado autenticação local. O esquema de autorização também deve ser criado para autorizar usuários
(exceto no caso de suporte ao servidor Radius), criando um esquema de autorização definindo o modo de
autorização. O comando do modo de autorização oferece suporte a modos para hwtacacs, local, se autenticado
e sem autorização.

• O comando domain <domain-name> é usado para criar um novo domínio, e a implementação do esquema de
autenticação <authentication-scheme> e do esquema de autorização <authorization-scheme> na visualização
do domínio aplicará os esquemas de autenticação e autorização para esse domínio.
• A configuração do domínio AAA local e os esquemas para autenticação e autorização podem ser verificados
através do domínio de exibição ou exibir nome de domínio <domain-name> comandos. Usando o domínio de
exibição comando fornece informações resumidas sobre todos os domínios que foram criados, incluindo o nome
de domínio e um índice de domínio que é usado para fazer referência a cada domínio criado.

• O nome de domínio de exibição <domain-name> comando fornece específico

detalhes de configuração em referência ao domínio definido no parâmetro nome de domínio. Junto com o nome
de domínio está o estado de domínio que se apresenta como Ativo ou Bloqueio, onde bloqueio se refere a um
domínio que está em estado de bloqueio e impede que os usuários neste domínio possam fazer login. Isso é
implementado por meio de um opcional estado [ativo | quadra] comando implementado sob a visão de domínio
AAA. Um domínio está em um estado ativo após ser criado por padrão.

• O nome do esquema de autenticação associa o esquema de autenticação criado ao domínio; o mesmo se aplica
ao regime de autorização. O esquema de contabilidade não está configurado localmente e, portanto, um
esquema de contabilidade não foi associado ao domínio criado e, como tal, o esquema de contabilidade padrão
é listado para o domínio por padrão. No caso de uma configuração não local (ou seja, RADIUS ou HWTACACS)
implementada para oferecer suporte a serviços AAA, eles serão associados ao domínio nos campos de modelo
de servidor.
• A configuração do VRP no modo local suportará esquemas de autenticação e autorização, o esquema de
contabilidade requer o suporte de gerenciamento remoto através de um servidor HWTACACS ou
RADIUS.

• Se um usuário for criado sem definir o domínio ao qual pertence, o usuário será automaticamente
associado ao domínio padrão, denominado default.
• A segurança do protocolo da Internet (IPSec) é um conjunto de protocolos definido pela Internet Engineering Task Force

(IETF) para proteger a comunicação do protocolo da Internet (IP) autenticando e / ou criptografando cada pacote IP de uma

sessão de comunicação. Duas partes que se comunicam podem criptografar os dados e / ou autenticar os dados originados

na camada IP para garantir a confidencialidade dos dados, integridade e disponibilidade do serviço.

• A confidencialidade é o serviço de segurança que protege a divulgação de dados normalmente no nível do aplicativo, mas

também abrange a divulgação da comunicação, o que também pode ser uma preocupação em algumas circunstâncias. A

confidencialidade do fluxo de tráfego é o serviço aplicado para ocultar os endereços de origem e destino, o comprimento da

mensagem ou a frequência da comunicação.

• O IPSec suporta duas formas de integridade; sem conexão e uma forma de integridade de sequência parcial. A integridade
sem conexão é um serviço que detecta a modificação de um datagrama IP individual, independentemente da ordem do
datagrama em um fluxo de tráfego. A forma de integridade de sequência parcial oferecida no IPSec é conhecida como
integridade anti-reprodução e detecta a chegada de datagramas IP duplicados (dentro de uma janela restrita). Isso contrasta
com a integridade orientada à conexão, que impõe requisitos de sequenciamento mais rigorosos ao tráfego, por exemplo, ser
capaz de detectar mensagens perdidas ou reordenadas. Embora os serviços de autenticação e integridade sejam
freqüentemente citados separadamente, na prática eles estão intimamente conectados e quase sempre oferecidos em
conjunto.

• A disponibilidade, quando vista como um serviço de segurança, trata das questões de segurança geradas por ataques contra

redes que negam ou degradam o serviço. Por exemplo, no contexto IPSec, o uso de mecanismos anti-reprodução nos

protocolos subjacentes, especificamente AH e ESP, oferece suporte à disponibilidade para evitar ataques iniciados por

usuários mal-intencionados, reenviando pacotes capturados.

• O IPSec usa dois protocolos para fornecer segurança de tráfego, Authentication Header (AH) e Encapsulating Security Payload (ESP).
O IP Authentication Header (AH) fornece integridade sem conexão, autenticação de origem de dados e um serviço anti-reprodução
opcional. O protocolo Encapsulating Security Payload (ESP) pode fornecer confidencialidade (criptografia) e confidencialidade de fluxo
de tráfego limitado.

• ESP opcionalmente fornece confidencialidade para o tráfego. A força do serviço de confidencialidade depende em parte do algoritmo de
criptografia empregado, para o qual três formas principais de algoritmo de criptografia são possíveis. O ESP também pode fornecer
autenticação opcionalmente, no entanto, o escopo da autenticação oferecida pelo ESP é mais restrito do que pelo AH, uma vez que o
cabeçalho IP externo (modo de túnel) e o cabeçalho ESP são / não protegidos pela autenticação ESP.

• O Padrão de Criptografia de Dados com Cipher Block Chaining (DES-CBC) é um algoritmo de chave secreta simétrica que usa um
tamanho de chave de 64 bits, mas é comumente conhecido como uma chave de 56 bits porque a chave tem 56 bits significativos; o bit
menos significativo em cada byte é o bit de paridade. Seu uso hoje é limitado devido à capacidade do poder computacional de realizar
ataques de força bruta em um período de tempo significativamente limitado. O Triple Data Encryption Standard (3DES) é um algoritmo
de criptografia de 168 bits que envolve uma iteração do processo DES com a adição de um vetor de inicialização (IV), um valor usado
para disfarçar padrões em dados criptografados para melhorar a confidencialidade geral dos dados. O Advanced Encryption Standard
(AES) suporta criptografia de até 256 bits, empregando novamente o CBC e IV para força adicional de criptografia.

• O AH suporta um algoritmo MD5 que recebe como entrada uma mensagem de comprimento arbitrário e produz como saída uma "impressão

digital" ou "resumo da mensagem" de 128 bits dessa entrada, enquanto o SHA-1 produz uma saída do resumo da mensagem de 160 bits. SHA-2

representa uma próxima geração de algoritmos de autenticação para estender a segurança à autenticação após a descoberta de certas fraquezas

no SHA-1.

• O termoSHA-2 não é definido oficialmente, mas geralmente é usado para se referir à coleção dos algoritmos SHA-224, SHA-256,
SHA-384 e SHA-512. VRP atualmente suportado pelo AR2200E, no entanto, oferece suporte apenas para SHA-256, SHA-384 e
SHA-512, onde o valor representa o comprimento do resumo de bits.
• Uma Associação de Segurança (SA) denota uma forma de conexão que é estabelecida em uma única direção
através da qual os serviços de segurança relevantes para o tráfego são definidos. Os serviços de segurança são
atribuídos a um SA na forma de AH ou ESP, mas não ambos. Se a proteção baseada em AH e ESP for aplicada
a um fluxo de tráfego, duas (ou mais) SAs serão criadas para atribuir proteção ao fluxo de tráfego. Para proteger
a comunicação bidirecional entre dois hosts ou dois gateways de segurança, conforme mostrado no exemplo,
são necessárias duas associações de segurança (uma em cada direção).

• As SAs IPSec são estabelecidas no modo manual ou no modo de negociação Internet Key Exchange (IKE).
Estabelecer SAs no modo manual requer que todas as informações, como os parâmetros exibidos no exemplo,
sejam configurados manualmente. Os SAs estabelecidos no modo manual, entretanto, nunca envelhecerão.
Estabelecer SAs usando o modo de negociação IKE é mais simples, pois as informações de negociação IKE
precisam ser configuradas apenas em dois pares e SAs são criadas e mantidas por meio de negociação IKE,
para a qual a complexidade existe principalmente no próprio processo de negociação automatizado IKE e, como
tal, não será abordado em detalhes aqui. A SA estabelecida na negociação IKE tem uma vida útil baseada no
tempo ou no tráfego. Quando o tempo especificado ou o volume de tráfego é atingido, um SA torna-se inválido.
Quando a SA estiver prestes a expirar, o IKE negociará uma nova SA.
• Um modo de transporte SA é uma associação de segurança entre dois hosts. No IPv4, um cabeçalho de protocolo de

segurança do modo de transporte aparece imediatamente após o cabeçalho IP, qualquer opção e antes de qualquer protocolo

de camada superior (por exemplo, TCP ou UDP). No modo de transporte, os protocolos fornecem proteção principalmente para

os protocolos da camada superior. Um cabeçalho AH ou ESP é inserido entre o cabeçalho IP e o cabeçalho do protocolo da

camada de transporte. No caso do ESP, um modo de transporte SA fornece serviços de segurança apenas para esses

protocolos de camada superior, não para o cabeçalho IP ou quaisquer cabeçalhos de extensão anteriores ao cabeçalho ESP.

No caso do AH, a proteção também é estendida a partes selecionadas do cabeçalho IP, bem como às opções selecionadas.
• No contexto IPSec, o uso de ESP no modo túnel, especialmente em um gateway de segurança, pode fornecer
algum nível de confidencialidade do fluxo de tráfego. O endereço de origem do cabeçalho IP externo e o endereço
de destino identificam os pontos finais do túnel. Os endereços de origem e destino do cabeçalho IP interno
identificam o remetente e o destinatário originais do datagrama (da perspectiva desse túnel), respectivamente.

• O cabeçalho IP interno não é alterado, exceto para diminuir o TTL e permanece inalterado durante sua entrega
ao ponto de saída do túnel. Nenhuma alteração ocorre nas opções de IP ou cabeçalhos de extensão no
cabeçalho interno durante a entrega do datagrama encapsulado pelo túnel. Um cabeçalho AH ou ESP é inserido
antes do cabeçalho IP original e um novo cabeçalho IP é inserido antes do cabeçalho AH ou ESP.

• O exemplo fornecido mostra o modo de túnel IPSec durante a transmissão de pacotes baseada em TCP. Se o AH também for

aplicado a um pacote, ele será aplicado ao cabeçalho ESP, Carga útil de dados, trailer ESP e Dados de autenticação ESP

(ICV), se os campos estiverem presentes.

• A implementação de uma rede privada virtual (VPN) IPSec requer que a acessibilidade da camada de rede entre o iniciador e o
destinatário seja verificada para garantir que a comunicação não-IPSec seja possível antes de construir qualquer VPN IPSec. Nem todo
o tráfego precisa estar sujeito a regras de integridade ou confidencialidade e, portanto, a filtragem de tráfego precisa ser aplicada ao
fluxo de dados para identificar o tráfego de interesse pelo qual o IPSec será responsável. Um fluxo de dados é uma coleção de tráfego e
pode ser identificado pelo endereço / máscara de origem, endereço / máscara de destino, número do protocolo, número da porta de
origem e número da porta de destino. Ao usar VRP, os fluxos de dados são definidos usando grupos ACL. Um fluxo de dados pode ser
uma única conexão TCP entre dois hosts ou todo o tráfego entre duas sub-redes.

• Uma proposta IPSec define o protocolo de segurança, algoritmo de autenticação, algoritmo de criptografia e modo de encapsulamento
para os fluxos de dados a serem protegidos. Os protocolos de segurança AH e ESP podem ser usados de forma independente ou em
conjunto. AH suporta algoritmos de autenticação MD5, SHA-1 e SHA-2. O ESP oferece suporte a três algoritmos de autenticação (MD5,
SHA-1 e SHA-2) e três algoritmos de criptografia (DES, 3DES e AES). IPSec também suporta modos de encapsulamento de transporte e
túnel. Para transmitir o mesmo fluxo de dados, os pares em ambas as extremidades de um túnel de segurança devem usar o mesmo
protocolo de segurança, algoritmo de autenticação, algoritmo de criptografia e modo de encapsulamento. Para implementar o IPSec entre
dois gateways, é aconselhável usar o modo de túnel para proteger os endereços IP de origem e destino reais usados na comunicação.

• Uma política IPSec define o protocolo de segurança, algoritmo de autenticação, algoritmo de criptografia e modo de encapsulamento para
fluxos de dados referenciando uma proposta IPSec. O nome e o número de sequência identificam exclusivamente uma política IPSec. As
políticas IPSec são classificadas em políticas IPSec usadas para estabelecer SAs manualmente e políticas IPSec usadas para estabelecer
SAs por meio de negociação IKE.

• Para configurar uma política IPSec usada para estabelecer SAs manualmente, defina parâmetros como a chave e SPI. Se o modo de túnel
estiver configurado, os endereços IP para dois pontos finais de um túnel de segurança também devem ser definidos. Ao configurar uma
política IPSec usada para estabelecer SAs por meio da negociação IKE, parâmetros como a chave e o SPI não precisam ser definidos, pois
são gerados automaticamente pela negociação IKE. As políticas IPSec com o mesmo nome, mas com números de sequência diferentes,
constituem um grupo de políticas IPSec.

• Em um grupo de políticas IPSec, uma política IPSec com um número de sequência menor tem uma prioridade mais alta. Depois que um grupo de
políticas IPSec é aplicado a uma interface, todas as políticas IPSec do grupo são aplicadas à interface. Isso permite que diferentes SAs sejam
usados para diferentes fluxos de dados.
• A comunicação na camada de rede representa o pré-requisito inicial de qualquer estabelecimento de conexão
VPN IPsec. Isso é suportado neste exemplo por meio da criação de uma rota estática apontando para o
endereço do próximo salto do RTB. É necessário implementar rotas estáticas em ambas as direções para
garantir a comunicação bidirecional entre as redes. Uma ACL avançada é criada para identificar o tráfego
interessante para o qual a VPN IPsec será iniciada, por meio da qual a ACL avançada é capaz de filtrar com
base em parâmetros específicos e escolher entre Descartar, Ignorar ou Proteger os dados filtrados.

• O comando de proposta ipsec cria uma proposta IPSec e entra na visualização da proposta IPSec. Ao configurar
uma política IPSec, é necessário referenciar uma proposta IPSec para especificar o protocolo de segurança,
algoritmo de criptografia, algoritmo de autenticação e modo de encapsulamento usado por ambas as extremidades
do túnel IPSec. Uma nova proposta IPSec criada usando o comando de proposta ipsec por padrão usa o protocolo
ESP, algoritmo de criptografia DES, algoritmo de autenticação MD5 e modo de encapsulamento de túnel. Eles
podem ser redefinidos usando vários comandos na visualização da proposta IPSec. A transformação [ah | ah-esp |
esp] permitirá que o conjunto de transformação atual seja alterado, o modo de encapsulamento {transporte | túnel}
pode alterar os meios usados para encapsular os pacotes.

• O algoritmo de autenticação usado pelo protocolo ESP pode ser definido usando o algoritmo de autenticação
esp [md5 | sha1 | sha2-256 | sha2-384 | sha2-512] e algoritmo de criptografia esp [des | 3des | aes-128 |
aes-192 | aes-256] para atribuição de criptografia ESP. O algoritmo de autenticação do protocolo AH ah [md5 |
sha1 | sha2-256 | sha2-384 | O comando sha2-512] permite que a autenticação baseada em AH seja definida.
• A verificação dos parâmetros da proposta IPSec pode ser realizada por meio do comando display ipsec
proposal [nome <proposal-name>]. Como resultado, é possível visualizar propostas selecionadas ou todas as
propostas que foram criadas. O nome define o nome dado à proposta IPSec criada, enquanto o modo de
encapsulamento lista o modo atual que está sendo usado para essa proposta, que pode ser transporte ou
túnel. Transformar se refere aos algoritmos sendo aplicados, onde pode ser AH, ESP ou uma combinação de
transformações AH e ESP. Dependendo da transformação definida, os algoritmos associados serão listados.
• Os parâmetros nome-da-política e número-seq identificam uma política IPSec. Várias políticas IPSec com o mesmo
nome de política IPSec constituem um grupo de políticas IPSec. Um grupo de políticas IPSec contém no máximo 16
políticas IPSec, e uma política IPSec com o menor número de sequência tem a prioridade mais alta. Depois que um
grupo de políticas IPSec é aplicado a uma interface, todas as políticas IPSec do grupo são aplicadas à interface para
proteger diferentes fluxos de dados. Junto com o nome da política e o número de sequência, a política deve definir a
criação de SA manualmente ou por meio da negociação IKE.

• Se a negociação IKE for usada, os parâmetros devem ser definidos usando o comando ipsec-policy-template,
enquanto onde os parâmetros definidos manualmente são configurados conforme mostrado no exemplo. A ACL
criada está vinculada à política junto com a proposta criada. Os comandos túnel local e túnel remoto definem a
interface na qual o túnel IPSec estabelecerá e terminará. Um índice de parâmetro de origem (SPI) é definido tanto
de entrada quanto de saída.

• O SPI de entrada na extremidade local deve ser igual ao SPI de saída na extremidade remota. O SPI de saída na
extremidade local deve ser igual ao SPI de entrada na extremidade remota. Este número é usado para fazer
referência a cada SA, tendo em mente que uma SA se aplica em apenas uma direção, portanto, requer que o SPI
em ambas as direções seja especificado. Finalmente, as chaves de autenticação devem ser definidas novamente,
tanto de entrada quanto de saída. A chave de autenticação de saída na extremidade local deve ser igual à chave de
autenticação de entrada na extremidade remota. Onde a negociação IKE é usada, as chaves SPI e de autenticação
são negociadas automaticamente.
• Após a criação de uma política e a vinculação da proposta e ACL à política, a própria política pode ser aplicada
à interface física na qual o tráfego estará sujeito ao processamento IPSec. No exemplo dado, um túnel IPSec
deve ser estabelecido entre a interface Gigabit Ethernet 0/0/1 de RTA e Gigabit Ethernet 0/0/1 de RTB. Na
visualização da interface, o comando ipsec policy é usado para aplicar a política criada à interface.

• One interface can only use one IPSec policy group. To apply a new IPSec policy group to the interface, the
previous policy group must be firstly removed. An IPSec policy group that establishes an SA through IKE
negotiation can be applied to multiple interfaces, whereas an IPSec policy group that establishes an SA in
manual mode can be applied only to one interface. When sending a packet from an interface, the AR2200
matches the packet with each IPSec policy in the IPSec policy group. If the packet matches an IPSec policy, the
AR2200 encapsulates the packet according to the policy. If not, the packet is sent without encapsulation.
• Usando a política ipsec de exibição [breve | nome da política-nome [número seq]], uma política IPSec específica
ou todas as políticas IPSec podem ser visualizadas. Os parâmetros da política IPSec exibidos incluem o nome da
política e o número de sequência da política, normalmente usados para distinguir a prioridade das políticas em
um grupo em que um número de sequência inferior representa uma prioridade mais alta. As associações de
política, como o nome da proposta e a ACL usada para filtrar o tráfego em uma política, são exibidas junto com os
endereços de túnel local e remoto da política IPSec.
• As configurações de parâmetros específicos também são definidas no comando display ipsec policy para SA
nas direções de entrada e saída. O SPI faz referência ao SA em cada direção que pode ser usado como parte
do processo de solução de problemas para garantir que o SPI na interface local de saída corresponda àquele
definido para a interface remota de entrada na interface de mesmo nível (que corresponde ao endereço remoto
do túnel). A string de chave também será definida para o SA de entrada e de saída para o qual a mesma
avaliação de configuração local e remota pode ser realizada.
• Uma associação de segurança pode ser entendida como uma conexão unidirecional ou construção de
gerenciamento que define os serviços que serão usados para negociar o estabelecimento da conexão. A
conexão depende da correspondência de SA em ambas as direções para estabelecer com êxito a
comunicação bidirecional segura.

• Todo o tráfego que se destina a ser encaminhado através da interface de saída na qual o IPSec é estabelecido será
primeiramente submetido à filtragem através de um Security Policy Database (SPD). Isso geralmente está na forma
de uma ACL que determinará se o tráfego deve ser descartado (Descartar), encaminhado normalmente (Desvio) ou
encaminhado através de um limite IPSec seguro (Proteger).
• Soluções econômicas para comunicação entre redes privadas têm utilizado tecnologias como IPSec para
permitir que redes públicas compartilhadas atuem como um meio para preencher a lacuna entre escritórios
remotos. Esta solução fornece transmissão segura para cargas úteis de pacotes IP, mas não permite que
protocolos de roteamento, como RIP e OSPF, sejam transportados entre os dois terminais de túnel. GRE
foi originalmente desenvolvido como um meio de apoiar a transmissão de protocolos como IPX através de
redes IP; no entanto, ao longo do tempo, a função principal do GRE mudou para o suporte de
encapsulamento de protocolo baseado em roteamento.
• GRE pode ser aplicado dentro de um sistema autônomo para superar certas limitações encontradas nos
protocolos IGP. As rotas RIP oferecem, por exemplo, um limite de 15 saltos além do qual todas as rotas estão
sujeitas à regra de contagem até o infinito. A aplicação do GRE em tais ambientes permitirá a criação de um
túnel sobre o qual atualizações de roteamento podem ser realizadas, permitindo que a escala de roteamento
do vetor de distância seja aumentada significativamente quando necessário.
• Uma das principais limitações do GRE é a falta de capacidade de proteger os pacotes à medida que são transportados

por uma rede pública. O tráfego transportado dentro de um túnel GRE não está sujeito à criptografia, uma vez que tais

recursos não são suportados pelo GRE. Como resultado, as soluções IPSec são empregadas em conjunto com o GRE

para permitir que túneis GRE sejam estabelecidos dentro dos túneis IPSec para estender recursos, incluindo

integridade e confidencialidade para GRE.

• Depois de receber um pacote da interface que está conectada à rede privada, o pacote é entregue ao
módulo de protocolo de rede privada para processamento. O módulo de protocolo de rede privada
verifica o campo de endereço de destino no cabeçalho do pacote de rede privada, pesquisa a interface
de saída na tabela de roteamento ou na tabela de encaminhamento da rede privada e determina como
rotear esse pacote. Se a interface de saída for a interface de túnel, o módulo de protocolo de rede
privada enviará o pacote para o módulo de túnel.

• Depois de receber o pacote, o módulo de túnel em primeiro lugar encapsula o pacote de acordo com o tipo
de protocolo do protocolo do passageiro e os parâmetros de checksum são configurados para o túnel GRE
atual. Ou seja, o módulo de túnel adiciona um cabeçalho GRE ao pacote. Em seguida, adiciona um
cabeçalho IP de acordo com a configuração. O endereço de origem deste cabeçalho IP é o endereço de
origem do túnel; o endereço de destino do cabeçalho IP é o endereço de destino do túnel, após o qual o
pacote é entregue ao módulo IP. O módulo IP procura a interface de saída apropriada na tabela de
roteamento da rede pública com base no endereço de destino no cabeçalho IP e encaminha o pacote. O
pacote encapsulado é então transmitido pela rede pública.

• Após receber o pacote da interface que está conectada à rede pública, a interface de saída analisa o
cabeçalho IP, determina o destino do pacote e descobre que o campo Tipo de protocolo é 47, indicando
que o protocolo é GRE.

• A interface de saída entrega o pacote ao módulo GRE para processamento. O módulo GRE remove o
cabeçalho IP e o cabeçalho GRE, e aprende com o campo Tipo de protocolo no cabeçalho GRE que o
protocolo do passageiro é o protocolo executado na rede privada, o módulo GRE então entrega o pacote
para este protocolo. O próprio protocolo trata o pacote como qualquer pacote comum.
• A autenticação de chave indica a autenticação em uma interface de túnel. Esse mecanismo de segurança
pode evitar que a interface de túnel identifique e receba incorretamente os pacotes de outros dispositivos.
Se o bit K no cabeçalho GRE for definido como 1, o campo Chave será inserido no cabeçalho GRE. Tanto
o receptor quanto o remetente executam a autenticação da chave no túnel.

• O campo Chave contém um valor de quatro bytes, que é inserido no cabeçalho GRE durante o encapsulamento do

pacote. O campo Chave é usado para identificar o tráfego no túnel. Os pacotes do mesmo fluxo de tráfego têm o

mesmo campo Chave. Quando os pacotes são desencapsulados, a extremidade do túnel identifica os pacotes do

mesmo tráfego de acordo com o campo Chave. A autenticação pode ser passada apenas quando os campos de chave

definidos em ambas as extremidades do túnel são consistentes, caso contrário, os pacotes são descartados.
• A função de detecção de manutenção de atividade é usada para detectar se o link de túnel está no estado
de manutenção de atividade a qualquer momento, ou seja, se o par do túnel está acessível. Se o par não
estiver acessível, o túnel será desconectado para evitar a ocorrência de buracos negros. Depois que a
função Keepalive é habilitada, a extremidade local do túnel GRE envia periodicamente um pacote de
detecção keepalive ao par. Se o par estiver acessível, a extremidade local receberá um pacote de resposta
do par. A função keepalive operará enquanto pelo menos uma extremidade estiver configurada com a
função keepalive, o par não precisa ter a função keepalive habilitada. Se o peer receber um pacote de
detecção de keepalive, ele enviará um pacote de resposta para a extremidade local, independentemente de
estar configurado com a função de keepalive.

• Depois que a função de manutenção de atividade é habilitada, a fonte de um túnel GRE cria um contador, envia
periodicamente os pacotes de detecção de manutenção de atividade e conta o número de pacotes de detecção.
O número aumenta em um após o envio de cada pacote de detecção.

• Se a fonte receber um pacote de resposta antes que o valor do contador atinja o valor predefinido, a fonte
considera que o par está acessível. Se a fonte não receber um pacote de resposta antes que o contador
atinja o valor predefinido que define o número de tentativas, a fonte considera que o par está inacessível e
procederá ao fechamento do túnel de conexão.
• O estabelecimento do GRE requer inicialmente a criação de uma interface de túnel. Depois de criar uma interface

de túnel, especifique GRE como o tipo de encapsulamento, defina o endereço de origem do túnel ou interface de

origem e defina o endereço de destino do túnel. Além disso, defina o endereço de rede da interface de túnel para

que o túnel possa suportar rotas. As rotas para um túnel devem estar disponíveis nos dispositivos de origem e

destino para que os pacotes encapsulados com GRE possam ser encaminhados corretamente. Uma rota que

passa por interfaces de túnel pode ser uma rota estática ou uma rota dinâmica.

• Outro ponto importante que deve ser levado em consideração durante a fase de configuração é o MTU.
O GRE resulta em 24 bytes adicionais de sobrecarga sendo aplicados aos cabeçalhos existentes e à
carga útil, resultando no potencial de fragmentação desnecessária. Isso pode ser resolvido ajustando o
tamanho da MTU usando o comando mtu <mtu> para permitir que os pacotes compensem a
sobrecarga adicional criada. Um MTU de 1476 é considerado um ajuste suficiente para o MTU, para
reduzir a carga adicional na interface.
• O status de execução e as informações de roteamento para a interface de túnel GRE podem ser
observados após a criação da interface de túnel. Uma interface de túnel ativa pode ser confirmada quando
o estado atual do túnel e o estado do protocolo da camada de link (linha) são exibidos como UP. Qualquer
ajuste ao MTU existente pode ser identificado para garantir que a sobrecarga adicional não seja criada
como resultado da fragmentação. O endereço da Internet representa o endereço IP do túnel configurado na
interface de saída. A origem e o destino do túnel exibem os endereços IP da interface física que está sendo
usada, sobre a qual o túnel GRE é estabelecido.
• A acessibilidade das redes através do túnel GRE pode ser determinada com base na tabela de roteamento
de IP que é exibida usando o comando display ip routing table. Nesse caso, é possível identificar o endereço
de rede de origem interna de uma rede local e sua capacidade de alcançar o endereço de rede de destino de
uma rede remota por meio de uma interface de túnel baseada em GRE. O endereço de destino se refere ao
endereço de rede que é alcançado pelo túnel GRE, enquanto o endereço do próximo salto faz referência ao
endereço IP da interface do túnel remoto GRE.
• A função keepalive pode ser habilitada na interface do túnel GRE especificando o comando keepalive
[período <period> [retry-times <retry-times>]], onde o período determina o número de segundos decorridos
antes de cada keepalive ser enviado, isto por padrão é definido para um período de 5 segundos. O número
de vezes que um keepalive será enviado é definido usando o parâmetro retry-times <retry-times>, que por
padrão é definido como 3 tentativas. Se o par não responder dentro do número de novas tentativas
definido, a comunicação entre as duas extremidades do túnel será considerada como falha e o túnel GRE
continuará a ser interrompido.
• O comando display interface tunnel pode ser aplicado novamente para avaliar se o túnel ainda está ativo
após uma perda de comunicação entre os pontos finais do túnel GRE. No exemplo, verifica-se que o status
da camada de link do túnel GRE mudou para um estado inativo, denotando que ocorreu uma falha na
comunicação. A função keepalive está atualmente habilitada e exibe um período de keepalive de três
segundos entre cada mensagem enviada. O número de novas tentativas também foi determinado como
permitindo uma perda de respostas de até três vezes.
• GRE fornece um meio de estabelecer roteamento dinâmico entre redes remotas que normalmente
pertencem a um único domínio administrativo, como no caso de filiais. A VPN IPSec é geralmente usada
para fornecer um túnel privado site a site através do qual as informações dinâmicas de roteamento podem
ser transmitidas; no entanto, os túneis VPN IPSec não suportam o encaminhamento de atualizações de
roteamento por IPSec diretamente, portanto, GRE é implementado.

• O endereço da Internet representa um endereço de rede de túnel virtual sobre o qual o GRE é
estabelecido, enquanto a origem do túnel faz referência ao ponto de entrada no qual o túnel é
estabelecido.
• O protocolo de gerenciamento de rede simples (SNMP) é um protocolo de gerenciamento de rede amplamente usado

na rede TCP / IP. SNMP é um método de gerenciamento de elementos de rede usando uma estação de trabalho de

console de rede que executa um software de gerenciamento de rede.

• O SNMP pode ser usado para realizar várias operações comunicativas. A Estação de Gerenciamento de Rede
(NMS) depende do SNMP para definir fontes de informações de rede e obter informações de recursos de rede.
O SNMP também é usado para retransmitir relatórios na forma de mensagens de trap para o NMS, de modo
que a estação possa obter o status da rede quase em tempo real, para permitir ao administrador da rede agir
rapidamente no caso de discrepâncias e falhas do sistema.

• SNMP é amplamente utilizado para gerenciar programas de aplicativos, contas de usuário e permissões de
gravação / leitura (licenças) etc., bem como para gerenciar o hardware que compõe a rede, incluindo estações de
trabalho, servidores, placas de rede, dispositivos de roteamento e switches. Normalmente, esses dispositivos estão
localizados longe do escritório central onde o administrador da rede está baseado. Quando ocorrem falhas nos
dispositivos, espera-se que o administrador da rede seja notificado automaticamente sobre as falhas. O SNMP
opera efetivamente como um meio de comunicação entre os elementos da rede e o administrador da rede / NMS.
• Os elementos de rede, como hosts, gateways, servidores de terminal, etc., contêm dois componentes
importantes que oferecem suporte às funções de gerenciamento de rede solicitadas pelas estações de
gerenciamento de rede. O agente de gerenciamento reside no elemento de rede para recuperar (obter) ou alterar
(definir) variáveis.

• Estações de gerenciamento de rede (NMS) associadas a agentes de gerenciamento que são responsáveis por
executar as funções de gerenciamento de rede solicitadas pelo NMS. O MIB armazena uma série de variáveis
associadas ao elemento de rede, com cada uma dessas variáveis sendo considerada um objeto MIB. A troca de
mensagens SNMP dentro do IP requer apenas o suporte de UDP como um serviço de datagrama não confiável,
para o qual cada mensagem é representada independentemente por um único datagrama de transporte.
• Uma Management Information Base (MIB) especifica as variáveis mantidas pelos elementos da rede. Essas variáveis

são as informações que podem ser consultadas e definidas pelo processo de gestão. Um MIB apresenta uma

estrutura de dados, coletando todos os objetos gerenciados possíveis na rede. O SNMP MIB adota uma estrutura de

árvore semelhante à encontrada em um Sistema de Nomes de Domínio (DNS).

• A árvore de nomenclatura de objetos tem três objetos principais: ISO, ITU-T (originalmente CCITT) e o ramo de
organizações conjuntas. Na ISO, existem quatro objetos entre os quais o número 3 é a organização identificada. Uma
subárvore do dod (6) do Departamento de Defesa dos Estados Unidos é definida na organização identificada (3) sob a
qual a subárvore Internet (1) está localizada. O objeto sob a Internet é mgmt (2). O que se segue ao mgmt (2) é o
MIB-II, originalmente MIB até 1991 quando a nova edição do MIB-II foi definida. O próprio caminho da árvore pode ser
definido como um valor de identificador de objeto (OID) {1.3.6.1.2.1}.
• SNMP define cinco tipos de Protocol Data Units (PDUs), a saber, pacotes SNMP, a serem trocados entre o
processo de gerenciamento e o processo do agente. A operação getrequest indica que o processo de
gerenciamento lê um ou mais valores de parâmetro do MIB do processo do agente. O get-next-request indica
que o processo de gerenciamento lê o próximo valor do parâmetro na ordem lexicográfica do MIB do processo
do agente. O set-request indica que o processo de gerenciamento define um ou mais valores de parâmetro no
MIB do processo do agente. O get-response retorna um ou mais valores de parâmetro. Esta operação é
executada pelo processo do agente. É a resposta às três operações anteriores. Por último, está a função trap
que é ativamente enviada pelo processo do agente para informar o processo de gerenciamento de eventos
importantes ou críticos.
• SNMPv1 é o protocolo de aplicação original pelo qual as variáveis do MIB de um agente podem ser
inspecionadas ou alteradas. A evolução do SNMP envolveu não apenas mudanças no protocolo, mas também no
MIB que foi usado. Novos objetos foram definidos no MIB resultando na definição do MIB-II (ou MIB-2), incluindo,
por exemplo, sysContact. sysName, sysLocation, sysServices para fornecer informações de contato,
administrativas, de localização e de serviço relacionadas ao nó gerenciado no grupo de sistemas e objetos
ipRouteMask, ipRouteMetric5 e ipRouteInfo incluídos como parte do objeto de tabela de rota IP.

• A transição para a versão 2 do SNMP envolveu uma série de revisões que resultaram no desenvolvimento do
SNMPv2c, incluindo a introdução de um novo tipo de PDU na forma de GetBulkRequest-PDU para permitir que
informações de vários objetos sejam recuperadas em uma única solicitação e a Solicitação de Informação, um PDU de
comunicação de gerente para gerente, usado onde um gerente envia informações de uma visualização MIB para outro
gerente. Objetos específicos também usam contadores como sintaxe que na versão 1 do SNMP representava um valor
de 32 bits. Isso significava que em determinados objetos, como a contagem de bytes de interfaces, era fácil para o
contador completar um ciclo completo de valores e agrupamento, semelhante ao hodômetro que mede a
quilometragem em veículos.

• Usando o contador de 32 bits, os octetos em uma interface Ethernet transmitindo a 10 Mbps seriam encerrados em 57
minutos, a 100 Mbps o contador seria encerrado em 5,7 minutos e a 1 Gbps levaria apenas 34 segundos antes de o contador
girar completamente. Os objetos são comumente pesquisados (inspecionados) a cada 1 ou 5 minutos, e surgem problemas
quando os contadores são agrupados mais de uma vez entre a pesquisa do objeto, pois uma medição verdadeira não pode
ser determinada.

• Para resolver isso, novos contadores foram definidos no SNMP versão 2c na forma de contadores de 64 bits para qualquer
situação em que os contadores de 32 bits envolvam muito rápido, o que se traduzia em qualquer interface que conte mais
rápido do que 650 milhões de bits por segundo. Em comparação, usando um contador de 64 bits para contar octetos em um
1Tbps (1.000 Gbps)
será encerrado em menos de 5 anos e levaria um link de 81 milhões de Tbps para fazer com que um contador de 64 bits fosse
encerrado em 30 minutos.
• Uma das principais melhorias do SNMPv3 diz respeito à segurança da transmissão de informações do objeto
MIB. Várias ameaças podem ser identificadas. Isso inclui a modificação das informações do objeto de uma
entidade não autorizada durante o trânsito, a execução de operações de gerenciamento não autorizadas por
usuários disfarçados de outro usuário autorizado; espionagem em trocas de mensagens e modificação do
fluxo de mensagens por meios como a reprodução da mensagem.

• SNMP aumenta a segurança através da aplicação de quatro medidas principais. A integridade dos dados é aplicada para garantir

que os dados não tenham sido alterados ou destruídos de maneira não autorizada, nem as sequências de dados tenham sido

alteradas a uma extensão maior do que pode ocorrer de forma não maliciosa.

• A autenticação da origem dos dados é suportada para garantir que a identidade reivindicada do usuário em cujo nome os

dados recebidos foram originados seja corroborada usando MD5 e SHA-1. A confidencialidade dos dados é aplicada para

garantir que as informações não sejam disponibilizadas ou divulgadas a indivíduos, entidades ou processos não

autorizados. Além disso, as soluções para proteção de reprodução limitada fornecem um meio de garantir que uma

mensagem cujo tempo de geração esteja fora de uma janela de tempo especificada não seja aceita.
• O agente SNMP é um processo de agente em um dispositivo na rede. O agente SNMP mantém os dispositivos de
rede gerenciados respondendo às solicitações do NMS e relatando dados de gerenciamento ao NMS. Para
configurar o SNMP em um dispositivo, o agente SNMP deve estar habilitado, para o qual o comando snmp-agent é
aplicado.

• O comando snmp-agent sys-info define as informações do sistema SNMP e também é usado para especificar a
(s) versão (ões) do SNMP que são suportadas, onde snmp-agent sysinfo version [[v1 | v2c | v3] * | all] é usado
para isso e deve-se observar que todas as versões do SNMP são suportadas por padrão. O comando
snmp-agent trap enable ativa a função de envio de traps à NMS, após a qual o dispositivo passará a relatar
quaisquer eventos configurados à NMS.

• Além disso, é necessário especificar a interface por meio da qual as notificações de trap serão enviadas. Esta
deve ser a interface apontando para a localização do NMS, como no exemplo onde o NMS é alcançado
através da interface Gigabit Ethernet 0/0/1.
• O uso do comando display snmp-agent sys-info exibe informações de contato do pessoal responsável pela
manutenção do sistema, a localização física do dispositivo e as versões SNMP atualmente suportadas. As
informações fornecidas no exemplo representam as informações do sistema padrão típicas encontradas nos
roteadores da série Huawei AR2200, no entanto, isso pode ser alterado através do uso do snmpagent
sys-info [contato | localização | version] parâmetros para refletir detalhes de contato e localização relevantes
para cada dispositivo individual.
• No roteador da série Huawei AR2200, todas as versões do SNMP (SNMPv1, SNMPv2c e SNMPv3) são
habilitadas por padrão.

• O agente encaminha mensagens de trap para a Estação de Gerenciamento de Rede (NMS) usando a porta UDP

de destino 162.
• Como um conjunto de especificações definidas pela Internet Engineering Task Force (IETF), o protocolo da
Internet versão 6 (IPv6) é o padrão de protocolo da camada de rede da próxima geração e o sucessor do
protocolo da Internet versão 4 (IPv4). A diferença mais óbvia entre IPv6 e IPv4 é que os endereços IP são
aumentados de 32 bits para 128 bits. Ao fazer isso, o IPv6 é capaz de suportar um número maior de níveis de
hierarquia de endereçamento, um número muito maior de nós endereçáveis e uma configuração automática
mais simples de endereços.

• O intervalo de endereços IPv4 existente foi implementado em um momento em que redes como a ARPANET e
a National Science Foundation Network (NSFNET) representavam a rede principal de backbone e em um
momento em que o IPv4 era considerado mais do que suficiente para suportar a gama de hosts que se
conectariam a essas redes em formação. A evolução imprevista da Internet a partir dessas redes ancestrais
resultou no rápido consumo do espaço de endereços IPv4 de 4,3 bilhões de endereços (dos quais muitos são
reservados), para os quais contra-medidas na forma de NAT e CIDR foram postas em prática para aliviar o
expansão, e dar tempo para uma solução mais permanente ser formada. Além disso,

• No entanto, espera-se que a rede IP elimine seu endereçamento IPv4 para dar lugar ao IPv6 e fornecer a capacidade

de endereçamento de mais de 340 undecilhões de endereços exclusivos, considerados mais do que o necessário para

o crescimento contínuo da rede IP. Junto com isso, a alocação de endereços pela Internet Assigned Numbers Authority

(IANA) garante que a alocação de endereços para IPv6 seja contígua para um gerenciamento futuro eficiente das

tabelas de roteamento IP.

• O cabeçalho IPv6 exigiu algum nível de expansão para acomodar o tamanho aumentado do endereço IP, porém muitos
outros campos que foram considerados redundantes em muitos casos de encaminhamento de pacotes foram removidos
para simplificar o design geral do cabeçalho IPv6 e otimizar o nível de sobrecarga que é necessária durante cada pacote
que é encaminhado pela rede. Em comparação com o cabeçalho do pacote IPv4, o cabeçalho do pacote IPv6 não contém
mais um comprimento de cabeçalho da Internet (IHL), identificador, sinalizadores, deslocamento de fragmento, soma de
verificação de cabeçalho, opções ou campos de preenchimento, mas em vez disso carrega um campo de rótulo de fluxo.

• O termo fluxo pode ser entendido como um fluxo contínuo de pacotes unicast, multicast ou anycast relacionados a um
aplicativo ou processo específico que se originam de uma determinada fonte e são transmitidos para um determinado
destino ou múltiplos destinos. O comportamento natural de uma rede comutada por pacotes significa que tais fluxos de
tráfego podem ser transportados por vários caminhos e chegar ao destino pretendido fora da seqüência. Os recursos
do sistema são então necessários para sequenciar novamente o fluxo do pacote antes que ele possa ser processado
pelas camadas superiores.

• O rótulo de fluxo pretende identificar esses fluxos de tráfego, juntamente com os campos de endereço de
origem e destino, para manter um caminho comum entre as redes para todos os pacotes associados ao fluxo
de tráfego. Ao fazer isso, os pacotes são capazes de manter a sequência na rede IP e isso otimiza a
eficiência do processo.

• À medida que a convergência de rede IP introduz tecnologias como a voz, que depende de um comportamento de fluxo de
tráfego comutado por circuito e desempenho quase em tempo real, a importância do campo de rótulo de fluxo torna-se
mais importante.

• Várias opções também podem ser suportadas sem alterar o formato do pacote existente, com a inclusão de campos
de informações de cabeçalho de extensão. Esses campos de cabeçalho de extensão são referenciados por meio do
campo Próximo Cabeçalho que substitui o campo de protocolo encontrado no IPv4, a fim de fornecer flexibilidade
adicional no IPv6.
• O cabeçalho de extensão é uma das principais mudanças no IPv6 para permitir que o cabeçalho IPv6 seja mais simplificado.

Existem vários cabeçalhos de extensão no IPv6 e são referenciados diretamente por meio de um valor hexadecimal no campo

Próximo Cabeçalho IPv6, da mesma forma que os cabeçalhos ICMP, TCP, UDP são referenciados no campo de protocolo do

cabeçalho IPv4. Cada cabeçalho de extensão também contém um próximo campo de cabeçalho para fazer referência ao

próximo cabeçalho após o processamento do cabeçalho de extensão. Vários cabeçalhos de extensão podem ser associados

a um pacote e cada um deles referenciado em sequência. A lista de cabeçalhos de extensão e a seqüência em que os

cabeçalhos de extensão são processados são as seguintes.

• Cabeçalho IPv6

• Cabeçalho de opções hop-by-hop

• Cabeçalho de opções de destino

• Cabeçalho de roteamento

• Cabeçalho de fragmento

• Cabeçalho de autenticação

• Encapsulating Security Payload header Destination

• Options header

• Cabeçalho da camada superior (como no túnel IPv6)

• Cada cabeçalho de extensão deve ocorrer no máximo uma vez, exceto para o cabeçalho de opções de destino, que

deve ocorrer no máximo duas vezes (uma vez antes de um cabeçalho de roteamento e uma vez antes do cabeçalho da

camada superior). Outro aspecto importante dos cabeçalhos de extensão é a introdução de protocolos IPSec na forma

de AH e ESP para aprimorar a segurança geral do IPv6.

• O endereço IPv6 é um identificador de 128 bits associado a uma interface ou conjunto de interfaces (no caso de

atribuição de endereço anycast abordada posteriormente). A notação de endereço devido ao tamanho é comumente

definida em formato hexadecimal e escrita na forma de xxxx: xxxx: xxxx: xxxx: xxxx: xxxx: xxxx: xxxx, onde xxxx está

relacionado aos quatro dígitos hexadecimais que se traduzem em um binário de 16 bits valor. O conjunto de valores

hexadecimais agrupados de 8 * 16 bits compreende o endereço IPv6 de 128 bits.

• O endereço em si é composto de um prefixo IPv6 usado para determinar a rede IPv6, seguido por um ID de
interface. O esquema de endereçamento básico representa uma arquitetura de duas camadas de prefixo e ID de
interface, no entanto, os tipos de endereço IPv6 podem conter muitos subníveis que permitem que uma extensa
arquitetura de endereçamento hierárquico seja formada na rede IPv6, para suportar agrupamento e
gerenciamento eficazes de usuários e domínios.
• O extenso tamanho de 128 bits do endereço IPv6 significa que a notação escrita geral pode ser impraticável em
muitos casos. Outro fator que permanecerá comum por algum tempo é a presença de longas sequências de
bits zero, principalmente devido à enormidade insondável da escala de endereços envolvida. Isso, entretanto,
traz um meio de simplificação e praticidade ao escrever endereços IPv6 que contêm zero bits. Um meio inicial
de simplificação do escopo do endereço é através da remoção de quaisquer valores de zero à esquerda
encontrados em cada conjunto de valores hexadecimais de 16 bits.

• Uma sintaxe especial está disponível para comprimir ainda mais os zeros e é representada na forma de dois pontos

duplos ou "::“. Este valor indica um ou mais grupos de zeros de 16 bits. No entanto, para permitir que o tamanho da string

seja determinável, o "::" só pode aparecer uma vez em um endereço. Os dois pontos duplos "::" podem ser usados para

compactar os zeros à esquerda em um endereço, conforme mostrado no exemplo fornecido.

• O espaço de endereçamento IPv6 ainda não foi completamente definido em primeiro lugar devido à magnitude do espaço de
endereçamento, para o qual não é provável que seja necessário em um futuro próximo, em segundo lugar, a formulação de
esquemas de endereçamento ainda está um pouco em um estágio inicial com muito discussão ocorrendo com relação aos tipos
de endereço que devem ser aplicados.

• Atualmente, uma fração do intervalo de endereços foi seccionada para uso na forma de um intervalo de endereços 2000 ::
/ 3 que representa um intervalo de endereços unicast global. Pode ser entendido como qualquer endereço roteável na rede
IP pública. O órgão administrativo IANA (agora parte da ICANN) é responsável por distribuir partes desse intervalo de
endereços para vários Registros Regionais da Internet (RIR) que gerenciam o endereçamento para uma das cinco regiões
do mundo. Superconjuntos de endereços IPv6 na forma de 2400 :: / 12 (APNIC), 2600 :: / 12 (ARIN), 2800 :: / 12
(LACNIC), 2A00 :: / 12 (RIPE NCC) e 2C00 :: / 12 (AfriNIC) foram alocados, permitindo que o potencial de endereçamento
para uma determinada região seja referenciado e gerenciado, entretanto, usando um único prefixo de endereço. Também
contidos no intervalo de prefixo 2000 :: / 3 estão os campos de endereço reservados, incluindo 2001: 0DB8 ::

• O endereçamento multicast é definido no IPv6 como FF00 :: / 8, com grande parte do escopo do endereçamento sendo
reservado para intervalos de endereços específicos (como link local) e no suporte de protocolos de roteamento, de maneira
semelhante a como os endereços multicast são usados no IPv4 . Uma grande mudança no IPv6 é que não há endereços de
broadcast, sua função sendo substituída por endereços multicast, o que reduz o processamento desnecessário por estações
finais na camada MAC dentro de redes IPv6, uma vez que os hosts são capazes de filtrar grupos de endereços MAC
multicast.

• Alguns endereços especiais também existem no IPv6, incluindo o endereço não especificado :: / 128 que representa uma
interface para a qual não há endereço IP atualmente atribuído. No entanto, isso não deve ser confundido com o endereço
IP padrão :: / 0 que é usado como um valor de endereço padrão para qualquer rede da mesma forma que o endereço
padrão 0.0.0.0/0 é usado no IPv4. Para o endereço de loopback (127.0.0.1), isso é definido no IPv6 como o endereço
reservado :: 1/128.
• O endereçamento unicast compreende principalmente unicast global e prefixos de endereço unicast local de
link; no entanto, também existem outras formas. Todos os endereços unicast globais têm um campo de ID de
interface de 64 bits, com exceção de endereços para os quais os três primeiros bits no endereço são 000. Para
esses endereços, não há restrição no tamanho ou estrutura do campo de ID de interface. O formato de
endereço para endereços unicast globais consiste em uma hierarquia na forma de um prefixo de roteamento
global e um identificador de sub-rede, seguido pelo identificador de interface. O prefixo de roteamento global é
projetado para ser estruturado hierarquicamente pelos Registros Regionais da Internet (RIR) e pelos
Provedores de Serviços da Internet (ISP) aos quais o RIR distribui prefixos de endereço IP.

• Em termos de endereço unicast local de link, o FE80 :: / 10 significa que os primeiros 10 bits do endereço local de
link são claramente distinguíveis como 1111111010. A faixa de endereço de interface de 64 bits é mais do que
suficiente para o endereçamento de hosts, e portanto, os 54 bits restantes no endereço local do link são mantidos
como 0. O exemplo exibe os formatos de endereço que podem ser normalmente associados a cada um dos tipos
de endereço unicast comuns.

• Deve-se notar também que um terceiro esquema de endereçamento unicast, referido como endereçamento local de
site (FC00 :: / 7) foi originalmente proposto em RFC3513 e pode aparecer em algumas implementações de IPv6, no
entanto, o intervalo de endereçamento foi preterido a partir de RFC4291 e deve ser evitado como parte de futuras
implementações.
• Um endereço multicast é um identificador para um conjunto de interfaces (normalmente pertencentes a nós diferentes). Um

pacote enviado a um endereço multicast é entregue a todas as interfaces identificadas por esse endereço. O intervalo de

endereços multicast é determinado a partir de um prefixo de endereço FF00 :: / 8 e é claramente distinguível dos primeiros 8

bits, que são sempre definidos como 11111111. A arquitetura de endereço para endereços multicast compreende

sinalizadores, campos de escopo e ID de grupo.

• O campo sinalizadores embora 4 bits, é atualmente usado para suportar a identificação se um endereço multicast é

bem conhecido (como atribuído e reconhecido pela autoridade de numeração da Internet global) ou transiente, o que

significa que o endereço multicast é temporariamente atribuído. Um segundo valor de bit é usado no campo

sinalizadores para determinar se o endereço multicast é ou não baseado no prefixo da rede. Os dois bits de ordem

superior restantes são reservados e permanecem definidos como 0.

• O escopo define uma série de intervalos potenciais aos quais o multicast é aplicado. Geralmente, isso pode se referir
a um escopo local do nó FF01 ::, ou ao escopo local do link FF02 :: que se refere aos ouvintes dentro do escopo da
camada do link, como um segmento Ethernet para o qual um gateway define o limite. Os endereços multicast locais
de link bem conhecidos comuns incluem FF02 :: 1, que é usado para encaminhar para todos os nós, e FF02 :: 2, que
permite a transmissão multicast para todos os endereços do roteador.
• Anycast representa um identificador para um conjunto de interfaces (normalmente pertencentes a nós diferentes). Um pacote
enviado a um endereço anycast é entregue a uma das interfaces identificadas por aquele endereço (a "mais próxima", de
acordo com a medida de distância dos protocolos de roteamento). A arquitetura anycast geralmente envolve um iniciador
anycast e um ou vários respondentes anycast.

• O iniciador anycast pode geralmente ser um host que está perguntando a um serviço, como no caso de uma pesquisa de DNS, ou

solicitando a recuperação de dados específicos, como informações de página da web HTTP. Os endereços anycast não são

distinguíveis de forma alguma dos endereços deunicast, com a exceção de que várias instâncias do mesmo endereço são aplicadas

a um determinado dispositivo.

• O aplicativo para anycast em relação aos métodos tradicionais de endereçamento traz muitos benefícios potenciais para a
operação e o desempenho da rede corporativa. A redundância de serviço é um aplicativo para anycast que permite que um
serviço como o HTTP seja usado em vários servidores, para os quais o mesmo endereço está associado a um ou mais
servidores que operam como respondedores anycast. No caso de ocorrer falha de serviço em um servidor, os clientes
precisam tradicionalmente procurar o endereço de outro servidor e, em seguida, reiniciar / restabelecer a comunicação.

• Usando o endereçamento anycast, o iniciador anycast estabelece automaticamente a comunicação com outro servidor que
está usando o mesmo endereço, fornecendo uma solução de redundância eficaz.

• Em termos de desempenho, o acesso multi-servidor pode ser aplicado, onde um iniciador anycast estabelece uma conexão com
o mesmo endereço unicast, cada conexão estabelece automaticamente para vários servidores que especificam o mesmo
endereço anycast, como no caso de um cliente navegando em uma empresa página da web.

• O cliente baixará o arquivo html e os arquivos de imagem individuais de servidores espelho separados. Como resultado, o

iniciador anycast libera a largura de banda de vários servidores para baixar a página da web muito mais rapidamente do

que seria possível com uma abordagem unicast.

• Ao se estabelecer fisicamente com uma rede IPv6, os hosts devem estabelecer um endereço IPv6 exclusivo e

parâmetros associados, como o prefixo da rede. Os roteadores enviam mensagens de anúncio de roteador

periodicamente e também em resposta a Solicitações de roteador (RS) para oferecer suporte à descoberta de

roteador, usado para localizar um roteador vizinho e aprender o prefixo de endereço e os parâmetros de configuração

para autoconfiguração de endereço.

• O IPv6 oferece suporte à configuração automática de endereço sem estado (SLAAC), que permite aos hosts obter

prefixos IPv6 e gerar IDs de interface automaticamente sem exigir um serviço externo, como DHCP. A descoberta do

roteador é a base para a configuração automática de endereços IPv6 e é implementada por meio de dois formatos de

mensagem.

• As mensagens de anúncio de roteador (RA) permitem que cada roteador envie periodicamente mensagens de

multicast RA que contêm parâmetros de configuração de rede, a fim de declarar a existência do roteador para hosts da

camada 2 e outros roteadores. Uma mensagem RA é identificada por um valor de 134 no campo de tipo da

mensagem. As mensagens de solicitação de roteador (RS) são geradas depois que um host é conectado à rede.

• Os roteadores enviarão periodicamente mensagens RA; entretanto, se um host desejar solicitar uma
mensagem RA, o host enviará uma mensagem RS. Os roteadores na rede irão gerar uma mensagem RA para
todos os nós para notificar o host do roteador padrão no segmento e parâmetros de configuração
relacionados. A mensagem RS gerada por um host pode ser distinguida pelo campo de tipo que contém um
valor de 133.
• Para facilitar a comunicação em uma rede IPv6, cada interface deve receber um endereço IPv6 válido. O ID da
interface do endereço IPv6 pode ser definido por meio da configuração manual por um administrador de rede,
gerado por meio do software do sistema ou gerado usando o formato IEEE 64-bit Extended Unique Identifier
(EUI-64).

• Devido à praticidade, o meio mais comum de endereçamento IPv6 é gerar o ID da interface usando o formato
EUI-64. Os padrões IEEE EUI-64 usam o endereço MAC da interface para gerar uma ID de interface IPv6. O
endereço MAC, entretanto, representa um endereço de 48 bits, enquanto a ID de interface necessária deve ser
composta por um valor de 64 bits. Os primeiros 24 bits (expressos por c) do endereço MAC representam o ID do
fornecedor (empresa), enquanto os 24 bits restantes (expressos por e) representam o identificador de extensão
exclusivo atribuído pelo fabricante.

• O sétimo bit mais alto no endereço representa um bit universal / local para habilitar identificadores de interface
com escopo universal. Onde este valor é 0, o endereço MAC é único globalmente. Durante a conversão, o
processo EUI-64 insere dois valores de octeto "0xFF" e "0xFE" totalizando 16 bits entre o identificador do
fornecedor e o identificador de extensão do endereço MAC, e o bit 0 universal / local é alterado para 1 para
indicar que a interface ID agora representa um valor de endereço globalmente exclusivo. Um ID de interface de
64 bits é criado e associado ao prefixo da interface para gerar o endereço da interface IPv6.
• Antes que um endereço unicast IPv6 seja atribuído a uma interface, a Detecção de endereço duplicado (DAD) é
realizada para verificar se o endereço é usado por outro nó. O DAD é necessário se os endereços IP forem
configurados automaticamente. Um endereço unicast IPv6 atribuído a uma interface, mas não verificado pelo
DAD, é chamado de endereço provisório. Uma interface não pode usar o endereço provisório para comunicação
unicast, mas unirá dois grupos multicast: grupo multicast de TODOS os nós e grupo multicast de nó solicitado.

• Um endereço multicast de Nó Solicitado é gerado pegando os últimos 24 bits de um endereço unicast ou

anycast e anexando o endereço ao
FF02: 0: 0: 0: 0: 1: FF00 :: / 104 prefixo. No caso em que o endereço 2000 :: 1 é usado, o endereço de
multicast do nó solicitado FF02 :: 1: FF00: 1 seria gerado.

• O IPv6 DAD é semelhante ao protocolo ARP gratuito usado no IPv4 para detectar endereços de host IPv4
duplicados na atribuição de endereço ou conexão do host à rede. Um nó envia uma mensagem de solicitação
de vizinho (NS) que solicita que o endereço provisório seja usado como o endereço de destino para o grupo
multicast Solicitednode.

• Se o nó receber uma mensagem de resposta de anúncio de vizinho (NA), o endereço provisório é confirmado
como sendo usado por outro nó e o nó não usará este endereço provisório para comunicação, após o que a
atribuição manual de um endereço por um administrador seria necessária.
• O endereço 2001: 0DB8: 0000: 0000: 0000: 0000: 032A: 2D70 pode ser condensado em 2001: DB8 :: 32A: 2D70. Os dois

pontos duplos podem ser usados para condensar sequências de zeros que costumam existir devido ao tamanho insondável

do espaço de endereço IPv6, mas só podem ser usados uma vez. Os valores de zero à esquerda podem ser condensados,

no entanto, os valores de zero à esquerda nas strings de endereço devem ser mantidos.

• O formato de identificador exclusivo estendido de 64 bits (EUI-64) pode ser usado para gerar um endereço IPv6
exclusivo. Isso é obtido inserindo-se dois valores de octeto 'FF' e 'FE' no endereço MAC de 48 bits existente da
interface, para criar um valor de 64 bits exclusivo que é adotado como o endereço IPv6 da interface da estação
final. A validação do endereço como um valor exclusivo é confirmada por meio do protocolo Duplicate Address
Detection (DAD).
• OSPFv3 é a versão do OSPF que é usada em redes IPv6 e, em termos de comunicação, assume que cada roteador
recebeu endereços unicast de link local em cada um dos links físicos anexados ao roteador. Os pacotes OSPF são
enviados usando o endereço unicast local de link associado de uma determinada interface física como o endereço de
origem. Um roteador aprende os endereços de link-local de todos os outros roteadores anexados a seus links e usa
esses endereços como informações do próximo salto durante o encaminhamento de pacotes. Esta operação é
verdadeira para todos os links físicos, com exceção dos links virtuais que estão fora do escopo deste material.

• Um endereço multicast reservado “AllSPFRouters” foi atribuído ao valor FF02 :: 5, refletindo o endereço multicast

224.0.0.5 usado em OSPFv2, para o qual deve ser observado que as duas versões não são compatíveis. Todos os

roteadores que executam OSPFv3 devem estar preparados para receber os pacotes enviados para este endereço. Os

pacotes de saudação são sempre enviados para este destino, assim como certos pacotes de protocolo OSPF durante o

procedimento de inundação.
• A ID do roteador desempenha um papel importante no OSPFv3 e agora é sempre usada para identificar roteadores
vizinhos. Anteriormente, eles eram identificados por um endereço IPv4 na transmissão, NBMA (Non-Broadcast
Multi-Access) e links ponto-a-multiponto. Cada ID de roteador (bem como a ID de área) é mantida como um valor
decimal pontuado de 32 bits e não pode ser configurada usando um endereço IPv6.

• O ID do roteador também continua a atuar ativamente como um desempatador no caso de a prioridade associada a cada

roteador habilitado para OSPFv3 ser igual. Nesses casos, o roteador designado (DR) é identificado como o roteador que

possui a ID de roteador mais alta. As mensagens de saudação enviadas conterão um ID de roteador definido como 0.0.0.0

se não houver um roteador designado. O mesmo princípio se aplica ao Roteador designado de backup, identificado pela

próxima ID de roteador mais alta. Uma prioridade de 0 definida em uma interface de roteador que participa do OSPFv3

considerará o roteador inelegível para participar das eleições de DR / BDR. A Prioridade do roteador é configurada apenas

para interfaces associadas a redes de broadcast e NBMA.

• O endereço multicast “AllDRouters” recebeu o valor FF02 :: 6, o equivalente ao endereço multicast

224.0.0.6 usado em OSPFv2 para IPv4. O roteador designado e o roteador designado de backup devem
estar preparados para receber pacotes destinados a este endereço.
• IPv6 se refere ao conceito de links para significar um meio entre nós através do qual a comunicação na camada
de link é facilitada. As interfaces, portanto, se conectam a links e várias sub-redes IPv6 podem ser associadas a
um único link, para permitir que dois nós se comuniquem diretamente em um único link, mesmo quando eles não
compartilham uma sub-rede IPv6 comum (prefixo IPv6). Como resultado, o OSPFv3 opera em uma base por link
em vez de por sub-rede IP como é encontrado no IPv4. O termo link, portanto, é usado para substituir os termos
rede e sub-rede que são entendidos no OSPFv2. As interfaces OSPF agora são entendidas para se conectar a
um link em vez de uma sub-rede IP. Essa mudança afeta o recebimento de pacotes de protocolo OSPF, o
conteúdo dos pacotes Hello e o conteúdo dos LSAs de rede.

• O impacto dos links pode ser compreendido a partir da capacidade OSPFv3 para agora suportar várias instâncias
do protocolo OSPF em um único link. Onde domínios de roteamento OSPF separados que desejam permanecer
separados, mas operam em um ou mais segmentos de rede física (links) que são comuns aos diferentes
domínios. O IPv4 exigia o isolamento dos domínios por meio de autenticação, o que não oferecia uma solução
prática para esse requisito de design.

• A operação por link também significa que o pacote Hello não contém mais nenhuma informação de endereço e, em vez
disso, agora inclui uma ID de interface que o roteador de origem atribui para identificar exclusivamente (entre suas
próprias interfaces) sua interface para o link.
• A autenticação no OSPFv3 não é mais suportada e, como tal, o tipo de autenticação e os campos de autenticação
(valor) do cabeçalho do pacote OSPF não existem mais. A partir do IPv6, as alterações no cabeçalho IP permitiram
a utilização de protocolos de segurança que estavam presentes apenas no IPv4 como parte do pacote IPsec, uma
vez que o desenvolvimento inicial do TCP / IP no final dos anos 1960 nunca foi projetado com a segurança em
mente, pois a segurança de TCP / IP na época não estava previsto como um requisito futuro.

• Com as melhorias de segurança feitas no IPv6 e a utilização de cabeçalhos de extensão IP no conjunto de

protocolos, o OSPFv3 é capaz de contar com o cabeçalho de autenticação IP e a carga útil de segurança de
encapsulamento de IP para garantir integridade, bem como autenticação e confidencialidade, durante a troca de
OSPFv3 informações de roteamento.
• A implementação do OSPFv3 entre pares requer, como com o RIPng, que o roteador seja capaz de oferecer
suporte ao IPv6. Além disso, o roteador também deve habilitar o protocolo OSPFv3 globalmente na visualização
do sistema. Cada interface deve receber um endereço IPv6. Durante a configuração do RIPng foi demonstrado
como a interface pode ser configurada automaticamente para atribuir um endereço local de link. Neste exemplo,
é demonstrado um método alternativo e recomendado de atribuição de endereço local de link. O endereço IPv6
local do link é atribuído manualmente e designado como um endereço local do link usando o ipv6 <link local
address> link-local

comando. Se o endereço associado à interface física for um endereço unicast IPv6 global, a interface também
gerará automaticamente um endereço local de link.

• Para gerar uma rota OSPFv3, o exemplo demonstra a atribuição de endereços unicast globais à interface de
loopback lógica de cada roteador. As interfaces físicas e lógicas devem ser associadas ao processo OSPFv3 e
ser atribuídas a um ID de processo (normalmente a mesma ID, a menos que operem como instâncias
separadas de OSPFv3) e também ser atribuídas a uma área, que neste caso está limitada a área 0.

• Como um lembrete, os nós OSPFv3 dependem da identificação por roteadores vizinhos por meio do uso da ID
do roteador e, portanto, uma ID de roteador exclusiva deve ser atribuída para cada roteador na exibição do
protocolo OSPFv3 após a configuração do
ospfv3 comando.
• Seguindo a configuração dos roteadores vizinhos que participam do OSPFv3, o comando display ospfv3 é
usado para verificar a operação e os parâmetros associados ao OSPFv3. Cada roteador mostrará um processo
OSPFv3 em execução e uma ID de roteador exclusiva. Se a adjacência entre vizinhos for estabelecida, o
número de vizinhos FULL (estado) mostrará um valor maior que zero.
• Uma ID de roteador de 32 bits é usada para distinguir exclusivamente cada nó executando OSPFv3.
• O protocolo de configuração dinâmica de hosts para IPv6 (DHCPv6) é uma tecnologia que gerencia e configura
endereços IPv6 dinamicamente de maneira centralizada. Ele foi projetado para atribuir endereços IPv6 e outros
parâmetros de configuração de rede aos hosts. O DHCPv6 usa o modelo cliente / servidor. Um cliente solicita
configurações como o endereço IPv6 e o endereço do servidor DNS do servidor, o servidor responde com as
configurações solicitadas com base nas políticas.

• Na configuração automática de endereço sem estado (SLAAC), os roteadores não registram os endereços IPv6 dos hosts,

portanto, a configuração automática de endereço sem estado tem pouca capacidade de gerenciamento. Além disso, os hosts

configurados com autoconfiguração de endereço sem estado não podem obter outros parâmetros de configuração, como o

endereço do servidor DNS. Os ISPs não fornecem instruções para alocação automática de prefixos IPv6 para roteadores.

Portanto, os usuários precisam configurar manualmente os endereços IPv6 para dispositivos durante a implantação da rede

IPv6.

• Como um protocolo com monitoração de estado para configurar endereços IPv6 automaticamente, o DHCPv6 resolve esse

problema. Durante a configuração do endereço com monitoração de estado, o servidor DHCPv6 atribui um endereço IPv6

completo a um host e fornece outra configuração. Parâmetros como endereço do servidor DNS e nome de domínio. Um agente

de retransmissão pode ser usado para encaminhar pacotes DHCPv6, no entanto, está fora do escopo deste material. O

servidor DHCPv6 liga o endereço IPv6 a um cliente, melhorando a capacidade de gerenciamento geral da rede.

• Clientes e servidores trocam mensagens DHCP usando UDP. O cliente usa um endereço local de link,
determinado por outros mecanismos para transmitir e receber mensagens DHCP. Os clientes escutam as
mensagens DHCP na porta UDP 546, enquanto os servidores (e agentes de retransmissão) escutam as
mensagens DHCP na porta UDP 547.
• Antes da alocação de endereços, deve ser claramente entendido que um nó IPv6 (cliente) é necessário para
gerar um endereço local de link e ser avaliado com sucesso pelo processo de Detecção de Endereço Duplicado
(DAD). Em seguida, um processo de descoberta de roteador de link é envolvido, para o qual o nó cliente IPv6
transmite uma mensagem de solicitação de roteador (RS) e o roteador de link responde com uma mensagem de
anúncio de roteador (RA) após receber a mensagem RS.

• Contidos na mensagem RA estão vários campos contendo parâmetros de configuração para a rede local. Um
campo em particular referido como campo Autoconfig Flags, é um campo de 8 bits que contém dois valores de bits
específicos para determinar o processo de configuração automática para a rede local. Um “sinalizador de
configuração de endereço gerenciado” (M) é um valor de 1 bit que define se a configuração de endereço com
informações de estado deve ser usada, normalmente aplicada na presença de um servidor DHCPv6 na rede local.
Onde o valor é definido como 1, o endereçamento stateful deve ser implementado, o que significa que o cliente
IPv6 deve obter o endereçamento IPv6 por meio do DHCPv6 stateful.

• O outro sinalizador de configuração com estado (O) representa o segundo valor de bit de sinalizador no campo Sinalizadores
de Autoconfig e define se outros parâmetros de configuração de rede, como DNS e SNTP (para servidores de gerenciamento
de tempo) devem ser determinados por meio de DHCPv6 com estado. O RFC2462 define que onde o bit M é verdadeiro (um
valor de 1), o bit O também deve ser implicitamente verdadeiro, no entanto, na prática, o bit M e o bit O podem ser definidos
de forma intercambiável para suportar serviços de endereçamento sem estado em DHCPv6, em que um O endereço IPv6
não foi atribuído, mas os parâmetros de configuração, sim.

• Também deve ser observado que o sinalizador de endereço gerenciado e outro sinalizador de configuração
são gerenciados por meio de VRP no roteador e não são definidos na mensagem RA por padrão. Para definir
esses sinalizadores, os comandos ipv6 nd autoconfig managedaddress-flag e ipv6 nd autoconfig other-flag
devem ser configurados no gateway responsável por gerar mensagens RA.
• Os nós clientes iniciados em uma rede com suporte a endereçamento com estado podem ser atendidos por um ou
mais servidores DHCPv6. O cliente IPv6 usa um endereço local de link atribuído à interface para a qual está
solicitando informações de configuração como o endereço de origem no cabeçalho do datagrama IPv6.

• O endereço multicast FF02 :: 1: 2 é um endereço multicast reservado que representa

“All_DHCP_Relay_Agents_and_Servers”, e é usado por um cliente para se comunicar com servidores vizinhos. Todos

os servidores (e agentes de retransmissão) são membros desse grupo multicast. Para qualquer cliente enviando uma

mensagem DHCP para o

Endereço All_DHCP_Relay_Agents_and_Servers, espera-se que o cliente envie a mensagem através da

interface para a qual as informações de configuração estão sendo solicitadas, porém podem ocorrer exceções a
esta regra onde duas interfaces no cliente estão associadas ao mesmo link, para o qual é possível que interface
alternativa a ser usada. Em ambos os casos, o endereço local do link da interface de encaminhamento deve ser
usado como o endereço de origem.
• A obtenção de endereçamento com informações de estado e outros parâmetros de um servidor DHCPv6 requer o envio de uma série

de mensagens. Um cliente inicialmente envia uma mensagem de solicitação para localizar servidores, dos quais os parâmetros de

endereçamento e configuração podem ser recebidos.

• Seguindo a mensagem de solicitação, um servidor DHCPv6 suportando o link irá gerar uma mensagem de
propaganda em resposta à mensagem de solicitação, que indica ao cliente o endereço IPv6 do servidor,
fornecendo o serviço DHCPv6 necessário. O cliente é então capaz de usar este endereço IPv6 para fazer
referência ao servidor DHCPv6 e gerar uma mensagem de solicitação. Quando vários servidores respondem à
mensagem de solicitação, o cliente precisa decidir qual servidor DHCPv6 deve ser usado, normalmente definido
por um valor de preferência de servidor definido pelo administrador do DHCPv6 no servidor, e transportado na
mensagem de anúncio. Além disso, o servidor pode transportar opções, incluindo uma opção unicast do servidor
que permite ao cliente usar o endereço IPv6 do servidor DHCPv6 para transmitir correspondência posterior com
este servidor como mensagens unicast.

• A mensagem de solicitação é transmitida ao servidor DHCP selecionado para solicitar parâmetros de

configuração e um ou vários endereços IPv6 a serem atribuídos. Finalmente, o servidor DHCPv6 responde
com uma mensagem de resposta que contém os endereços confirmados e os parâmetros de configuração
da rede.
• O DHCP também pode ser empregado para oferecer suporte à configuração sem estado no caso de um host ser capaz

de recuperar informações de endereçamento IPv6 por meio de configuração sem estado e exigir apenas parâmetros de

configuração específicos do servidor DHCPv6. Em tais eventos, mensagens de solicitação de informações são geradas

e enviadas por clientes a um servidor para solicitar parâmetros de configuração. O cliente é capaz de obter informações

de configuração, como endereços de servidor e informações de domínio, como uma lista de parâmetros de configuração

disponíveis, usando apenas uma única mensagem e resposta que é trocada com um servidor DHCP.

• A mensagem de solicitação de informação é enviada para o

Endereço multicast “All_DHCP_Relay_Agents_and_Servers” após o qual os servidores respondem com uma

mensagem de resposta contendo as informações de configuração para o cliente. Visto que nenhum estado dinâmico
está sendo mantido (ou seja, na forma de atribuição de endereço IPv6), a alocação de informações de configuração
é considerada sem estado.
• Um DHCP Unique Identifier (DUID) é um valor que é usado para distinguir entre cada cliente e servidor DHCP, para o
qual apenas um DUID está presente em cada caso. Os clientes podem ter uma ou várias interfaces para as quais
cada uma receberá um endereço IPv6 junto com outros parâmetros de configuração e é referenciada usando um
Identificador de Associação de Identidade (IAID). Eles são usados junto com o DUID para permitir que os servidores
DHCPv6 referenciem um cliente e o endereço da interface / parâmetros de configuração que devem ser atribuídos.

• No caso de cada cliente, o DUID será utilizado para identificar um servidor DHCP específico com o qual um cliente

deseja se comunicar. O comprimento do valor DUID pode variar de qualquer lugar na faixa de 96 bits (12 bytes) a 160

bits (20 bytes), dependendo do formato que é usado. Existem três desses formatos, usando o endereço da camada de

link (DUID-LL), uma combinação do endereço da camada de link e o número da empresa (DUID-EN), um valor

atribuído pelo fornecedor no ponto de fabricação do dispositivo ou uma combinação de o endereço da camada de

enlace e um valor de carimbo de data / hora (DUID-LLT) gerado no ponto de criação do DUID em segundos a partir da

meia-noite de 1º de janeiro de 2000 (GMT), módulo 232.

• Os valores iniciais de 16 bits (00:01) representam o formato usado, onde “00:01” denota o formato DUID-LLT,
“00:02” o formato DUID-EN e “00:03” o formato DUID-LL. No caso dos formatos DUID-LL e DUID-LLT, os 16 bits
imediatamente após representam o endereço de hardware com base nas atribuições de parâmetro de tipo de
hardware IANA, com 00:01 representando Ethernet (10 Mb) e 00:06 definindo os padrões de rede IEEE 802. Um
registro de data e hora segue no formato DUID-LLT e, finalmente, o valor do endereço da camada de link. Para
DUID-LL, segue-se apenas o endereço da camada de enlace.
• O formato DUID pode ser atribuído por meio do comando dhcpv6 duid, para o qual o formato DUID-LL ou
DUID-LLT pode ser aplicado. O formato DUID-LL é aplicado por padrão. Para o DUID-LLT, o valor do carimbo
de data / hora fará referência à hora a partir do ponto em que o comando dhcpv6 duid llt é aplicado. O comando
display dhcpv6 duid pode ser usado para verificar o formato atual com base principalmente no comprimento do
valor DUID, bem como no próprio valor DUID.
• A implementação do endereçamento stateful requer que um pool de endereços seja definido com um prefixo de
endereço típico definido para o intervalo fornecido, bem como parâmetros específicos do pool. O exemplo
demonstra como um pool é criado com a definição de um pool e o nome do pool associado, bem como o
prefixo do endereço a partir do qual o intervalo de endereços de host será alocado.

• Os endereços excluídos referem-se aos endereços que fazem parte do intervalo do pool, mas não devem ser
alocados por meio de DHCP, pois são comumente usados para outros aplicativos, como o endereço de
interface do servidor DHCP. Parâmetros de configuração adicionais também serão especificados para um
determinado pool com exemplos, como endereços de servidor e nomes de domínio especificados para alocação
de parâmetros a clientes DHCPv6.
• Um pool DHCPv6 criado deve ser associado a uma interface por meio da qual atenderá clientes DHCP. Um
endereço IPv6 é atribuído à interface do servidor DHCPv6 e a interface então associada ao pool de endereços.
Neste caso, o valor do endereço excluído foi usado para representar o endereço da interface para garantir que
nenhuma tentativa seja feita pelo servidor DHCPv6 para atribuir o endereço da interface a um cliente DHCP.
• A configuração resultante do servidor DHCPv6 pode ser esclarecida por meio do comando display dhcpv6 pool, a
partir do qual o (s) pool (s) definido (s) podem ser identificados e o prefixo de endereço associado ao pool
determinado. Informações adicionais, como o tempo de vida, podem ser visualizados, para os quais o tempo de
vida padrão de um endereço alugado é 86400 segundos ou 1 dia e podem ser reconfigurados conforme necessário
usando o comando information-refresh na visualização dhcpv6 pool <pool-name>. Onde clientes ativos alugaram
endereços do servidor DHCP, as estatísticas relacionadas podem ser encontradas aqui.
• O roteador da série AR2200 é capaz de suportar os formatos Link Layer (DUID-LL) e Link Layer with Time
(DUID-LLT).

• Quando um anúncio de roteador é recebido contendo valores de bits M e O definidos como 1, o cliente
realizará a descoberta de um servidor DHCPv6 para configuração de endereço com estado. A configuração
incluirá um endereço IPv6 e também outras informações de configuração, como prefixos e endereços de
servidores que fornecem serviços, como DNS.
• No encaminhamento de IP tradicional, a camada física recebe um pacote de uma porta no roteador e o envia para a camada

de enlace de dados.

• A camada de enlace remove o encapsulamento da camada de enlace e, em seguida, envia para a camada de rede correspondente,

de acordo com o campo de protocolo do pacote.

• A camada de rede verificará se o pacote foi enviado para este dispositivo; se for, removerá o encapsulamento da camada de

rede e enviará para seu protocolo de nível superior. Caso contrário, ele irá consultar a tabela de roteamento de acordo com o

endereço IP de destino do pacote, se a rota for casada, o pacote será enviado para a camada de enlace de dados da porta

correspondente, após encapsulado pela camada de enlace de dados será transmitido. Se não houver correspondência, o

pacote será descartado.

• O encaminhamento de IP tradicional adota o encaminhamento de salto a salto, cada roteador pelo qual o pacote

passou deve implementar o processo (como mostra a figura, o RTA recebe um pacote de dados cujo endereço IP

de destino é 10.2.0.1, o RTA procura a tabela de roteamento e encaminha de acordo com para o item de rota

correspondente, RTB, RTC, RTD também farão assim), então a eficiência é baixa. E todos os roteadores precisam

conhecer todas as rotas em toda a rede ou rota padrão.

• Além disso, o encaminhamento de IP tradicional é orientado sem conexão, por isso é difícil implantar Qos.
• MPLS é um tipo de tecnologia de encaminhamento de rótulo, adota plano de controle sem conexão e plano de dados

orientado para conexão, plano de controle sem conexão implementa transmissão de roteamento e distribuição de rótulo, plano

de dados orientado para conexão implementa transmissão de pacotes ao longo do LSP (caminho de comutação de rótulo)

estabelecido anteriormente.

• No domínio da rede MPLS, o roteador não precisa analisar o endereço IP de destino de cada pacote, apenas encaminha

pelo rótulo adicionado antes do cabeçalho IP (como o figurador mostra que o RTB recebe o pacote rotulado do RTA, depois

encaminha pelo rótulo, o RTC é semelhante). Em comparação com o encaminhamento de IP tradicional, o

encaminhamento de rótulo MPLS melhora muito a eficiência do encaminhamento.

• No entanto, com o desenvolvimento da tecnologia ASIC, a velocidade de pesquisa de roteamento não é mais o

gargalo do desenvolvimento de rede. Melhorar a velocidade de encaminhamento não é mais a vantagem óbvia do

MPLS.

• MPLS integra a vantagem das duas tecnologias de encaminhamento, poderosa função de roteamento da camada 3 da

rede IP e mecanismo de encaminhamento de alta eficiência da rede tradicional da camada 2, seu plano de

encaminhamento adota a conexão orientada, é muito semelhante ao método de encaminhamento da rede da camada 2

existente.

• It makes MPLS easy to implement seamless combination of IP and ATM, frame relay and other layer 2
network, and provide better solution for TE (Traffic Engineering), VPN (Virtual Private Network), QoS
(Quality of Service) and other applications.

• VPN based on MPLS can combine different embranchment of private network, form a uniform network, VPN
based on MPLS also supports communication control between different VPN. As the figure shows, CE is user
edge device; PE is service provider edge router, which is located in backbone network. P is backbone router in
the service provider network, it does not directly connect with CE. VPN data is transmitted along LSP (label
switch path) encapsulated with MPLS label.
• MPLS TE integra tecnologia MPLS e TE, reserva recursos através do estabelecimento de encapsulamento LSP em

direção ao caminho designado, torna o tráfego desviando do nó de congestionamento, atinge o objetivo de equilibrar

o tráfego da rede.

• Como mostrado na figura, 70% do tráfego da Rede A para a Rede B é transmitido pelo caminho do
RTB-RTC-RTD, 30% do tráfego é transmitido pelo caminho do RTB-RTG-RTHRTD.

• O tráfego da Rede B para a Rede C é semelhante.

• A estrutura típica da rede MPLS é mostrada neste slide: o roteador e o switch ATM localizados dentro do
domínio MPLS são chamados de LSR, o roteador e o switch ATM localizados na borda do domínio MPLS que
costumavam conectar a rede IP ou outros tipos de rede são chamados LER.

• Na rede IP, ele implementa o encaminhamento de IP tradicional; no domínio MPLS, ele implementa o

encaminhamento de rótulos.

• Tanto o LER quanto o LSR têm a capacidade de encaminhamento de etiqueta, mas eles estão localizados em

posições diferentes, o processamento do pacote é diferente. A cobrança do LER é receber o pacote IP da rede IP e

inserir o rótulo no pacote e então transmiti-lo ao LSR, enquanto sua cobrança também é receber o pacote marcado do

LSR e remover o rótulo, transmiti-lo à rede IP; A cobrança do LSR é para encaminhar de acordo com o rótulo.

• O caminho pelo qual o pacote passa no domínio MPLS é denominado Label Switch Path (LSP), esse caminho já
foi confirmado e estabelecido por tipos de protocolos antes do encaminhamento do pacote, o pacote será
transmitido ao longo do LSP especificado.
• A rede MPLS encaminha o pacote de acordo com o rótulo. Mas como o rótulo é gerado? Qual mecanismo o
MPLS adota para implementar o encaminhamento de dados?

• MPLS inclui dois planos: plano de controle e plano de dados.

• A carga do avião de controle é gerar e manter informações de roteamento e informações de rótulo. A carga do plano de

dados é o encaminhamento de pacotes IP convencional e encaminhamento de pacotes rotulados. No plano de controle,

o módulo de protocolo de roteamento é usado para transmitir informações de roteamento, gerar tabela de roteamento;

O protocolo de distribuição de rótulo é usado para concluir a troca de rótulo e estabelecer o caminho de troca de rótulo.

• O plano de dados inclui tabela de encaminhamento de IP e tabela de encaminhamento de rótulo, ao receber pacotes IP

convencionais, se for encaminhamento de IP convencional, deve-se consultar a tabela de roteamento e encaminhar, se for

encaminhamento de rótulo, deve encaminhar pela tabela de encaminhamento de rótulo; ao receber pacotes etiquetados,

se precisar encaminhar por etiqueta, deverá encaminhar por tabela de encaminhamento de etiqueta; se precisar transmitir

para rede IP, deverá remover etiqueta e encaminhar por tabela de roteamento IP.
• Os rótulos MPLS são usados para transmitir informações MPLS. Os roteadores trocam rótulos para transmitir dados nos

caminhos de encaminhamento de rótulos estabelecidos.

• O comprimento do cabeçalho MPLS é de 32 bits, inclui campo de rótulo de 20 bits, este campo é usado para

encaminhamento de dados; EXP de 3 bits é usado para transportar a precedência do pacote IP; S de 1 bit está na parte

inferior da pilha e é usado para indicar se é o último rótulo (o rótulo MPLS pode ser aninhamento múltiplo); TTL de 8 bits, sua

função é semelhante ao TTL do cabeçalho IP, é usado para evitar o loop de dados.
• O protocolo PID arquivado no cabeçalho da camada 2 especifica que a carga útil começa com o pacote com rótulo
encapsulado ou cabeçalho IP. Por exemplo, no protocolo Ethernet, PID = 0x8847 identifica que a carga útil do
quadro é um pacote MPLS multicast. PID = 0x8848 identifica que a carga útil do quadro é um pacote MPLS
unicast. PID = 0x0800 identifica que a carga útil do quadro é um pacote IP unicast. No protocolo PPP, PID =
0x8281 identifica que a carga útil do quadro é um pacote MPLS unicast. PID = 0x8283 identifica que a carga útil do
quadro é um pacote MPLS multicast.

• O bit S no cabeçalho MPLS indica se o próximo cabeçalho é outro rótulo ou um cabeçalho IP da camada 3.

• Normalmente, o MPLS aloca apenas um rótulo para um pacote. Mas alguns aplicativos avançados de MPLS usam

vários rótulos. Por exemplo, MPLS VPN usará 2 camadas de rótulos (em situações complexas, ele até usa 3 camadas

de rótulos), o rótulo externo é usado para encaminhamento de rede pública, o rótulo interno é usado para indicar a

qual VPN o pacote pertence; MPLS TE também usa dois ou mais rótulos, o rótulo mais externo é usado para indicar o

tunelamento TE, o rótulo interno indica o destino do pacote.

• Nota: O Label1, Label2, Label3 significam todos os cabeçalhos MPLS de 4 bytes no último slide, incluindo informações de

rótulo de 20 bits.
• FEC (classe de equivalência de encaminhamento) significa um grupo de pacotes IP que são encaminhados no
método da equipolência, por exemplo, um grupo de pacotes IP com o mesmo prefixo IP de destino será atribuído a
um rótulo único. Neste caso, o pacote cujo prefixo IP de destino é 10.2.0.0/24 pertence a um FEC, o rótulo alocado
para este FEC é 1030.

• NHLFE é usado ao encaminhar um pacote rotulado, ele contém as seguintes informações:

• 1. o próximo salto do pacote;

• 2. a operação a realizar na pilha de etiquetas do pacote (contém empurrar uma nova etiqueta, estourar
etiqueta, substituir a etiqueta original por uma nova etiqueta). Ele também pode conter outras informações,
como o encapsulamento do link de dados a ser usado ao transmitir o pacote. Nesse caso, o próximo salto é
10.1.1.2, a operação de rótulo é “push”.
• FEC representa o mesmo tipo de pacote, NHLFE contém próximo salto, operação de etiqueta e outras informações.

Apenas associando FEC com NHLFE, pode implementar encaminhamento de rótulo particular para o mesmo tipo de

pacotes, FTN pode implementar esta função, FTN (FEC-para-NHLFE) indica o mapeamento de um FEC para NHLFE,

se houver vários caminhos de custo igual, um FEC pode ser mapeado para vários NHLFE.

• Quando um pacote IP entra no domínio MPLS, o ingresso LER (RTA) analisa o pacote, determina qual rótulo
encapsular o pacote de acordo com a característica do pacote (geralmente por análise de prefixo do endereço
IP de destino) e determina a transmissão para qual próximo salto de qual interface.

• No ingresso, a tabela NHLFE é consultada para orientar o encaminhamento de pacotes.

• No nó de trânsito, o LSR (RTB) recebe a mensagem com a etiqueta MPLS 1030 do RTA e a encaminha de acordo com a

etiqueta MPLS. Ele encontrará o próximo salto 10.1.1.6, usará o rótulo de saída para trocar o rótulo de entrada e, a

seguir, continuará o encaminhamento. (este caso é especial, etiqueta de saída e etiqueta de entrada são iguais).

• O ILM mapeia cada etiqueta de entrada para um conjunto de NHLFE, é usado ao encaminhar pacotes que chegam

como pacotes etiquetados. Se houver vários caminhos de custo igual, um rótulo de entrada mapeia para vários NHLFE.
• Semelhante ao RTB, quando o RTC recebe a mensagem com o rótulo 1030, ele encaminha pacote por rótulo e usa o

novo rótulo de saída para trocar o rótulo original.

• Nesse caso, o RTC usa o rótulo de saída 1032 para trocar o rótulo de entrada e, a seguir, transmite o pacote da

interface de saída Serial3, o próximo salto é 10.1.1.10.

• O LSR de saída （RTD） recebe a mensagem com rótulo 1032, exibe o rótulo, pesquisa a tabela de roteamento IP e a

encaminha.

• Nesse caso, o RTD exibe o rótulo 1032 e encaminha a mensagem para o próximo salto

10.2.0.2.
• Responda:

• 1: C

• 2: ABC
• LDP (Label Distribute Protocol): O protocolo de distribuição de rótulos aloca rótulos com base nos endereços de destino e

usa o encaminhamento de rótulos em vez de encaminhamento de IP. A vantagem do LDP: ele isola as rotas da rede

pública, seleciona os caminhos de encaminhamento com base nas rotas ideais e oferece suporte ao ECMP. E a

configuração é simples.

• Diferentes tipos de serviços, como voz, dados, vídeo e RV, têm diferentes requisitos na rede. Os requisitos de
largura de banda estão aumentando e a escala da rede está aumentando explosivamente. A tecnologia MPLS
tradicional requer um protocolo de distribuição de etiqueta dedicado. Os rótulos precisam ser alocados para cada
LSP, que ocupa uma grande quantidade de recursos. Os pacotes de protocolo de manutenção de status ocupam
uma grande quantidade de largura de banda. Ele precisa ser sincronizado com o protocolo IGP. A implantação e
manutenção são complexas e a escalabilidade é ruim. Este modo de operação de rede não pode atender aos
requisitos dos provedores de serviço para implementar rapidamente serviços de rede sob demanda. Além disso, o
OPEX (Despesa Operacional) aumenta linearmente com a escala.
• LDP depende da tabela de roteamento IGP para calcular LSPs,
• RSVP: protocolo de reserva de recursos. O RSVP-TE é apresentado para resolver o problema de que a rede IP

tradicional pode encaminhar apenas o caminho ideal e o caminho não pode ser planejado. RSVP-TE traz muitos

benefícios, como planejamento de caminho explícito, reserva de recursos de largura de banda e múltiplos esquemas

de proteção.

• O RSVP depende do IGP para manter seu vizinho e o status do link, complica o plano de controle e complica a
manutenção da rede e a localização da falha.

• O RSVP-TE precisa estabelecer vários túneis para implementar a função ECMP.

• Na manutenção do status do LSP, PATH e RESV precisam ser atualizados continuamente. Após o aumento
dos serviços, ocorrem problemas de desempenho no ponto intermediário (serviços são sobrepostos. Além
disso, a quantidade de configuração do túnel RSVP-TE é sempre criticada pela operadora. Em média, oito
túneis precisam ser configurados para cada túnel.
• C: Controle

• F: Encaminhamento

• SDN (Rede Definida por Software) é uma nova arquitetura de inovação de rede proposta pelo Stanford
University Clean Slate Research Group. A tecnologia principal separa o plano de controle do plano de dados
para implementar o controle flexível do tráfego de rede e fornecer uma boa plataforma para a inovação de
redes e aplicativos principais.

• A revolucionária rede SDN usa uma arquitetura de controle centralizado. As funções de controle (como cálculo de
rota) dos dispositivos de rede são centralizadas em um controlador, e a tabela de encaminhamento é gerada e
entregue pelo controlador ao dispositivo. As funções do dispositivo são simplificadas e são responsáveis apenas
pelo encaminhamento. OpenFlow é uma interface de controle entre o Controlador e os dispositivos.

• A rede SDN incremental expande a rede existente. Os dispositivos existentes evoluem para o SDN. Algumas
funções de controle são reservadas no dispositivo. Algumas funções que requerem controle centralizado são
processadas no controlador, o que enfatiza a capacidade de evolução suave do dispositivo.
• O Segmento de Prefixo indica o endereço de destino e o Segmento de Adjacência indica o link de saída do
pacote de dados, que pode ser semelhante ao endereço IP de destino e à interface de saída no
encaminhamento de IP tradicional. Em uma área IGP, o dispositivo de elemento de rede inunda o SID do Nó e o
SID de Adjacência do dispositivo de elemento de rede usando uma mensagem IGP estendida, de modo que
qualquer elemento de rede possa obter informações de outro elemento de rede. Qualquer caminho na rede pode
ser construído combinando o prefixo (nó) SID e SID adjacente em sequência. Em cada salto do caminho, o
próximo salto é distinguido pelo uso das informações do segmento superior da pilha. As informações do
segmento são empilhadas no topo do cabeçote de dados em sequência. Quando as informações do segmento
superior da pilha incluem o identificador de outro nó, o nó receptor usa o multipath equivalente (ECMP) para
encaminhar o pacote de dados para o próximo salto. Quando a informação do segmento superior da pilha é o
identificador do nó atual, o nó receptor exibe o segmento superior e executa a tarefa exigida pelo próximo
segmento.

• Em aplicativos reais, o Segmento de Adjacência, o Segmento de Prefixo e o Segmento de Nó podem ser usados

independentemente ou juntos.

• Existem três cenários: Segmento de Prefixo, Segmento de Adjacência, Segmento de Adjacência +

Segmento de Nó
• O roteamento de segmento encapsula a sequência de segmento que representa o caminho de encaminhamento em
um cabeçalho de pacote de dados e transmite o pacote com o pacote de dados. Depois de receber o pacote de
dados, o nó da rede analisa a sequência do segmento. Se o identificador de segmento superior da sequência do
segmento for Node SID, o nó da rede encaminha a sequência do segmento para o nó de acordo com o caminho mais
curto calculado pelo SPF (se houver um caminho equivalente, o ECMP pode ser implementado), e se o path é um
SID de Adjacência, encaminha a sequência do segmento para o próximo nó de acordo com o SID de Adjacência, o
pacote de dados chega ao nó de destino.
• Veja o LSP de PE1 a PE2 como exemplo.

• 1. O endereço de loopback da interface LoopBack1 no Egress PE2 é xxxx / x, o SID alocado para o endereço
é 10 e a informação é enviada para todo o domínio IS-IS.
2. Todos os nós recebem o Node SID do PE2 e geram uma tabela de encaminhamento de etiqueta.

• Etiqueta de entrada: valor inicial SRGB local + valor de deslocamento liberado

• Etiqueta de saída: valor inicial de SRGB do próximo salto + valor de deslocamento anunciado

• Próximo salto da interface de saída: Próximo salto da interface de saída do caminho mais curto calculado

pelo IGP
3. O Ingress PE1 executa o cálculo IS-IS SPF para obter os dois caminhos mais curtos do ECMP para o PE2.
• O tipo de operação de etiqueta do SR é o mesmo que o do MPLS, incluindo empilhamento de pilha de etiqueta, troca de pilha

de etiqueta e popping de etiqueta (Pop).

A figura a seguir usa o túnel SR-BE em PE1 a PE2 como exemplo.

1 PE1 no nó de ingresso: depois de receber um pacote de serviço, o encapsula o rótulo de saída alocado pelo

próximo salto P de acordo com o endereço de destino, tabela de encaminhamento de rótulo e algoritmo de

distribuição de tráfego ECMP e, em seguida, encaminha o pacote através da interface correspondente com base em

o prefixo de destino SID e a tabela de encaminhamento de rótulo.

Exemplo:

Empurre 210 para P1

Push 310 para P2

• 2. Nó de trânsito: De acordo com o rótulo externo e a tabela de encaminhamento de rótulo, o rótulo de

saída do SR é alocado para o próximo salto e o rótulo de saída é encaminhado por meio da interface

correspondente.

Exemplo:

Troque 210 para 410 em P1

Troque 310 por 510 em P2

• 3. Nó de saída PE2: Se o rótulo externo for ele mesmo, o rótulo externo é exibido e o pacote de serviço é

encaminhado ao CE de acordo com o endereço IP externo.

Exemplo:

Pop 610 de P3

Pop 610 de P4
1 Geração de rótulos, tabelas de encaminhamento de rótulos e informações de topologia

Cada nó na rede usa o protocolo IS-IS SR para alocar SIDs adjacentes aos seus
adjacências, inunda os IDs para toda a rede e gera entradas de encaminhamento de rótulo para os SIDs
adjacentes locais alocados aos nós. Além disso, as informações de topologia com as informações SID
adjacentes são geradas.

Além disso, o SRGB / prefixo SID / nó SID, capacidade SR e SR configurados manualmente

algoritmos são inundados no domínio IGP por meio de pacotes IGP. Cada nó executa ISIS SPF para calcular o caminho de
encaminhamento mais curto de cada etiqueta de nó e gera uma tabela de encaminhamento de etiqueta.

2. Relate as informações de rótulo e topologia.

Cada nó na rede relata as informações de topologia com o SID adjacente

informações ao controlador por meio do BGP Link-State (BGP-LS).

3. Cálculo do caminho

O controlador usa o Path Computation Element (PCEP) para calcular o rótulo

caminho de encaminhamento.

4. Entregue trilhas.

O controlador fornece informações de túnel através do PCEP e fornece túnel

atributos para o primeiro nó do túnel através do NETCONF. O primeiro nó do túnel relata o status do túnel ao
controlador por meio do PCEP.

5. Crie um túnel.

O primeiro nó do túnel estabelece um túnel SR-TE com base na pilha de rótulos

entregue pelo controlador.
1 Geração de rótulos, tabelas de encaminhamento de rótulos e informações de topologia

Cada nó na rede usa o protocolo IS-IS SR para alocar SIDs adjacentes aos seus
adjacências, inunda os IDs para toda a rede e gera entradas de encaminhamento de rótulo para os SIDs
adjacentes locais alocados aos nós. Além disso, as informações de topologia com as informações SID
adjacentes são geradas.

Além disso, o SRGB / prefixo SID / nó SID, capacidade SR e SR configurados manualmente

algoritmos são inundados no domínio IGP por meio de pacotes IGP. Cada nó executa ISIS SPF para calcular o caminho de
encaminhamento mais curto de cada etiqueta de nó e gera uma tabela de encaminhamento de etiqueta.

2. Relate as informações de rótulo e topologia.

Cada nó na rede relata as informações de topologia com o SID adjacente

informações ao controlador por meio do BGP Link-State (BGP-LS).

3. Cálculo do caminho

O controlador usa o Path Computation Element (PCEP) para calcular o rótulo

caminho de encaminhamento.

4. Entregue trilhas.

O controlador fornece informações de túnel através do PCEP e fornece túnel

atributos para o primeiro nó do túnel através do NETCONF. O primeiro nó do túnel relata o status do túnel ao
controlador por meio do PCEP.

5. Crie um túnel.

O primeiro nó do túnel estabelece um túnel SR-TE com base na pilha de rótulos

entregue pelo controlador.
• O nó SR executa uma operação de rótulo no pacote de acordo com a pilha de rótulo correspondente ao túnel
SR-TE no cabeçalho do pacote. Pesquisa a interface de saída salto a salto com base no rótulo superior da pilha
para instruir os pacotes de dados a serem encaminhados ao endereço de destino do túnel.

Pegue o caminho estrito SR-TE Tunnel de PE1 a PE2 como exemplo.

• 1. PE1 no nó de ingresso: Após receber o pacote de serviço, o encapsula a pilha de etiqueta correspondente ao

túnel SR-TE de acordo com o túnel SR-TE determinado pela política de roteamento ou política de túnel

configurada no serviço. Se for determinado que a etiqueta superior da pilha 501 correspondente é um SID

adjacente, a etiqueta superior da pilha 501 é exibida e a parte restante [103, 304, 406] da pilha de etiquetas é

encapsulada no pacote de serviço e é encaminhada fora da interface PE1-> P1 correspondente de acordo com

a etiqueta superior e a tabela de encaminhamento de etiqueta.

• 2. Nó de trânsito: Se a etiqueta do topo da pilha for o SID adjacente, a etiqueta do topo da pilha será exibida e a etiqueta

do topo da pilha e a tabela de encaminhamento de etiqueta serão encaminhadas através da interface correspondente.

Tome P1 como um exemplo: Se for determinado que a etiqueta do topo da pilha 103 é um SID adjacente, a etiqueta do topo

da pilha 103 é exibida e a etiqueta do topo da pilha 103 é encaminhada de acordo com a etiqueta do topo 103 e a mesa

de encaminhamento de etiqueta de a interface correspondente P1-> P3.

• 3. Nó de saída PE2: O encaminha os pacotes de serviço ao CE de acordo com o endereço IP externo dos
pacotes de serviço.
O SR realiza uma operação de etiqueta no pacote de acordo com a pilha de etiqueta

correspondente ao túnel SR-TE no cabeçalho do pacote. Pesquisa a interface de saída salto a salto com base

no rótulo superior da pilha para instruir os pacotes de dados a serem encaminhados ao endereço de destino do

túnel.

Pegue o caminho livre SR-TE Tunnel de PE1 a PE2 como exemplo.

• 1. PE1 no nó de ingresso: Depois de receber o pacote de serviço, o encapsula a pilha de rótulo [1004, 403, 306]

correspondente ao túnel SR-TE de acordo com o túnel SR-TE determinado pela política de roteamento ou política

de túnel configurada em o serviço. Encapsulando a etiqueta de saída SR 1004 alocada pelo nó P do próximo salto

de acordo com a etiqueta externa e a tabela de encaminhamento de etiqueta, e encaminhando a etiqueta de saída

SR 1004 de acordo com a tabela de encaminhamento de etiqueta.

2 、 Nó de trânsito P2: De acordo com a etiqueta externa 1004 e a tabela de encaminhamento de etiqueta, a etiqueta extern
a é comutada para a etiqueta de saída 1004 alocada para o próximo salto e é encaminhada através da interface
correspondente P2-> P4.
3 、 Nó de trânsito P4: A etiqueta externa 1004 é considerada ela mesma, e a etiqueta externa 1004 é removida. D
eterminar que o próximo rótulo de camada 403 é o SID adjacente, abrir o rótulo 403 e encaminhar a tabela de
encaminhamento de rótulo da interface P4-> P3 correspondente de acordo com a tabela de encaminhamento de
rótulo.
4. Nó de trânsito P3: Julgando que a etiqueta externa 306 é a etiqueta de adjacência, destaca a etiqueta externa 306 e
encaminha a etiqueta externa 306 da interface correspondente P3-> PE2 de acordo com a tabela de encaminhamento
de etiqueta.
5. Nó de saída PE2: O encaminha os pacotes de serviço para o CE de acordo com o endereço IP externo dos
pacotes de serviço.
• Responda

• 1: ABD

• 2: ABC
 Recomendações

• Site de aprendizagem da Huawei

• http://learning.huawei.com/en

• Huawei e-Learning

• https://ilearningx.huawei.com/portal/#/portal/EBG/51

• Certificação Huawei

• http://support.huawei.com/learning/NavigationAction!createNavi?navId=_31 & lang = en

• Encontre treinamento

• http://support.huawei.com/learning/NavigationAction!createNavi?navId=_trai ningsearch & lang =

en

Mais Informações

• APP de aprendizagem Huawei

版权所有 © 201 9 华为 技术 有限公司