Software Cisco IOS e NX-OS : Cisco IOS Embedded Event Manager (EEM)

Utilize EEM com IP SLA para pesquisar defeitos aletas ou perda de pacotes IGP através de um túnel VPN

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Muitos casos são abertos com o sintoma “aletas EIGRP/OSPF/BGP sobre meu túnel DMVPN/GRE/sVTI”. A fim pesquisar defeitos esta edição, a primeira pergunta que precisa de ser respondida é, “é esta um VPN, um protocolo de roteamento ou uma edição ISP?”

A maneira que esta pode ser testada é encontrar se o transporte subjacente ainda está funcionando corretamente durante a época do flap/indisponibilidade. Infelizmente, estes dados são geralmente cargo-evento revisto e são impossíveis determinar esta parte de dados. Este documento fornece a informação sobre o uso dos acordos do nível de serviço IP (SLA), dos objetos da trilha e do gerente encaixado do evento (EEM) a fim recolher esta informação durante a época da edição.

Nota: Contribuído pelo gaio Taylor novo, engenheiro de TAC da Cisco.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

  • IP SLA

  • EEM

Componentes Utilizados

A informação neste documento é baseada no código do Software Release 15.2(4)M de Cisco IOS� em uns 881, mas todo o código recente (15.0(1)M ou mais atrasado) terá este apoio.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Caracterize a informação

O IP SLA é os processos que são executado no roteador no fundo que testa um número de variação de condições de rede. Nesta Conectividade do IP geral do documento é testado usando o teste do “ICMP-eco”.

Em seguida que o estado IP o SLA está seguido usando um objeto da trilha. Então, usando um applet EEM, o estado da rede no buffer do Syslog puder ser gravado tomando ações quando as mudanças de estado do objeto da trilha.

Com o estado da rede incluído inline com os Syslog, você pode retro-ativo compreender o estado atual da rede durante o flap/indisponibilidade e determinar se havia um cripto, transporte, ou edição IGP.

Metodologia de Troubleshooting

http://www.cisco.com/c/dam/en/us/support/docs/ios-nx-os-software/ios-embedded-event-manager-eem/113696-eem-tshoot-igp-01.gif

Dois SLA separados são usados para seguir cada camada de conectividade IP:

  • Endereço IP público ao endereço IP público (172.18.3.52 ---> 172.20.5.43)

    ip sla 100
           icmp-echo 172.20.5.43 source-interface FastEthernet4
           frequency 5
       ip sla schedule 100 life forever start-time now
  • Endereço IP de Um ou Mais Servidores Cisco ICM NT do túnel para escavar um túnel o endereço IP de Um ou Mais Servidores Cisco ICM NT (10.1.12.100 ----> 10.1.12.1)

    ip sla 200
           icmp-echo 10.1.12.1 source-interface Tunnel100
           frequency 5
       ip sla schedule 200 life forever start-time now

Estes SLA enviarão a um único pacote de ping os segundos cada 5 aos pares definidos. Se o sibilo responde o SLA será " OK " marcado. Se não responde será “intervalo marcado”. Então, os objetos da trilha são usados para seguir o estado do SLA.

  • Endereço IP público à trilha de endereço IP público

    track 100 ip sla 100
         delay down 15 up 15
  • Endereço IP de Um ou Mais Servidores Cisco ICM NT do túnel para escavar um túnel a trilha do endereço IP de Um ou Mais Servidores Cisco ICM NT

    track 200 ip sla 200
         delay down 15 up 15

Quando o objeto da trilha muda, uma mensagem pode ser introduzida nos Syslog.

  • Endereço IP público à trilha de endereço IP público

    event manager applet ipsla100down 
        event track 100 state down
        action 1.0 syslog msg "Physical SLA probe failed!"
    event manager applet ipsla100up 
       event track 100 state up
       action 1.0 syslog msg "Physical SLA probe came up!"
  • Endereço IP de Um ou Mais Servidores Cisco ICM NT do túnel para escavar um túnel a trilha do endereço IP de Um ou Mais Servidores Cisco ICM NT

    event manager applet ipsla200down 
        event track 200 state down
        action 1.0 syslog msg "Tunnel SLA probe failed!"
    event manager applet ipsla200up 
       event track 200 state up
       action 1.0 syslog msg "Tunnel SLA probe came up!"

Análise de dados

Quando uma indisponibilidade ocorre, recolha a saída do comando show log.

Procure as mensagens SLA acima.

Durante a indisponibilidade, se você vê:

  • Falha ambos os SLA. Isto significa:

    • A Conectividade da camada 3 através do Internet entre os dois pares foi interrompida. Isto precisa investigações adicionais.

    • Não há nenhum problema com o túnel. Está falhando porque é uma vítima da interrupção acima.

  • O SLA físico não falha mas o túnel SLA faz. Isto significa:

    • A Conectividade da camada 3 através do Internet entre os dois pares está trabalhando corretamente.

    • Há um problema com o túnel. As investigações adicionais do túnel são necessárias.

  • Nenhumas da falha SLA. Isto significa:

    • A Conectividade da camada 3 através do Internet entre os dois pares está trabalhando corretamente.

    • A Conectividade do unicast da camada 3 através do túnel entre os dois pares está trabalhando corretamente.

    • A Conectividade do Multicast da camada 3 através do túnel é desconhecida. Isto pode ser testado sibilando o endereço de multicast usado pelo IGP.

    • Se os trabalhos de teste acima então isto indicam uma edição do aplicativo (EIGRP/OSFP/BGP). Uma investigação mais adicional do protocolo é necessária.

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 113696