Nope, because that's not how VLANs and trunks work.
It might be best to get back to basics.
Why are you using a LAG? This will significantly complicate things and is probably not going to give you an improvement in performance, so it would be useful to know exactly why you need/want it.
You should start with only the router, then add the first switch, then the second. You need to prove at each steps that the VLANs are working properly.
My recommendation would be to reset everything to defaults (go ahead and take backups first so you can get back to your current state if you want).
Then, create a new network on the router and assign it to one physical port (untagged) so that you can verify the operation of the new network in general.
Once that is done, you can try assigning that network as tagged on another physical port to create a trunk. You'll want the same configuration of untagged + PVID (if any) + tagged networks on the uplink port on the switch so that both sides of the trunk are the same. Assign one port on your switch as an access port (untagged + PVID) to verify that the trunk is working properly. Then you can do the same for your downstream switch.
@jedthe3rd - it might make sense for you to look at how 802.1q works so that you can have a more comprehensive understanding of the principles at work.
Fundamentally there are 3 kinds of port configurations:
access port: This is a port that has just a single network and it is untagged (also sometimes called PVID, native, or default). This is basically a "normal" connection for most devices (think computers, STBs and game consoles, etc.).
trunk port: this is a port that carries more than one network. To do this, tags are introduced into the header of the ethernet frames. this allows the connected equipment to differentiate the ethernet frames for each network and handle them appropriately.
you may have zero or one untagged network + one or more tagged networks on a trunk, per the standard.
many people believe that it is bad practice to have any untagged networks on a trunk; the standard allows it, but personal/professional opinion/practice will dictate here.
[don't know the name for this 3rd type]: a single tagged network on a port, no untagged networks. This isn't technically an access port (because the network is tagged), but is also not a trunk (because there is only one network). This is less common in home environments, but is somewhat frequently found in VoIP phones and such that expect a tagged network.
Connecting switches, routers, APs, and other VLAN aware equipment together using a trunk means that each side must be configured to match (it would be okay to have a mis-match if it is intentional, but typically it is best to keep them matching and only send relevant networks).
Your switch doesn't do this:
except insofar as the management/configuration interface of the switch itself is typically set to be part of a single network -- often by default VLAN 1. But that has nothing to do with the ability to pass VLANS.
Ya, I did read the standard and understand what an access port and trunk port is. Does my configuration look wrong? The main reason I made my comment is because of a thread I read saying that the trunk port on both sides needs to be in VLAN1 for the Netgear GS724TP. It was talking about the configuration between the Netgear GS724TP and a MikroTik switch like mine. It seems like many of these switches have their own flavor of how they "follow" and expose the standard via GUI, so that is why made that comment.
A LAG is just a logical port so it shouldn't matter what port my switch talks to the router through. If I do remove the LAG and it works, that doesn't really get me anywhere because I want a LAG between my switch and the router. Maybe the LAG doesn't have any practical purpose and I realize that, but this is as much a learning exercise as it is a network configuration.
After reviewing my OpenWRT configuration do you see anything that doesn't look correct with the VLAN setup?
Should I have created a Bridge for my LAG and used the Bridge VLAN filtering tab to configure the VLAN relationship?
The basics are a LAG is just another port and the way I have my VLAN configured it isn't working.
But why? I don't think it serves any purpose except to make the configuration more complicated and difficult to debug.
You can always re-build your configuration with a LAG once you have validated how all of the pieces come together. You have 3 dissimilar pieces of equipment (OpenWrt, Netgear, 'Tik), and although they are all standards compliant, the details about how they must be configured will vary for each brand. And as such, including LAG is just one more layer of complexity to worry about. You need to be certain that you understand how each device works to get a working VLAN setup in the first place, which I don't think is currently established.
Bluntly put: if you don't reduce your variables, you'll likely never fully understand why things are or are not working.
So does my current VLAN configuration look correct if I were to remove the LAG?
I created the vlan on the internal Switch (switch0). Set the port(s) I wanted to use for the vlan as tagged, then tagged the CPU that I want to use for hardware processing. Create an interface over that VLAN with a static address, add it to a firewall-zone (I am using the default lan firewall zone) that is configured correctly. Enable dhcp on that interface to allow it to auto-assign ip's.
I'm not sure what this means? Also, which version of your config files -- you've posted a few?
Again, the better way to do this is to start with a default configuration (bonus -- if you have another router than can run OpenWrt, you can do all of this without disturbing your main setup).
All of this sounds good, provided that the config is essentially default as a starting point.
So if you remove the LAG, you may be in better shape. However...
Something doesn't look right, as @trendy said earlier.
To figure out what might be happening, you should reset to defaults and look at the network configuration file in the default state. Post that here, too, so we can see exactly what you are looking at. Then we can probably move from there.
What specifically doesn't look right? I know what the default state looks like so I just need to know what seems wrong, because I will end up at this exact config except the bonding if I reset to default and retrace my steps. I generated this config purely from LUCI and the Netgear R7800 isn't configured to use DSA by default.
The only thing I can think of without either of you giving me specifics is that the interface names aren't "standard" swconfig, but that shouldn't matter right? Interface names are transient.
The fact that there appears to be a mixture of DSA and swconfig related configuration statements.
this looks like DSA:
and this looks like swconfig:
It either is or is not DSA on 21.02. There is no concept of "by default." -- the underlying software architecture on OpenWrt has been changed such that some devices are now DSA, and others still use the older swconfig. You wouldn't say that the combustion engine in a car "isn't configured for diesel fuel by default" -- it is either gasoline or diesel, and putting in the wrong fuel will be bad.
I am urging you to reset your router to defaults and then post the /etc/config/network file so that we can understand what should be there by default. From there we can talk about the specific process.
I think we can see the default network config file in /rom/etc/config/network or something like that.
Other than that, the network file is a bit complicated, even if we leave apart the LAG, due to this mix of DSA and swconfig.
I'll agree with @psherman , take a backup of the current config. You'll be able to restore at any point like this. Reset OpenWrt to defaults. Work your way to create a trunk first from OpenWrt to the switch and verify connectivity with Mikrobrick. After you got all that working, introduce the LAG in the configuration.
That should, in theory, regenerate the default file for /etc/config/network, but there are a whole lot of assumptions for the default config that may or may not be true when working with an existing configuration and could result in the system becoming unreachable. The relative risk makes this undesirable vs simply resetting to defaults. Besides, in this particular case, I suspect that there is a lot of value in resetting since it may have lots of other issues beyond just the network file.
