(6) Comentários

Por André Ortega, 24/05/2011 09:14

Continuando o post sobre o EEM – Embedded Event Manager, vamos ver os scripts. Como já dito no post anterior, o script é feito usando o TCL – Tool Command Language e permite a criação de EEM Policies mais elaboradas.

No exemplo escolhido para ilustrar este post, usando um script EEM o roteador passará a enviar e-mails sempre que uma mensagem syslog SYS-5-CONFIG for gerada.

Repositório

A Cisco mantém um repositório onde podemos encontrar scripts criados pela comunidade. Qualquer um pode criar um script e enviar para que outras pessoas possam utilizar.

Neste repositório temos um template com a programação TCL pronta para que o roteador envie e-mail. Vamos fazer o download deste arquivo, e usá-lo como base neste exemplo.

Editando o Sendmail.tcl

Descompacte o arquivo e abra o sendmail.tcl em um editor de texto.

O autor deste script deixou ele pronto para ser executado manualmente (sem gatilho), mas os códigos para detecção de eventos já estão no arquivo. Assim, precisamos habilitar a linha para detectar syslog e indicar o tipo de mensagem que queremos verificar (*SYS-5-CONFIG.*). Você pode mudar isso de acordo com suas necessidades.

Depois vamos configurar para que o show running-config seja enviado no e-mail (o arquivo original envia o show version). Veja no vídeo abaixo.

Usando o Script EEM

1) Agora, usando um tftp server, pegue o arquivo editado e envie para a flash do roteador.

BrainRT01#copy tftp: flash:
Address or name of remote host [10.10.8.66]? 10.10.8.3
Source filename [brainwork_sendmail.tcl]?
Destination filename [brainwork_sendmail.tcl]?
Accessing tftp://10.10.8.3/brainwork_sendmail.tcl…
Loading brainwork_sendmail.tcl from 10.10.8.3 (via FastEthernet0/0): !
[OK - 5265 bytes]

5265 bytes copied in 0.588 secs (8954 bytes/sec)
BrainRT01#

2) Configure as variáveis utilizadas no script (ip do servidor de email, mail from e mail to).

BrainRT01# conf t
BrainRT01(config)#event manager environment _email_server 10.10.10.4
BrainRT01(config)#event manager environment _email_from BrainRT01@brainwork.com.br
BrainRT01(config)#event manager environment _email_to destinatario@brainwork.com.br
BrainRT01(config)#

Observe que o servidor deve estar configurado de forma aceitar que o roteador envie o e-mail.

3) Defina o diretório de uso e registre o Script.

BrainRT01(config)#event manager directory user policy "flash:/"
BrainRT01(config)#event manager policy brainwork_sendmail.tcl
BrainRT01(config)#

4) Pronto. Quando você sair do modo de configuração global será gerada uma mensagem syslog, notificando das configurações realizadas, o que iniciará a execução do Script.

BrainRT01(config)#exit
BrainRT01#
May 13 18:57:42.533: %SYS-5-CONFIG_I: Configured from console by admin on vty0 (10.10.8.3)
May 13 18:57:44.453: %HA_EM-6-LOG: brainwork_sendmail.tcl: Creating mail header…
May 13 18:57:49.441: %HA_EM-6-LOG: brainwork_sendmail.tcl: E-mail sent!
BrainRT01#

Não esqueça de usar o Terminal Monitor, se você estiver acessando o equipamento por Telnet/SSH. E se o e-mail demorar verifique se não foi classificado como SPAM.

O lado negro da força

Como toda ferramenta, o EEM pode ser usado para o bem e para o mal.

Tome cuidado ao baixar scripts da Internet. Scripts baixados de outros lugares que não o repositório Cisco, podem conter backdoor/trojan, permitindo acesso ao seu equipamento.

Aliás, recentemente no Web Security Forum, o Adilson Florentino, do Netfinders, fez uma apresentação chamada IOS Trojan – Quem é o dono do seu roteador? Nela o Adilson alertava justamente para o risco de alguém ter acesso ao seu equipamento e plantar um trojan, que permitiria acesso a sua rede.

É possível, por exemplo, criar um túnel GRE entre seu equipamento e um roteador qualquer, por onde o acesso passaria a ser realizado. Além disso o cracker pode manipular os comandos (show run, show ip int bri, dir) de forma que você não veja as alterações realizadas.

Parece difícil? Saiba que esse script já foi criado, e basta procurar no Google para encontrar o código, comentado inclusive.

Links

Criando scritps
http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_eem_policy_tcl.html

Repositório
http://forums.cisco.com/eforum/servlet/EEM

Até a próxima.

(6) Comentários

Por André Ortega, 16/05/2011 09:57

O EEM – Embedded Event Manager é um subsistema dentro do IOS, que permite monitorar eventos em real time, bem como executar medida corretivas ou informativas com base nestes eventos.

É possivelmente a funcionalidade mais “cool” que a Cisco já colocou no roteador. Com o EEM podemos criar ações customizadas para uma dezena de situações, tendo como limite apenas a imaginação.

Por exemplo, se uma interface fica down, automaticamente o roteador gera uma mensagem syslog. Mas com o EEM podemos criar uma política, onde além da mensagem, um e-mail seja enviado ou até mesmo que um mensagem seja enviada para o Twitter (sério, e isso já existe, veja o @myciscorouter).

Deu para perceber as possibilidades??

Além de ser executado automaticamente por gatilhos (eventos), também é possível executar o Applet ou Script manualmente, como veremos abaixo.

Alguns termos importantes

• EEM Policy: é uma entidade que define um evento e as ações a serem tomadas quando este evento ocorrer.
• Applet: forma mais simples de política, criada usando a própria CLI. Apenas um evento é permitido em no Applet.
• Script: é a política criada usando o TCL – Tool Command Language. É como uma linguagem de programação, e os scripts devem ser criados em um editor de texto. Depois são enviados para a flash e registrados no EEM.
• Event Detectors: programas usados pelo EEM para detectar quando um evento ocorre. São sistemas separados, que fazem a interface entre o EEM Agent e o EEM Policy. Exemplos de Event Detectors: CLI ED, Counter ED, GOLD ED, IP SLA ED, SNMP ED, entre outros.
• EEM Actions: ação configurada em uma política e executada após um evento monitorado. Exemplos de ações: executar um comando (ou conjunto de comandos), gerar um trap SNMP, reiniciar o roteador, enviar um e-mail.
• EEM Environment Variables: são variáveis que podemos usar nas políticas. Funcionam de forma similar as variáveis utilizadas em linguagens de programação. Existem variáveis pré definidas e também é possível criar variáveis.

EEM Applet – Gerando uma mensagem

Depois da introdução, vamos para prática. Como vocês devem ter percebido, o EEM é bem interessante, mas também pode ser complexo.

Este exemplo é apenas para iniciarmos, e não teria nenhuma aplicação prática.

Mensagem Syslog gerada através de um EEM Applet

BrainRT01#conf t
! No nome de conf global crie um applet e de um nome
BrainRT01(config)#event manager applet falha1
! Defina o evento, neste caso nenhum
BrainRT01(config-applet)# event none
! Defina a ação. Neste caso uma mensagem Syslog será gerada
BrainRT01(config-applet)# action TESTE syslog priority emergencies msg "TESTE APPLET"
BrainRT01(config-applet)#end
! No modo de configuração privilegiado execute o applet criado.
BrainRT01#event manager run falha1
BrainRT01#
May 12 18:12:27.503: %HA_EM-0-LOG: falha1: TESTE APPLET

EEM Applet – No shutdown automático

Este exemplo, mais elaborado, encontrei no blog anetworkerblog. Com ele uma interface que é colocada em administrativamente down, volta ficar UP automaticamente (imagina a cara do administrador…).

No shutdown em uma interface com EEM

BrainRT01#conf t
! Crie um applet
BrainRT01(config)#event manager applet No_shut_Lo0
! Defina o evento
BrainRT01(config-applet)#event syslog occurs 1 pattern "Loopback0, changed state to admin"
! Coloque as ações. Aqui temos um conjunto, onde geremos mensagens syslog e
! também comandos, que vão restaurar a interface
BrainRT01(config-applet)#action 1.0 syslog msg "Desabilitaram a Loopbackp0…"
BrainRT01(config-applet)#action 1.1 syslog msg "Vou fazer a lo0 ficar UP novamente, kkkk"
BrainRT01(config-applet)#action 1.2 cli command "enable"
BrainRT01(config-applet)#action 1.3 cli command "conf t"
BrainRT01(config-applet)#action 1.4 cli command "int lo0"
BrainRT01(config-applet)#action 1.5 cli command "no shut"
BrainRT01(config-applet)#action 1.6 syslog msg "Pronto, a Loopback 0 esta UP"
BrainRT01(config-applet)#end
BrainRT01#

Com este applet configurado, sempre que alguém dar um shutdown na interface Loopback0 o EEM vai perceber, através da mensagem gerada pelo roteador, e vai restaurar a interface com o comando no shutdown.

No próximo post vou falar sobre os scripts EEM (que permitem criar políticas mais elaboradas), com um exemplo bacana, e também sobre os riscos do Embedded Event Manager.

E se alguém quiser compartilhar applets/scripts fique a vontade.

Links

Introdução EEM
http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_eem_overview.html

Criando Applets
http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_eem_policy_cli.html

Até a próxima.

(4) Comentários

Por André Ortega, 14/03/2011 16:42

O Cisco Discovery Protocol (CDP) é um protocolo layer 2 que funciona independente do meio físico (Ethernet, Frame Relay, …) e do protocolo. Ele é usado para descobrir informações sobre equipamentos Cisco diretamente conectados e está presente em roteadores, switches, APs, firewalls e até em telefones.

Um equipamento com CDP ativado passará a enviar mensagens periódicas via multicast, e também receber os anúncios dos outros equipamentos. Desta forma é possível descobrir o nome, IP, modelo e a versão do software de um equipamento vizinho.

Podemos habilitar o CDP globalmente, e assim os anúncios passarão a ser enviados por todas as interfaces suportadas, ou podemos configurar apenas nas interfaces desejadas. Por padrão o CDP vem habilitado (globalmente), e já faz os anúncios na versão 2.

A versão 2 do CDP traz algumas melhorias e com ela podemos verificar a VLAN nativa, domínio VTP e o modo da porta (duplex/speed) do equipamento diretamente conectado.

Habilitando o CDP globalmente

BrainGW01#conf t
BrainGW01(config)#cdp run
BrainGW01(config)#

Desabilitando o CDP globalmente

BrainGW01#conf t
BrainGW01(config)#no cdp run
BrainGW01(config)#

Habilitando anúncios versão 2

BrainGW01(config)#cdp advertise-v2

Desabilitando anúncios versão 2

BrainGW01(config)#no cdp advertise-v2

Habilitando o CDP em uma interface específica

BrainGW01(config)#interface f0/1
BrainGW01(config-if)#cdp enable

Desabilitando o CDP em uma interface específica

BrainGW01(config)#interface f0/1
BrainGW01(config-if)#no cdp enable

Os comandos “shows” são os mais importantes/utilizados do CDP, já que a configuração normalmente não sofre alteração.

Verificando o CDP (status padrão)

BrainGW01#show cdp
Global CDP information:
        Sending CDP packets every 60 seconds
        Sending a holdtime value of 180 seconds
        Sending CDPv2 advertisements is enabled
BrainGW01#

Verificando o CDP em uma interface específica ( timers padrão)

BrainGW01#show cdp interface gigabitEthernet 1/0/1
GigabitEthernet1/0/1 is up, line protocol is up
  Encapsulation ARPA
  Sending CDP packets every 60 seconds
  Holdtime is 180 seconds
BrainRT01#

Verificando os equipamentos diretamente conectados (sumario)

BrainGW01#show cdp neighbors
Capability Codes: R – Router, T – Trans Bridge, B – Source Route Bridge
                  S – Switch, H – Host, I – IGMP, r – Repeater, P – Phone,
                  D – Remote, C – CVTA, M – Two-port Mac Relay

Device ID        Local Intrfce     Holdtme    Capability       Platform               Port ID
BrainSW1        Gig 1/0/48        152              S I            WS-C2960-          Gig 0/2
BrainSW8        Gig 1/0/45        121              S I            WS-C2960-          Gig 0/1
BrainGW02      Gig 1/0/26        179             R S I          2821                    Gig 0/1
BrainGW01#

Verificando os equipamentos vizinhos (detalhado)

BrainGW01#show cdp neighbors detail
————————-
Device ID: BrainSW1
Entry address(es):
  IP address: 10.10.10.59
Platform: cisco WS-C2960-24PC-L,  Capabilities: Switch IGMP
Interface: GigabitEthernet1/0/48,  Port ID (outgoing port): GigabitEthernet0/2
Holdtime : 158 sec

Version :
Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 12.2(50)SE4, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Fri 26-Mar-10 09:14 by prod_rel_team

advertisement version: 2
Protocol Hello:  OUI=0x00000C, Protocol ID=0×0112; payload len=27, value=00000000FFFFFFFF01022501000000000000ECC88212D480FF0000
VTP Management Domain: ‘brainwork’
Native VLAN: 1
Duplex: full
Management address(es):
  IP address: 10.10.10.59

Também é possível configurar os timers do CDP, e se necessário acompanhar a troca de pacotes através do comando debug cdp ip e debug cdp packets.

Mais informações sobre o CDP aqui e também neste link.

Até a próxima.

Atualização: O CDP também é muito útil quando temos telefones IPs Cisco e switches também Cisco. Neste cenário o CDP permite que o telefone seja associado a um VLAN de voz automaticamente (e normalmente nesta VLAN temos configurações específicas, como QoS).

E como bem lembrou o Fábio, no comentário abaixo, em alguns casos é recomendado que o CDP seja desabilitado, evitando que informações dos seus equipamentos sejam divulgadas e que a banda seja utilizada desnecessariamente.

(2) Comentários

Por André Ortega, 28/01/2011 10:07

Para reiniciar um roteador Cisco utilizamos o comando reload (modo privilegiado ou diagnostico). Mas além disso este comando tem alguns parâmetros que podem ser muito úteis.

Veja abaixo a principais opções do comando reload.

Verify: O comando reload verify faz com que o equipamento verifique a integridade do IOS antes de reiniciar o equipamento. Se a integridade não estiver ok o reload não é executado.

Exemplo: Verificar a integridade do software antes de reiniciar

BrainRT01#reload /verify

In: Ao usarmos o reload in podemos especificar em quanto tempo o reload será executado. Muito útil quando estamos trabalhando remotamente. Podemos deixar o reload programado, assim, se alguma alteração causar a perda do acesso, em algum tempo o equipamento reinicia e o acesso volta (desde que você não tenha salvo a cagada rsrsrsr).

Exemplo: Reiniciar em 20 minutos

BrainRT01#reload in 20

Cancel: O reload cancel pode fazer par com o reload in. Após um reload estar programado, se você não quiser que ele seja executado basta usar o comando reload cancel.

Exemplo: Cancelar um reload programado

BrainRT01#reload cancel

At: Programa o reload para um horário específico. Podemos usar um horário, no formato HH:MM ou ainda especificar o dia e mês.

Exemplo: Agendando um reload para horário específico

BrainRT01#reload at 20:30
ou
BrainRT01#reload at 15:20 feb 10

Reason: O argumento reason permite adicionar um comentário sobre o reload.

Exemplo: Adicionando um comentário ao reload

BrainRT01#reload reason Troca do IOS

Ainda existem outras opções, que podem ser verificadas no Command Reference da versão 12.4.

Até a próxima.

(2) Comentários

Por Leandro Oliveira, 10/01/2011 17:51

Há algum tempo atrás li um post no Blog CCNA introdutório a tecnologia HFC, como este é um assunto pouco difundido e uma das minhas promessas de ano novo é ajudar a turma aqui do blog e popular um pouco com meus posts (acho que esta vai ser mais fácil de cumprir do que aquela de perder alguns quilos.. ), resolvi pegar este assunto como foco e escrever sobre teoria e experiências de campo, sem estender mais o assunto vamos ao que interessa…

A sigla CMTS vem do inglês Cable Modem Termination System, basicamente trata-se de um roteador que centraliza toda a comunicação com os cable modems de uma estrutura HFC (como NET, TVA, Viacabo, TV Cidade entre outras) que muitos de nós possuímos em casa.

Analogamente aos sistemas ADSL das empresas Telco (Telefonica, GVT, Oi, CTBC) o CMTS faz o papel do DSLAM na topologia, a grande diferença nesta comparação esta no fato da tecnologia ADSL possuir um alcance (DSLAM – Modem) muito inferior as tecnologia HFC (CMTS – Modem) e o fato de em uma tecnologia utilizar um cabo dedicado para cada modem (ADSL) e a outra compartilhar as frequências de um mesmo cabo (Cable), as diferenças não param por aí, mas este não é o foco deste post.

Em uma rede HFC (padrão NTSC) as frequências possuem um tamanho de 6 MHz e são basicamente divididas em sinais analógicos e sinais digitais, os sinais analógicos são aqueles utilizados pelos antigos sistemas de CATV (mas ainda continuam a ser utilizados por muitos operadores de cabo) e apenas um canal de TV pode ser transmitido em 6MHz. O sinal digital possui o mesmo tamanho do analógico, porem quando utilizado para transmissão de TV este pode “carregar” um número maior de canais de TV.

Para transmissão de dados o CMTS realiza a geração de sinais digitais no sentido Downstream (tráfego do CMTS para o Modem) e recebe sinais digitais no sentido Upstream (tráfego do Modem para o CMTS). Para se ter uma idéia, cada frequência no sentido Downstream pode transportar até 38 Mbps de dados e em um cabo coaxial as frequências de Downstream iniciam-se em 54 MHz e podem chegar até 1000 Mhz (1 GHz) (saltando de 6 em 6 MHz), ou seja, é muita banda… No caso do Upstream o spectrum disponível é muito menor (de 5 MHz até 42 MHz) e o tamanho do canal pode variar de 0,8 MHz até 6,4 MHz, o que faz todo sentido visto que o envio de informações para a Internet é muito menor do o recebimento.

O protocolo utilizado para realizar a transmissão dos dados sobre a rede HFC é denominado DOCSIS e toda padronização para esta indústria é realizado por um órgão sem fins lucrativos chamado CableLabs que foi fundado em 1988 e é mantido pelos próprios operadores de cabo. Fazendo uma analogia ao modelo OSI e para entendermos melhor como o TCP/IP se encaixa na brincadeira temos a imagem ilustrada abaixo.

Em outras oportunidades vamos entender melhor como a transmissão de dados é realizada e quanto de banda efetivamente temos disponível para este processo. Até mais…