HPN

Resumo do Protocolo LLDP

Diego Dias1 Comment

O protocolo LLDP(802.1AB) permite que dispositivos de rede como Servidores, Switches e Roteadores, descubram uns aos outros. Ele opera na camada de enlace do modelo OSI (camada 2)  permitindo que informações básicas como hostname, versão do Sistema Operacional , endereço da interface, entre outros, sejam aprendidas dinâmicamente por equipamentos diretamente conectados.

O mais bacana do Link Layer Discovery Protocol (LLDP)  é a integração entre equipamentos de diversos fabricantes; e para aqueles que já estudaram o material do CCNA da Cisco, a feature é identica ao Cisco Discover Protocol (CDP) – o protocolo proprietário da Cisco para descoberta de vizinhos.

A tirinha abaixo adaptada do site http://vincentbernat.github.com/lldpd/index.html  demonstra bem a utilização do LLDP (ou como ajudaria no caso abaixo.. rs )  O site possui instruções de instalação do protocolo para diversas plataformas.

LLDP tirinha

Conceitos Básicos

Para redes Ethernet, o LLDP é encaminhado dentro do quadro Ethernet da seguinte maneira:

LLDP Packet

A mensagem encaminhada também é chamada de LLDPDU (Link Layer Discover Protocol Data Unit)

Endereço MAC de destino (Destination MAC address)
O endereço MAC de destino de um LLDPDU pode ser anunciado nos endereços Multicast  0180-C200-000E , 0180-C200-0003 ou 0180-C200-0000.

Endereço MAC de  origem (Source MAC address)
O endereço MAC de origem é o da porta que encaminha o LLDPDU, se a interface não tiver endereço MAC, será encaminhado o endereço reservado do Switch/Roteador

Type
O Ethernet type usado para o LLDP é o 0x88CC for LLDP.

Data
LLDP data unit (LLDPDU)

FCS
Frame check sequence é um valor de CRC de 32-bit CRC usado para determinar a validade do recebimento do quadro  Ethernet.

Os LLDPDUs

O LLDP usa os LLPDU’s para troca de informações. Dentro do LLDPDU há uma sequencia de campos TLV ( type [tipo], length [comprimento] e value [valor])

LLDPDU encapsulation format

Um LLPDU pode carregar até 28 tipos de TLVs. Os itens obrigatóriso devem carregar:

  • TLV de identificação do Chassis
  • TLV de identificação da Porta
  • TTL TLV
  • TLV do fim do LLPDU
  • Outros campos são opcionais

A demonstração feita nos dá uma boa visão das informações carregadas pelo protocolo:

LLDPDU encapsulation format 2

A saída do comando display lldp  neighbor-information brief  em um Switch HPN demonstra o estudo:

<Switch>display lldp  neighbor-information brief
LLDP neighbor-information of port 469[GigabitEthernet1/9/0/1]:
Neighbor 1:
ChassisID/subtype: 3822-d6b6-4c01/MAC address
PortID/subtype   : GigabitEthernet1/0/48/Interface name
Capabilities     : Bridge,Router

Para os campos Opcionais é possível obter informações como Hostname, descrição do tipo de equipamento, endereço de gerenciamento, informação sobre VLANs, etc.

LLDP-MED

A extensão do LLDP chamada de Media Endpoint Discovery extension (MED) é muito utilizada para Telefonia IP e provê as seguintes informações:

  • Provisionamento de informações de politicas para a rede local agir de forma plug-and-play (como VLAN, Prioridades na marcação de pacotes e quadros para fins de QoS)
  • Identificação do local do dispositivo
  • Funções para PoE
  • etc

Configuração básica do LLDP

[Switch]lldp enable
! Ativando o LLDP globalmente

[Switch]interface Ethernet 1/0/1
[Switch-Ethernet1/0/1]lldp enable
! Ativando o LLDP na interface

Para ajuste de envio, recebimento ou desativar o LLDP em uma interface, existem as seguintes opções:

[Switch-Ethernet1/0/1]lldp  admin-status ?
disable  The port can neither transmit nor receive LLDP frames
rx       The port can only receive LLDP frames
tx       The port can only transmit LLDP frames
txrx     The port can both transmit and receive LLDP frames

Para  mais informações sobre a compatibilidade entre o LLDP e o CDP, acesse o seguinte post:
http://www.comutadores.com.br/switches-hp-a7500-tabela-de-vizinhos-via-protocolo-cdp/

Obs: Fique sempre atento as informações encaminhadas pelo LLDP em uma rede local, pois o protocolo habilita inumeras informações que tornam a rede “vulnerável”. Certifique-se que o ambiente é controlado e desabilite o LLDP (se possível) após a coleta de informações! 

Para mais informações sobre configuração do LLDP em Switches Cisco, acesse  o seguinte post:
http://www.comutadores.com.br/switches-hpn-12500-utilizando-lldp-ao-inves-do-cdp/

 

Referências

http://www.h3c.com/portal/Technical_Support___Documents/Technical_Documents/Switches/…

http://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol

http://vincentbernat.github.com/lldpd/index.html

Switches 3Com 7900 – Aplicando ACLs em VLANs

Diego Dias4 Comments

Para configurarmos as listas de acesso (ACL) e aplicarmos a uma interface física ou VLAN no Switch 7900 é necessário o vínculo a uma politica de QoS, aplicando a ACL indiretamente à Interface ou VLAN.

No script abaixo iremos negar a rede 192.168.1.0/24 de comunicar-se com a rede 172.31.1.0/24.

Configuração

vlan 192
vlan 172
#
interface Vlan-interface192
ip address 192.168.1.1 255.255.255.0
#
interface Vlan-interface172
ip address 172.31.1.1 255.255.255.0
#
acl number 3001
!criando a ACL avançada 3001
rule 0 deny ip source 192.168.1.0 0.0.0.255 destination 172.31.1.0 0.0.0.255
! regra 0 irá negar a origem 192.168.1.0/24 (é obrigatório a utilização de máscara curinga) de comunicar com a rede 172.31.1.0/24. Nesse caso poderíamos ter mais de uma regra!!
quit
traffic classifier rede_192 operator and
! Criando a classificação de tráfego com o nome rede_192
if-match acl 3001
! Efetuando match na ACL 3001
quit
#
traffic behavior rede_172
! Criando o comportamento com o nome rede_172
filter deny
! Criando o filtro negar (deny)
quit
#
qos policy proibe_rede_192_172
!Criando a policy com nome proibe_rede_192_172
classifier rede_192 behavior rede_172
! vinculo do classifier rede_192(ACL) com o behavior rede_172 (deny)
quit
qos vlan-policy proibe_192_172 vlan 192 inbound
! aplicando a politica de QoS na VLAN 192, proibindo a rede 192.168.1.0/24 de comunicar-se com a rede 172.31.1.0/24 no sentido de entrada do Switch

Para aplicarmos a sintaxe a uma porta física (GigabitEthernet) a sintaxe seria:

interface GigabitEthernet 2/0/9
qos apply policy proibe_192_172 inbound

A utilização do script acima para filtro de pacotes negará todas as regras que forem explicitamente escritas, nesse caso permitirá a comunicação da rede 192.168.1.0/24 com qualquer outra rede que não tenha referência nas linhas da ACL 3001 (não importando o permit ou deny da ACL).

Até logo 🙂

 

 

Procedimento de Back-out para equipamentos HPN

Diego DiasLeave a comment

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 😉

Switches 3Com 7900 – Como o DLDP poderá ajudar a “sua” Fibra Óptica!!

Diego DiasLeave a comment

O DLDP é um protocolo que funciona acima da camada física para detecção de links unidirecionais, como problemas no TX ou RX, colocando a porta em shutdown em caso de falha. A feature é bastante útil para checar a integridade dos 2 pontos da conexão ( Fibra Óptica ou UTP).

Para ativar o dldp é muito simples:
dldp enable 
! Ativando o DLDP globalmente
interface Ten-GigabitEthernet8/0/1
dldp enable
! Ativando o DLDP na interface

Para o correto funcionamento do DLDP é necessário habilitarmos o comando nos 2 Switches do UpLink.

Testando o DLDP

Na imagem abaixo durante uma janela de manutenção das fibras, a equipe de cabeamento acabou conectando o Tx da interface Ten-GigabitEthernet8/0/1 na interface Ten-GigabitEthernet8/0/2. Nesse cenário sem o DLDP os Switches não perceberiam o erro e as interfaces seriam exibidas como UP em qualquer comando display; mas a comunicação lógica estaria com problemas…

Com o DLDP ativo, os Switches exibem o seguinte Log de erro:

#Aug 18 22:03:28:016 2010 7900 DLDP/1/TrapOfUnidirectional:Slot=8;
h3cDLDPUnidirectionalPort : DLDP detects a unidirectional link in port 70516736.

Comando Display

[7900]display int ten8/0/1
Ten-GigabitEthernet8/0/1 current state: DLDP DOWN
IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 0024-7399-9917
Description: ENLACE_10G_COM_SIA
Loopback is not set
Media type is optical fiber,Port hardware type is 10G_BASE_LR
10Gbps-speed mode, full-duplex mode
Link speed type is force link, link duplex type is force link

------

[7900]display dldp Ten-GigabitEthernet 8/0/1

Interface Ten-GigabitEthernet8/0/1
DLDP port state : disable 
DLDP link state : down 
The neighbor number of the port is 0

Após a correção do erro…

o DLDP ajudou a salvar o dia…

[7900]disp interface Ten-GigabitEthernet 8/0/1
Ten-GigabitEthernet8/0/2 current state: UP
IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 0024-7399-9917
Description: ENALCE_10G_COM_SCN
Loopback is not set

Obs; o método também permite utilizarmos autenticação MD5 entre os Switches que conversam DLDP

[7900]dldp authentication-mode md5 dldp2010
! Habilitando a autenticação do protocolo DLDP com a senha "dldp2010"

Até a próxima!

QoS – Aplicando Line Rate na Interface Física (Policy)

Diego Dias4 Comments

Alguns modelos de Switches HPN Serie-A com o Comware 5 possibilitam a configuração de limite de banda em interfaces físicas de uma maneira bem simples. A feature chama QoS Line Rate.

[Switch-GigabitEthernet1/0/1]qos lr ?
  inbound   Limit the rate on inbound
  outbound  Limit the rate on outbound

[Switch-GigabitEthernet1/0/1]qos lr inbound cir ?
  INTEGER  Committed Information Rate(kbps)

Para a configuração de limite de banda para a interface em 256kbps para pacotes de entrada e saída basta digitar.

[Switch-GigabitEthernet1/0/1]qos lr inbound cir 256
[Switch-GigabitEthernet1/0/1]qos lr outbound cir 256

Até logo 😉

Switches 3Com 4800G – Port Security

Diego Dias2 Comments

A feature port security permite o aprendizado dinâmico de endereço MAC vinculado a uma interface GibabitEthernet para fins de segurança, não permitindo que outro host funcione naquela interface. Se a condição não for satisfeita (a utilização do MAC correto), a porta entrará em estado de violação e não trafegará dados.

É possível configurar a quantidade de endereços MAC aprendidos dinamicamente pela Interface, inserindo assim (após o aprendizado estático ou dinâmico dos endereços) entradas fixas na tabela de endereços MAC.

A feature é bastante útil em ambientes que os hosts/Servidores precisam ser vinculados a uma interface (como em CPDs, DataCenters, etc) ou em localidades que o usuário costuma migrar a estação sem comunicar a equipe de suporte!

As configurações aprendidas serão atribuídas à configuração da memória volátil. Se o dispositivo for reiniciado ele aprenderá novos endereços. Na necessidade de manter os endereços aprendidos, sugerimos salvar a configuração.

Configuração

[4800] port-security enable
! Habilitando o port-security no Switch
[4800] interface gigabitethernet 1/0/1
[4800-GigabitEthernet1/0/1] port-security max-mac-count 1
! Habilitando o port-security para o aprendizado dinamico de
! apenas 1 endereço MAC ( o primeiro descoberto)
[4800-GigabitEthernet1/0/1] port-security port-mode autolearn
! Habilitando o port-security para aprendizado dinamico do endereço
! MAC para a interface GigabitEthernet 1/0/1

Obs: Após o aprendizado do endereço MAC, a interface GigabitEthernet não permitirá a conexão de outra máquina na porta giga 1/0/1. O endereço aprendido na interface giga 1/0/1 não poderá ser utilizado em outra interface no mesmo Switch. Sugerimos não configurar o Port-Security em interfaces TRUNK

Display

Segue abaixo a configuração da interface após o aprendizado:

#
interface GigabitEthernet1/0/1
port access vlan 10
stp edged-port enable
port-security max-mac-count 1
port-security port-mode autolearn
port-security mac-address security 000a-aab2-a33b vlan 10

! A saída abaixo relata a troca de máquina na int GigabitEthernet 1/0/1

%Apr 26 17:23:01:527 2000 SBSSWCOR03 PORTSEC/1/VIOLATION:
OID: 1.3.6.1.4.1.43.45.1.10.2.26.1.3.2
An intrusion occurs!
IfIndex: 9437189
Port:GigabitEthernet1/0/1
MAC Addr: 00:0F:DF:B4:FA:49
VLAN id:10
IfAdminStatus: 1

Switches 3Com 4800G – Ataques ao protocolo ARP

Diego Dias3 Comments

O protocolo ARP possui 3 principais vulnerabilidades:

  • Não possui suporte a autenticação
  • É suscetível a vazamento de informação via análise de mensagens Broadcast do protocolo durante solicitação de conversa entre dispositivos.
  • Força o processamento para os hosts da VLAN para todas as requisições ARP, consumindo CPU e largura de banda.

Umas das principais técnicas utilizadas em ataques ao ARP são conhecidas com ARP Spoofing ou ARP Poisoning. A técnica consiste em encaminhar uma resposta falsa a requisição ARP original ou via Gratuitous ARP, permitindo ao atacante atuar no meio da comunicação (Man-in-the-Middle) para “sniffar” o trafego . O host de origem não perceberia a atuação do atacante.

Clique no link para assistir uma rápida demonstração utilizando o software Cain (em inglês) http://www.irongeek.com/i.php?page=videos/using-cain-to-do-a-man-in-the-middle-attack-by-arp-poisoning

ARP Detection

A detecção de ARP permite ao Switch encaminhar somente o tráfego válido na tabela ARP.O tráfego pode ser validado via 802.1x, entradas estáticas ou via DHCP Snooping, no script abaixo mostraremos a técnica utilizando o modo estático e via o mapeamento do DHCP Snooping.

A utilização da feature DHCP-Snooping permite aos Switches o bloqueio de respostas DHCP de Servidores não-válidos na rede e o mapeamento dos Endereços IP entregue ao usuário com o endereço MAC do host, conforme display abaixo:

[4800G]display dhcp-snooping 

DHCP Snooping is enabled.
The client binding table for all untrusted ports.
Type : D--Dynamic , S--Static
Type IP Address MAC Address Lease VLAN Interface
==== =============== ============== ============ ==== =================
D 192.168.1.102 0027-0e0f-a154 172653 1 GigabitEthernet1/0/4
D 192.168.1.103 0027-0e0f-9edb 172728 1 GigabitEthernet1/0/12
--- 2 dhcp-snooping item(s) found ---

Quando ativamos a detecção ARP, todas as portas são consideradas não confiáveis comparando o endereço MAC de origem com o mapeamento IP + MAC checado.

#
dhcp-snooping
!Ativando o DHCP Snooping
#
vlan 1
arp detection enable
!Habilitando a detecção ARP na VLAN 1
#
arp detection mode dhcp-snooping
!Ativando a detecção ARP para verificação da tabela gerada pelo DHCP Snooping
arp detection mode static-bind
!Ativando a detecção ARP para verificação da tabela estática
arp detection static-bind 192.168.1.104 0027-c686-6681
! Gerando uma entrada estática para detecção de ARP
#

Obs: É possível configurar uma interface como confiável para não haver detecção de ARP naquela porta. Configure o comando “arp detection trust” na interface.

ARP Source Suppression

Para proteção contra ataques à hosts com o envio de grande numero de requisições ARP é possível habilitar a supressão de ARP.

!
arp source-suppression enable
arp source-suppression limit 10
! Limita o numero de 10 requisições ARP da mesma origem para endereços
! não resolvidos no threshold de 5 segundos. Se o limite for excedido,
! o Switch efetuará a supressão do ARP do host por 5 segundos.

No guia de configuração dos Switches há maiores referencias e outras técnicas de proteção contra ataques ao ARP. Caso conheça outras técnicas e softwares deixe um comentário.

Abraço a todos!

Referências e Consulta

Lan Switch Security , Eric Vyncke and Christopher Paggen ,Cisco Press, 2008
http://comutadores.blogspot.com/2010/04/switches-3com-4800-dhcp-snooping-como.html
http://www.irongeek.com/i.php?page=security/arpspoof
http://imasters.com.br/artigo/10117/seguranca/arp_poisoning/

Switches HPN 12500 – MPLS – Configuração Básica

Diego DiasLeave a comment

Dando continuidade aos posts anteriores sobre MPLS, segue abaixo a configuração básica para ativar o serviço em um Switch HPN modelo A12500. O script dará foco no protocolo LDP para adjacência entre roteadores vizinhos e a troca de labels; em conjunto com o OSPF para o vinculo (binding) dos prefixos IP com  labels.

Configuração

#
interface LoopBack1
 ip address 1.1.1.1 255.255.255.255
#
mpls
! Ativando o Serviço MPLS no Switch
#
mpls ldp
! Ativando o protocolo LDP para troca de labels
#
mpls lsr-id 1.1.1.1
! Forçando o Router id com o endereço da Loopback para adjacência
! entre Roteadores  vizinhos
#
interface Vlan-interface1
 ip address 10.0.0.1 255.255.255.0
 mpls
! Ativando o Serviço na interface VLAN 1
 mpls ldp
! Ativando o protocol LDP para troca de Labels na
! Interface VLAN 1 e adjacência
#
interface Ten-GigabitEthernet0/0/34
 port link-mode route
 ip address 10.0.1.2 255.255.255.252
mpls 
mpls ldp
#
ospf 1
 area 0.0.0.0
 network 0.0.0.0 255.255.255.255
 #

Displays

Para visualização dos neighbors, LSP e bindings, sugiro os seguintes comandos abaixo:

[Switch] display mpls ldp peer

[Switch] display mpls ldp session

[Switch] display mpls ldp interface

[Switch]display mpls ldp lsp
                              LDP LSP Information
 SN     DestAddress/Mask   In/OutLabel   Next-Hop        In/Out-Interface 

26     192.168.1.0/24       25/26     10.0.1.1          XGE0/0/34
27     192.168.0.1/32      2236/3043     192.0.0.5      XGE0/0/34
28     192.168.3.1/32     1037/1044     192.0.0.5       XGE0/0/34

[Switch]display mpls ldp
                           LDP Global Information

 Protocol Version        : V1           Neighbor Liveness    : 120 Sec
 Graceful Restart        : Off          FT Reconnect Timer   : 300 Sec
 MTU Signaling           : Off          Recovery Timer       : 300 Sec
                          LDP Instance Information

 Instance ID             : 0            VPN-Instance         :
 Instance Status         : Active       LSR ID               : 1.1.1.1
 Hop Count Limit         : 32           Path Vector Limit    : 32
 Loop Detection          : Off
 DU Re-advertise Timer   : 30 Sec       DU Re-advertise Flag : On
 DU Explicit Request     : Off          Request Retry Flag   : On
 Label Distribution Mode : Ordered      Label Retention Mode : Liberal

Até logo!

Script de Configuração NQA com Tracking (IP SLA)

Diego Dias4 Comments

A dica de utilização do NQA foi encaminhada pelo Leandro Cândido: “Caros, estava testando a Feature de NQA + TRACK  (SIMILAR AO IP SLA DO CISCO), pois iríamos precisar utilizar em um dos nossos clientes, e vi que funciona perfeitamente bem. Então, estou encaminhando o script caso alguém precise aplicar em algum projeto que envolva equipamentos 8800, 4800, 7900 e outros…”

A Feature NQA (Network Quality Analizer) permite o diagnóstico de desempenho de Links para verificação de Jitter, atraso de conexão TCP, FTP, ICMP e etc.

O NQA realiza testes utilizando pacotes ICMP echo, DHCP, FTP, HTTP, UDP jitter, SNMP, TCP, UDP echo, voz e DLSw.

No exemplo abaixo utilizaremos o NQA para testar o link principal com pacotes ICMP (PING). Em caso de falha do Link, o NQA permitirá ao Switch utilizar uma segunda a rota default para encaminhar o tráfego para o Link Redundante.

Utilizaremos o primeiro Roteador da Operadora A (Link principal) como Objeto para “rastrear” o Link como ativo.

Configuração

Nessa primeira parte do Script efetuaremos o vínculo do NQA (responsável por gerar os pacotes ICMP) com o Track.

 

nqa entry empresax rota_monitorada_via_icmp
!Criando o grupo NQA empresax rota_monitorada_via_icmp
type icmp-echo
! definindo o tipo de pacote como ICMP
destination ip 200.1.2.3
! endereço monitorado no primeiro salto da Operadora A
frequency 500
! a freqüência do teste será a cada 500ms
reaction 1 checked-element probe-fail threshold-type consecutive 4 action-type trigger-only
! Se a reação 1 identificar 4 falhas no objeto monitorado, ele será invalidado 

nqa schedule empresax rota_monitorada_via_icmp start-time now lifetime forever
!ativando o tempo de monitoração como infinito
nqa agent enable

track 1 nqa entry empresax rota_monitorada_via_icmp reaction 1
!Associando o track 1 ao NQA empresax

Obs: Até agora apenas criamos o NQA para monitorar o endereço do primeiro salto da Operadora A (é possível identificarmos esse endereço com o comando traceroute para qualquer endereço de internet) e vinculamos ao Track. A idéia agora é vincularmos a rota default principal como Objeto do Track, para invalidarmos a rota em caso de falha no link.

ip route-static 0.0.0.0 0.0.0.0 192.0.1.1 track 1 preference 1 descripition rota_principal
! Associando a rota estática com preferência 1 ao Track 1
ip route-static 200.1.2.3 255.255.255.255 192.0.1.1 descripition roteador_operadoraA
! A rota estática  está forçando a monitoração do Link Principal pelo roteador 192.0.1.1 
! evitando chegarmos no Roteador da operadora A via Operadora B em caso de falha no link principal

ip route-static 0.0.0.0 0.0.0.0 192.0.2.1 preference 60 description rota_backup
! rota de backup com preferência 60

Comandos Display

[4800G] display track 1
Track ID: 1
Status: Positive
! Rota principal funcionando
Reference object:
NQA entry: empresax rota_monitorada_via_icmp
Reaction: 1

[4800G]display nqa statistics
NQA entry(admin empresax, tag rota_monitorada_via_icmp) test 
statistics:
NO. : 1
Destination IP address: 200.1.2.3 
Start time: 2000-04-26 13:14:57.0 
Life time: 2612 
Send operation times: 2510 Receive response times: 2067 
Min/Max/Average round trip time: 3/460/4 
Square-Sum of round trip time: 553275 

Extended results:
Packet lost in test: 17% 
Failures due to timeout: 443
Failures due to disconnect: 0 
Failures due to no connection: 0
Failures due to sequence error: 0 
Failures due to internal error: 0
Failures due to other errors: 0

Packet(s) arrived late: 0

[4800G]display ip routing-table 
Routing Tables: Public
Destination/Mask Proto Pre Cost NextHop Interface
0.0.0.0/0 Static 1 0 192.0.1.1 Vlan1 
!Tráfego encaminhado via interface vlan 1, antes do problema no link

Após a falha

Se o resultado do teste NQA der negativo, isto é, 200.1.2.3 como inalcançável, (o status do Objeto Track é Negative) a rota estática será inválida.

[4800G]display track 1 
Track ID: 1
Status: Negative
!Momento em que ocorre o problema no link, rota principal para de funcionar 
Reference object:
NQA entry: empresax rota_monitorada_via_icmp
Reaction: 1

[4800G]dis ip routing-table 
Routing Tables: Public
Destination/Mask Proto Pre Cost NextHop Interface
0.0.0.0/0 Static 60 0 192.0.2.1 Vlan3 
! Agora o Tráfego será encaminhado via interface vlan 3. Se o link principal 
! voltar a comunicar, a rota default com preferência 1 voltará para tabela de 
! rotas excluíndo a de preferência 60

O que acharam do NQA? já tiveram alguma experiência com essa feature? Comentem…

Abraços