netconfd-pro Hooks Into Net-SNMP

When started with --with-snmp=true, netconfd-pro starts its SNMP agent listener using the Net-SNMP agentaddress setting in snmpd.conf. Without an agentaddress or agentAddress directive, the default listener remains UDP port 161. During boot, netconfd-pro also creates trap sinks and enables the SNMP server. This includes:

  • SNMP configuration file parsing

  • Registering a handler for incoming SNMP packets. This is the callback registered for incoming packets

  • Registering the Network Service Address Point (NSAP) with the net-snmp library and setup an agent session on the given transport. In this step netconfd-pro links the net-snmp library and registers all the needed callbacks and handlers that will be used for packet handling, PDU creation, and reply output

  • Reading the Net-SNMP agentaddress setting to select the server listener transport. Without a listener directive, the default remains the Net-SNMP UDP listener. TLS/TCP and DTLS/UDP listeners are available when the linked Net-SNMP build includes those transports and TSM.

Important

When upgrading from a release that ignored agentaddress or agentAddress as an unknown token, review existing snmpd.conf files before restarting. These directives now select the listeners and replace the default UDP endpoint. For example, agentaddress 127.0.0.1,[::1] restricts access to loopback; remote managers can no longer reach that agent. Explicitly include every required listener, including a UDP endpoint if existing managers use it. Repeated directives add endpoints to the configured listener list.

Then the server starts to check if there is any SNMP messages to process. It checks for any packets from the network. If there are any packets to process the server calls the net-snmp API to process them.

For SNMP requests, e.g. 'snmpget' on a GET2 node, the server will perform the following:

  • Parse the incoming packet (OID; request type ,get, getnext, etc)

  • Resolve the internal SNMP request type, request on indexed node, on scalar without any indexes, etc., based on the request type the server will adjust the target object resolution

  • Then the server will either try to find the best next OID and repeat the same steps or proceed to the actual value retrieval

  • In order to get the get2 value, the server calls the get2 callbacks starting from the table of the target node - the target node will always be a leaf

Based on the callback’s results, the server creates a new PDU to return, sets the return value(s) for the requested Varbind list in that PDU, and sends that packet back to the agent.

For config true and virtual nodes all the steps are the same except the server does not call get2 callbacks, it locates the requested Table in the database first, during the RESTCONF parse path processing, and after that the best value is retrieved from that Table.

yp-snmp – NETCONF and SNMP Message Paths

../_images/ypsnmp_message.png

When converted MIB modules are loaded into netconfd-pro server the Northbound protocols, such as NETCONF, access the YANG datastores in the usual way, i.e. through the message path colored red in the above diagram. Any notifications are handled in the usual way.

SNMP messages are processed by the Net-SNMP process and the netconfd-pro server with the SIL providing the instrumentation, i.e. the message path colored yellow in the diagram above. The server generates any SNMP Traps necessary.