This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
I have a GS308T that I am trying to configure and I am having difficulty. I need one physical port (port 1) to connect to my router as the trunk / access port for all traffic to the Internet. I also need three VLANS configured s follows: ports 2 thru 6 as VLAN 10, port 7 as VLAN 20, and port 8 as VLAN 30. For security purposes I want VLAN 20 isolated from the other ports, and port 30 also isolated from all other VLANs. All VLANs need access to port 1 for internet access.
ive tried several times to configure the VLANs but nothing seems to work. If someone has the time and knowledge perhaps you could help me figure out what I am missing.
I am including a few screen shots of what I have configured already.
I think it's more the marketing people telling the engineers what to stick in there.
...
The PVID config option might exist just so they can say it exists, not because they intend it to be used.
Considering the presence (and requirement) to not forget to configure the PVID to send the untgged ingress to the correct VLAN is probably the #1 VLAN switch support issue .... figure.
I need one physical port (port 1) to connect to my router as the trunk / access port for all traffic to the Internet. I also need three VLANS configured s follows: ports 2 thru 6 as VLAN 10, port 7 as VLAN 20, and port 8 as VLAN 30. ... All VLANs need access to port 1 for internet access.
This hasn't much to do with a true 802.1q VLANs where each VLAN makes up it's own network. What you try to achieve here is a so-called asymmetric VLAN config. Netgear does not have this documented (to my knowledge).
For security purposes I want VLAN 20 isolated from the other ports, and port 30 also isolated from all other VLANs.
Just to clarify: This is exactly what an asymmetric VLAN config will not achieve. It's some tricking with the source MAC sending it over different VLANs on the switch internally, but merging together at another port.
That switch has no layer-3 routing ability so you can't do what you want the way you want to do it.
There's a right way and a wrong way to do this IMHO
The wrong way is to put everything into 1 VLAN then use a series of MAC address ACL's on the switch to prevent things from taking to each other but allow them to talk to the Internet port. That's what you are trying to do but you are misunderstanding what a VLAN is and how it works which is why you are failing. I also assume your "Internet connection" is a translated private address from a router.
The right way is to replace your Internet router that is doing the translation with one that can create multiple VLANs as well as do the network address translation between the Internet and multiple internal network subnets. The router would supply all the VLANS on the trunking port to the switch as well as run ACL's that would block the machines on the different VLANs from talking to each other.
OR just replace the switch with one with layer 3 routing capabilities and address translation capabilities but that's really high end $witch feature$ if you get my drift...
That switch has no layer-3 routing ability so you can't do what you want the way you want to do it.
The original proposal (by the OP @Chrispybacon ) implies using an asymmetric VLAN approach. This does not require neither a L3 capable switch nor a multi-VLAN capable environment.
There's a right way and a wrong way to do this IMHO
Well, we're both to much business and strict VLAN architecture with properly isolated networks, dedicated subnets, and much more. There is some room in between. However, Netgear isn't really interested in supporting these kind of set-ups.
The wrong way is to put everything into 1 VLAN then use a series of MAC address ACL's on the switch to prevent things from taking to each other but allow them to talk to the Internet port.
Check it out ... asymmetric VLAN 8-) ... no MAC filtering required.
Right - but since Netgear does not support it, I'm not going to send him down that rabbithole.
He COULD duplicate the functionality - somewhat - with the switch he has. Or he could buy a Catalyst from Cisco and run real RFC5517 PVLANs.
I've dealt with this sort of thing before with large DSL deployments. It is NOT simple. Troubleshooting is a real itch-bay since simple things like sending a ping you don't know if it's being blocked by a filter or the device just isn't responding. It's justified by the scenario outlined by Cisco in RFC5517 where you are dealing with extremely scarce public IP numbering and you must use every last IP. It's NOT justified by a collection of $50 devices in a home to satisfy someone's particularly paranoid tinfoil hatter scenario where everything is privately numbered and because it IS privately numbered you don't have to go down the "asymmectric VLAN" rabbithole because you can waste enormous amounts of private IP addressing and do it right.
All he needs is a convenient Linux box - heck he could use a Raspberri Pi - to create a REAL router, and he can define as many "traditional" private subnets as he wants on as many "traditional" VLANS as he wants, and route between them properly, like normal people without creating a tear-out-your-hair scenario.
There's solutions that belong at the carrier - like PVLANS, aka "asymmectric VLANS" - that need to STAY at the carrier. That's why Netgear isn't interested in supporting this sort of thing, because nobody with 4000 DSL customers needing isolation is going to be spending $1000 on a Netgear switch, they are going to be spending $20,000 on a carrier-grade product from Juniper or Cisco. Unfortuinately what so often happens in networking is people read about the esoteric stuff going on at the carrier level and think "that is so kewel I just gotta have it from my $50 network device I bought at Costco" they don't stop to think WHY things are done that way at the carrier and how much of a PIA they are to the admins working at the carrier.
Trust me if we had done things properly on the Internet in the beginning we would all be running IPv6 and nobody would give a tinker's dam about asymmectric VLANs or PVLANS or any of that. Back in my admin days with those DSL deployments I would have dropped all the layer2 filtering in a hot second if I could have just had a v6 allocation and sliced off /48's for my customers like cheese slices. What we did then was NOT something anyone with a brain would want to duplicate, it is NOT "kewel" by any means.
Right - but since Netgear does not support it, I'm not going to send him down that rabbithole.
Hey I'm with you 8-)
But exactly the (unsupported?) asymmetric VLAN is the (only?) reason for having the crappy PVID config option on almost all Netgear switches. Because without, a port could be configured with only one [U]ntagged VLAN (actually it allows is to configure many), and a simple access port config for VLAN x would be much easier to understand for this customer base.
Somehow I think Netgear forgot about why things are speced and implemented as they are....
I think it's more the marketing people telling the engineers what to stick in there.
Somewhere on the Netgear site (it may be gone, now) I recall years ago reading "layer 3 routing" in a marketing glossy for the ProSafe+ switch series. Of course I dug into it since nobody at the time was making and selling routing switches for under $2000. Well the glossies from Marketing were trumpeting that but the actual user manual for every switch I looked at from the boring engineer types said no such thing.
Another one that irks me is "layer 2 monitoring" claims for switches that have no possible way to display the mac address database inside the switch.
The PVID config option might exist just so they can say it exists, not because they intend it to be used.
Unfortuately Netgear isn't the only company that engages in this. I learned a long long time ago before plunking down any cash to throughly read the user manual and see if the device can actually do what I want it to do instead of what the manufacturer wants me to think it can do. 🙂
I think it's more the marketing people telling the engineers what to stick in there.
...
The PVID config option might exist just so they can say it exists, not because they intend it to be used.
Considering the presence (and requirement) to not forget to configure the PVID to send the untgged ingress to the correct VLAN is probably the #1 VLAN switch support issue .... figure.
