Comware: Rapid Spanning-Tree (802.1w)

Diego DiasLeave a comment

O protocolo Rapid Spanning-Tree é definido no padrão IEEE 802.1w para melhora no tempo de convergência do Spanning-Tree (802.1d) ,definindo regras para que os links alterem rapidamente ao estado de encaminhamento (forwarding), gerando mensagens BPDUs em vez de apenas retransmitir os BPDUs do Root, oferecendo uma significativa melhora no tempo de convergência da rede.

Uma das principais melhorias efetuadas no protocolo reduziu o tempo de convergência em caso de falha de 3 Hellos BPDU’s (por default 2 segundos cada Hello) ao invés de 10 Hellos BPDU’s na versão anterior do Protocolo.

O RSTP elege o Switch Root da mesma maneira que o 802.1d e o tempo de transição para o estado das portas foi reduzido com 3 operações básicas: Discarding, Learning e Forwarding

A rápida transição para o forwarding é permitida sem a necessidade de esperar o tempo da configuração, baseando-se na classificação dos equipamentos conectados nas portas do Switch.

  • Edge : porta conectada a computadores, telefones IP, impressoras etc.
  • Point-to-Point: porta conectada em outro Switch
  • Shared: Porta conectada a um Hub

Edge

As portas do Switch conectadas a computadores e servidores precisam de configuração manual para rápida transição do modo de discarding para o forwarding. 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.

[Sw] interface gigabitethernet 1/0/1
[Sw-GigabitEthernet1/0/1] stp edged-port enable

Obs: Se uma porta configurada como edge receber um BPDU, automaticamente voltará ao estado uma porta normal do STP 

Point-to-Point

Por default as portas RSTP conectadas e negociadas como Full Duplex entre Switches consideram-se point-to-point. A rápida transição é possível após a porta encaminhar um BPDU como Proposal e receber a confirmação do BPDU com um Agreement , esse processo é chamado de handshake ( na tradução literal, aperto de mãos).

e houverem Links redundantes na topologia a porta com caminho alternativo para o Switch Root ficará no estado de discarding e será considerada como uma Alternate Port.

Outra melhora na versão do protocolo ocorre durante mudanças na topologia, como por exemplo, quebra do caminho principal. Os Switches não terão que esperar o aviso do Switch Root para efetuarem a convergência da topologia (basta receber um TCN do Switch vizinho) e assim a porta com caminho alternativo poderá mudar imediatamente para o estado de encaminhamento.

Em testes práticos a convergência na quebra de um link chega a perder um PING.

Para habilitar o RSTP nos Switches H3C/3Com utilize o comando stp mode rstp

Rapidinhas

• Todo Switch vem de fabrica com o valor da Bridge priority como 32768, a eleição do Switch Root pode ser manipulada alterando o valor do bridge priority menor que o Valor padrão. Em caso de empate é utilizado o endereço MAC do equipamento.

• O estado de “bloqueio” das portas utilizado no Spanning-Tree (802.1d) é renomeado para estado de “descarte”(discarding). A função de uma porta de descarte é a de uma porta alternativa. A porta de descarte pode tornar-se uma porta designada se a porta do segmento falhar.

• As regras de Portas Root e Designadas são idênticas em ambas versões do STP

• Uma porta Root possui o melhor caminho para o Switch Root que é geralmente o caminho de menor custo. ( O Switch Root não possui porta Root)

• Uma porta Designada é porta que encaminha os BPDUs dentro de um segmento. ( Existente em Switches Root e não-Root)

• Alternate Port – porta bloqueada por ser um caminho alternativo para o Switch Root. A porta alternativa irá tornar-se root se a porta root falhar.

• Backup Port – porta bloqueada que recebe um BPDU de uma porta designada do mesmo segmento. (como por exemplo um cabo conectado do próprio Switch ou 2 conexões para o mesmo HUB)

• Utilize sempre os comandos display stp e display stp briefpara visualização dos estados das portas do STP.

• O protocolo 802.1w possui compatibilidade com o 802.1d

Abraços a todos!

Comware: OSPF – Comando Silent-Interface ( Passive Interface)

Diego DiasLeave a comment

Durante as configurações do processo OSPF para Switches, Servidores ou Roteadores, algumas redes precisam ser declaradas no OSPF, mas isso não significa que elas (precisarão) formar adjacência com outros Roteadores – ao inserirmos uma rede com o comando network o equipamento começará a trocar mensagens OSPF por aquela interface.

O fato da interface gerar mensagens pelo protocolo OSPF a deixa vunerável ao aprendizado de mensagens de outros equipamentos que podem por consequência inserir redes por engano ou de forma maliciosa  (perdendo assim o controle sobre o Roteamento da rede).

Nesse caso poderemos deixar as interfaces Físicas e VLANs em modo silencioso, sem gerar mensagens do protocolo para a LAN.

O comando silent-interface  (em Switches e Roteadores 3Com/H3C/HP ) seguido do numero da interface VLAN ou Interface física, permitirá ao Switch/Roteador não gerar mensagens LSA.

ospf 100
silent-interface Vlan-interface1
! Configurando a interface VLAN 1 em modo silent
area 0.0.0.0
network 192.168.1.2 0.0.0.0
network 172.31.0.1 0.0.0.0

! As melhores práticas sugerem configurarmos todas as interfaces
! como silent ( passive) e habilitarmos somente as VLANs/Interfaces
! de adjacência com o comando undo silent-interface + Interface

silent-interface all
! Configurando todas as Interfaces VLAN como silent
undo silent-interface Vlan-interface 2
! Removendo a interterface VLAN 2 do silent

Dúvidas? Deixe um comentário!

Abraços a todos!

Comware: Configurando espelhamento de VLANs (Traffic Mirroring)

Diego DiasLeave a comment

O espelhamento de VLANs é uma técnica que permite que o Switch efetue a cópia dos pacotes de uma VLAN para uma porta do Switch.

Essa técnica é bastante utilizada quando precisamos analisar o comportamento de alguma rede como por exemplo, para identificação de vírus, acessos “estranhos”, etc.

No cenário abaixo efetuaremos a cópia do tráfego da vlan 99 do Switch para o Servidor de Análise. A comunicação da VLAN 99 com qualquer host ou servidor da rede não será afetada pois o Switch direcionará apenas a cópia do tráfego!

Configuração

#
vlan 99
#
traffic classifier TRAFEGO operator and
if-match any
! Criando a política para dar match no tráfego, nesse caso, qualquer tráfego (any)
! ( é possível inclusive vincular uma ACL para filtrar o tráfego)
#
traffic behavior ESPELHAR
mirror-to interface Ethernet1/0/7
!  Criando o behavior para o espelhamento [para a interface Ethernet1/0/7]
#
qos policy ESPELHAMENTO
classifier TRAFEGO behavior ESPELHAR
! Vinculando o tráfego com o comportamento na policy
#
qos vlan-policy ESPELHAMENTO vlan 99 inbound
! Vinculando a policy para a vlan 99
#

No servidor de coleta poderíamos utilizar os Softwares TCPDump, Wireshark, etc para monitorar o tráfego.

Resumo sobre ACL para Switches e Roteadores baseados no Comware

Diego DiasLeave a comment

As ACL (Access Control List) são utilizadas para classificar tráfego para os mais diversos fins, como por exemplo, políticas de filtro de pacotes, QoS e PBR.

Uma ACL pode classificar um tráfego baseando-se no fluxo de dados que entram ou saem de uma interface (porta física, interface VLAN, VLAN, etc).

Na maioria dos casos uma ACL é utilizada para determinar se um pacote será permitido ou descartado em uma porta com as ações PERMIT ou DENY.

Essas ações são seguidas das definições DO QUE se deve permitir (PERMIT) ou negar (DENY). Estas, basicamente, são as principais opções:

ANY (tudo)
[IP do host/rede]
[subrede no formato wildcard]
[protocolo]

Imaginando de maneira prática, os Roteadores e Switches também podem utilizar como referência para classificação de tráfego as informações de cabeçalho de camada 2 (como endereço MAC), camada 3 (campos de cabeçalho IP) e camada 4 ( portas TCP e UDP).

Para uma ACL é possível adicionar diversas regras.  A leitura das regras pelo equipamento é efetuada linha por linha, de cima para baixo; e após a condição ser encontrada (match) o restante das regras não serão mais verificadas. A ordem para satisfazer uma condição, é lida na ordem em que as regras são configuradas.

O blog do CCNA faz o seguinte comentário para a utilização de uma ACL para filtro de pacotes (lembrando que uma ACL pode incluir diversas regras):

A regra básica diz que somente UMA ACL pode ser aplicada em uma mesma interface e direção, em um determinado router (ou switch). Ou seja, em uma mesma interface você até pode ter mais de uma ACL, desde que em sentidos opostos. Os sentidos possíveis são ilustrados no diagrama abaixo.

(IN) entrante —–> ROUTER ——> sainte (OUT)

Tipos de ACL

Os equipamentos baseados no Comware permitem três tipos de ACL:

  • Camada 2: Especificam regras baseadas em endereços MAC de origem, destino, VLAN e tipos de protocolo Ethernet.
  • Camada 3(básica): Especificam regras baseadas em endereços IP e rede de origem.
  • Camada 3 (Avançada): Especificam regras baseadas em protocolos de camada 3, redes de origem e destino; e portas de origem e destino.

Definindo a ACL

A definição do template para a configuração das Listas de Acesso é baseado pelos números,que a identificam:

  • ACL Básica: número 2000 a 2999
  • ACL Avançada: número de 3000 a 3999
  • ACL de camada 2: número de 4000 a 4999

ACL Básica

Baseia-se no endereço de rede de origem para filtrar ou permitir o tráfego.

Imaginando que você deseja filtrar quais máquinas podem efetuar efetuar Read and Write via SNMP em um Switch…

acl number 2100
! Criando a ACL 2100
rule permit source 172.31.1.100 0.0.0.0
! Criando a primeira regra na ACL 2000 permitindo a rede 172.31.1.100
! com 32 bits (máscara de host para somente uma máquina gerenciar o Switch via SNMP)
quit

snmp-agent community write comutadores acl 2100
! Vinculando a ACL 2100 na communty SNMP RW “comutadores”

A regra acima irá permitir o acesso SNMP  somente ao host  172.31.1.100, o restante da rede terá o acesso negado para coleta SNMP nesse equipamento.

Obs: Apesar do exemplo acima ser bem simples, uma ACL básica  também pode ser configurada para filtrar pacotes que entram ou saem do Roteador com a política baseada na rede de origem.

ACL Avançada

A diferença entre uma ACL básica e avançada é a forma de relacionamento com as informações no cabeçalho IP. A ACL avançada utiliza os campos de endereço IP de origem e destino, porta e número de protocolo diferenciando pacotes como TCP e UDP.

Alguns parâmetros especiais poderão ser utilizados na construção de uma ACL avançada:

  • Endereço IP de origem
  • Endereço IP de destino
  • Porta de origem
  • Porta de destino
  • Tipo de pacote ICMP
  • Parâmetro SYN do TCP
  • Valor IP Precedence
  • Valor DSCP
  • Valor TOS
  • Fragmentos

Abaixo segue o exemplo de uma ACL avançada criada e aplicada em uma interface do Roteador  HP 6600 para filtro de pacotes na entrada da interface Giga3/2/1

firewall enable slot 3
 !  Habilitando o filtro de pacotes no slot3 do roteador
 firewall default deny slot 3
! Habilitando uma regra de deny implícito após a configuração manual da última regra da ACL 

acl number 3030 name INTERNET-INBOUND
! Criando a ACL 3030 e atribuíndo o nome de "INTERNET-INBOUND"
 rule 10 permit icmp destination 200.200.200.0 0.0.0.255
! permindo os pacotes com o ip dentro do range 200.200.200.0/24 no cabeçalho de destino com wildcard
 rule  deny ip source 10.0.0.0 0.255.255.255
 rule  deny ip source 172.16.0.0 0.15.255.255
 rule  deny ip source 192.168.0.0 0.0.255.255
 rule  deny ip source 127.0.0.0 0.255.255.255
! negando qualquer pacote com ip de origem dentro do range da RFC 1918 
 rule 60 deny ip source 0.0.0.0 0.255.255.255
! negando qualquer pacote com ip de origem como 0.0.0.0
 rule 9999 permit ip
! permitindo qualquer endereço IP de origem e destino
 quit
 #
acl number 3040 name INTERNET-OUTBOUND
 rule  deny ip source 10.0.0.0 0.255.255.255
 rule  deny ip source 172.16.0.0 0.15.255.255
 rule deny ip source 192.168.0.0 0.0.255.255
 rule deny ip destination 224.0.0.0 15.255.255.255
 rule deny ip source 224.0.0.0 15.255.255.255
#
 interface GigabitEthernet3/2/1
 port link-mode route
 firewall packet-filter name INTERNET-INBOUND inbound
 firewall packet-filter name INTERNET-OUTBOUND outbound
! Aplicando a ACL para filtro na entrada e saída de pacotes
 ip address 123.123.123.218 255.255.255.252
 #

Segue um segundo exemplo de ACL avançada mas dessa vez em Switches do modelo 4800

acl number 3000
! Criando a ACL 3000
rule permit ip source 172.31.1.0 0.0.0.255 destination 192.168.1.0 0.0.0.255
! Criando a primeira regra na ACL 3000 permitindo a rede 172.31.1.0 com 24 bits (máscara
/24) efetuar comunicação IP com a rede 192.168.1.0/24 
rule deny ip source any
! Criando a segunda regra na ACL 3000 negando qualquer rede de origem
quit
#
interface vlan 2
ip address 192.168
packet-filter 3000 inbound
!Aplicando a ACL 2000 para filtro na interface VLAN.

Obs: Para aplicarmos uma ACL em  Portas físicas ou interface VLAN de um Switch é utilizado o comando packet-filter, já para roteadores, comando poderá ser incrementando com a sintaxe “firewall packet-filter….”

A regra acima irá permitir a comunicação IP, da rede 172.31.1.0/24 para a rede 192.168.1.0/24, o restante do tráfego terá o acesso negado.

Se precisarmos utilizar outros parâmetros para match da ACL podermos utilizar o caracter ? após o permit ou deny. Parâmetros como TCP, UDP, ICMP e etc poderão também ser utilizados

O exemplo abaixo exemplifica a utilização de parâmetros de portas TCP para criarmos a regra, como por exemplo permitir o acesso somente a serviços que realmente serão utilizados.

O restante do tráfego será negado, provendo maior segurança e escalabilidade pela utlilização de diversas VLANs.

[4800-acl-adv-3020] rule permit tcp source 172.31.1.0 0.0.0.255 destination 192.168.1.0 0.0.0.255 destination-port eq 80

ACL de camada 2

As ACL que utilizam parâmetros da camada de enlace do modelo de referencia OSI, poderão ser utilizadas para filtrar baseando-se em campos como ID da VLAN, mascara de endereços MAC (os primeiros bits são reservados para endereço dos fabricantes) , tipos de Protocolos,etc.

acl number 4999
 rule 0 permit type 8868 ffff
 rule 1 permit source 00e0-bb00-0000 ffff-ff00-0000
 rule 2 permit source 0003-6b00-0000 ffff-ff00-0000
 rule 3 permit source 00e0-7500-0000 ffff-ff00-0000
 rule 4 permit source 00d0-1e00-0000 ffff-ff00-0000
 rule 5 permit source 0001-e300-0000 ffff-ff00-0000
 rule 6 permit source 000f-e200-0000 ffff-ff00-0000
 rule 7 permit source 0060-b900-0000 ffff-ff00-0000
 rule 8 deny dest 0000-0000-0000 ffff-ffff-ffff

Obs: a configuração e o tipo de ACL disponivel em cada equipamento pode sofrer pequenas variações ou limitações na configuração. Sempre faça um teste antes de aplicar  a ACL em  um ambiente de produção.

Até logo.

Referência               

http://blog.ccna.com.br/2007/10/21/tutorial-basico-acls-para-o-exame-ccna/

http://blog.ccna.com.br/2012/11/21/wildcards-x-mascaras-de-rede/

Comware7: Configuração básica para BGP

Diego DiasLeave a comment

As configurações do BGP via CLI para os equipamentos baseados no Comware 7 diferem um pouco em relação aos Switches e Roteadores baseados no Comware 5.

Basicamente para o Comware 7, uma vez dentro do processo BGP, basta habilitar o ‘peering’ com o roteador vizinho normalmente, mas a grande diferença está no anuncio de prefixos, pois uma vez que você necessite anunciar prefixos IPv4 ou IPv6, será necessário entrar no address-family, ativar o peering e aplicar o comando network, import (redistribute) etc.

Para ficar mais fácil, veja o exemplo abaixo o peering eBGP entre o Roteador R1 (AS 100) e R4 (AS 400):

<R1> display current-configuration configuration bgp
bgp 100
peer 10.0.0.2 as-number 400
#
 address-family ipv4 unicast
    network 192.168.1.0 255.255.255.0
    peer 10.0.0.2 enable 
   
<R4> display current-configuration configuration bgp
bgp 400
peer 10.0.0.1 as-number 100
#
 address-family ipv4 unicast
  network 192.168.2.0 255.255.255.0
  peer 10.0.0.1 enable

O ponto mais importante dessa configuração é definir o IPv4 unicast address family e ativar o peer. Perceba que as redes deverão ser anunciadas dentro do address family correto.
Para validar o peering:

<R1>display bgp peer ipv4 unicast
BGP local router ID: 192.168.1.1
Local AS number: 100
Total number of peers: 1 Peers in established state: 1
* - Dynamically created peer
Peer     AS   MsgRcvd MsgSent OutQ PrefRcv Up/Down State
10.0.0.2 400   125     118     0    2       01:47:39 Established

IPv6
O mesmo vale se o peering e/ou prefixos for para endereços IPV6

<R4>display current-configuration configuration bgp
#
bgp 400
 peer 2001:DB8:14::1 as-number 100
 #
  address-family ipv6 unicast
   network 2001:DB8:4:: 64
   network 2001:DB8:44:: 64
   peer 2001:DB8:14::1 enable

Para validar o peering BGP com endereço IPv6:

 <R4>display bgp peer ipv6 unicast
 BGP local router ID: 192.168.44.4
 Local AS number: 400
 Total number of peers: 1          Peers in established state: 1
  * - Dynamically created peer
Peer             AS  MsgRcvd  MsgSent OutQ PrefRcv Up/Down  State

2001:DB8:14::1   100 60       60      0     2 00:47:40 Established

Para validar a tabela BGP basta preencher conforme o output abaixo: IPv4, IPv6, vpnv4, vpnv6, etc..

<R4>display bgp routing-table ?
  dampened   Display dampened BGP routes
  flap-info  Display BGP route flap information
  ipv4       Specify the IPv4 address Family
  ipv6       Specify the IPv6 address Family
  vpnv4      Specify the VPNv4 address family
  vpnv6      Specify the VPNv6 address family

Até logo.

Configurando Link-Aggregation/Etherchannel entre Cisco IOS e HP Comware

Diego DiasLeave a comment

A agregação de diversas interfaces Ethernet (portas físicas) para a utilização de uma única porta lógica com o intuito de prover redundância e aumento de banda é uma atividade muito comum em redes de médio e grande porte .

Infelizmente o nome atribuído pelos fabricantes não segue um padrão, mas por outro lado todos possuem as mesmas funções citadas anteriormente:Etherchannel, Port-channel, Link-Aggregation, Bridge-Aggregation, Trunk  [ nome dado antigamente para agregação de portas. (Não confundam com a utilização de interface Trunk atribuída pelos Switches Cisco e 3Com. Os Switches Procurve ainda utilizam essa terminologia) ]  e etc.

Existem algumas formas de estabelecer a agregação de portas, como por exemplo:

– Manual : sem a certificação do meio por protocolos auxiliares
– PAgP : Protocolo disponível em equipamentos Cisco
– LACP : Protocolo padrão IEEE,  disponível quase todos Switches gerenciáveis.

Modos de formação de um Etherchannel em Switches Cisco

Cisco(config-if)# channel-group 1 mode ?
  active Enable LACP unconditionally
  auto       Enable PAgP only if a PAgP device is detected
  desirable  Enable PAgP unconditionally
  on         Enable Etherchannel only
  passive    Enable LACP only if a LACP device is detected

No Script abaixo mostraremos a configuraçaõ de Link Aggregation/Etherchannel entre um Switch Cisco IOS e um Switch HP baseado no Comware:

Switch Comware

#
interface Bridge-aggregation 1
link-aggregation mode dynamic
! Estabelecendo a conexão do Link-Aggregation utilizando o protocolo LACP
#
interface gigabitEthernet 1/0/1
port link-aggregation group 1
! Atribuindo a porta para negociar a agregação via protocolo LACP
#
interface gigabitEthernet 1/0/2
port link-aggregation group 1
! Atribuindo a porta para negociar a agregação via protocolo LACP

Switch Cisco IOS

!
interface port-channel 1
!
interface gigabitEthernet 1/10
channel-group 1 mode active
! Estabelecendo a conexão do Etherchannel utilizando o protocolo LACP
!
interface gigabitEthernet 1/11
channel-group 1 mode active
! Estabelecendo a conexão do Etherchannel utilizando o protocolo LACP
!

Comandos Show e Display

Switch Comware

[HPN]display link aggregation verbose
Aggregation Interface: Bridge-Aggregation1
Aggregation Mode: Dynamic
Loadsharing Type: Shar
System ID: 0x8000, 3822-d6a2-5c00

Local:
  Port             Status  Priority Oper-Key  Flag
----------------------------------------------------
GE1/0/1       S       32768    8         {ACDEF}
GE1/0/2       S       32768    8         {ACDEF}

Remote:
Actor Partner Priority Oper-Key SystemID Flag
------------------------------------------------------------
GE1/0/1 516 32768 45 0x8000, 4055-39d4-8e13 {ACDEF}
GE1/0/2 517 32768 45 0x8000, 4055-39d4-8e13 {ACDEF}

Switch Cisco IOS

Cisco#show etherchannel summary
Flags:  D - down        P - bundled in port-channel
        I - stand-alone s – suspended
        H - Hot-standby (LACP only)
        R - Layer3      S - Layer2
        U - in use      f - failed to allocate aggregator
        M - not in use, minimum links not met
        u - unsuitable for bundling
        w - waiting to be aggregated
        d - default port
Number of channel-groups in use: 2
Number of aggregators:           2
Group  Port-channel  Protocol    Ports
------+-------------+-----------+--------------------------
1     Po1(SU)        LACP      Gi1/10(P)  Gi1/11(P)

Não esqueça!!!

Sempre quando for necessario a alteração de VLANs das portas do Link Aggregation/Etherchannel faça a alteração somente na interface virtual ( port channel/ bridge-aggregation), que a configuração será replicada para as interfaces físicas.
Mantenha a consistência de VLANs nas 2 pontas do Link Aggregation/Etherchannel.

Use velocidades de portas idênticas como: interfaces 1Gb com interfaces 1G e interfaces 10Gb com interfaces 10Gb e assim por diante…

Comware 7: QoS – Configurando hierarchical CAR

Diego DiasLeave a comment

A configuração de hierarchical CAR permite agregar inúmeras políticas de “limitação de banda” e compartilhar sobre uma única “grande” banda.

Dependendo do modo de configuração, a limitação de banda dos perfis (traffic classifier + traffic behavior) de “QoS” flutuará até atingir o limite do hierarchical CAR.

Imaginando que no cenário abaixo um Cliente quer limitar a banda de HTTP em 128Kbps e o “restante do tráfego” em 64Kbps. Como a banda contratada foi de 256Kbps, o trafego HTTP poderá usar 192Kbps caso o “restante do tráfego” esteja em 64kbps; ou o “restante do tráfego” poderá utilizar 128Kbps caso o HTTP não passe de 128Kbps.


Configuração

vlan 3
#
qos car CLIENTE-A hierarchy cir 256
! Configurando o hierarchy CAR como 256kbps
#
acl number 3001 name MATCH_WWW
 rule 0 permit tcp destination-port eq www
! Selecionando o tráfego HTTP como destino
#
traffic classifier MATCH_HTTP operator and
 if-match acl name MATCH_WWW
! Classificação do tráfego da ACL  MATCH_WWW
!
traffic classifier MATCH_ANY operator and
if-match any
! Classificação para qualquer tipo de tráfego
#
traffic behavior 128kbps-BW
car cir 128 hierarchy-car CLIENTE-A mode or
! Comportamento para limitar a banda em 128Kbps vinculado ao hierarchy-car
traffic behavior 64kbps-BW
car cir 64 hierarchy-car CLIENTE-A mode or
! Comportamento para limitar a banda em 64Kbps vinculado ao hierarchy-car
#
qos policy BW-CLIENTE-A
classifier MATCH_WWW behavior 128kbps-BW
classifier MATCH_ANY behavior 64kbps-BW
! Criando Policy para vincular os classifier + behavior
#
interface GigabitEthernet1/0/15
port link-mode bridge
port access vlan 3
qos apply policy BW-CLIENTE-A inbound
qos apply policy BW-CLIENTE-A outbound
! Aplicando a Policy à interface no sentido de entrada e saída

Para a verificação da banda e scripts utilizados use os comandos display  qos car name [nome do hierchical car] ou display qos policy interface [nome da interface] [ inbound | outbound ]

Modos AND e OR

Por padrão, o hierarchical CAR funciona no modo OR no qual um fluxo pode passar o limite aplicado a ele desde que não ultrapasse o limite do hierarchical CAR. Como, por exemplo, o cenário dado nesse post.

Já o modo AND o fluxo não pode passar o limite aplicado e a soma dos 2 não pode passar o limite total do hierarchical CAR. Por exemplo, 2 fluxos configurados com 128Kbps e o hierarchical CAR configurado com 192kbps. Cada fluxo individualmente não poderá passar da banda total contratada (192Kbps) e caso haja banda disponível e o total de cada fluxo será de 128Kbps (se houver banda disponível).

Até logo!