quinta-feira, 20 de novembro de 2008

Cisco IP SLA

Conhecida antes da versão 12.4T como RTR (Response Time Report) e SAA (Service Assurance Agent), a ferramenta de monitoração Cisco IP SLA (Service Level Agent) é utilizada para fazer monitoração ativa de tempo de resposta via ICMP (ou utilizando outras aplicações como HTTP e DNS), jitter (inclusive jitter unidirecional), perda de pacotes, etc. diretamente em um roteador Cisco, ou seja, sem depender de um outro software ou servidor para fazer a colheta destas informações. Apesar das informações estarem disponíveis no roteador, é também interessante utilizar alguma ferramenta para gerar um gráfico, como o MRTG ou Cacti, para deixar o seu chefe ainda mais feliz! :-)

Configurando o IP SLA

Vamos ver um exemplo de configuração para medir o tempo de resposta entre dois pontos utilizando a ferramenta para medir jitter do IP SLA. Entenda dois pontos como um circuit ponto-a-ponto ou dois pontos quaisquer na Internet. Veja a configuração:

! criamos a monitoração 100 para o endereço IP 10.10.10.1
!
ip sla 100
icmp-jitter 10.10.10.1 source-ip 192.168.1.1 num-packets 20
frequency 300
!
! então é necessário ativar a monitoração recém criada
!
ip sla schedule 100 start-time now life forever

Depois de criarmos a monitoração e ativá-la, podemos verificar se está funcionando e como está o nosso tempo de resposta e perda de pacotes com o comando show ip sla statistics 100.

Router#sh ip sla statistics 100

Round Trip Time (RTT) for Index 100
Type of operation: icmpJitter
Latest RTT: 230 milliseconds
Latest operation start time: 13:04:36.499 BRST Wed Nov 26 2008
Latest operation return code: OK
RTT Values:
Number Of RTT: 13 RTT Min/Avg/Max: 325/354/413
Latency one-way time:
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0
Destination to Source Latency one way Min/Avg/Max: 0/0/0
Jitter Time:
Number of SD Jitter Samples: 9
Number of DS Jitter Samples: 9
Source to Destination Jitter Min/Avg/Max: 1/5/17
Destination to Source Jitter Min/Avg/Max: 0/25/71
Packet Late Arrival: 0
Out Of Sequence: 0
Source to Destination: 0 Destination to Source 0
In both Directions: 0
Packet Skipped: 0 Packet Unprocessed: 7
Packet Loss: 0
Loss Period Length Min/Max: 0/0
Number of successes: 1
Number of failures: 0
Operation time to live: Forever

As informações que queremos observar estão destacadas em azul.

Gerando os Gráficos

Para continuar este exemplo, vamos gerar um gráfico das informações de RTT (round-trip time) máximo e mínimo. Para isso, vamos utilizar o MRTG e os OIDs:
  • rttMonLatestIcmpJitterRTTMin.XXX ou 1.3.6.1.4.1.9.9.42.1.5.4.1.4.XXX para medir o RTT mínimo da instância XXX (no nosso caso a instância 100).
  • rttMonLatestIcmpJitterRTTMax.XXX ou 1.3.6.1.4.1.9.9.42.1.5.4.1.5.XXX para medir o RTT máximo da instância XXX.
A configuração do MRTG utilizada foi:

# IP SLA 100
Target[rtt_mon_100]:1.3.6.1.4.1.9.9.42.1.5.4.1.4.100&1.3.6.1.4.1.9.9.42.1.5.4.1.5.100:community@192.168.1.1:
MaxBytes[rtt_mon_100]: 350
AbsMax[rtt_mon_100]: 2000
YLegend[rtt_mon_100]: Round Trip Time
ShortLegend[rtt_mon_100]: ms
LegendI[rtt_mon_100]: min rtt (ms):
LegendO[rtt_mon_100]: max rtt (ms):
Legend1[rtt_mon_100]: min rtt (ms)
Legend2[rtt_mon_100]: max rtt (ms)
Title[rtt_mon_100]: Tempo de Resposta - IP SLA 100


Para a monitoração que configuramos anteriormente, podemos obter um gráfico que nos mostrará o tempo de resposta mínimo (em verde) e o máximo (em azul). Deste gráfico podemos ter uma idéia de como está o jitter para um determinado circuito ou caminho.
Com esta simples monitoração é possível observar a variação do tempo de resposta com o passar do tempo (veja figura 1 no período entre 18:00 e 22:00 horas) ou ainda verificar que um determinado caminho está congestionado - com alterações no tempo de resposta, principalmente durante certos períodos (veja figura 2).

Figura 1

Figura 2

Para mais informações:

quarta-feira, 12 de novembro de 2008

Monitoração de prefixos BGP na Internet

O Problema

Depois dos diversos problemas de sequestro de prefixos BGP na Internet - como o famoso caso YouTube versus Pakistan Telecom - as ferramentas de monitoração de prefixos BGP, gratuitas ou pagas, ganharam mais visibilidade entre os administradores de rede ao redor do mundo. E nesta última terça-feira, 11 de novembro às 2:00 horas GMT, uma destas ferramentas começou a disparar inúmeros alertas alegando que o AS16735 havia sequestrado uma grande quantidade de prefixos (mais de 50% dos prefixos existentes na Internet). Veja um exemplo do alerta gerado pelo BGPmon:

You Receive this email because you are subscribed to BGPmon.net.
For more details about these updates please visit:
http://bgpmon.net/showupdates.php

====================
Possible Prefix Hijack (Code: 11)
1 number of peer(s) detected this updates for your prefix
10.10.80.0/20:
Update details: 2008-11-11 02:24 (UTC)
10.10.80.0/20
Announced by: AS16735 (Companhia de Telecomunicacoes do
Brasil Central)
Transit AS: 27664 (CTBC Multimídia)
ASpath: 27664 16735
=====================
Como os administradores que receberam estes alertas não conseguiram alcançar o AS16735, logo assumiram que o sequestro realmente tinha acontecido, já que ao verificar a situação dos prefixos sequestrados no RIS (ferramenta do RIPE) ou no looking glass do PTT-Metro, também constataram que o AS-path (27664 16735 ou ainda 22548 16735) não estava correto.

Os Fatos

O primeiro fato interessante é que tanto o AS27664 e quanto o AS22548 são clientes de trânsito do AS16735 e os dois primeiros (AS27664 e o AS22548) estão alimentando com a tabela BGP completa o projeto RIS do RIPE no PTT-Metro (rrc15). Isso significa que tanto para o RIS quanto para o BGPmon (que utiliza as informações do RIS para monitorar e gerar os alertas) ínumeros prefixos da tabela BGP passaram a ser anunciados pelo AS16735 - o que comumente é conhecido como leaking (ou vazamento) da tabela BGP. Já que o AS16735 não possui autoridade administrativa sobre estes prefixos, podemos supor então que houve um re-anúncio da tabela BGP, este último causado por algum problema interno ao AS16735.

Esse sequestro de prefixos, no entanto, não foi percebido em nenhum outro ponto da Internet - ficando restrito ao AS16735 e seus clientes, como é o caso do AS27664 e AS22548 - graças aos filtros existentes na maioria dos sistemas autônomos ou grandes operadoras de telecomunicações. Ainda de acordo com as análises do BGPmon e da Renesys, este problema durou aproximadamente 5 minutos. Mas, mesmo depois deste período, muitos outros sistemas autônomos continuaram não alcançando a rede do AS16735, pois grande parte do AS16735 não estava acessível em razão de outros problemas. E este último fato aumentou consideravelmente o burburinho sobre este problema.

As Lições Aprendidas

A primeira grande lição é não confiar somente em uma fonte de informação, como foi o caso de muita gente. Para ter certeza do problema, verifique a informação nos mais diversos servidores de looking glass espalhados pelo mundo. Como exemplo, o primeiro looking glass que eu verifiquei naquela madrugada, sequer soube da existência do AS16735 no caminho destes inúmeros prefixos... Mesmo assim, esse tipo de problema não deve ser subestimado.

É interessante também utilizar vários sistemas de monitoração e verificação dos prefixos na tabela BGP da Internet, desde que estes sistemas sejam alimentados por fontes de informação diferentes (esse não foi o caso do RIS, BGPmon ou do Looking Glass do PTT-Metro). Alguns exemplos de ferramentas disponíveis para verificação são: Internet Alert RegistryWatchMY.net, BGPmon e PHAS.

Por último (e já não tão relacionado com o que acabei de descrever) fica a dica de uma ferramenta (ainda beta) para visualização mais amigável das informações colhidas pelo projeto RIS e pode ser acessada da página principal do projeto, entrando com a informação de número de AS ou prefixo próximo ao canto superior direito.


Tela da ferramenta de visualização do RIS/RIPE.

Atualizado em 13/Nov/2008:

Ontem a noite, algumas horas depois de terminar este post, Danny McPherson publicou no blog da Arbor Networks uma análise muito semelhante a exposta acima, no entanto, ele acrecentou um ponto que eu também gostaria de destacar aqui:

Toda esta confusão só poderá ser evitada com a utilização de uma solução segura para roteamento entre-domínios (ou sistemas autônomos). E este padrão está em fase de desenvolvimento dentro do IETF, mais especificamente através do grupo SIDR (Secure Inter-Domain Routing). Queria destacar também a apresentação do Ricardo Patara (do LACNIC) na última reunião do GTER sobre este tema. Vale a pena dar uma olhada!

Mais informações em:

terça-feira, 11 de novembro de 2008

Adicionando as buscas da Cisco no seu Browser

Agora podemos fazer buscas na página web da Cisco diretamente na barra de endereços do seu browser. Por enquanto disponível apenas para Firefox e Internet Explorer. As buscas possíveis são:

Ferramentas (conteúdo fechado, é necessário possuir uma conta CCO para acessar)

Buscas

Mais informações na página da Cisco: http://www.cisco.com/web/tsweb/searchplugins/plugin_homepage.html#

segunda-feira, 3 de novembro de 2008

O que mudou ?

Este post, de certa forma, completa dois outros antigos posts publicados aqui: o primeiro deles sobre o Replace e o Rollback da configuração de roteadores Cisco e o segundo post sobre a ferramenta de backup de configuração open-source chamada Rancid. Desde a versão 12.3(4)T do Cisco IOS é possível utilizar o próprio CLI para saber o que mudou no seu roteador da seguinte forma:

Router#show archive config differences

Vejamos um exemplo:

Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#int fa0/0
Router(config-if)#ip address 172.16.0.1 255.255.255.0
Router(config-if)#^Z
Router#show archive config differences nvram:startup-config system:running-config
Contextual Config Diffs:
interface FastEthernet0/0
+ip address 172.16.0.1 255.255.255.0
+ip route 192.168.2.0 255.255.255.0 172.16.1.10
interface FastEthernet0/0
-ip address 192.168.0.1 255.255.255.0
Hum. Alguém já havia alterado a rota 192.168.2.0 deste roteador (e não tinha salvado a configuração!!!), além da configuração que acabamos de alterar (endereço IP da interface Fa0/0). Este é somente um exemplo de uma configuração extremamente simples, mas podemos imaginar a ajuda que podemos ter em configurações mais complexas e em grandes mudanças.

Outro ponto importante desta feature é o fato de conseguirmos comparar a configuração atual (running-config) com uma configuração armazenada em um servidor TFTP. Se combinarmos as configurações armazenadas no Rancid com a opção de comparar a configuração direto no roteador, temos uma poderosa ferramenta em mãos.

Router#show archive config differences tftp://10.1.1.1/Router.bkp system:running-config
(...)

Mais informações em:

Aumentando a velocidade do show running-config

Muitas vezes nos deparamos com um equipamento que possui muitas linhas de configuração e, ao executar um comando de show running-config, demora muito para que o comando retorne a configuração atual além do que gera uma carga adicional de processamento ao equipamento.

A partir das versões 12.2(25)S, 12.2(27)SBC e 12.3(7)T é possível otimizar esta operação criando um cache da configuração atual, o que reduz em até 90% o tempo de execução de um show running-config (efetuei testes em laboratório e o tempo diminui de 30 segundos para 3 segundos).

Router(config)# parser config cache interface

Após a aplicação deste comando é preciso executar um primeiro show run para que seja criado o cache. Todos os show running posteriores devem ter um ganho de performance (obs: será consumido uma parcela da memória do equipamento para este cache).

Link:
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gtinvgen.html