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:

https://techhub.hpe.com/eginfolib/Aruba/OS-CX_10.04/5200-6704/index.html#GUID-CDF72645-BB14-41DE-B0B6-4404A42E46FD.html

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 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