Unmanaged versus Managed Switches (L2 v L2+)

[RumorConsumer]

Ok so I asked this with the wrong language yesterday and didnt quite get the questions answered that I needed. I am re-asking here in a new thread with the correct language that I think will help.

Lets say my network has a segment that looks like

MX-->Managed switch --> Unmanaged switch (uplinked to the managed switch on one of it's access ports providing the same vlan (4) to all its clients)

Lets say that the default VLAN is 1 and there is one tagged VLAN at #4.

I may use an unmanaged switch in this way in one of two situations

1. Where I need to quickly get some wired clients into a lab and don't have a spare managed switch in which case, like I said above, I set the access port its hung off of to VLAN 4 and then everything wired thereafter is on VLAN 4

or

2. Where I will only be connecting MR's to it and so dont have any need for access ports on the switch itself as the MRs will handle the VLAN tagging to clients.

What are the negative side effects here? I had read that QOS will not work correctly, and also there may be some extra load on the MX and possibly some extra latency but not much. Do you need to be using Meraki switches for them to inherit QOS preferences properly or is there some kind of language that managed switches all can speak to properly implement the settings on the MX? I do not care so much about inter-VLAN communication. Im most interested in optimizing traffic on a single VLAN (4 - my client VLAN).

Thanks!

[rhbirkelund]

There's a good chance that the unmanaged switch doesn't understand 802.1q trunking.

That being said, if you on the managed switch have a port where vlan 1 is native (untagged) and tagging vlan 4, connect the unmanaged switch to said port, all traffic will ingress on the untagged vlan 1 on the managed switch, because the unmanaged switch has no concept of vlans.

Now if the managed switch port is in Access mode on vlan 4, and the unmanaged switch is connected to this port, all traffic on the unmanaged switch will ingress on vlan 4 of the managed.

I hope that made sense.

The negative effects of an unmanaged switch is that you really have no chance to configure features on it, debug network issues etc. Chances are also that it doesn't support any safeguard measures, so you stand the risk of bringing the entire network down, or if someone with little networking knowledge connects a cable to two ports on the same unmanaged switch (introducing a network loop).

Also QoS can not be done on a unmanaged switch, so traffic can not be priorotized on the unmanaged switch. Only on the managed switch.

[RumorConsumer]

@rhbirkelund 

>>>There's a good chance that the unmanaged switch doesn't understand 802.1q trunking.

That being said, if you on the managed switch have a port where vlan 1 is native (untagged) and tagging vlan 4, connect the unmanaged switch to said port, all traffic will ingress on the untagged vlan 1 on the managed switch, because the unmanaged switch has no concept of vlans.

Now if the managed switch port is in Access mode on vlan 4, and the unmanaged switch is connected to this port, all traffic on the unmanaged switch will ingress on vlan 4 of the managed.

I hope that made sense.

--

Yes it makes sense. But check me on this - right now I have just such a situation. 

I have an unmanaged switch on a port off a managed switch that is default VLAN of 1 and tagged VLAN of 4. Every port aside from the one being connected to the managed switch connects to a MR that serves an SSID with a VLAN Tag of 4. In dashboard, the proper VLAN assignments are occurring - MRs are on VLAN 1 which is expected, and the MRs are properly distributing VLAN 4 to clients on said SSID. So on the unmanaged switch it seems like the traffic is able to traverse, but my guess is there is something undesirable happening even though the results seem good. 

[rhbirkelund]

Perhaps then the unmanaged switch can dynamically discover 802.1q packets? Not that I have ever heard of such a switch. What's the make and model of it?

[RumorConsumer]

@rhbirkelund 

https://www.netgear.com/business/wired/switches/unmanaged/gs108pp/

[BlakeRichardson]

Cisco refer to this as Auto-QOS so the switch has a basic understanding of QOS but its NOT user configurable obviously 

[RumorConsumer]

@BlakeRichardson can you be more specific about "this"? To what exactly are you referring?

[Bruce]

@RumorConsumer, just had a look at that switch’s data sheet and it states that it supports 802.1p CoS and DSCP. Since it’s unmanaged all I can guess is that it has some sort of preprogrammed QoS policies, and/or it just passes through the 802.1p CoS header.

The interesting part here is that the 802.1p CoS bits are part of the 802.1Q header that also carries the VLAN information. So my guess at what you’re seeing is that the 802.1Q header is being copied across the switch. Essentially this means that every port on the switch behaves as a pseudo trunk port. If traffic enters the switch untagged it will also leave the switch untagged, if it enters with a tag, it will leave with the same tag.