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:
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.
22 comentários
Pular para o formulário de comentário
Show de bola…
Eu utilizo em alguns clientes de missão crítica, principalmente na questão de QoS.
Grande artigo.
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!
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
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
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
Autor
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.
Entendi Marco. Em relação ao VoIP tem outra abordagem. 🙂
Simplesmente demais! Muito bom o recurso Marco!
Parabéns pela matéria.
[]’s
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
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!
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
Eu estive pensando com meus botões. SLA seria uma ótima ferramenta para prover redundância entre links não?
Autor
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.
onde posso pegar a imagem para fazer o lab? Não tenho acesso ao rapdshare e nem 4shared
uga,
Diogo
dcardozo,
Você pode pegar aqui:
http://files.studioworks.ru/files/cisco/IOS/
Consegui Minu blz
Legal também é ver isso funcionando no CiscoWorks – IPM, pois ele exige que o IP SLA seja configurando nos roteadores,
Parabéns, excelente post!
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
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????
Esse artigo é muito legal!
Obrigado pelas dicas Marco.
Vou testar no Dynamips já já 🙂
Show!!
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.