Netgear GSM72224 VLAN config
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
||||||||||||||||
|
Posted by WS on November 8, 2004, 12:49 pm
Please log in for more thread options 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: 1. Created a second VLAN (2) on the switch, and assigned port 1 to a status of "include", with "included" participation, and no tagging. 2. On VLAN 2 assigned port 24 (the uplink) to be included, with included participation, with tagging. 3. All other ports on VLAN 2 are set to a status of "exclude", participation of "exclude", and no tagging. 4. Altered the default VLAN to have port 1 with a status of "exclude", participation of "exclude", and "untagged". 5. Altered the default VLAN to have port 24 with a status of "include", participation of "include", and "tagged". 6. All other ports on the default VLAN are set to a status of "include", participation of "include", and no tagging. 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. Someone mentioned that I needed to use trunking mode, presumably on the uplink port? Are there any other configuration changes I need to make. Thanks in advance! | ||||||||||||||||
|
Posted by Walter Roberson on November 8, 2004, 2:02 am
Please log in for more thread options :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. -- Look out, there are llamas! | ||||||||||||||||
|
Posted by WS on November 15, 2004, 1:13 pm
Please log in for more thread options This REALLY helped.
FYI (and everyone else's), the trick was (as you said below) to ensure that the uplink ports were tagged, while the vlan member ports remained untagged. I'd also suggest that people assign two ports on a single switch as members of a new vlan, and get those working first before attempting to get vlans BETWEEN switches working. | ||||||||||||||||
| Similar Threads | Posted |
| Netgear GSM72224 VLAN config | November 8, 2004, 12:49 pm |
| What is VLAN, how it is used?. I have 4 PC's on one LAN connectd to router, how can I apply VLAN concept here?. | February 4, 2005, 1:16 am |
| Netgear FS526T | January 25, 2005, 8:48 pm |
| NetGear WGU624 | March 16, 2006, 6:37 pm |
| Which router for vlan - vlan to internet | September 7, 2004, 2:37 pm |
| Netgear WGT624 V2 Router | July 7, 2004, 2:28 pm |
| Voyager 205 and Netgear FS605 | May 6, 2005, 6:00 pm |
| Dead Netgear PE-102s | March 29, 2006, 6:09 pm |
| Netgear and Cisco Trunk | May 3, 2007, 4:04 am |
| Re: Netgear powerline extenders | May 12, 2008, 4:25 pm |
| Netgear router setup problem | January 7, 2006, 6:56 pm |
| Netgear router setup problem | January 7, 2006, 6:56 pm |
| Allied Telesyn vs Cisco vs netgear | March 24, 2006, 4:02 pm |
| Intra-switch VLANs Netgear | September 6, 2006, 1:46 pm |
| Third Party SFPs in Netgear Switches | September 24, 2006, 2:27 pm |
> :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.
> --
> Look out, there are llamas!