Hi guys,
I have a CCR2116 with two VRFs, one for management and one for user traffic (no main routing table is being used). After this change everything works fine, but in System - Packages, when I click on “Check for updates” it says timeout.
I configured the VRF management in the IP DNS section, but it doesn’t work. Is there any solution from mikrotik to this limitation?
Best regards
The connections initiated by the router itself are generated without routing marks, except for features where this is configurable. This includes the built-in dns resolver, the upgrade checking/downloading and all other stuff.
Specifically, the vrf setting for dns assigns the listening (server-side) socket to the specified vrf. When the dns server needs to do recursive resolution, the connection for that is initiated, again, without routing marks.
The simplest solution to your problem is to use the “main” table as the management one. There’s no reason not to do so and it solves your problems.
The way to make another VRF work instead of main in these cases is to add an appropriate routing rule. This is sometimes useful, but in your case only achieves the same thing in a bit more convoluted way.
Thanks. I hope Mikrotik adds real support for MGMT VRF soon, it’s a must for larger networks
While better VRF support for certain features would be welcome, I don’t see what renaming “main” to something else would get you in terms of functionality. (And, as I said, using another VRF instead of main for management requires a single routing rule.)
… and are you going to post an example of this single rule?
(it may be useful to someone, or however it would be something good to know)
It really shouldn’t be used. There’s really no benefit. Just for educational purposes:
/routing rule
add action=lookup-only-in-table table=mgmt interface=lo routing-mark=main
So, it is not just a single firewall rule, you need also a MGMT table ( but maybe that already exists) a suitable route in it, a RoS version that exposes the lo loopback Interface and - I presume - a mangle rule to mark the connection.
A complex (and ugly) workaround, better than no workaround, of course, still …
Just no. First of all, I didn’t say it required a firewall rule, but a routing rule:
The question I answered specifically said:
and that
This means that the mgmt vrf (along with its routing table) and suitable routes already exist. This also indicates that the appropriate services were assigned to this mgmt vrf. Mangling in this case is simply not necessary.
So, yes, a single routing rule was needed. (Again, not that I would suggest using it: in these cases simply use the main table for management and vrfs for user traffic.)
My bad, I thought “routing” and wrote “firewall”.
But I still don’t understand the routing-mark=main, where does it come from?
Simple. If you look at a drop-down where you can select a routing mark to apply, you only have the defined routing tables available. Similarly, when you filter based on a routing mark (e.g. as a firewall matcher) there’s no option of “no-mark” like for packet-mark or connection-mark. This gives a clue as to the internal implementation.
“main” can simply be considered the default mark applied to packets generated by the router.
Ok, so packets generated by router (in #15 of the flowchart) get automatically a routing-mark of “main”, it makes sense. 
But the interface “lo”?
I get that DNS is somehow different from other router’s processes, but how does the packet get to #26?
With regard to the routing mark, it’s not that “main” gets assigned, but that actually not having any is equivalent to it being “main”.
Packets emitted by the router itself have the lo as their ingress interface (iif=0), this is the same test that is applied in #5 (just in a different context). These packets don’t actually go through #26 (of course they may, just not in general.)
For creating these sorts of rules you have to look into the details of the actual networking stack implementation. This is usually not something that users are really expected to mess with, these things are for the makers of these router/firewall systems (distributions, OSs, whatever you choose to name them.)
The different systems choose to approach this from different angles: some choose to place the router processes themselves in a non-default namespace, Mikrotik chooses (currently) the Linux default behavior, that the router (as a host) uses the main vrf, and if you want isolation, you should use another for isolated traffic. These solutions are roughly equivalent. (Again, I don’t dispute that for many specific services, Mikrotik’s vrf support could improve, but this is simply further work to be done, and not some inherent result of this design decision.)
Especially for older hardware-based routers, the data plane is done almost entirely in hardware, and the control plane in software, and for these, the separation of the control plane was a necessary design decision. This makes people think that this is somehow a fundamentally better approach, because the high powered stuff does it this way, when in fact they started doing this basically out of necessity (and of course later stayed with it.)
Maybe we can call it “implied” routing-mark, to “catch” a non-routing-marked packet we need to select routing-mark=main.
So, a DNS packet is generated in the “cloud” of router processes in the middle of the flowchart (#15), then it has a shortcut path (not shown in the flowchart) to loopback interface lo (#26) and from it there is another shortcut (as well not shown in the flowchart) that connects lo interface to outgoing packet (#27)?
All packets carry a routing mark. (Internally, fwmark, or part of the fwmark), the default is simply named “main” in Mikrotik’s interface. If you wish to call it “considered to be…”, “implied”, “assumed”, you’re free to do so.
The loopback interface is not involved. The packet is simply considered to come from the appropriate loopback interface for routing purposes. This is very useful.
Just as a (further) aside, in this, the appropriate loopback interface is the key, and actually I strongly suspect that this is the reason the loopback interfaces were exposed in the Mikrotik UI. When you don’t have vrfs, not having a loopback is just mildly irritating, but once you get into vrfs, it’s untenable.
I know that I am probably a PITA, but to (hopefully) understand things, I need to make my own mental maps, and giving (appropriate) names and adjectives to things is part of this mental map building.
So the interface=lo (which should IMHO be renamed to “in-interface” to make it understandable and similar to what is used in other parts of Ros) is a sort of “virtual” source, I do like the “considered to be” description, both for the routing-mark and for the interface.
So:
Basically yes. With the addition that loopbacks mostly become important when there is more than one.