Wish: Catalyst 1200/1300

[Mitzhel]

Hello.

I would like to submitt a wish:
Portadmin support for the Cisco Catalyst 1200 and 1300 switches.

They are the successor to Cisco's CBS line, and have the same problems as described in Github issue 3046.
Our model is the C1200-24P-4G and have 1.3.6.1.4.1.9.1.3217 as sysObjectID

All "General mode" ports shows as a trunk, with no VLANs in the list.

Changing the sysObjectID in NAV to 1.3.6.1.2.1.17.7 as described in issue 3046, makes Portadmin partialy work.
The "General PVID" is correctly set on the port, but NAV still shows the error "Error setting vlan: SNMP Error: wrongValue (The set value is illegal or unsupported in some way)".

The sysObjectID in NAV gets reverted to original after a while. Is there another way to force Portadmin to use the SNMPHandler?

Example port:
Name: gi2
Switchport: enable
Administrative Mode: general
Operational Mode: down
Access Mode VLAN: 1
Trunking Native Mode VLAN: 248
Trunking VLANs: 1,240-244,247-249
2-239,245-246,250-4094 (Inactive)
General PVID: 240
General VLANs: 240-244,247-249
General Egress Tagged VLANs: 244
General Forbidden VLANs: none
General Ingress Filtering: enabled
General Acceptable Frame Type: all
General GVRP status: disabled
Customer Mode VLAN: none

Datasheets:
https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-1200-series-switches/nb-06-cat1200-ser-data-sheet-cte-en.html
https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-1300-series-switches/nb-06-cat1300-ser-data-sheet-cte-en.html

Thank you

[lunkwill42]

They are the successor to Cisco's CBS line, and have the same problems as described in Github issue #3046. Our model is the C1200-24P-4G and have 1.3.6.1.4.1.9.1.3217 as sysObjectID

CISCO-PRODUCTS-MIB defines this as:

ciscoC120024P4G                     OBJECT IDENTIFIER ::= { ciscoProducts 3217 } -- Catalyst 1200 Series Smart Switch, 24-port GE, PoE, 4x1G SFP (C1200-24P-4G)

All "General mode" ports shows as a trunk, with no VLANs in the list.

Changing the sysObjectID in NAV to 1.3.6.1.2.1.17.7 as described in issue #3046, makes Portadmin partialy work. The "General PVID" is correctly set on the port, but NAV still shows the error "Error setting vlan: SNMP Error: wrongValue (The set value is illegal or unsupported in some way)".

Not really sure where you got 1.3.6.1.2.1.17.7 from; this is not a proper sysObjectID value, it is the root OID of the Q-BRIDGE-MIB.

The sysObjectID in NAV gets reverted to original after a while. Is there another way to force Portadmin to use the SNMPHandler?

Not really, no. The sysObjectID is always collected using SNMP and will always revert to the collected value when the inventory job runs.

The problem here is that your switch' sysObjectID value places it squarely in the normal range of ciscoProducts. If this switch represents a new line of switches that do not behave as "normal" Cisco switches, then the SNMP backend selector in PortAdmin would have to keep even more exceptions to the ".1.3.6.1.4.1.9 is always Cisco" rule. From the latest CISCO-PRODUCTS-MIB I can see at least 44 different sysObjectID values for the 1200- and 1300-series switches.

If newer Cisco products are actually moving away from the old method of community-indexing for getting VLAN information, then we would need to implement a new heuristic for detecting which back-end is proper to use for these products. Perhaps by having ipdevpoll testing the capabilities of a Cisco device and adding some sub-categorization attributes to it (the PortAdmin back-end selector does not use SNMP requests to classify each switch, it relies on data that has already been collected about the device)
.

[Mitzhel]

Not really sure where you got 1.3.6.1.2.1.17.7 from; this is not a proper sysObjectID value, it is the root OID of the Q-BRIDGE-MIB.

Indeed, but it did make Portadmin use SNMPHandler.
I tried 1.3.6.1.4.1.9.6.1.1004.10.1 that you mentioned in #3046, but errors when opening Portadmin:

Request Method:	GET
Request URL:	https://nav.oo.no/portadmin/interfaceid%3D10564/data/
Django Version:	4.2.25
Exception Type:	TypeError
Exception Value:	'NoneType' object is not callable
Exception Location:	/opt/venvs/nav/lib/python3.9/site-packages/nav/web/portadmin/views.py, line 447, in set_voice_vlan_attribute_cisco
Raised during:	nav.web.portadmin.views.load_portadmin_data
Python Executable:	/opt/venvs/nav/bin/python
Python Version:	3.9.2
Python Path:	['/usr/lib/python39.zip',
 '/usr/lib/python3.9',
 '/usr/lib/python3.9/lib-dynload',
 '/opt/venvs/nav/lib/python3.9/site-packages',
 '/usr/local/lib/python3.9/dist-packages',
 '/usr/lib/python3/dist-packages',
 '/usr/lib/python3.9/dist-packages',
 '/opt/venvs/nav/lib/python3.9/site-packages',
 '/etc/nav/python']
Server time:	Tue, 04 Nov 2025 12:28:06 +0100

Not really, no. The sysObjectID is always collected using SNMP and will always revert to the collected value when the inventory job runs.

Seems if i change "Sysobjectid" and leave "Type name" alone, it dosen't revert. But it causes inventory to fail:

[ERROR jobs.jobhandler] [inventory switch] Job 'inventory' for switch aborted: Job aborted due to plugin failure (cause=IntegrityError('duplicate key value violates unique constraint "type_vendorid_typename_key"\nDETAIL: Key (vendorid, typename)=(cisco, .1.3.6.1.4.1.9.1.3217) already exists.\n'))

If newer Cisco products are actually moving away from the old method of community-indexing for getting VLAN information, then we would need to implement a new heuristic for detecting which back-end is proper to use for these products. Perhaps by having ipdevpoll testing the capabilities of a Cisco device and adding some sub-categorization attributes to it (the PortAdmin back-end selector does not use SNMP requests to classify each switch, it relies on data that has already been collected about the device)

It's quite possible, since they are also the successor to the Catalyst 1000-line.
I've read that the the 1000-switches are the last ones to use classic IOS, as 1200/1300 uses the same OS as the CBS-line

If there are any possibility that NAV could support these switches, we are willing to donate both a 1200 and a 1300 switch if it helps

[lunkwill42]

Indeed, but it did make Portadmin use SNMPHandler.

Sure, any unknown sysObjectID value would cause that.

I tried 1.3.6.1.4.1.9.6.1.1004.10.1 that you mentioned in #3046, but errors when opening Portadmin:

Request Method:	GET
Request URL:	https://nav.oo.no/portadmin/interfaceid%3D10564/data/
Django Version:	4.2.25
Exception Type:	TypeError
Exception Value:	'NoneType' object is not callable
Exception Location:	/opt/venvs/nav/lib/python3.9/site-packages/nav/web/portadmin/views.py, line 447, in set_voice_vlan_attribute_cisco
Raised during:	nav.web.portadmin.views.load_portadmin_data
Python Executable:	/opt/venvs/nav/bin/python
Python Version:	3.9.2
Python Path:	['/usr/lib/python39.zip',
 '/usr/lib/python3.9',
 '/usr/lib/python3.9/lib-dynload',
 '/opt/venvs/nav/lib/python3.9/site-packages',
 '/usr/local/lib/python3.9/dist-packages',
 '/usr/lib/python3/dist-packages',
 '/usr/lib/python3.9/dist-packages',
 '/opt/venvs/nav/lib/python3.9/site-packages',
 '/etc/nav/python']
Server time:	Tue, 04 Nov 2025 12:28:06 +0100

Unfortunately, this doesn't tell me too much without a full traceback - i.e. I can identify which line errors out, but not really why.

Not really, no. The sysObjectID is always collected using SNMP and will always revert to the collected value when the inventory job runs.

Seems if i change "Sysobjectid" and leave "Type name" alone, it dosen't revert. But it causes inventory to fail:

[ERROR jobs.jobhandler] [inventory switch] Job 'inventory' for switch aborted: Job aborted due to plugin failure (cause=IntegrityError('duplicate key value violates unique constraint "type_vendorid_typename_key"\nDETAIL: Key (vendorid, typename)=(cisco, .1.3.6.1.4.1.9.1.3217) already exists.\n'))

Not really sure what you changed here. Did you change the sysObjectID value of an already existing type entry in NAV/SeedDB? That wouldn't normally be advisable. It seems here that ipdevpoll collected the switch' real sysObjectID, could not find it in the database, and tried to create a new entry for it - except that the type name it tries to autogenerate is a duplicate of the entry whose sysObjectID you changed - so now it is unable to register the real type of the switch (or process the switch) until you clean up the typename of the record you changed in SeedDB.

It's quite possible, since they are also the successor to the Catalyst 1000-line. I've read that the the 1000-switches are the last ones to use classic IOS, as 1200/1300 uses the same OS as the CBS-line

If there are any possibility that NAV could support these switches, we are willing to donate both a 1200 and a 1300 switch if it helps

There's always a possibility. Cisco was the most prevalent vendor in the Norwegian HE sector when NAV was first built, so a lot of focus was put into that. While our internal focus may be more on Juniper these days, Cisco is probably still most prevalent among our customer base (though the CBS line is probably not used by anyone here, so we have nothing to test on).

I'm not sure how you would go about donating switches. For testing/development purposes, it would be just as good if you were able to set up a switch in a lab setting and provide us with remote access to it.

[Mitzhel]

Unfortunately, this doesn't tell me too much without a full traceback - i.e. I can identify which line errors out, but not really why.

Here is the full error message i got on email from NAV:
Django ERROR (EXTERNAL IP) Internal Server Error portadmininterfaceid10564data.htm
Is this the one you need, or can i generate a trace another way?

Not really sure what you changed here. Did you change the sysObjectID value of an already existing type entry in NAV/SeedDB?

That's correct. It's run like this a couple of weeks, and dosen't seem to have broken anything else, yet.

I'm not sure how you would go about donating switches. For testing/development purposes, it would be just as good if you were able to set up a switch in a lab setting and provide us with remote access to it.

I thought it would be more convenient for you to be able to test them on-hand.
We could buy them from Atea and send them directly to you.

I can of course set up a lab instead if you wish.