Community discussions

MikroTik App
 
admiralmcstabby
just joined
Topic Author
Posts: 8
Joined: Wed Apr 27, 2022 9:12 pm

Bridging Advice

Wed Apr 27, 2022 9:28 pm

Good afternoon all,

I (like I'm sure many members) come from a Cisco world and understand bridging in the CRS switches a little differently. I've been trying to understand how to properly manage VLANs within a bridge created but wanted to get some clarification on what it is I'm actually doing. For reference, I'm following the Basic VLAN Switching information on the MikroTik wiki.

1) When I am bridging ports inside a CRS1xx switch, am I simply grouping ports together, or are they actually being separated from the rest of the un-bridged ports?
2) Do I actually need to bridge ports when using them a switchports in a /interface/ethernet/switch perspective?
3) According to the wiki, I need to add the ports under /interface ethernet switch vlan *and* /interface ethernet switch ingress-vlan-translation, will the ports work as access ports just the same if I don't add them to /interface ethernet switch ingress-vlan-translation or is this a necessary configuration? I assume that if I'm not translating VLANs I can leave the second command out, but wanted to make sure.
4) I am (temporarily) connecting my WAN interfaces and LAN interfaces on the same switch (like I said, temporary) so my configuration will be Cable Modem-> Port 1, Firewall external -> Port2, Firewall internal -> Port 3, in the interim I want to make sure the WAN/LAN ports are as logically separated as possible...would putting them into different bridges help or would simply adding them to separate VLANs suffice? CAN I put them in different bridges and my design still work?

Sorry for all the questions but I really want to understand MikroTik and ultimately utilize their products over Cisco, but not without understanding MikroTik logic.

Thank you!
 
tdw
Forum Guru
Forum Guru
Posts: 1843
Joined: Sat May 05, 2018 11:55 am

Re: Bridging Advice  [SOLVED]

Thu Apr 28, 2022 2:52 am

Any port not in a bridge is in its own layer 2 broadcast domain, not connected to any other ports. The switch chip and linux network driver martial data between physical ports and the logical interfaces in the UI / CLI behind the scenes.

A group of ports added to a bridge operate in the same fashion as an unmanaged hardware switch, VLAN tags are treated as just another ethertype and passed to all ports (as drop-if-no-vlan-assignment-on-ports=none, drop-if-invalid-or-src-port-not-member-of-vlan-on-ports=none and forward-unknown-vlan=yes).

The CRS1xx/2xx devices do little to hide the complexities of the switch chip. The configuration sections pretty much program the switch chip verbatim, there is no simplified VLAN configuration where the complexities of the configuration would be hidden away, so you have to specify VLAN membership, untagged ingress translation (equivalent to the PVID with other vendors) and any tagged egress.
 
admiralmcstabby
just joined
Topic Author
Posts: 8
Joined: Wed Apr 27, 2022 9:12 pm

Re: Bridging Advice

Thu Apr 28, 2022 8:18 am

The CRS1xx/2xx devices do little to hide the complexities of the switch chip.
Now that I think about the extensive command-set, you hit the nail on the head! And in all honesty, while it may be harder to configure than other vendors, I do appreciate learning the "lower level" concept of switching. I would think it opens the door to more granularity, control and makes me look cooler to my other networking friends 8)

Thank you for the input, this greatly helped me understand what's going on and where my mindset needs to be for MikroTik devices.
 
tangent
Forum Guru
Forum Guru
Posts: 1351
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Bridging Advice

Thu Apr 28, 2022 8:38 am

When I am bridging ports inside a CRS1xx switch, am I simply grouping ports together, or are they actually being separated from the rest of the un-bridged ports?

According to this, you can have up to 7 isolated hardware bridges with that class of switch. There are, however, limitations imposed when doing that.

Do I actually need to bridge ports when using them a switchports in a /interface/ethernet/switch perspective?

If I understand your question correctly, you're asking if you need to configure bridging, or switching, or both? The answer is both, because some things are configured down at the switch chip level, and some are configured at the bridging level.

I believe the confusion arises because RouterOS tries to abstract such distinctions away, devolving to software bridging if the underlying switch chip can't handle multiple hardware bridges. Therefore, it wouldn't make sense to put some configuration items down at the "switch" level, even if your particular hardware does allow it to be hardware-offloaded.

It's a leaky abstraction, because there is often need for the one setting the device up to understand how the hardware functions in order to set it up properly. RouterOS will do its best to implement the design you specify, but it might have to do something in software even though it has a way to do it in hardware because you weren't knowledgeable enough to configure it properly.

Cable Modem-> Port 1, Firewall external -> Port2, Firewall internal -> Port 3

Why not modem → firewall → router → filtering proxy? (I assume that's the distinction between the external and internal "firewalls." If not, please clarify.) As it stands, it looks like you need two WAN IPs for this configuration, not the usual 1 for a small Internet NAT gateway setup.

would putting them into different bridges help

Quite possibly, but you might be able to have just one bridge for all LAN things and one un-bridged port for the WAN.

Beware that some things can only be done with a bridge in RouterOS, even with a single isolated port, so you might end up with 2-3 bridges anyway. Thus all the talk in that first link about checking the "H" flag.

adding them to separate VLANs suffice?

I think VLANs are often overused. If some isolation is good, more isolation must be better, right?

It seems to me that you have a clear separation of domains in this design already, so hardware separation should suffice. VLANs come into their own when you want to say things like "…and port 4 is on VLANs 52 and 39…" When each port is on just one logical LAN and router/firewall rules decide what propagates from one LAN to the other, I don't see any need for VLANs.
 
admiralmcstabby
just joined
Topic Author
Posts: 8
Joined: Wed Apr 27, 2022 9:12 pm

Re: Bridging Advice

Fri Apr 29, 2022 1:42 am

Tangent,

Incredible wealth of knowledge there! Thank you so much! To answer a couple of your questions:

If I understand your question correctly, you're asking if you need to configure bridging, or switching, or both? The answer is both, because some things are configured down at the switch chip level, and some are configured at the bridging level.
Yes, you understood correctly. I come from a primarly Cisco background and bridging isn't a feature on switches (well there are a couple commands that relate to bridging but never used on access level switches). The last time I heard of bridges it was in the context of an individual device that quite literally "bridged" two separate networks together (or separated CDs) so I was trying to wrap my head around the concept of bridging commands and their need at a access switch level, in MikroTik's environment. With Cisco switches, its enough to simply put ports in separate VLANs and be done with it, but from what you're telling me (and I interpreting it correctly) the ports need to be bridged first.

According to this, you can have up to 7 isolated hardware bridges with that class of switch. There are, however, limitations imposed when doing that.
Your first referenced link describes what I intended to deploy (as you mentioned, though ironically, "more isolation must be better") and I did take note of the potential limitations this could create in regards to performance, but after configuring three different bridges (one for WAN, LAN and DMZ) all of my ports still show HW as enabled (see below). I'm curious if this is accurate, am I reading this incorrectly or will it change when data starts traversing the CRS?
Screenshot 2022-04-28 122159.png

Why not modem → firewall → router → filtering proxy?
Normally I'd have a separate switch for my WAN connectivity, I have my modem in bridged mode or "pass-through" mode so my external IP address sits at the firewall. Furthermore, when you mentioned needing two external IP addresses I assume, you assume, I want an external IP on the switch? If so, that's not what I do. I simply have the modem/firewall connect through the switch so I can also have a second WAN IP (I also have a 4g LTE modem for backup as I provide some services for friends and want redundancy). Management of the switch would normally be through a dedicated mgmt port on a Cisco 3750X or Cisco 2960X, right now this won't be much of an issue since the switch will have connections internally as well, but I assume I'll have to put a dedicated port in a separate bridge when I get another CRS.

VLANs come into their own when you want to say things like "…and port 4 is on VLANs 52 and 39
You're correct, but also this is a habit of mine from the Cisco world. According to recommended security practices you never want to leave a port untagged (and change the Native VLAN from default VLAN 1) as this reduces the chances for VLAN hopping, which I don't think is a vulnerability that is commonly exploited but it's always stuck with me. Also, I do segregate things off via VLANs as I have VLANs for my servers (Plex, DNS, DHCP, PacketFence, etc) VLANs for "risky" but not necessarily DMZ worthy applications like my smart home equipment and more. I actually have about 7 VLANs lol. All of this would normally be routed by a VyOS router I had stood up when I was running my full network rack, but I am trying to create a "micro" sized network for electricity cost's sake while still maintaining most of what I had before. I am in the process of shopping for another dual NIC NUC for a router, in the meantime the firewall will do my routing (also not best practice but will suffice for now).


Again, thank you so much for the info...it was a lot of help!
You do not have the required permissions to view the files attached to this post.
 
tangent
Forum Guru
Forum Guru
Posts: 1351
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Bridging Advice

Fri Apr 29, 2022 2:42 am

Cisco background and bridging isn't a feature on switches (well there are a couple commands that relate to bridging but never used on access level switches)

I don't know IOS at any serious level, but a bit of web searching turned up this feature of IOS, which looks like what RouterOS calls software bridging. Hardware-offloaded bridging is simply doing this on the switch chip, rather than send everything down through the CPU.

The last time I heard of bridges it was in the context of an individual device that quite literally "bridged" two separate networks together (or separated CDs)

Yes, that's one use. Although such 2-interface hardware devices were more common when there were more incompatible LAN technologies in use (e.g. Ethernet to TokenRing bridge) they're still found as in WiFi to Ethernet bridges, or PowerLine to Ethernet bridges.

Then you have the software abstraction of that concept, as seen in VM hypervisors.

That is then further abstracted in the Linux kernel, from which RouterOS's use of the term comes.

These uses aren't incompatible. You can use a Linux kernel bridge to implement 2-port media translation bridges, VM hypervisor virtual-to-real network bridges, and virtual Ethernet switches.

the ports need to be bridged first.

If you want multiple ports in a single broadcast domain, yes.

However, one common situation on RouterOS is to have a single WAN uplink port that isn't in any bridge at all, because Ⓐ there is no need for a broadcast domain; and Ⓑ the underlying switch port supports only one hardware bridge, so you may get no benefit of putting the single WAN uplink port into a bridge; or Ⓒ it's a proper router, so all bridges are in software, so case B goes double.

That said, I warned above that some things can only be done in a bridge. Just last week, someone here wanted to do bridge VLAN filtering on the WAN side, which required a single-port bridge just to gain access to the RouterOS VLAN filtering features needed on that WAN uplink port. There is no "switch VLAN filtering" feature in RouterOS for what the other poster wanted: their desired feature is handled at the bridge level because it works for both hardware and software bridges.

after configuring three different bridges (one for WAN, LAN and DMZ) all of my ports still show HW as enabled

As expected, from the docs' claim that you can have up to 7 hardware bridges on your switch model.

Contrast something like an RB5009, which supports only one hardware bridge. That's fine, since it's often used in cases like above: single WAN uplink port, and everything else bridged together for the LAN. Even if you end up needing a software bridge on the WAN port, the collective throughput of that one port is low enough that a software bridge is likely to work at line rate, whereas the many other ports could in aggregate spam the CPU if it wasn't for bridge hardware offloading.

you never want to leave a port untagged (and change the Native VLAN from default VLAN 1) as this reduces the chances for VLAN hopping, which I don't think is a vulnerability that is commonly exploited but it's always stuck with me.

RouterOS also uses VLAN 1 as a kind of generic fall-back, so yes, if you're using VLANs for security isolation, none of the ports should use PVID 1.

Contrast VLANs used as lightweight routing, where the PVID 1 consideration doesn't come into it. You see this with ports intended to allow both untagged and tagged traffic so that traffic that knows where it needs to go can be pre-tagged and traffic that does not gets a sensible default VLAN tag. Here you're depending on the default PVID and good behavior among those that don't use that default to get a useful feature.

Example: You've got a public access port that puts untagged traffic onto the customer VLAN, but if someone plugs in an IP cam preconfigured with an 802.1q tag for the video VLAN, it goes over to the DVR instead. Port isolation doesn't enter into this sort of configuration: merely by one device's say-so, it got traffic onto the video VLAN instead of the customer VLAN.

Is this wrong? It depends on the security design and local IT policies. If it's a security cam and the DVR is intended as a tamper-proof record for law enforcement, it's probably not a smart idea. If instead the IP cam is for capturing events happening in that room, archived on the DVR, this design is likely not only harmless, but helpful, since it saves the need to pull a dedicated Ethernet drop to the room, merely so you can hard-tag it to the video VLAN.

One thing VLANs give you that physical LANs chained together do not is that a single port can be in multiple VLANs at once. That's not your use case: each group of bridged ports is non-overlapping. This is why I say that, as you've documented it so far, I don't see a need for VLANs in your configuration at all. The separate hardware bridges do the isolation for you, and traffic moves between them under control of routing rules.

If your use case is wider than that, then in those areas where VLAN isolation is all that's keeping your traffic on those shared ports from intermingling, you might have cause to think about PVID defaults and such.

I actually have about 7 VLANs lol.

My point is, with that CRS, you could just as well have 7 bridges instead. It's the same subnet scheme and the same firewall rules between subnets to control which bridge can talk to which other, but it's done at the port level, with each port in a single distinct subnet.

Until you find yourself needing to say that a given port is in 2+ subnets for some reason, VLANs aren't buying you anything extra over the same number of bridges.

I'll give you a counterexample: in your reply, you mentioned the possibility of adding a proper router to the CRS. (This is a good idea, by the way, since CRS1xx/2xx aren't great as WAN routers due to lack of CPU power.) If the CRS moves into a core network function, you might then have a trunk link from the CRS to the router, and you'd then want to use VLAN tags in firewall rules to say things like "the Plex VLAN can only talk to the entertainment system VLAN and to the Plex cloud," and "the guest VLAN can talk to anything on the Internet, but nothing on the LAN." That would be a good justification for VLANs over bridges.
 
donatoroman
newbie
Posts: 30
Joined: Tue Dec 07, 2021 9:03 pm

Re: Bridging Advice

Sun May 01, 2022 5:56 pm

One thing to note here is that, unless was changed very recently, l3 hardware offloading only works off the main bridge, not any additional custom bridges. I don't know if the CRS1xxx/2xxx supports it but CRS3xxx does for sure. This only becomes important if you need to do a lot of inter-vlan routing and need near line rate performance.
 
tangent
Forum Guru
Forum Guru
Posts: 1351
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Bridging Advice

Mon May 02, 2022 3:44 am

l3 hardware offloading only works off the main bridge

My read of the docs is that you’re conflating two separate facts: 1. CRS3xx support only one hardware bridge; and 2. L3HW offload requires a hardware bridge underneath. (Source)

Those facts should be independent. A switch chip which supports both L3HW and multiple bridges should allow L3HW on all. Should, I say; I have no direct experience to prove it.

By process of elimination, that leaves as candidates the new CRS504 and the CCR2xxx. Is there anyone reading this that’s willing to try it and see?

And if the MikroTik docs team is reading this, a table listing the hardware bridge limit of the various device families would be helpful. Currently that info is scattered through several sections.

I don't know if the CRS1xxx/2xxx supports it

Nope. Hence I repeat: within the limiting scope of the OP’s case, VLANs buy nothing over bridging.
 
User avatar
chechito
Forum Guru
Forum Guru
Posts: 2990
Joined: Sun Aug 24, 2014 3:14 am
Location: Bogota Colombia
Contact:

Re: Bridging Advice

Mon May 02, 2022 3:52 am

i think crs 1xx/2xx are almost legacy devices, no new development or features

all the focus is on crs 3xx and 5xx with chipsets from another vendor

Who is online

Users browsing this forum: No registered users and 43 guests