Serviços IP
Switches 3Com 4500 – Exemplo de configuração com DHCP-Snooping
Autoconfiguração (Autodeploy) com DHCP no Comware
Esses dias pesquisando na web sobre protocolos de autoconfiguração para Roteadores HP achei dois artigos bem legais no site abouthpnetworking.com. O site é tão bacana que tenho as vezes vontade e traduzir todos os posts. 😛
A autoconfiguração (autodeploy) descrita nos 2 artigos do abouthpnetworking utilizará as configurações de fábrica do dispositivo que via DHCP irá procurar por um arquivo de configuração e tentar executa-lo.
Apesar dos textos estarem escritos em inglês vale a pena a consulta:
1 – utilizando as opções do DHCP para autoconfiguração com um servidor TFTP:
http://abouthpnetworking.com/2013/12/31/comware-config-autodeploy/
2- Autoconfiguração com scripts em Python para equipamentos baseados no comware 7
http://abouthpnetworking.com/2015/08/12/comware-7-autodeploy-supports-python-scripts/
Até logo
VRRP: Track baseado no estado de uma interface física
O protocolo VRRP funciona para redundância de Gateway em uma rede, com o objetivo de 2 ou mais roteadores compartilharem o mesmo IP virtual no modo ativo/backup (por padrão).
Para os outros dispositivos da rede, o VRRP permite que o gateway seja visualizado como um único equipamento.
O VRRP é bastante simples em sua função básica: um Roteador é eleito o Master e é responsável pelo encaminhamento do tráfego da rede para os equipamentos que tem aquele o IP Virtual como gateway. O segundo roteador chamado de Backup apenas monitora os pacotes VRRP do barramento. Entretanto, quando o equipamento Master deixar de funcionar, o equipamento Backup assume suas funções como Master.
Os equipamentos configurados com VRRP possuem a sua adminstração de forma individual (Plano de dados e controle separados) e por isso a configuração de rotas e outras features, deverão ser configurada individualmente.
Para um equipamento se eleger como Master é verificado a prioridade (por padrão é 100), vence o roteador que tiver a maior prioridade.
Caso não seja configurada a prioridade do grupo VRRP em um Roteador, o mesmo atribuirá o valor padrão (100) para o equipamento.
Se o endereço IP do Roteador for o mesmo do IP virtual, o equipamento será o MASTER.
Se o Roteador principal falhar, o novo Master será o Roteador Backup com maior prioridade.
VRRP Track
Há também cenários que o roteador Master do VRRP continua ativo, mas não consegue encaminhar os pacotes devido a interface saída (como para a Internet por exemplo) cair. Podemos então fazer o track para o processo VRRP monitorar algum objeto, que pode ser o estado da interface( UP ou down), pingar determinado site, teste de conexão telnet e etc; e dessa forma reduzir a prioridade VRRP baseando-se em uma condição.
No exemplo abaixo, o script demonstrará a redução da prioridade do VRRP do Roteador Master (R2) de forma que quando o link de saída para o Roteador 1 cair, o Roteador Backup (R3) se tornará o Master.
Configuração do VRRP com track
Roteador R2 (Master VRRP)
# track 1 interface GigabitEthernet0/0/3 ! Configurando o track para interface Giga0/0/3 # interface GigabitEthernet0/0/4 ip address 192.168.32.2 255.255.255.0 vrrp vrid 32 virtual-ip 192.168.32.1 ! configurando o grupo VRRP 32 com o IP virtual vrrp vrid 32 priority 115 ! configurando a prioridade do grupo 32 como 110 vrrp vrid 32 track 1 reduced 20 ! configurando o track 1 e em caso de falha, ele reduzirá a ! prioridade do VRRP para 95 #
Roteador R3 (Backup VRRP)
# interface GigabitEthernet0/0/4 ip address 192.168.32.3 255.255.255.0 vrrp vrid 32 virtual-ip 192.168.32.1 #
Validando o Roteador R2 que é o VRRP Master
[R2]display vrrp verbose
IPv4 Virtual Router Information:
Running Mode : Standard
Total number of virtual routers : 1
Interface GigabitEthernet0/0/4
VRID : 32 Adver Timer : 100
Admin Status : Up State : Master
Config Pri : 115 Running Pri : 115
Preempt Mode : Yes Delay Time : 0
Auth Type : None
Virtual IP : 192.168.32.1
Virtual MAC : 0000-5e00-0120
Master IP : 192.168.32.2
VRRP Track Information:
Track Object : 1 State : Positive Pri Reduced : 20
Simulando uma falha…
Quando a interface Giga0/0/3 do Roteador R2 falha, o track do VRRP irá identificar a falha e assim reduzir a prioridade do VRRP do Roteador, tornando dessa forma o R3 como Master
! Log do Roteador R2 após a falha na interface Giga0/0/3 %Jul 7 14:37:35:605 2015 R2 VRRP4/6/VRRP_STATUS_CHANGE: The status of IPv4 virtual router 32 (configured on GigabitEthernet0/0/4) changed from Master to Backup: VRRP packet received.
Output do Roteador R3 após a falha demonstrando a sua eleição como Master
[R3]display vrrp verbose
IPv4 Virtual Router Information:
Running Mode : Standard
Total number of virtual routers : 1
Interface GigabitEthernet0/0/4
VRID : 32 Adver Timer : 100
Admin Status : Up State : Master
Config Pri : 100 Running Pri : 100
Preempt Mode : Yes Delay Time : 0
Auth Type : None
Virtual IP : 192.168.32.1
Virtual MAC : 0000-5e00-0120
Master IP : 192.168.32.3
Por padrão a preempção é ativa nos Roteadores e dessa forma quando a interface Giga 0/0/3 do Roteador R2 voltar ao estado UP, o R2 voltará a ser o Master do VRRP.
Até logo galera.
Switches HPN 10500 – Configurando mapeamento estático multicast para NLB em Switches baseados no Comware
O protocolo NLB da Microsot (Network Load Balancing) tem como objetivo o balanceamento de tráfego entre um grupo de Servidores utilizando endereços MAC em multicast. Os clientes que acessam os serviços de um grupo de Servidores com NLB, enxergam o serviço de forma transparente.
Para trabalhar com NLB o Switch deve encaminhar o tráfego com destino ao serviço NLB para todos os servidores especificados no cluster NLB e cada servidor filtra o tráfego não desejado.
A cooperação entre o Switch e o protocolo NLB é muito importante e dessa forma é importante saber as maneiras que o protcolo NLB trabalha, que são os modos Unicast e Multicast:
Unicast
No modo unicast, NLB substitui o endereço MAC real de cada servidor no cluster para um endereço comum NLB MAC. Quando todos os servidores no cluster têm o mesmo endereço MAC, todos os pacotes enviados para esse endereço são enviados para todos os membros do cluster. No entanto, um problema com esta configuração é quando os servidores cluster NLB estão conectados ao mesmo switch, você não pode ter duas portas no switch com o registro do mesmo endereço MAC. O protocolo NLB resolve este problema mascarando o endereço MAC do cluster. O Switch olha para o endereço MAC de origem no cabeçalho do quadro Ethernet, a fim de saber quais os endereços MAC são associados com suas portas. O NLB cria um endereço MAC falso e atribui esse falso endereço MAC para cada servidor no cluster NLB. O NLB atribui a cada servidor NLB um endereço MAC falso diferente com base na identificação do membro.
Por exemplo, o endereço MAC do cluster NLB é o 00-bf-ac-10-00-01. O NLB no modo unicast leva o endereço MAC do cluster e, para cada membro do cluster, o NLB muda o segundo octeto do membro NLB. Por exemplo, o servidor 1 terá como falso endereço MAC 00-01-ac-10-00-01, o server com o ID 2 tem o falso endereço MAC 00-02-ac-10-00-01, assim por diante. Se um único endereço MAC está registrado em cada porta do switch, os pacotes não são entregues a todos os membros do cluster, em vez disso os pacotes são enviados para as portas de individuais com base no endereço MAC atribuído a essa porta. Para fazer os quadros serem entregues a todos os membros do cluster, o NLB registra um MAC diferente e utiliza nas mensagens ARP em broadcast. Quando o roteador envia uma solicitação ARP para o endereço MAC do endereço IP virtual, a resposta contém no cabeçalho ARP com o endereço MAC real do cluster NLB 00-bf-ac-10-00-01, como por exemplo citado acima e não o endereço MAC falso.
Os clientes então utilizam o endereço MAC no cabeçalho ARP, não o cabeçalho Ethernet para comunicar-se com o servidor. O switch usa o endereço MAC no cabeçalho Ethernet, não o cabeçalho ARP. A questão é quando um cliente envia um pacote para o cluster NLB com endereço MAC de destino como cluster de endereço MAC 00-bf-ac-10-00-01, o switch olha para a tabela MAC para o endereço MAC 00-bf-ac-10-00-01. Como não há porta registrada com o endereço do cluster NLB 00-bf-ac-10-00-01, o quadro é entregue a todas as portas. Isso força o Switch a encaminhar o quadro para toads as portas ocasionando flooding e atrapalhando o desempenho da rede.
Uma solução para mudar o comportamento de flooding é colocar um hub na frente dos membros do cluster NLB e, em seguida,um uplink do hub para uma porta do switch. Isso evita o problema de duas portas de switch registrando o mesmo endereço MAC. Quando o cliente envia pacotes para o endereço MAC do cluster NLB, os pacotes podem ir diretamente para a porta do switch conectado ao hub e, em seguida, para os membros do cluster NLB.
Multicast
Quando você usa o método de multicast, cada servidor do cluster mantém o endereço MAC original do da placa de rede. Além do endereço MAC original, é também atribuído um endereço MAC em multicast, que é compartilhado por todos os servidores de cluster. As requisições de entrada do cliente são enviadas para todos os servidores do cluster usando o endereço MAC em multicast.
No entanto, no modo multicast, a resposta ARP (ARP reply) enviada por um servidor do cluster em resposta a uma requisição ARP, mapeia o endereço IP unicast do cluster para endereços MAC em multicast. Tal mapeamento no ARP reply é rejeitado por alguns roteadores (ou Switch L3). Dessa forma os administradores devem adicionar uma entrada ARP estática no roteador para mapear o Endereço IP do cluster ao seu MAC Address.
Configurando NLB Multicast mode com o mapeamento estático para Comware
- Desabilite a função de validação do ARP.: undo arp check enable
Obs: configure nos Switches L3 e L2 (que os servidores do cluster estejam conectados). - Configure uma entrada estática para o ARP :. arp static ip-address mac-address vlan-id interface-type interface-number .
Obs: Para Switches com função L3 na topologia. - Configure uma entrada multicast MAC estática: mac-address multicast mac-address interface interface-list vlan vlan-id
Obs: dependendo do cenário, configure nos Switches L3 (porta para o trunk com o Switch de acesso) e L2 (porta para os servidores)
Resumo
Modo Unicast : O NLB atribui a cada membro de cluster um endereço MAC comum, que é o endereço MAC do cluster e muda o endereço MAC de origem de cada pacote enviado pelos servidores do cluster . Assim, o switch não pode adicionar o endereço MAC do cluster à sua tabela MAC . Dessa forma o endereço MAC é desconhecido e os pacotes destinados ao Cluster são encaminhados para todas as portas do Switch.
Modo Multicast : O NLB usa um endereço MAC multicast que é um endereço MAC virtual para as máquinas do Cluster.
Configuração
No configuration guide do Switch HPN 10500 há uma configuração mais simples sem o mapeamento da entrada ARP no Switch (o link do arquivo de configuração está nas referências abaixo).
O cluster NLB está na VLAN 10 enquanto os clientes estão na VLAN 20. O Switch fará o roteamento entre VLANs e o encaminhamento do tráfego NLB em modo multicast
Obs: iniciaremos a configuração com todas as portas configuradas nas respectivas VLANs e as máquinas utilizando o Switch como gateway
<Switch> system-view [Switch] interface vlan-interface 10 [Switch-Vlan-interface10] ip address 16.1.1.1 255.255.255.0 [Switch-Vlan-interface10] quit [Switch] [Switch] interface vlan-interface 20 [Switch-Vlan-interface20] ip address 10.0.0.1 255.255.255.0 [Switch-Vlan-interface20] quit # Desabilitando a validação ARP [Switch] undo arp check enable # Configurando a entrada MAC multicast estática [Switch] mac-address multicast 03bf-1001-0164 interface GigabitEthernet 4/0/2 GigabitEthernet 4/0/3 vlan 10
Referências
http://h10032.www1.hp.com/ctg/Manual/c03796252
Obs: Se vocês tiverem algum outro script ou experiência com esse tipo de cenário, por favor deixe um comentário 🙂
Se o link estiver quebrado, também deixe uma mensagem.
Switches HP 5800 – Resumo – DHCP Relay Agent
A feature DHCP Relay permite ao Switch encaminhar as mensagens DHCP em broadcast (para requisição de endereço IP) para determinado servidor, possibilitando assim utilização de um único servidor DHCP para toda a LAN.
Devido ao fato das solicitações de endereço IP ao servidor DHCP ocorrem em broadcast, o Switch configurado com a feature DHCP Relay encaminhará as mensagens ao Servidor DHCP em Unicast ( que está em uma VLAN diferente do host) .
O servidor DHCP entregará ao cliente o escopo correto baseado na interface IP de origem (alterada e inserida no cabeçalho DHCP).
Para o administrador do servidor DHCP bastará apenas criar os escopos no servidor.
Configurando o DHCP Relay
<SwitchA>system-view
[SwitchA] dhcp enable
! Ativando o DHCP
[SwitchA] dhcp relay server-group 1 ip 10.1.1.1
! Adicionando o servidor DHCP 10.1.1.1 dentro do grupo 1.
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 10.1.1.254 255.255.255.0
[SwitchA-Vlan-interface2] quit
[SwitchA] interface vlan-interface 40
[SwitchA-Vlan-interface40] ip address 10.2.2.254 255.255.255.0
[SwitchA-Vlan-interface40] dhcp select relay
!Ativando o DHCP relay agent na VLAN-interface 40
[SwitchA-Vlan-interface40] dhcp relay server-select 1
! Correlacionando a VLAN-interface 40 para o grupo DHCP 1
Obs: as configurações de DHCP Relay podem variar dependendo do modelo do Switch. A configuração acima foi executada em um Switch HP modelo 4800.
Até logo
Laboratório para configuração de VRRP no HP Network Simulator
Galera, montei um laboratório de VRRP no Simulador HP para o Comware 7 com o objetivo de validar a sintaxe dos comandos, além de testar o protocolo conforme cenário abaixo..
Para aqueles que não conhecem o VRRP, o protocolo funciona para redundância de Gateway em uma rede, com o objetivo de 2 ou mais roteadores compartilharem o mesmo IP virtual no modo ativo/backup ou ativo/ativo. O padrão do protocolo é o ativo(Master)/backup
Segue a configuração do VRRP nos Roteadores R1 e R2 além da configuração do Switch.
# Switch vlan 2 # interface GigabitEthernet1/0/2 port link-mode bridge port access vlan 2 # interface GigabitEthernet1/0/3 port link-mode bridge port access vlan 2 # Roteador - R1 interface GigabitEthernet 0/0/2 port link-mode route ip add 192.168.1.2 255.255.255.0 vrrp vrid 1 virtual-ip 192.168.1.1 vrrp vrid 1 priority 110 Roteador - R2 interface GigabitEthernet 0/0/2 port link-mode route ip add 192.168.1.3 255.255.255.0 vrrp vrid 1 virtual-ip 192.168.1.1
Os comandos display vrrp e display vrrp verbose executados nos roteadores exibem valiosas informações sobre o status do VRRP.
A configuração da topologia para HP Network Simulator 7.1.50 pode ser baixada aqui.
Os comandos são identicos para a versão 5 do Comware.
Até logo.
Configuração básica do VRRP entre equipamentos Cisco e HPN
Esses dias durante a finalização do Capítulo sobre VRRP para o segundo eBook “Guia Básico para Configuração de Switches” com o foco em Alta Disponibilidade” para equipamentos HPN/3Com/H3C, fiz alguns laboratórios com o protocolo VRRP, incluindo a utilização entre diferentes fabricantes. Segue abaixo um mini resumo sobre o protocolo, scripts das configurações e as “saídas” dos dispositivos.
O VRRP permite que 2 ou mais roteadores atuem como um único Roteador Virtual – na visão das máquinas de uma rede local – atuando de forma redundante em caso de falha no Roteador que é o default gateway das estações.
O protocolo é bem simples. Os Roteadores elegem um equipamento para ser o MASTER que é o responsável por encaminhar o tráfego e atuar como gateway para as máquinas da LAN, enquanto os outros Roteadores monitoram as mensagens geradas pelo MASTER e atuam como um Roteador Backup para em caso de falha do equipamento principal.
Atuação principal do Roteador Master é responder as requisições ARP das máquinas da rede local sobre o endereço MAC do Gateway e consequentemente processar o trafego encaminhado.
Em caso de falha do equipamento Master, um dos Roteadores Backup será eleito como novo Master para o grupo VRRP.
O protocolo é descrito pelo IETF na RFC 3768 e permite a configuração entre equipamentos de diferente fabricantes.
Na topologia abaixo, mostraremos um Script com a configuração de um grupo VRRP entre um Roteador Cisco e um Switch e/ou Roteador HPN /H3C.
Roteador Cisco
! interface FastEthernet0/0 ip address 172.16.0.2 255.255.255.0 duplex auto speed auto vrrp 1 ip 172.16.0.1 ! Configurando o grupo vrrp 1 com o endereço IP virtual 172.16.0.1 vrrp 1 priority 120 ! Configurando a prioridade do Roteador para 120 vrrp 1 authentication rdefault ! Configurando a autenticação do grupo VRRP 1 com a “senha” rdefault end !
Roteador HPN
# interface Ethernet0/0 port link-mode route ip address 172.16.0.3 255.255.255.0 vrrp vrid 1 virtual-ip 172.16.0.1 ! Configurando o grupo vrrp 1 com o endereço IP virtual 172.16.0.1 vrrp vrid 1 authentication-mode simple rdefault ! Configurando a autenticação do grupo VRRP 1 com a “senha” rdefault #
Comandos show e display
Roteador Cisco
Router#show vrrp FastEthernet0/0 - Group 1 State is Master Virtual IP address is 172.16.0.1 Virtual MAC address is 0000.5e00.0101 Advertisement interval is 1.000 sec Preemption enabled Priority is 120 Authentication text, string "rdefault" Master Router is 172.16.0.2 (local), priority is 120 Master Advertisement interval is 1.000 sec Master Down interval is 3.531 sec
Roteador HPN
[H3C]display vrrp verbose
IPv4 Standby Information:
Run Mode : Standard
Run Method : Virtual MAC
Total number of virtual routers : 1
Interface Ethernet0/0
VRID : 1 Adver Timer : 1
Admin Status : Up State : Backup
Config Pri : 100 Running Pri : 100
Preempt Mode : Yes Delay Time : 0
Auth Type : Simple Key : rdefault
Virtual IP : 172.16.0.1
Master IP : 172.16.0.2
Não esqueça
- Caso não seja configurada a prioridade do grupo VRRP em um Roteador, o mesmo atribuirá o valor padrão (100) para o equipamento.
- Se o endereço IP do Roteador for o mesmo do IP virtual, o equipamento será o MASTER.
- Se o Roteador principal falhar, o novo Master será o Roteador com maior prioridade.
Agora uma pergunta: – É possível decrementar a prioridade de um Roteador/ Switch VRRP para em caso de falha no Link para Internet no Roteador principal o outro equipamento Backup assumir como Master ? Se sim… deixem comentários! 
Outras referências e links:
Viva o linux http://www.vivaolinux.com.br/artigo/Firewalls-redundantes-utilizando-VRRP
Diferença entre VRRP, HSRP e GLBP http://blog.ccna.com.br/2008/12/16/pr-vrrp-x-hsrp-x-glbp/
RFC em inglês para suporte também a IPv6 http://tools.ietf.org/html/rfc5798
VRRP Load-Balance em Switches HPN http://www.comutadores.com.br/switches-hp-a7500-vrrp-load-balance/
Publicado originalmente em http://www.rotadefault.com.br/2012/09/26/configuracao-basica-do-vrrp-entre-equipamentos-cisco-e-hpn/
Switches HP A7500 – VRRP Load Balance
Publicado originalmente em 10 DE NOVEMBRO DE 2010
Cada estação de trabalho necessita de um endereço IP, Mascara e Gateway para comunicação com a Internet. Geralmente tais informações são distribuídas via servidor DHCP ou configuradas estaticamente na placa de rede.
Infelizmente tais configurações não são alteradas dinamicamente após mudanças na rede, como por exemplo, a falha do Switch ou Roteador com papel de Gateway.
Se o default gateway falhar, não haverá conectividade com o acesso fora da LAN. Ao adicionar outro roteador de Backup, ajudará parcialmente, pois precisaremos alterar o endereço do Gateway de todas as máquinas da rede para novo Gateway.
O VRRP (Virtual Router Redundancy Protocol) permite utilizarmos um endereço IP virtual para mais de um Gateway. Baseado na troca de mensagens entre dispositivos com o VRRP ativo, o processo elege um equipamento MASTER e outro BACKUP.
A cada solicitação ARP dos hosts da rede solicitando o endereço MAC do Gateway o dispositivo Master irá responder a solicitação, em caso de falha do Master, o dispositivo de Backup ( que será o Master a partir da falha) irá continuar a responder pelo IP Virtual.
A eleição do MASTER é baseada no equipamento com maior prioridade, valor configurável no dispositivo entre 0 e 255, o valor default é 100. Se os dois Switches tiverem a mesma prioridade, vence a eleição o dispositivo com maior endereço IP configurado.
O MASTER deverá encaminhar anúncios em intervalos constantes, monitorados pelo BACKUP. Em caso de não recebimento de alguns anúncios, será efetuada nova eleição para substituição do Switch MASTER.
Obs: Os anúncios são encaminhados para equipamentos que estão no mesmo segmento. As mensagens VRRP são encaminhadas a cada 1 segundo e o tempo de falha é 3 vezes o valor.
VRRP Load Balance
Uma das desvantagens do VRRP é que o equipamento de Backup sempre estará em modo passivo enquanto não houver uma falha no dispositivo Master, o VRRP Load Balance permite balancearmos o encaminhamento dos tráfego, alterando a resposta ARP, hora com o endereço MAC do Master, hora com o endereço MAC do Backup .
No modo VRRP Load Balance, é criado dinamicamente endereços MAC virtuais para cada dispositivo do Grupo, cabe ao Master, continuar respondendo qual endereço será respondido em cada requisição ARP.
Obs: A feature é similar ao GLBP proprietário da Cisco!
Configurando
Switch Master VRRP
vrrp mode load-balance ! Habilitando o VRRP em modo de Balanceamento # interface Vlan-interface1 ip address 192.168.1.2 255.255.255.0 ! Endereço IP físico da Interface VLAN 1 vrrp vrid 1 virtual-ip 192.168.1.1 ! Endereço IP Virtual do VRRP grupo 1 vrrp vrid 1 priority 120 ! Aumentando a Prioridade para eleição do Master ! (a prioridade default é 100, vence o maior) vrrp vrid 1 authentication-mode md5 vrrpcomutadores ! Forçando a autenticação dos Switches que participarão do ! Grupo VRRP 1 com a senha vrrpcomutadores
Switch Backup VRRP
vrrp mode load-balance ! Habilitando o VRRP em modo de Balanceamento # interface Vlan-interface1 ip address 192.168.1.3 255.255.255.0 ! Endereço IP físico da Interface VLAN 1 vrrp vrid 1 virtual-ip 192.168.1.1 ! Endereço IP Virtual do VRRP grupo 1 vrrp vrid 1 authentication-mode md5 vrrpcomutadores ! Forçando a autenticação dos Switches que participarão do ! Grupo VRRP 1 com a senha vrrpcomutadores
Display
Comando display no Switch eleito como Master
[SW1]display vrrp verbose IPv4 Standby Information: Run Mode : Load Balance Run Method : Virtual MAC Total number of virtual routers : 2 Interface Vlan-interface1 VRID : 1 Adver Timer : 1 Admin Status : Up State : Master Config Pri : 120 Running Pri : 120 Preempt Mode : Yes Delay Time : 5 Auth Type : MD5 Key : 0-Ma,R:)9P'Q=^Q`MAF4 Virtual IP : 192.168.1.1 Master IP : 192.168.1.2 Forwarder Information: 2 Forwarders 1 Active Config Weight : 255 Running Weight : 255 Forwarder 01 State : Listening Virtual MAC : 000f-e2ff-0011 (Learnt) Owner ID : 0024-7399-27f5 Priority : 127 Active : 192.168.1.2 Forwarder 02 State : Active Virtual MAC : 000f-e2ff-0012 (Owner) Owner ID : 0024-7399-27f0 Priority : 255 Active : local
Até a próxima!
Script de Configuração NQA com Tracking (IP SLA)
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