vrf connected route leaking

RouterOS Forwarding Protocols
1

Hi,
I’m able to ping local interfaces which are assigned to different vrf’s of the mikrotik router (RB750 6.00rc11).
It is a problem in my case, because IP address which represents local interface in one vrf represents another host in the other vrf, however it is always routed to the local interface no matter what I do.
Is it “feature be desing” or is it a bug ? :open_mouth:

RouterOS v7.0 beta1 - when?
Traffic assigned to alternate routing table leaks to main table.
New router OS
2

this problem will be fixed in rc12

3

Hi mrz,

I am running rc12 and this problem still exists.

e.g. I create a loopback bridge, assign an IP address, add this interface to a VRF other than main, and I am still able to ping the loopback from the main table.

4

Hello guys.I also use the rci1 router but i am fully satisfy for the speed and its create no error..some time error occurred when you shared the net with another people at this situation IP is mix up and that why problem is occurred.Did you shared the net to the other person?

5

I’ve just also stumbled into the same problem. Traffic always goes to locally-assigned address, even if it is in a different routing table/VRF.

This is a serious issue as it causes problems when you have VRFs with overlapping IPs. Basically it makes MPLS L3VPN functionality of Mikrotik close to useless.

I found this explanation in Russian which explains the issue in detail: http://net-labs.in/2014/07/19/vrf-l3vpn-в-mikrotik-routeros-defective-by-design/

Any suggestions/advice is welcome. Verified on RouterOS 6.23, 6.19 and 5.22.

6

Is this issue fixed?

We are still experiencing leak between VRFs, when running L3VPN.

Tested on a CCR1036-8G-2S+:

  • RouterOS v6.30 (fw:3.24)
  • RouterOS v6.27 (fw:3.22)

Do please give some feedback!

7

See prev message.
This problem by design, mk promised fix design problem in 7.x
Waiting …

8

Thanks @resetsa.

I was wishing to see a Mikrotik member posting that confirmation.

So, all Mikrotik RouterOS products including the newest CCR1072-1G-8+ suffer of this “problem by design” well documented in that specific post in russian.

“the 0th rule PBR (0: from all lookup local) in older versions of the Linux kernel (<2.6.33) can not be removed, which limits the ability to implement VRF-s based on routing tables Linux, similar to Cisco, Juniper, etc.”

So if in a production environment and in need of a router that does VRF based L3VPN MPLS (no density to do VPLS) i might as well forget about Mikrotik products, is this correct? :confused:

Any Mikrotik Forum member wishes to comment on this? :confused:

9

RouterOS v7 will have completely isolated VRFs, unfortunately we cannot make these changes in ROS v6.

10

You can still use VRF based L3VPN on RouterOS v6.

The limitation is that you cannot have interfaces with overlapping ranges on the same router. So while 192.168.0.0/24 can existing in multiple L3VPN. It cannot exist on multiple interfaces on the same router and maintain isolation.

11

So if you make friends with 100.64.0.0/12 for transit and loopbacks then all your RFC1918 overlap problems go away :sunglasses:

However, from a security perspective, it will be nice to ensure complete isolation especially with Cisco getting a lot of press this year on a fairly recent VRF DDoS vulnerability in most IOS code. While not exactly the same thing it does highlight the need for increased security focus and testing when developing code for VRFs

Cisco VRF issue is here:

http://www.securityweek.com/cisco-fixes-dos-vulnerabilities-ios-software

12

Good idea, I never thought about that, we have always just used public IP’s from our APNIC allocation for our loopbacks and link nets so never had an issue.

13

Thanks! Since I started using the CGN space as an alternative to private IPs, i’ve noticed it in some larger networks as well,. Level3 MPLS handoffs use 100.64.x.x/30. However when working with Verizon for their MPLS interconnects, they re-use public IPs out of their ARIN range within customer VRFs.

I think either way is completely valid, I just tend to lean towards the CGN when designing a service provider MPLS network because it scales so well.

14

Thank you for the feedback @mrz

Is there any planned beta testing in the works? can we apply to it?

Thank you

15

Not yet, but v7beta is coming later this year

16

Thank you Normis for the feedback.

Mikrotik could have a beta testing program in the works for costumers willing to test v7.

We have plenty of units, especially CCR’s and we would like to test the full feature set of the L3VPN MPLS as soon as possible.

thanks once again.

17

We would also like to be involved in a v7 alpha / beta program. We have a large mikrotik lab with many different CCRs / routerboards and APs.

18

We are interested in testing v7 beta’s, we are happy to sign any required NDA and provide Mikrotik with remote access to test devices.

We have a fairly good size test lab as well with CCR1036, CCR1016, CCR1009, RB1200, RB1100AHx2, ASR1002, SRX240.

We can assist in testing:

BGP/OSPF/RIP
VRF
MPLS
L3VPN
L2VPN
IPv6
Any RADIUS attribute changes/additions

19

Hello Normis,
We are waiting for a long time to fix this issue. You promised to release the first beta version of microtik v7 two years ago. When can we expect full VRF functionality in mikrotik?
Thank you for your response.

Vitis

20

Are we there yet?