Status in source: current.
Names: vtssVclConfigIpTable
Technical details
{
"smi_kind": "OBJECT-TYPE",
"definition": [
"vtssVclConfigIpTable",
"OBJECT-TYPE",
"SYNTAX",
"SEQUENCE",
"OF",
"VTSSVclConfigIpEntry",
"MAX-ACCESS",
"not-accessible",
"STATUS",
"current",
"DESCRIPTION",
"\"This is the IP Subnet to VLAN ID configuration table. The key of this table is the IP subnet expressed as x.x.x.x/x, where the first 4 octets represent the IPv4 address and the last one is the mask length. NOTE#1: Inside the VCL module these entries are actually sorted based on a priority defined by the mask length, so that subnets with larger mask lengths are first in the list, followed by entries with smaller mask lengths. SNMP cannot follow this sorting, therefore the order the entries are retrieved by the iterator may not be the same as the actually stored order. (This is not an issue, but should be taken into consideration when using the SNMP interface to create a user interface. NOTE#2: Even though only the subnet address is stored in the table (i.e. both 192.168.1.0/4 and 192.168.2.0/4 will end up as 192.0.0.0/4), the SNMP iterator will NOT take this into consideration. So, when searching the next subnet of 192.168.1.0/4, the result could be 193.0.0.0/4 but not 192.168.1.0/24 (granted that these entries are present)\"",
"::=",
"{",
"vtssVclConfigIp",
"1",
"}"
],
"syntax_tree": [
[
"conceptualTable",
[
"row",
"VTSSVclConfigIpEntry"
]
],
null,
[
"MaxAccessPart",
"not-accessible"
],
[
"Status",
"current"
],
[
"DESCRIPTION",
"This is the IP Subnet to VLAN ID configuration table. The key of this table is the IP subnet expressed as x.x.x.x/x, where the first 4 octets represent the IPv4 address and the last one is the mask length. NOTE#1: Inside the VCL module these entries are actually sorted based on a priority defined by the mask length, so that subnets with larger mask lengths are first in the list, followed by entries with smaller mask lengths. SNMP cannot follow this sorting, therefore the order the entries are retrieved by the iterator may not be the same as the actually stored order. (This is not an issue, but should be taken into consideration when using the SNMP interface to create a user interface. NOTE#2: Even though only the subnet address is stored in the table (i.e. both 192.168.1.0/4 and 192.168.2.0/4 will end up as 192.0.0.0/4), the SNMP iterator will NOT take this into consideration. So, when searching the next subnet of 192.168.1.0/4, the result could be 193.0.0.0/4 but not 192.168.1.0/24 (granted that these entries are present)"
],
null,
null,
null,
null
]
}