NetXMS Support Forum

Thank you very much.

Thank you very much. The physical topology is shown in the figure. There is no physical link between MEth0/0/0 and 10GE2/0/1. The SNMP logs have been uploaded. Could you please help analyze and provide guidance? I would highly appreciate your support!

My apologies, I overlooked that. The version of NetXMS is 6.2.1.

Thank you for your help! I found that the peer node information on both devices failed to fully auto-update to the latest timestamp. I have manually deleted all port entries with a Peer Last Updated timestamp from half a month ago on the two devices, then re-run the configuration polling operation with reset. Please refer to the attachment for the current running status of the devices; could you help analyze this issue and advise a solution?

I sincerely need your help troubleshooting abnormal PeerNode recognition on Huawei S16808 switches. Screenshots of network topology and device links in NetXMS are attached.
Below are nxsnmpwalk commands and outputs against the Huawei private OID on both switches:
plaintext
root@XMNMS01:~# /usr/bin/nxsnmpwalk -v 2c -c stonewell2000 10.61.99.2 1.3.6.1.4.1.2011.5.25.42.4.1.19.1.2
huaweiDatacomm.42.4.1.19.1.2.0 [Hex-STRING]: 00 00 AC 5E 14 7F 89 01

root@XMNMS01:~# /usr/bin/nxsnmpwalk -v 2c -c stonewell2000 10.61.99.3 1.3.6.1.4.1.2011.5.25.42.4.1.19.1.2
huaweiDatacomm.42.4.1.19.1.2.0 [Hex-STRING]: 00 00 AC 5E 14 7F 89 01
Could you please help identify the root cause and advise a fix? Many thanks.

Thanks very much!

Thanks so much for your reply！
Here is the result：

root@XMNMS01:~# /usr/bin/nxsnmpwalk -v 2c -c stonewell2000 10.61.10.9 1.3.6.1.4.1.2011.5.25.42.4.1.19.1.2
huaweiDatacomm.42.4.1.19.1.2.0 [Hex-STRING]: 80 00 E4 DC CC 1A 59 61
root@XMNMS01:~# /usr/bin/nxsnmpwalk -v 2c -c stonewell2000 10.61.10.10 1.3.6.1.4.1.2011.5.25.42.4.1.19.1.2
huaweiDatacomm.42.4.1.19.1.2.0 [Hex-STRING]: 80 00 E4 DC CC 1A 59 61
root@XMNMS01:~# snmpwalk -v 2c -c stonewell2000 10.61.10.9 1.3.6.1.4.1.2011.5.25.42.4.1.19.1.2
Created directory: /var/lib/snmp/cert_indexes
iso.3.6.1.4.1.2011.5.25.42.4.1.19.1.2.0 = Hex-STRING: 80 00 E4 DC CC 1A 59 61
root@XMNMS01:~# snmpwalk -v 2c -c stonewell2000 10.61.10.10 1.3.6.1.4.1.2011.5.25.42.4.1.19.1.2
iso.3.6.1.4.1.2011.5.25.42.4.1.19.1.2.0 = Hex-STRING: 80 00 E4 DC CC 1A 59 61
root@XMNMS01:~#

Dear NetXMS Moderators and Support Team,
I am writing to ask for your guidance on an interface identification issue.
I have two Huawei C8865 switches configured as an MLAG pair, with IP addresses 10.61.10.9 and 10.61.10.10 respectively. There are only 3 physical ports used for inter-switch interconnection between the two devices. However, NetXMS incorrectly recognizes a large number of other unrelated ports as inter-switch interconnect ports.
I have uploaded the system screenshots and detailed interface information for your reference. It would be highly appreciated if you could help look into this issue and offer some advice.
Thank you very much for your time and assistance.

Thanks a lot for your help. I'll give it a try.

Quote from: Filipp Sudanov on June 09, 2026, 12:36:35 PMCan you give some examples of the issues for which you want to send notifications? How it can be determined that it's the same issue?

Thanks for your reply!

For nodes with frequent online/offline status or fluctuating PING latency around the threshold caused by line issues, do not send repeated alarms temporarily as the admin has been informed. Send recovery alerts only after the initial alarm is issued, and keep alerting for other new fault types on the same node.

Thank you so much for taking the time to reply to my post and offer your help!

I'm trying to set up reliable alarm and recovery notifications for my monitoring setup, and I was hoping you could advise me on the best way to achieve this using **native EPP rule configurations** in NetXMS 6.1.3, without needing to write custom NXSL scripts.

The core functionality I need is:
1.  **Alarm deduplication**: Only send one notification for the same issue within a 2-hour window, to avoid spamming
2.  **Proper alarm-recovery pairing**: Ensure recovery notifications are only sent for issues that actually triggered an alarm earlier
3.  **Targeted device filtering**: Only send notifications for devices I've marked as "focused" (not all devices in the system)

I did try writing my own NXSL scripts to implement this, but I got stuck on one critical part: I couldn't figure out how to design a **universal key value that works across all types of events and alarms** (similar to what I've seen others refer to as an "alarm key") to properly link alarm events with their corresponding recovery events. Without this, I can't reliably ensure that a recovery notification is only sent if an alarm notification was actually sent for that specific issue first.

I've looked through the EPP rule settings but I'm not sure how to combine these three requirements correctly using the built-in options. Could you walk me through how to configure the EPP rules to achieve this, or point me to the relevant documentation sections?

Thanks again for your time and generosity.

We suspect it might be a switch configuration problem, yet it functions normally occasionally. We'll keep an eye on it. Thanks for your help.

Thank you very much. The nDepth attribute was not found in the logs. Could you please help check the log files. Thanks a lot!

But this topology issue seems to persist. I'm not sure if it's due to my wrong configuration. Could you please give me some guidance? Thanks a lot!

The model is deployed using vLLM with the configuration --tool-call-parser=hermes. Could you please provide guidance?

Below is a current example:
[root@ai-app-0l apps]# curl http://IP:8001/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <your_token>" \
-d '{
  "model": "qwen3.6-35b-a3b",
  "messages": [
    {"role": "user", "content": "What's the weather like in Beijing today?"}
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "Get the current weather for the specified city",
        "parameters": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "City name, e.g., Beijing, Shanghai"
            }
          },
          "required": ["location"]
        }
      }
    }
  ]
}'

Response:

{
  "id": "chatcmpl-a914ca7d228bc903",
  "object": "chat.completion",
  "created": 1779196243,
  "model": "qwen3.6-35b-a3b",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "\n\n<tool_call>\n<function=get_weather>\n<parameter=location>\nBeijing\n</parameter>\n</function>\n</tool_call>",
        "refusal": null,
        "annotations": null,
        "audio": null,
        "function_call": null,
        "tool_calls": [],
        "reasoning": "Here's a thinking process:\n\n1. **Analyze User Input:**\n - User asks: \"What's the weather like in Beijing today?\"\n - Key entity: Beijing\n - Request: Current weather\n\n2. **Identify Available Tools:**\n - I have one tool: 'get_weather'\n - Tool description: Get the current weather for a specified city\n - Parameters: 'location' (string, required) - City name, e.g., Beijing, Shanghai\n\n3. **Map User Input to Tool Parameters:**\n - 'location' should be \"Beijing\"\n\n4. **Execute Tool Call:**\n - Call 'get_weather' with 'location: \"Beijing\"'\n\n5. **Process Tool Response (Simulation/Expectation):**\n - Since I don't have real-time access, I'll simulate the tool call and assume it returns a reasonable weather response. However, in this environment, I will actually make the tool call and let the system handle it. I'll generate the tool call now.\n\n Tool Call:\n```json\n{\n  \"name\": \"get_weather\",\n  \"parameters\": {\n    \"location\": \"Beijing\"\n  }\n}\n```\n\n6. **Formulate Response:**\n After receiving the tool response, I will present the weather information clearly to the user in Chinese.\n - For now, I'll just make the tool call."
      },
      "logprobs": null,
      "finish_reason": "stop",
      "stop_reason": null,
      "token_ids": null
    }
  ],
  "service_tier": null,
  "system_fingerprint": null,
  "usage": {
    "prompt_tokens": 284,
    "total_tokens": 656,
    "completion_tokens": 372,
    "prompt_tokens_details": null
  },
  "prompt_logprobs": null,
  "prompt_token_ids": null,
  "ky_transfer_params": null
}