Pedro GM escribió:
El sáb, 21-03-2009 a las 17:42 -0400, Sebastián Veloso Varas escribió:
Pedro GM escribió:
El sáb, 21-03-2009 a las 10:04 -0600, Vida Luz Arista escribió:
Hola a todos,
Actualmente tengo un enlace 12 MBps, este entra a un cisco 3550, tenemos un
problema porque distribuimos el tráfico hacia varias recintos de una
universidad, sin embargo en determinado momento se dispara el trafico
entrante y se vuelve lento todo, configuramos uno de los puertos del switch
como monitor port, y redirigimos el tráfico hacia un Linux con NTOP, en le
summary del NTOP sale un broadcast con el 29%, el problema es que en el NTOP
no hemos encontrado la manera de saber que IP generan ese broadcast, asi
mismo el NTOP consume mucha memoria y a cada momento se detiene.
Agradecería cualquier sugerencia.
Saludos,
“La Vida”
Ntop tiene una opcion "-l" con esta lo que va capturando se guarda en
un archivo con el formato .pcap, entonces lo puedes analizar
posteriormente con algun analizador de protocolos compatible con libpcap
como tcpdump o wireshark (este ulimo tiene interfaz grafica).
Sip, pero es mucho más detallista Wireshark para sus cosas.
Cierto estoy de acuerdo con esa afirmacion, pero ella esta usando Ntop
por un tema de estadisticas y graficas del trafico, puede usar
ambos(ntop para las graficas y wireshark para analisis) ya que wireshark
es muy util para analizar en profundidad.
Exacto. Graficamente es mucho mas practico un Ntop. Es por esto que
tambien uso /en algunos casos/ el Sniffer Pro de la Network Associates
para a veces mostrar graficas a clientes o informes. Tambien es valido
lo que dices respecto a Ntop
De esta forma puedes analizar mas en calma los datos de la encapsulacion
de los paquetes de broadcast para poder llegar a observar una ip de
origen o una mac de origen (que te podria llevar al switch que esta
propagando el broadcast, observando con los comandos show del 3550 a que
puerto esta asociado esa mac de origen). también notaras si hay algun
servicio de aplicación involucrado en esto y te pueda dar mas pistas.
Estoy seguro que el problema es un equipo generando trafico en la red
con algún virus/troyano (que podría ocasionar ataques DoS, spoofing ARP
entre otros) o sino ya un loop de red ... algo que debiese ser
controlado por switching. Yo he tenido varios dolores de cabeza por
estas causas. La idea es hacer un levantamiento desde lo fisico hasta la
aplicacion, distinguir las capas de acceso, distribuicion y core en tu
red (si es que las posees claramente identificadas) para solucionar tu
problema.
En mi experiencia es lo mas probable, hace poco tube un caso similar en
mi trabajo y eran unas estaciones(infectadas) que inundaban con trafico
a toda la lan y se generaban muchas solicitudes arp, una vez localizadas
las estaciones un simple netstat mostro muuuuchos sockets abiertos.
Por otro lado si fuese una tormenta de broadcast entre switches, el
spanning-tree del 3550 lo habria detenido ya.
Claro, respecto a tu comentario del 3550 pero estas tormentas en su
mayoria a veces no pueden ser controladas por STP automaticamente ni por
CLI (o sea entrar al Sw remotamente y verificar que esta pasando).
Tampoco no tenemos claridad que este conectado directamente al Switch
3550 (quizas haya un enjambre de hubs o switches en cascada, que se yo
.. jejeje). A veces estos equipos simplemente se bloquean y hay que
reiniciarlos y desconectar cables!!
Eso es lo que se me ocurre a primera instancia para ayudar a detectar el
origen del broadcast.
La solución del storm control es buena pero es muy util que encuentres
desde donde vienen esos broadcast.
Claramente esta es una solución del tipo "aspirina para el dolor de
cabeza" .... .Son utiles para entender la naturaleza y solucion de la
problemática y calmar el momento.
suerte.
