Any one who can help with the following question:
- If a SNMP polling device is requesting information on a cisco switch of router, how large would the packet be?
- When the software ask for more than one OID, will it do so in only one request? So, the request makes the packet response larger?
- Or will a polling software iterate to the 'OID-information'? So more or less a stream of responses?
Any idea or experience is welcome.
Hello @bart.dermul1 ,
for a simple GET command the SNMP packet will be not so big the message code, the SNMP community and the OID of the requested MIB.
However, GET-BULK is also available and in this case the answer from device have to provide all the elements on the MIB table indicated by the OID.
WARNING: it is possible to create a self originated denial of service if for example a router with a full BGP table is queried every few minutes to provide the current BGP table or IP routing table.
From a single request thousands of answer packets should be prepared and sent to the poller.
It is very important to understand the impact of a GET or GET-BULK to avoid issues that can include device instability and device crash in the worst case.
In other cases I have seen heavy monitoring impacting on performance of monitored devices.
Hope to help
"If a SNMP polling device is requesting information on a cisco switch of router, how large would the packet be?"
I believe the response packet(s) will follow usual IP rules for MTU. I.e. if the requested data won't all fit in one MTU sized packet, multiple MTU sized packets will be sent, except, of course, for the last packet.
One often overlooked "gotcha", MTU is usually limited to 576, for all off local network destinations, unless PMTUD is enabled. (NB: this "gotcha" is often also overlooked regarding BGP too. [I.e. something like BGP session startup, for Internet tables, often "speeds up" when off local network MTU is actually used.]) Also when PMTUD is not enabled, off local network destination packets might be fragmented, but normally unlikely as 576 being used.
As to what is a "response", it would be per SNMP command (as also explained by Giuseppe). I.e. one logical response per GET or GET-BULK.
Both reply are helpful. I did some wiresharking in the MTU 'snmp-server packet size' and on the GET and REPLY situation.
In the first case I guess the command didn't do anything. Probably because of the reason that I only did an ifindex walk. So the responses where kept small. However, I did lower the MTU to 500 and even then it did not chop up the reply. I guess it is a legacy command and that my Tunnel interface takes priority.
In terms of the SNMP reply, it is indeed what I would expect. Thank you for confirming.
With the wireshark I noticed many packets returning and that created a stream for a few minutes between 80-160kbps.
So the relation between polling interval and the transmission delay are better to think over.
I wish you a nice day !