Comware 5

Comware: Alterando a distância administrativa para as rotas estáticas para Switches e Roteadores

Diego DiasLeave a comment

Eu já escrevi alguns post sobre a atenção que deve ser dada para a integração entre Switches e Roteadores baseados no Cowmare quando há a necessidade de compartilhar o roteamento dinâmico.

Como no exemplo abaixo, podemos ver que por padrão, toda rota estática é atribuída com o valor 60 para a distância administrativa. De forma didática, faço a comparação nas duas saídas do comando “display ip routing-table” da escolha da tabela de Roteamento pela rota aprendida com a menor distância adminstrativa (no primeiro quadro via rota estática e no segundo exemplo via OSPF).

[Switch] ip route-static 192.168.10.0 255.255.255.0 192.168.12.2
[Switch]
[Switch] display ip routing-table
Routing Tables: Public
        Destinations : 5        Routes : 5

Destination/Mask    Proto  Pre  Cost         NextHop         Interface

127.0.0.0/8         Direct 0    0            127.0.0.1       InLoop0
127.0.0.1/32        Direct 0    0            127.0.0.1       InLoop0
192.168.10.0/24     Static 60   0            192.168.12.2    Eth0/0/0
192.168.12.0/30     Direct 0    0            192.168.12.1    Eth0/0/0
192.168.12.1/32     Direct 0    0            127.0.0.1       InLoop0

Com a rota aprendida dinâmicamente via OSPF (e a estática ainda configurada), percebam que o roteador insere apenas a rota com a menor distância administrativa (valor 10 para o OSPF).

[Switch]display ip routing-table
Routing Tables: Public
        Destinations : 5        Routes : 5

Destination/Mask    Proto  Pre  Cost         NextHop         Interface

127.0.0.0/8         Direct 0    0            127.0.0.1       InLoop0
127.0.0.1/32        Direct 0    0            127.0.0.1       InLoop0
192.168.10.0/24     OSPF   10   2            192.168.12.2    Eth0/0/0
192.168.12.0/30     Direct 0    0            192.168.12.1    Eth0/0/0
192.168.12.1/32     Direct 0    0            127.0.0.1       InLoop0

Apesar da rota aprendida dinâmicamente “tomar” o lugar da rota estática e possuir o mesmo next-hop (no caso 192.168.12.2, interface Eth0/0/0), em redes mais complexas, o roteamento poderia escolher um caminho menos desejado pelo administrador de rede, visto que em equipamentos de outros fabricantes as rotas estáticas são atribuídas com a distâncias administrativa 1 ( e isso pode passar desapercebido ).

O comando “ip route-static default-preference 1” ajuda aqueles que estão acostumados a trabalhar com ambos roteamento dinâmico e estático, permitindo que as novas rotas configuradas possuam a distância adminstrativa 1 (nesse caso, melhor que todos os protocolos de Roteamento Dinâmico).

[Switch] ip route-static default-preference 1

Caso você prefira escolher manualmente o peso que cada rota terá, basta adicionar o “preference” no final de cada rota.

[Switch] ip route-static 192.168.20.0 255.255.255.0 192.168.12.2  preference ?
  INTEGER  Preference value range

Abração

Comware: OSPF – Roteador Designado (DR) e Roteador Designado de Backup (BDR)

Diego DiasLeave a comment

Para o estabelecimento de uma adjacência no OSPF os Roteadores vizinhos devem se reconhecer para trocarem informações, encaminhando e recebendo mensagens Hello nas Interfaces participantes do OSPF; no endereço de Multicast 224.0.0.5.

Durante estabelecimento da Adjacência, serão trocadas informações dos Roteadores da Rede como a informação da área, prioridade dos Roteadores, etc. Após a sincronizarem as informações, os Roteadores da área terão a mesma visão da Topologia e rodarão o algoritmo SPF para escolha do melhor caminho para chegar ao Destino.

Os Roteadores (já) Adjacentes encaminharão mensagens Hellos ( verificação da disponibilidade), mensagens LSA com as atualizações da rede e mensagens a cada 30 minutos de refresh de cada LSA para certificar que os a tabela OSPF (LSDB) esteja sincronizada.

Durante a falha de um Link, a informação é inundada (flooded) para todos os Roteadores Adjacentes da Área. 

Em ambientes Multiacesso como redes Ethernet, os Roteadores OSPF elegem um Roteador Designado (DR) para formar Adjacência e encaminhar os LSA’s somente para ele. O Roteador DR reencaminha os updates recebidos por um vizinho para os outros Roteadores na mesma LAN.

Há também a eleição de um Roteador Desingnado de Backup (BDR) para assumir em caso de falha do DR.

O método de eleição do DR e BDR é bastante efetivo e confiável para estabelecimento de Adjacências e mensagens trocadas para manutenção do OSPF, economizando assim recursos conforme o crescimento da Topologia.

Quando ocorre uma mudança na topologia o Roteador/Switch encaminha uma mensagem em Multicast para o endereço 224.0.0.6 que é destinada a todos Roteadores OSPF DR/BDR.

Após o recebimento do Update, o Roteador DR confirma o recebimento (LSAck) e reencaminha a mensagem para os demais roteadores da rede no endereço de Multicast 224.0.0.5; após o recebimento da atualização todos os roteadores deverão confirmar a mensagem ao Roteador Designado (LSAck), tornando o processo confiável.

Se algum Roteador estiver conectado à outras redes, o processo de flood é repetido!

Obs: O BDR não efetua nenhuma operação enquanto o DR estiver ativo!

Como é feita a eleição do DR e BDR? 

Durante o processo de estabelecimento de Adjacência é verificado o campo Priority na troca de mensagens Hello. O Roteador com maior valor é eleito o DR e o Roteador com segundo maior valor é eleito o BDR ( em cada segmento).

O valor default da prioridade de todos os Roteador é 1, no caso de empate, é escolhido o valor do ID do Roteador para desempate. Vence quem tiver o maior valor!

Obs: Se a prioridade for configurada como 0, o dispositivo nunca será um DR ou BDR. Nesse caso ele será classificado com DROther ( não DR e não BDR) 

Configurando
O valor da prioridade deverá ser configurado na Interface VLAN ou física (Ethernet, GigabitEthernet, etc) dos Switches/Roteadores com o processo de OSPF ativo:

interface Vlan-interface1
ip address 192.168.0.26 255.255.255.0
ospf dr-priority 3
!Configurando a Prioridade para eleição do DR/BDR com o valor 3

Porém….

A prioridade do DR e do BDR não é preemptiva, isto é, para manter a estabilidade da topologia se um dispositivo for eleito como DR e BDR, o mesmo não perderá esse direito até ocorrer algum problema no link ou no dispositivo eleito.

Conforme comando display abaixo em Switches Comware, o Switch configurado com a prioridade 3 perde a eleição (de tornar-se o DR) para dispositivo com a prioridade 4 ( pelo fato de ser inserido na topologia posteriormente a eleição do DR/BR).

[COMWARE]display ospf peer
OSPF Process 100 with Router ID 192.168.0.5
Neighbor Brief Information

Area: 0.0.0.0
Router ID Address Pri Dead-Time Interface State

192.168.0.13 192.168.0.13 0 38 Vlan1 Full/DROther
192.168.0.14 192.168.0.14 1 31 Vlan1 Full/DROther
192.168.0.20 192.168.0.20 1 34 Vlan1 Full/DROther
192.168.0.21 192.168.0.21 4 30 Vlan1 Full/DR
!Roteador DR com a prioridade 4
192.168.0.26 192.168.0.26 5 31 Vlan1 Full/DROther
! Roteador DROther com a prioridade 5 só será o DR na falha do DR e BDR
192.168.0.33 192.168.0.33 1 32 Vlan1 Full/BDR
! Roteador BDR com a prioridade 1
192.168.0.45 192.168.0.45 1 40 Vlan1 Full/DROther

O Switch com a Prioridade 5, irá tornar-se DR somente após falha no DR e no BDR.

Referencias:

Building Scalable Cisco Internetworks – Diane Teare/Catherine Paquet

Duvidas? Deixe um comentário!

Um grande abraço

Resumo do Protocolo LLDP

Diego DiasLeave a comment

O protocolo LLDP(802.1AB) permite que dispositivos de rede como Servidores, Switches e Roteadores, descubram uns aos outros. Ele opera na camada de enlace do modelo OSI (camada 2)  permitindo que informações básicas como hostname, versão do Sistema Operacional , endereço da interface, entre outros, sejam aprendidas dinâmicamente por equipamentos diretamente conectados.

O mais bacana do Link Layer Discovery Protocol (LLDP)  é a integração entre equipamentos de diversos fabricantes; e para aqueles que já estudaram o material do CCNA da Cisco, a feature é identica ao Cisco Discover Protocol (CDP) – o protocolo proprietário da Cisco para descoberta de vizinhos.

A tirinha abaixo adaptada do site http://vincentbernat.github.com/lldpd/index.html  demonstra bem a utilização do LLDP (ou como ajudaria no caso abaixo.. rs )  O site possui instruções de instalação do protocolo para diversas plataformas.

Conceitos Básicos

Para redes Ethernet, o LLDP é encaminhado dentro do quadro Ethernet da seguinte maneira:

A mensagem encaminhada também é chamada de LLDPDU (Link Layer Discover Protocol Data Unit)

Endereço MAC de destino (Destination MAC address)
O endereço MAC de destino de um LLDPDU pode ser anunciado nos endereços Multicast  0180-C200-000E , 0180-C200-0003 ou 0180-C200-0000.

Endereço MAC de  origem (Source MAC address)
O endereço MAC de origem é o da porta que encaminha o LLDPDU, se a interface não tiver endereço MAC, será encaminhado o endereço reservado do Switch/Roteador

Type
O Ethernet type usado para o LLDP é o 0x88CC for LLDP.

Data
LLDP data unit (LLDPDU)

FCS
Frame check sequence é um valor de CRC de 32-bit CRC usado para determinar a validade do recebimento do quadro  Ethernet.

Os LLDPDUs

O LLDP usa os LLPDU’s para troca de informações. Dentro do LLDPDU há uma sequencia de campos TLV ( type [tipo], length [comprimento] e value [valor])

Um LLPDU pode carregar até 28 tipos de TLVs. Os itens obrigatóriso devem carregar:

  • TLV de identificação do Chassis
  • TLV de identificação da Porta
  • TTL TLV
  • TLV do fim do LLPDU
  • Outros campos são opcionais

A demonstração feita nos dá uma boa visão das informações carregadas pelo protocolo:

 saída do comando display lldp  neighbor-information brief  em um Switch HPN demonstra o estudo:

<Switch>display lldp  neighbor-information brief
LLDP neighbor-information of port 469[GigabitEthernet1/9/0/1]:
Neighbor 1:
ChassisID/subtype: 3822-d6b6-4c01/MAC address
PortID/subtype   : GigabitEthernet1/0/48/Interface name
Capabilities     : Bridge,Router

Para os campos Opcionais é possível obter informações como Hostname, descrição do tipo de equipamento, endereço de gerenciamento, informação sobre VLANs, etc.

LLDP-MED

A extensão do LLDP chamada de Media Endpoint Discovery extension (MED) é muito utilizada para Telefonia IP e provê as seguintes informações:

  • Provisionamento de informações de politicas para a rede local agir de forma plug-and-play (como VLAN, Prioridades na marcação de pacotes e quadros para fins de QoS)
  • Identificação do local do dispositivo
  • Funções para PoE
  • etc

Configuração básica do LLDP em Switches Comware

[Switch]lldp enable
! Ativando o LLDP globalmente

[Switch]interface Ethernet 1/0/1
[Switch-Ethernet1/0/1]lldp enable
! Ativando o LLDP na interface

Para ajuste de envio, recebimento ou desativar o LLDP em uma interface, existem as seguintes opções:

[Switch-Ethernet1/0/1]lldp  admin-status ?
disable  The port can neither transmit nor receive LLDP frames
rx       The port can only receive LLDP frames
tx       The port can only transmit LLDP frames
txrx     The port can both transmit and receive LLDP frames

Obs: Fique sempre atento as informações encaminhadas pelo LLDP em uma rede local, pois o protocolo habilita inumeras informações que tornam a rede “vulnerável”. Certifique-se que o ambiente é controlado e desabilite o LLDP (se possível) após a coleta de informações! 

Comware: Elegendo o Switch Root do Spanning-Tree

Diego DiasLeave a comment

O Protocolo Spanning-Tree ( STP) foi desenvolvido para evitar que loops físicos interfiram no desempenho da rede. O protocolo consegue detectar onde estão os loops na rede bloqueando os caminhos redundantes.

“Quando um Switch recebe um broadcast, ele o repete em cada porta (exceto naquela em que foi recebido). Em um ambiente com loop, os broadcasts podem ser repetidos infinitamente” Gary A. Donahue , Network Warrior, O’Reilly, 2007, p59)

Em caso de caminhos redundantes sem a utilização do Spanning-Tree, o processo de encaminhamento de broadcast só será interrompido quando o loop for desfeito, com a remoção de cabos ou o desligando o equipamento. Em diversas situações, uma tempestade de broadcast “derruba” a comunicação da rede.

O Switch Root

A utilização do STP é geralmente imperceptível na grande maioria das redes devido ao fato da convergência ocorrer sem a necessidade de configurações adicionais. Todo Switch da LAN , recebe informações sobre os outros Switches da rede através da troca de mensagens chamadas de BPDUs (Bridge Protocol Data Units).

Ao tirarmos um Switch da caixa ( preferencialmente gerenciável) e colocarmos em nossa rede, haverá a comunicação com todos os Switches da rede para convergência com o novo dispositivo.

A partir das mensagens trocadas pelos Switches, é efetuada uma eleição para escolha de um Switch Raiz (Root) que será o responsável por alimentar a topologia da Rede pela geração de BPDUs e todos os Switches não-Raiz bloquearão as portas com caminhos redundantes para o Raiz.

Os BPDUs são encaminhados pelo Root a cada 2 segundos em todas as portas para garantir a estabilidade da rede; e então os BPDUs re-encaminhados pelos outros Switches.

As mensagens BPDU contêm informações suficientes para que os Switches elejam quais portas encaminharão os dados, baseando-se em custo do caminho, informações do Switch e informações da porta.

Obs: a porta em estado de Bloqueio continuará a ouvir os BPDUs pois em caso de perda de comunicação do enlace principal, a porta bloqueada estará pronta para encaminhar os quadros! 

Elegendo o Switch Root

O primeiro processo para uma topologia livre de Loops utilizando o protocolo Spanning-Tree é a eleição do Switch Root. Vence a eleição o Switch quem possuir o menor Bridge ID.

O Bridge ID é composto dos campos Prioridade (Bridge Priority) e o endereço MAC do Switch. Por padrão a prioridade dos Switches é 32768 (o Switch com menor prioridade vence) e em caso de empate vence a eleição o Switch que possui o menor endereço MAC.

Após a eleição, se houver algum caminho redundante, o mesmo será bloqueado!

Escolhendo quem será o Root da rede

As melhores práticas sugerem configurarmos o Switch Core da rede como Root com o comando stp root primary pela posição privilegiada na rede, melhor arquitetura,processamento, etc. O comando nos Switches 3Com alterará a prioridade para o valor0 (zero) forçando o dispositivo a ser o Root.

Uma segunda maneira de alterar a prioridade Switch é utilizando o comando stp priority 4096 ( sempre escolha valores múltiplos de 4096)

Obs:Se houver mais de um Switch com a prioridade 0, vence a eleição quem possuir o menor endereço MAC. 

Display STP

O comando display stp em Switches basedos no Comware, exibe informações como o valor do Bridge ID (Bridge priority e endereço MAC) do Switch e do Root, timers,etc. O comando display stp brief exibe o estado das portas na Topologia.

display stp
-------[CIST Global Info][Mode STP]-------
CIST Bridge :32768.000f-cbb8-6329
! Lista a Prioridade do Switch como 32768 e o endereço MAC 000f-cbb8-6329
Bridge Times :Hello 2s MaxAge 20s FwDly 15s MaxHop 20
CIST Root/ERPC :0.000f-cbb8-8f55/ 20000
! A linha exibe a prioridade do Switch Root da Topologia como 0
! (zero nesse caso) e o endereço MAC 000f-cbb8-8f55
CIST RegRoot/IRPC :32768.000f-cbb8-63c0 / 0
CIST RootPortId :128.28
BPDU-Protection :disabled
Bridge Config
Digest Snooping :disabled
TC or TCN received :7
Time since last TC :0 days 24h:20m:51s
! Contador exibindo a última vez que houve uma mudança na topologia STP

Comware 5: Protocolo de Tunelamento GRE

Diego DiasLeave a comment

O GRE (Generic Routing Encapsulation) é um protocolo de tunelamento que pode encapsular diversos protocolos dentro de túneis IP, criando links ponto-a-ponto virtuais entre roteadores remotos.

O protocolo é extremamente funcional em diversos cenários, pois foi desenvolvido para permitir que redes remotas pareçam estar diretamente conectadas. Como GRE não criptografa as informações que são transmitidas através do túnel, podemos utilizar o GRE em conjunto com IPsec para garantir a integridade das informações.

Abaixo podemos observar a representação de encapsulamento  de um pacote IP pelo GRE e a  inclusão de um novo cabeçalho.

O interessante é que o protocolo de transporte poderia ser o IPv6 e o protocolo encapsulado  poderia ser o IPX, tráfego Multicast, etc; E ao ser entregue ao roteador de destino, o novo cabeçalho é removido e o pacote é entregue intacto.

Agora você deve estar se perguntando. Em quais situações podemos usar o GRE ? Veja  o cenário:

Você em um dia normal como analista de redes e seu gerente de TI te informa que  sua   empresa acaba de adquirir uma nova filial e eles precisam ter acesso a alguns servidores que   estão na rede local do ambiente que você administra.  Depois de concluir todo processo de contratação do link e a conectividade com a filial estar finalizada, seu gerente de TI lhe informa   que na nova filial utilizará OSPF para declarar as redes locais.

Agora você pensa: como podemos configurar o OSPF nesses roteadores se eles não estão diretamente conectados? Como administrar o processo de roteamento via uma rede gerenciada pela Operadora como por exemplo, com MPLS,  que não está emulando um Lan-to-Lan ? É ai que entra o Túnel GRE.

Configuração

Antes de criar o tunnel, certifique-se que a origem e o destino mapeados na Interface Tunnel estejam acessíveis via roteamento. No nosso exemplo, usaremos  a Loopback.

Como os roteadores simularão uma conexão ponto-a-ponto, eles irão trocar informações  de  roteamento através do túnel como se estivessem diretamente conectados.

Por padrão o Comware habilita o protocolo GRE em túneis sem a necessidade de configuração adicional. Caso você precise utilizar uma Interface Tunnel para alguma outra função, segue abaixo algumas possibilidades:

[RA-Tunnel10]tunnel-protocol ?
  dvpn       Dynamic Virtual Private Network
  gre        Generic Routing Encapsulation
  ipsec      IPsec tunnel encapsulation
  ipv4-ipv4  tunnel mode ipv4 over ipv4
  ipv4-ipv6  tunnel mode ipv4 over ipv6
  ipv6-ipv4  tunnel mode ipv6 over(to) ipv4
  ipv6-ipv6  tunnel mode ipv6 over ipv6
  mpls       Multiprotocol Label Switching

Considerações para a utilização de Tunnel em Switches HP baseados no Comware

A utilização de interface Tunnel em Switches HP baseados no Comware pode ser um pouco mais complicada que em roteadores. Antes de utilizarmos o processo acima  é necessário criar uma configuração de “Service Loopback” (em alguns modelos de Switches), vincular à uma porta não utilizada (vazia) e também vincular o serviço ao Tunnel. Segue abaixo os passos:

• Crie um “tunnel-type service loopback group’.

• Adicione uma porta não utilizada ao “Service loopback group”.

# Criando o “Service-loopback” group 1 e especificando o tipo como tunnel.
[SwitchA] service-loopback group 1 type tunnel

# Vinculando a porta Giga 1/0/3 para o “Service-loopback” group 1. 
#Desabilite o STP e o LLDP da interface.
[SwitchA] interface GigabitEthernet 1/0/3
[SwitchA-GigabitEthernet1/0/3] undo stp enable
[SwitchA-GigabitEthernet1/0/3] undo lldp enable
[SwitchA-GigabitEthernet1/0/3] port service-loopback group 1
[SwitchA-GigabitEthernet1/0/3] quit

# Aplique  o “Service-loopback” group 1 à interface tunnel.
[SwitchA] interface tunnel 0
[SwitchA-Tunnel0] service-loopback-group 1
[SwitchA-Tunnel0] quit
# O tunnel ficará up mesmo que a outra ponta não esteja configurada

Até a próxima

Roteamento entre VLANs e configuração de rota estática para Switches HP, 3Com e H3C

Diego DiasLeave a comment

Fala Galera, tudo bom!?

Segue mais uma vídeo-aula produzida por nós, contendo dessa vez o assunto Roteamento entre VLANs utilizando Switches ou Roteadores, além de falarmos também sobre roteamento estático, Topologia, etc.. para equipamentos baseados no Comware (HP , 3Com e H3C) .

Ainda estou apanhando um pouco no formado das vídeo-aulas, mas espero que o vídeo seja útil. 

Comware: VLAN – Trunk utilizando 802.1q (dot1q)

Diego DiasLeave a comment

A utilização de VLAN (Virtual Local Area Network) permite que uma rede física seja dividida em várias redes lógicas dentro de um Switch. A partir da utilização de VLANs, uma estação não é capaz de comunicar-se com estações que não são pertencentes a mesma VLAN (para isto, é necessário a utilização de uma sub-rede por VLAN e que o tráfego passe primeiro por um roteador para chegar a outra rede [ ou utilizando um Switch Multicamada para efetuar o Roteamento]).

Se não utilizássemos uma interface como Trunk e precisássemos passar o tráfego da VLAN para o outro Switch, seria necessário a passagem de um cabo de cada VLAN para o outro dispositivo, como no exemplo abaixo.

Como a maioria dos Switches possui entre 24 e 48 portas a solução ficaria inviável , inutilizando a maioria das portas para conexões entre os dispositivos.

O protocolo IEEE 802.1q permite utilizarmos apenas um cabo na comunicação entre os Switches, marcando cada Frame (quadro) com o ID de cada VLAN.

A marcação efetuada (chamada de TAG) adiciona aos quadros Ethernet 4 bytes no frame original e calculam um novo valor de checagem de erro para o campo FCS.

Dos valores contidos dentro do campo TAG o numero da VLAN é adicionado ao campo VLAN id permitindo a identificação da VLAN entre os Switches.

Uma observação relevante é a utilização do campo Priority (também dentro da TAG) para função de QoS em camada 2 para Ethernet, chamado de 802.1p ou CoS (Class of Services), permitindo a diferenciação de classes de serviços por Switches sem a necessidade de leitura do campo IP.

Já a comunicação entre computadores no mesmo Switch que pertencem a mesma VLAN não são “tagueadas” (untagged). Muitas placas de rede para PC’s e impressoras não são compativéis com o protocolo 802.1Q e ao receberem um frame tagged, não compreenderão o TAG de VLAN e descartarão a informação.
Os Switches que recebem na sua interface Trunk um frame com TAG, irão remover o campo e entregar o quadro ao destino sem a marcação.

A regra é bem simples para a maioria dos casos (salvo exceções):

  • Para comunicação entre Switches, configure as interfaces como Trunk ( Tagged)
  • Para comunicação entre Switches e hosts, servidores, impressoras; configure as interfaces como Access (untagged) com o ID da VLAN

Configuração

Para a maioria dos Switches H3C/3Com configure as portas como trunk da seguinte maneira:

interface GigabitEthernet 1/0/x
! acesso a interface GigabitEthernet
port link-type trunk
! configuração da interface como trunk (frames encaminhados como tagged)
port trunk permit vlan all
! configuração da porta permitindo todas as VLANs no trunk

Porta de acesso

interface GigabitEthernet 1/0/x
! acesso a interface GigabitEthernet
port link-type access
! configuração da interface como acesso (frames encaminhados como untagged)
port access vlan 2
! configuração da porta na vlan 2

Para retornar a porta de alguma VLAN para a VLAN 1, digite o comando undo port access vlan dentro da interface física.

Obs: Por default os frames da VLAN 1 não são encaminhados com TAG dentro do Trunk.

Abraços a todos!!!

Gratuitous ARP em Switches baseados no Comware

Diego DiasLeave a comment

O Protocolo ARP é utilizado na comunicação entre dispositivos em uma Rede Ethernet da mesma Sub-rede que utilizam endereços IPv4. A principal função do ARP é a tradução de endereços IP em endereços MAC. O emissor encaminha em broadcast um pacote ARP contendo o endereço IP do outro host e espera uma resposta com um endereço MAC respectivo.

Em resumo, o ARP auxilia os computadores e Switches que utilizam endereços IPv4 (endereço lógico) ,  a encontrarem o endereço mac (endereço físico) das máquinas em redes Ethernet.

Todo endereço da camada de rede, precisa do mapeamento do endereço da camada de enlace.

Assim,  todos os equipamentos de rede montam uma tabela ARP dinâmica (em redes LAN), que é atualizada de tempos em tempos (o tempo pode variar dependendo do Sistema Operacional) caso alguma máquina troque de IP, ou aprenda um endereço “velho” via DHCP.

Segue abaixo a saída da tabela ARP de uma máquina rodando windows 7.

C:\Users\comutadores>arp -a
Interface: 192.168.99.104 --- 0x10
  Internet Address      Physical Address      Type
  192.168.99.1          14-d6-4d-7e-f7-d8     dynamic
  192.168.99.100        10-3b-59-c7-62-34     dynamic
  192.168.99.102        e8-8d-28-f2-60-7b     dynamic
  192.168.99.255        ff-ff-ff-ff-ff-ff     static
  224.0.0.22            01-00-5e-00-00-16     static
  224.0.0.251           01-00-5e-00-00-fb     static
  224.0.0.252           01-00-5e-00-00-fc     static
  239.255.255.250       01-00-5e-7f-ff-fa     static
  255.255.255.255       ff-ff-ff-ff-ff-ff     static

Uma das  funções do protocolo ARP é o Gratuitous ARP, que permite o envio de requisição ou resposta (contendo o mapeamento endereço IP + endereço MAC) mesmo quando não é solicitado.

O gratuitous ARP é uma mensagem enviada geralmente para atualizar a tabela ARP.

Por exemplo, imagine que todas as máquinas de uma rede possuam como gateway um Switch de Distribuição que precisa ser substituído por um novo equipamento mais robusto e moderno. Agora, imagine que essa migração deva ocorrer de maneira quase que imperceptível por inúmeras restrições. O novo Switch é então conectado a todos os outros Switches da rede, incluindo o Switch legado, e cada vez que uma interface do Switch legado é colocada em shutdown (desligada), a mesma é configurada no Switch novo.

Pense que, uma vez que o gateway é movido para outro equipamento (com o mesmo IP) o endereço mac  deverá mudar…

A configuração do gratuitous ARP deverá auxiliar nessa questão, com o novo equipamento enviando a atualização do endereço IP + MAC para todos os dispositivos da rede.

interface Vlan-interface1
 ip address 192.168.99.1 255.255.255.0
 arp send-gratuitous-arp

Após a certificação e sucesso da migração, o comando poderá ser removido da interface vlan.

[Switch-Vlan-interface1]undo arp send-gratuitous-arp

Espero ter ajudado

Comware: STP edged-port + BPDU-protection

Diego DiasLeave a comment

A feature edged-port permite a interface saltar os estados Listening e Learning do Spanning-Tree Protocol (STP), colocando as portas imediatamente em estado Forwarding (Encaminhamento). A configuração do stp edged-port enableforça a interface a ignorar os estados de convergência do STP, incluíndo as mensagens de notificação de mudança na topologia (mensagens TCN ).

A utilização da feature edged-port com a configuração do comando stp bpdu-protection, protege as portas configuradas como edged-port de receberem BPDUs. Ao receber um BPDU a porta entrará em shutdown.