In article , WS wrote: :I've been experimenting with the VLAN configuration on a Netgear GSM7224 :switch, but am having some issues with it.
:What I am trying to achieve is to transport two physically separate networks :via a single cable between two buildings. To do this I thought I'd create a :separate VLAN for each network (A and B respectively). To do this I did the :following:
:2. On VLAN 2 assigned port 24 (the uplink) to be included, with included :participation, with tagging.
:Someone mentioned that I needed to use trunking mode, presumably on the :uplink port? Are there any other configuration changes I need to make.
Different manufacturers use different terminologies. Setting a port to be tagged for a VLAN is the same thing as setting the port to use trunking. The only difference is it sounds like you could end up with multiple untagged vlans on a port that was also carrying tagged vlans, which would be a mistake. Systems that refer to 'trunk' vs 'access' port usually automatically ensure that this does not happen.
:5. Altered the default VLAN to have port 24 with a status of "include", :participation of "include", and "tagged".
That might be a small configuration mistake. When you are working with 802.1Q vlans, each port usually has an associated Primary VLAN ID (PVID) or 'native VLAN', and packets that are in that VLAN are supposed to go out untagged. In your configuration, the PVID is probably 1, the default VLAN, so on both sides you should probably set VLAN 1 to be untagged.
The PVID or "native VLAN" of a port is the VLAN number that traffic that arrives on that port should be put into for the purposes of redistribution.
:The behavior of the default VLAN works as expected; I can ping :machines/devices on either switch, however I cannot ping any device via VLAN :2.
My guess is that you haven't set port 1 (the one which you want to be in VLAN 2) to have a PVID of 2, so traffic entering that untagged port is being sent into VLAN 1.
As a usage note: some people prefer to configure VLANs so that the default VLAN is -not- carried over any trunks (aka tagged ports). That is, in your situation, they would configure the ports that you want to be in the VLAN A, to use a different VLAN number (e.g., 3) than the default VLAN, and they would set the PVID for all ports in VLAN A to be
3, and they would set the uplink to carry VLANs 2 and 3 but not VLAN 1. This configuration lowers the risk that traffic from unconfigured local ports will be sent across the trunk to the remote end.Some people would further reduce the risk by setting the PVID of the trunks on both sides to be a VLAN that is otherwise unused, especially a VLAN number that is not being carried over the trunk: then there will be no untagged traffic going over the trunk. Not having any untagged traffic going over the trunk is safer in that if you were to connect a device to the other end of the trunk before having configured the VLANs on that device, the untagged traffic coming from the device would be treated as being part of the VLAN marked as being the PVID for the port. In your configuration, for example, you would not be able to tell the difference between traffic that was intended for VLAN 1 (but had its tag stripped because 802.1Q says the PVID goes out untagged) and traffic that was arriving because the port at the other end had not been configured for VLANs at all. If the PVID associated with the uplink port is one that is not used for any real traffic, then although the packets from the unconfigured remote port will enter the local switch, the traffic will be taked as being part of the VLAN indicated by the PVID, and the traffic will not be sent to any local ports because none of them would have that VLAN number.
If you leave the PVID of a trunked port at 1, then you are configuring for 'FAIL-OPEN', like how firedoors should always be openable from inside if the power fails on their electronic locks. If you configure a different otherwise unused VLAN number as the PVID on a trunked port, then you are configuring for 'FAIL-CLOSED', like how railway stoplights should turn red in all directions if the signalling system fails, to prevent the possibility that two trains travelling in opposite directions will enter the same stretch of tracks. Both those situations are examples of configuring to be "FAIL-SAFE", but "safe" can mean different things in different situations. When security is your goal, then you should be configuring for FAIL-CLOSED... but not on data or voice circuits that might be used to carry emergency calls.