I currently used two GS305e at different locations at home. Between the switches I used a trunc-connection with VLAN 101 (192.168.2.0/24) and VLAN 200 (192.168.10.0/24) on Port 5. Port 5 is set as VLAN-Member 101 (tagged) and 200 (tagged), to prevent untagged traffic on this Ports I also set VLAN 2 only to this Ports (tagged) and PVID also to VLAN 2. All other Ports are untagged on VLAN 101 or VLAN 200.
At this config I can manage both switchs from devices they are connectet to any other port (untagged VLAN 101) at any switch. Now I swaped one of the GS305e to a GS308e, I setting up the same VLAN/Port configuration, but I can manage the GS308e only from local connected devices now.
Some tests later it seems that incomming management traffic on tagged Port, from GS308e respond as untagged traffic. If I set the PVID on correspondending Port at GS305e from 2 to 101, its allows manage the GS308e over devices they connected to GS305e.
This behavior cannot be correct.
The switchs are config with static IP (192.168.2.132 ; .133).
Sascha
Model: GS308E|8 Port Gigabit Ethernet Smart Managed Plus Switch
I have encountered the same problem with the GS308E switch. There are two major issues with the web management interface's traffic:
Outgoing web management traffic is broadcast on all ports regardless of the incoming port (wow!).
Outgoing web management traffic is always untagged.
Having outgoing web management traffic on all ports is a major security breach and must be addressed asap!
The following is the traffic captured by mirroring one tagged port (a trunk) to another tagged port (a monitor) while the web management console is being accessed. 192.168.1.1 is the router, 192.168.1.11 is the GS308E switch. Note how all outgoing traffic (from the GS308E's perspective) is untagged while incoming traffic from VLAN 1 is tagged. Currently, I am forced to use PVID=1 on the trunk port on the router in order to be able to access the management interface.
Model: GS308E|8 Port Gigabit Ethernet Smart Managed Plus Switch
My case in processing since 4 weeks. A lot of posts later the supporter has not yet managed to configure the switches as I specified to reproduce the problem. 🙄
"We have received an update from the Engineering team, who could reproduce the issue and find the root cause. The root cause is GS308E chip can't reply to ARP with the tag however, GS305E can send the reply to ARP with the tag."
"It is a Hardware limitation. It cannot be fixed by software updates." ☹️
Workarround should be use PVID (@GS305E) to retagging packets from GS308E, but it's no solution for direct connections from other hardware with 802.1Q.
That is beyond ridiculous... So they're saying that the chip supports tagging all other traffic, but is unable to tag its own? And what about the second issue when the replies are broadcast on all ports? Is it another "hardware limitation"? I think I'm done with Netgear...
These re indeed chipset limitations, several vendors offer the almost exact same devices and the similar variance, some direct chipset related, some related to the earlier mentioned microcontroller implementation.
If you expect strict managed VLAN, buy switches supporting this.
@schumaku I guess this is what happens when millennials are in charge of writing firmware. And you once again avoided addressing the second issue - broadcasting management traffic on all ports - which is much more severe than the first one.
This could even be microcode issue on that switch chip. The firmware people (which just set some bits to the behavior of the switch like on an embedded device don't have control over it. To what I can see, the switch code is not a loaded module, probably burned-in with the manufacturing.
Please understand I'm not Netgear, just yet another user, and are not very keen buying hardware (this GS3x series if for certain specific sales channels) just for reproducing each and every potential nicely reported issue.
This could even be microcode issue on that switch chip. The firmware people (which just set some bits to the behavior of the switch like on an embedded device don't have control over it. To what I can see, the switch code is not a loaded module, probably burned-in with the manufacturing.
It's hard to make any assumptions without knowing what exact switch chip is used in the GS308E, but according to this video https://youtu.be/HuQ3iv4iLbw?t=322 it's clearly seen that the GS108 (a simple unmanaged switch) uses Broadcom BCM53118. According to the chip's description (https://html.alldatasheet.com/html-pdf/1074559/BOARDCOM/BCM53118/448/1/BCM53118.html) this switch chip is highly versatile, supports VLAN tagging and has one GMII/RGMII interface along with 10/100/1000 MAC for connection with a CPU or a wireless/DLS/cable router chip. That interface is obviously not used in the GS108 due to its unmanaged nature. Thinking that the chip can't tag/untag traffic received/sent on that internal interface renders it absolutely useless for what it's designed for.
Simple logic leads me to a conclusion that something clearly more advanced like the GS308E uses at least something similar as a switch controller partly because the GS108 does not even use managed capabilities of its own chip. It's hard to believe that the GS308E uses an inferior chip provided it needs a CPU for management tasks.
Simple logic leads me to a conclusion that something clearly more advanced like the GS308E uses at least something similar as a switch controller partly because the GS108 does not even use managed capabilities of its own chip.
The GS108 is the typical design example for a design for non-managed switches. Newer unmanaged switches still have got the addition of a controller adapted to the GMII/RGMII to add some features desired, similar to the GS308E. It happened to more than one vendor that this added code was faulty, so complete series of unmanaged switches showed problems on operations.
Scratch the simple logic. These switches are a their heart unmanaged switches, built on non-managed switch cores.
Don't want to dispute if the add on is an additional microcontroller or a CPU, the boundary is unsharp nowadays,. And the chip added does take care of various tasks the simple switch chip can't do on its own, and for several functions it requires the full access to the data stream. This processor does not just handle the tiny IP stack, the web server (on very early E models the NSDP protocol), it also takes care of IGMP snooping for example. And yes that chip is linked to the GMII/RGMII. And because there is no VLAN tagging support on the switch chip, and the tiny IP stack can't handle the VLAN tagging, can't handle tls, but it serves both the switch runtime and the management functions like http, sftp, nsdp.
Certain larger GSxxxE and XSxxxE type models are indeed built on managed cores - there Netgear has made the management VLAN capability available. Beyond, the admin feature set was kept intentionally in line to the configurable, but unmanaged functionality.
This is all I can say, everything based on observations done while Beta testing some of these Plus switches over the years.
@waxar When reading into the release notes, you might understand my non-reverse-engineering design info can't be to much off:
===
To support the device UI, all HTTP packets are forwarded to the embedded CPU. With Flow Control enabled, throughput can be affected if the rate is higher than the CPU can handle. ...
IGMP dynamic router port does not timeout exactly at 300 seconds. It could be anywhere from 300 to 600 seconds. IGMP host timeout is not exactly 260 seconds. It could be anywhere from 260 to 520 seconds.
