«

»

jul 28 2008

Cisco IOS IP SLA tool

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:

rtr.gif
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.



Comente usando o Facebook!
0
0

22 comentários

Pular para o formulário de comentário

  1. Marcos Pitanga

    Show de bola…

    Eu utilizo em alguns clientes de missão crítica, principalmente na questão de QoS.

    Grande artigo.

    0

    0
  2. Marcelo Conterato

    Muito bom Marco, fico cada vez mais interessado nas ferramentas disponíveis, uma pena e que muitas vezes, não temos oportunidade de utilizar na prática tais ferramentas, mesmo assim, muito interessante o assunto abordado. Abraço!

    0

    0
  3. Luiz Silva

    Marco…
    Sem palavras…estou abismado!!!

    o nível das suas matérias está cada vez melhor…super detalhado…já tinha ouvido falar dessa feature, mas nunca a utilizei.

    vou praticar AGORA!!!

    abraços

    0

    0
  4. Luiz Silva

    show de bola…consegui fzer tudo que foi mostrado…
    mudaram alguns comandos …mas deve ser a versão da IOS (c3725-advipservicesk9-mz.124-3.bin) que utilizei…

    mais uma vez obrigado…

    abraços

    0

    0
  5. Marcia Guimaraes

    Marco…

    Somente aqui poderíamos ter acesso a esse nível de informação. Assim a curiosidade fica aguçada e está em estado permanente de reavaliação de conteúdo. Muito bom ! 🙂

    Mas fiquei em dúvida sobre um conceito. No link do documento no site da Cisco, diz que o recurso CISCO IP SLA é “independente de transporte camada 2” e “coleta um sub-conjunto únido de métricas de performance” de Delay, Jitter e etc. ok… mas…

    … não compreendi como o recurso do CISCO IP SLA pode medir o Jitter se este está associado interferência eletromagnética (EMI) e ao crosstalk e outros sinais. Como o jitter sendo essencialmente um sinal analógico pode ser medido via protocolo com recurso como este ?? E o documento fala de “UDP Jitter”. Pensei que Jitter só existisse no nível físico, camada 1.

    Não tenho o nível de conhecimento de muitos aqui. E diante de um novo recurso como esse que vc apresentou, as dúvidas surgem… e ela entra em “loop”… rssss… e não poderia deixar de perguntar.

    Hoje vou dormir pensando nisso. 🙂

    Sds.
    Márcia

    0

    0
  6. Marco Filippetti

    Oi Márcia, a definição de jitter – quando aplicado em VoIP, ao menos – seria a variação do atraso na transmissão de pacotes, meramente. Não sei exatamente como o IP SLA implementa isso, mas poderia ser aingido medindo-se o atraso entre os pacotes e fazendo uma comparação estatística entre estes atrasos.

    Abs!

    Marco.

    0

    0
  7. Marcia Guimaraes

    Entendi Marco. Em relação ao VoIP tem outra abordagem. 🙂

    0

    0
  8. Alexander Willians

    Simplesmente demais! Muito bom o recurso Marco!

    Parabéns pela matéria.

    []’s

    0

    0
  9. Minu

    Hoje pude ler com mais calma este artigo. É um ótimo recurso, irei testar aqui no meu lab virtual, como tudo que vou aprendendo aqui 🙂

    Abraços

    0

    0
  10. Rodrigo Farias

    Consegui rodar aqui no Dynamips!!
    Ja salvei o post aqui no meu pc pra não esquecer.
    Isso pode ser bastante útil num futuro próximo pra mim.

    Abraço!

    0

    0
  11. Éder Marcelo

    Marco, eu não conhecia a feature “ip sla transmiter/responder”, já utilizei o comando “ip sla monitor” para monitorar um link priorizado para internet (net ou speed por exemplo) e quando esse link ficasse down essa feature troca a rota default apontando para o link WAN por exemplo.

    Pergunta: Estamos falando da mesma feature?

    []’s

    0

    0
  12. Minu

    Eu estive pensando com meus botões. SLA seria uma ótima ferramenta para prover redundância entre links não?

    0

    0
  13. Marco Filippetti

    Minú, o que seus botões reposnderam?? rsrsrs SIM, IP SLA pode ser usado para projetar contigências. O legal do IP SLA é que você pode determinar que um caminho alternativo seja tomado não apenas em caso de falha do principal, mas baseado em outros fatores, como latência acima do esperado, jitter alto, etc.

    Abs!

    Marco.

    0

    0
  14. Diogo Cardozo

    onde posso pegar a imagem para fazer o lab? Não tenho acesso ao rapdshare e nem 4shared

    uga,

    Diogo

    0

    0
  15. Minu

    dcardozo,

    Você pode pegar aqui:
    http://files.studioworks.ru/files/cisco/IOS/

    0

    0
  16. Diogo Cardozo

    Consegui Minu blz

    0

    0
  17. Italo Amaral

    Legal também é ver isso funcionando no CiscoWorks – IPM, pois ele exige que o IP SLA seja configurando nos roteadores,

    Parabéns, excelente post!

    0

    0
  18. wstaenle

    Prezado !

    Utilizei o ip sla e surgiram alguns duvida , gostaria da ajuda de vcs !

    Configurei o ip sla e utilizei o track para derrubar a rota default para que uma segunda assumisse , isso funcionou perfeito , minha duvida agora é como monitorar isso atraves do nagios .

    Alem disso houve algumas ios que nao tem a opcao track , como fazer para habilitar nessa caso e como utilizo o comando rtr ? O rtr é a mesma coisa que o ip sla ?
    Agradeço

    0

    0
  19. rogeriorezende

    marco,

    Utilizo ip sla para contigencia de link’s Lan-to-Lan… mas sempre tentei fazer a monitoria destes links atraves do ip sla no nagios mas não consigo… li uma ves que eu teria que alterar a versão do ios para uma que tenha o ip sla monitor.. ainda não troquei o ios… mas minha duvida é se tem um geito de monitorar sem trocar a ios.. sabe qual smnp eu uso para monitorar o ip sla????

    0

    0
  20. Edson

    Esse artigo é muito legal!
    Obrigado pelas dicas Marco.

    Vou testar no Dynamips já já 🙂

    0

    0
  21. DavidSoaresBR

    Show!!

    0

    0
  22. roger da luz

    Estou estudando sobre como realizar o failover de link de internet através do IP SLA. VLew Marco mais uma vez ajudando de montão a galera.

    0

    0

Deixe uma resposta