Community discussions

MikroTik App
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Topic Author
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

L3HW User Manual Updated

Thu Jul 08, 2021 3:29 pm

Good day, ladies and gentlemen!

We have updated Layer 3 Hardware Offloading User Manual to reflect the latest features, changes, and configuration samples.

Feel free to use and do not hesitate to provide feedback!
 
Cablenut9
Long time Member
Long time Member
Posts: 542
Joined: Fri Jan 08, 2021 5:30 am

Re: L3HW User Manual Updated

Thu Jul 08, 2021 3:36 pm

How is there a 7.1beta7 listed if it hasn't been released yet, or are you just keeping it as up-to-date as possible?
 
User avatar
pcunite
Forum Guru
Forum Guru
Posts: 1345
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: L3HW User Manual Updated

Thu Jul 08, 2021 3:38 pm

Thank you, excited about the changes, wireguard too.
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Topic Author
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

Re: L3HW User Manual Updated

Thu Jul 08, 2021 3:45 pm

How is there a 7.1beta7 listed if it hasn't been released yet, or are you just keeping it as up-to-date as possible?
Oops, we accidentally posted implemented but yet unreleased features. Well, I guess that now you have an official sneak peek of the upcoming changes.
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 2096
Joined: Mon Jan 14, 2008 1:53 pm
Location: Over the Rainbow
Contact:

Re: L3HW User Manual Updated

Thu Jul 08, 2021 3:54 pm

Release by release the L3HW feature set is growing ☺️

Hopefully IPv6 support is added in the next few releases.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11439
Joined: Thu Mar 03, 2016 10:23 pm

Re: L3HW User Manual Updated

Thu Jul 08, 2021 4:09 pm

IMO there's an error in the "VLAN configuration example":
/interface/bridge/port add bridge=bridge interface=ether2 pvid=20
/interface/bridge/vlan add bridge=bridge tagged=bridge,ether2 vlan-ids=20
Doesn't first line of this example set ether2 as access port for VID 20 and should thus be set as untagged member of VLAN 20 in the second configuration line?

Or (according to the idea behind the example) ether2 should rather be set as tagged port with "pvid" setting omitted?
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Topic Author
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

Re: L3HW User Manual Updated

Thu Jul 08, 2021 5:39 pm

IMO there's an error in the "VLAN configuration example":
/interface/bridge/port add bridge=bridge interface=ether2 pvid=20
/interface/bridge/vlan add bridge=bridge tagged=bridge,ether2 vlan-ids=20
Doesn't first line of this example set ether2 as access port for VID 20 and should thus be set as untagged member of VLAN 20 in the second configuration line?

Or (according to the idea behind the example) ether2 should rather be set as tagged port with "pvid" setting omitted?
That's a good question. Thank you! Let me explain.

The example you are referring to shows how to properly set up hardware routing for a tagged single (i.e., not bridged) port. It is a rare case but has a high chance of misconfiguration.
  • In the case of software routing, you don't need a bridge in-between because the port is not meant to be bridged with other ports. You simple create /interface/vlan on top of the physical port.
  • However, this does not work for hardware routing. L3HW is built on top of L2HW, and L2HW, or in particular - the hardware bridge, is the one that assigns VLAN tags to the packets. Therefore, you need a bridge in between, otherwise, the hardware cannot set VLAN tags. This is a hardware requirement.
  • That's why we have to put the port under the hardware bridge but, no matter how weird it sounds, make sure it is not bridged (by setting VLAN filtering).
  • pvid property of /in/br/port is mandatory. If you omit it, the default pvid=1 is used, meaning the port gets bridged with other ports with VLAN ID 1. We do not want this, so we explicitly set pvid=20.
  • Setting port's pvid leads to a dynamic vlan creation where the port is untagged by default. But we need port to be tagged, therefore we explicitly define /in/br/vlan entry for VLAN ID 20.
  • Port's pvid is not used for inter-VLAN routing. We offload vlan-id of /interface/vlan entry into the hardware routing table instead. So you are right that pvid could be theoretically omitted, but in reality, pvid is mandatory. So the rule of thumb is to set pvid to the same value as vlan-id. Or one of vlan-ids because multiple VLANs may be routed through a single trunk port.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11439
Joined: Thu Mar 03, 2016 10:23 pm

Re: L3HW User Manual Updated

Fri Jul 09, 2021 12:53 am

  • pvid property of /in/br/port is mandatory. If you omit it, the default pvid=1 is used, meaning the port gets bridged with other ports with VLAN ID 1. We do not want this, so we explicitly set pvid=20.
  • Setting port's pvid leads to a dynamic vlan creation where the port is untagged by default. But we need port to be tagged, therefore we explicitly define /in/br/vlan entry for VLAN ID 20.
  • Port's pvid is not used for inter-VLAN routing. We offload vlan-id of /interface/vlan entry into the hardware routing table instead. So you are right that pvid could be theoretically omitted, but in reality, pvid is mandatory. So the rule of thumb is to set pvid to the same value as vlan-id. Or one of vlan-ids because multiple VLANs may be routed through a single trunk port.

Not directly related to L3 routing (hence off topic in this thread), but anyway: I always thought that setting port tagged member of VLAN (/in/br/vlan entry for VLAN ID) and setting PVID on bridge port (/in/br/port) makes possible mismatch: if frame-types is not set, then untagged frames are allowed and get tagged on ingress while on egress they are always transmitted tagged? Or did this behaviour change in ROS v7?
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Topic Author
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

Re: L3HW User Manual Updated

Fri Jul 09, 2021 8:12 am

Not directly related to L3 routing (hence off topic in this thread), but anyway: I always thought that setting port tagged member of VLAN (/in/br/vlan entry for VLAN ID) and setting PVID on bridge port (/in/br/port) makes possible mismatch: if frame-types is not set, then untagged frames are allowed and get tagged on ingress while on egress they are always transmitted tagged? Or did this behaviour change in ROS v7?

If you want to prohibit untagged traffic, set frame-types=admit-only-vlan-tagged for the given /in/br/port. The same behavior in both ROS v6 and v7.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19105
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: L3HW User Manual Updated

Fri Jul 09, 2021 7:27 pm

Just to be clear this aberration, anomaly is only for a very specific or rare scenario because its seem counter intuitive to what we have been exposed to up to this point in time.

In other words, can you better describe the use case/requirement that would lead to such a bizarre setup and is this limited to specific MT devices or all?
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11439
Joined: Thu Mar 03, 2016 10:23 pm

Re: L3HW User Manual Updated

Fri Jul 09, 2021 11:24 pm

If I understood @raimondsp's explanation correctly, then it's the same for all devices and kind of makes sense:

when bridge port has PVID set (and it always has one, if nothing else the implicit pvid=1), then it gets automatically added as untagged member of corresponding VLAN. Unless it's explicitly added as tagged member of the same VLAN (manual setting overrides automatic one), in that case port becomes tagged member of said VLAN.
And setting of frame-types to correct value should be at least good practice because of higher security, the default setting of frame-types=admit-all might be a good starting point (because it doesn't block anything) but often (if not mostly) it's just too permissive.

I'm sure @raimondsp will correct me if I'm wrong.

I still don't fully understand why PVID setting is mandatory in practice. @raimondsp writes that omitting to set it keeps the default setting of pvid=1 (which we already know very well), but the argument about bridging the port with other ports with pvid=1 seems moot to me if frame-types property is properly set (to admit-only-vlan-tagged) (in which case port won't pass untagged frames on ingress and in practice pvid membership doesn't matter much).
 
User avatar
pcunite
Forum Guru
Forum Guru
Posts: 1345
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: L3HW User Manual Updated

Sat Jul 10, 2021 1:02 am

I still don't fully understand why PVID setting is mandatory in practice. @raimondsp writes that omitting to set it keeps the default setting of pvid=1 (which we already know very well), but the argument about bridging the port with other ports with pvid=1 seems moot to me if frame-types property is properly set (to admit-only-vlan-tagged) (in which case port won't pass untagged frames on ingress and in practice pvid membership doesn't matter much).

Actually, when the frame-types property is set to admit-only-vlan-tagged, it does not necessary check the ingress. If ingress-filtering is set then it will. Ultimately, all this applies to us when configuring Hybrid ports:

ingress-filtering
By default, VLANs that don't exist in the bridge VLAN table are dropped before they are sent out (egress), but this property allows you to drop the packets when they are received (ingress).

So, if you want port security in a Hybrid configuration, you need four confusing settings: pvid=X, frame-types=admit-all, ingress-filtering=yes, and then finally a tagged behavior on the port. Even though you have admit-all set, ingress-filtering will check to see if PVID is not 1 and if a tagged VLAN ID has been set on the egress behavior. This toxic mix of settings allows untagged and tagged frames, but only tagged frames from the list of allowed tags. Good tags pass entrance, bad tags are dropped at the door.
 
User avatar
StubArea51
Trainer
Trainer
Posts: 1739
Joined: Fri Aug 10, 2012 6:46 am
Location: stubarea51.net
Contact:

Re: L3HW User Manual Updated

Sat Jul 10, 2021 9:01 pm

Oops, we accidentally posted implemented but yet unreleased features. Well, I guess that now you have an official sneak peek of the upcoming changes.

Not complaining :P

What range of values will be possible for MTU on the CRS3xx series?
RouterOS v7.1beta7: variable MTU / Jumbo frame support.
 
rpra
newbie
Posts: 45
Joined: Tue Jan 24, 2012 8:43 pm

Re: L3HW User Manual Updated

Wed Jul 14, 2021 6:24 pm

Will it be possible to use switch as PE device?
As a P router?
 
Railander
Frequent Visitor
Frequent Visitor
Posts: 85
Joined: Thu Jun 16, 2016 11:30 pm

Re: L3HW User Manual Updated

Wed Jul 21, 2021 7:18 am

  • pvid property of /in/br/port is mandatory. If you omit it, the default pvid=1 is used, meaning the port gets bridged with other ports with VLAN ID 1. We do not want this, so we explicitly set pvid=20.
  • Setting port's pvid leads to a dynamic vlan creation where the port is untagged by default. But we need port to be tagged, therefore we explicitly define /in/br/vlan entry for VLAN ID 20.
  • Port's pvid is not used for inter-VLAN routing. We offload vlan-id of /interface/vlan entry into the hardware routing table instead. So you are right that pvid could be theoretically omitted, but in reality, pvid is mandatory. So the rule of thumb is to set pvid to the same value as vlan-id. Or one of vlan-ids because multiple VLANs may be routed through a single trunk port.

Not directly related to L3 routing (hence off topic in this thread), but anyway: I always thought that setting port tagged member of VLAN (/in/br/vlan entry for VLAN ID) and setting PVID on bridge port (/in/br/port) makes possible mismatch: if frame-types is not set, then untagged frames are allowed and get tagged on ingress while on egress they are always transmitted tagged? Or did this behaviour change in ROS v7?
i agree.
i understand setting the port PVID is meant to segregate the physical ports (equivalent to no bridge whatsoever, or port isolation), but setting the port PVID to the same as what you're sending tagged is just bad practice.
ignoring untagged frames on the interface works, but you might actually want to do something with those frames so i think instead the best practice would be using a different PVID to what you're tagging out the port, so using their example
/interface/bridge/port add bridge=bridge interface=ether2 pvid=20
/interface/bridge/vlan add bridge=bridge tagged=bridge,ether2 vlan-ids=21
this accomplishes the same while IMO being good practice.
if you wanted to route with untagged frames on that port, you would just need to add another VLAN entry for that ID.
/interface/bridge/vlan add bridge=bridge tagged=bridge untagged=ether2 vlan-ids=20
 
Railander
Frequent Visitor
Frequent Visitor
Posts: 85
Joined: Thu Jun 16, 2016 11:30 pm

Re: L3HW User Manual Updated

Wed Jul 21, 2021 7:25 am

I still don't fully understand why PVID setting is mandatory in practice. @raimondsp writes that omitting to set it keeps the default setting of pvid=1 (which we already know very well), but the argument about bridging the port with other ports with pvid=1 seems moot to me if frame-types property is properly set (to admit-only-vlan-tagged) (in which case port won't pass untagged frames on ingress and in practice pvid membership doesn't matter much).
actually as i understand it, while disallowing untagged frames might make that port unable to talk to others it can still eavesdrop all other ports in that PVID (broadcast packets from other members would still be sent out untagged to it).
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11439
Joined: Thu Mar 03, 2016 10:23 pm

Re: L3HW User Manual Updated

Wed Jul 21, 2021 7:53 am

I still don't fully understand why PVID setting is mandatory in practice. @raimondsp writes that omitting to set it keeps the default setting of pvid=1 (which we already know very well), but the argument about bridging the port with other ports with pvid=1 seems moot to me if frame-types property is properly set (to admit-only-vlan-tagged) (in which case port won't pass untagged frames on ingress and in practice pvid membership doesn't matter much).
actually as i understand it, while disallowing untagged frames might make that port unable to talk to others it can still eavesdrop all other ports in that PVID (broadcast packets from other members would still be sent out untagged to it).
You're right. But in that case recommended practice would be to set PVID of each trunk (tagged only) port to a different value, but not one of VLAN IDs allowed as tagged.

Who is online

Users browsing this forum: No registered users and 16 guests