I was digging into how to best configure the connection with the ISP that use PPPoE and VLAN ID.
The best&clear solution I found around, was to
edit the WAN interface,
set the protocol to PPPoE and (in my case I’m using a Flint2 that use the eth1 for the ougoing traffic)
set the device to eth1.ID
This would lead very easily to have the outgoing port (eth1) configured as a 802.1q trunk with the appropriate ID. This make sense also because the outgoing port to manage as a trunk is clearly identified.
BUT THEN I found also this video https://www.youtube.com/watch?v=06BTDkWw0v8, where the trunk port for the wan , is created just editing the WAN interface, and having the device port just indicated ad wan.ID !!
Considering that in OpenWrt an “interface” is a match of protocol+device, In this way no port seems to be identified and paired with the wan… ?!?!?
Kindly ASK:
How is this setting supposed to work choosing the right device for the port to trunk?
How could the system arbitrarily choose between port eth1 or eth0 ?
Normally this is the correct way to approach the configuration. However, the 3rd point is hardware dependent...
To elaborate -- the name of the device used for the wan interface could be different depending on the hardware in question. If the device uses DSA, it will likely be called wan, but this also depends on the external markings on the case (DSA aims to make the logical switch port names consistent with the physical labeling at the ports).
If the device has individually routed ports (i.e. not connected to a switch chip such as for x86 systems), the name will typically be something like eth1. A swconfig based system operates a bit differently and would require an edit of the switch's VLANs.
With all that in mind, we can guide you more specifically if we know the hardware and ideally the (near) default network config file construct:
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button (red circle; this works best in the 'Markdown' composer view in the blue oval):
Remember to redact passwords, VPN keys, MAC addresses and any public IP addresses you may have:
AFAIK starting in OpenWrt 21.02, many target architectures have switched from swconfig to DSA.
So I assumed:
my router is using DSA
the video is using v 23.05.05; so it is using DSA too and make use of the wan.ID syntax.
At present time, my configuration DOES work setting the trunk to eth1.100, BUT I cannot understand how it COULD work setting the trunk port as wan.100 (I did not test it YET…) !!
I cannot figure out in the video, how the system could “guess” which port to set the trunk correctly wor wan.ID!
In my case could be eth1 or lan1, or lan2, or ….
Is there some other information that the video is not showing , that will make the match ?
Would the configuration used in the video (wan.ID) work for my system, or there are some differences, that will make my system fail to connect ?
Yes, but it has been a few targets at a time and some still remain on swconfig.
Slight (hopefully not too pedantic) nit here: you're not setting a trunk. A trunk is a port that carries multiple networks (using 802.1q tags). Here you're just setting the port for a tagged VLAN, but just one so it's not technically a trunk.
It's not 'guessing' anything -- it's being set explicitly.
In the case of your device, eth0 from the CPU is connected to the switch and you have 5 ports that are (by default) treated as a lan. Because of the switch chip and DSA, eth0 and the switch chip are abstracted into the ports lan1-lan5. Meanwhile, eth1 on the CPU is directly wired to the ethernet port on the back which is typically used as a wan. Since it doesn't go through the switch, it is what we would call an individually routed port.
When you set eth1.100, it is saying take the base eth1 device and use 802.1q tags to setup a tagged VLAN with VLAN ID 100.
No. Not easily. The system has no concept of a device called 'wan' but it does know about eth1.
I didn’t watch the video you mention because for some reason it’s age restricted, which is suspicious. Basically with DSA drivers you don’t use the underlying CPU port names even though they may be present.
So in your case, either you are meant to use ‘eth1’ , or there actually is a ‘wan’ device that is linked to the wan port.
There’s also everything-in-one-bridge method you can use where you put everything in one bridge even wireless and then you can set the vlan tag for the wan there. I do this with my dsl router. It has the advantage of not setting up bridges on top of bridges, there’s just one bridge.
eth1 is a direct connection between the CPU and the ethernet port and does not pass through a switch chip. It is not renamed wan in the DTS file. So in the config files, it will be eth1 for the MT6000.
It is not necessary or useful to include eth1 in br-lan in the case of the MT6000 when the eth1 port is being used as a wan.
Further, it's not setting up "bridges on top of bridges", it is simply declaring that this port should use a tagged VLAN ID. There is still only one bridge (br-lan) which contains ports lan1-lan5 and the eth0 connection to the CPU.
Just as an addon for @wilsonyan
It's called "vlan aware bridge". Yes back in the days you had to Tag on an interface and then enslave that interface to a bridge which had no further knowledge about the vlan id. But since 10 years Linux is able to handle vlans on the bridge device. And with dsa it's available on most OpenWrt supported devices.
That’s true, I guess this case of mine is a little different because the modem is being used as a bridge so then it is directly useful. I guess you’re right there might be a small overhead.
Not in this case, but for people setting up “dumb ap” or whatever other setups they can end up needing to put bridge vlan devices as ports into other bridges, i’m not sure but I think that can have a performance penalty especially on unaccelerated mips cpu stuff.
Yes, different use case. And yeah, there is a risk of some overhead. I don't have that unit and I don't know how much of a bandwidth hit would be expected here (I suspect not much in actual throughput, but likely not insignificant on CPU load).
Right... again, you've got a different use case. Yes, for those working in the bridged-AP mode and/or with VLANs on the lan side, bridge-vlans are the necessity.
