VLAN Trunking

Update - I was able to run some test configs yesterday and verified the addition of the bridge name in the tagged list didn’t seemingly do anything, and best I could tell had no effect on any traffic whatsoever, so it’s being removed from the production config during the next maintenance window.

I don’t have a test environment I can test and validate something right now and for some reason I’m struggling to remember the correct config for VLAN setup inside a bridge, because I just logged onto a working environment someone setup and see a config that doesn’t make sense and now I’m questioning my memory & reading of VLAN implementation…

This is a situation where multiple ports are added to a bridge (in this case ether3, 4 and 5), and vlan-filtering=yes on the bridge. The goal is to allow tagged VLAN100 traffic in on ether3 and ether5 but not ether4.

This was the config I found

/interface bridge vlan
add bridge=LAN tagged=LAN,ether3,ether5 vlan-ids=100

I thought the correct config should have been

/interface bridge vlan
add bridge=LAN tagged=ether3,ether5 vlan-ids=100

but while I’m at it, because this has me all confused now, would the inclusion of LAN in the tagged list serve to allow any member of the bridge to pass tagged VLAN100 traffic, thus invalidating the need to specify the individual interfaces (and also in this case allow traffic on the port that wasn’t intended)?

/interface bridge vlan
add bridge=LAN tagged=LAN vlan-ids=100

main reason for the question is this is a remotely running production system that I have to schedule making any changes to, and have limited access to test functionality while remote, and as I’m also away right now I don’t have access to my lab for testing before making changes to this system.

Inclusion of bridge port to the list of ports members of certain VLAN allows device (router) to interact with said VLAN. As bridge port is configured as tagged member of VLAN 100, a vlan interface is needed (e.g. /interface vlan add interface=LAN name=vlan100 vlan-id=100). Then one would add IP setup to that vlan interface (IP address, DHCP server, etc.).

!/2 the equation, you need to show the / interface bridge port

add bridge=LAN ingress-filtering=yes frame-types=admit-only-vlan-tagged interface=ethernet3
add bridge=LAN ingress-filtering=yes frame-types=admit-only-vlan-tagged interface=ethernet5

/ip bridge interface
/interface bridge vlan
add bridge=LAN tagged=LAN,ether3,ether5 vlan-ids=100

By the way using word LAN for a bridge is plain dumb since LAN is an already used construct and nomenclature in MT RoS
Change it!

Yes, In this case the router is not supposed to interact with VLAN100, just simply pass the tagged VLAN packets between the ports. This is why I was confused, I didn’t configure this router and so I’m trying to understand why it was setup this way.

Not trying add multiple bridges…


Maybe in the consumer devices default settings that’s true (and then only as an interface list), but no that is not at all correct for the platform as a whole, or even a non-consumer default config like a CCR router that only comes with an IP address assigned to a port (and in the past sometimes not even that).

I also still support routers and offices that had their base configs built before interface lists even existed in ROS (all of which have of course been migrated to newer hardware, but exported/imported the config), there’s no reason to break anything just to appease a default config which these devices have never before seen.

If that the case, you’re right, your bridge called “LAN” shouldn’t be tagged=…

I’d presume there is NOT a /interface/vlan with vlan-id=100 — as that wouldn’t be needed if bridge was only to forward VLAN100…
i.e. if router VLAN interface that was listening on “LAN bridge” for VLAN 100 & it was NOT marked as tagged= in /interface/bridge/vlans… that MIGHT cause a problem… Theoretically, it shouldn’t since it isn’t tagged=, BUT who knows…

Good points, if one is simply flowing data from an existing vlan into the device and out one of the ports, the bridge is not tagged just the interfaces involved tagged coming in and either tagged or untagged on the way out depending. The only vlan that needs to be identifed in /interface vlan and tagged is the management vlan (where the device gets its LANIP)

Regardless name of LAN for bridge is not wise, it will get you into trouble sooner or later,

hey brian, lived one year in Wallingford CT, in the late 60s. On south main street, house doesnt exist anymore doing a google search…

correct, it is just allowing tagged packets to pass through, not engaging in any network activity beyond that.

A) LAN for the bridge name makes zero difference if you’re not using a default config on a consumer model router, and it never will because default configs are only applied during a reset
B) While it IS used on other devices I support, in this case LAN was used as illustrative for easy post understanding, the real bridge name is something specific to the installation
C) In the event if I did want to name the bridge LAN on a consumer device with a default config, it would only first require renaming the interface list name, once done there would never be any conflict or issue, and if I did reset the device it would still reset fine and resume normal operation without problem, and it could operate with the renamed interfaces forever.
D) The consumer devices I support (this was not one of them) use a proprietary default config we wrote in-house that’s nearly 1000 lines long, and performs a ton off custom setup, stock default config is not something that matters to me.
E) There is nothing at all in RouterOS that will care what you name an interface, nor will you ever get into trouble naming the interface anything you can imagine, if the name can be entered via the CLI, you are guaranteed safe to name it whatever you want, it’s just up to you to manage the device with that config. Renaming interfaces will not break things, nor is there any future fault or risk to what you name the interfaces, as long as they work for your config.

As for Wallingford, certainly heard of it, but aside from passing through it on the highway heading up to Vermont to go skiing I’ve never been there, I tend to stick to the coast, but I imagine like most things in this state it’s changed to the point of being nearly unrecognizable from 60 years ago.

We also had a farm in South Woodbury Vermont. Maybe we are related LOL.

I grew up in in midwest, moved here in 2008 so I’d say chances of that are pretty small, but I do love Vermont what a beautiful place to visit!