NetXMS Support Forum

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
}

V6.1.2

Dear Support Team,
I'm writing to seek technical support for two issues with the network topology functions.
When I right-click a node, select Topology maps, and choose Layer 2 topology or other topology types, the displayed topology coverage is far too large. It appears that the discovery scope is not restricted by the parameter Topology.DefaultDiscoveryRadius, which is currently set to 5.
Regarding the Network Map feature: when using MSTP links with ISP communication devices deployed between two end nodes, the system sometimes fails to recognize the connection relationship between the two terminal nodes. We presume this issue results from improper configuration of the intermediate ISP-side devices.
We sincerely hope you can offer relevant solutions and troubleshooting suggestions. Thank you very much for your help!
Best regards！

Hello NetXMS Development Team,
 
I have a question about the AI tool invocation format of NetXMS.
 
I heard that NetXMS currently only accepts AI tool calls developed based on standard JSON format, and it cannot work properly with models that adopt XML format for tool calling.
 
The Qwen3.6 series large models use XML format to implement tool invocation. I would like to confirm whether NetXMS is indeed incompatible with XML tool calling mode right now.
 
Besides, I sincerely hope that you can add support for XML format AI tool calls in subsequent version updates. This optimization will bring great convenience for users applying Qwen3.6 and other XML-based AI models.
 
Thank you very much for your time and support!

That's wonderful! I'm looking forward to the next version update, and thank you so much for your tremendous help!

I tested the command nxsnmpwalk -v 2c -c stonewell2000 10.61.43.131 1.3.6.1.2.1.17.7.1.2.2.1 separately on version 5.0.8 and 6.1.1, and there are obvious discrepancies between the two results. Only version 5.0.8 can retrieve the complete data normally.The packet capture logs of v6.1.1 have been uploaded as an attachment. Thank you so much!

Quote from: Victor Kirhenshtein on May 04, 2026, 01:53:50 PMIs there really only one row in SNMP walk result? If yes, try to do separate walks on 1.3.6.1.2.1.17.7.1.2.2.1.3 and 1.3.6.1.2.1.17.7.1.2.2.1.2 - there should be more entries. Also try walk on 1.3.6.1.2.1.17.4.3.1.3

This issue does not occur in version 5.X. Could you please assist us with the diagnosis and troubleshooting?

Quote from: Victor Kirhenshtein on May 04, 2026, 01:58:42 PMRegarding AI invocation - I've tried to check qwen3.6-35b-a3b model via OpenRouter, but looks like they don't have providers with tool calling support. From your screenshot it seems that tool call is not recognized and interpreted as part of an answer. Are you sure that runner or service you are using actually follows Open AI API?

Thanks for your guidance. I'll check with my colleague in charge of AI large models.

The SNMP walk result for 1.3.6.1.2.1.17.7.1.2.2.1 indeed returns only one entry, which is rather unusual. Many H3C switches show exactly the same result, whereas this used to work normally before.The SNMP traversal results for other OIDs are listed below. Thanks for your help.