Perguntas e Respostas: Comware – Portas Access/Trunk/Híbrida, LACP e STP.

Galera, essa semana recebi um email com algumas dúvidas sobre portas Trunk/Hybrid, Link Aggregation e STP. Achei que seria bacana responder na forma de post pois acredito que essas questões podem ser as dúvidas de mais pessoas.

Segue abaixo as questões editadas… sintam-se livres para interagir nos comentários.

Diego,
Se não for muito incomodo pra vc, consegue me responder as questões abaixo?

  1. Diferença do link aggregation em modo static e dynamic, quando usar um ou outro?

O Link-Aggregation permite  agregação de diversas interfaces Ethernet (portas físicas) para a criação de uma única porta lógica com o intuito de prover redundância e aumento de banda. As melhores práticas sugerem a negociação do protocolo LACP (802.3ad) entre os 2 equipamentos que desejam fechar a agregação de portas afim de evitar erros de cabeamento e certificar o meio físico em todo o tempo que o Link-Aggregation estiver ativo, além de agilizar a redundância em caso de falhas.

Mas há também cenários em que um dos equipamentos não utiliza o protocolo LACP  para agregação de links ou então o meio físico oferecido pelo Provedor de Serviços para comunicação Ethernet não permite o encaminhamento de alguns protocolos da camada de enlace como o LLDP, CDP, LACP, STP, etc. Então nesses cenários devemos usar o modo static, isto é, Link-aggregation configurado manualmente sem validação do meio e/ou equipamentos por um protocolo como 802.3ad. Se a porta estiver UP, o modo static irá encaminhar o tráfego, mesmo que o cabeamento esteja conectado em outro equipamento incorretamente.

  1. Diferença de portas trunk e hybrid, quando usar a hybrid?

Enquanto a porta configurada como access permite apenas o tráfego de quadros Ethernet sem marcação de tag 802.1Q, o que faz com que o Switch atribua a comunicação para aquela VLAN, a configuração Trunk e Hybrid permitem a utilização de várias VLANs em uma única porta. As portas configuradas como access são geralmente atribuídas para computadores, servidores, impressoras, etc.

A porta Trunk é utilizada para o encaminhamento e recebimento de tráfego Ethernet tagueado com o ID da VLAN mas com a exceção de permitir apenas uma VLAN não tagueada, dita explicitamente na configuração. Por padrão o tráfego não tagueado de uma porta trunk é direcionado para a VLAN 1 (mas isso pode ser modificado). As portas trunk são configuradas na comunicação entre Switches e também com Servidores que possuem Switches virtuais internos para VMs, etc.

Já a porta Hybrida permite encaminhar o tráfego de inúmeras VLAN tagueadas ou não. Por exemplo, se você precisa que o tráfego de duas máquinas que estão atrás de um HUB seja separado dinamicamente entre duas  VLANs diferentes, a configuração de porta hybrida permite que o Switch leia marcações como endereço MAC, 802.1p, cabeçalho IP e etc, para dinamicamente efetuar diferenciação do tráfego para as suas respectivas VLANs (lembrando que o tráfego nesse caso pode vir sem TAG das máquinas).

  1. O spanning tree é habilitado nas portas (uma a uma) ou no switch?

Para habilitar (ou desabiltar) o spanning-tree no Switch é preciso a configuração no modo global.

Apesar de ser o protocolo mais utilizado para prevenção de loop, o Spanning-Tree não se encaixa em todos os cenários de rede e o seu algoritmo  pode as vezes prejudicar a integração de diferentes ambiente. Nesse caso é possível adicionar algumas features individualmente nas portas para ajuste fino, como por exemplo o stp-edged port (portfast) ou então desabilitar o STP somente em determinadas portas. Mas cada caso deve ser estudado minuciosamente para evitar situações de loop.

  1. Diferença do spanning tree para o rapid spanning tree, quando usar o rapid spanning tree?

O Rapid Spanning-Tree (802.1w) é uma evolução do Spanning-Tree inicial (802.1d) com um significativa melhora no tempo de convergência e conectividade da rede.

Uma das grandes limitações do STP não foi corrigida na versão 802.1w que é o bloqueio de todos os caminhos redundantes como prevenção de Loop. Esse tipo de cenário acaba gerando ocasionando gargalos pois a empresa gasta uma quantidade significativa de dinheiro para a extensão de fibra redundante deixando um dos links sobrecarregados enquanto o outro está ocioso.

A versão Multiple Spanning-Tree (802.1s) permite a criação de instancias independentes do STP para balanceamento de VLAN permitindo a alteração do root para determinadas VLANs ou o custo para o root. O protocolo é um pouco complexo quando você deseja conectar grandes domínios 802.1s entre si, por exemplo estender a LAN de duas empresas, mas com um bom planejamento o protocolo torna-se uma ferramenta poderosa.

Todos os Switches HP baseados no Comware, ao habilitar o STP, iniciam a versão 802.1s. Caso você não faça nenhuma configuração de ajuste o 802.1s terá o comportamento da versão Rapid-Spanning Tree.

  1. Para habilitar o spanning tree, basta dar um enable stp na porta de uplink ou é necessario configurar algo a mais (ou quando habilitamos para a switch, já é aplicado para todas as interfaces)?

Ao habilitar o STP no Switch a configuração é atribuída a todas as portas e as mesmas iniciam o encaminhamento de BPDUs para prevenção de loop.

  1. Devo usar os mesmo comandos do stp (ex: “stp edged-port enable”, “stp cost”, ) quando utilizado o rstp?

Sim, o comando é o mesmo para as versões 802.1w e 802.1s

  1. Nas interfaces de uplink, entre switchs que nao sao cores, as portas stp devem ficar como DESIGNATED, PORT ROOT ou ALTERNATE PORT?

Tudo vai depender de quem será o Switch Root da sua rede. Se o Switch Core for o root, os uplinks do Switch Core estarão como DESIGNATED, já os Switches não-Core, conectados a ele, terão suas portas como ROOT PORT (melhor caminho para o Switch ROOT) ou ALTERNATE PORT (porta redundante bloqueada para prevenção de Loop)

  1. Em qual interface, dos switchs roots, devo usar o comando stp root-protection?

A configuração da porta como Root Guard permite à uma porta Designada a prevenção de recebimento de BPDU’s superiores, que indicariam outro Switch com melhor prioridade para tornar-se Root. A feature força a porta a cessar comunicação toda vez quem um Switch tiver o Priority ID mais favoravel para tornar-se Root, então o Switch Root isola assim o segmento para o Switch indesejado. Após encerrar o recebimento desses BPDU’s a interface voltará à comunicação normalmente

Essa feature é geralmente configurada em portas Designadas do Switch Root.

  1. Devo setar o comando “stp loop-protection” nas interfaces “ALTERNATE PORT” (caminho secundário) das switchs não core. Correto?

Correto, a configuração da porta como Loop Guard possibilita aos Switches não-Root, com caminhos redundantes ao Switch Raiz, a função de se  proteger contra cenários de loop na rede quando há falhas no recebimento de BPDU’s em portas ALTERNATE.

Quando uma porta ALTERNATE parar de receber BPDU’s ela identificará o caminho como livre de Loop e entrará em modo de encaminhamento ( imaginando que a porta Root  continue recebendo BPDU’s) criando assim um Loop lógico em toda a LAN. Nesse caso a feature deixará a porta alternativa sem comunicação até voltar a receber BPDU’s do Switch Root.

Obs: Dica! Simule as features em ambiente de laboratório antes de aplicar em uma rede de produção. Isso permitirá ao administrador conhecer melhor os cenários, equipamentos, falhas e troubleshooting.

Até logo.

Comware 7: interface range

Os Switches que suportam a versão 7 do Comware, permitem a configuração de grupos de interfaces de maneira muito similar a utilizada em Switches Cisco IOS.

Basta utilizar o comando interface range seguido das interfaces como no exemplo abaixo e assim as configurações serão replicadas para as interfaces selecionadas.

interface range GigabitEthernet 1/0/2 to GigabitEthernet 1/0/5
  port link-type trunk
  port trunk permit vlan all
  undo shut
  quit

Até logo

Vídeo: Comware – QinQ (802.1ad)

A feature QinQ (802.1q sobre 802.1q – 802.1ad ), conhecido também como Stacked VLAN ou VLAN sobre VLAN, suporta a utilização de duas TAGs 802.1Q no mesmo frame para trafegar uma VLAN dentro de outra VLAN – sem alterar a TAG original.

Para o cliente é como se o provedor de serviços tivesse estendido o cabo entre os seus Switches. Já para a operadora não importa se o cliente está mandando um frame com TAG ou sem TAG, pois ele adicionará mais uma TAG ao cabeçalho e removerá na outra ponta apenas a ultima TAG inserida.

Utilizar o Spanning-Tree, sim ou não?

Olá amigos, a idéia desse post partiu de uma discussão com um colega sobre a razão dele não utilizar e não confiar no Protocolo Spanning-Tree ao ponto de desabilitá-lo em todos os Switches da rede.

O administrador dessa rede sempre priorizou a idéia do controle total sobre a topologia, sem redundâncias com o argumento de que em caso de falhas na rede é preferível perder algumas dezenas de minuto na troca do suposto equipamento (ou meio físico defeituoso) ao invés de não conseguir identificar problemas de convergência na Topologia.

Nessa mesma rede que chamaremos de Empresa X, todos os UpLinks estão conectados no Switch Core com um único cabo, sem caminhos alternativos ou redundância. Então faço a seguinte pergunta: O administrador dessa rede está correto? Eu diria que sim… Se não houver redundância ou Loop Físico entre os Switches não há função para o Spanning-Tree.


Mas é possível possuir o controle total da rede? Podemos confiar que um usuário não irá conectar um “Switch Hub” na rede para prover mais pontos ou ligar sem querer um ponto de rede do equipamento no próprio Switch?

O Protocolo Spanning-Tree poderia ajudar o Administrador da Empresa X em casos como esse bloqueando o Loop físico e/ou permitindo a utilização de meios físicos redundantes como fibra, cabo UTP ou via Wireless.

Na prática se o Switch estiver com o Spanning-Tree habilitado, irá encaminhar BPDUs -mensagens geradas pelo Root da Topologia . A rede efetuaria a convergência com o mínimo de perda em caso de falhas no meio físico ou Switches, deixando a disponibilidade dependente apenas dos timers do Max Age e do Forward Delay.

Olhando o desenho, quem é o Switch Root da Rede?

Abraços

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.

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.

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

Comware: Route leaking – roteamento estático entre VRFs

A tradução literal para route leaking seria “vazamento de rotas” e esse tipo de configuração permite que determinadas configurações que isolam o roteamento de cada tabela de rotas, como a utilização de VRFs por exemplo, troquem roteamento entre as VRFs (vpn-instance).

Em posts anteriores, publicamos um artigo sobre o roteamento entre VRFs utizando MP-BGP em Switches e Roteadores HP baseados no Comware, mas nesse exemplo, a função é apenas permitir o roteamento entre as vpn-instances para algumas rotas.

Durante a configuração do “route leaking” lembre-se de planejar a configuração de rotas sempre pensando no tráfego bidirecional, isto é, configurando tambem as rotas de retorno.

O Overlapping de subredes nas VRFs pode também ser utilizado, mas requerem configurações de NAT inter-VRF ( ou inter-VPN instance NAT) que somente são suportados em roteadores.

Restrições

As rotas estáticas precisam do endereço do next-hop e há limitação para rotas diretamente conectadas no roteamento inter-VRF.

Para o roteamentro entre VLANs nas VRFs, utilize o MP-BGP.

Somente os roteadores  suportam a configuração de NAT para esse cenário (para os equipamentos baseados no Comware).

Configuração

No exemplo abaixo, o roteador possui duas VRF (vermelha e azul) que necessitam acessar 1 uma rede da outra VRF (lembrando que a utilização de VRFs permite o isolamento das tabelas de roteamento).

#
 ip route-static vpn-instance vermelho 192.168.3.0 24 vpn-instance azul 192.168.23.3
 ip route-static vpn-instance azul 192.168.1.0 24 vpn-instance vermelho 192.168.12.1
#

Obs: lembre-se que o roteamento de retorno tem que estar configurado nos roteadores R1 e R2 do exemplo.

Outra coisa bacana é que também é possível configurar o roteamento de uma VRF para a tabela global de um roteador.

802.3bt – Power Over Ethernet

O crescimento do mercado de dispositivos IoT e as mais recentes tecnologias de rede sem fio como Wifi 5 Wifi 6 (802.11ax) tem demandando uma atenção especial à escolha dos Switches com capacidade Power over Ethernet, tecnologia que combina envio de dados e energia elétrica sobre um único cabo Ethernet.

Ao eliminar a necessidade para cabos separados de dados e energia, o PoE fornece vantagens da simplicidade e economia de custos, além de adicionar novos recursos de controle de dispositivo inteligente.

Impulsionado pela necessidade dos novos dispositivos “Internet das coisas”, a tecnologia PoE evoluiu com o introdução do padrão IEEE 802.3bt. Esse novo padrão permite que Switches e dispositivos energizados operem acima de 30 Watts por porta, suportando agora de 60 até 90 Watts de PoE.

Padrões para Power Over Ethernet

Em 2003, o IEEE publicou o padrão 802.3af, que descreveu as características do Power over Ethernet (PoE) em até 15,4 W de energia, executando 10BASE-T e 100BASE-T. A energia é fornecida em dois dos quatro pares trançados nos cabos Cat 3 ou acima.

Em 2009, o IEEE introduziu o 802.3at, também conhecido como padrão PoE+. Esta atualização permitiu a entrega de até 30 W em 1000BASE-T suportado em CAT 5 ou 6. Enquanto o PoE + alterna suporte a dispositivos que requerem maior potência, o padrão também pode detectar dispositivos que exigem 13 watts ou menos para fornecer o nível de energia necessário.

Em 2013, o IEEE anunciou o grupo de estudo para a criação de 802.3bt, que definiu o PoE em quatro pares e inclui suporte para 10GBASE-T, 5GBASE-T e 2.5GBASE-T em CAT5e ou superior. Essa nova tecnologia usa todos os 4 pares em um cabo Ethernet para fornecer energia e dados no mesmo meio. O padrão IEEE 802.3bt foi finalizado em setembro de 2018 e define dois tipos de PoE:

• Tipo 3 que suporta até 60 Watts
• Tipo 4 que suporta até 90 Watts

Embora novos recursos tenham sido adicionados, a ideia é que o padrão funcione com dispositivos legados Tipo 1 e Tipo 2. Desde que o PSE seja capaz (em termos de potência) de suportar o PD e ambos sejam compatíveis com o padrão.

Dentre os novos dispositivos alimentados pelo padrão podemos destacar:

  • Edifícios inteligentes com IoT corporativa (iluminação LED conectada);
  • Cidades seguras (câmeras PTZ);
  • Quiosques;
  • Terminais de ponto de venda (POS)
  • Thin clientes
  • Access Points
  • Etc;

Referências

https://en.wikipedia.org/wiki/Power_over_Ethernet

Switches ArubaOS – Configurando Link Aggregation (trunk)

Os switches ArubaOS, em sua função, oferece um grande número de portas para a rede local. Com a utilização de interfaces Ethernet, isolam domínios de Broadcast e permitem uma topologia livre de loops.

Em diversos cenários, as funções básicas não são suficientes para que determinados serviços da rede local funcionem da maneira desejada.

Features, como o Link Aggregation, podem ser utilizadas para aumento de banda entre dois dispositivos ou fornecer alta-disponibilidade.

O “conceito” de agregação de portas permite o agrupamento lógico de diversas portas para incrementar a velocidade do link na comunicação full duplex entre dois dispositivos. Os links são utilizados em paralelo, provendo crescimento, expansão de banda e redundância, sem a necessidade de compra de um hardware adicional.

Por exemplo, podemos utilizar 4 portas de 1Gb em cada dispositivo para formar um link de comunicação entre 2 Switches de 4Gb.

A feature Link-Aggregation também evita os cenários com loop de quadros Ethernet entre dois dispositivos, evitando também os estados de bloqueios do Spanning-Tree para as portas agregadas, tratando-as como uma única interface. Assim para os protocolos STP, coleta SNMP e VLANs, as interfaces são tratadas como um único link lógico.

Configuração

Um ponto importante a ser levantado é que os Switches ArubaOS chamam a configuração de agregação de portas de “TRUNK”  e isso não tem relação com o conceito que outros sistemas operacionais como Comware e IOS, atribuem as portas que aceitam TAG de VLANs.

O conceito de trunk é atribuido na configuração como descrito abaixo:

ArubaOS-Switch(config)# trunk 20-23 trk1 lacp 
! Configurando as interfaces 20 a 23 para a interface TRUNK trk1 com a utilização do LACP
 

Os Switches ArubaOs nomeiam as interfaces Link-Aggregation como trunk e identificam cada interface TRUNK como trk[numero].

Para atribuir uma VLAN ao TRUNK, acesse a interface e diga quais VLANs são tagged e untagged:

ArubaOS-Switch(config)# vlan 220 tagged trk1
! Configurando o trafego da VLAN 220 como tagged no trk1
 

Cenário

Na topologia abaixo demonstramos a configuração de agregação de portas entre 2 Switches, as interfaces agregadas irão transportar as VLANs de 1 a 5.

desconecte todas as portas que você deseja adicionar ou remover do link aggregation. Depois de concluir a configuração do trunk, ative ou reconecte as portas.

Como alternativa, verifique se o STP está ativo no switch.

Comandos show

ArubaOS-Switch# show trunks

ArubaOS-Switch# show lacp

Até logo!