NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Private VLANs on the GC728X and GC752X Switches
Hello Netgear Gurus, I am trying to understand how the Private VLANs on the GC728X and GC752X switches operate. I have a Terminal Server that only negotiates to 100 Mbps Full. So we constantly ...
akio63 wrote:Okay you gave me two options.
Please keep in mind I'm just another community member, not a Netgear support or the like.
I would prefer to go to the Security > Traffic Control > Private VLAN > Private Vlan Port Mode Configuration config. Because this is what the documentation does request. At that point again, I would expect a different config pushed in place than a classic dot1q
This compares well to similar configurations on different switch models to support the asymmetrical VLAN configurations. And this is again a feature not supported on general dot1q configs. And this is in my understanding not a generic dot1q config - so thus I was talking about that before
Afraid again, have no test horse available. The related answers could come from Netgear switch engineering (via support), some insight could come from comparing the configs generated by the two variants.
-Kurt
Still curious why these devices (MAC address) are participating on that many VLANs. Are these many other VLANs routed combining many different subnets?
akio63 wrote:
How can I prevent that traffic from reaching the Terminal Server?
Afraid, I can't understand this VLAN design on googles...
akio63 wrote:
Neither the source nor the destination is participating in VLAN 159 so it shouldn't reach the Terminal Server which has a PVID of 159. Or do I not understand the significance of the PVID? Do I need to create a new VLAN for sim1, say VLAN 800, put sim1 into VLAN 800 and remove VLAN 111 from the Terminal Server's Participating VLANs, as well as add VLAN 800 to it?
So there must be other reasons why this VLAN does show up on the terminal server port.
The PVID does define the VLAN incoming untagged frames on a port are sent to.
akio63 wrote:
I tried using MAC address filtering to filter out traffic other than VLAN 111, MAC address a4:bb:6d:5e:0e:35 from Switch R1SW2 Port g15 which is the Terminal Server port, however the switch would not let me do that because, I assume, outbound MAC address filtering is restricted to multicast traffic only.
As above - no idea on what magic you expect VLAN to be workable. In the typical use case, your define a VLAN xyz, configure for example two ports untagged for this VLAN xyz (and no other VLAN associations) and PVID xyz so all untagged frames on these two ports go to the VLAN xyz.
Are you trying to configure some asymmetric VLAN environment here?
In a clean VLAN environment, you have access ports configured to be in one VLAN xyz. The other simple config is a trunk connection, where you can carry more than one VLAN on a port, either all tagged, one untagged, and two or more untagged. Each VLAN does make up it's own network (and handle dedicated IP subnet each. Some special usages exist where you bring multiple networks to one port, e.g. a workstation untagged, and an IP phone tagged.
Okay if you want to know (and have an hour to spare), I can explain the need for all the extra VLANs.
Let's take for example a simple port. Switch R1SW2 port g15 is a Terminal Server so it's PVID is 159. We want it to talk to a device on VLAN 111 so we added VLAN 111 to the Participating VLANs. We don't want everything on VLAN 111 to talk to the Terminal Server so we created VLAN 159 for the Terminal Servers and added VLAN 159 as a Participating VLANs for those ports that we do want to have connectivity to the Terminal Servers.
Switch Port PVID Participating VLANs
R1SW2 g15 159 111,159
We have the following VLANs defined:
VLAN Description Purpose
111 General Switch Traffic for Rig 1 All devices on Rig 1 that require connectivity to each other
159 Terminal Servers Terminal Servers that provide telnet sessions to users
Now for a more advanced port. Switch R1SW1 port g14 is srv1. It needs to talk to a lot of devices. So it is in PVID 111 and this gives it access to many other devices. We also want it to talk to the Terminal Servers as srv1 is a gateway into the Rig. Users ssh to srv1 then ssh to the Terminal Servers to reach various other devices in the Rig. So we want srv1 to talk to the Terminal Servers. We want the Terminal Servers to talk back to srv1.
But we don't want the Terminal Servers to be able to talk to anyone else. Some of those systems are simulation servers and backup simulation servers. And seeing their own traffic coming from a different IP address would mess it up and we could have corrupted data. So we added VLAN 159 to the Participating VLANs for Switch R1SW1 port g14 to allow srv1 to talk to the Terminal Servers. Server srv1 needs connectivity to other devices in other VLANs so we added those VLANs to the Participating VLANs as well to Switch R1SW1 port g14.
Switch Port PVID Participating VLANs
R1SW1 g14 111 111,112,114,116,117,120,156,158,159,161,163,164,501,505,1111,2111
I still wonder if this could be performed better using Private VLANs.
So this is the way it was explained to me. Traffic from srv1 comes into R1SW1 on port g14 and becomes tagged with VLAN 111. It has an IP address of 10.116.80.236/8. That traffic destined for the Terminal Server at IP address 10.43.79.180/8 is sent locally. The server srv1 should send an ARP request for 10.43.79.180. The Terminal Server will reply with it's MAC address. The switch R1SW1 will receive the packets from srv1 destined to the Terminal Server, check it's Address Table and see that the destination MAC address is on the port with the trunk between R1SW1 and R1SW2 and sends it out that port.
Now R1SW2 has the packet. The packet still has the VLAN tag 111. R1SW2 checks it's Address Table and sees the destination MAC address is on port g15. It also sees that VLAN 111 is allowed on port g15 so it sends it out that port to the Terminal Server.
Is this not correct?
Also, you stated:
schumaku wrote:In the typical use case, your define a VLAN xyz, configure for example two ports untagged for this VLAN xyz (and no other VLAN associations) and PVID xyz so all untagged frames on these two ports go to the VLAN xyz.
So I believe that I do not understand the concepts of Tagged VLAN, Untagged VLAN and PVID.
PVID defines what VLAN tag will be placed on all incoming packets that are not tagged on that port..
Tagged means all packets transmitted for this VLAN will be tagged. For instance a trunk port.
Untagged means all packets transmitted for this VLAN will be untagged. For instance an access port.
Does the VLAN membership not dictate what VLAN traffic is allowed or dropped on an interface?
Thank you.
All right ... to start with, pure curiosity: Are these VLANs configured the classic 802.1q way, or using the Security > Traffic Control > Private VLAN > Private Vlan Port Mode Configuration? Enough experienced on Cisco NX-OS L2 configs, but no Netgear CX7xx playground available.
Okay you gave me two options.
Option 1
Classic 802.1q way
Option 2
Using the Security > Traffic Control > Private VLAN > Private Vlan Port Mode Configuration
Since I did not use the Security > Traffic Control method, I must have done it the Classic 802.1q way. However the Classic 802.1q way for me is:
config t
int fa0/1
switchport access vlan 51
But in this case that is neither here nor there.
So my answer is Classic 802.1q way. Hmmm wait, Regis, can I get a Lifeline?
Thanks
akio63 wrote:Okay you gave me two options.
Please keep in mind I'm just another community member, not a Netgear support or the like.
I would prefer to go to the Security > Traffic Control > Private VLAN > Private Vlan Port Mode Configuration config. Because this is what the documentation does request. At that point again, I would expect a different config pushed in place than a classic dot1q
This compares well to similar configurations on different switch models to support the asymmetrical VLAN configurations. And this is again a feature not supported on general dot1q configs. And this is in my understanding not a generic dot1q config - so thus I was talking about that before
Afraid again, have no test horse available. The related answers could come from Netgear switch engineering (via support), some insight could come from comparing the configs generated by the two variants.
-Kurt
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
