You are talking about CCR2116 that is brute-force on CPU, right? How many of those? 20? 30?
I’m talking about thousands of CRS 3XX, and even some CRS5XX that uses Marvel Prestera, similar (some better, some worse) to the switch-chip of CCR2XXX.
What is happening with those devices by the lack of support of a trustable underlay/overlay methodology?
They are being replaced by devices from Huawei, Raisecom, Datacom, ZTE…
The switch-chip specs say it supports it.
There are other vendors that use the same switch-chips and reach those rates.
Those devices will never reach those rates on CPU-Based forwarding.
CRS3XX supports line-rate of simple label swapping based on hardware off-load (P.Router position), I tested it myself and I can attest it.
But if you use CRS3XX for encapsulating MPLS(PE position) L2VPN or L3VPN it becomes trash, limited by the CPU.
In a minimally respectable equipment architecture, nothing from DataPlane should go up to the CPU, and the CPU should be dedicated to ControlPlane. And that is what I’m asking for.
From my point of view, there are two distinct tasks.
Dataplane, where everything starts with properly supporting a VRF IP and VRF MAC scenario.
Control-Plane, involving LDP, Martini, Kompella, BGP-LU, BGP-LS, SR-MPLS, SRv6, VXLan, and all the flavors that are convenient.
If the first is done, the second is possible and maybe even “easy”.
If the first is not done, everything that is done in the second will be a workaround to try to make things work (who knows for how long).
Certainly going into the details of MPLS configurations for a specific environment is much more OFF-Topic than even I like to go.
So I suggest creating a specific thread for this in another forum topic.
I don’t know your environment, but some questions come to mind:
What’s going wrong with “/mpls ldp advertise-filter”?
How are you using “/mpls ldp accept-filter”?
A good hierarchical addressing plan makes this much easier.
I only thought it was appropriate to make this Off-Topic because this MPLS filtering methodology was “forgotten” in the change from ROSv6 to ROSv7.
How poor in resources and flexibility these filters are in RouterOS!?!
And this considering that the routing filtering syntax of ROSv7 is extremely powerful, I think this is a critical point to be addressed for future versions of RouterOS.
Have you ever imagined being able to use the same Address-Lists to filter LDP and OSPF (or ISIS) at the same time?
And what about filtering routes imported from FIB to LDP?
This is something that has haunted me in Mikrotik for a long time!
Well, it is also already quite some time ago that we were promised the capability to store received routes in an address list rather than (or in addition to) a routing table, presumably via a routing filter… that would also help in some special cases.
I not looked really since what exact version it stopped to work but in one moment i suddenly started to get thousands of LDP remote inactive mappings and after investigations i found that mpls adv filters just ignored i can consider that in 7.11 and ROS 6 filters works .
7.17 and 7,18 all versions not works.
Millions and millions of customers for MikroTik…? Perhaps over XYX period of time… I would look at your year over year growth, or lack of [With current direction of hardware and software]. Or are you contributing the “millions of customers” to 1:1 of hardware sales. Most of the hardware sold is through vendors and resellers; MikroTik doesnt sell direct to consumer - so how can you say this?
Need to again look at the revenue stream of consumer hardware [hAP - RouterOS home] and then segment the rest of the hardware to professional/enterprise. As others mentioned, with the sprawl of RouterOS – it doesnt make sense long term. Unifi is full steam ahead with their development this year on their software and improvements… what is MIkroTik doing?
RouterOS hAP – Use Mobile App [Works quite good] and a redesigned web interface
RouterOS Pro/Enterprise [there are already License levels…]. Full featured, more than 16Mb of flash storage… We would pay more for better hardware, the higher cost or licensing could be revenue stream to help develop and feed R&D.
I will do it with pleasure…
As soon as there are specific places where the MikroTik team really interacts as actively as here on new releases.
A place for official roadmap.
A place for known bugs.
And all this being done without lies or half-truths, and without wordplay and generic phrases like “improved stability” or “issue fixed”, without additional details.
I concur with you on this and your points. I feel MikroTik is too busy managing their Discord channel and taking feedback & suggestions from consumers, rather than professionals.
These reminders about “keeping this forum topic strictly related to this particular RouterOS release” miss the point: Many here do volunteer testing for MT, which is a commercial product. While many bugs are actually user’s configuration errors, there are still bugs that MT ignores, but that do exist. Together with incomplete release notes people then get aggrevated.
I would again like to propose to MT that you publish reference configurations which are ready-to-use and which can be replicated in a test lab of 5-20 routers. The MT test lab itself should use the reference configs too, and for every ROS release (including beta and RC) MT should publish for each reference configuration whether it works. Can be a few days later, but it would eliminate a lot of redundant testing if one knows that has been tested already, or what does not work.
Reference configurations would also serve as a basis for network designs. Because: How can I safely specify a MT network for a customer? For example… if I use MPLS over GRE, is it supported? probably yes. LDP filters? no they don´t work any more. MPLS over L2TP? maybe but not sure. LDP in general? Not sure, and I stopped testing. EoIP as a replacement for PW? Yes reliably. IPsec on L2TP? not sure anymore. MPLS on a VLAN interface? Hmm, some risk. But those guts feelings are not enough to provide a customer a reliable network design that will not break in ROS 8.0.
I am thankful for many features and possibilities of the ROS platform. Maybe there is a bit too much now for getting all to work. I am happy when they tell me “L2TP will not be supported any more for MPLS” - then I know.
Probably many of those examples are just special cases of the generic “there is so much flexibility in RouterOS configuration and usage that it is impossible to test everything”, and stuff that we see fail over time is not a hardwired “that is not supported (anymore)” but it is just something that failed due to some unrelated change or bugfix, and hasn’t been noticed by MikroTik.
Or has been noticed but no time has yet been spent to fix it.
It is surprising that some “simple” usages like running BGP over a partial mesh of redundant tunnels between branch routers has stopped working reliably in 7.16, but likely MikroTik focus much more on using BGP for a couple of full table internet feeds and never notice this during their in-house testing.
Like you, I would expect them to run regression testing on a (large) number of configurations, especially when they have been problematic before, but it looks like that testing has not very much coverage. And when you report issues, you have to be lucky to have it handled by someone who understands what is wrong and how to fix it (or have it fixed by another team member).
So some things just stop working and we can do little else than thinking “apparently no longer supported”…
Has anyone be able to fix the RX Error on CHR sfp port ?
Im running CHR on Proxmox, lasted 7.19 beta8 , SFP card is 82599ES, with PCI-Passthrough.
Everything works fine, except there’s a RX Error on the interface of sfp module ( i use 1G BIdi module 1310/1550 to connect to my isp)
Linkpeed is 1G fixed, i mean everything works just perfect except it’s thrown that RX Error,
I though the latest update has improvement for sfp stuffs, it turns out that it has been broken for years ( based on my search about RX Error in this forum)
Ah, so it’s only half broken. I’ll keep digging then.
(It transmits MCS 0-9 only for 1SS).
But this is not part of the standard, some clients might still not like it? No way to turn it off?
LE: I went through downgrades down to 7.13.5 and upgrades back to 7.19beta6, resetting everything, now it seems fine even on the beta. x.x
One thing I did notice, in 7.15.3 I saw this: Short Slot Time: In use (0x0531) while on all the other versions, it was: Short Slot Time: Not in use (0x1131), I don’t know what this is about.
What’s going on, beats me.
The interface loopback can be deleted kudos to the OP, to restore lo in my brief test you have to perform /system/reset-configuration no-defaults=yes this is not only for 7.19 i test this on 7.18 same bug