Nesse vídeos mostramos uma configuração simples de um Switch ArubaOS-CX para gerenciamento de switches com funcionalidades como: VRF, NTP, Syslog, SNMP, SSH, usuários local, RADIUS, TACACS entre outros.
6300
Vídeo: Switches ArubaOS-CX – Configurando Spanning-Tree no EVE-NG
Nesse video, montamos um laboratório no EVE-NG com Switches ArubaOS-CX demonstrando a configuração do Spanning-Tree e das portas admin-edge.
Switches ArubaOS-CX: Portas em admin-edge / portfast
O protocolo Spanning-Tree utiliza um algoritmo para detecção de caminhos alternativos colocando as interfaces redundantes em modo temporário de bloqueio, eliminando o loop lógico.
Um switch da rede local com o Spanning-Tree habilitado e conectado a outros switches que utilizam o protocolo, trocam informações STP por mensagens chamadas de BPDUs (Bridge Protocol Data Units). Os BPDU’s são os responsáveis pelo correto funcionamento do algoritmo do Spanning-Tree e são encaminhados a cada 2 segundos para todas as portas.
O objetivo do STP é eliminar loops na rede com a negociação de caminhos livres através do switch root (raiz). Dessa forma é garantido que haverá apenas um caminho para qualquer destino, com o bloqueio dos caminhos redundantes. Se houver falha no enlace principal, o caminho em estado de bloqueio torna-se o principal.
O algoritmo do Spanning-Tree (chamado STA) deve encontrar um ponto de referência na rede (root) e determinar os caminhos disponíveis, além de detectar os enlaces redundantes e bloqueá-los.
Com o objetivo de detectar loop na rede, o spanning-tree necessita que o processo de detecção de BPDUs ocorra em todas as portas do Switch, inclusive em portas destinadas aos computadores, servidores, impressoras etc.
Em razão disso as portas do Switch conectadas aos dispositivos finais precisam de uma configuração manual para rápida transição do modo de discarding para o forwarding e assim iniciar imediatamente, visto que não há previsão para conectividade entre Switches naquela porta e espera todo o processo do spanning-tree que poderá deixar a porta em espera por alguns segundos.
Portas Edges enviam BPDU, mas não devem receber (não devem ser conectadas à switches). Se uma porta Edge receber BPDU, o Portfast é “desabilitado” e a porta faz o processo normal do STP.
Durante qualquer alteração da topologia do Spanning-tree a porta Edge não participará do Spanning-Tree, mas gerará BPDU’s por segurança.
A recomendação, uma vez utilizando o spanning-tree em Switches Aruba CX é habilitar o admin-edge em todas as portas de hosts.
Configurando uma interface como admin-edge:
interface 1/1/n spanning-tree port-type admin-edge spanning-tree tcn-guard exit
O comando tcn-guard desabilita a propagação de notificações de alteração de topologia (TCNs) para outras portas STP. Use isso quando você não quiser que as alterações de topologia sejam percebidas pelos dispositivos STP vizinhos.
Referências:
http://www.comutadores.com.br/rapid-spanning-tree-802-1w/
https://community.arubanetworks.com/community-home/digestviewer/viewthread?MID=32043
Switches ArubaOS-CX: IP source-interface
O commando ip source-interface define o endereço IP de origem para nas mensagens enviadas do Switches para servidores externos, como por exemplo SYSLOG, sFlow, RADIUS, TACACS, entre outros. Isso garante que todo o tráfego enviado ao recurso tenha o mesmo endereço IP de origem, independentemente de como ele sai do switch.
ip source-interface {sflow | tftp | radius | tacacs | ntp | syslog | ubt | dhcp-relay | simplivity | dns | all} {interface <IFNAME> | <IPV4-ADDR>} [vrf <VRF-NAME>]
switch(config)# ip source-interface ? all All protocols central Aruba Central protocol dhcp_relay DHCP_RELAY protocol dns DNS protocol ntp NTP protocol radius RADIUS protocol sflow sFlow protocol syslog syslog protocol tacacs TACACS protocol tftp TFTP protocol switch(config)# ip source-interface all ? A.B.C.D Specify an IPv4 address interface Interface information switch(config)# ip source-interface all 192.168.2.1
Até logo!
Vídeo: Switches ArubaOS-CX – Configurando Roteamento entre VLAN no EVE-NG
Nesse vídeo, montamos um laboratório no EVE-NG com Switches ArubaOS-CX demonstrando a configuração do roteamento entre VLANs.
Vídeo: Switches ArubaOS-CX – Configurando Link Aggregation
Nesse vídeo, explicamos a configuração de Link Aggregation em Switches ArubaOS-CX.
Vídeo: Switches ArubaOS-CX – Configurando VLAN e Link-Aggregation no EVE-NG
Nesse vídeo, montamos um laboratório no EVE-NG com Switches ArubaOS-CX demonstrando a configuração de VLANs com as portas access e trunk, Link-Aggregation com LACP, assim como os detalhes de alguns parâmetros relacionados a essas funcionalidades.
Swiches ArubaOS-CX 6300 e 6200: Configurando VSF
A feature VSF é a tecnologia responsável pelo empilhamento dos Switches ArubaOS-CX família 6200 e 6300 . Uma vez que a pilha VSF é formada, todos os switches interconectados operam como um único switch virtual, com um único plano de controle. Todas as interfaces e serviços de todos os switches da pilha VSF estarão disponíveis para configuração e gerenciamento.
A funcionalidade também permite a configuração do link-aggregation distribuído, abrangendo as interfaces de vários switches individuais dentro da pilha para a formação da agregação de portas.
A configuração do VSF é bem simples e está disponível no ArubaOS-CX na versão 10.04 ou superior. Todos os membros devem rodar a mesma versão do OS-CX.
Os switches 6200 e 6300 não podem formar o VSF entre si, mas diferente modelos de switches 6300 podem formar o stack VSF.
Para a formação de um link VSF deverão ser utilizadas as interfaces de 10Gbps , 25Gbps ou 50Gbps.
Configurando o VSF
Validando a formação do VSF
SW-Access1# show vsf
MAC Address : 64:e8:81:d8:ed:40
Secondary :
Topology : Chain
Status : No Split
Split Detection Method : None
Mbr Mac Address type Status
ID
--- ------------------- -------------- ---------------
1 64:e8:81:d8:ed:40 JL666A Master
2 64:e8:81:d9:b1:00 JL666A Member
SW-Access1# show vsf topology
Mstr
+---+ +---+
| 2 |1==1| 1 |
+---+ +---+
Configurando o secondary member
A pilha não terá um membro secundário por padrão. Um membro secundário pode ser configurado a partir de membros disponíveis e será atribuído a função de “master standy” na pilha. A funcionalidade permitirá definir qual switch assumirá a função de master, na falha do equipamento principal (o master).
Quando for configurado como secundário, um membro do stacking que já está presente na pilha será reinicializado e reintegrado à pilha como o standby.
Um membro já provisionado como standby pode ser configurado como um membro secundário. Quando o membro entrar no stacking, ele será inicializado na função de standby, sem nenhuma reinicialização adicional.
Se um membro secundário já estiver configurado e fisicamente presente na pilha e outro switch for iniciado já configurado como standby, a remoção do membro secundário anterior fará com que o ‘switch membro secundário anterior’ reinicie e entre como member.
Caso o master apresente problemas, o standby assumirá a função do master.
Abaixo, mostramos a continuidade da configuração acima, adicionando o switch 2 para a função de standby (com o stacking já formado e sem configuração de switch standby previamente) .
SW-AccessVSF(config)# show vsf MAC Address : 64:e8:81:d8:ed:40 Secondary : 2 Topology : Chain Status : No Split Split Detection Method : None Mbr Mac Address type Status ID --- ------------------- -------------- --------------- 1 64:e8:81:d8:ed:40 JL666A Master 2 64:e8:81:d9:b1:00 JL666A Standby SW-AccessVSF(config)# show vsf topology Stdby Mstr +---+ +---+ | 2 |1==1| 1 | +---+ +---+
Caso adicionemos mais switches a pilha, o Switch 1 continuará como master e o Switch 2 como standby na pilha VSF.
Referência
ArubaOS-CX Virtual Switching Framework (VSF) Guide 6200, 6300 Switch Series