Quando pensamos nos requerimentos atuais das empresas, no que se refere ao transporte de dados, instalar alguns routers e switches e estabelecer a conectividade entre estes elementos certamente não é mais o suficiente para considerar o trabalho como concluído. O oferecimento de serviços gerenciados vêm se consolidando como uma tendência já há algum tempo, e a Cisco disponibiliza algumas ferramentas que podem nos ajudar a melhor uma rede e nos alertar de eventuais problemas, assim que estes aparecerem. Em um mundo em que soluções de IP Telephony e vídeo-conferência IP vêm se tornando parte do dia-a-dia das empresas, a feature Cisco IOS IP SLA pode ser uma poderosa aliada.

O que é o CISCO IP SLA?

CISCO IP SLA é uma feature presente em algumas versões do IOS da Cisco que permite o gerenciamento proativo das condições da rede monitorada. Basicamente, gera-se um tráfego específico de um dispositivo com destino a outro, que responde à este tráfego e medições são realizadas no decorrer do processo. Esta ferramenta torna muito mais simples tarefas como verificação do correto funcionamento das políticas de QoS, e também permite certificarmo-nos que estamos cumprindo os acordos de “uptime” assinados com o cliente, por exemplo. Na AT&T, empresa em que trabalhei por 2 anos entre 2004 e 2006, este recurso era largamente utilizado, inclusive como input para gerar os relatórios disponibilizados aos clientes. Ou seja, é realmente um recurso poderoso.

As opções que esta ferramente disponibiliza são imensas, e os dados podem ser observados via linha de comando, diretamente no router, ou podem ser acessados via SNMP.

Quando se utiliza esta ferramente, é necessário configurar ao menos 2 elementos: O “transmitter” e o “responder”. A configuração do responder é bastante simples. Ao iniciar a operação, o transmitter envia mensagens de controle ao responder. Estas mensagens de controle informam ao responder qual porta lógica (TCP ou UDP) deve ser usada para as requisições do transmitter. A ativação do serviço “responder” pode nem ser necessária, se o elemento que irá responder às solicitações do transmitter já estiver aguardando dados nas portas a serem testadas (ex. o serviço HTTP já está ativado no router que agirá como responder, e este é o serviço que queremos “medir”). Esta feature funciona muito bem também em topologias “hub & spoke” (estrela). Neste caso, normalmente, você teria o HUB como responder, e os spokes como transmitters.

Uma vez que o serviço SLA esteja devidamente configurado no transmissor, sua operação precisa ser agendada. As estatísticas apenas serão coletadas quando a configuração estiver operacional. As atividades de geração de tráfego e coleta podem ser agendadas para iniciar de imediato, ou em uma data / hora pré-determinadas. Podem ainda ser iniciadas sob certas condições.

ref: http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsoverv.html

Exemplo do IP SLA em ação

Suponhamos a seguinte rede de teste:

Vamos ativar OSPF single-area nesta rede, para garantir conectividade fim-a-fim. Vamos ativar o IP SLA neste cenário para monitorar um determinado serviço que roda na porta UDP 1234, de R1 para a interface Loopback0 de R3. Vamos começar ativando o IP SLA no responder (R3) :

R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#ip sla responder

E vamos verificar:

R3#show ip sla responder
IP SLAs Responder is: Enabled
Number of control message received: 0 Number of errors: 0
Recent sources:
Recent error sources:

Na sequência, vamos habilitar o R1 como transmitter, gerando o tráfego que determinamos para a loopback de R3 (responder) :

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ip sla 1
R1(config-ip-sla)#udp-echo 150.1.3.3 1234
R1(config-ip-sla-udp)#frequency 30
R1(config-ip-sla-udp)#exit
R1(config)#

O que fiz aqui foi criar uma operação com o ID 1 que gerará um pacote com destino à porta UDP 1234 ao IP 150.1.3.3 (L0 do responder), à cada 30 segundos. Vamos agora iniciar esta operação de imediato, sem expiração:

R1(config)#ip sla schedule 1 life forever start-time now

Vamos observar como estão as coisas em R1, nosso transmitter:

R1#show ip sla configuration 1
IP SLAs, Infrastructure Engine-II.
Entry number: 1
Owner:
Tag:
Type of operation to perform: udp-echo
Target address/Source address: 150.1.3.3/0.0.0.0
Target port/Source port: 1234/0
Request size (ARR data portion): 16
Operation timeout (milliseconds): 5000
Type Of Service parameters: 0×0
Verify data: No
Data pattern:
Vrf Name:
Control Packets: enabled
Schedule:
Operation frequency (seconds): 30 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
Enhanced History:
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None

R1#show ip sla statistics 1

Round Trip Time (RTT) for Index 1
Latest RTT: 68 milliseconds
Latest operation start time: *13:35:48.015 UTC Mon Jul 28 2008
Latest operation return code: OK
Number of successes: 9
Number of failures: 0
Operation time to live: Forever

Notem que a configuração já se encontra operacional no lado do transmitter (R1). Vamos observar como está do lado do responder (R3) :

R3#show ip sla responder
IP SLAs Responder is: Enabled
Number of control message received: 9 Number of errors: 0
Recent sources:
192.168.12.1 [13:36:17.971 UTC Mon Jul 28 2008]
192.168.12.1 [13:35:47.971 UTC Mon Jul 28 2008]
192.168.12.1 [13:35:17.959 UTC Mon Jul 28 2008]
192.168.12.1 [13:34:47.951 UTC Mon Jul 28 2008]
192.168.12.1 [13:34:17.999 UTC Mon Jul 28 2008]
Recent error sources:

Muito bom, não é mesmo??? Agora… como fazer este tipo de informação “trabalhar” para você? Ah, aí entra uma aplicação prática e bastante útil desta ferramenta…! Eu sei que vocês vão adorar ehehehehe! E se eu criasse uma rota estática, por exemplo, que apenas estivesse presente quando as condições da operação que eu acabei de criar fosse bem sucedida? É possível utilizar operações de SLA como se fossem objetos, que podem ser utilizados como condições por outros comandos / atividades em um router Cisco! Vou criar uma rota para a rede 123.123.123.0 /24 condicionada à operação SLA 1, que criei anteriormente:

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#track 1 rtr 1
R1(config-track)#exit
R1(config)#ip route 123.123.123.0 255.255.255.0 192.168.12.2 track 1

R1#sh ip route static
123.0.0.0/24 is subnetted, 1 subnets
S 123.123.123.0 [1/0] via 192.168.12.2

OK, a rota está lá, como deveria ! O que acontece agora se eu “matar” a interface loopback no responder (R3)? Nossa operação reportará uma falha e, teoricamente, a rota que acabei de criar em R1 deverá sair da tabela. Será? Vamos ver:

R3(config)#int l0
R3(config-if)#sh
R3(config-if)#
*Jul  28 00:14:11.219: %LINK-5-CHANGED: Interface Loopback0, changed state to adm
inistratively down
*Jul  28 00:14:12.219: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0,
 changed state to down

R1#
*Jul  28 00:15:41.671: %TRACKING-5-STATE: 1 rtr 1 state Up->Down
R1#
R1#sh ip sla statistics 1

Round Trip Time (RTT) for       Index 1
        Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: *00:15:23.031 UTC Mon Jul 28 2008
Latest operation return code: No connection
Number of successes: 9
Number of failures: 1
Operation time to live: Forever

R1#sh ip route 123.123.123.0
% Network not in table
R1#

Gostaram??? Espero que sim! Esta feature é muito interessante e útil!

Fiz estes testes utilizando o Dynamips. O arquivo “.net” utilizado segue:

[localhost]

    [[3725]]
        image = C:Program FilesDynamipsimagesC3725-AD.BIN
        ram = 128

    [[ROUTER R1]]
        model = 3725
        S1/0 = R2 S1/0
        idlepc = 0x60bf1f5c

    [[ROUTER R2]]
        model = 3725
        S1/1 = R3 S1/0
        idlepc = 0x60bf1f5c

    [[ROUTER R3]]
        model = 3725
        idlepc = 0x60bf1f5c

Testem! Vale a pena!

um abraço!!

Marco.

• 10 dicas “quentes” relacionadas ao Cisco IOS
• Níveis de privilégio no IOS Cisco
• Comandos não-documentados do Cisco IOS
• Cisco Dynamic Multipoint VPN (DMVPN)
• Auto-Segurança em roteadores Cisco
• Acoplando um Sistema de Aceleração - Juniper WX - a um Roteador Cisco via WCCPv2
• Ativando SSH em Roteadores Cisco
• Implementando Pequenas Redes com Cisco
• VA: Cisco SDM no Dynamips
• NetFormX - O novo configurator da Cisco®

Este post foi postado Monday, 28 de July de 2008 às 7:49 pm e está em Tecnologia, Cisco, Dicas. Você pode verificar qualquer resposta a este post através do feed RSS 2.0. Você pode ir até o final e deixar uma resposta. Pings não são permitidos.