Overview
After configuring an SNMP trap on a node, the node does not send the traps as intended. This article provides the steps on how to resolve the problem by:
Requirements
- VPN access
- Access to the lab system to double-check the configuration (optional)
- Access to the SNMP Trap Reference Guide available in Skyvera Help Center > NewNet > NewNet Download Center
Resolution
Step 1: Check the Node's Configuration
Check the configuration against the SNMP Trap Reference Guide. The trap configuration has the following format:
<trapreceiver ipaddress="111.222.333.444" udpport="162"/>
Optionally, the same line can be added to a lab system configuration file (common_config.txt), which can be validated for errors.
-
Log in as a TextPass user.
-
Move to the configuration directory:
$ cd /usr/TextPass/etc/
-
Create a backup of the configuration file:
$ cp -p common_config.txt common_config.txt_YYYYMMDD
-
Edit the configuration file:
$ vi common_config.txt
-
Add the line below towards the end of the configuration file, before the
</tpconfig>
tag and save the file:<trapreceiver ipaddress="111.222.333.444" udpport="162"/>
-
Validate the changes you have made. There should be no output, which means there are no errors in the configuration:
$ tp_config --validatecommonconfig common_config.txt
-
Connect to the VPN and verify the same configuration from all the nodes identified by the end-user. The sample below is from an LGP node.
-
Log in as a TextPass user and run the following command:
$ tp_walk -l alarmStationTable
Sample output:
alarmStationIndex.1 = Gauge32: 1
alarmStationIndex.2 = Gauge32: 2
alarmStationIndex.3 = Gauge32: 3
alarmStationIpAddress.1 = STRING: "127.0.0.1"
alarmStationIpAddress.2 = STRING: "127.0.0.1"
alarmStationIpAddress.3 = STRING: "111.222.333.444"
alarmStationUdpPort.1 = Gauge32: 11173
alarmStationUdpPort.2 = Gauge32: 11173
alarmStationUdpPort.3 = Gauge32: 162
Step 2: Checking the Connectivity
After verifying that the node has been configured correctly, check the connectivity (the end-user should also confirm end-to-end connectivity). Log in as a TextPass user and execute the following command:
$ ping 111.222.333.444
Step 3: Analyze a Trap's Trace
After verifying the node's configuration and connectivity, you can now conduct a trace on the port, which will simulate a trap in the node. This step will allow you to see what is happening with the traps.
If the node does not generate actual traffic (like an LGP), restarting tp_fclient
will not affect the service.
Note: All processes that need to be restarted require the customer's permission.
Example (for an LGP):
- Open three SSH connections to the LGP node:
-
In the first connection, log in as a root user and only type the
tcpdump
command below, where<path>
refers to a directory with enough space:tcpdump -i any -s 0 -w /<path>/<filename>.pcap port 162
Important: Please DO NOT run the code yet.
-
In the second connection, log in as a root user and use the
tail
command on the syslog, which will allow you to monitor the trap that will be generated:tail -f /var/log/messages
-
In the third connection, log in as a TextPass user and note/copy the following command to restart tp_fclient :
tp_stop --tp_fclient; tp_start --tp_fclient
Important: Please DO NOT run the code yet.
-
Run the trace provided in step 1a, and immediately run the tp_fclient restart command in step 1c.
-
Monitor the connection using the command in step 1b. If a trap appears, stop the trace in the running connection (from step 1a) by pressing Ctrl + C on your keyboard. Stop the trace when the tp_fclient is up and running.
-
To check the tp_fclient status, run the command below as a TextPass user:
tp_status --tp_fclient
-
Collect the trace and analyze if the node is sending the traps to the configured IP address and port. Examine what happens to the trap that was sent.