Pourquoi est-SNMP l'habitude de courir sur UDP et non TCP/IP?

Ce matin, il y avait de gros problèmes au travail à cause d'une interruption SNMP n'a pas "passer à travers" parce que SNMP est exécuté sur UDP. Je me souviens de la mise en réseau de classe au collège que le protocole UDP n'est pas la garantie de livraison comme TCP/IP. Et Wikipedia dit que SNMP peut être exécuté sur TCP/IP, UDP mais est plus fréquente.

Je reçois que quelques-uns des avantages de l'UDP sur TCP/IP sont la vitesse, de la radiodiffusion, et la multidiffusion. Mais il me semble que la garantie de livraison est de plus en plus important pour la surveillance du réseau que de la capacité de diffusion. Surtout quand il y a de graves haut-besoins de sécurité. Un de mes collègues m'a dit que les paquets UDP sont les premières à être supprimées lorsque la circulation est lourde. C'est encore une autre raison de préférer le protocole TCP/IP sur le port UDP pour la surveillance du réseau (OMI).

Alors pourquoi ne SNMP UDP? Je ne peux pas la comprendre et ne peut pas trouver une bonne raison sur Google non plus.

  • "Wikipédia dit que SNMP peut être exécuté sur TCP/IP", si vous lisez le RFC3430 soigneusement, faqs.org/rfcs/rfc3430.html vous allez voir c'est expérimental, de sorte que vous ne pouvait pas s'attendre à tous les fournisseurs de produit prend en charge.
  • +1 pour les questions pratiques
  • l'homme que vous êtes dur, il a besoin de creuser à travers RFC1155, 1157, 1212, 1215, 1901, 1908, 2578, 2579, 2580, 3416 et 3417 (v1 & v2c), ainsi que RFC1213, 2863, 3418, 4001, 4001, 4022, 4113, 4292, 4293 et 4898 (MIB) 🙂
  • 1) Grâce à la RFC lien 2) Message de l'avenir: la question n'était pas "en plus de ce protocole est en cours d'exécution", mais "pourquoi l'utilise UDP" 3) désolé pour le retard de réagir
InformationsquelleAutor EC0 | 2010-08-25
  1. 47

    UDP est effectivement prévu de travailler mieux que la TCP dans la perte des réseaux (ou congestionné, réseaux). TCP est bien mieux pour le transfert de grandes quantités de données, mais lorsque le réseau tombe en panne, il est plus probable que le protocole UDP sera de passer à travers. (en fait, j'ai récemment fait une étude de test et il a constaté que SNMP UDP réussi beaucoup mieux que le SNMP sur TCP dans la perte des réseaux lors de l'UDP délai d'attente a été réglé correctement). Généralement, TCP commence à se comporter mal à environ 5% de perte de paquets et devient complètement inutile à 33% (ish) et UDP va encore réussir (enfin).

    Donc la bonne chose à faire, comme toujours, est de choisir le bon outil pour le bon travail. Si vous êtes en train de faire de la surveillance de routine de beaucoup de données, vous pourriez envisager de TCP. Mais être prêt à revenir à UDP pour résoudre des problèmes. La plupart des piles de ces jours peut effectivement utiliser TCP et UDP.

    Comme pour l'envoi des Pièges, oui les Pièges ne sont pas fiables car ils ne sont pas reconnus. Cependant, SNMP Informe sont reconnu la version d'un TRAP SNMP. Donc si vous voulez savoir que la notification récepteur a reçu le message, merci d'utiliser l'Informe. Notez que TCP n' pas résoudre ce problème, car il ne fournit à la couche de niveau 3 de la notification que le message a été reçu. Il n'y a aucune assurance que la notification récepteur effectivement obtenu. SNMP Informe demande de niveau de reconnaissance et sont beaucoup plus dignes de confiance que de supposer un accusé de réception TCP indique ils l'ont obtenu.

    • "à propos de 33% [de perte de paquets] UDP va encore réussir (enfin)" - quel genre de magie est qui? Ne pas UDP juste fondamentalement aveuglément crier dans le vide, et espérer pour le mieux?
    • si vous criez constamment vous finirez par être entendu, c'est l'idée
    InformationsquelleAutor Wes Hardaker
  2. 12

    Si les systèmes envoyé des interruptions SNMP via TCP qu'ils pouvaient bloquer en attente pour les paquets roupe animé si il y avait un problème à obtenir le trafic vers le récepteur. Si beaucoup de pièges ont été générés, il pourrait utiliser les sockets disponibles sur le système et le système de verrouillage en place. Avec UDP qui n'est pas un problème parce qu'il est apatride. Un problème similaire a sorti BitBucket en janvier mais il a été syslog protocole plutôt que de SNMP-en gros, ils ont été par inadvertance à l'aide de syslog sur TCP en raison d'une erreur de configuration, le serveur syslog est allé vers le bas, et tous les serveurs verrouillé en place d'attente pour le serveur syslog ACK leurs paquets. Si des interruptions SNMP ont été envoyés sur le protocole TCP, un problème similaire peut se produire.

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

    InformationsquelleAutor Jonathan Dill
  3. 4

    L'utilisation de pièges SNMP est considéré comme peu fiable. Vous ne devrait vraiment pas être en s'appuyant sur les pièges.

    SNMP a été conçu pour être utilisé comme une demande/réponse de protocole. Le protocole de détails sont simples (d'où le nom de "simple network management protocol"). Et UDP est un très simple de transport. Essayez la mise en œuvre de TCP sur votre base de l'agent - c'est beaucoup plus complexe qu'un simple agent codées en utilisant UDP.

    SNMP get/getnext opérations ont un mécanisme de nouvelle tentative - si une réponse n'est pas reçu dans les délai d'attente alors la même demande est envoyée à un nombre maximum de tentatives.

    • Il est clairement évident que votre organisation n'ait pas pensé à leur stratégie de gestion du réseau. De temps pour obtenir certains membres du personnel sur certains cours d'éducation!
    • Je suppose que la simplicité est l'avantage de l'UDP a plus de TCP/IP que je ne pouvais pas comprendre. Je vous remercie pour cela. Je suis surpris, cependant, que l'inscription du pro & con arguments, je suis venu avec dans mes efforts pour comprendre la décision est considérée comme le dénigrement.
    • SNMP est vraiment une grande protocole; cependant, juste parce que la mise en œuvre du protocole est simple ne veut pas dire qu'il est simple à utiliser et à comprendre. Et pour une entreprise de trouver lui-même dans l'embarras car il a été en s'appuyant sur les pièges n'est rien de professionnel et montre un manque fondamental de la compréhension de la plus élémentaire des concepts de mise en réseau. Tout ce que je peux dire, c'est que je suis heureux d'ingénieurs civils en fait avoir à être certifié avant la construction d'infrastructures, les gens comptent sur.
    InformationsquelleAutor PP.
  4. 4

    Découvrez O'Reilly écrits sur SNMP: https://library.oreilly.com/book/9780596008406/essential-snmp/18.xhtml

    Un avantage de l'utilisation d'UDP pour des traps SNMP est que vous pouvez directement UDP à une adresse de diffusion, puis de les aligner avec plusieurs stations de gestion de ce sous-réseau.

    InformationsquelleAutor Scott
  5. 0

    Habituellement, lorsque vous êtes en train de faire SNMP, vous êtes sur un réseau d'entreprise, vous ne faites pas ceci sur le long terme. UDP peut être plus efficace. Regardons (une simplification grossière de) la conversation via TCP, puis via UDP...

    Version TCP:

    client sends SYN to server
server sends SYN/ACK to client
client sends ACK to server - socket is now established
client sends DATA to server
server sends ACK to client
server sends RESPONSE to client
client sends ACK to server
client sends FIN to server
server sends FIN/ACK to client
client sends ACK to server - socket is torn down

    UDP version:

    client sends request to server
server sends response to client

    généralement, l'UDP version réussit puisque c'est sur le même sous-réseau, ou pas loin (c'est à dire sur le réseau de l'entreprise).
    Cependant, si il ya un problème avec la demande initiale ou de la réponse, c'est à l'application de décider. A. peut-on s'en sortir avec un raté de paquets? si oui, qui s'en soucie, il suffit de déplacer sur. B. nous devons nous assurer que le message est envoyé? simple, il suffit de refaire le truc... client envoie une requête au serveur, le serveur envoie une réponse au client. L'application peut fournir un numéro, juste au cas où le destinataire du message reçoit les messages, il sait que c'est vraiment le même message envoyé à nouveau.

    Cette même technique est pourquoi le DNS est fait sur UDP. Il est beaucoup plus léger et généralement ça marche la première fois, parce que vous êtes censé être à proximité de votre DNS.

    InformationsquelleAutor Tony Schwartz