× NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Orbi WiFi 7 RBE973
Reply

GS748Tv5 Unable to add tagged VLAN members using SNMP

mvduin
Guide

GS748Tv5 Unable to add tagged VLAN members using SNMP

GS748Tv5 running latest firmware (v6.3.1.43)

 

Adding ports to a VLAN via SNMP causes these to be implicitly added to the untagged set. For example, here vlan 1000 initially has no members:

~$ snmpget $switch_hostname dot1qVlanStatic{Egress,Untagged}Ports.1000
Q-BRIDGE-MIB::dot1qVlanStaticEgressPorts[1000] = Hex-STRING: 00 00 00 00 00 00 00 00 00 00 00 00
Q-BRIDGE-MIB::dot1qVlanStaticUntaggedPorts[1000] = Hex-STRING: 00 00 00 00 00 00 00 00 00 00 00 00

If we then add ports 1-8 to the egress port mask,

~$ snmpset $switch_hostname dot1qVlanStaticEgressPorts.1000 x ff0000000000000000000000
Q-BRIDGE-MIB::dot1qVlanStaticEgressPorts[1000] = Hex-STRING: FF 00 00 00 00 00 00 00 00 00 00 00

then they inexplicably also get added to the untagged port mask:

~$ snmpget $switch_hostname dot1qVlanStatic{Egress,Untagged}Ports.1000
Q-BRIDGE-MIB::dot1qVlanStaticEgressPorts[1000] = Hex-STRING: FF 00 00 00 00 00 00 00 00 00 00 00
Q-BRIDGE-MIB::dot1qVlanStaticUntaggedPorts[1000] = Hex-STRING: FF 00 00 00 00 00 00 00 00 00 00 00

Explicitly setting dot1qVlanStaticUntaggedPorts to all-zeros in the same set-request does not help, all ports added to EgressPorts still get added to UntaggedPorts anyway.

 

It is possible to first add ports to the egress port set and then subsequently remove them from the untagged port set as workaround, but this still leaves a short window of time where these ports are untagged members and can end up receiving packets from this vlan without a vlan tag, which is obviously very much undesirable, especially if they are already an untagged member of a different VLAN.

 

Adding VLANs via SNMP also seems to be quite buggy. If you do not specify the egress port set then the VLAN gets added just fine but again all of the ports are implicitly untagged members:

~$ snmpset $switch_hostname dot1qVlanStaticRowStatus.1000 = createAndGo  dot1qVlanStaticEgressPorts.1000 x ff0000000000000000000000
Q-BRIDGE-MIB::dot1qVlanStaticRowStatus[1000] = INTEGER: createAndGo(4)
Q-BRIDGE-MIB::dot1qVlanStaticEgressPorts[1000] = Hex-STRING: FF 00 00 00 00 00 00 00 00 00 00 00
~$ snmpget $switch_hostname dot1qVlanStatic{EgressPorts,UntaggedPorts}.1000
Q-BRIDGE-MIB::dot1qVlanStaticEgressPorts[1000] = Hex-STRING: FF 00 00 00 00 00 00 00 00 00 00 00
Q-BRIDGE-MIB::dot1qVlanStaticUntaggedPorts[1000] = Hex-STRING: FF 00 00 00 00 00 00 00 00 00 00 00

But you try to explicitly configure the untagged set during creation, you usually get a commit-failure but the vlan gets created anyway with all ports untagged:

~$ snmpset $switch_hostname dot1qVlanStaticRowStatus.1000 = createAndGo dot1qVlanStaticEgressPorts.1000 x ff0000000000000000000000 dot1qVlanStaticUntaggedPorts.1000 x 000000000000000000000000
Error in packet.
Reason: commitFailed
Failed object: Q-BRIDGE-MIB::dot1qVlanStaticRowStatus[1000]

~$ snmpget $switch_hostname dot1qVlanStatic{Egress,Untagged}Ports.1000
Q-BRIDGE-MIB::dot1qVlanStaticEgressPorts[1000] = Hex-STRING: FF 00 00 00 00 00 00 00 00 00 00 00
Q-BRIDGE-MIB::dot1qVlanStaticUntaggedPorts[1000] = Hex-STRING: FF 00 00 00 00 00 00 00 00 00 00 00

Bizarrely it will sometimes work correctly, but if you then remove the newly created vlan and try the exact same creation command a second time it will fail again. Whether or not you provide other fields (StaticName and/or ForbiddenPorts) does not seem to matter, they get sensible defaults if omitted.

 

Note btw that a commitFailed error is supposed to indicate that:

  1. The set request passed validation, hence the agent commenced to apply the changes.
  2. Some kind of unexpected internal error occurred preventing the changes from being successfully applied (despite previous validation).
  3. Any changes made have been successfully undone.

That final part clearly didn't happen here, even though undoing should be easy in this case (just delete the created VLAN). As a last resort, if undoing the changes also failed for some reason then an undoFailed error should be reported instead of commitFailed (though the SNMPv2 spec emphatically encourages implementations to "take all possible measures" to prevent this from happening).

Message 1 of 1
Top Contributors
Discussion stats
  • 0 replies
  • 662 views
  • 0 kudos
  • 1 in conversation
Announcements