Switches HPN 4200G – Configurando a autenticação com TACACS

Compatilho abaixo o script básico (comentado) para a autenticação no acesso em Switches HPN utilizando AAA, com o Servidor ACS da Cisco e o protocolo TACACS. A autenticação para o super usuário em nosso exemplo, está como local.

Configuração

#
super password level 3 simple S3nha
! Criando a senha do super usuário como "S3nha"
#
hwtacacs scheme comutadores
! Criando o esquema TACACS com o nome Comutadores
primary authentication 192.168.1.10
!Configurando o IP do Servidor ACS para autenticação
primary authorization 192.168.1.10
!Configurando o IP do Servidor ACS para autorização
primary accounting 192.168.1.10
!Configurando o IP do Servidor ACS para contabilidade
nas-ip 148.91.219.56
!Endereço de IP do Switch cadastrado no ACS
key authentication s3nhacom
! Chave para autenticação com o servidor ACS  com a senha"s3nhacom"

key authorization s3nhacom
key accounting s3nhacom
user-name-format without-domain
! Encaminhamento do usuário sem o formato @dominio
#
domain comutadores.com.br
authentication login hwtacacs-scheme comutadores local
!Configurando a autenticação com TACACS e em caso de falha, a autenticação será local.
authorization login hwtacacs-scheme comutadores local
accounting login hwtacacs-scheme comutadores local
#
domain default enable comutadores.com.br
! Habilitando o dominio comutadores.com.br como default para auetnticação
#
user-interface vty 0 4
authentication-mode scheme
#

obs: Sugerimos que durante os testes, não configure o authentication-mode scheme no acesso via Console, para em caso de falha nos testes, você não fique trancado do lado de fora do Switch. 😉

Boa semana!

Switches 3Com 4800G – Port Security

A feature port security permite o aprendizado dinâmico de endereço MAC vinculado a uma interface GibabitEthernet para fins de segurança, não permitindo que outro host funcione naquela interface. Se a condição não for satisfeita (a utilização do MAC correto), a porta entrará em estado de violação e não trafegará dados.

É possível configurar a quantidade de endereços MAC aprendidos dinamicamente pela Interface, inserindo assim (após o aprendizado estático ou dinâmico dos endereços) entradas fixas na tabela de endereços MAC.

A feature é bastante útil em ambientes que os hosts/Servidores precisam ser vinculados a uma interface (como em CPDs, DataCenters, etc) ou em localidades que o usuário costuma migrar a estação sem comunicar a equipe de suporte!

As configurações aprendidas serão atribuídas à configuração da memória volátil. Se o dispositivo for reiniciado ele aprenderá novos endereços. Na necessidade de manter os endereços aprendidos, sugerimos salvar a configuração.

Configuração

[4800] port-security enable
! Habilitando o port-security no Switch
[4800] interface gigabitethernet 1/0/1
[4800-GigabitEthernet1/0/1] port-security max-mac-count 1
! Habilitando o port-security para o aprendizado dinamico de
! apenas 1 endereço MAC ( o primeiro descoberto)
[4800-GigabitEthernet1/0/1] port-security port-mode autolearn
! Habilitando o port-security para aprendizado dinamico do endereço
! MAC para a interface GigabitEthernet 1/0/1

Obs: Após o aprendizado do endereço MAC, a interface GigabitEthernet não permitirá a conexão de outra máquina na porta giga 1/0/1. O endereço aprendido na interface giga 1/0/1 não poderá ser utilizado em outra interface no mesmo Switch. Sugerimos não configurar o Port-Security em interfaces TRUNK

Display

Segue abaixo a configuração da interface após o aprendizado:

#
interface GigabitEthernet1/0/1
port access vlan 10
stp edged-port enable
port-security max-mac-count 1
port-security port-mode autolearn
port-security mac-address security 000a-aab2-a33b vlan 10

! A saída abaixo relata a troca de máquina na int GigabitEthernet 1/0/1

%Apr 26 17:23:01:527 2000 SBSSWCOR03 PORTSEC/1/VIOLATION:
OID: 1.3.6.1.4.1.43.45.1.10.2.26.1.3.2
An intrusion occurs!
IfIndex: 9437189
Port:GigabitEthernet1/0/1
MAC Addr: 00:0F:DF:B4:FA:49
VLAN id:10
IfAdminStatus: 1

Switches 3Com 4800G – Ataques ao protocolo ARP

O protocolo ARP possui 3 principais vulnerabilidades:

  • Não possui suporte a autenticação
  • É suscetível a vazamento de informação via análise de mensagens Broadcast do protocolo durante solicitação de conversa entre dispositivos.
  • Força o processamento para os hosts da VLAN para todas as requisições ARP, consumindo CPU e largura de banda.

Umas das principais técnicas utilizadas em ataques ao ARP são conhecidas com ARP Spoofing ou ARP Poisoning. A técnica consiste em encaminhar uma resposta falsa a requisição ARP original ou via Gratuitous ARP, permitindo ao atacante atuar no meio da comunicação (Man-in-the-Middle) para “sniffar” o trafego . O host de origem não perceberia a atuação do atacante.

Clique no link para assistir uma rápida demonstração utilizando o software Cain (em inglês) http://www.irongeek.com/i.php?page=videos/using-cain-to-do-a-man-in-the-middle-attack-by-arp-poisoning

ARP Detection

A detecção de ARP permite ao Switch encaminhar somente o tráfego válido na tabela ARP.O tráfego pode ser validado via 802.1x, entradas estáticas ou via DHCP Snooping, no script abaixo mostraremos a técnica utilizando o modo estático e via o mapeamento do DHCP Snooping.

A utilização da feature DHCP-Snooping permite aos Switches o bloqueio de respostas DHCP de Servidores não-válidos na rede e o mapeamento dos Endereços IP entregue ao usuário com o endereço MAC do host, conforme display abaixo:

[4800G]display dhcp-snooping 

DHCP Snooping is enabled.
The client binding table for all untrusted ports.
Type : D--Dynamic , S--Static
Type IP Address MAC Address Lease VLAN Interface
==== =============== ============== ============ ==== =================
D 192.168.1.102 0027-0e0f-a154 172653 1 GigabitEthernet1/0/4
D 192.168.1.103 0027-0e0f-9edb 172728 1 GigabitEthernet1/0/12
--- 2 dhcp-snooping item(s) found ---

Quando ativamos a detecção ARP, todas as portas são consideradas não confiáveis comparando o endereço MAC de origem com o mapeamento IP + MAC checado.

#
dhcp-snooping
!Ativando o DHCP Snooping
#
vlan 1
arp detection enable
!Habilitando a detecção ARP na VLAN 1
#
arp detection mode dhcp-snooping
!Ativando a detecção ARP para verificação da tabela gerada pelo DHCP Snooping
arp detection mode static-bind
!Ativando a detecção ARP para verificação da tabela estática
arp detection static-bind 192.168.1.104 0027-c686-6681
! Gerando uma entrada estática para detecção de ARP
#

Obs: É possível configurar uma interface como confiável para não haver detecção de ARP naquela porta. Configure o comando “arp detection trust” na interface.

ARP Source Suppression

Para proteção contra ataques à hosts com o envio de grande numero de requisições ARP é possível habilitar a supressão de ARP.

!
arp source-suppression enable
arp source-suppression limit 10
! Limita o numero de 10 requisições ARP da mesma origem para endereços
! não resolvidos no threshold de 5 segundos. Se o limite for excedido,
! o Switch efetuará a supressão do ARP do host por 5 segundos.

No guia de configuração dos Switches há maiores referencias e outras técnicas de proteção contra ataques ao ARP. Caso conheça outras técnicas e softwares deixe um comentário.

Abraço a todos!

Referências e Consulta

Lan Switch Security , Eric Vyncke and Christopher Paggen ,Cisco Press, 2008
http://comutadores.blogspot.com/2010/04/switches-3com-4800-dhcp-snooping-como.html
http://www.irongeek.com/i.php?page=security/arpspoof
http://imasters.com.br/artigo/10117/seguranca/arp_poisoning/

Como funciona a Auto-negociação?

Publicado originalmente em 17 DE FEVEREIRO DE 2010

A auto-negociação é uma protocolo da Camada Física do modelo de referência OSI, que permite que dois equipamentos de rede (Switches, Roteadores e Servidores) negociem velocidade eduplex para escolha dinâmica do melhor cenário para a comunicação de dados.

O padrão é bastante útil no dimensionamento de redes para a compatibilidade entre as versões 10/100/1000Mb das interfaces.

Apesar da instabilidade inicial do padrão (devido à incompatibilidade dos fabricantes na adoção do modelo), as discussões da especificação da auto-negociação foram eliminados pela versão de 1998 do IEEE 802.3. Em 1999, o protocolo de negociação foi significativamente ampliado por IEEE 802.3ab, que especificava o protocolo de GigabitEthernet, tornando obrigatória a auto-negociação para 1000BASE-T.

A auto-negociação é utilizada por dispositivos com diferentesvelocidades de operação (como 10Mb e 1Gb) e diferentes modos de operação duplex (Half-duplex e Full-duplex).

A incompatibilidade de duplex (duplex mismatch) ocorre quando um dispositivo está em full-duplex e o outro está funcionando em half-duplex. Por causa desse cenário um grande número de colisões irá ocorrer no lado half-duplex. Uma segunda ressalva é que interfaces configuradas manualmente não funcionam adequadamente com interfaces configuradas como auto-negociação.

Problemas de duplex mismatch são comuns e difíceis de diagnosticar, pois a rede continua a funcionar; e em testes básicos de troubleshooting, reportam uma conexão ativa, mas a rede funciona com lentidão.

Melhores práticas
Certifique-se que ambos os lados do link estão configurados da mesma maneira”.(Gary A. Donahue , Network Warrior, O’Reilly, 2007, p22)

Configurando a Auto-negociação 

Em Switches 3Com a auto-negociação está habilitada por default:

speed { 10 100 1000 auto }
duplex { auto full half }

Exemplo de configuração de speed e duplex em auto:

[Switch-GigabitEthernet1/0/1]duplex auto
#
[Switch-GigabitEthernet1/0/1]speed auto

Referências:

Wikipedia – http://en.wikipedia.org/wiki/Autonegotiation
Ethermanage – http://www.ethermanage.com/ethernet/100quickref/ch13qr_3.html

Script de Configuração NQA com Tracking (IP SLA)

A dica de utilização do NQA foi encaminhada pelo Leandro Cândido: “Caros, estava testando a Feature de NQA + TRACK  (SIMILAR AO IP SLA DO CISCO), pois iríamos precisar utilizar em um dos nossos clientes, e vi que funciona perfeitamente bem. Então, estou encaminhando o script caso alguém precise aplicar em algum projeto que envolva equipamentos 8800, 4800, 7900 e outros…”

A Feature NQA (Network Quality Analizer) permite o diagnóstico de desempenho de Links para verificação de Jitter, atraso de conexão TCP, FTP, ICMP e etc.

O NQA realiza testes utilizando pacotes ICMP echo, DHCP, FTP, HTTP, UDP jitter, SNMP, TCP, UDP echo, voz e DLSw.

No exemplo abaixo utilizaremos o NQA para testar o link principal com pacotes ICMP (PING). Em caso de falha do Link, o NQA permitirá ao Switch utilizar uma segunda a rota default para encaminhar o tráfego para o Link Redundante.

Utilizaremos o primeiro Roteador da Operadora A (Link principal) como Objeto para “rastrear” o Link como ativo.

Configuração

Nessa primeira parte do Script efetuaremos o vínculo do NQA (responsável por gerar os pacotes ICMP) com o Track.

 

nqa entry empresax rota_monitorada_via_icmp
!Criando o grupo NQA empresax rota_monitorada_via_icmp
type icmp-echo
! definindo o tipo de pacote como ICMP
destination ip 200.1.2.3
! endereço monitorado no primeiro salto da Operadora A
frequency 500
! a freqüência do teste será a cada 500ms
reaction 1 checked-element probe-fail threshold-type consecutive 4 action-type trigger-only
! Se a reação 1 identificar 4 falhas no objeto monitorado, ele será invalidado 

nqa schedule empresax rota_monitorada_via_icmp start-time now lifetime forever
!ativando o tempo de monitoração como infinito
nqa agent enable

track 1 nqa entry empresax rota_monitorada_via_icmp reaction 1
!Associando o track 1 ao NQA empresax

Obs: Até agora apenas criamos o NQA para monitorar o endereço do primeiro salto da Operadora A (é possível identificarmos esse endereço com o comando traceroute para qualquer endereço de internet) e vinculamos ao Track. A idéia agora é vincularmos a rota default principal como Objeto do Track, para invalidarmos a rota em caso de falha no link.

ip route-static 0.0.0.0 0.0.0.0 192.0.1.1 track 1 preference 1 descripition rota_principal
! Associando a rota estática com preferência 1 ao Track 1
ip route-static 200.1.2.3 255.255.255.255 192.0.1.1 descripition roteador_operadoraA
! A rota estática  está forçando a monitoração do Link Principal pelo roteador 192.0.1.1 
! evitando chegarmos no Roteador da operadora A via Operadora B em caso de falha no link principal

ip route-static 0.0.0.0 0.0.0.0 192.0.2.1 preference 60 description rota_backup
! rota de backup com preferência 60

Comandos Display

[4800G] display track 1
Track ID: 1
Status: Positive
! Rota principal funcionando
Reference object:
NQA entry: empresax rota_monitorada_via_icmp
Reaction: 1

[4800G]display nqa statistics
NQA entry(admin empresax, tag rota_monitorada_via_icmp) test 
statistics:
NO. : 1
Destination IP address: 200.1.2.3 
Start time: 2000-04-26 13:14:57.0 
Life time: 2612 
Send operation times: 2510 Receive response times: 2067 
Min/Max/Average round trip time: 3/460/4 
Square-Sum of round trip time: 553275 

Extended results:
Packet lost in test: 17% 
Failures due to timeout: 443
Failures due to disconnect: 0 
Failures due to no connection: 0
Failures due to sequence error: 0 
Failures due to internal error: 0
Failures due to other errors: 0

Packet(s) arrived late: 0

[4800G]display ip routing-table 
Routing Tables: Public
Destination/Mask Proto Pre Cost NextHop Interface
0.0.0.0/0 Static 1 0 192.0.1.1 Vlan1 
!Tráfego encaminhado via interface vlan 1, antes do problema no link

Após a falha

Se o resultado do teste NQA der negativo, isto é, 200.1.2.3 como inalcançável, (o status do Objeto Track é Negative) a rota estática será inválida.

[4800G]display track 1 
Track ID: 1
Status: Negative
!Momento em que ocorre o problema no link, rota principal para de funcionar 
Reference object:
NQA entry: empresax rota_monitorada_via_icmp
Reaction: 1

[4800G]dis ip routing-table 
Routing Tables: Public
Destination/Mask Proto Pre Cost NextHop Interface
0.0.0.0/0 Static 60 0 192.0.2.1 Vlan3 
! Agora o Tráfego será encaminhado via interface vlan 3. Se o link principal 
! voltar a comunicar, a rota default com preferência 1 voltará para tabela de 
! rotas excluíndo a de preferência 60

O que acharam do NQA? já tiveram alguma experiência com essa feature? Comentem…

Abraços

Switches 3Com 4800G – Upgrade do Sistema Operacional por TFTP

No modo user-view é possível efetuarmos a cópia de arquivos no sentido Switch x Servidor (PUT) ou Servidor x Switch (GET). O TFTP é o modo mais utilizado para cópia de arquivos com o objetivo de atualização de extensões como .bin, .btm, .cfg,etc.

É necessário configurarmos ao menos um endereço IP no Switch, além de validarmos comunicação entre o Servidor TFTP e o Switch.

A sintaxe para cópia de arquivos para o Switch é a seguinte:

Tftp [ip do servidor TFTP] get [nome do arquivo no servidor TFTP]

Uma outra opção para utilizarmos o comando TFTP é para o Backup de configurações/arquivos no servidor TFTP. A sintaxe necessária para a cópia de arquivos para o Servidor TFTP é a seguinte:

Tftp [ip do servidor TFTP] put [nome do arquivo no Switch]

Para transformar a sua máquina em um Servidor TFTP podemos utilizar diversos softwares grátis como o Solarwinds TFTP Server,tftpd32 e etc.

No exemplo abaixo o Switch efetuará a cópia dos arquivos s4800g-cmw520-r2202p15-s56.bin e S4800G-BTM_604.btm do Servidor TFTP para a memória Flash do Switch 4800G e configuraremos o dispositivo para iniciar com a imagem na próxima vez que reiniciar!

Copiando o arquivo .bin e .btm para o Switch

<4800G>tftp 192.168.1.68 get s4800g-cmw520-r2202p15-s56.bin

<4800G>tftp 192.168.1.68 get S4800G-BTM_604.btm

Até agora, só copiamos os arquivos para o Switch, nos exemplos abaixo ensinaremos como configurar o Switch para utilizar as novas imagens!!

Boot-loader
O comando boot-loader define qual imagem será escolhida como principal e backup na inicialização do Switch. Por Exemplo, após atualização por TFTP da imagem atual do Switch de                              s4800g-cmw520-r2102p02.bin para s4800g-cmw520-r2202p15-s56.bin, precisaremos informar ao equipamento qual versão do Sistema Operacional iremos utilizar no próximo boot. Digite:

<4800G>boot-loader file S4800G-cmw520-r2202p15-s56.bin main

Bootrom
No documento de liberação da imagem s4800g-cmw520-r2202p15-s56.bin, a H3C/3Com solicita o upgrade do bootrom. Digite:

<4800G>bootrom update file s4800g-btm_604.btm

Após efetuados os passos acima, reinicie o equipamento com o comando reboot

Problemas
Em caso de problemas na transferência de arquivos verifique:

  • Se há espaço disponível na memória flash do Switch com o comando dir no modo user-view
  • Verifique se o firewall do Servidor está bloqueando a transferência
  • Identifique se o serviço TFTP está ativo no computador.
  • Verifique se a pasta de destino configurada no Servidor para coleta dos arquivos está com o caminho correto no Software de TFTP

Em caso de problemas após efetuar a cópia e configurar o bootloader/bootrom no Switch , o mesmo ficará reiniciando ( após inumeras tentativas de subir o Sistema Operacional), pressione ctrl + B na seguinte tela, provavelmente o password estará em branco (pressione Enter):

 O Switch cairá no modo Bootrom sem nenhuma configuração, mas será possivel com a opção 2 selecionar os arquivos para Boot ( em caso de erro) ou com a opção 1 copiar novamente os arquivos para a Flash, etc. O Switch permitirá nos menus a configuração de endereço IP para nova cópia!

Dúvidas, deixe um comentário!!

Switches HP 7900 / Roteadores MSR’s – Comando network no OSPF versão 2

Publicado originalmente em 28 DE NOVEMBRO DE 2010

Nos últimos dias durante um treinamento do OSPF fui questionado sobre  a função do comando network dentro do processo OSPF em um Switch/Roteador .

Hoje, por acaso, encontrei um tópico semelhante no Packet Life que serviu de inspiração escrever esse artigo.

Usarei o conceito de interface VLAN para o exemplo,  mas o efeito é o mesmo para Interfaces Ethernet, Serial,etc..

O comando Network

O comando network dentro do Processo OSPF tem a função de PERMITIR uma determinada interface dentro do Protocolo de Roteamento. No exemplo abaixo configuraremos a rede 192.168.1.0/24 e 172.31.0.0/16 como normalmente é executado:

ospf 100
! Configurando o processo OSPF com o número 100
area 0.0.0.0
!Configurando a Aérea 0
network 192.168.1.0 0.0.0.255
! Configurando a rede 192.168.24.0/24 com a wildcard mask (mascara curinga)
network 172.31.0.0 0.0.255.255
! Configurando a rede 172.31.0.0/16 com a wildcard mask (mascara curinga)

Com a configuração efetuada, todas as interfaces com o endereço IP dentro desse range começarão a trocar pacotes Hello para estabelecimento de adjacência OSPF.

Se o IP da interface VLAN fosse 192.168.1.1/24 poderíamos configurar o comando network como:

network 192.168.1.1 0.0.0.0
! Configurando a Interface VLAN  com IP 192.168.1.1 com mascara curinga de
! 32 bits para participar no processo OSPF.

ou 

network 0.0.0.0 255.255.255.255
! Configurando TODAS Interfaces VLAN do Switch com mascara curinga de
! 0 bits para participar no processo OSPF.

Se analisássemos a Tabela de Roteamento dos Roteadores adjacentes, veríamos que a rede 192.168.1.0/24 seria declarada da mesma maneira.

[7500]disp ip routing-table
Routing Tables: Public

Destination/Mask Proto Pre Cost NextHop      Interface

192.168.1.0/24  OSPF   100  1   172.31.1.2    Vlan2

Com os exemplos apresentados acima para a adjacência OSPF, sugerimos apenas a configuração do IP da Interface que  participará do processo com a mascara curinga 0.0.0.0, para assim não inserir outras redes por engano.  😉

Conversor de Part Number 3Com para HP


A HP possui uma ferramenta para quem precisa converter o Part Number de equipamentos da 3Com e H3C para os novos Part Number da HP.

A ferramenta é bastante útil quando em necessidades de encontrar equipamentos com Part Numbers alterados após a aquisição, encontrar atualizações de firmware/SO e documentações dos dispositivos.

No exemplo abaixo, após a identificação do modelo do equipamento com o comando display version é possivel indentificar o modelo do equipamento.

[Switch]display version
H3C Comware Platform Software
Comware Software, Version 5.20, Release 1211P04
Copyright (c) 2004-2012 Hangzhou H3C Tech. Co., Ltd. All rights reserved.
H3C S5800-60C-PWR uptime is 5 weeks, 1 day, 17 hours, 11 minutes
…..

No link http://h17007.www1.hp.com/br/pt/support/converter/index.aspx é possível preencher as informações como nome do fabricante (pré-aquisição da HP) , tipo do equipamento (Switch, Router, etc) e o nome do produto conforme imagem abaixo:

A dica foi encontrada no blog http://blog.microsafe.com.br/index.php/2011/05/31/guia-de-conversao-de-part-numbers-3com-para-hp-networking/trackback/

 

Switches 3Com 4800G – Link Aggregation

Publicado originalmente em 9 DE ABRIL DE 2010

Os Switches 3Com/ HPN/ H3C oferecem a utilização de interfaces Ethernet, Fast Ethernet, GigabitEthernet ou 10 GigabitEthernet. O Link Aggregation permite a agregação de diversas portas para incrementar a velocidade do link na comunicação full duplex entre dois dispositivos.

Os link são utilizados em paralelo, provendo crescimento e expansão de banda, redundância, sem a necessidade de compra de Hardware adicional.

Por exemplo, podemos utilizar 4 portas de 100Mb em cada dispositivo para formar um link de comunicação entre 2 Switches de 400Mb. Entretanto a utlilzação de enlaces redundantes cria a possibilidade de Loops na rede. O Link Aggregation evita que os estados de bloqueios ou Loop para as portas agregadas, tratando-as como uma única interface. Para o STP, SNMP e VLANs as interfaces são tratadas como um único link lógico.

Outros nomes utilizados para o Link Aggregation são: Ethernet bonding, NIC teaming, port channel, link bundling, EtherChannel, MLT, NIC bonding, network bonding e Network Fault Tolerance (NFT).

O protocol LACP é parte da especificação 802.3ad para Link Aggregation, permitindo que Switches, Servidores negociem automaticamente o grupo de portas em diferentes fabricantes. Ambas as portas deverão oferecer suporte ao protocolo para o correto funcionamento do Link Aggregation.

Alguns modelos de Switch poderão utilizar o protocolo PAgP(Cisco) ou o modo estático das interfaces, sugerimos a utilização do protocolo LACP que é suportado pela grande maioria dos fabricantes de dispositivos para rede.

!Criando uma agregação de links com o ID 1
interface bridge-aggregation 1
! Criação da interface lógica com o ID 2 para o Link Aggregation
link-aggregation mode dynamic
! Configuração da interface lógica para troca dinâmica do protocol LACP

No Exemplo abaixo configuraremos 2 portas GigaEthernet como Link Aggregation, formando um link de 2 Gigabits

4800-1

interface Bridge-Aggregation1
link-aggregation mode dynamic
port link-type trunk
port trunk permit vlan all
#
interface GigabitEthernet1/0/31
port link-type trunk
port trunk permit vlan all
port link-aggregation group 1
#
interface GigabitEthernet1/0/32
port link-type trunk
port trunk permit vlan all
port link-aggregation group 1

4800-2

interface Bridge-Aggregation1
link-aggregation mode dynamic
port link-type trunk
port trunk permit vlan all#
interface GigabitEthernet1/0/23
port link-type trunk
port trunk permit vlan all
port link-aggregation group 1
#
interface GigabitEthernet1/0/24
port link-type trunk
port trunk permit vlan all
port link-aggregation group 1

Comandos display

[4800-1]display link-aggretion summary

Aggregation Interface Type:
BAGG -- Bridge-Aggregation, RAGG -- Route-Aggregation Aggregation Mode: S -- Static, D -- Dynamic
Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing
Actor System ID: 0x8000, 4001-c621-8400

AGG AGG Partner ID Select Unselect
Share Interface Mode Ports Ports Type
-------------------------------------
BAGG1 D 0x8000, 0024-73cd-b900 2 0 Shar

[4800-1]displ link-aggregation verbose
Loadsharing Type:
Shar -- Loadsharing, NonS -- Non-Loadsharing
Port Status: S -- Selected, U -- Unselected Flags: A -- LACP_Activity,
B -- LACP_Timeout, C -- Aggregation,D -- Synchronization, E -- Collecting,
F -- Distributing, G -- Defaulted, H -- Expired

Aggregation Interface: Bridge-Aggregation1Aggregation Mode: Dynamic
Loadsharing Type: Shar
System ID: 0x8000, 4001-c621-8400
Local: Port Status Priority Oper-Key Flag
--------------------------------------
GE1/0/31 S 32768 1 {ACDEF}
GE1/0/32 S 32768 1 {ACDEF}

Remote:
Actor Partner Priority Oper-Key SystemID Flag
GE1/0/23 1 32768 1 0x8000, 0024-73cd-b900 {ACDEF}
GE1/0/24 2 32768 1 0x8000, 0024-73cd-b900 {ACDEF}

Verificando o Spanning-Tree

[4800-2]displ stp brief
MSTID Port Role STP State Protection
0 Bridge-Aggregation1 ROOT FORWARDING NONE

É possível verificarmos que as interfaces são reconhecidas como uma única porta para a Topologia Spanning-Tree, de forma que as duas portas estão ativas na Topologia com redundância.

Links interessantes para Configuração do 802.1x em Switches HPN, H3C e 3Com

IEEE 802.1X é um padrão IEEE para controle de acesso à rede que provê um mecanismo de autenticação para dispositivos que desejam juntar-se à uma porta na LAN, prevenindo acesso para esta porta se a autenticação falhar. A feature é também bastante poderosa para vinculo de VLANs, VLANs Guest e ACL’s dinâmicas.

Segue abaixo alguns links com modelos e soluções bem interessantes. Infelizmente nunca participei diretamente em projetos envolvendo esse modelo de autenticação, mas os documentos possuem detalhes importantes e vale a pena a leitura caso haja interesse em implementar a solução.

IEEE 802.1x Authentication –
http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA3-7309ENW.pdf
! Esse arquivo PDF foi muito bem escrito e possui alguns modelos de autenticação de 802.1x com Software Livre, infelizmente o documento está em inglês.

Estudo de caso: Autenticação IEEE 802.1x baseada no Protocolo RADIUS e Serviço de Diretório LDAP aplicado a rede GIGAUFOPNET
http://www.decom.ufop.br/menotti/monoII102/files/BCC391-102-vf-04.1.4174…
! Documento muito bem escrito pelo Tiago Rodrigues Chaves como trabalho de conclusão de curso, utilizando Switches 3Com modelo 5500 e 4500

801.1x Configuration – H3C
http://www.h3c.com/portal/Technical_Support___Documents/Technical_Documents/Switches/H3C_…
! Material bem técnico elaborado pela H3C, infelizmente o documento está em inglês.

Se algum link estiver quebrado, mande email ou deixe um comentário

Boa leitura