Dica: Comware – Desconectando um usuário travado (free user-interface)

O TBrecci nos enviou uma dica para desconectar um usuário travado em uma conexão SSH durante o ajuste do AAA. O procedimento pode ser utilizado em qualquer outra situação.

A histório era que estava tentando aplicar o TACACS no equipamento. Para isso, criei um outro domain, me conectei por ele, para somente assim alterar a autenthicação do domain system. Porém o bichinho reclamava quando tem alguém conectado no outro domain, e não deixava fazer a modificação.

Neste caso, era a minha propria conexão de outro Putty que estava impedindo.

No exemplo abaixo o usuário netwsuporte estava travado na VTY 0

[Switch]display users

The user application information of the user interface(s):
  Idx UI      Delay    Type Userlevel
  20  VTY 0   00:22:16 SSH  3
+ 21  VTY 1   00:00:00 SSH  3
Following are more details.
VTY 0   :
        User name: netwsuporte
        Location: 192.168.219.62
VTY 1   :
        User name: [email protected]
        Location: 192.168.219.62
+    : Current operation user.
F    : Current operation user work in async mode.
[Switch]

Abaixo a desconexão do usuário conectado na VTY 0
 

<Switch> free user-interface vty 0
Are you sure to free user-interface vty0? [Y/N]:y
[OK]

<Switch> display users

The user application information of the user interface(s):

  Idx UI      Delay    Type Userlevel
+ 21  VTY 1   00:00:00 SSH  3

Following are more details.
VTY 1   :
        User name: [email protected]
        Location: 192.168.219.62+    
     
     : Current operation user.

F    : Current operation user work in async mode.

<Switch>

Abração

Networktest:HP-Cisco Switching and Routing Interoperability Cookbook

Galera, saiu mais um cookbook para interoperabilidade entre equipamentos de rede Cisco x HP, com o Sistema Operacional IOS, Comware e Provision. Dessa vez pela equipe do Networktest.

Para acesso clique em http://networktest.com/hpiop/hpiopcookbook.pdf

O documento (em inglês) apresenta exemplos de configuração dos seguinte protocolos:

– BGP
– CDP
– LACP
– LLDP
– PIM-SM
– IGMP
– OSPFv2 (para redes IPv4)
– OSPFv3 (para redes IPv6)
– STP, RSTP, PVST+ e MST
– VRRP
– 802.1Q (VLANs)

Obs: se o link estiver quebrado deixe um comentário.

abração

Comware: Custo OSPF

O protocolo OSPF permite a todos roteadores em uma área a visão completa da topologia. O protocolo possibilita assim a decisão do caminho mais curto baseado no custo que é atribuído a cada interface, com o algoritmo Dijkstra. O custo de uma rota é a soma do custos de todas as interfaces de saída para um destino. Por padrão, os roteadores calculam o custo OSPF baseado na fórmula Cost =Reference bandwidth value / Link bandwidth.

Caso o valor da “largura de banda de referência” não seja configurado os roteadores usarão o valor de 100Mb para cálculo. Por exemplo, se a interface for 10Mb, calcularemos 100Mb dividido por 10Mb, então o custo da interface será 10. Já os valores fracionados, serão arredondados para valor inteiro mais próximo e toda velocidade maior que 100Mb será atribuido o custo 1.

Veja no exemplo abaixo:

OSPF Cost 1 Comware

O custo do Roteador R1 para os Roteadores vizinho é 1.

OSPF Cost 1 output Comware

O mesmo para a interface loopback de R2 (o comware não adiciona o custo para as interfaces loopback)

OSPF Cost 2 output Comware

Se por algum motive houver a necessidade de manipulação do roteamento para a interface Ge0/0/3(Roteador R3) basta aumentar o custo do OSPF na interface Ge0/0/2 para que a interface Ge0/0/3 tenha o menor custo para a rede 2.2.2.2.

Interface GigabitEthernet0/0/2
ospf cost 20
! Alterando o custo da interface para 20

OSPF Cost 2 Comware
OSPF Cost 3 output Comware

Caso seja necessário alterar a referência para largura de banda utilize o seguinte comando em um roteador HP Comware.

OSPF Cost 4 output Comware

O “bandwidth- reference 100” é o default para 100Mb, onde 100Mb na topologia tem o custo = 1 .

Assim, para ter links 1G com o custo = 1 , o “auto-cost…” deve ser configurado como 1000. Se a referência for links 10G , “auto-cost…” seria 10000 , para 100G, seria 100000 .

Obs: Lembre-se de sempre manter o bandwidth- reference consistente em todos os roteadores para evitar comportamentos inesperados no roteamento.

Até logo

Apaguei sem querer a imagem do Switch, e agora?

Durante o processo de boot de um Switch HP / 3Com / H3C, a imagem do Switch (Sistema Operacional [Comware]) e o arquivo de configuração são copiados da memória Flash para a memória RAM. As vezes durante a manipulação dos arquivos da Flash, acidentalmente podemos deletar  algum desses arquivos que não afetarão o funcionamento do Switch imediatamente enquanto o mesmo estiver ligado, mas  quando ocorre novamente o processo de boot de um Switch (após reiniciar o equipamento por exemplo), o Switch não encontrará os arquivos do Cowmare e ficará em loop no processo de boot (o mesmo pode ocorrer se a imagem estiver corrompida).

Quando acontecer esse tipo de acidente, tente executar o procedimento abaixo:

Primeiro, se você não tiver a cópia da imagem que foi apagada em algum outro lugar da flash ou repositório, tente baixar no site da HP alguma versão mais atualizada do Comware para o Switch citado.

Segundo, como o processo de boot fica em loop sem a imagem principal, digite Crtl + B para cair no Boot menu (…quando o Switch solicitar)

1. Download application file to flash
2. Select application file to boot
3. Display all files in flash
4. Delete file from flash
5. Modify BootRom password
6. Enter BootRom upgrade menu
7. Skip current system configuration
8. Set BootRom password recovery
9. Set switch startup mode
0. Reboot

faça o Download da nova imagem no equipamento com a opção 1;  depois atualize o arquivo que o Switch irá chamar no boot com a opção 2 (você precisará de um programa FTP ou TFTP).

Se tiver algum arquivo para atualizar o bootrom (.btm), utilize o passo 6.

Dica

 Os switches baseados no Comware utilizam as principais extensões abaixo:

• .bin ou .app : é a imagem do Switch, o Sistema Operacional do dispositivo
• .cfg ou .def: são arquivos de texto contendo as configurações salvas
• .web: pacote para administração do Switch por HTTP
• .btm : arquivo do bootrom responsável pelo boot da Sistema Operacional

Abração

Dica: 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. 🙂

Roteamento entre VRFs com MP-BGP em Roteadores HP / H3C

A utilização de VRFs (Virtual Routing and Forwarding) em Roteadores permite a criação de tabelas de roteamentos virtuais que trabalham de forma independente da tabela de roteamento “normal”, protegendo os processos de roteamento de cada cliente de forma individual.

VRFs Comware

Empresas que prestam serviços de gerenciamento de rede ou monitoração, empresas que vendem serviços em Data Center e provedores de serviço utilizam largamente VRFs, otimizando assim a administração e o retorno financeiro no total do custo de um projeto.

A configuração de VRFs é bem simples e há um artigo aqui do blog que pode ser consultado no link [http://www.comutadores.com.br/vrf-em-switches-e-roteadores-hpn-vpn-instance/].

Já o Roteamento entre VRFs ocorre quando há a necessidade de comunicarmos diferentes tabelas de roteamento que estão segregadas por VRF, para compartilharem alguns ou todos os prefixos. Há diversas formas de configurarmos o roteamento entre VRFs, como por exemplo com a utilização de um cabo virado para o próprio roteador com as portas em diferente VRFs [apontando assim uma rota para  nexthop da proxima VRF; ou com algum IGP] e também com a utilização de um outro roteador, etc; nesse post explicaremos o roteamento interVRF com o processo MPBGP que é a maneira mais escalável… preparados? Então vamos lá… 😉

Habilitando o import e export das VRFs

Ao configurarmos o processo de roteamento entre VRFs em um mesmo roteador , dois valores de extrema importancia devem ser configurados na VRF: o RD (route distinguisher) e o RT (route target)

RD – Route Distinguisher

Como explicado anteriormente,  as VRFs permitem a reutilização de endereços IP em diferentes tabelas de roteamento. Por exemplo, suponha que você tenha que conectar a três diferentes clientes , os quais estão usando 192.168.1.0/24 em sua rede local. Podemos designar a cada cliente a sua própria VRF de modo que as redes sobrepostas são mantidas isoladas em suas VRFs .

O RD funciona mantendo o controle de quais rotas 192.168.1.0/24 pertencem a cada cliente  como um diferenciador de rota (RD) para cada VRF. O route distinguisher é um número único adiciondo para cada rota dentro de uma VRF para identificá-lo como pertencente a essa VRF ou cliente particular. O valor do RD é carregado juntamente com uma rota através do processo MP- BGP quando o roteador troca rotas VPN com outros Roteadores PE.

O valor RD é de 64 bits e é sugerido a configuração do valor do RD como ASN::nn ou endereçoIP:nn. Mas apesar das sugestões, o valor é apenas representativo.

 

[R1-vpn-instance-Cliente_A]route-distinguisher ?
  STRING  ASN:nn or IP_address:nn  VPN Route Distinguisher
!
! Configurando a VRF para os clientes A B e C 
ip vpn-instance Cliente_A
 route-distinguisher 65000:1
!
ip vpn-instance Cliente_B
 route-distinguisher 65000:2
!
ip vpn-instance Cliente_C
route-distinguisher 65000:3

Quando rotas VPN são anunciados entre os roteadores PE via MP-BGP, o RD é incluído como parte da rota, juntamente com o prefixo IP. Por exemplo, uma via para 192.0.2.0/24 na VRF Cliente_B é anunciado como 65000:2:192.0.1.0 / 24.

RT – Route-Target ou VPN-target

Considerando que o valor do RD é utilizado para manter a exclusividade entre rotas idênticas em diferentes VRFs, o RT (route target)é utilizado para compartilhar rotas entre eles. Podemos aplicar o RT para uma VRF com o objetivo de controlar a importação e exportação de rotas entre ela e outras VRFs.

O route target assume a forma de uma comunidade BGP estendida com uma estrutura semelhante à de um RD (que é, provavelmente, porque os dois são tão facilmente confundidos).

Segue abaixo um exemplo de configuração, onde o Cliente_A fará o roteamento entre VRFs com o Cliente_B, já o Cliente_C continuará com a sua VRF isolada dos outros clientes.

 

!
!
ip vpn-instance Cliente_A
 route-distinguisher 65000:1
 vpn-target 65000:1 export-extcommunity
 vpn-target 65000:1 import-extcommunity
 vpn-target 65000:2 import-extcommunity 
!
ip vpn-instance Cliente_B
 route-distinguisher 65000:2
 vpn-target 65000:2 export-extcommunity
 vpn-target 65000:2 import-extcommunity
 vpn-target 65000:1 import-extcommunity  
!
ip vpn-instance Cliente_C
 route-distinguisher 65000:3
 vpn-target 65000:3 export-extcommunity
 vpn-target 65000:3 import-extcommunity
!

Inter VRF Routing

Segue abaixo a configuração das interfaces de cada VRF , e o processo MP-BGP responsável por funcionar o import/export de prefixos das VRFs.

!
!
interface Loopback0
 ip address 192.168.1.1 255.255.255.0
!
interface Loopback1
 ip binding vpn-instance Cliente_A
 ip address 1.1.1.1 255.255.255.0
!
interface Loopback2
 ip binding vpn-instance Cliente_B
 ip address 2.2.2.2 255.255.255.0
!
interface Loopback3
 ip binding vpn-instance Cliente_C
 ip address 3.3.3.3 255.255.255.0
!
#
bgp 6500
 undo synchronization
#
 ipv4-family vpn-instance Cliente_A
  import-route direct
#
 ipv4-family vpn-instance Cliente_B
  import-route direct
#
 ipv4-family vpn-instance Cliente_C
  import-route direct
#
!

Segue abaixo os outputs das rotas aprendidas para o roteamento entre VRFs(vpn-instances) e o teste de ICMP

[R1]display ip routing-table vpn-instance Cliente_A
Routing Tables: Cliente_A
        Destinations : 4        Routes : 4
Destination/Mask    Proto  Pre  Cost         NextHop         Interface
1.1.1.1/32          Direct 0    0            127.0.0.1       InLoop0
2.2.2.2/32          BGP    130  0            127.0.0.1       InLoop0
127.0.0.0/8         Direct 0    0            127.0.0.1       InLoop0
127.0.0.1/32        Direct 0    0            127.0.0.1       InLoop0

[R1]ping -vpn-instance Cliente_A 2.2.2.2
  PING 2.2.2.2: 56  data bytes, press CTRL_C to break
    Reply from 2.2.2.2: bytes=56 Sequence=1 ttl=255 time=4 ms
    Reply from 2.2.2.2: bytes=56 Sequence=2 ttl=255 time=10 ms
    Reply from 2.2.2.2: bytes=56 Sequence=3 ttl=255 time=10 ms
    Reply from 2.2.2.2: bytes=56 Sequence=4 ttl=255 time=5 ms
    Reply from 2.2.2.2: bytes=56 Sequence=5 ttl=255 time=4 ms
 --- 2.2.2.2 ping statistics ---
    5 packet(s) transmitted
    5 packet(s) received
    0.00% packet loss
    round-trip min/avg/max = 4/5/10 ms

Segue abaixo a configuração completa do R1

Para dúvidas em sugestões deixe um comentário. Até logo 😉

Dicionário de Comandos BGP: Comware vs Cisco

Pessoal, segue abaixo a lista de alguns comandos para BGP quando há a necessidade de traduzir de Cisco IOS para HP Comware.

Comware                                                      Cisco IOS
------------                                                 --------------
bgp xxxxx                                                   router bgp xxxxx
router-id x.x.x.x                                           bgp router-id x.x.x.x 
preference 200 200 200 (valor recomendado, não é default)   distance 20 200 200 (default)
undo synchronization                                        no synchronization (not default)
v5: recomendado (não é default)
v7: default
undo summary automatic (default)                            no auto-summary (not default)
log-peer-change                                             bgp log-neighbor-changes
graceful-restart                                            bgp graceful-restart
bgp graceful-restart restart-time 120 (default)             bgp graceful-restart stalepath-time 360 (default)
balance n (default=1)                                       maximum-path (dependente do contexto, default=1)
v5: global BGP config
v7: in ipv4 address family
maximum-path n (n=numero de rotas paralelas)                 maximum-path ibgp m 
ebgp-interface-sensitive (default)                           bgp fast-external-fallover (default)
network x.x.x.x y.y.y.y                                      network x.x.x.x mask y.y.y.y
aggregate x.x.x.x y.y.y.y                                    aggregate-addresss x.x.x.x y.y.y.y
aggregate x.x.x.x y.y.y.y detail-suppressed                  aggregate-addresss x.x.x.x y.y.y.y summary-only
import-route static [route-policy name]                      redistribute static [route-map name]
import-route direct [route-policy name]                      redistribute connected [route-map name]
import-route ospf process_id [route-policy name]             redistribute ospf process_id [route-map name]
default-information originate                                 
reflector cluster-id x.x.x.x                                 bgp cluster-id x.x.x.x
dampening                                                    bgp dampening
peer x.x.x.x as-number AS-number                             neighbor x.x.x.x remote-as AS-number
peer x.x.x.x description blabla                              neighbor x.x.x.x description blabla
peer x.x.x.x connect-interface LoopBack0                     neighbor x.x.x.x update-source Loopback0
peer x.x.x.x next-hop-local                                  neighbor x.x.x.x next-hop-self
peer x.x.x.x advertise-community                             neighbor x.x.x.x send-community
peer x.x.x.x password simple|cipher string                   neighbor x.x.x.x password 7 string
(default)                                                    neighbor x.x.x.x version 4 (no negotiation)
peer x.x.x.x ebgp-max-hop                                    neighbor x.x.x.x ebgp-multihop hop_count
peer x.x.x.x preferred-value default_prefval                 neighbor x.x.x.x weight default_weight
peer x.x.x.x default-route-advertise route-policy name       neighbor x.x.x.x default-originate route-map name
peer x.x.x.x timer keepalive keepalive hold holdtime         neighbor x.x.x.x timers keepalive holdtime minholdtime
peer x.x.x.x route-policy name import | export               neighbor x.x.x.x route-map name in | out
peer x.x.x.x public-as-only                                  neighbor x.x.x.x remove-private-as
peer x.x.x.x fake-as AS-number                               neighbor x.x.x.x local-as no-prepend AS-number replace-as
peer x.x.x.x substitute-as                                  
peer x.x.x.x allow-as-loop AS_occurances                     neighbor x.x.x.x allowas-in AS_occurances  
peer x.x.x.x route-limit prefix_number % reconnect restart_interval 
                                              neighbor x.x.x.x maximum-prefix prefix_number % restart restart_interval
peer x.x.x.x reflect-client                                  neighbor x.x.x.x route-reflector-client
peer x.x.x.x ignore                                          neighbor x.x.x.x shutdown
group group_name internal | external                         neighbor group_name peer-group
peer x.x.x.x group group_name                                neighbor x.x.x.x peer-group group_name

compare-different-as-med                                     bgp always-compare-med
bestroute compare-med                                        bgp deterministic-med
bestroute as-path-neglect                                    bgp bestpath as-path ignore

undo default ipv4-unicast                                    no bgp default ipv4-unicast
(Default)                                                    bgp suppress-inactive
peer x.x.x.x capability-advertise orf ip-prefix both         neighbor x.x.x.x capability orf prefix-list both
peer x.x.x.x capability-advertise route-refresh (default)    neighbor x.x.x.x soft-reconfiguration inbound
peer x.x.x.x bfd                                             neighbor x.x.x.x fall-over bfd
peer x.x.x.x route-update-interval timer                     neighbor x.x.x.x advertisement-interval seconds
(iBGP default=5s, eBGP default=30s)                          iBGP default=0s, eBGP (na VRF) default=0s, eBGP default=0s)
peer x.x.x.x next-hop-local                                  neighbor x.x.x.x next-hop-self
peer x.x.x.x capability-advertise orf ip-prefix both         neighbor x.x.x.x capability orf prefix-list both
Deve ser usado no vpnv4 address-family.                      Deve ser usado no vpnv4 address-family.
peer x.x.x.x advertise-ext-community                         neighbor x.x.x.x send-community extended | both
undo peer x.x.x.x enable                                     no neighbor x.x.x.x activate

Verificando a troca de prefixos												
display bgp routing-table peer x.x.x.x received-routes      show ip bgp neighbors x.x.x.x received-routes
display bgp routing-table peer x.x.x.x advertised-routes    show ip bgp neighbors x.x.x.x advertised-routes

MPBGP
display bgp vpnv4 vpn-instance vpn-instance-name routing-table peer x.x.x.x received-routes
show ip bgp vpnv4 vrf vrf-instance-name neighbors x.x.x.x received-routes
display bgp vpnv4 all routing-table peer x.x.x.x received-routes
v5
show ip bgp vpnv4 all neighbors x.x.x.x received-routes

display bgp vpnv4 vpn-instance vpn-instance-name routing-table peer x.x.x.x advertised-routes
show ip bgp neighbors x.x.x.x advertised-routes
display bgp vpnv4 all routing-table peer x.x.x.x advertised-routes
show ip bgp

Comandos comparativos para Troubleshooting, Reset e Refresh do BGP : Comware v5 x IOS Cisco

Segue uma lista para rápida comparação de comandos para troubleshooting, reset e refresh para o processo BGP comparando os comandos entre equipamentos 3Com,H3C e HP baseados no Comware e Cisco IOS.

Troubleshooting

Comware                                           IOS

display ip routing-table                          show ip route
display ip routing-table x.x.x.x                  show ip route x.x.x.x
display ip routing-table x.x.x.x longer-match     show ip route x.x.x.x longer-prefixes
display ip routing-table protocol bgp             show ip route bgp
display bgp routing-table                         show ip bgp
display bgp routing-table x.x.x.x                 show ip bgp x.x.x.x
display bgp routing peer                          show ip bgp summary
display bgp routing regular-expression AS-number  show ip bgp regexp AS-number

Reset e Refresh

Comware                                           IOS

reset bgp x.x.x.x            (modo user-view)     clear ip bgp x.x.x.x
refresh bgp x.x.x.x import   (modo user-view)     clear ip bgp x.x.x.x in
                                                  clear ip bgp x.x.x.x soft in

refresh bgp x.x.x.x export                        clear ip bgp x.x.x.x out
                                                  clear ip bgp x.x.x.x soft out

Video: Roteamento entre VLANs e configuração de rota estática para Switches HPN, 3Com e H3C

Fala Galera, tudo bom!?

Segue mais uma vídeo-aula produzida por nós, contendo dessa vez o assunto Roteamento entre VLANs utilizando Switches ou Roteadores, além de falarmos também sobre roteamento estático, Topologia, etc.. para equipamentos baseados no Comware (HP , 3Com e H3C) .

Ainda estou apanhando um pouco no formado das vídeo-aulas, mas espero que o vídeo seja útil. 😉




Abração

Comware: comando Send

Em empresas de médio e grande porte é comum encontramos cenários onde um ou mais administradores de rede efetuam o acesso remoto em um unico equipamento para fins de troubleshooting, etc.

O comando send , em Switches HP baseados no Comware, permite enviar uma mensagem pela própria CLI para alertar os outros usuários sobre uma determinada informação relevante, como por exemplo, a execução de um comando como o reboot.

Configurando

Primeiro, identifique com o comando display users os usuários conectados.

<Switch>display users
The user application information of the user interface(s):
Idx UI      Delay    Type Userlevel
+ 29  VTY 0   00:00:00 SSH  3
  30  VTY 1   00:00:04 SSH  0

Following are more details.

VTY 0   :
User name: fulano
Location: 192.168.208.23
VTY 1   :
User name: ciclano
Location: 192.168.208.93

+    : Current operation user.
F    : Current operation user work in async mode.

Com o comando send, é possível escolher se a informação será enviada para um determinado administrador  ou para todos os usuários conectados ao equipamento.

<Switch>send ?
INTEGER<0-44>  Specify one user terminal interface
all            All user terminal interfaces
aux            Aux user terminal interface
tty            Async serial user terminal interface
vty            Virtual user terminal interface

<Switch>send all
Enter message, end with CTRL+Z or Enter; abort with CTRL+C:
Pessoal, reiniciaremos o Switch em 2 minutos
Send message? [Y/N]:y
! Enviando a mensagem para ser impressa na tela dos outros usuários

<Switch>

***
***
***Message from con0 to con0
***
Pessoal, reiniciaremos o Switch em 2 minutos

<Switch>
! Exemplo de como o texto será exibido

Até logo.