Laboratorio de Netflow y SNMP vía PRTG

Fecha: 22 de diciembre del 2015 Clase: CCNA 4 R&S y Especialización en datacenters

 

Escenario

 

Este escenario se realizó para tratar temas de SNMP y Netflow correspondientes a los módulos de administración

de redes de CCNA 4 R&S y la especialización de datacenters.

Se configuró un equipo Cisco 2901 como gateway de la red del aula y se analizó con NetFlow tanto el tráfico entrante

en la Gi0/0 (inside) como el saliente en la Gi0/1 (outside). Este último está traducido (nateado) a la dirección de la

interface y por lo tanto, en este última variante no se discriminan los hosts involucrados en la demanda de tráfico.

Esto se realizó para tener la capacidad de determinar donde colocar un sensor en una determinada infraestructura

y evaluar los efectos debido a su ubicación.

 

 

 

Configuración del router (sólo lo mas relevante)

 

Aula7b#sh runn

Building configuration...

 

Current configuration : 1541 bytes

!

version 15.1

!

hostname Aula7b

!

ip dhcp pool DHCP

   network 192.168.72.0 255.255.255.0

   default-router 192.168.72.253

   dns-server 8.8.8.8

!

interface GigabitEthernet0/0

 ip address 192.168.72.253 255.255.255.0

 ip flow ingress (se analiza el tráfico sin ‘natear’ con las IP reales)

 ip nat inside

!

interface GigabitEthernet0/1

 mac-address fc75.1620.8209

 ip address 192.168.0.72 255.255.255.0

 ip flow egress (se analiza el tráfico ya ‘nateado’)

 ip nat outside

!

ip flow-export version 9

ip flow-export destination 192.168.72.168 9996

!

ip nat inside source list 10 interface GigabitEthernet0/1 overload

ip route 0.0.0.0 0.0.0.0 192.168.0.1

!

access-list 10 permit 192.168.72.0 0.0.0.255

!

snmp-server community public RW

snmp-server trap link ietf

snmp-server host 192.168.72.168 version 2c public

!

line vty 0 4

 access-class 10 in

 login local

 transport input ssh

!

 end

 

Aula7b#  

 

Verificación:

 

Aula7b#sh ip flow export

Flow export v9 is enabled for main cache

  Export source and destination details :

  VRF ID : Default

    Destination(1)  192.168.72.168 (9996)

  Version 9 flow records

  1237129 flows exported in 123380 udp datagrams

  0 flows failed due to lack of export packet

  0 export packets were sent up to process level

  0 export packets were dropped due to no fib

  1 export packets were dropped due to adjacency issues

  0 export packets were dropped due to fragmentation failures

  0 export packets were dropped due to encapsulation fixup failures

Aula7b#

 

 Aula7b#sh ip flow interface

GigabitEthernet0/0

  ip flow ingress

GigabitEthernet0/1

  ip flow egress

Aula7b#

 

Consola del PRTG:

 

Inicialmente, el PRTG tiene configurado 18 sensores, la versión trial que luego se convierte en free permite hasta 100

sensores o puntos de medición. Pero a medida que se agregan dispositivos este número aumenta facilemente.

 

En el siguiente gráfico el router solamente utiliza 4 (estado de la administración HTTP, tiempo de startup, estado SNMP

de la interface outside (internet) y control de flujos de tráfico vía Netflow.

 

Verificación del sensor SNMP:

 

A las 6.20 pm se genera tráfico para verificar el monitoreo de consumo de ancho de banda de la interface, el vínculo

de internet es de 6 Mbps y se llegan a tener algunos picos de capacidad máxima, pero no está exigido.

 

Detalle: aquí se visualiza el histórico (2 días) puede verificarse la utilización en horario de exámenes (18.00 a 20.00 Hs).

En el siguiente gráfico se puede observar el resultado de colocar el sensor NetFlow en la interface inside (direcciones sin

traducír como 192.168.72.x) y el resultado de todas las direcciones traducidas mediante PAT en una única dirección

192.168.0.72 (si se suman los % de cada sesión 72.x (6+6+2+2+2+1+1+1+1) nos da 22 que son todas las sesiones en una).

 

Ejemplo de una misma sesión interna y externa traducida con PAT, resultado de sensar en ambas interfaces.

                                 

Detalle de los protocolos discriminados (esto aplica a ambas interfaces ya que lo púnico que cambia es la IP origen).

Agregado de un sensor en un dispositivo:

 

En este caso agregamos la utilización de CPU en el router.

 

 

Definimos que sensor vamos a utilizar:

 

Definimos que mediones nos interesan obtener:

Verificamos en el panel general:                                                         

Podemos ver que la cantidad de sensores aumentó de 18 a 24, sin agregar equipos, por lo que llegar a 100 es fácil y

debemos saber determinar la criticidad de lo que vamos a medir (o comprar una licencia sería lo correcto).

 

Verificamos el sensor de uso de CPU:

Esto equivale a correr show process, a diferencia de que nos queda un histórico.

Generamos una alarma asociada a la interface outside:

Por fallo de la capas 1 y 2 de la interface (UP/UP-> UP/DOWN ó DOWN/DOWN):

Por consumo de ancho de banda:

Verificación:

Prueba: se visualizan varios videos en HD (aclaro que de música, Gilmour TrueHD) y se alcanzan 12 Mbps de bajada:

Verificación:

Aquí vemos el detalle del ticket generado por sobrepasar el umbral de velocidad configurado.

(2016) Sensei, the VoIP packets can reach the sound speed ?

Rosario, Argentina