Thanks for all these videos @MikroTik. I watch all your MikroTips videos religiously. This one might take a while to understand but will rewatch over and over. An application might come soon. The next video in this series should be about L3 VLAN configurations with the introduction on L3 Hardware Offloading in ROSv7.6. It should showcase the best CRS devices to use for L3 Switching and explain how it differentiates from L2 Switching. L3 VLAN vs L2 VLAN diferrences should be emphasized. Once again, thank you guys! You're doing a great job 🎉❤👍🏿

I have seen all VLAN and ARP Video, now ican better understand this part very very Thank you🙏

Amazing... Thank you.

Labrīt, Vajag konsultāciju.

Is there a version without the background music please.

I've been experiencing an issue where the traffic stops going on an SFP port which has 8 vlans configured, the L2MTU has been 1580, I recently changed to the maximum 10222 l2mtu value, does that make any sense on attemping to fix the issue as I have many Vlans configured (8).

would be nice to have a specific video on L2MTU and MTU and the corelation of those two in rOS

@aidangillett5396

5 ай бұрын

It's quite simple. MTU = the data payload that is allowed to be carried (including IP headers). This should almost always be 1500 as that is standard across the board for IPv4 over the internet and is what is expected. I.e. if you are downloading a file, the payload is almost always 1500 bytes. And over a PPPoE connection its often 1492 or 1480 bytes to account for the PPP overhead L2MTU = the above, but including the Layer2 transport mechanisms required to deliver packets (such as VLAN tags) You rarely need to be specific with L2MTU and there is no harm setting it as large as the device is capable. Just make sure L2MTU is sufficiently large through your ENTIRE transport network. As a cheap and nasty switch that only supports 1518 bytes will cause issues as soon as you start adding anything at Layer2

@drumaddict89

5 ай бұрын

@@aidangillett5396 thanks for your explanation - quite easy to understand 👍

VLANs over wifi with or without capsman, please

@kwinsch7423

10 ай бұрын

Yes. If only 2 or 3 APs are involved, static configuration, of VLAN per SSID and fast roaming partners would be gold 🥇

❤

First of all, thank you for your valuable sharing. I would like to consult you about a situation that I think may be related to this issue. I use 2x ISPs and both service providers provide service over VLAN35 with the PPOE method. And I cannot get service with more than one VLAN35 on the modem. Is it possible to solve this with qinq? If I add 1x Qinq supporting device, can I terminate 2x ISP on my modem? I am using a Keenetic Hopper modem.

@mikrotik

9 ай бұрын

That might be a limitation of your modem. If it is able to process 2 ISP at the same time with the same VLAN ID, you could use QinQ to deliver those vlans to the modem. If it can process 2 ISP, but needs different VLAN IDs, or the traffic needs to be untagged then you will need to be more clever about your RotuerOS configuration. In the second case you should seek out Mikrotik consultant or trainer to help you.

Thanks for the video it helps, but unfortunately I still don't have full clarity on a few things. If you are receiving QinQ frames on a Mikrotik Switch and you don't want to strip them or do anything to them and simply move them upstream is there anything special you need to do? Something like the equivalent of a "trunk" port in the Cisco world and it wouldn't matter what VLAN the STAG or CTAG is and it would move it upstream to a L3 Mikrotik Router that is stripping the STAG and CTAG. Also, did you say you can't do hardware offload for QinQ frames on Mikrotik (It has to be processed through the CPU?). I appreciate the help.

@mikrotik

10 ай бұрын

A simple bridge can forward your VLAN tagged frames without doing anything to them. If you need to enable vlan-filtering on that bridge, simply create two trunk ports using the VLAN ID of the outer tag - that will forward those frames untouched just like a regular bridge would. Hardware offloading is generally possible for the bridge method, it is only impossible when creating VLAN interfaces. Watch pt1 and pt2 if you haven't, we talk about VLAN hardware offloading there in more depth.

@oliver1121

10 ай бұрын

@@mikrotik Right, thanks for the clarity!

If I use use-service-tag=yes, which Ethertype will be used? 0x88A8 or 0x9100? As far as I can see, the is no option like in Bridge?

@mikrotik

9 ай бұрын

0x88A8 is the 'service-tag'

If I add a VLAN interface VID20 to an already existing VLAN interface VID10, I understand this will create a Q-in-Q frame. But how does it get decapsulated on the other end? It goes into the bridge, it will remove the outer tag (VID10) and then, VID20 is left. How does it (the bridge) know, it has to send the frame to VLAN-Interface with ID20? And how does this concept work if use a single Bridge is used instead of directly attached VLAN-Interfaces to an eth-Interface? Does it go VLAN.20 attached to VLAN.10 attached to the Bridge? Or VLAN.20 attached to the Bridge and VLAN.10 attached to the Bridge. Unfortunately this is left totally left unclear.

@mikrotik

9 ай бұрын

The bridge can only work with one (outer) tag at a time, any additional tags don't even get read by the bridge interface. In you example VID20 gets handled by the bridge, so you need something in the same broadcast domain that will process the VID10. You could either have a vlan interface for VID10 as a port on the bridge, or a physical port from your bridge could connect to another device that will process VID10.

regarding increasing l2mtu and the buffer size, if you just set it to the max what can you expect in terms of performance? or is it that it simply uses more RAM?

@mikrotik

10 ай бұрын

You won't even notice any difference on high end devices, but on something from the lower end, you will likely see more RAM and CPU usage. Everything depends on the specific hardware and the rest of your setup.

Would be nice to make videos information or best practise any corelation mtu we know in mpls , there are interface mtu, interface l2mtu and mpls interface mtu. And also in vpls we recognise another mtu settting like (vpls mtu, vpls actual mtu, vpls l2mtu)

15:14 "and since they cannot be hardware offloaded" Said it in a quick comment, like it was a trivial thing... What does that mean? How becomes hardware offload in scenarios where you need to receive 0x8100 on some ports and send with 0x88a8+0x8100 on other ports?

@mikrotik

10 ай бұрын

VLAN interfaces are always processed by the CPU. VLAN filtering using a bridge interface can be hardware offloaded. Watch pt1 and pt2 for more details.

@fischerdouglas

10 ай бұрын

@@mikrotik Could you please demonstrate hardware offload on CRS3XX on dot1q being stacked in qinq (outer tag being 0x8818)? What about Hardware Offload on seletive QinQ?