¿Por qué SNMP generalmente se ejecuta en UDP y no en TCP/IP?

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 networking en la universidad que UDP no garantiza la entrega 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 radiodifusión y la multidifusión. Pero me parece que la entrega garantizada es más importante para el monitoreo de la red que 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 en ser eliminados cuando el tráfico se hace pesado. Esa es otra razón más para preferir TCP/IP sobre UDP para monitoreo de red (IMO).

¿Por qué SNMP usa UDP? No puedo resolverlo y tampoco puedo encontrar una buena razón en Google.

Answer 1

UDP se espera que funcione mejor que TCP en redes con pérdidas (o redes congestionadas). TCP es mucho mejor en la transferencia de grandes cantidades de datos, pero cuando la red falla, es más probable que el UDP lo haga. (De hecho, hace poco hice un estudio para probar esto y descubrí que SNMP sobre UDP era mucho mejor que SNMP sobre TCP en redes con pérdidas cuando el tiempo de espera de UDP se configuraba correctamente). En general, TCP comienza a comportarse mal a aproximadamente 5% de pérdida de paquetes y se vuelve completamente inútil al 33% (ish) y el UDP seguirá teniendo éxito (eventualmente).

Así que lo correcto, como siempre, es elegir la herramienta adecuada para el trabajo correcto. Si realiza una supervisión rutinaria de muchos datos, puede considerar TCP. Pero prepárate para recurrir a UDP para solucionar problemas. La mayoría de las pilas actualmente pueden usar tanto TCP como UDP.

En cuanto al envío de TRAP, sí las TRAP no son confiables porque no están reconocidas. Sin embargo, los INFORMES SNMP son una versión reconocida de una TRAMPA SNMP. Por lo tanto, si desea saber que el receptor de notificaciones recibió el mensaje, utilice INFORMs. Tenga en cuenta que TCP hace 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 notificaciones realmente lo haya obtenido. Los informes SNMP hacen reconocimiento de nivel de aplicación y son mucho más confiables que asumir que un TCP ack indica que lo obtuvieron.

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 simple agente codificado usando UDP.

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

Answer 3

Echa un vistazo a los escritos de O'Reilly sobre SNMP: https://library.oreilly.com/book/9780596008406/essential-snmp/18.xhtml

Una ventaja de utilizar UDP para trampas SNMP es que se puede dirigir UDP a una dirección de difusión, y luego les campo con múltiples estaciones de administración de dicha subred.

Answer 4

Si los sistemas envían capturas SNMP a través de TCP, podrían bloquear la espera de que los paquetes reciban un ACK si hubiera un problema para obtener el tráfico al receptor. Si se generan muchas trampas, podría agotar las tomas disponibles en el sistema y el sistema se bloqueará. Con UDP eso no es un problema porque es sin estado.Un problema similar eliminó BitBucket en enero, aunque era protocolo syslog en lugar de SNMP; básicamente, inadvertidamente usaban syslog sobre TCP debido a un error de configuración, el servidor syslog se desconectaba y todos los servidores bloqueados esperando el syslog servidor para ACK sus paquetes. Si las trampas SNMP se enviaron 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/