Hi there, I have a feature request:
I would like to introduce the concept of a management VRF:
A management VRF allows you to use a separate routing-table for management. Access to ssh, winbox, telnet, whatever is only allowed within this VRF. Within an ISP environment this secures your main routing table, as this is the routing table that contains internet routes, thus your customer's internet traffic will pass through it. The management VRF will be the routing-table where all access to the router goes. Telnet, ssh, winbox, snmp, etc will only be listening to addresses on the VRF, as well as remote logging, ntp, etc.

I see this implemented in RouterOS like this:

1) Allow /ip service to have the keyword routing-table. So, I would be able to do the following:
/ip service set ssh routing-table=management. Then ssh will bind itself to interfaces within the management VRF. Default would be "main" to make it work without MPLS support.
2) Allow you to specify the @routingtable option globally, so you could do this:
/system logging target add name="my.nms.station" target=remote remote=192.168.255.13:514@management
alternatively a routing-table option here too.

I've seen this implemented on cisco's ASR-1000 routers and I believe it's a right way to secure MPLS networks that contains customer routes in the global table.

I hope you will implement this feature. If you have any questions, I'll be happy to elaborate.

Nice Eising. is a very interesting option, especially when working in a shared environment. Should be analyzed as to solve the scalability problems presented by this protocol (VRF)

Could you please explain me this management VRF in detail with diagramatic representation

It would be very useful feature. Is there any progress? @mikrotik: Thinking someone about implement this feature to RouterOS?

+1, very useful and not only in MPLS. Now management/services isn't supported

+1 (and, any workarounds?)

According to local legend, this feature will be available in RouterOS v7.

VRF isn't perfect/flawless and aimed for relatively "simple", compact/dumb purposes/configuration.
if you need something more flexible/manageable/elegant that not grow like behemoth over time in size and in resource consumption - PBR may be another option for you.
anyway, VRF do its job. maybe with MPLS in future ROS - too, yep.

It's maybe just me, but i think the routing protocols are as much important as the management itself.
so my approach is to have the global routing table to take care of those two.
everything else (user plane traffic, vrfs [if there's any]) can stay isolated as i do not want to have
users being able to access the network elements.

the management vrf idea evolved itself out from devices originally not being able to have isolated routing
tables. then you hade all the stuff (user plane, control plane, mgmt plane) in the same routing instance.
then routing table virtualisation came around in the early 2000s, so for a quick win everyone tried to hide
their mgmt access in there. the more elegant solution would have been putting everything else into isolated
instances, yes even the internet traffic. but that was tricky if-not-impossible with a big network consisting of
many (10s-100s) devices.

i assume you will run MPLS in the network, otherwise vrfs are not much of a fun. in this case you will need to hide your topology from everybody anyway. and this routing information (IGP, iBGP, LDP) will be always located in the GRT. and if you focus on security, you may not want to have any user related stuff there, which then makes it as the best place to put the management plane traffic into.

i'm not saying, that vrf-aware management plane is bad, actually you'll need a lot more anyway, each and every single tool/command you can use for communication/testing/whatsoever must be vrf aware. but there are more than one ways to do it. as always.

EDIT: if it's just about "near perfect" access control, you can have it by using ip firewall's input chain for controlling inbound traffic. nonetheless it will be a bit more complicated

It's maybe just me, but i think the routing protocols are as much important as the management itself.
so my approach is to have the global routing table to take care of those two.
everything else (user plane traffic, vrfs [if there's any]) can stay isolated as i do not want to have
users being able to access the network elements.

Interesting approach. I'd considered that as well, but somehow felt uncomfortable with the idea of placing a global BGP table into a VRF... but then I suppose if the network core/distribution layers ONLY have your own topology in them, and the PE routers use LSPs to reach the border routers, then the majority of devices won't even have a global routing table, so it makes much more sense in that regard.... hmmmmm.... (wheels turning)

But yeah, the tools and services on the host should definitely be vrf-aware. The inability to put a pppoe server into a VRF, for instance, has stymied many people's network designs here....

But yeah, the tools and services on the host should definitely be vrf-aware. The inability to put a pppoe server into a VRF, for instance, has stymied many people's network designs here....

+1

This is why we still have Cisco ASR's in our network!

We need to be able to run L2TP server in a VRF facing our wholesale providers (for security reasons), then when users connect to our L2TP concentrator we need RADIUS VSA's to place these connections in to another VRF.

VRF originally more like "simple/direct solution for small setup/companies" rather than silver/bullet, panacea :=)
and yeah, MPLS/VPLS evolution itself - make more sense/weigh to me too.
aswell as all this "ad-hoc" stuff, like HWMPLUS/802.11s, BATMAN v3/4/5, cjdns and few less popular options.
as for packing/bending global routing table(either over VRF or any other among popular) - most routers still lacking necesary HW resources for, sadly(and CCR scale not ideally, yet). as for endpoint securtity - using radius/diameter servers as backbone of(for auth. to verify 1/2/3-way auth against d-db) it quite usual and make sense, but L2TP for that itself - kinda overkill and generally 802.1x-2010 kinda enough.