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