Well, what I meant by “Out-Of-Band” is a independent Network port which is hard-wired for management only can cannot be used for something else (e.g. routing or traffic processing).
OK, so dedicated ethernet rather than some other interface technology (USB, serial, etc.)
I admit, a dedicated management VLAN (over a dedicated VRF if possible) is an acceptable compromise in most deployments - including mine.
Abusing routing filters to insert the route into another table, rather than VRF would work too. Or just IP firewall filters.
According to your explanation (“eth10 socket -> switch chip #2 -> switch2-cpu interface -> ethernet driver -> logical ether10 interface”), this means that switched (not routed!) traffic from any port of switch 1 needs to go through the ASIC of SW1, then the ASIC of SW2 to get to a port of SW2. Therefore, in a high-traffic pair of ports should be keps on the same switch rather than split over both switches. Is that Correct?
From my understanding, this is somewhat different from switches were all ports are connected to a bus on the backplane whose max bandwidth is the half of the all port’s BW.
But on the other hand, the 3011 is definitely meant to be used as a router, so this “limitiation” is irrelevant, the traffic being processed by the CPU anyway in that case.
Yes, it is actually worse than that as inter-switch traffic passes through CPU interfaces - see
https://i.mt.lv/cdn/product_files/RB301 ... 160313.png. The RBxxxx devices with more than five ethernet ports all have this style of port expansion, as you say primarily intended to be a router rather than a switch. The CRSxxx have a more conventional wirespeed switch architecture plus a small CPU to provide some additional services, but not approaching anything like wirespeed.
My initial config with individual bridges was definitely not a good option. This was more to play with it and see how it behaved.
In my scenario, I thing the best is to simply have the L3 directly mapped to each physical interface.
There are various limititations/pitfalls, other than the CRS3xx devices having a vlan-aware bridge disables hardware switching so all of the physical port traffic is multiplexed back over the internal links to the CPU. It is possible to use a non-vlan-aware bridge, which behaves like an unmanaged switch, and then configure the switching directly. There are some additional caveats on devices with multiple switch chips as mentioned in one section of the link sent previously.
Your comment regarding the interface behaviour (the fact that the Mikrotik responds to the IP assigned to eth10 on ALL interfaces) is very interesting. But doesn’t that imply that all interfaces are switched with a sort of common uplink to the L3?
If so, that would mean that all devices connected on the mikrotik are able to communicate with each other on L2, which I see as a very bad thing. For instance, if you have a WAN and LAN segment that would share the same L2 broadcast domain and only be separated by their L3 addressing plan.
No. Using your example of eth9: 192.168.88.1/24 and eth10: 10.0.0.1/24 with no bridges, i.e. the addresses attached directly to the ports each in a L2 domain. If you have a device attached to eth10 with an address of 10.0.0.99/24 and a default gateway of 10.0.0.1 and ping 192.168.88.1 the device will forward the packet to 10.0.0.1 as it is not directly reachable. Despite being in a different subnet this is handled via the L3 input chain on the Mikrotik, not the L3 forward chain. The packet flow is described here
https://help.mikrotik.com/docs/display/ ... n+RouterOS