AI skills invocation issues and MAC address learning issues with port "security"
-
-
Is 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
-
Regarding 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?
-
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.
-
@victor said in AI skills invocation issues and MAC address learning issues with port "security":
Regarding 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.
-
@victor said in AI skills invocation issues and MAC address learning issues with port "security":
Is 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?
-
It looks like regression in SNMP library. Could you please try same SNMP walk from command line using nxsnmpwalk tool? Ideally do walk on same device using nxsnmpwalk from v5 as well.
If there will be discrepancies between v5 and v6, send me packet capture from v6 walk if possible. -
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!
-
Problem is with device processing SNMP GET NEXT requests incorrectly; standard requires that GET NEXT should return OID that is strictly higher than previous one; however, device returns entries in FDB in random order:
1.3.6.1.2.1.17.7.1.2.2.1.2.67.180.5.93.216.211.69 [INTEGER]: 15
1.3.6.1.2.1.17.7.1.2.2.1.2.70.28.131.65.44.65.209 [INTEGER]: 53
1.3.6.1.2.1.17.7.1.2.2.1.2.64.180.5.93.216.211.179 [INTEGER]: 53third entry actually less than first one.
In version 6 we did some optimizations to SNMP walk, including stricter checks for loop detection, this is why walk on H3C start failing. In next patch release we will relax it to handle buggy devices like this one.
-
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login