logicos - ¿Por qué normalmente se ejecuta SNMP sobre UDP y no TCP/IP?

puertos http alternativos

Question

Esta mañana, hubo grandes problemas en el trabajo porque una trampa SNMP no "pasó" porque SNMP se ejecuta sobre UDP. Recuerdo de la clase de redes en la universidad que no se garantiza la entrega UDP como TCP / IP. Y Wikipedia dice que SNMP se puede ejecutar sobre TCP / IP, pero UDP es más común.

Entiendo que algunas de las ventajas de UDP sobre TCP / IP son la velocidad, la transmisión y la multidifusión. Pero me parece que la entrega garantizada es más importante para la supervisión de la red que para la capacidad de transmisión. Particularmente cuando hay serias necesidades de alta seguridad. Uno de mis compañeros de trabajo me dijo que los paquetes UDP son los primeros que se eliminan cuando el tráfico se agrava. Esa es otra razón más para preferir TCP / IP sobre UDP para monitoreo de red (IMO).

Entonces, ¿por qué SNMP usa UDP? No puedo entenderlo y tampoco puedo encontrar una buena razón en Google.

Answer 1

Consulte los escritos de O''Reilly en SNMP: https://library.oreilly.com/book/9780596008406/essential-snmp/18.xhtml

Una de las ventajas de usar UDP para las capturas SNMP es que puede dirigir UDP a una dirección de transmisión y luego colocarlas en el campo con múltiples estaciones de administración en esa subred.

Answer 2

El uso de trampas con SNMP no se considera confiable. Realmente no deberías confiar en las trampas.

SNMP fue diseñado para ser utilizado como un protocolo de solicitud / respuesta. Los detalles del protocolo son simples (de ahí el nombre, "protocolo simple de administración de red"). Y UDP es un transporte muy simple. Intente implementar TCP en su agente básico: es considerablemente más complejo que un agente simple codificado mediante UDP.

Las operaciones get / getnext de SNMP tienen un mecanismo de reintento: si no se recibe una respuesta dentro del tiempo de espera, la misma solicitud se envía hasta un número máximo de intentos.

Answer 3

En realidad, se espera que UDP funcione mejor que TCP en redes con pérdidas (o redes congestionadas). TCP es mucho mejor a la hora de transferir grandes cantidades de datos, pero cuando la red falla, es más probable que UDP se transmita. (de hecho, recientemente hice un estudio que probó esto y descubrí que SNMP sobre UDP tuvo mucho más éxito que SNMP sobre TCP en redes con pérdidas cuando el tiempo de espera de UDP se configuró correctamente). En general, el TCP comienza a comportarse de manera deficiente con aproximadamente el 5% de pérdida de paquetes y se vuelve completamente inútil al 33% (ish) y UDP seguirá teniendo éxito (eventualmente).

Entonces, como siempre, lo correcto es elegir la herramienta adecuada para el trabajo correcto. Si está realizando un monitoreo de rutina de gran cantidad de datos, podría considerar TCP. Pero prepárate para recurrir a UDP para solucionar problemas. La mayoría de las pilas en estos días pueden usar tanto TCP como UDP.

En cuanto al envío de TRAP, sí, los TRAP no son confiables porque no se reconocen. Sin embargo, los SNMP INFORM son una versión reconocida de una SNMP TRAP. Por lo tanto, si desea saber que el destinatario de la notificación recibió el mensaje, utilice INFORMs. Tenga en cuenta que TCP no resuelve este problema, ya que solo proporciona una notificación de nivel de capa 3 de que se recibió el mensaje. No hay seguridad de que el receptor de la notificación realmente lo haya recibido. Los informes SNMP hacen un reconocimiento de nivel de aplicación y son mucho más confiables que suponer que un acuse de recibo de TCP indica que lo lograron.

Answer 4

Si los sistemas enviaban capturas SNMP a través de TCP, podrían bloquearse la espera de que se ACKeden los paquetes si hubiera un problema para llevar el tráfico al receptor. Si se generaran muchas trampas, podría usar los sockets disponibles en el sistema y el sistema se bloquearía. Con UDP eso no es un problema porque no tiene estado. Un problema similar sacó a BitBucket en enero, aunque era un protocolo de syslog en lugar de SNMP; básicamente, estaban usando inadvertidamente syslog sobre TCP debido a un error de configuración, el servidor de syslog se cerró y todos los servidores quedaron bloqueados esperando el syslog. Servidor para ACK sus paquetes. Si se enviaran capturas SNMP a través de TCP, podría ocurrir un problema similar.

http://blog.bitbucket.org/2012/01/12/follow-up-on-our-downtime-last-week/