SNMP discovery Issues

Products

• VMware Smart Assurance

Issue/Introduction

• Getting below error on device discovery. 

    SWFE-E-EGETNEXT-While getting next of OID <oid>

• However, no issues seen on manually running the commands snmpgetnext and snmpbulkget on OID reported in the above error. PFB the commands:
  • snmpgetnext -v 2c -c <community> <device_IP> .1.3.6.1.2.1.2.2.1.2
  • snmpbulkget -v 2c -c <community> <device_IP> .1.3.6.1.2.1.2.2.1.2

• Fragmented IP protocol seen in the tcpdump captured (tcpdump -i any host <device_ip> and port 161 -w tcpdump.pcap) for getBulkRequest on above OID reported in the error while device discovery. PFB screenshot of an example for reference:

       

Environment

All supported Smarts releases

Cause

• In the above example it is seen that get-response for getBulkRequest on OID .1.3.6.1.2.1.2.2.1.2 is getting fragmented as the get-response size is 1516 bytes.

• The maximum transmission unit (MTU) is the largest size a data packet can be transmitted over a network connection without fragmentation. For standard Ethernet, the default MTU is 1500 bytes.

• It seems MTU set at the device end is less than or equal to 1500.

• When the fragmentation happens, at the destination end, the TCP stack is supposed to unite or stitch the packet. That is the responsibility of the TCP stack process. In some cases, not all the time. The stitching may fail or it may take time.

• Since this is an UDP packet, there is no assurance that it will be well stitched.

Resolution

• There are multiple ways to address this issue like increase MTU at the device end or ensure Smarts is sending snmp requests whose response size is less than the MTU set at the device end.

• From Smarts end you can disable getBulk requests for the impacted device sysOID referring to the KB.