Better accommodation for IoT classes using Install VLAN #782
Comments
|
Owen DeLong wrote:
## Description
Currently, we have applied a workaround for IoT (and other trainings) which require wired devices on the same broadcast domain as wireless devices by dedicating 8 ports on each of the cfRoom switches as untagged cfSCALE-FAST.
This is a security risk as well as an improper use of this global WiFi VLAN.
I propose instead, that we add the cfInstall VLAN as an additional "SCALE-TRAINING" SSID on the 2.4Ghz radios only.
ideally this would only be in the room that's doing the training. (first use
case for our netmap parameter? although I think it only does wired currently)
This would give us the ability to impose additional limitations on that VLAN (e.g. not allowing it to communicate with other conference VLANs, limitations on its internet access, etc.
yes, we need to do more of this sort of thing
I'd also like to see us use semi-smart tabletop switches for all of the
training labs that would use these ports. In this way, the ports could be
tagged on the cfRoom switches and converted to untagged by the tabletop
switches. This would prevent casual use of the ports in non-training rooms by
conference attendees.
sounds good, there are a lot of pretty cheap 8 and 16 port switches out there
that are low power and small (much better for the tables than using enterprise
grade switches, even if the price delta isn't that much)
David Lang
… These are a couple of possible solutions. I'm open to additional suggestions or better ideas.
## Acceptance Criteria
No further untagged ports open on switches in public accessible areas
Better security audit and control of the Install VLAN
Implementation of the above across all cfRoom switches.
|
|
You'll need to explain the "net map" parameter to me, first I'm hearing of it. Cheap 8 and 16 port unmanaged switches wouldn't quite cut it in this role. We need at least something that understands VLANs and 802.1q. |
|
All in the ~$70-110 price range. At least one option has a lifetime warranty, which could be useful in our environment. |
|
Owen DeLong wrote:
You'll need to explain the "net map" parameter to me, first I'm hearing of it.
we pass a dhcp parameter to the APs that lets them reconfigure their network
config amoung one of several pre-installed versions. (load multiple network
configs with basename.# and the # that is passed via dhcp gets copied on top of
the real file and the AP reboots)
not as flexible as feeding the entire config, but a little more error resistant
as all options can be pre-tested, and there is a default if there isn't one
available.
I think it only does the wired config right now, but it could be tweaked
slightly to cover wireless as well.
Cheap 8 and 16 port unmanaged switches wouldn't quite cut it in this role. We need at least something that understands VLANs and 802.1q.
this isn't as cheap as some (~$50), but that's because it includes PoE
https://www.amazon.com/gp/product/B07PY93BL2/
some cheap ones that I haven't used (as cheap as $13 for a 5 port one)
https://www.amazon.com/STEAMEMO-Easy-Managed-Ethernet-Splitter/dp/B0DG2N8DWH
https://www.amazon.com/Gigabit-Managed-Snooping-Aggregation-GS1200-5/dp/B07BNVTZ3S
These are basically using the same switch chips that are used in APs, but
managed with their proprietary web GUI.
David Lang
|
|
Since a 5 port switch is effectively a 4 port (plus uplink) switch, the $/port is actually about the same as the 16 port switches I was proposing in the $70 range. $70/15+ usable = $4.67/port while $13/4 usable = $3.25/port. Further, I proposed switches from well established known brands vs. random unknowns (The only recognized brand in your list is the $50 TP-Link which is $7.05/port (based on 7 usable ports) so more expensive than the options I proposed). Further, I think managing that many 5 port switches plus their attendant wall warts, etc. would be a much bigger pain than a smaller number of 16 port switches. I'm willing to go with the group thinking on this, but I think the above considerations are worth factoring. |
|
Owen DeLong wrote:
Since a 5 port switch is effectively a 4 port (plus uplink) switch, the $/port is actually about the same as the 16 port switches I was proposing in the $70 range. $70/15+ usable = $4.67/port while $13/4 usable = $3.25/port. Further, I proposed switches from well established known brands vs. random unknowns (The only recognized brand in your list is the $50 TP-Link which is $7.05/port so more expensive than the options I proposed).
Further, I think managing that many 5 port switches plus their attendant wall warts, etc. would be a much bigger pain than a smaller number of 16 port switches.
I'm willing to go with the group thinking on this, but I think the above considerations are worth factoring.
I'm more interested in what the chipset inside the box is than the brand name on
the outside :-)
but we'd have to buy one or hunt down a reference to find that out
the 8 port one for $16 is $2.29 per port PoE
https://www.amazon.com/STEAMEMO-Easy-Managed-Ethernet-Splitter/dp/B0DGKN4L2F?th=1
but as I said, I haven't tried one of these yet, so they could be utter junk.
David Lang
|
Description
Currently, we have applied a workaround for IoT (and other trainings) which require wired devices on the same broadcast domain as wireless devices by dedicating 8 ports on each of the cfRoom switches as untagged cfSCALE-FAST.
This is a security risk as well as an improper use of this global WiFi VLAN.
I propose instead, that we add the cfInstall VLAN as an additional "SCALE-TRAINING" SSID on the 2.4Ghz radios only.
This would give us the ability to impose additional limitations on that VLAN (e.g. not allowing it to communicate with other conference VLANs, limitations on its internet access, etc.
I'd also like to see us use semi-smart tabletop switches for all of the training labs that would use these ports. In this way, the ports could be tagged on the cfRoom switches and converted to untagged by the tabletop switches. This would prevent casual use of the ports in non-training rooms by conference attendees.
These are a couple of possible solutions. I'm open to additional suggestions or better ideas.
Acceptance Criteria
No further untagged ports open on switches in public accessible areas
Better security audit and control of the Install VLAN
Implementation of the above across all cfRoom switches.
The text was updated successfully, but these errors were encountered: