Thinking this is more of a bug than a feature request since vlans are currently returned incorrectly.
Currently we are seeing an issue with Vlan to port association on Cumulus Linux. According to Cumulus this is the correct way to do it.
More info including Discovery, Poller, and Walk can be found at https://gist.github.com/theherodied/dba2fd38f459bf4b6481f3ec75d92d23
The dogt1qPvid indexing does not index by ifIndex. To get the ifindex you have to look at the ifindex to dot1xBasePortIfIndex. RFC 4188 (BRIDGE-MIB) defines the
dot1dBasePortIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
“The value of the instance of the ifIndex object,
defined in IF-MIB, for the interface corresponding
to this port.”
::= { dot1dBasePortEntry 2 }
And RF 4363 (Q-BRIDGE-MIB) is where the pvids are shown. These are indexed by
dot1qPortVlanTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1qPortVlanEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
“A table containing per-port control and status
information for VLAN configuration in the device.”
::= { dot1qVlan 5 }
dot1qPortVlanEntry OBJECT-TYPE
SYNTAX Dot1qPortVlanEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
“Information controlling VLAN configuration for a port
on the device. This is indexed by dot1dBasePort.”
AUGMENTS { dot1dBasePortEntry }
::= { dot1qPortVlanTable 1 }
dot1qPvid OBJECT-TYPE
SYNTAX VlanIndex
MAX-ACCESS read-write
STATUS current
DESCRIPTION
“The PVID, the VLAN-ID assigned to untagged frames or
Priority-Tagged frames received on this port.
The value of this object MUST be retained across
reinitializations of the management system.”
REFERENCE
“IEEE 802.1Q/D11 Section 12.10.1.1”
DEFVAL { 1 }
::= { dot1qPortVlanEntry 1 }
So walking the Q-BRIDGE MIB bridge port ifindexing and then walk the BRIDGE-MIB to get the mapping from the bridge port ifindex to the ifindex.
There’s confusion caused by the fact that the pvid rows (as are most things in these mibs) are indexed by the bridge port number index and this is not the ifIndex you see when running “ip link show”. For some reason, the MIB authors felt the need to use their own indices and just map them back to the ifIndex.
Here’s an example that may help: I have a bridge with ports configured like
auto bridge
iface bridge
bridge-ports swp1 swp2 swp3 swp4 swp53 swp54s2 swp54s3
bridge-vids 11 100-110 666
bridge-vlan-aware yes
I get the bridge port number to IfIndex mapping in the BRIDGE-MIB (these are indeed the ifindex one sees when running ‘ip link show’):
BRIDGE-MIB::dot1dBasePortIfIndex.1 = INTEGER: 3
BRIDGE-MIB::dot1dBasePortIfIndex.2 = INTEGER: 4
BRIDGE-MIB::dot1dBasePortIfIndex.3 = INTEGER: 5
BRIDGE-MIB::dot1dBasePortIfIndex.4 = INTEGER: 6
BRIDGE-MIB::dot1dBasePortIfIndex.5 = INTEGER: 55
BRIDGE-MIB::dot1dBasePortIfIndex.6 = INTEGER: 59
BRIDGE-MIB::dot1dBasePortIfIndex.7 = INTEGER: 60
and so when I look at the PVID rows, I see the PVID for each bridge port number
down in the Q-BRIDGE-MIB, I can see:
Q-BRIDGE-MIB::dot1qPvid.1 = Gauge32: 1
Q-BRIDGE-MIB::dot1qPvid.2 = Gauge32: 1
Q-BRIDGE-MIB::dot1qPvid.3 = Gauge32: 1
Q-BRIDGE-MIB::dot1qPvid.4 = Gauge32: 1
Q-BRIDGE-MIB::dot1qPvid.5 = Gauge32: 1
Q-BRIDGE-MIB::dot1qPvid.6 = Gauge32: 1
Q-BRIDGE-MIB::dot1qPvid.7 = Gauge32: 1
…