Community discussions

MikroTik App
 
User avatar
Eising
Member Candidate
Member Candidate
Topic Author
Posts: 272
Joined: Mon Oct 27, 2008 10:21 am
Location: Copenhagen, Denmark

MPLS feature request: Management VRF

Fri Nov 27, 2009 4:37 pm

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.
The road to hell is paved with good intentions.
 
User avatar
chapex
Member Candidate
Member Candidate
Posts: 137
Joined: Wed May 30, 2007 1:23 am

Re: MPLS feature request: Management VRF

Sat Nov 28, 2009 2:40 am

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)
Ubnet datacenter: bandwith transport
 
padmaramya
just joined
Posts: 1
Joined: Tue May 11, 2010 3:23 pm

Re: MPLS feature request: Management VRF

Tue May 11, 2010 3:26 pm

Could you please explain me this management VRF in detail with diagramatic representation
 
borec420
just joined
Posts: 1
Joined: Thu Jun 14, 2012 12:39 pm

Re: MPLS feature request: Management VRF

Tue Jun 19, 2012 2:13 pm

It would be very useful feature. Is there any progress? @mikrotik: Thinking someone about implement this feature to RouterOS?
 
LukasSVK
newbie
Posts: 40
Joined: Tue Dec 07, 2010 1:57 am
Location: Bratislava, Slovakia

Re: MPLS feature request: Management VRF

Sun Jul 01, 2012 4:44 am

+1, very useful and not only in MPLS. Now management/services isn't supported :-(
 
User avatar
nicktc
just joined
Posts: 13
Joined: Mon Mar 28, 2016 9:52 pm

Re: MPLS feature request: Management VRF

Thu Apr 14, 2016 7:55 pm

+1 (and, any workarounds?)
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 1842
Joined: Mon Jan 14, 2008 1:53 pm
Location: Straya
Contact:

Re: MPLS feature request: Management VRF

Fri Apr 15, 2016 2:54 pm

According to local legend, this feature will be available in RouterOS v7.
http://thebrotherswisp.com/ | Mikrotik MTCNA, MTCRE, MTCINE | Fortinet FTCNA, FCNSP, FCT | Extreme Networks ENA
 
Zorro
Long time Member
Long time Member
Posts: 676
Joined: Wed Apr 16, 2014 2:43 pm

Re: MPLS feature request: Management VRF

Tue May 17, 2016 6:19 am

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.
 
User avatar
doneware
Trainer
Trainer
Posts: 547
Joined: Mon Oct 08, 2012 8:39 pm
Location: Hungary

Re: MPLS feature request: Management VRF

Tue May 17, 2016 11:04 pm

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
#TR0359
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: MPLS feature request: Management VRF

Tue May 17, 2016 11:54 pm

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....
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 1842
Joined: Mon Jan 14, 2008 1:53 pm
Location: Straya
Contact:

Re: MPLS feature request: Management VRF

Wed May 18, 2016 12:10 pm

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.
http://thebrotherswisp.com/ | Mikrotik MTCNA, MTCRE, MTCINE | Fortinet FTCNA, FCNSP, FCT | Extreme Networks ENA
 
Zorro
Long time Member
Long time Member
Posts: 676
Joined: Wed Apr 16, 2014 2:43 pm

Re: MPLS feature request: Management VRF

Thu May 19, 2016 2:13 am

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.

Who is online

Users browsing this forum: idlemind, mandrade, samwarez and 199 guests