The L2 forwarding task is simple and thus easy to implement in hardware. L3 forwarding is equally simple, or maybe even simpler, if only routing per se is implemented in hardware. What makes L3 difficult for hardware implementation are the additional tasks, like dynamic updates of the routing tables, stateful firewall or even DPI, etc. So RouterOS (and other networking-oriented OSes as well) does what cannot be offloaded to HW in software and offloads whatever can be offloaded to hardware.
If you take a powerful machine and equip it with multiple networking cards, it won’t be possible to offload any of the packet forwarding tasks from the CPU, i.e. the CPU will have to see, and maybe manipulate (add/remove VLAN tag) the header of every single frame. So the total throughput on pure bridging (L2 forwarding) will require a very powerful CPU to match the one of a hardware switch. I.e. the “joules of electricity spent per forwarded frame” parameter is much better (lower) for a hardware switch.
Thanks for the valuable information. Yes started to use Webfig for the initial configuration, will slowly turn to commandline/ssh once I get the feel of RouterOS syntax.
Regarding the performance of the Switches and the Cheaper Vs Enterprise Switches, I always think of building a switch with the X86 servers. If this is good performance-wise, it will be better to build as powerful x86 CPU based switch. Moreover, if learned once, the same knowledge can be used to build the entire companies network switches. After all, when we are building Routers and Firewalls with the X86 based machines with Linux and FreeBSD based distributions, why can’t and should not we build our own switches with more capable CPUs?
Hardware machine oriented switches will not be too many in the given setup. After all I have 2-3 core switches in my network. Even if switching feature is not offloaded to the Chip in the custom machine, the CPU is much powerful to handle all the switching and L3 features by itself.
Regarding saving electricity, this we can done by virtualizing the entire switch machine and with the hardware NIC passthrough. That way Switch will be just one of the VM/Container running on the server.
The only issue that bothers me is whether this Switch will perform any lower and degraded than a hardware switch?
This is just a thought. May be we need to ponder more on it. Maybe some experiments that can be done to very the concept.
The number of switches is not that important, think rather about the number of the network cards on a single “handicrafted switch” and the bus throughput. When a frame arrives to one network interface, the network cards uses the bus bandwidth to store it into RAM, then it notifies the CPU about its presence in the RAM, the CPU inspects or modifies the header and then tells another NIC from where in RAM to fetch the frame and send it, again using the bus bandwidth.
This has nothing to do with how much energy you spend on handling a given frame. The number of CPU cycles required is the same or negligibly higher in case of a virtual machine as compared to a dedicated bare metal one. Virtualization is efficient where you have more resources than a single task requires so you can reuse these resources for other tasks as well; this does not seem to be the case here.
The bottlenecks are the bus throughput and the CPU power. So you can get “wirespeed” also this way, provided that you pour in enough CPU and keep the total amount of traffic on all the NICs below the total bandwidth of the bus.
The main difference between using a software based router (lets say VyOS) on a x86 vs a hardware offloaded one (lets say Mikrotik CRS326) is number of packets per second (which turns into bandwidth) along with latency.
Softwarebased routing will have a limit of approx >250kpps per core using interruptbased drivers and >1Mpps per core using pollingbased drivers (the later will also consume 100% CPU since you normally want idlepoll aswell).
While looking at CCR2216-1G-12XS-2XQ we can see from the testresults of Mikrotik that this one can push 284090 kpps which is ALOT more than most softwarebased routers can do.
Once you approach the upper limit of pps with softwarebased routers the latency will run away while with a hardwarebased router that will sustain lets say 0.1ms latency until it peaks at wirespeed (that is you cant physically put more packets into the interface per second because lets say a 100Gbps interface can only do 100Gbps (which means 200Gbps at full duplex to be processed).
So far now, I have CRS326 which I am trying to configure properly with hardware offloading. I am not into software based router for now at-least.
I have connected my router and fired-up winbox. In the RouterOS, it asked me to put the CRS326 in Router mode or Switch mode. I have selected the Switch Mode. I have not checked the option “Bridge all ports”.
I have assigned the IP in the core switches range and that’s how I am able to connect to the CRS326 with IP address.
Everywhere it’s pointed out to keep the management port (ethermet) out of the bridge. So I have removed it from the bridge from the GUI.
It is also suggested to keep one port out of the Bridge setup so that I can access the switch. How can I do that? When I moved one port out of the bridge, through which I was connected, I could not access the switch. Because I feel that the 10G port is not having an IP. It is the bridge which is having the IP, when I assigned the IP initially while configuring the device in Bridge mode.
Does the VLAN1, the management vlan in my case, is available only for bridge and not for the individual ports? I have not created any Vlans for now. When I moved the port 24 out of the Bridge, it should still be on Vlan1 and I should be able to connect to the switch. Why is the port 24 out of vlan 1.
Mikrotik device configuration is a hell of a task. Things don’t work the way they should.
Somebody please point what should I do. Where I am going wrong?
Use Winbox.
Winbox can connect not only by IP but also by MAC.
With it you can assign an IP address to that port, and then you will be able to access it via Webfig (browser).
The issue with many people here is that they usually skip the initial wizards and go straight to manual configuration, i.e. they are not familiar with what the wizards do. So it is critical that you did not switch from RouterOS to SwOS. Within RouterOS, the “bridge mode” and “router mode” should be just initial templates, so it should not be critical which one you have chosen, you can manually get to the same configuration regardless the initial template used. But SwOS is a different thing, much less features, different way of configuration, no routing.
To be able to help you, we have to start from a known point, so please go to the teminal window and issue the following command: /export file=some-nice-name
Once it finishes, download the file some-nice-name.rsc. It is a plaintext file, so remove any sensitive information from it (at the moment, that should only mean the serial number) and post the contents here between [code] and [/code] tags.
and 4. are about the same thing - before you start playing with vlan-filtering and the associated settings, it is better to remove one Ethernet interface from the membership in the bridge and attach some static IP address to it so that you could connect to it locally, using a PC configured into the same subnet or using Winbox login to MAC address. This is a generic advice regardless the device model, so it may seem redundant for a CRS, but again, I have no clue how the initial templates actually look like.
The VLAN namespace is only related to a single bridge. So if you create multiple bridges (which is something not many vendors support at the first place, so it may be an unfamiliar concept to you), you can have VLAN 1 on each of them, and the traffic from VLAN 1 on bridge A will not leak to VLAN 1 on bridge B. An interface that is not a member port of any bridge can only handle tagless frames unless you attach an /interface/vlan (in Cisco vernacular, a “subinterface”) to it, which then takes care about tagging and untagging the frames.
For a novice, indeed. However, “flexibility” and “simplicity” do not get along well.
They work the intended (by designers) way, which is not the same like the expected (by novice admins) way. Don’t worry, it just needs some practice to grasp the concepts. On a bare Linux, the possibility to create multiple bridges and set up totally unrelated VLANs with the same ID on different bridges exists as well.
VLAN 1 is being used as management vlan from the beginning in my existing setup. Changing it will require many changes and may risk in a downtime, hence I am continuing to use it.
I had attached the CRS326 to my existing setup and would like to configure it remotely. The IP address of CRS326 is being routed by my existing setup and is on different subnet. Hence, winbox cannot connect it by MAC address. I changed the connectivity to a different port and got the access. But my port 24 is out of bridge and i cant access switch through it.
There is no point in keeping that port out of bridge,if I cant access switch through it.
Should I give a different IP to the Interface 24 and on the same subnet as the bridge to access through it?
How to assign such an IP to that Interface, keeping the bridge IP intact, and access the switch through it?
As you wrote above - if you don’t have physical access to the interface you have put out of the bridge, or an independent remote access to it, there is no point in keeping it out of the bridge. If you can ask someone on site to connect the management port to an access port of a VLAN on another switch or to a port of some router that you could access remotely, it is worth considering, otherwise forget it and just do the changes one by one in “safe mode”, which automatically reverts all the changes made since you have activated it if the last change causes loss of the management connection.
I wonder whether an online session (teamviewer, anydesk etc.) would not be more helpful?
No reason to install third party software on your mgmt-stations when ssh and webfig will get the work done using a ssh-client and a webbrowser which most likely already exists on your mgmt-station.
I am on site and I have physical access to the switch. I have attached a fiber patch cord to the sfp-sfpplus23 port to my existing HP core-2 switch. I have assigned the IP address to the CRS326 through while I was in my initial configuration. I have moved ether1 which is the management port out of my bridge.I am able to connect to my switch through the sfp-sfpplus ports.
The RouterOS in the initial configuration as Bridge mode assigned the IP to the sfp-sfplus1 port. I have not connected any cable to the sfp-sfplu1 port, but still I am able to access my switch. I do not understand this.
My Management VLAN is VLAN 1 in my existing setup and so I want to access the switch by assigning IP of the switch to VLAN 1. Should I create VLAN 1 as I dont see default VLAN 1 existing on my CRS326.
In the default configuration, all ports of the bridge, including the virtual one that connects the functional block “bridge” to the functional block “router”, are configured as access ports to VLAN 1. Hence you do not need to create any interface for VLAN 1 - the frames belonging to VLAN 1 are available without a tag at the router interface named “bridge”. Attach the IP configuration directly to the “bridge” interface. This is similar to e.g. a Cisco router with a plug-in switch card.
There is no hurry as my existing HP Core Switches setup is intact and I am just dropping in Mikrotik CRS326 in the existing setup. I am learning the Mikrotik nuances step by step.
Meantime I have grabbed one TP-lInk 10G switch and have inserted it along with the HP Core Switches. Configuring TP-Link switch was like a charm. Could do that in 10 minutes without learning any new thing and with the fact that I was doing it for the first time.
Now this CRS326 is just being used to learn the RouterOS so that I can better use this gear.
If sfp-sfpplus1 is a member port of the bridge, attaching IP address to it works almost the same as attaching it to the bridge - it is an incorrect setup but it “somehow” works probably to allow migration from an “old” way of configuring hardware accelerated bridges to the “new” one.
What does /interface/bridge/port print where interface~“sfp” and /ip/route/print detail show?