hello all!

just to preface my post, i am not a networking noob, but i am noob-ish with mikrotik

i am having some troubles configuring a QinQ setup, i have gone through a few posts and wiki, but i am still confused, maybe even more confused then when i started...

i am using RB750Gr3 (hEX), and it should do the following:
- eth1 is the uplink interface connected to the ISP switch. it should carry only 2 vlans for now, vlan1900 (customer) and vlan4003 (hEX management), but they should be encapsulated in s-vlan 1948
- eth2 is the access port for the customer, and the tagging should be done by hEX
it seems to be a pretty simple setup, but i can not get it to work, i need some help with this! i am also aware that it could be done in more ways...

thanks!

Sorry, don't like problems just thrown over the wall hoping someone will catch it and do it for you.

What have you tried so far, export of config what you tried?

I don't like lazy people either, but I wouldn't say it's this case. I'm not sure about correct solution myself, and it looks like interesting thing to try. If on one interface you have packet in vlan X, that's in another service vlan Y and you want to send it untagged to another interface, how do you do it? I came up with two working ways, but I'm not very excited about either of them.

Simple old style bridging works (but it would be nightmare for more vlans):
Ideally, I'd want simple and direct config, one bridge with vlan filtering and some configuration magic that would allow to connect vlan1900@vlan1948@ether1 to ether2, but it doesn't seem possible. Or am I missing something?

Intermediate solution:
This solves the problem with many client vlans, because it uses more efficient (smaller config) bridge vlan filtering. But this is just quick test with few CHRs, so I'm already not sure what it will do to hw offloading, when the device has some. Next problem is with service vlans, what to do if there's more of them and I need to send them to different interfaces, either tagged or untagged? Again, I don't see any one-bridge solution. As a test, I tried two-level bridge, where ether1 was part of another bridge for service vlans, and vlan1948 was on new bridge instead of on ether1 directly:
But for some reason it doesn't work, and I can't see why. It's not something I'd like too much. Still, I think it should do something. But I just can't find what's wrong.

So in short, same as OP, I'm also interested to see what's proper solution.

Sorry, don't like problems just thrown over the wall hoping someone will catch it and do it for you.

do you know what a forum is for, right? people come here when they can not solve a problem themselves

at the moment no export because i'm starting from scratch again, but there have been a few tries that didn't work

@Sob thanks, i'll give your configs a test and report back

do you know what a forum is for, right? people come here when they can not solve a problem themselves

In this forum there are a lot of helpful people, often they will respond this way. Partially so they don't waste their time giving you advice that you may have already tried. Other times they are outright brash, rough week perhaps.

Just an FYI - QinQ requires jumbo frames. 1500 byte frames aren't enough to encapsulate a VLAN inside a VLAN.

Not sure if it is/isn't the issue but worth noting regardless as you'll run into massive fragmentation issues once you actually start pushing data.

The s-tag side needs to be confirmed as usually that is done on the ISP switch and commonly known as "provider bridge" config. With this, customers can then pass through any vlans they want.

If above is correct, then all you have to do is standard vlan config on Hex.

Confirm above first and post back here

Wow, for once, I can maybe assist @Sob,

For "Provider Bridge" config, you don't need to add a vlan sub interface which is probably reason your config failed, the bridge (new bridge vlan filtering way) looks at ether type, and will add the SVID based on the pvid value of the customer facing "access port".

i.o.w. the customer sends the CVID tagged packets on ether type 0x8100, the bridge will then add the SVID based on the pvid value of customer facing "access port" port you configured. and on other side of "provider Bridge" the SVID will be stripped passing through the CVID tagged frames

Hope this makes sense

I can't say that it's definitely that (needs confirmation from OP), but I understood "eth2 is the access port for the customer, and the tagging should be done by hEX" in a way that vlan1900 on eth2 should be untagged. So it would mean somehow removing both tags. And I don't see any simple direct way.

About my non-working last config, something is wrong, and I'm not convinced it's the config. I get strange results when using service tags, even with simpler tests. Either it's VMware Player I use to run CHRs, or maybe RouterOS, but it doesn't seem likely, because surely someone would have already noticed if there was some bug. But something is definitely strange, because for example, with Tools->Torch on ethernet interface I see tagged packets, but packet sniffer on same interface gives me untagged packets. I'll try to find more when I have time.

In this forum there are a lot of helpful people, often they will respond this way. Partially so they don't waste their time giving you advice that you may have already tried. Other times they are outright brash, rough week perhaps.

It's much more. If people ask questions without providing enough details (posting config is good way, ideally with additional explanation, because not all requirements or intentions may be obvious), it's often difficult to answer. They see what they have, but I don't. I have no idea if they are almost there or if they are completely missing the point. There are too many ways how things can be (mis)configured, and in most cases it's not fun to guess which one it is. Often what they think they did is something different than they actually did, so I can't really believe them when they only describe something. Or they think some parts of config are irrelevant, but it's not true.

In the end it makes huge difference. Provide enough info and answer can be quick "rule X is wrong, change it to Y". Don't provide enough info and we can play long interrogation and explore dead ends for a week. Or you won't get any answer, because this prospect is no fun and it's easier to move on and help someone else.

Just for the record, it's otherwise OT.

[emoji106]

Sorry, don't like problems just thrown over the wall hoping someone will catch it and do it for you.

What have you tried so far, export of config what you tried?

Strange reply? The basic problem is that Mikrotik doc's sucks.
QinQ on Cisco is a piece of cake,- search their docs, and you find 10 great explanations, configurations, notes, "how to test and verify" etc.

With Mikrotik,- missing documentation, people try to lab and find out, finding their own solutions,- perhaps with with hidden faults.
Even a simple vlan configuration on a Mikrotik is strange thing.

Then,- a beginner, unsure of how to do it correctly, asks "how to do?".
That's not lazy, that's common sense.