Почему SNMP обычно запускается через UDP, а не TCP/IP?

Сегодня утром на работе возникли большие проблемы, потому что SNMP-ловушка не "прошла", потому что SNMP запущен через UDP. Я помню из сетевого класса в колледже, что UDP не гарантирует доставку, как TCP/IP. И Wikipedia говорит, что SNMP можно запускать через TCP/IP, но UDP более распространен.

Я понимаю, что некоторые преимущества UDP через TCP/IP - скорость, широковещание и многоадресная рассылка. Но мне кажется, что гарантированная доставка важнее для сетевого мониторинга, чем возможность вещания. В частности, когда есть серьезные потребности в высокой безопасности. Один из моих сотрудников сказал мне, что пакеты UDP первыми отбрасываются, когда трафик становится тяжелым. Это еще одна причина для предпочтения TCP/IP через UDP для мониторинга сети (IMO).

Итак, почему SNMP использует UDP? Я не могу понять это и не могу найти хорошую причину в Google.

Ответ 1

Предполагается, что UDP будет работать лучше TCP в сетях с потерями (или в перегруженных сетях). TCP намного лучше переносит большое количество данных, но когда сеть выходит из строя, более вероятно, что UDP пройдет. (на самом деле, я недавно провел исследование, тестировавшее это, и обнаружил, что SNMP через UDP удалось намного лучше, чем SNMP через TCP в сетях с потерями, когда тайм-аут UDP был установлен правильно). Как правило, TCP начинает плохо себя вести с потерей пакетов около 5% и становится совершенно бесполезным на 33% (ish), а UDP все равно будет успешным (в конечном итоге).

Итак, правильная вещь, как всегда, - выбрать правильный инструмент для правильной работы. Если вы выполняете обычный мониторинг большого количества данных, вы можете рассмотреть TCP. Но будьте готовы вернуться к UDP для устранения проблем. Большинство стеков в наши дни могут фактически использовать TCP и UDP.

Что касается отправки TRAP, да, TRAP являются ненадежными, потому что они не подтверждены. Однако SNMP INFORMs является подтвержденной версией SNMP TRAP. Таким образом, если вы хотите знать, что получатель сообщения получил сообщение, пожалуйста, используйте INFORMs. Обратите внимание, что TCP выполняет not решить эту проблему, поскольку он только обеспечивает уведомление уровня 3 уровня о том, что сообщение получено. Нет уверенности в том, что получатель уведомлений действительно получил его. SNMP INFORMs делает подтверждение уровня приложения и гораздо более надежным, чем предполагая, что TCP ack указывает, что он получил его.

Ответ 2

Если системы отправили SNMP-ловушки через TCP, они могли блокировать ожидание того, что пакеты будут ACKed, если возникла проблема с получением трафика на приемник. Если было создано много ловушек, он мог бы использовать доступные сокеты в системе, и система запиралась. С UDP это не проблема, потому что она без гражданства. Аналогичная проблема взяла BitBucket в январе, хотя это был протокол syslog, а не SNMP - в основном они случайно использовали syslog через TCP из-за ошибки конфигурации, сервер syslog опустился, и все серверы заблокировали ожидания syslog сервер для ACK их пакетов. Если SNMP-ловушки были отправлены через TCP, может возникнуть аналогичная проблема.

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

Ответ 3

Использование ловушек с SNMP считается ненадежным. Вы действительно не должны полагаться на ловушки.

SNMP был разработан для использования в качестве протокола запроса/ответа. Детали протокола просты (отсюда и название, "простой протокол сетевого управления" ). И UDP - очень простой транспорт. Попробуйте реализовать TCP для вашего основного агента - он значительно сложнее, чем простой агент, закодированный с использованием UDP.

Операции SNMP get/getnext имеют механизм повтора - если ответ не получен в течение таймаута, то тот же запрос отправляется до максимального количества попыток.

Ответ 4

Ознакомьтесь с работами O'Reilly в SNMP: https://library.oreilly.com/book/9780596008406/essential-snmp/18.xhtml

Одним из преимуществ использования UDP для ловушек SNMP является то, что вы можете направить UDP на широковещательный адрес, а затем поместить их с несколькими станциями управления в этой подсети.