TCL Script - Desabilitar interface E1 caso ping falhe

Bom dia amigos,

Estou precisando de um help.

Fazer um script que ping nos hosts (exemplo 10.0.0.1 e 10.0.0.2). Caso o ping falhe, ele de um SHUT na minha int s0/0, caso ok, verifique se a s0/0 esta up, nao faz nada, caso down, dê NO SHUT na int s0/0

tclsh
proc teste {} {
foreach ips {
10.0.0.1
10.0.0.2
} { set result [ string first "!!!" [exec ping $ips timeout 3 ] ]
if { $result == -1 } {
puts "link down"
} else {
puts "link UP"
}}}
teste
tclquit


Comecei a fazer ele dando uma mensagem(puts),mas para executar o comando para subir ou descer a placa, alem de ver o status eu to todo enrolado. E pra ficar mais dificil, colocar o script no KRON para rodar a cada 5 minutos.

Procuro fazer isto para transbordo automatico do VoIP quando a minha plataforma estiver fora, eu nao ter q ta ligando pro cliente pra pedir pra ele retirar o cabo do meu equipamento, ja que so tenho a placa de 1 E1 no equipamento.

Desde ja agradeço a todos

Qual é o equipamento e versão?

Abraços

Router Cisco 2801 Version 12.4(13r)T

Se fizer por TCL,vpode-se usar o ios_config para alterar a config. Mas sobre colocar em loop ou no cron, não sei.

exemplo:
ios_config "interface serial 0/0" "shutdown"
ios_config "interface serial 0/0" "no shutdown"

No seu caso, talvez, compense shutar a controller ao invés da interface.


Se for apenas para dar um recycle na interface (shut/no shut), eu não faria com TCL. Para isso, acho que usaria Embedded Event Manager (EEM).

Eu criaria um objeto, usando IP SLA para monitorar e, dependendo da versão de seu IOS, você pode usar o track no objeto para detectar o estado ou mesmo fazer baseado em SNMP, usando o OID para saber sobre o resultado do IP SLA então, via EEM, shutaria a interface e então, no shut.


exemplo:


Fonte: http://blog.ioshints.info/2011/05/router-reload-after-15-minutes-of.html

ip sla 10
icmp-echo 10.255.251.64 source-interface Loopback0
request-data-size 16384
frequency 10
ip sla schedule 10 life forever start-time after 00:30:0


event manager applet vodafone_down_RELOAD
event snmp oid 1.3.6.1.4.1.9.9.42.1.2.9.1.6.10
get-type exact entry-op lt entry-val "2" poll-interval 10
trigger occurs 179 period 1790
action 01.0 syslog msg "No ping response last 30 min."
action 02.0 syslog msg "Reloading now to see if things get better..."
action 03.0 reload



No seu caso, seria mais ou menos como acima, apenas alterando as mensagens de log e o OID. Bem como readequando o IP SLA.

exemplo de ações baseado no event:

action 1.0 syslog msg "No ping response for the last 10 minutes"
action 1.1 syslog msg "Recycling the interface se0/0 in order to see if things get better..."
action 1.2 cli "enable"
action 1.3 cli "configure terminal"
action 1.4 cli "interface serial 0/0"
action 1.5 cli "shutdown"
action 1.6 cli "no shutdown"





Olha um exemplo legal que uma notificação via e-mail para interfaces que tiverem mais de 2 CRCs por minuto:

FONTE: http://blog.ioshints.info/2011/07/monitor-multiple-interfaces-with-single.html

event manager environment _email_server 10.10.10.10
event manager environment _email_to lan_admin@example.com
event manager environment _info_routername Router
!
event manager applet multiple_if
event tag if_1 interface name Serial0/0/0 parameter input_errors_crc ?
entry-op ge entry-val 2 entry-type increment poll-interval 60
event tag if_2 interface name Serial0/0/1 parameter input_errors_crc ?
entry-op ge entry-val 2 entry-type increment poll-interval 60
event tag if_3 interface name Serial0/0/2 parameter input_errors_crc ?
entry-op ge entry-val 2 entry-type increment poll-interval 60
event tag if_4 interface name Serial0/0/3 parameter input_errors_crc ?
entry-op ge entry-val 2 entry-type increment poll-interval 60
event tag if_5 interface name Serial0/1/0 parameter input_errors_crc ?
entry-op ge entry-val 2 entry-type increment poll-interval 60
event tag if_6 interface name Serial0/1/1 parameter input_errors_crc ?
entry-op ge entry-val 2 entry-type increment poll-interval 60
trigger
correlate event if_1 or event if_2 or event if_3 or event if_4 or ?
event if_5 or event if_6
action 1.0 syslog msg "CRC failure leased line $_interface_name"
action 2.0 mail server "$_email_server" to "$_email_to" ?
from "$_info_routername@example.com" ?
subject "CRC problems on $_info_routername interface $_interface_name" ?
body "CRC failures have exceeded the threshold"




Eu também fiz uns testes básicos com o EEM baseado em mensagem de log e funcionou.

Mais tarde, tentarei reproduzir o seu ambiente, usando IP SLA juntamente com EEM.
Dependendo da versão, dá pra usar o "track" direto, mas acho difícil, pois só tem pra IOSes muito novos (não sei a versão exata). Mas dá pra fazer via SNMP, como o primeiro exemplo mostra.

Abraços,

Correção!!!

Citação :

OID. Bem como readequando o IP SLA.

exemplo de ações baseado no event:

action 1.0 syslog msg "No ping response for the last 10 minutes"
action 1.1 syslog msg "Recycling the interface se0/0 in order to see if things get better..."
action 1.2 cli "enable"
action 1.3 cli "configure terminal"
action 1.4 cli "interface serial 0/0"
action 1.5 cli "shutdown"
action 1.6 cli "no shutdown"

Na parte exibida acima, o comando seria: action <ID> cli command "comando"
Lembrando que tem que ser sequencial, como se você estivesse entrando com os comandos.

Não prometo quando, mas tentarei reproduzir em lab mesmo... é algo bem itneressante.


Basicamente:

criar um IP SLA para testar o ping, de tempos em tempos

criar o EEM para checar o status do IP SLA. Se estiver fora da SLA, dá um recycle da interface.

Criar um ip sla schedule com "after", para que após o recycle da interface é executado, o valor do IP SLA possivelmente ainda ficará inalterado até que ele consiga pingar novamente. Com o schedule, dará um tempo para o IP SLA saia de seu estado anterior sem que fique sempre dando shut/no shut na interface...

Agora vai!!! Mais um post loooongo, mas interessante.


Fiz o teste!! E FUNCIONOU

Como não sabia qual era o SNMP OID para o IP SLA e ia perder um tempo para procurar, resolvi fazer baseado em mensagem de log mesmo.

Bom... Existem diversas maneiras de se fazer, cada qual com seus prós e contras.

Com certeza tem muito o que melhorar, mas o esqueleto é isso aí.
Tente melhorá-lo, se gostar do mesmo, claro!!!!


=================================

Config completa:


logging buffer debug
ip sla monitor logging traps

ip sla monitor 10
type echo protocol ipIcmpEcho 1.1.1.1 source-ipaddr 2.2.2.2
frequency 30
timeout 2000

ip sla monitor schedule 10 life forever start-time after 00:30:00

ip sla monitor reaction-configuration 10 react timeout threshold-type consecutive 3 action-type trapOnly


event manager applet RECYCLE_INTERFACE
event syslog pattern "condition occurred, entry number = 10"
action 1.0 syslog msg "No ping response for the last 1.5 minute."
action 2.0 syslog msg "Recycling the loopback0 interface via EEM RECYCLE_INTERFACE"
action 3.0 cli command "enable"
action 4.0 cli command "conf t"
action 5.0 cli command "int lo0"
action 6.0 cli command "shut"
action 7.0 cli command " no shut"




=================================




EXPLICANDO...

Primeiramente, já que estou me baseando em syslog, obrigatoriamente, devo habilitar logging e trapping para IP SLA. Caso contrário, não funciona, pois a mensagem não será gerada, por consequência, o EEM, que monitora o syslog, não vai startar.


Habilitando log:

logging buffer debug



Habilitando syslog:

ip sla monitor logging traps



Criando o IP SLA:


ip sla monitor 10
type echo protocol ipIcmpEcho 1.1.1.1 source-ipaddr 2.2.2.2
frequency 30
timeout 2000


Criei o IP SLA (identificação 10) para pingar o IP 1.1.1.1 com origem, o IP 2.2.2.2. O ping possui um timeout de 2 segundos e é executado a cada 30 segundos.
Não é necessário usar source, mas é bom. Se for usar, tenha certeza de usar o de loopback (Que sempre fica up).
Pode-se usar outras opções... Se você estiver usando isso para voz e usando QoS, aconselho marcar o pacote via o comando "tos", dentro do ip sla. Dessa maneira, o ping será tratado na policy dedicada para voz. Em casos de congestion, se estiver na classe default, ele pode se perder, mesmo que o tráfego de voz, na priority queue, não tenha qualquer impacto. Isso faria com que a interface fosse bounceada sem a real necessidade, impactando o tráfego de voz.
Também tem diversos tipos de monitoração, como Jitter, o que é mais adequado para ambiente de voz.
Tenha certeza também de que o ping passará pela interface e que não tenha qualquer outra redundância, fazendo com que o mesmo continue pingando, mesmo com problema no circuito.
Tenha certeza de que o teste representa realmente o que você quer. Pingue os IPs se realmente os mesmos forem imprescindíveis para o funcionamento de voz. Não use qualquer IP, já que você pode pingar algum que não esteja diretamente conectado e o problema pode ser remoto, e não local. Dê preferência para testes o mais prózimo possível da interface.





Definindo o período de monitoração:


ip sla monitor schedule 10 life forever start-time after 00:30:0


Fiz com que ele faça essa checagem sempre (life forever). Porém, note que coloquei o "after" com 30 minutos. Isso está aí, pois caso o roteador venha a rebootar, leva algum tempo para que os protocolos de roteamento subam. Melhor dar um tempinho para que tudo esteja estável antes de iniciar a monitoração.
O número 10, é o identificador.




Gerando log:


ip sla monitor reaction-configuration 10 react timeout threshold-type consecutive 3 action-type trapOnly


Agora, configurei o "reaction". Isso informa como devem ser tratadas as respostas do IP SLA. Sem isso, por exemplo, não gera log ou traps.
Neste caso, eu configurei para reagir com timeouts. Configurei para que, quando detectar timeout, que espere por 3 tentativas consecutivas. Caso as 3 continuem no mesmo estado, isto é, continuem em timeout, ele gera um trap (loga e trap). NEste caso, demoraria, ao menos, 1.5 minuto para gerar um trap, já que o IP SLA está configurado para checar a cada 30 segundos.

Outra forma legal, seria configurar a opção "xOfy" ao invés de "consecutive". Imagine que você possua um problema intermitente. Com o "consecutive", se apenas 1 ping tiver sucesso, zera tudo, e o processo não starta, tendo que esperar por mais 3 perdas consecutivas. No seu caso, não se se aplica, já que se o problema for intermitente, não é um simples shut/no shut que resolverá. Mas dá pra te mandar uma notificação ou você inventa qualquer coisa




Gerando o EEM:

Por fim, configurei o EEM, que nada mais é do que TCL scripts, mas embutidos em comandos, para facilitar.
Note que usei como "pattern" a mensagem de log gerada pelo IP SLA. O número 10, é do identificador do mesmo.
Logo em seguida, configurei duas mensagens para ficar no log. Uma delas informa que não há resposta de ping por 1.5 minuto, e outra informando que a interface está sendo bounceada pelo EEM RECYCLE_INTERFACE.
Depois, seguem os comandos, como se fosse alguém digitando no terminal. No meu caso, o lab foi feito com a loopback 0.

event manager applet RECYCLE_INTERFACE
event syslog pattern "condition occurred, entry number = 10"
action 1.0 syslog msg "No ping response for the last 1.5 minute."
action 2.0 syslog msg "Recycling the loopback0 interface via EEM RECYCLE_INTERFACE"
action 3.0 cli command "enable"
action 4.0 cli command "conf t"
action 5.0 cli command "int lo0"
action 6.0 cli command "shut"
action 7.0 cli command " no shut"





===================================



VALIDANDO:

Abaixo, segue o teste que fiz, para validar:


CE01 é o roteador que fará o recycle na interface loopback0.
Loopback0 possui o IP 1.1.1.1
Usei a Loopback 1 para ser o source 2.2.2.2


Mostrando que está tudo ok:

CE01#sh ip int bri
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.1.1.1 YES manual administratively down down
FastEthernet0/1 unassigned YES unset administratively down down
Loopback0 1.1.1.1 YES manual up up
Loopback1 2.2.2.2 YES manual up up

CE01#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/44/120 ms


Note o status mostrando OK (campo Latest operation return code:):

CE01#sh ip sla mon st
Round trip time (RTT) Index 10
Latest RTT: 4 ms
Latest operation start time: 00:01:04.267 UTC Thu Sep 22 2011
Latest operation return code: OK
Number of successes: 2
Number of failures: 0
Operation time to live: Forever



Derrubando o host 1.1.1.1.

CE01#conf t
Enter configuration commands, one per line. End with CNTL/Z.
CE01(config)#int lo0
CE01(config-if)#shut
CE01(config-if)#
CE01#


CE01#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)



Logo em seguida, já é exibida 1 falha, mas nada de log, pois deverá logar apenas após 3 falhas consecutivas:


CE01#sh ip sla mon st
Round trip time (RTT) Index 10
Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: 00:01:34.267 UTC Thu Sep 22 2011
Latest operation return code: Timeout
Number of successes: 2
Number of failures: 1
Operation time to live: Forever



Após um minuto e meio, isto é, 3 falhas consecutivas, é gerado um log e todo o processo é startado:

Logando IP SLA:

Sep 22 00:02:36: %RTT-4-OPER_TIMEOUT: condition occurred, entry number = 10
Sep 22 00:02:36: %RTT-3-IPSLATHRESHOLD: IP SLA Monitor(10): Threshold for timeout


Executando o EEM. Logando as mensagens de aviso que configuramos:

Sep 22 00:02:36: %HA_EM-6-LOG: RECYCLE_INTERFACE: No ping response for the last 1.5 minute.
Sep 22 00:02:36: %HA_EM-6-LOG: RECYCLE_INTERFACE: Recycling the loopback0 interface via EEM RECYCLE_INTERFACE

Como existiu alteração de config (shut/no shut), loga:

Sep 22 00:02:36: %SYS-5-CONFIG_I: Configured from console by vty0



Interface subindo:

Sep 22 00:02:38: %LINK-3-UPDOWN: Interface Loopback0, changed state to up
Sep 22 00:02:39: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up



IP SLA de volta ao estado normal:

Sep 22 00:03:04: %RTT-4-OPER_TIMEOUT: condition cleared, entry number = 10
CE01#
Sep 22 00:03:04: %RTT-3-IPSLATHRESHOLD: IP SLA Monitor(10): Threshold for timeout



Checando, nota-se que existiram, exatamente, 3 falhas, startando todo o processo.(elas são cumulativas. Neste caso, foi a primeira falha).

CE01#sh ip sla mon st
Round trip time (RTT) Index 10
Latest RTT: 3 ms
Latest operation start time: 00:06:04.267 UTC Thu Sep 22 2011
Latest operation return code: OK
Number of successes: 9
Number of failures: 3
Operation time to live: Forever







Espero ter ajudado.


Abraços,

Ronaldo,

Cara, vc se garante. Parabéns pela dedicação e força que nos dá nesse forum.

Verdadeiramente você dá aula parceiro.

Estou verde ainda em cisco (CCNA), mas estudando sempre.

Pesquisei bastante e não conseguia juntar as informações.

E a sua explicação foi nota 1000.

Vou implementar aqui sua solução e com certeza vai rodar, trocando a somente a interface q nao é a loopback.

Assim que fizer posto aqui novamente minha gratidão a você e todos os amigos do forum.

Abraço chefe.

Opa! Fico a disposição e feliz pelo feedback.

Implemente lá e depois mande notícias.

Abraços,

ronaldobf escreveu:

Opa! Fico a disposição e feliz pelo feedback.

Implemente lá e depois mande notícias.

Abraços,

Grande Ronaldo,

Funcionou 100%, mais uma vez obrigado pela força e atenção dada...Deixo um site que também me ajudou, apesar de seu passo a passo ter sido o bastante para a implementação.Obrigado

http://blog.ccna.com.br/2008/07/28/cisco-ios-ip-sla-tool/

Legal que funcionou!

Obrigado por informar.

Abraços