Galera, a Aruba criou alguns guias para provisionamento de laboratórios para estudo e testes do Switch ArubaOX-CX para uso no GNS3, Virtual Box e EVE-NG
Nesse video, montamos um laboratório no EVE-NG com Switches ArubaOS-CX demonstrando a configuração do Spanning-Tree e das funcionalidades Root-Guard e Loop-Guard.
Root Guard: A configuração da porta como Root Guard permite à uma porta Designada a prevenção do recebimento de BPDU’s superiores, que indicariam outro Switch com melhor prioridade para tornar-se Root, forçando a porta a cessar comunicação, isolando assim o segmento. Após encerrar o recebimento desses BPDU’s a interface voltará à comunicação normalmente.
Loop Guard: A configuração da porta como Loop Guard possibilita aos Switches não-Root, com caminhos redundantes ao Switch Raiz, evitar situações de Loop na falha de recebimentos de BPDU’s em portas com caminhos redundantes. Em um cenátio atípico, quando uma porta alternativa parar de receber BPDU (mas ainda UP) ela identificará o caminho como livre de Loop e entrará em modo de encaminhamento criando assim um Loop lógico em toda a LAN. Nesse caso a funcionalidade deixará a porta alternativa sem comunicação (como blocking em loop-inconsistent) até voltar a receber BPDU’s do Switch Root
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.
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.
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.
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.
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
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.
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