Comware 7: Procedimento de Back-out

Segue abaixo uma dica bacana enviada pelo Paulo Roque…
Alguns Switches HPNs suportam uma funcionalidade de back-out que permite retornar a configuração ao um estado anterior com um único comando.  Basta salvar a configuração antes de iniciar o processo de mudança da configuração e em necessidade de retorno da configuração anterior por problemas de feature, planejamento e etc, basta retornar para a última configuração salva 😉

A vantagem é que minimiza erros em caso de problemas durante uma janela de mudança… 

 Funciona assim:

Salvar a configuração antes da alteração.

# <Switch>save current-config flash:change123.cfg

Fazer back-out

# <Switch> config replace file flash:change123.cfg

Obs: Em caso de dúvidas sobre o procedimento, sempre execute testes em laboratório, se possível 😉

Distância administrativa em equipamentos Comware

A tabela de roteamento dos Switches L3 e Roteadores, insere os destinos aprendidos manualmente (rotas estáticas ou redes diretamente conectadas) ou dinamicamente (aprendidos via protocolo de roteamento dinâmico).

 Para os casos de uma destino ser aprendido de diferentes formas, como por exemplo, o prefixo 192.168.1.0/24 ser aprendido via RIP e OSPF, o Roteador dará preferência para a rota com  Distância Administrativa de menor valor, no caso, o destino aprendido via OSPF terá preferência pelo valor 10 em detrimento do protocolo RIP com o valor 100 (nesse exemplo a rota eo gateway da rede que será inserido na tabela de roteamento será o aprendido via OSPF).Perceba que as rotas diretamente conectadas possuem a prioridade 0 (zero) e serão roteadas internamente pelo dispositivo.

 A Distância Administrativa possui apenas função local e não é compartilhada pelo protocolo de roteamento. Um detalhe importante a ser percebido é a diferença com os valores atribuídos para a distancia administrativa para Roteadores Cisco. Em todo caso para evitar problemas em cenários com mais de 1 protocolo de roteamento, altere a métrica  em um dos dois dispositivos.

Distância Adm. HP Serie ADistância Adm. Cisco
Directly Connected00
OSPF10110
IS-IS15115
STATIC601
RIP100120
OSPF ASE150110
OSPF NSSA150110
IBGP255200
EBGP25520
Unknown256255

Abraços a todos

Comware 7: Configurando TACACS em uma VPN-Instance (VRF)

Compatilho abaixo o script (comentado) para a autenticação de usuários em uma base remota para administração de um Roteador MSR 30-16. Os testes serviram para validar um Servidor ACS da Cisco para autenticação via TACACS em um Roteador HP. A diferença deste teste para as outras configurações é a utilização do TACACS dentro de uma vpn-instance (VRF).


Configuração
#
ip vpn-instance test
 route-distinguisher 1:1
 vpn-target 1:1 export-extcommunity
 vpn-target 1:1 import-extcommunity
! Criando a VRF “test”
#
super password level 3 simple s3nhasup3r
super authentication-mode scheme
#
telnet server enable
#
hwtacacs scheme acs
! Criando o esquema TACACS com o nome acs
primary authentication 192.168.1.10 vpn-instance test
!Configurando o IP do Servidor ACS para autenticação
primary authorization 192.168.1.10 vpn-instance test
!Configurando o IP do Servidor ACS para autorização
primary accounting 192.168.1.10 vpn-instance test
!Configurando o IP do Servidor ACS para contabilidade
nas-ip 172.16.1.1
!Endereço de IP do Switch cadastrado no ACS
key authentication teste123
! Chave para autenticação com o servidor ACS  com a senha"teste123"
key authorization teste123
key accounting teste123
user-name-format without-domain
! Encaminhamento do usuário sem o formato @dominio
#
domain acs
authentication login hwtacacs-scheme acs local
!Configurando a autenticação com TACACS e em caso de falha, a autenticação será local.
authorization login hwtacacs-scheme acs local
accounting login hwtacacs-scheme acs local
authentication default hwtacacs-scheme acs local
authorization default hwtacacs-scheme acs
accounting default hwtacacs-scheme acs
authentication super hwtacacs-scheme acs
accounting command hwtacacs-scheme acs
#
domain default enable acs
! Habilitando o dominio acs como default para auetnticação
#
interface Ethernet0/0
 port link-mode route
 ip binding vpn-instance test
 172.16.1.1 255.255.255.0
#
user-interface vty 0 4
authentication-mode scheme
#

obs: Sugerimos que durante os testes, não configure o authentication-mode scheme no acesso via Console, para em caso de falha nos testes, você não fique trancado do lado de fora do Switch.

A autenticação do “super-usuário” via TACACS também está inclusa no script.

Abração

Comware 7: QoS -Medição e Colorização (Coloring and Metering) – Modelo CIR/PIR

A utilização de Shapping e Policy em modelos de QoS permite o controle do tráfego utilizado em cima de uma banda disponível , mas finita. Ambos são mecanismos de medição e controle para diferentes classes, para atribuição de políticas ou acordos de níveis de serviço.

O modelo de traffic Shapping buferiza o tráfego que é excedente de acordo com as politicas estabelecidas/contratadas;  já o modelo de Policing descarta o tráfego que é excedente ou remarca o campo do pacote IP para cair em uma classe de serviço menos prioritária.

Para conseguir efetuar a medição do tráfego, um modelo bastante utilizado pelo mercado é o CIR/ PIR ( CIR – Committted Information Rate, e PIR – Peak Information Rate).

A função do CIR é garantir a banda (ou taxa de dados) contratada; e a função do PIR é a banda máxima (ou pico de dados) que possa ser utilizado no link. Geralmente este modelo é oferecido na venda de serviços para terceiros.

O modelo CIR/PIR  possui três modelos de interválos para tráfego de entrada onde cada um é associado  a uma cor. O tráfego dentro do CIR é colorido como verde , o tráfego entre o CIR e o PIR como amarelo e o tráfego acima do limite do PIR é colorido como vermelho, descritos na RFC 2698.

Uma vez estabelecido os limites de serviço, por exemplo, um serviço de 1024Kbps contratado como CIR e o PIR como  2048Kbps , o trafego dentro do CIR terá a garantia de banda de 1Mb, já o tráfego dentro do PIR não terá a garantia de encaminhamento ou talvez cobrado o “Mega” adicional de pacotes e bytes transferidos na faixa entre o CIR e o PIR;  para o trafego acima de 2Mb,  será categorizado como vermelho, e provavelmente será configurado uma politica de descarte de pacotes.

Segue abaixo um exemplo de configuração utilizando o CIR/PIR com Policy em um Switch HPN 5800 para controle de banda:

Configuração em um Switch HPN 5800

vlan 15
 name cliente-x
#
 traffic classifier cliente-x operator and
 if-match any
! Classifier dando match em todo o tráfego
#
traffic behavior cliente-x
 car cir 1024 pir 2048 green pass red discard yellow pass
! Configurando o CIR o PIR e permitindo o trafego green, yellow e descartando o red
 accounting byte
! Contabilizando o tráfego no formato bytes
#
 qos policy CLIENTE-X-BW-CONTROL
 classifier cliente-x behavior cliente-x
#
  qos vlan-policy CLIENTE-X-BW-CONTROL vlan 15 inbound
! Configurando a Policy à VLAN 15 para controle do tráfego do cliente
#

Comandos Display

<5800>display qos vlan-policy  vlan  15
  Vlan 15
  Direction: Inbound

   Classifier: cliente-x
     Matched : 0(Packets)
     Operator: AND
     Rule(s) : If-match any
     Behavior: cliente-x
      Committed Access Rate:
        CIR 1024 (kbps), CBS 64000 (byte), EBS 0 (byte), PIR 2048 (kbps)
        Green Action: pass
        Red Action: discard
        Yellow Action: pass
        Green : 34555(Packets) 89891278(Bytes)
        Yellow: 2(Packets) 2048(Bytes)
        Red   : 0(Packets) 0(Bytes)
      Accounting Enable:
        4967306 (Packets)

Conforme dito anteriormente, é possível remarcar os pacotes que estão como yellow e red para valores DSCP com prioridade menor…

[5800-behavior-cliente-x]remark ?
  atm-clp           Remark ATM CLP
  bfi               Remark BFI ID
  customer-vlan-id  Remark Customer VLAN ID
  dot1p             Remark IEEE 802.1p COS
  drop-precedence   Remark drop precedence
  dscp              Remark DSCP (DiffServ CodePoint)
  forwarding-class  Remark forwarding class
  fr-de             Remark fr-de
  green             Specify type of remark for green packets
  ip-precedence     Remark IP precedence
  local-precedence  Remark local precedence
  mpls-exp          Remark MPLS EXP
  qos-local-id      Specify QoS local ID feature
  red               Specify type of remark for red packets
  yellow            Specify type of remark for yellow packets

[5800-behavior-cliente-x]remark red ?
  atm-clp           Remark ATM CLP
  dot1p             Remark IEEE 802.1p COS
  dscp              Remark DSCP (DiffServ CodePoint)
  fr-de             Remark fr-de
  ip-precedence     Remark IP precedence
  local-precedence  Remark local precedence
  mpls-exp          Remark MPLS EXP

Com a coleta SNMP habilitada no Switch é possível contabilizar os bytes tráfegados em um servidor de coleta para venda de serviços on-demand, como internet por exemplo.

Obs: Para aqueles que estão acostumados com equipamentos Cisco, os dispositivos poderão trabalhar o modelo CIR/PIR da seguinte forma:
 – Menor ou igual ao CIR é chamado de “conform”
 – Acima do CIR e Menor ou igual ao PIR é chamado de “exceed”
 – Acima do PIR “violate”

Até a proxima! 😉

Referências:
QoS-Enabled Networks: Tools and Foudations – Miguel Barreiros e Peter Lundqvist – John Wiley & Sons

Cisco ONT – Offical Certification Guide –Amir Ranjbar – CiscoPress

Comware: DHCP Snooping

A funcionalidade DHCP Snooping permite a proteção da rede contra Servidores DHCP não autorizados e sua configuração é bastante simples. O comando dhcp-snooping configurado globalmente, faz o Switch filtrar todas as mensagens DHCP Offer e DHCP Ack encaminhadas pelo falso Servidor DHCP. A configuração restringe todas as portas do Switch como untrusted (não confiável).

Para o funcionamento do ‘Servidor DHCP válido’ deveremos configurar a porta do Servidor DHCP como trusted (confiável), incluíndo as portas de uplink.

Comware: Configurando o atributo MED em anúncios de prefixos BGP via route-policy

O propósito do atributo MED (ou MULTI_EXIT_DISC) é permitir que rotadores em um determinado AS digam a roteadores em outro AS a preferência de caminho para determinado prefixo. Apesar de conseguir manipular o “custo” de decisão do melhor caminho em outro AS, o MED não está no topo das escolhas de prioridades do protocolo, mas em diversos casos é muito eficiente.

Apesar de eu já ter utilizado o parâmetro algumas vezes, sempre me esqueço do comando correto e não consigo encontrar nos “Configure Guide” da vida em cenários com a aplicação do MED dentro de uma route policy. Uma das coisas mais legais de ter um blog é poder salvar assuntos que no futuro também facilitarão minha vida. 🙂

Voltando ao assunto… há a possibilidade de configurar o atributo MED direto no processo BGP (já para a versão7 do Comware a configuração deverá ser feita dentro do address-family).

Entretando, para configurar o MED dentro de uma route-policy o comando correto para atribuir um valor para o BGP Multi-Exit Discriminator é apply cost [valor MED].

route-policy SET_MED permit node 10
 if-match ip address prefix-list abc
 apply cost 1000

Seleção de rotas BGP antes do atributo MED

Segue abaixo a lista com a ordem para escolha da melhor rota na tabela BGP antes do atributo MED:

  1. Seleciona a rota com maior preferred_value (similar ao weight da Cisco).
  2. Seleciona a rota com maior Local_Pref.
  3. Seleciona a rota originada pelo roteador local.
  4. Seleciona a rota com menor AS-Path.
  5. Seleciona a rota baseado na prioridade de origem.
  6. Seleciona a rota com o menor MED.

Obs: Caso as opções de melhor preferência estejam com os mesmos atributos, o MED será a sexta opção para desempate.

Exemplo de Configuração

No cenário acima o roteador RB anuncia o prefixo 192.168.11.0/24 com o atributo MED com valor 10 e o roteador RC também anuncia o prefixo 192.168.11.0/24 mas com o atributo MED como 20.

Os Roteadores do AS 64500 comparam o menor MED e caso não exista melhor parâmetro para seleção, o atributo MED será escolhido para encaminhar o tráfego ao roteador (vence o menor valor MED).

Configuração do Roteador RB (com o Comware7)

#
ip prefix-list rede_192 index 5 permit 192.168.11.0 24
#
route-policy SET_MED_10 permit node 10
 if-match ip address prefix-list rede_192
 apply cost 10
#
bgp 64507
 peer 192.168.12.2 as-number 64500
#
 address-family ipv4 unicast
     peer 192.168.12.2 enable
     peer 192.168.12.2 route-policy SET_MED_10 export
#

Os roteadores do ASN 64500 terão em sua tabela BGP o seguinte cenário:

[RE]display bgp routing-table ipv4
 Total number of routes: 5
 BGP local router ID is 192.168.3.3
 Status codes: * - valid, > - best, d - dampened, h - history,
               s - suppressed, S - stale, i - internal, e – external
               Origin: i - IGP, e - EGP, ? - incomplete
     Network            NextHop         MED        LocPrf     PrefVal Path/Ogn
* >i 192.168.1.0        192.168.12.1    0          100        0       64507i
*  e                    192.168.13.1    0                     0       64507
  >i 192.168.2.0        192.168.2.2     0          100        0       i
* >i 192.168.11.0       192.168.12.1    10         100        0       64507i
*  e                    192.168.34.1    20                    0       64507i

Veja que a rota “best” em nosso cenário é o prefixo com menor valor do atributo MED.

Até logo!

Referências

CCIE Routing and Switching Certification Guide, 4th Edition, Cisco Press, Wendell Odom, Rus Healy, Denise Donohue

Roteadores MSR – Acesso OOB

Os Roteadores MSR possuem um módulo de interfaces para gerenciamento OOB (Out of band ) de equipamentos de rede. Para o funcionamento dessa rede OOB basta conectar um cabo RJ45 na porta Async do módulo do Roteador e a outra porta na porta console do Switch/Roteador em que deseja efetuar o acesso. A pinagem do cabo é conhecida como RollOver.

O Andre Gomes encaminhou o procedimento ao blog para acesso utilizando o módulo JF841 (HP 16p Async Serial Intrfc MIM A-MSR Module) em um Roteador MSR 30-20 da HP. “Segue abaixo uma breve explicação de como se faz para acessar a porta console de um equipamento através dos equipamentos de OOB (MSR30-20, por exemplo)”:

Configuração da interface Async

#
interface Async5/0
 async mode flow
 undo detect dsr-dtr
 link-protocol ppp
#
user-interface tty 81 96
 undo shell
 flow-control none
 redirect enable
 terminal type vt100

Efetuando o acesso OOB

telnet < ip do próprio device OOB que você está conectado > 208x

Esse comando é para acessar a porta console dos equipamentos que estão ligados a um router OOB (Out Of Band) como os MSR30-20, por exemplo.A sintaxe desse comando é a seguinte:

telnet <ip do próprio device OOB que você está conectado> 208x (onde o ‘x’ é o número da porta no qual o equipamento remoto está conectado adicionando mais um.

Exemplo: Você quer acessar o Roteador OOB01 com ip: 10.0.0.1 para acessar o Switch001. O switch001, por sua vez, tem a sua porta console conectada a porta 5/2 do nosso Roteador Out Of Band.

Então, para acessarmos a porta console do nosso Switch001, através do nosso Roteador OOB001 devemos fazer os seguintes passos:

– acesse o Roteador OOB001;

– após acessá-lo digite o comando: telnet 10.0.0.1 2083

Lembre-se: o ip 10.0.0.1 é o ip do próprio Roteador OOB01 e estamos usando a porta “virtual” 2083, porque o nosso Switch001 está conectado na porta 5/2 do OOB01 (x = porta OOB + 1; x = 2 +1; x=3)

Obs.: Para sair do equipamento após o acesso a porta console, como neste caso, utilize as teclas: “Ctrl+K”;

Comware: Configurando o atributo Preferred_value (weight) em anúncios de prefixos BGP via route-policy

O atributo BGP Preferred_value permite ao roteador examinar internamente as atualizações BGP decidir a rota preferêncial.

O atributo não é encaminhado nas mensagens BGP e possui apenas função local em um roteador. Para aqueles que estão acostumados a configuração do protocolo BGP em roteadores Cisco com IOS, a funcionalidade é idêntica a configuração BGP weight, que é proprietária.

Preferred_value é eficiente quando há a necessidade de manipular um destino na saída de um AS, em meio múltiplas rotas.

Vence a rota com maior valor do Preferred_value e é possível configurar valores entre 0 e 65535.

Por padrão os prefixos aprendidos via eBGP possuem o valor como 0 e o Preferred_Value é o parâmetro preferencial para escolha da melhor rota.

Seleção de rotas BGP

Segue abaixo a lista com a ordem para escolha da melhor rota na tabela BGP:

  1. Seleciona a rota com maior preferred_value (similar ao weight da Cisco).
  2. Seleciona a rota com maior Local_Pref.
  3. Seleciona a rota originada pelo roteador local.
  4. Seleciona a rota com menor AS-Path.
  5. ….

Exemplo de Configuração

No exemplo abaixo iremos manipular o roteamento do AS 64507 para o prefixo 2001:db8:3::/64 anunciado pelo AS 64500, para o roteador RA escolher o caminho via RC (next-hop 2001:db8:13::3). O exemplo de configuração é o mesmo para os prefixos IPv4.

Script de configuração de um roteador MSR com o Comware 7

ipv6 prefix-list abc index 10 permit 2001:DB8:3:: 64
! Configurando a prefix-list da rede 2001:db8::3/64
#
route-policy SET_PV permit node 10
 if-match ipv6 address prefix-list abc
 apply preferred-value 200
! Criando a route-map para aplicar o Preferred_value 200 a prefix-list abc
#
bgp 64507
 peer 2001:DB8:12::2 as-number 64500
 peer 2001:DB8:13::3 as-number 64500
 #
 address-family ipv6 unicast
  network 2001:DB8:1:: 64
  peer 2001:DB8:12::2 enable
  peer 2001:DB8:13::3 enable
  peer 2001:DB8:13::3 route-policy SET_PV import
! Aplicando a route-policy SET_PV para os prefixos aprendidos pelo peer
#

Verificando a tabela de roteamento

[RA]display bgp routing-table ipv6
 Total number of routes: 3

 BGP local router ID is 192.168.11.1
 Status codes: * - valid, > - best, d - dampened, h - history,
               s - suppressed, S - stale, i - internal, e – external
               Origin: i - IGP, e - EGP, ? - incomplete
* >e Network : 2001:DB8:2::                            PrefixLen : 64
     NextHop : 2001:DB8:12::2                          LocPrf    :
     PrefVal : 0                                       OutLabel  : NULL
     MED     : 0
     Path/Ogn: 64500i
* >e Network : 2001:DB8:3::                             PrefixLen : 64
     NextHop : 2001:DB8:13::3                           LocPrf    :
     PrefVal : 200                                      OutLabel  : NULL
     MED     : 0                                     
     Path/Ogn: 64500i
*  e Network : 2001:DB8:3::                             PrefixLen : 64
     NextHop : 2001:DB8:12::2                           LocPrf    :
     PrefVal : 0                                        OutLabel  : NULL
     MED     :
     Path/Ogn: 64500i

Veja que a rota “best” para o prefixo 2001:db8:3::/64 está com o Preferred_value como 200.

Até logo

Agendando o Reboot no Comware

O Kleber Coelho, enviou a dica abaixo na qual ele precisou mexer em uma configuração sensível no Switch HP 7510 que poderia gerar a perda da gerencia do equipamento.

Inicialmente ele salvou a configuração atual do Switch. Após isso, agendou o reboot para 10 minutos (em caso de perda da gerencia, o Switch reiniciaria e voltaria a ultima configuração salva), aplicou a configuração e após o sucesso dos comandos aplicados, ele cancelou o reboot.

A configuração do schedule reboot deverá ser feita no modo “user-view”

Segue o email do Kleber:

Diego, boa tarde, tudo bem?

Recentemente precisei bloquear da divulgação do OSPF um IP de gerência local em um HP-A7510.
Se for útil para você colocar no blog, sinta-se à vontade!

# salvando a configuração atual
save force
# gatilho de reboot para garantir a recuperação, 
# caso dê algo errado e perca o acesso 
schedule reboot delay 10
# criar ACL com redes bloqueadas
system
acl number 2500 name Remove_BOGON_OSPF
# rule deny source <IP> <Wildcard>
rule deny source 192.168.255.0 0.0.0.255
rule permit
# aplicar ACL na instancia OSPF
ospf 1
filter-policy 2500 export
# Se der algo errado e perder acesso, 
#     basta esperar  o equipamento reiniciar em 10 minutos.
# Se tudo der certo, salve e remova o agendamento de reboot.
save force
quit
quit
undo schedule reboot

Agradeço ao Kleber pela dica enviada.

Comware 7 – Autenticação de TACACS com Tac_plus

Galera, durante a criação de um laboratório para testes de autenticação com TACACS de Roteadores MSR com Comware7, utilizamos o Debian com o tac_plus como Servidor.

Segue abaixo os scripts utilizados:

#
# tacacs configuration file
# Pierre-Yves Maunier – 20060713
# /etc/tac_plus.conf
# set the key
key = labcomutadores
accounting file = /var/log/tac_plus.acct
# users accounts
user = student1 {
	login = cleartext "normal"
	enable = cleartext "enable"
	name = "Usuario Teste"
	service = exec {
	    roles="network-admin"
       }
}
user = student2 {
	login = cleartext "normal"
	enable = cleartext "enable"
	name = "Usuario Teste"
	service = exec {
	    roles="network-operator"	
        }
}

Configuração do Roteador MSR HP

wtacacs scheme tac
primary authentication 192.168.1.10
primary authorization 192.168.1.10
primary accounting 192.168.1.10
! endereço do servidor TACACS
key authentication simple labcomutadores
key authorization simple labcomutadores
key accounting simple labcomutadores
user-name-format without-domain
#
domain tac.com.br
authentication login hwtacacs-scheme tac local
authorization login hwtacacs-scheme tac local
accounting login hwtacacs-scheme tac local
#
domain default enable tac.com.br
#
user-interface vty 0 4
authentication-mode scheme

Até logo