Setting up a Cisco Trunk Uplink to a GS105PE - Just configs - and How to
I purchased several GS105PE switches to utilize where I have no AC power, for several devices. The catch is I have to 802.1Q trunk vlans to this switch. I can configure a Cisco switch port to power it, and send tagged 802.1Q traffic to the uplink port (port 5). However, the help documents dictate configuring this puppy over a web interface. When you try and configure the uplink port, it breaks your current connection to the management IP address. HOW do you get around this? There is definetly a trick to both accessing the device (over IP/Web), AND... changing the uplink config. OK, that's the need - NetGear Tech support - GO!
However, the help documents dictate configuring this puppy over a web interface. When you try and configure the uplink port, it breaks your current connection to the management IP address.
Not very different from whatever expensive different brand switch while doing in-band config, regardless of whatever access protocol you are using, isn't it?
Unfortunately, you don't tell us much about the uplink config on the other side (VLANs, IP subnet, DHCP), and on how you initially access it. These switches are very simple configurable devices. As such, we must understand the limitations of the microcontroller serving various purposes.
First, be aware the microcontroller does access all VLANs concurrently, means there is no management VLAN, the switches can pick up an IP config from any VLAN DHCP address. Second, due to the microcontroller simplicity IP stack, the DHCP server can time-out and fall back to the default IP - it will not retry even if the device is set to be a DHCP client.
This should give you an idea what might happen while doing your config.
The most simple way is keep the VLAN you intend to use on the uplink port untagged, initial access the switch on it's default IP or the DHCP assigned IP, then set the IP to a local static config. In case it tends to pick an IP config from a different upstream VLAN DHCP already (the NETGEAR Switch Discovery Tool (NSDT) is your friend), disable these for a moment (and power reboot due to the DHCP client shortcoming). Now configure the ports, including the uplink as required.
To avoid another small hurdle, don't forget about the need for setting the PVID to the single VLAN ID you run [U]ntgged to the device. The PVID does define the VLAN ID where untagged frames flowing into the switch port will be assigned to.
It's nothing difficult, it isn't overly complex - when keeping these points in mind.
There is just one issue. The IP I gave it which is on VLAN 11 takes 6 to 7 times longer than the other VLANs. Ports 3, 4, 5 connect to devices. I'm using this like an edge switch. So I average about 0.25ms from my core switch to the devices on port 3, 4, and 5 respectively. But I'm at about 2ms from my core switch to the Netgear switch. It makes no sense, I probably have something messed up somewhere but not sure where.
Regardless as the edge devices have low latency and everything is just fine, no packet loss, loops or drops, I'm good as I got what I wanted. A Cisco trunk w/ 802.1q tagging and a native working.
I think VLAN 1 has to exist but as I had been fiddling with this for hours I didn't want to risk removing it entirely.
Port 1 is my uplink.
Port 3, 4, 5 are links, each to different VLANs.
As using VLAN 1 is a no-no because it's usually the default everywhere I will give an example of mysetup using 11, 12, 13, and 14.
Think again from where this theoretical logic is coming from: Cisco had a big problem with their old switch design and the native VLAN.
These switches don't care on over which VLAN you bring the untagged frames to the uC doing the ICMP Multicast and the simple IP stack with the Web UI...
There is just one issue. The IP I gave it which is on VLAN 11 takes 6 to 7 times longer than the other VLANs. Ports 3, 4, 5 connect to devices. I'm using this like an edge switch. So I average about 0.25ms from my core switch to the devices on port 3, 4, and 5 respectively. But I'm at about 2ms from my core switch to the Netgear switch. It makes no sense, I probably have something messed up somewhere but not sure where.
...as long as the frames are coming in with what can be interpreted as an IPv4 address. What does not work (or could cause some massive delays) is the attempt on bringing this management IP address over a trunked connection.
Can't see anything wrong with your config - except that you still fail to understand on how these Plus switches (at least those not implemented on a managed switch core, there are some...), their very simple IP stack is implemented.
Regardless as the edge devices have low latency and everything is just fine, no packet loss, loops or drops, I'm good as I got what I wanted. A Cisco trunk w/ 802.1q tagging and a native working.
Yes, this is what an unmanaged switch - this is what it is - (configured to some dot1q settings) can do nicely.
Feel free to remove the VLAN 1 from your unspecified Plus switch - as long as this is a classic Plus switch, not e.g. one of the more decent models with a managed core (where there is a config option for the management VLAN!).
Curious what you are "measuring" and what makes you think there must be some delay? The time to/from the uC where some famous engineers managed to implement a simple IP stack and ICMP Multicast handler for controlling the ports related to Multicast? This tiny uC does listen to -any- traffic flowing over this -unmanaged- switch most likely? And yes, the more traffic there is, the higher will the delay be. This is in no aspect something negative to these switches: It does not have an impact on the switching capabilities.
