El tráfico de broadcast es un elemento necesario en el funcionamiento de los protocolos que operan en nuestra red, a la vez que un problema por el consumo innecesario de ancho de banda y recursos. Limitar las consecuencias de un excesivo tráfico de broadcast en nuestra red es una de las tareas permanentes del Administrador de la red. ¿Qué es el broadcast?
El broadcast es un componente natural de las redes TCP/IP y particularmente las redes Ethernet. Distinguimos 3 tipos básicos de comunicaciones:
- Unicast - Comunicación de una terminal origen a una terminal destino.
- Multicast - Comunicación de una terminal origen a un grupo de terminales destino.
- Broadcast - Comunicación de una terminal origen a TODAS las terminales de un dominio de broadcast (red, subred o VLAN).
Un paquete broadcast a nivel de capa de red, es un paquete cuya dirección de destino es 255.255.255.255. Si se trata de una red o subred específica el paquete puede tener como dirección destino la dirección reservada de subred correpondiente, por ejemplo: 172.16.1.255/24.
Los paquetes de broadcast se encapsulan a nivel de capa de enlace de datos con una dirección MAC reservada que es FFFF.FFFF.FFFF. Los switches LAN cuando reciben una trama con una dirección broadcast de destino inundan esa trama a todas sus bocas salvo la boca a través de la cual han recibido la trama.
Hay múltiples protocolos que automatizan operaciones de la red que utilizan en algunos de sus procesos direcciones de broadcast. Es el caso, por ejemplo, de los protocolos ARP y DHCP.
Limitando el broadcast de la red
El broadcast es un riesgo permanente en nuestra red, ¿porqué?
- Porque inunda la red utilizando ancho de banda innecesariamente.
- Porque insume recursos de los dispositivos que deben procesar este broadcast.
- Porque insume recursos de las terminales y servidores que reciben el broadcast y deben analizarlo.
Adicionalmente, problemas de configuración o fallos de los dispositivos o de las terminales pueden provocar la presencia de montos muy importantes de broadcast en la red que quitan recursos para el procesamiento del tráfico de datos o la operación regular de la red, bajando de modo notable su performance.
El primer recurso para limitar el impacto negativo del tráfico de broadcast es limitar el tamaño de los dominios de broadcast (el conjunto de nodos que reciben un paquete de broadcast). Para esto, las herramientas tradicionales son:
- Dividir la red en subredes.
- Implementar dispositivos de capa 3 para la comunicación entre subredes.
- Dividir la red en VLANs.
Cuando implementamos switching de capa 2, el único recurso disponible para limitar la difusión de broadcast es la implementación de VLANs, ya que por definición los switches LAN no filtran el broadcast y lo inundan a toda la red. Sin embargo, cuando implementamos switches Cisco se puede limitar el monto de ancho de banda que se utilizará para tráfico de broadcast implementando supresión de broadcast.
Supresión de broadcast con Cisco IOS
Los switches Cisco IOS brindan un feature que permite con facilidad limitar la porción de ancho de banda que puede ser ocupada por tráfico de broadcast en cada puerto del switch. Esta función está deshabilitada por defecto. Esta función permite adicionalmente definir el modo en que cada puerto debe manejar el tráfico de broadcast que recibe: se puede descartar el tráfico de broadcast excedente por un tiempo limitado o hasta que el tráfico de broadcast que llega disminuya.
Un ejemplo de cómo configurar esta función en un switch Catalyst 2950:
Switch(config)#interface fastethernet 0/10
Switch(config-if)#storm-control broadcast level 50
Switch(config-if)#storm-control action trap
El primer comando es el único requerido. En esa línea se define el tráfico que se desea limitar (también se puede utilizar para limitar tráfico de multicast o de unicast) y hasta qué nivel se tolera el mismo.
La segunda línea indica la acción que se desea tomar. Si la opción buscada es que el puerto sea inhabilitado completamente, el comando será: storm-control action shutdown. Si no se especifica nada, por defecto, el comando descarta el tráfico de broadcast. También se puede solicitar que envíe un aviso de SNMP a una estación de management.
El estado de los puertos respectos de esta función de descarte de tráfico broadcast puede ser verificado con el correspondiente comando show:
Swtich#show storm-control broadcast
Interface Filter State Trap State. Upper....Lower....Current
--------- ------------ ----------. ------...-----....-------
Fa0/1.... inactive....inactive.....100.00%..100.00%....N/A
Fa0/2.... inactive....inactive.....100.00%..100.00%....N/A
Fa0/3.... inactive....inactive.....100.00%..100.00%....N/A
Fa0/4.... inactive....inactive.....100.00%..100.00%....N/A
Fa0/5.... inactive....inactive.....100.00%..100.00%....N/A
Fa0/6.... inactive....inactive.....100.00%..100.00%....N/A
Fa0/7.... inactive....inactive.....100.00%..100.00%....N/A
Fa0/8.... inactive....inactive.....100.00%..100.00%....N/A
Fa0/9.... inactive....inactive.....100.00%..100.00%....N/A
Fa0/10....Forwarding..Below rising..50.00%...50.00%..0.00%
Fa0/11....inactive....inactive.....100.00%..100.00%....N/A
Fa0/12....inactive....inactive.....100.00%..100.00%....N/A
¿Tenés alguna información o referencia adicional para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta.
Buenas amigo,sabes como se haria paralimitar el trafico de ancho de banda de los switch 2950
ResponderBorrarAsias x adelantado
Hola te queria hacer una consulta, diseñe una red para 1000 usuarios en varias subredes, y necesito dividir el ancho de banda en los equipos que se encuentran en la zona de distribucion ¿existe algun mecanismo para hacerlo? gracias.
ResponderBorrarsi claro se hace vlan para cada segmento de usuarios, en los switches o en el DHCP, segundo en el router cisco que tiene que tener la capacidad haces los segmentos de bandwith control , consulta a un expero en cisco para que te ayude
Borrarpero si se puede yo tenia divido el ancho de banda por segmentos es decir 10.0.0/24 le tenia 20 mbps al 10.0.0.4/24 le tenia 4 mbps al 10.0.5/24 le tenia 2 mbps y asi sucesibamente
Estimado.
ResponderBorrarNo se si logro comprender el planteo. Si la red está dividida en subredes, cada subred ya constituye un dominio de broadcast. ¿Cuál es el ancho de banda que deseás dividir?
La pregunta seria ¿como estimo el ancho de banda para una subred de 500 usuarios? gracias
ResponderBorrarSigo sin terminar de comprender la pregunta. Si sirve de algo: el requerimiento de ancho de banda no es función de la cantidad de usuarios, sino de cuál es el uso que esos usuarios harán de la red. Aplicaciones que deben utilizar, tareas que deben cubrir, concurrencia o no de esas tareas, requerimientos de las mismas, etc.
ResponderBorrarOscar, como puedo analizar si el trafico de broadcast en mi red es excesivo. Es decir, tomo un analizador de paquetes, como ser el wireshark o Observer, hago la captura por x cantidad de tiempo y veo que tengo trafico de broadcast. Pero ¿como se si esa cantidad es normal o excede lo normal?
ResponderBorrarGracias
Buena pregunta Facundo.
ResponderBorrarEn primer lugar, un análisis de este tipo es conveninete, si es posible, correrlo en un espacio de tiempo que sea relativamente representativo de la operación regular de la red, por ejemplo, una semana.
Si no es posible, es conveniente entonces tomar diferentes franjas horarias en diferentes días, de modo de lograr tener un panorama representativo.
Respecto del nivel de broadcast aceptable, Cisco establece como aceptable un máximo del 20% del tráfico destinado a broadcast o multicast.
Sin embargo, esto se debe adaptar a la realidada de cada red considerando líneas de base, aplicaciones que corren, origen de ese tráfico, etc.
Como me conecto al switch
ResponderBorrary si tienes documentacion para irme metiendo a esto en mi trabajo tengo la posibilidad de aprender e ir practicando asi que me gustaria saber si tienes algun material para principiantes
Adrián.
ResponderBorrarLa manera óptima de conectarte al dispositivo para tener mayor control, es conectarte al puerto consola desde el puerto serie de una terminal, utilizando un cable consola.
La descripción completa de todos los procesimientos la puedes acceder aquí: http://www.cisco.com/en/US/docs/switches/lan/catalyst2960/hardware/quick/guide/9170.pdf
Respecto a materiales para principiantes, sugiero mi primer libro, Principios Básicos de Networking. Toda la información al respecto la puedes acceder aquí: http://librosnetworking.blogspot.com/2007/03/principios-bsicos-de-networking-versin.html
Oscar excelentes todos tus escritos en este Blog, Quisiera saber por que no comentas nada de VLAN en ellos ya que muy bien, puede resolver los problemas de colisiones y broadcast en estos casos.
ResponderBorrarsaludos
Alex.
ResponderBorrarLos temas que aparecen en el blog no siguen un planteo sistemático sino surgen a partir de consultas o el desarrollo de clases o escritos.
En este caso particular, el post está orientado a un feature específico. Es cierto que las VLANs permiten dividir dominios de broadcast, pero en este caso el objetivo estaba centrado en storm-control.
profe de como es un broadcast en switch y como en un router
ResponderBorrarNo se si entiendo bien la pregunta.
ResponderBorrarUn broadcast es siempre una trama que tiene como destino la totalidad de los nodos que componen una red o subred. Y esto es independiente de si la trama o paquete está a travesando un switch o un router.
El broadcast se identifica en el encabezado de la trama (capa 2) por la MAC ff:ff:ff:ff:ff:ff. En el encabezado del paquete (capa 3) está representado por la dirección IP 255.255.255.255 o la dirección de broadcast de la red o subred correspondiente, por ejemplo 192.168.1.255/24 o 172.16.12.31/28.
saludos me gustaria saber mas acerca de las redes de broadcast, como sus tipos o caracteristicas.
ResponderBorrargracias
Se denominan redes de broadcast aquellas que se basan en la generación de una señal portadora sobre un medio (cobre o atmósfera, por ejemplo) en un formato tal que puede ser copiado por todo receptor que esté dentro del área de cobertura del emisor.
ResponderBorrarLos sistemas de radio y televisión públicos son redes de broadcast. En el universo de la transmisión de datos, las redes Ethernet son redes de broadcast.
Una consulta sabras de algun programa para administrar un Firewall CISCO 5510. Ya que necesito sabes que Direccion IP esta consumiendo el ancho de banda.
ResponderBorrarEl herramienta CISCO ASDM no me permite solo me permite ver el acumulado pero no ver quien consume mayor ancho de banda ( haciendo una descargar muy pesada).
Lázaro.
ResponderBorrarLo que deseás se puede hacer activando Netflow y luego procesando la información con alguna de las consolas de monitoreo para Netflow que hay disponibles.
Hola Oscar:
ResponderBorrarEs recomendable activar Storm Control en los switches??? oes opcional, me puedes explicar un poco mas cual es su funcion principal.Mil Gracias y saludos desde Perú
Estimado.
ResponderBorrarEl control de broadcast en las interfaces es un feature de seguridad que se implementa en función de las políticas de seguridad o control de tráfico que se han definido en la red.
Ningún feature es mandatorio. Son todas herramientas que cada uno debe utilizar en función de los objetivos específicos que tiene para la operación de la red.
La función del comando es brindar una herramienta que permite limitar el tráfico de acuerdo a su tipo (broadcast, multicast o unicast) evitando de esta forma el uso abusivo del ancho de banda disponible, lo que podría provocar una denegación de servicio.
Oscar!!! Cuando tengo configurado el storm control en una interfaz y tengo alto nivel de descarte de paquetes ya sea broadcast, multicast o unicast, que puede ocasionar este incremento de descartes en el Router???
ResponderBorrarAmigo.
ResponderBorrarEl descarte de paquete no necesariamente o solamente se debe a la implementación de storm-control.
Hay que revisar otros elementos: ¿en qué condiciones se da el descarte de tráfioco?, ¿siempre o en contextos específicos?, ¿hay políticas asignadas?, ¿el enlace tiene suficiente capacidad?, ¿dónde se produce el descarte de tráfico?
Si pensás que es el storm-control, simplemente retiralo o configuralo para que genere traps y no descarte y volvé a verificar los contadores de la interfaz.
Estimado
ResponderBorrarCon storm control de multicast y broadcast me alcanza para bloquear "DHCP server no autorizados" en mi red? si no es asi, que caracteristica o funcionalidad debo tener en cuenta para elegir un switch y evitar lo antas mencionado?
Espero tus comentarios. Gracias.
No ya que DHCP no es el único tráfico de broadcast, no genera volumen de tráfico, y siempre debes dejar algo para que los protocolos de automatización de funciones operen correctamente.
ResponderBorrarEn los switches Catalyst hay un feature específico para controlar servidores DHCP no autorizados que es DHCP snooping.
Oscar, como estas, podrias definirme la funcionalidad del software "Network Assistant." que se puede descargar de la pagina de cisco. Desde ya muchas gracias
ResponderBorrarCisco Network Assistant (CNA) es un software de management para dispositivos Cisco diseñado para dar soporte a redes de hasta 40 dispositivos.
BorrarRealmente muy útil y fácil de operar. Una buena herramienta para redes que no tienen un alto grado de complejidad.
Oscar, buenos dias:
ResponderBorrarQuiero hacerte una consulta sobre el trafico de broadcast, tengo en mi red del trabajo 2 PC que consultan todo el tiempo todas las ip de nuestro DHCP. Por medio del Wireshark detecte esta situacion. estas maquinas son 2 host finales corriendo W XP y nada mas.
Ya deshabilite el netBios TCP y siguen haciendo lo mismo.
Espero me puedas ayudar, Gracias!!
¿Porqué decís tráfico de broadcast?
BorrarLo que describís parece más bien un intento de barrido de direcciones IP provocado por alguna aplicación.
Oscar:
BorrarLo que sucede es que estas 2 PC consultan la red y las subredes todo el tiempo IP por IP y no se el porque.
Pues bien, eso no es broadcast.
ResponderBorrarBroadcast es tráfico que tiene como destino, un único paquete, todas las IPs del dominio.
En este caso, lo que describís es un barrido de direcciones IP. Esto significa que esas terminales tienen alguna aplicación que está haciendo esto. Si ninguna aplicación legítima de la red tiene este funcionamiento, debieras pensar entonces en algún troyano o semejante que está realizando este barrido de modo oculto.
Muy interesante esta información, mi pregunta o duda es la siguiente:
ResponderBorrarEsta configuración puedo realizarla en las interfaces de los switches que están configurados en un dominio VTP, spanning-tree y con sus respectivas vlan para evitar los bucles o inundaciones de tráfico de la red a la hora de agregar redundancia. Porque en una practica de laboratorio configure una red con vlan y todas las demás configuraciones pero a la hora de agregarle redundancia se perdía la conexión la única opción para que volviera a funcionar la red era desconectar la redunciancia sinceramente quisiera saber muy bien como solucionar este tipo de problemas, la red ya estaba configurada con el protocolo spanning-tree que es el encargado de solucionar estos problemas en la red pero aun así siempre me sucede lo mismo.
Henry
ResponderBorrarCreo que estás mezclando diferentes temas.
El feature que se describe en este post permite administrar el exceso de tráfico de broadcast que se genera normalmente la red.
Lo que describes es un tema específicamente de STP. Si cuando utilizas redundancia (habría que ver en realidad qué es lo que estás conectando) hay "pérdida de conexión" (supongo que alguno de los switches dejará de operar por estar desbordado en su capacidad, esto también habría que ver si es así) tienes un problema de configuración de STP. El único protocolo que administra la redundancia en redes switcheadas es STP. Todo lo demás, VTP, VLANs o estos features, no tienen que ver con la administración de enlaces redundantes.
Ok. Thanks, solo esa era mi duda
ResponderBorrarMuy buena información, Pero tengo una duda ¿ Como podríamos saber si hay un excesivo trafico de broadcast en nuestro dominio, desde la consola del switch y no con una aplicación como wireshark?
ResponderBorrarIrving.
BorrarAnte todo, un analizador de tráfico no es reemplazable en cuanto a la información que nos proporciona, y debiera ser un recurso disponible como herramienta de trabajo.
De cualquier manera, si no contamos con un analizador, el tener configurado storm control nos permite conocer cuando estamos excediendo límites en función de los mensajes de syslog que genera el sistema operativo.
Otra opción sería utilizar el comando capture en el puerto que deseamos analizar, pero en ese caso para un análisis completo seguimos necesitando un analizados.
Oscar buenas tardes! Tengo una red de videovigilancia la cual esta montada en una red inalámbrica. Es un sistema de videovigilancia urbano. COnforme ha ido creciendo va presentando mayores problemas. Una de las soluciones es implementar multicast en el switch. Para hacerlo me recomiendas que el switch sea de capa 3? Me han recomendado ésto. Un switch de capa dos no es suficiente entonces?
ResponderBorrarMuchas gracias!
Para controlar la propagación de tráfico de multicast, se pueden utilizar switches layer 2 de tipo enterprise (como la línea Catalyst) con soporte de multicast en capa 2.
ResponderBorrarLa recomendación, depende de la topología de la red y la aplicación que se está utilizando. Hay que estudiar el caso y ver cuál es la mejor solución o la posible.
Muchas gracias Oscar!
ResponderBorrarActualmente el modelo de switch que está instalado es un SG-300 de cisco, sin embargo tengo Catalyst 2960 para probar con estos.
La topología de la red son punto a multipunto. Se está utilizando SkyPilot pero no en su topología convencional o mas recomendada que sería mesh. Esto no nos funcionó por requerir mucho ancho de banda, por lo que se hizo una topología de varios punto a multipunto. Radios conectados a un Gateway, o en algunos casos radios-extender- gateway.
Todos los gateways se van a un punto central ya sea directamente o mediante un radio alterno. Es decir, el trafico de un gateway se va por un enlace alterno(ubiquiti Rocket M5) o por el mismo gateway al nodo central. En el punto central bajan todos los enlaces a un switch donde llegan y al mismo están conectadas las estaciones de trabajo de los usuarios y las grabadoras NVR. Al ser una red urbana, se tienen 80 camaras o nodos en diversos puntos de la ciudad ademas de haber dos centros de monitoreo. El punto central es uno de ellos y el otro centro de monitoreo esta conectado a éste por otro enlace inalámbrico por donde pasa el tráfico de video del punto central a ellos. En este otro centro de monitoreo hay 9 usuarios mas.
En total tenemos cuatro clientes geográficamente hablando. Pero los principales son éstos dos centros de monitoreo en donde en total son 9 estaciones en el punto externo, 7 estaciones en el punto local , mas las NVR donde se graba el video de éstas camaras.. por esta razon es que se quiere implementar Multicast.
Oscar no se si es que me puedes apoyar con esto, y si así fuera te lo agradezco mucho y te pido me comentes si puedo enviarte la topología por otro medio o subir un diagrama.
Muchas gracias!
Un gran saludo!
Lo que estás proponiendo excede largamente los alcances de comentarios en un blog.
BorrarTu planteo requiere un análisis serio y documentado de la red y la solución, con una respuesta profesional dada con responsabilidad. Creo que para esto ya debieras buscar una consultoría.
Hola Oscar, quiero preguntarte algo. Si divido la red en subredes y las conecto a un switch (sin configuracion de vlans), que pasa con el broadcast, se propaga por las demas subredes conectadas al mismo switch?. Entiendo que cada subred representa un dominio de broadcast
ResponderBorrarEfectivamente, una subred es un dominio de broadcast.
BorrarPero también es cierto que una dirección IP de broadcast se encapsula en una dirección MAC de broadcast. En consecuencia, si no se dividen VLANs en un switch layer 2, aún cuando se utilicen subredes diferentes todo es un único dominio de broadcast desde la perspectiva de capa 2.
Muchas gracias por tu pronta respuesta Oscar. disculpa mi ignorancia, pero si divido el switch en VLANs que beneficio tiene crear subredes? con respecto al broadcast claro!!
ResponderBorrarPues... el mapear subredes a VLANs no tiene como objetivo dividir dominios de broadcast.
BorrarEso ya lo hacen las VLANs.
El mapeo de VLANs a subredes tiene como propósito permitir luego el enrutamiento de esas subredes, a nivel de capa 3.
Oscar buena tarde, existe algun software o hardware que pueda simular o generar trafico de broadcast con el fin de estresar la red y ver que el porcentaje de storm control se cumpla?
ResponderBorrarSaludos
Hya varias posibilidades, una de ellas es jperf. En este post explico algo de su funcionamiento: http://librosnetworking.blogspot.com.ar/2012/02/medicion-de-performance-de-enlaces.html
BorrarHola Oscar:
ResponderBorrarTengo una red de Fibra óptica-FO con Switches L2/L3 en diferentes edificios, en cada Edificio(NODO) se conectan otras Empresas diferentes Redes (VLAN´s) a quienes les doy servicio, y llegan hasta el Nodo a través de FO;Transceiver;Pto. del Nodo, el problema es que una de las Empresas me genera abundante tráfico de Broadcast y configurando storm-control en el puerto al cual se conecta en el Nodo no logro parar y consume mucho procesamiento del Nodo, por lo que tengo que bajar el puerto para evitar la caída del Nodo, habría otro Feature recomendado para este caso?
Gracias
Juan.
BorrarNo logro terminar de comprender la situación. Supongo que se trata de switches Catalyst, que lo que denominás "nodo" es un switch Catalyst, y que aún habilitando storm control (y que esto funciona) ¿se desborda el procesamiento del swithc?
Tengo la impresión de que en este caso hay algún elemento adicional que está impactando y que no es simplemente el volumen de Broadcast que genera tu cliente, ya que si así fuera, la red de tu cliente tendría un serio problema también.
Hola Oscar,
ResponderBorrarMe gustaría tener tu opion respecto a la siguiente configuración. Tengo una red con varios switches conetados en una topologia strella, donde se pueden distingir claramente dos niveles: un nivel de core y un nivel de accesso.
Lo que me llama poderosamente la atencion es que en todos los switches los puertos tiene habilitado el storm-control con la accion shutdow.
En mi opinion esta configuracion como estrategia para proteger la red, me parece demasiado radical. Entiendo que uno de los principios de la seguridad es la disponibilidad y bajar la interfaz es una acción que antenta contra el mismo. ¿Cual sería una buena estrategia?
Cada implementación obedece a un diseño (bueno o malo, siempre los hay), y cada diseño responde a objetivos.
BorrarAntes de revisar la implementación debieras conocer los objetivos propuestos para poder evaluar si la estrategia adoptada es o no la mejor.
Hola Oscar,
ResponderBorrarTenemos una red con equipos bastantes sensibles conectados.
Hace tiempo tuvimos que bajar el ARP Timeout a 1 minuto y desde entonces vimos que aumentaban los errores de comunicación entre los equipos finales.
Hemos conectado analizadores IP comprobando que registran perdida de tramas con una frecuencia igual al ARP Timeout.
¿Es normal que ocurra ésto?
El problema es que aunque aumentemos el ARP Timeout, cuando se produce el refresco se siguen perdiendo tramas.
¿Cual puede ser la causa?
Gracias por adelantado
Estimado.
BorrarPara responder tu pregunta es preciso conocer la red en la que estás operando, su arquitectura, y la aplicación que está generando estos errores.
Sintetizando: no es un tema para resolver a través de un post de blog :)
Sin embargo, de lo que relatas surgen algunas cosas: ¿porqué suponen que reduciendo el timeout de ARP la aplicación debe operar mejor? Esto fuerza a que los equipos estén permanentemente generando tráfico de ARP lo que incrementa el tráfico y reduce la performance.
Por otra parte, ¿en qué punto de la red se están perdiendo tramas?
espero que al menos esas 2 preguntas te orienten en la búsqueda.
Oscar,
ResponderBorrarPrimero que todo bueno blog tienes, felicitaciones.
Segundo. en donde recomeindas aplicar estos comandos para el control de broadcast storm? en las interfaces de acceso o uplinks? me hace mas sentido en esta ultima.
Gracias!
Cristian.
BorrarComando y funcionalidades son herramientas que tenemos para operar y optimizar nuestra red.
El mejor lugar para la aplicación en todos los casos dependerá del diseño de la red y los objetivos que tengas. El lugar más adecuado en un caso, puede significar un problema o desventaja en otro.
Oscar, felicidades por el Blog, tengo una duda a ver si puedes ayudarme, en mi empresa tenemos definidas vlans distintas según el tipo de tráfico, en concreto para voz y video, tenemos una. Vamos a poner en marcha una sede grande, con muchos terminales voip, ¿cual consideras que sería un tamaño límite (aproximado)recomendable para ir pensando en crear nuevas vlan para voz teniendo en cuenta que la latencia es crítica en voip ?
ResponderBorrarUn saludo
Mira.
BorrarLa pregunta que planteás no tiene una respuesta genérica.
La definición de las dimensiones de la VLAN de voz deberán depender esencialmente del diseño de la red y el tráfico que la misma tenga. Es uno de los aspectos que debe considerar el diseñador y tomar decisiones en función de los objetivos planteados.
Hey buen día, gracias por la informacion de tu blog, es muy útil.
ResponderBorrarTengo un problema en la red y espero me puedas proporcionar ayuda;
tengo una red con el modelo de las 3 capas en uno de los witches de distribucion ocurre un problema, de pronto se bloquean ciertas VLANs, es decir, reciben direccion IP, hacen ping a su gateway, e inclusive ven otras redes de otro switch de distribución en otra parte de la red, sin embargo no salen a internet. use el comando y reduje el tráfico unicast, multacast y broadcast a un 50% y aun así he tenido el mismo error, habrá algo más que se pueda hacer, ¿Algo que se me esté pasando?
Ta agradezco por tu tiempo.
Estimado.
BorrarEl problema que planteas puede tener diferentes causas, y a mi parecer, lo último sería pensar en un problema de desbordamiento de tráfico.
Debieras hacer un diagnóstico sistemático de la situación, y en caso de ser necesario buscar un soporte externo.
te agradezco por tu respuesta, creí que era un caso de desbordamiento de tráfico debido a que tras reiniciar las interfaces Vlans vuelven a tener acceso a internet
BorrarNo digo que no sea, pero creo que está faltando un diagnóstico preliminar del problema. Lo único que tienes es el síntoma.
BorrarMaestro, muchas gracias por la explicación...... saludos desde Colombia
ResponderBorrarHola , agradezco tu dedicacion, leyendo este post y los comentarios, me animo a preguntar los siguiente,.
ResponderBorrarSe dijo
Respecto del nivel de broadcast aceptable, Cisco establece como aceptable un máximo del 20% del tráfico destinado a broadcast o multicast.
COMO CALCULO ESE NIVEL?
Yo Hago, broadcast/packets input (en porcentaje), en el caso abajo me da 56%. ESTOY HACIENDOLO BIEN.
agradecido de Antemano.
GigabitEthernet1/0/32 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 6c50.4d12.6520 (bia 6c50.4d12.6520)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 27000 bits/sec, 30 packets/sec
4141990 packets input, 577509442 bytes, 0 no buffer
Received 2343860 broadcasts (337 multicasts)
broadcast/packets input
La referencia al 20% de tráfico de broadcast/multicast es una referencia de diseño para evaluar el nivel de saturación de un enlace. Está referida al ancho de banda del enlace y se toma a partir de una línea base, no de una medición puntual.
BorrarCuando te referís a una medición puntual puede ocurrirte que circunstancialmente cerca del 100% del tráfico sea broadcast, ya que esto dependerá de la actividad registrada por el switch en ese momento. Por ejemplo, en una red con escasa actividad de tráfico de datos es muy posible que el porcentaje de broadcast sea altísimo ya que la mayor parte de los protocolos de automatización de la red utilizan broadcast para su negociación (DHCP, ARP, etc.)
Por otra parte, el contador del show interfaces es un contador de paquetes, no de bytes, con lo que es una referencia que no te sirve para ponderar utilización de ancho de banda.
Hola oscar,
ResponderBorrarGracias por el artículo, tengo la siguiente duda:
Tengo un catalyst 3750, tiene configurado storm control con un maximo del 20%,
En el log estoy viendo que por una interface se esta superando ese máximo, en dicha interface hay conectado un fw fortinet , que herramienta puedo usar para encontrar el motivo de este aumento de multicast?
Gracias de antemano
Si no tienes implementado un sistema de monitoreo de tráfico, tipo NetFlow, operando en tu red, la opción es realizar una captura de tráfico sobre esa interfaz para poder analizarla. Para analizar ese tráfico necesitas un "analizador de tráfico" (valga la redundancia), para lo que puedes utilizar WireShark como herramienta free, o en su defecto alguno de los sistemas licenciados que se ofrecen, y que tienen mejores herramientas de reporte.
BorrarHola Oscar,
ResponderBorrarGracias de antemano por la respuesta.
Tengo es siguiente escenario. SW 2960 como acceso y 2 SW 3750X como CORE en Stack que manejan todo el tema de enrutamiento de las Vlans. Me ha pasado lo siguiente. Toda la red empezó a perder paquetes, cuando hacía ping de consultas tenía muchos saltos hacía mi servidores e incluso a mis SW. Cuando a la red le quito la salida a internet que es controlado por un FW, todo se restablece a la normalidad. Mi consulta es como puedo saber en el SW que dispositivo me esta saturando la red, imagino que debe tener algún virus que trabaje con internet y aumente el tráfico que hace que mi CORE caiga.
Jimmy
BorrarEn primer lugar, si tu diagnóstico indica que tienes muchos saltos para llegar a tu servidor, esto pareciera en primer lugar ser un problema de enrutamiento, no de tráfico.
Ante todo habría que revisar entonces cómo está el enrutamiento en tu red, viendo en primer lugar cuáles son esos saltos; antes de suponer que se trata de un problema de volumen de tráfico.
En segundo lugar, si es un problema de tráfico generado por algún bot o troyano, esto debiera poder resolverse en el firewall, filtrando ese tipo de tráfico. Habría que revisar qué firewall tiene la red y si ofrece esa posibilidad.
En tercero, para mejorar tu diagnóstico desde la perspectiva del tráfico puedes implementar NetFlow, o SNMP para poder monitorear mejor la operación.
Gracias por la información, nos servirá para el próximo proyecto.
ResponderBorrarHola Oscar, tengo una consulta tengo 2 servidores DHCP en una red capa 2, necesito saber si puedo bloquear en una puerta de un SW cisco 2950 en envio de DHCP a la red de usuarios.
ResponderBorrarLa topologia es la siguiente:
Internet -- Linux DHCP 1 -- SWUSUARIOS ---cableunion----SW2950 --- Router Cisco con DHCP 2.
PD, en apartados anteriores estuve leyendo y vi algo de DHCP snooping
PD1, estoy haciendo unas pruebas con PRTG, D-ITG, Call manager, firewal cisco, y otras cosas por lo cual no puedo separa en capa 3.
Nibaldo
BorrarSi en una única red capa 2 tienes 2 servidores DHCP y deseas solamente uno en operaciones, la opción más simple es apagar el servicio que no deseas utilizar.
DHCP snooping es una herramienta para evitar ataques de spoofing de DHCP. Pero si no deseas uno de los servicios, simplemente lo bajas.
Por otra parte, cualquiera de los elementos que mencionas pueden implementarse en redes segmentadas en capa 3.
hola Oscar
ResponderBorrarun favor cual es la ventaja mayor de usar subredes VLAN ?
Subredes y VLANs son 2 recursos diferentes. Ambos dividen dominios de broacast, las VLANs a nivel de capa 2 y las subredes a nivel de capa 3.
Borrar¿Cuál es el propósito de segmentar el dominio de broadcast utilizando estas técnicas? Obviamente acotar el dominio de broadcast, lo cual contiene la difusión de tráfico de broadcast y de multicast, mejora la performance, agrega una capa de seguridad permitiendo realizar control de tráfico, aumenta la escalabilidad y estabilidad de la red y facilita las tareas de diagnóstico y resolución de problemas.
Es bueno limitar el trafico unicast ¿afecta el rendimiento de la red?
ResponderBorrarSi la red tiene como propósito posibilitar la comunicación entre terminales transportando el tráfico entre ambas, al limitar el tráfico estás limitando el rendimiento.
BorrarLa pregunta en realidad es ¿por qué limitarías, indiscriminadamente, todo el tráfico de unicast de la red? ¿Cuál sería el propósito?
Oscar, tal vez hice mal el planteamiento tengo dos dudas primero si configuro storm control broadcast y storm control unicast ¿ perderé paquetes buenos en la red? Lo que quiero es optimizar el funcionamiento de la red. Utilicé Wireshark y veo que algunos equipos de cómputo tienen mucho tráfico ARP y algunos envían mucho Broadcast.
BorrarLos mecanismos de control tienen el objetivo de preservar los recursos de red disponibles, no el tráfico. Si se activan estos mecanismos de control, son mecanismos de control en función de volumen y no discriminan tráfico útil de tráfico producto de un posible ataque.
BorrarSi se desea limitar el exceso de tráfico producto de un mal uso de los recursos de la red, el mecanismo es QoS.
Si se desea tomar medidas preventivas respecto de potenciales ataques, entonces el mecanismo es seguridad.
El funcionamiento de la red se debe optimizar en función de objetivos finales que no son la red en sí misma. Primero hay que definir qué es optimizar. En algún caso puede ser incluso descartar tráfico legítimo si el objetivo es preservar un tráfico crítico.
El tráfico ARP es un problema sin dudas, por los recursos que consume. Pero la pregunta en realidad si ese tráfico ARP es legítimo y necesario para la operación. Si fuera así, no podemos tocar ese tráfico; si no, habría que analizar la fuente. Si es un problema de diseño de aplicación hay que apuntar a corregir la aplicación, caso contrario podemos exponernos a que algún elemento crítico de la operación no funcione adecuadamente.
Hola Oscar, primero felicitarte por el blog.
ResponderBorrarTe quería hablar acerca de un problema con el broadcast. Resulta que tengo Vlans creadas y en una de ellas hay un programa que genera tráfico broadcast. Es posible que solo ese tráfico de broadcast pueda llegar a las de,as subredes ??? Un saludo
Miguel.
BorrarEl tráfico de broadcast no atraviera las VLANs ni es enrutado. Las VLANs, precisamente, igual que las subredes, dividen dominios de broadcast.
Gracias por la respuesta. Entonces si un dispositivo con en la red 192.168.0.x 255.255.255.0 envía un paquete con dirección 192.168.1.255, el router no lo enroutaria??
BorrarGracias y enhorabuena por el blog
El broadcast no es solamente en capa 3, sino también en capa 2. Un broadcast dirigido (como el que ponés en tu ejemplo) se encapsula en capa 2 con una dirección MAC de broadcast, así que llega al router como un simple broadcast.
BorrarAhora bien, ¿qué protocolo está utilizando esa dirección de capa 3?
Me temía algo de eso pero no estaba 100% seguro. Sería UDP. Que solución podría adoptar entonces?? Muchas gracia por la ayuda. Un saludo.
BorrarSi se trata de UDP y conoces el puerto al que apuntan las solicitudes, puedes incluir esas solicitudes en el comando ip helper-address.
BorrarEl comando ip helper-address reenvía por defecto 8 servicios UDP: time, TACACS, DNS, DHCP server, DHCP client, TFTP, NetBios name service y NetBios datagram service. Pero puedes modificar esa lista utilizando el comando ip forward-protocol udp [puerto].
Hola Oscar, mi última consulta.
BorrarComo te comentaba hay 4 vlans con sus repectivas direcciones broadcast. Si este dispositivo que genera broadcast por el purto x UDP, debería ser broadcat dirigido como 192.168.0.255, 192.168.1.255, etc (Si las Vlan son 192.168.0.0, 192.168.1.0 etc). O en cambio enviando dicho trafico con la direcion 255.255.255.255 sería suficiente para llegar a todos si lo activo en el helper-address??
Muchas gracias.
Un saludo..
Miguel.
BorrarAcabo de publicar un post sobre este tema en el que creo está la respuesta: http://librosnetworking.blogspot.com.ar/2016/05/ip-helper-address.html
Muchas gracias Oscar, me ha venido perfecto.
BorrarUn saludo.
Un comando que me ha ayudado mucho en los switch de capa 3, es "srr-queue bandwidth limit 10", ta ayuda a limitar el ancho de banda por interfaz
ResponderBorrarRaúl
BorrarEsa es otra posibilidad, implementar QoS en las interfaces.
Hola oscar:
ResponderBorrarAl implementar el speed no negotiate en mi core que es de otra marca diferente a cisco , ¿genera problemas de rendimiento en la red de datos ? Es que por alguna razón el rendimiento ha decaído ba partir de qué instalé este core y por otra parte ¿si implemento storm control afecta el rendimiento de la red?
Estimado
BorrarSpeed no negotiate suprime los mecanismos de autonegociación del puerto. En este sentido lo que haces es suprimir la negociación de velocidad y eso fuerza a que la definas manualmente. Esto afecta la performance en la medida en que tu configuración no sea la correcta.
La caida de rendimiento general de la red, puede depender de una configuración imperfecta, pero también depende de qué es lo que has instalado como core: capacidad de backplane, capacidad de forwardeo de paquetes, etc.
Como suelo decir... antes de hacer nada, hay que diseñar, al diseñar hay que hacerlo en base a objetivos y entonces luego plantearse si el objetivo se consigue o no. Si no se consigue, el error está en el diseño.
En los puertos gigabit de los switches cisco están en modo trunk y con el speed nonegotiate ¿crees que tendría que decirles que su speed es 1000 ?
BorrarGracias por tu respuesta.
BorrarHe querido configurar la velocidad de los puertos gigabit de forma manual pero al entrar a la interfaz no muestra el comando, sólo muestra nonegotiate, ¿como puedo deciirle a la interfaz de forma manual que su speed es de 1000?la otra que pienso es que los equipos cisco ya toman por default quensu velocidades a 1000
En una buena práctica aconsejada que la velocidad de los puertos esté definida de modo estático.
BorrarLos elementos de configuración disponibles siempre dependen de la plataforma y la versión de sistema operativo con que estamos trabajando. Lo que debes hacer es revisar la configuration guide correspondiente a plataforma y sistema operativo.
BorrarPor otra parte, si se trata de un switch Catalyst, puedes revisar el modo en que está operando con el comando show interfaces status.
Oscar
ResponderBorrarEl protocolo ¿ spanning tree se debe configurar en una red Ethernet aunque no tenga enlaces redundantes ? Por lo que sé, configurar está opción ayuda al rendimiento de la red.
STP no está relacionado con la mejora de performance de las redes Ethernet, sino con la prevención de posibles bucles. En este sentido debe estar siempre activo por una cuestión de seguridad más que de performance (aún cuando no haya enlaces redundantes).
BorrarGracias oscar por tu apoyo
ResponderBorrarOscar
ResponderBorrarTengo un puerto fast Ethernet configurado para voz y datos ¿es necesario configurar spanning tree port fast?
Si es un puerto en el que tienes conectados dispositivos terminales (supongo un teléfono con una PC), no es obligatorio pero es conveniente pues acelerará la negociación inicial de STP.
BorrarMuchas gracias por tu comentario
ResponderBorrarHola Oscar un gusto saludarte.
ResponderBorrarSupongamos el siguiente caso, tengo un servidor dhcp y esta asociado a un puerto y a una vlan de un switch. Mi pregunta es, a ese puerto o a la vlan del switch; es recomendable configurar el comando storm control para evitar el broadcast de la red y que el dhcp en determinado momento se sature de tanta petición innecesaria?? Te hago la pregunta porque me ha pasado que el dhcp tarda en responder las peticiones de un equipo, y tengo que reiniciar el server pars que otorgue una ip.
Gracias,
Andrés.
BorrarPuedes aplicar esto para limitar el tráfico de broadcast en el puerto al que está conectado el servidor.
Pero creo que debes investigar el origen de lo que llamas "peticiones innecesarias" y procurar solucionar el problema antes de que llegue al puerto del switch que conecta al servidor, porque si se alcanza el límite que definas para broadcast entonces el problema será el mismo: se descargarán tanto solicitudes legítimas como ilegítimas y podrías generar un problema de DoS por tu implementación.
Primero hay que investigar el origen de ese tráfico innecesario.
Hola Oscar:
ResponderBorrarCuando activo ip dhcp snooping funciona bien en la red cableada pero resulta que en la WLAN no me asigna direcciones dhcp tengo una controladora cisco para toda la wlan, ya configure los puertos troncales que llegan a esa controladora con ip dhcp snooping trust.
¿ Sera que me está faltando alguna configuración? o tengo que configurar en la controladora algo de snooping?
En principio la implementación de DHCP snooping no debería provocar inconvenientes con la asignación de configuración IP en la red inalámbrica.
BorrarHabría que examinar cuidadosamente la topología y la implementación.
Como primera instancia podrías retirar la configuración de DHCP snooping y verificar que la configuración de DHCP para la red inalámbrica opere de modo correcto.
En cuanto a las aplicaciones que utilizan broadcast se podría esperar algún mal funcionamiento de la aplicación por limitar ese tipo de trafico????
ResponderBorrarSi está adecuadamente dimensionado, considerando el tráfico regulara de la red, no debiera generar ningún inconveniente.
BorrarEl secreto es la planificación y conocimiento de la red.
Hola oscar
BorrarLos comandos ip dhcp snooping y ip dhcp snooping vlan deben de aplicarse a todos los switches de la red ?
IP DHCP snooping es un feature que se activa globalmente en el switch y luego se ajusta por interfaz.
BorrarSu implementación requiere de un análisis cuidadoso de la red ya que puede obstaculizar la asignación de DHCP o en el otro extremo, ser completamente ineficiente. No es solo un tema de configuración sino primariamente de diseño.