VLAN basic scenario help?

[IntL-Daniel]

I am sorry for maybe a basic question, BUT I am little bit lost in VLAN configuration. My symplified situation is as folows:

So what I want to do is in fact divide two switches into four independent switches. So what I think need to do
* select ports 11-12 as VLAN2 UNTAGED on both switches?
* leave ports 1-10 as VLAN1 UNTAGED (and Management) on both switches?
* and then I have to select and configure trunk port(s)?


As you can see, there are two connections between switches but while the first connection (on port 11) is incomming connectivity to router (WAN2), other connection (on port 1) is the LAN behind the router. Both connections are two independent p2p wireless links. I need them both completely separate like independent switches. Is there a solution for this task via VLAN?

Thank you in advance!

[sirhc]

So yes you can divide a switch into 2 or more logical switches but there are caveats.

ID Description...... 1 2 3 4 5 6 7 8 9 10 11 12 13 14
1 Management..... U U U U U U U U U U E E E E
2 Logical Switch 2 E E E E E E E E E E U U E E
Spacing above is off but you can figure it our

In the above example
Devices plugged into ports 11 and 12 would not see devices plugged into ports 1-10
Devices plugged into ports 1 thru 10 would not see devices plugged into ports 11 and 12

However you could only access the switch UI/CLI on ports 1-10 as stated many times the TOP VLAN is the management VLAN and the only VLAN that can be the management VLAN meaning has access to the IP assigned to the switch.

Now you can change the top VLAN ID to what ever ID you want but the TOP VLAN is always the management port.

Also since ports 13 and 14 belong to no VLAN they are essentially disabled and neither port can not see any other port or each other.

You can see what I do in this post at my WISP and there is a long video even that walks you through it.
viewtopic.php?f=30&t=452#p2961


Only a single VLAN can have a U assigned to a port, that can be any VLAN.

The way we address VLANS is no differnt than the way most if not all switches address VLANs as this is an industry standard, the only thing being differnt is our UI which in my opinion our UI is pretty straight forward and simple to anyone that understands VLANs. The only thing most people do not get off the bat is that the TOP VLAN is always the Management VLAN where other switches have a check box or a configuration to specify which VLAN is the management VLAN and you can only ever have 1 management VLAN on any switch.

One thing we offer is the ability to assign an IP to any VLAN not the management VLAN which would allow you to access the UI/CLI on any VLAN but the IP address accessing the UI/CLI on a VLAN that is not the management VLAN "must" be withing the same subnet as the IP assigned to that VLAN as it does not have the ability to assign a gate which is for a good reason as it does not have routing ability. The other reason one might assign an IP to VLAN is so from the switch you can ping a device connected to that VLAN that is not accessible to the IP assigned to the switch to get to the UI so you can ping that device from the switch to setup auto port bouncing encase a device stops responding.

However the IP assigned to a VLAN should not be in the same subnet as the IP assigned to the switch. Not sure what that would not, might work, might not I never tested that.


There are also several post on the forums discussing this very same question which you can search for and even though for some stupid reason the magnifying glass in the search box no longer shows up but is still there if you move your mouse to the far right side of the box and your mouse pointer will indicate there is a selection there which will take you to the ADVANCED search section.

[IntL-Daniel]

Thanks for detailed reply. Mentioned settings is the first one I did try. Are you sure that with this settings on both switches I can connect both switches together via port 12 (12 to 12) and port 1 (1 to 1)? On my test it seems there was a loop but I can test it again. So for my case, no trunk configuration necessary? Do I have to change MTU on these ports or 1528 is enough?

[sirhc]

Yea if both switches are the same config you could go 1 to 1 and 12 to 12 and no loop would occur.

1528 is fine for VLANs but in the above config there are no VLAN tags anyway so packets are not encapsulated.

Now on my switches which you get a full tour on in the previously linked video you will see we are using VLANs pretty extensively and our MTU is default.

However if you search the forums there are many posts on MTU sizes with VLANs

One of these days I need to move my videos off YouTube and go to Rumble. I am tired of supporting big tech and their cancel culture. I will soon be moving my cloud stuff off AWS and GMAIL and Facebook and Twitter and Instagram can all bite me too.

I love DuckDuckGo vs Google, no politics, no PC, and honest/complete/full search results uncensored.

[IntL-Daniel]

So yes you can divide a switch into 2 or more logical switches but there are caveats.

Code: Select all

 
ID Description...... 1 2 3 4 5 6 7 8 9 10 11 12 13 14
 1 Management....... U U U U U U U U U U E E E E
 2 Logical Switch2.. E E E E E E E E E E U U U U

Unfortunately if I have 2 switches exactly with this configuration above and then:
1/ if connect port 14 to 14 via patch RJ45 cable (in production it will be wireless p2p link) then
* device connected to port 11-13 can reach device connected to port 11-13 on other switch - OK

2/ if add another patch cable and connect ports 1 to 1 then
* devices connected to port 11-13 cannot reach (!) devices connected to port 11-13 on other switch - ???
* but devices connected to ports 2-10 can reach devices connected to port 2-10 on other switch - OK

So I am at the begining, that is why I create this thread..what I am missing? Thanks.

[sirhc]

Well originally in your post you did not specify ports 13 & 14 so I simply put them in VLAN 2 so no, ports 13-14 could not reach the switch UI/CLI/I{P directly as the TOP VLAN is always the management VLAN regardless of the ID you assign it and in the TOP VLAN 1 which os where the switch IP address is, on the TOP VLAN 1 ports 13-14 have an E which means exclude so they can not get to the switch I{ address.

We do not handle VLANs any differently than any other switch as VLANs is a "standard" and follows rules. The main difference with our VLAN UI is that we do not have a check box on each vlan to indicate the management VLAN we simply state that the TOP VLAN is always the management VLAN regardless of the ID assigned to it. This would be why you can move other VLANs up or down in the list for easier visual interpretation but the TOP VLAN is FIXED in the top position. If we did have a checkbox on each VLAN row you would only be allowed to check one VLAN as the management VLAN.

There is a ? in the upper right corner with a pop up help screen.

[IntL-Daniel]

Well originally in your post you did not specify ports 13 & 14 so I simply put them in VLAN 2 so no, ports 13-14 could not reach the switch UI/CLI/I{P directly as the TOP VLAN is always the management VLAN regardless of the ID you assign it and in the TOP VLAN 1 which os where the switch IP address is, on the TOP VLAN 1 ports 13-14 have an E which means exclude so they can not get to the switch I{ address.

We do not handle VLANs any differently than any other switch as VLANs is a "standard" and follows rules. The main difference with our VLAN UI is that we do not have a check box on each vlan to indicate the management VLAN we simply state that the TOP VLAN is always the management VLAN regardless of the ID assigned to it. This would be why you can move other VLANs up or down in the list for easier visual interpretation but the TOP VLAN is FIXED in the top position. If we did have a checkbox on each VLAN row you would only be allowed to check one VLAN as the management VLAN.

There is a ? in the upper right corner with a pop up help screen.

Not sure if you uderstand the root of my issue, so again, if both "parts" (defined by two VLANs) of two switches are connected together, then only one part (management VLAN) of the switches is working and other part (VLAN) does not work. To be working means that devices conencted to each part (VLAN) of switches can communicate together. Not working means, that device connected to port 11-14 on VLAN2 of switch1 cannot reach device connected to port 11-14 on VLAN2 of switch2. So I am not talking about reachability of switch web UI from VLAN2.

[sirhc]

That is correct unless you connected say port 1 to 1 and 11 to 11 between the switches.

Then devices on both switches ports 2-10 would see each other and devices on both switches ports 12-14 would see each other but ports 1-10 could not see ports 11-14 unless somewhere else you routed or bridged the logical switches. Also only devices on ports 2-10 could see the switch UI/CLI unless other wise connected or routed which would then allow 12-14 to see the switches.

There are many different ways to do this based on what you want to achieve.

Again I made a complete thread in Sirhc's Corner which Linked above where I show you a fairly complicated VLAN setup with routers and such in my towers and I go over it in a LONG video you just need to find the part where I discuss the VLANs.

But again we handle VLANs the same way any other switch does so there are tons of tutorials and white papers available on the net.

I am sorry I can not completely understand what you want or I would simply tell you, I am NOT trying to be cryptic.

[IntL-Daniel]

It seems that the root of my issue is the STP that is not supported to run in multiple instances , see here so it seems now that it would be enough to disable STP on both trunk ports (1-1 and 14-14) and on both switches! :-) (otherwise STP do not care about separate VLANS and still thinks there could be a loop and disable one path).