Skip to content

Add support for management VLAN#105

Merged
vDorst merged 1 commit intomainfrom
mgmt_vlan
Jan 29, 2026
Merged

Add support for management VLAN#105
vDorst merged 1 commit intomainfrom
mgmt_vlan

Conversation

@logicog
Copy link
Owner

@logicog logicog commented Jan 27, 2026 •
edited
Loading

This adds support for the verification of a mangement vlan. When enabled, then the switch's CPU will not listen to any packets that are not tagged with the respective VLAN tag.
On the command line this is enabled by setting:

> vlan <vlan> mgmt

Setting the vlan ID of the management VLAN to 0 or 1 disables the mangement VLAN function.

The functionality can be tested by running on an attached PC ping to the switch. After powering up, the switch will reply to the pings.
Now:

> vlan 2 mgmt
Management VLAN set to 0x0002

========= ping no longer gets replies ===========

> vlan 2 1t

vlan_create called
vlan: 0x0002, members: 0x0210, tagged: 0x0210
vlan_create done 

> pvid 1 2

port_pvid_set called 
========= ping works again ===========

> vlan 0 mgmt
Management VLAN disabled

========= ping continues to work ===========

@vDorst
Copy link
Collaborator

vDorst commented Jan 28, 2026

I a missing why I can't set the management interface only to vlan 1. Is this a hardware limitation?

vDorst
vDorst reviewed Jan 28, 2026
View reviewed changes
Copy link
Collaborator

@vDorst vDorst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit

cmd_parser.c Outdated
Comment on lines 294 to 302
if (vlan == 1)
management_vlan = 0;
else
management_vlan = vlan;
if (!management_vlan) {
print_string("Management VLAN disabled\n");
} else {
print_string("Management VLAN set to "); print_short(management_vlan); write_char('\n');
}
Copy link
Collaborator

@vDorst vDorst Jan 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be just one if-statement. Using (vlan <= 1)

Copy link
Owner Author

@logicog logicog Jan 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will fix. Well spotted!

@logicog
Copy link
Owner Author

logicog commented Jan 28, 2026

I a missing why I can't set the management interface only to vlan 1. Is this a hardware limitation?

Sorry, that was my mistake. I should have mentioned in the comments of the example that 1 is actually the port number of the port the managing device is attached to. So we set PVID 2 for that port and require tagged ports and that is the easiest way that we can make all the packets from that PC end up in VLAN 2, which is the one that is accepted by the TCP/IP stack.

Regarding VLAN 1, it is actually the other way round: 1 is the default VLAN of the switch, so it is unsuitable as management VLAN, or rather, you can use 1 for management, but then you better disable this functionality. The switch can be run with VLAN entirely off, or VLAN on, in which case the switch always uses 1 as the default VLAN. You cannot disable VLAN 1 in that situation, so if you used it for management, that would be rather unsafe. Better to handle VLAN 1 for management as no management VLAN at all. But one could also say only 0 is management VLAN off, and assume users known that 1 would be unsafe.

Some unmanaged devices (e.g. the HG0402XG)have a switch which enables VLAN for the device, which just means that it will keep the tags.

@logicog logicog force-pushed the mgmt_vlan branch 2 times, most recently from 01bd9e1 to 6e5b2f3 Compare January 28, 2026 16:55
@logicog
Copy link
Owner Author

logicog commented Jan 28, 2026

Fixed and pushed rebased commit.

@vDorst
Copy link
Collaborator

vDorst commented Jan 29, 2026

Regarding VLAN 1, it is actually the other way round: 1 is the default VLAN of the switch, so it is unsuitable as management VLAN, or rather, you can use 1 for management, but then you better disable this functionality. The switch can be run with VLAN entirely off, or VLAN on, in which case the switch always uses 1 as the default VLAN. You cannot disable VLAN 1 in that situation, so if you used it for management, that would be rather unsafe. Better to handle VLAN 1 for management as no management VLAN at all. But one could also say only 0 is management VLAN off, and assume users known that 1 would be unsafe.

On the one hand, I say yes, but on the other hand, I'm not so sure. What if I set my internet provider to VLAN 300 and my local network to VLAN 1? Then I would like to be able to access management only on VLAN 1.

In this setup, I have to choose either a different VLAN for my LAN or accept that other VLANs can also access management.

I also think we want to apply port filters so that management can only be accessed via certain ports on the switch. This could possibly be done later via the basic firewall rules.

@logicog
Copy link
Owner Author

logicog commented Jan 29, 2026

On the one hand, I say yes, but on the other hand, I'm not so sure. What if I set my internet provider to VLAN 300 and my local network to VLAN 1? Then I would like to be able to access management only on VLAN 1.

I was not so sure about this either. I will change the code to allow VLAN 1 as management vlan.

@logicog
Add support for management vlan
9d4eef2 
This adds support for the verification of a mangement vlan.
When enabled, then the switch's CPU will not listen to any packets
that are not tagged with the respective VLAN tag.
On the command line this is enabled by setting:
> vlan <vlan> mgmt

Setting the vlan ID of the management VLAN to 0 or 1 disables
the mangement VLAN function.
@logicog
Copy link
Owner Author

logicog commented Jan 29, 2026

I changed the management vlan logic as suggested.

I also think we want to apply port filters so that management can only be accessed via certain ports on the switch. This could possibly be done later via the basic firewall rules.

I also thought about that. In principle with the pvid solution that is given in the example, we have a port filter. For additional security, one would additionally need to drop the VLAN from other ports (easy, but disables additional vlans), or filter VLAN 2 (this will need the ACL engine). The simplest solution would have been to use port isolation and only allow the CPU port to talk to the management port, but that also covers the other protocols like DHCP (client/server) or STP, which would no longer work.

The PVID example solution for getting VLAN 2 is the solution that is proposed by most switch vendors when discussing management VLAN setup.

@vDorst
Copy link
Collaborator

vDorst commented Jan 29, 2026

Hmm it don't like typos.

> vlan 1 mgmr
mgmr255.255.0�e�m�|�vI@<

vlan_create called
vlan: 0x0001, members: 0x0200, tagged: 0x0200
vlan_create done 
vlan_ptr 0x0024:>001mgmr<

> vlan 1 mgmt
Management VLAN set to 0x0001

> vlan 1 mgt
mgt255.255.0�e�o�|�v    @(��I�d��6��������s�8~�a�ױ��}�+�~��i���%��Ӻ��ʅ�/<

vlan_create called
vlan: 0x0001, members: 0x0200, tagged: 0x0200
vlan_create done 
vlan_ptr 0x005e:>001mgt<

@logicog
Copy link
Owner Author

logicog commented Jan 29, 2026

That is the reason why PR #93 exists. The logic for parsing is necessarily simple, because anything complex will eat up OSEG/DSEG. One would need a state machine-based parser for that, possibly with its own parsing language.

@vDorst vDorst merged commit 2a5f1de into main Jan 29, 2026
1 check passed
@vDorst
Copy link
Collaborator

vDorst commented Jan 29, 2026

Great feature thanks.

@logicog logicog deleted the mgmt_vlan branch February 14, 2026 05:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@vDorst vDorst vDorst left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@logicog @vDorst