I got a few older ZyXEL GS-1900-48 and I very happily replaced ZyXEL OS by the fantastic OpenWrt ;-).
I want to configure all ZyXEL switches with one port for administration only (port 48) with and SSH / HTTP access and the other ports just for switching. In other words the switch IP won't be accessible via ports 1-47 and to configure it I'll need to physically plug cable into port 48 (or via serial).
I started building this configuration by deleting default interface, changing device switch to switch only ports 1-8 (just for a test) and creating new interface for lan48 with static IP. I quickly realized that I can SSH / HTTP via port 48 but that switching ports don't work.
After a few trials and errors I realized that when I create an interface with Protocol: Unmanaged then the switching ports 1-8 start working as a switch.
Should I configure it like this? With option proto 'none' interface?
Thank you very much.
Joe
Example that works without VLANs:
...
config device 'switch'
option name 'switch'
option type 'bridge'
option macaddr 'ab:cd:ef:00:11:22'
list ports 'lan01'
list ports 'lan02'
list ports 'lan03'
list ports 'lan04'
list ports 'lan05'
list ports 'lan06'
list ports 'lan07'
list ports 'lan08'
config interface 'mymng'
option proto 'static'
option device 'lan48'
option ipaddr '10.0.0.1'
option netmask '255.255.255.0'
config interface 'myswitch'
option proto 'none'
option device 'switch'
...
Example that works with VLANs:
...
config device 'switch'
option name 'switch'
option type 'bridge'
option macaddr 'ab:cd:ef:00:11:22'
list ports 'lan01'
list ports 'lan02'
list ports 'lan03'
list ports 'lan04'
list ports 'lan05'
list ports 'lan06'
list ports 'lan07'
list ports 'lan08'
config bridge-vlan
option device 'switch'
option vlan '100'
list ports 'lan01:t'
list ports 'lan02:t'
config bridge-vlan
option device 'switch'
option vlan '101'
list ports 'lan01:t'
list ports 'lan02:t'
config bridge-vlan
option device 'switch'
option vlan '102'
list ports 'lan01:t'
list ports 'lan02:t'
list ports 'lan03'
list ports 'lan04'
list ports 'lan05'
config bridge-vlan
option device 'switch'
option vlan '103'
list ports 'lan01:t'
list ports 'lan02:t'
list ports 'lan06'
list ports 'lan07'
list ports 'lan08'
config bridge-vlan
option device 'switch'
option vlan '104'
list ports 'lan01:t'
list ports 'lan02:t'
config bridge-vlan
option device 'switch'
option vlan '105'
list ports 'lan01:t'
list ports 'lan02:t'
config interface 'mymng'
option proto 'static'
option device 'lan48'
option ipaddr '10.0.0.1'
option netmask '255.255.255.0'
config interface 'myswitch'
option proto 'none'
option device 'switch'
...
Yes, this is expected and fine. Reason is the way netifd works internally, it requires a "user" (a logical interface) for a "device" to actually bring it up.
I have a similar setup... I have a "Mgmt-VLAN" using DHCP/DHCPv6 and a pseudo safety net providing only IPv6 Link Local. I have a DGS-1210-10
Incomplete config, just for illustrating:
config device
option name 'switch'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
list ports 'lan5'
list ports 'lan6'
list ports 'lan7'
list ports 'lan8'
list ports 'lan9'
list ports 'lan10'
option macaddr '08:5a:11:a2:7f:10'
# My regular Mgmt Interface (but this is tagged, as I'm using only
# one uplink port to my router, and every vlan is tagged on that link...
config bridge-vlan
option device 'switch'
option vlan '16'
list ports 'lan8:t'
config interface 'vlan16'
option device 'switch.16'
option proto 'dhcp'
config interface 'vlan16_v6'
option device 'switch.16'
option proto 'dhcpv6'
# And my pseudo out of band / safety net direct access link,
# IPv6 link local only
config bridge-vlan
option device 'switch'
option vlan '4094'
list ports 'lan1'
config interface 'vlan4094'
option device 'switch.4094'
option proto 'static'
option ip6class 'local'
option ip6assign '64'
root@sw1:~# ip addr show switch.16
26: switch.16@switch: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 08:5a:11:a2:7f:10 brd ff:ff:ff:ff:ff:ff
inet 192.168.16.180/24 brd 192.168.16.255 scope global switch.16
valid_lft forever preferred_lft forever
inet6 fde6:a09a:b373:10:a5a:11ff:fea2:7f10/64 scope global dynamic noprefixroute
valid_lft 43113sec preferred_lft 43113sec
inet6 2003:XXXX10:a5a:11ff:fea2:7f10/64 scope global dynamic noprefixroute
valid_lft 13884sec preferred_lft 1284sec
inet6 2003:XXXX10::d1f9/128 scope global dynamic noprefixroute
valid_lft 27045sec preferred_lft 27045sec
inet6 fde6:a09a:b373:10::d1f9/128 scope global dynamic noprefixroute
valid_lft 27045sec preferred_lft 27045sec
inet6 fe80::a5a:11ff:fea2:7f10/64 scope link
valid_lft forever preferred_lft forever
root@sw1:~# ip addr show lan1
3: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master switch state LOWERLAYERDOWN group default qlen 1000
link/ether 08:5a:11:a2:7f:10 brd ff:ff:ff:ff:ff:ff
root@sw1:~# ip addr show switch.4094
34: switch.4094@switch: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 08:5a:11:a2:7f:10 brd ff:ff:ff:ff:ff:ff
inet6 fe80::a5a:11ff:fea2:7f10/64 scope link
valid_lft forever preferred_lft forever
Thank you @_bernd , I can see in your configuration that you don't have an interface with protocol "none" (Unmanaged) so as Jow mentioned it makes sense that the netfid user is in your case an interface on a VLAN that has protocol DHCP / static.
Great idea since link-local is not routable. I was actually thinking about the same after I get comfortable with OpenWrt on a switch. But I was thinking about using unique local (fd00::/8) with a known "static" IPv6.
Thank you @_bernd for posting the config. It makes a lot of sense and I'm going to test if there is a functional difference between proto 'none' on the whole bridge and proto 'none' on each VLAN.
I also want to try untick the [x] Local checkbox in LUCI device configuration and see what is going to happen in the textual configuration.
My assumption is that proto 'none' on the whole bridge and [ ] Local is the simplest secure configuration for L2 switch.
That means that untagged port accepts tagged packets with the correct tag. In my opinion that's wrong but it's not a security problem so I guess it's OK.
I'm not 100% sure, but I assume it "works" because there is no other tag (neither tagged or untagged) assigned to lan3 of that second switch. I have never considered this use case or setup
/* I've only once seen a setup where the dudes had a cable (on the same switch) from one port to an other to build a really poor mens "vlan translation" */
Can you explain to me what option local is doing?
I don't understand what the wiki wants say to me
https://openwrt.org/docs/guide-user/network/dsa/converting-to-dsa
Local option will automatically assign the specified VLAN ID to the bridge interface and create a VLAN interface of the bridge interface. So the router can use the VLAN interface to be involved in that VLAN.
If you don't want the router to be involved in that VLAN, you can disable this option and run service network restart for this change to take effect.
PS: So now you are happy and you have a working setup?
Thank you for asking. Testing setup is working, I'll see what is going to happen when I add more VLANs and try enabling STP
My understanding is that if it isn't local (option local 0) then it is not usable within the OS. I can see in LUCI that with option local 0 I can't use those VLANs to setup interfaces:
Is this just an OpenWrt configuration "thing" or does it mean that I can't use those VLANs inside the OS (for example with ip command)? I don't know... If those VLANs are really unusable then this is a more secure setup. If it's just an OpenWrt configuration "thing" then it doesn't matter...
Yes - I tried it and it has no effect. My understanding is that PVID (lan3:u*) has no effect for a port with single untagged VLAN. PVID would have effect if I had (lan3) on one VLAN and ((lan3:u*) on other VLAN. But I don't see too many use cases for that...
Yes. Looking at https://git.openwrt.org/?p=project/netifd.git;a=blob;f=bridge.c;hb=HEAD#l230 it seems the difference is whether netifd will add the vlan to the bridge itself in addition to the ports. Which is required if you want to use it for routing or anythng else in the OS. Otherwise it will only be switched within the bridge.
lan8 is a trunk; all other ports are access ports; (if and how lan9 and lan10 are usable I don't know. on the vendor firmware i think the user needs to toggle and choose between lan7 or lan9 and between lan8 and lan10.
PS: I don't quiet get the "issue" in the linked github issue. Like I also miss the info: Are both devices on the same subnet? Different subnets? But if I can help somehow, I can give it a try...
Re: issue: Yes, all devices are on the same subnet, there is no router there. Of course I don't plan to have devices on the same subnet in different VLANs - it's just for testing L2 on the switch.
My ZyXEL (and you can test your D-Link DGS-1210-10) works OK for a single switch setup. Devices on access ports in different VLANs cannot speak to each other. But when I connect two switches via trunk, the VLAN isolation breaks and devices on VLAN 102 on my first switch can speak to devices on VLAN 103 on the second switch.
I'm happy that I found this problem before I moved the switches into "production" (my house) since what is the point of having router+firewall when VLANing doesn't work.
Are the packets properly tagged on the trunk? You should be able to test that by simply connect the PC to the tagged port and snoop with wireshark or similar. We should find out whether this is an egress or ingress issue.
I'm not seeing this on my switches. Haven't actually tried to connect to of them directly, but I do use them to split VLAN trunks into both untagged access ports and trunk ports. I'm pretty sure I would notice any such failures immediately. But my switches are all RTL8380 based, like @_bernd 's DGS-1210-10. So I guess this could related to the RTL839x.
Another thought is that you could somehow be software switching the packets, conneting all VLANs together in the software bridge. Don't know how. Just a bad feeling I got from the
[230498.762516] rtl838x-eth 1b00a300.ethernet eth0: Ring contention: r: 0, last a40002dc, cur a4000400
error you mentioned in the github issue. AFAIK, that shouldn't happen unless you send "a lot" of traffic to the CPU port. Not necessarily that much relative to what the switch ports can handle, but way more than normal switch management traffic.
The last time I saw something similar was when we had a bug causing flooding of everything to all ports.
