Switches ArubaOS-CX: Configurando VLANs

A utilização de VLANs (Virtual Local Area Network) permite que a rede seja dividida em várias redes lógicas dentro de um switch.Uma vez que há a necessidade de separar o tráfego de cada departamento da sua empresa por VLANs, você deverá atribuir cada porta do switch para a VLAN correspondente. Geralmente a configuração de VLANs em switches divide as portas em 2 grupos: portas de acesso e portas de uplink.

Para a comunicação entre os switches da rede (portas de uplink), configure as interfaces como trunk com as suas respectivas VLANs permitidas.

Para comunicação dos hosts conectados ao switch, configure as interfaces como access em sua respectiva VLAN.

Exemplo de configuração de VLANs nas portas de uplink:

Interface 1/1/x   
    vlan trunk allowed [VLAN-LIST | all] 

Exemplo de configuração de VLANs nas portas de acesso:

Interface 1/1/x
  vlan access [VLAN-ID]

No exemplo abaixo, demonstros a configuração do switch utilizando 2 VLANs na rede para segmentação das máquinas:

#ArubaCX1
vlan 1,3-4
!
interface 1/1/2
    vlan trunk native 1
    vlan trunk allowed 3-4
interface 1/1/3
    vlan access 3
interface 1/1/4
    vlan access 4
!
#ArubaCX2
vlan 1,3-4
!
interface 1/1/2
    vlan trunk native 1
    vlan trunk allowed 3-4
interface 1/1/3
    vlan access 3
interface 1/1/4
    vlan access 4
!

Dicas

Caso a porta apresente mensagem de erro durante a configuração da VLAN, como ‘Operation not allowed on an interface with routing enabled’, altere o modo de funcionamento da porta de L3 para L2 com o comando no routing.

ArubaCX1(config-if)# interface 1/1/11
ArubaCX2(config-if)# vlan access 4
Operation not allowed on an interface with routing enabled.
ArubaCX1(config-if)# no routing
ArubaCX2(config-if)# vlan access 4

Para validar a configuração das interfaces e VLAN, utilize os comandos show vlan e show interface brief, entre outros.

A configuração de vlan native é habilitada por default em todas as interfaces configuradas como trunk e ela indica para qual VLAN um quadro não-marcado com o ID da VLAN (untagged) será direcionado. Por padrão de mercado todos os pacotes não tagueados são direcionados para a VLAN 1 em uma porta trunk (uplink).

ArubaOS-CX: Instalando a versão 10.06 do Simulator no EVE-NG

A Aruba liberou a versão 10.06 do Aruba_AOS-CX_Switch_Simulator_10.06.0110 no portal ASP (Aruba Support Portal) https://asp.arubanetworks.com/.  Caso você não tenha permissão para baixar os arquivos, converse com o canal responsável por sua conta ou com o fabricante.

A instalação no EVE-NG é bem tranquila e similar com o procedimento escrito pelo time do Emulador: https://www.eve-ng.net/index.php/documentation/howtos/howto-add-aruba-cx-switch/

1. Faça o download da imagem Aruba_AOS-CX_Switch_Simulator_10.06.0110.zip.

2. Conecte via SSH no EVE como root, crie uma pasta temporária para cópia da imagem:

mkdir ArubaCX/
cd ArubaCX/

3. Faça o upload da imagem OVA para o EVE, via SCP (utilizando por exemplo o FileZilla ou WinSCP):

4. Extraia a imagem OVA para utilizarmos a imagem vmdk.

unzip Aruba_AOS-CX_Switch_Simulator_10.06.0110.zip
Archive:  Aruba_AOS-CX_Switch_Simulator_10.06.0110.zip
  inflating: ArubaOS-CX_OVA_ALA.PDF
  inflating: ArubaOS-CX_10_06_0110.ova
tar xvf ArubaOS-CX_10_06_0110.ova
arubaoscx-disk-image-genericx86-p4-20210316185909.ovf
arubaoscx-disk-image-genericx86-p4-20210316185909.vmdk

5. Converta o vmdk para o formato qcow2

/opt/qemu/bin/qemu-img convert -f vmdk -O qcow2 arubaoscx-disk-image-genericx86-p4-20210316185909.vmdk virtioa.qcow2

6. Crie uma pasta

mkdir /opt/unetlab/addons/qemu/arubacx-10.06

7. Mova a nova imagem preparada virtioa.qcow2 para o novo diretório

mv virtioa.qcow2 /opt/unetlab/addons/qemu/arubacx-10.06/

8. Remova o diretório temporário e corrija as permissões

cd
rm -rf ArubaCX
 /opt/unetlab/wrappers/unl_wrapper -a fixpermissions

Agora é só utilizar o ArubaOS-CX  no EVE-NG e simular o cenário que você ‘quiser’.

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

ArubaOS-CX: Entendendo o Checkpoint

A funcionalidade checkpoint nos Switches ArubaOS-CX é um registro da configuração em execução (running-config) do switch e seus metadados referentes ao tempo.

O checkpoint pode ser utilizado pelo administrador para aplicar a configuração armazenada em um ponto de verificação (checkpoint) escolhido quando necessário, como por exemplo, para reverter para uma configuração anterior.

Os switches ArubaOS-CX são capazes de armazenar vários pontos de verificação.

Um checkpoint da configuração pode ser gerado após 5 minutos de inatividade automaticamente (após uma mudança de configuração) ou então gerado pelo usuário administrador.

Para cada alteração de configuração, o contador de tempo limite é reiniciado.

O checkpoint gerado pelo sistema possuirá o formato CP<YYYYMMDDHHMMSS>.

Já o checkpoint gerado pelo usuário poderá utilizar um nome customizado para a configuração.

Para validar a os checkpoint gerados digite:

 SW-Access1# show checkpoint list
CPC20210223231221
CPC20210224020931
startup-config

Para gerar um checkpoint digite:

SW-Access1# copy running-config checkpoint TESTE1
Configuration changes will take time to process, please be patient.
! Gerando uma checkpoint chamado TESTE1

Após mudança na configuração e o desejo de mudança para a configuração anterior do checkpoint TESTE1, digite:

SW-Access1# copy checkpoint TESTE1 running-config 
Configuration changes will take time to process, please be patient.
! Copiando o checkpoint TESTE1 para a running-config

Para validar todos os checkpoint digite:

SW-Access1#  show checkpoint list all
|NAME                                              |TYPE                |WRITER              |DATE(UTC)                     |HARDWARE  
          |IMAGE VERSION       |
|CPC20210223231221                                 |checkpoint          |System              |2021-02-23T23:12:21Z          |6300      
          |FL.10.04.3031       |
|CPC20210224020931                                 |checkpoint          |System              |2021-02-24T02:09:31Z          |6300      
          |FL.10.04.3031       |
|startup-config                                    |startup             |User                |2021-02-24T02:14:40Z          |6300      
          |FL.10.04.3031       |
|TESTE1                                            |latest              |User                |2021-02-24T02:15:24Z          |6300      
          |FL.10.04.3031       |
		  

Todos os checkpoints gerados pelo usuário incluem um carimbo de data/hora para identificar quando um ponto de verificação foi criado.

No máximo 32 checkpoints podem ser gerados pelo usuário.

No máximo 32 checkpoint de sistema podem ser criados. Além desse limite, o checkpoint do sistema mais recente substitui o mais antigo.

Checkpoints e auto-rollback

Um recurso adicional é a reversão automática da configuração. Se antes de iniciar uma alteração na configuração, você inserir: checkpoint auto <número de minutos> e após expirar o tempo configurado, você será solicitado a confirmar as alterações. Caso contrário, ao final do período, a configuração voltará ao estado anterior ao que você configurou o checkpoint auto. Para este propósito, um ponto de verificação oculto é usado.

O principal objetivo desta opção é recuperar de um erro de configuração que desconectou você do dispositivo (especialmente se acessá-lo remotamente).

GUI

Para gerenciar o checkpoint no modo GUI:

Referências

https://community.arubanetworks.com/community-home/digestviewer/viewthread?MID=22966

https://techhub.hpe.com/eginfolib/Aruba/OS-CX_10.04/5200-6701/index.html#GUID-B43F99C4-8ADA-4934-9A6B-5DE0B20391FE.html