Recently RouterOS exposed the internal loopback interfaces.
The “lo” interface is the internal loopback related to main VRF.
And for each VRF that is added, RouterOS adds an interface called “VRF” that is actually an internal in Kernel loopback attached to the respective VRF.
My suggestion, with the objective of making the objects on the system more intuitive, is to change the standard of naming those interfaces.
In the cases of extra VRFs, the suggested standard is to prefix the name of the interface with an “lo.”.
Exemplifying:
vrf “customer-blue”, interface name “lo.customer-blue”
vrf “customer-red”, interface name “lo.customer-red
”vrf “transit-ntt”, interface name “lo.transit-ntt
”vrf “transit-cogent”, interface name “lo.transit-cogent”
P.S.: Other vendors use this standard, and it is very self-explanatory. Bringing intuitiveness to the system, even on more complex scenarios,
There is a complementary suggestion to the specific case of the default “main” VRF. To keep standard as the other named VRFs, the suggestion is to rename the VRF to “lo.main”
Exemplifying:
vrf “main”, interface name “lo.main”
Extra:
The naming Type of “lo” and “VRF” interfaces could be unified as “lo.vrf”, or something like this…
I’m convinced that on the road to EVPN (mac-vrf and type5 routes), and MPLS L3VPN with VRFs (v4 and v6), a change like that will make things easier for end users of RouterOS.
Just to make things a little bit more formal, i created a ticket on Jira: SUP-191607
I can understand their position if it's going to break a bunch of stuff in ROS, but it definitely would have been nice to have. Now we just have to create them on our own
What really scares me is that in 2025 they'll still have this immense difficulty adding or removing things.
That you'll have to hope for a new major to see simple changes.
And I'm not just talking about naming standardization.
MikroTik needs to rethink its development methodology to become more modular.
The kernel version they use and the impossibility of updating it (and I'm not talking about backporting) is already very scary.
I honestly believe this "no" had much more to do with the person submitting the suggestion than with the suggestion itself.
I've seen much more blatant standard breaches than this happening recently, and not a peep about it.
But... Using Hanlon's razor principle...
The only reasonable justification I can think of is concern about user scripts involving VRFs.
WRONG scripting strategies that use the loopback name as a variable instead of the VRF itself.
But just look at Normis's "kind" responses in the forum history about using incorrect logic in scripting and MikroTik's responsibility for it, and I would even rule out that reason as a barrier to this suggestion.
I'm not sure how changing default name "breaks" anything. And agree calling it a loopback makes sense.
I doubt that. I'm sometimes a critic, and they still do occasionally accept suggestions ;).
My take is two-fold:
MikroTik is trying to get to a long-term V7 release. And for that the rate of changes to configuration surface has to go down. And while I cannot think of any "breaking" change when talking about default naming, that does not mean one would not pop up. So I can see some caution to changing names.
IMO how VRFs are handled overall is rather haphazard in RouterOS config today, beyond just naming. My hope has MikroTik has bigger plans for VRFs to make them more "first class citizens" in RouterOS config, since it's not just naming of the loopbacks that make VRFs confusing. So perhaps that's part of the V8 plans.
I'm not really pro or con, but I'm wondering if there's something that I'm not seeing. Why is lo.whatever objectively better?
On Linux it's not exactly uncommon to name the lo the same as a vrf, and it follows a long tradition of overloading naming in different contexts when this cannot cause confusion. At least in networking.
It is not better or worse it is just different and somebody might not like it, but since there were no massive backlash of such naming during beta state there is no reason to believe that nobody likes it and naming is bad.
And now after more than a year just to change something for the sake of changing is not reasonable.
Exposed Lo interfaces exist since the beginning of year 2024, so rethorical question, if the naming is so bad where were you back then?
Now with EVPN, and if everything goes well with type 5 routes, we'll see how much noise will occur with the terrible methodology of creating bridges as if they were loopbacks.
Learning more about the software process overall and not just the software coding, and understanding business cases, leads one to conclude MT is not capable of being, nor should strive to be, whimsical. They do not stand around the table, deciding which users they intend on pissing off this month. We are already arrogant enough to think our recommended changes are the most important ones and should be implemented in the next version ( I still dont understand why mine are not already incuded ) but really, its next level narciccism to think they do not work on ideas due to the recommender.
Agree with what you said!
But I'd like to put this distorted expectation we've created with the biased methodology for evaluating Issues and suggestions that come in on an equal footing.
a. business case, will we recoup the cost of development, testing and potential added problems by adding enhancement X.
b. to answer a, one needs to know the level of complexity of said enhancement.
c. to answer a, what is the impact of said enhancement, high impact, low frequency or low impact high frequency etc and thus talking about value to end users
d. competitive edge or catch-up speaks about future sales.
e. Impact upon available (resources) to fix know bugs that need attention………
bugs are also ranked, must fix immediately (cve), must fix in next build (critical functionality), must fix when possible, ………….. never fix…… ( and they have their own impact and cost etc…..)
Comes down to $$$ (mostly being people), we should see prices drop dramatically when strods is replaced with AI.
and Normis looks like this………
There is probably a quick filter method to put bugs or enhancements into triage buckets (look at this week, this month, this year, never etc.). So no, there is no such thing as equal footing, each suggestion has to be
a. first understood ( from user opinion, to some sort of evaluated ‘truth’ - ( which may also entail finding the right evaluator to look at the issue first ))
b. triaged
c. reviewed within an assessed time frame.
Nowhere in this process is the originator a factor. I would say that the ability of the originator to communicate clearly, factually, and with a certain degree of knowledge, would certainly make the job of understanding the issue more completely/accurately and timely, would mean it gets triaged faster etc.( would explain why my input seems to take ages )
) but really, its next level narciccism to think they do not work on ideas due to the recommender.