I have a MikroTik router configured as an edge router with two separate VRFs (vrf1 and vrf2). Each VRF is connected to a different client via eBGP. The goal is to exchange routes between these two VRFs locally within the same router.
Details:
Clients and VRFs:
Client 1 is connected to vrf1 and advertises the route 192.168.11.0/24 via eBGP.
Client 2 is connected to vrf2 and advertises the route 192.168.22.0/24 via eBGP.
Objective:
Make the route 192.168.11.0/24 from vrf1 accessible in vrf2.
Make the route 192.168.22.0/24 from vrf2 accessible in vrf1.
Configuration:
VRF Setup:
Two VRFs (vrf1 and vrf2) are configured and mapped to separate interfaces.
BGP Sessions:
eBGP sessions are established in vrf1 and vrf2 to receive routes from Client 1 and Client 2, respectively.
Route Distinguisher (RD) and Route Target (RT):
Unique RDs are configured for vrf1 and vrf2.
RTs are used for importing and exporting routes between the VRFs.
Route Exchange:
Routes from vrf1 are exported with an RT that is imported by vrf2.
Routes from vrf2 are exported with an RT that is imported by vrf1.
Problem:
Routes are being exchanged between the VRFs (i.e., the routes appear in the routing tables), but they do not work. Specifically, the immediate gateway field is empty for the leaked routes, and traffic does not flow as expected.
I am aware that a separate BGP session between VRFs is not required for route leaking, as the route import/export process is handled by the Route Distinguisher (RD) and Route Target (RT) configurations.
The issue I am facing is that while routes are successfully exchanged between VRFs (vrf1 and vrf2), these leaked routes are non-functional because the immediate gateway field is empty in the routing table. As a result, the router cannot forward traffic based on these routes.
Updated Problem Description:
Routes from vrf1 are visible in vrf2 and vice versa, indicating that route exchange is occurring as configured.
However, the leaked routes have an empty immediate gateway field, making them unusable for traffic forwarding.
The issue appears related to the next-hop resolution for these leaked routes.
Key Question:
What additional configuration or troubleshooting steps are required to resolve the empty immediate gateway field for routes leaked between VRFs?
Supporting Information:
My RD, RT, and BGP configurations follow the standard practices as per MikroTik documentation, and the problem persists despite these configurations.
Let me know if you need logs, debug outputs, or more detailed configuration snippets for further analysis.
Thank you for your prompt response regarding the issue with resolving BGP gateways in local VRF setups. As this functionality is critical for my MPLS deployment and requires BGP to configure routing based on communities, I am eager to test the upcoming fix in my specific scenario.
Would it be possible to provide early access to the beta version containing this fix? I can test it thoroughly in my environment and provide you with detailed feedback to help ensure the resolution works as expected.
Did you see the “H” marked on the leaked next-hop route to other VRF?
I could bet a beer that your issue is related to that!
AS you can check on the actual version of MikroTik documentation about L3 Hardware Offloading.
RouterOS do not know how to deal with VRFs with hardware offload.
Only the main routing table gets offloaded. If VRF is used together with L3HW and packets arrive on a switch port with l3-hw-offloading=yes, packets can be incorrectly routed through the main routing table. To avoid this, disable L3HW on needed switch ports or use ACL rules to redirect specific traffic to the CPU.
Maybe if you disable all the hardware offload on those boxes, you could reach where you want. But probably with mediocre performance.
I also saw de “y” on your routes.
Your scenario seems to be related to a L3VPN over MPLS. Right?
It is worth mentioning that RouterOS also does not support Hardware Offload of Encap/Decap (P.E. Router) of MPLS.
Not for L2VPN(VPLS) or even for a simple L3VPN.
P.S.1: They do not support that kind of hardware offload, but the switch-chips they use do support it. So is fair to conclude that it is a GAP of RouterOS.
P.S.2: Someone will appear on the following posts screaming about fast-path. Saying that Router RouterOS supports Fast-Path to MPLS P.E. Usually they can’t differ kernel-by-pass and hardware-offload.
I have been trying for MANY YEARS to use MPLS on MikroTik, and my recommendation is:
If you like to sleep and not be woken up in the middle of the night, do not let any RouterOS(v6 or v7) operate LDP or any other Label Exchange protocol with devices from other more consolidated vendors (Cisco, Juniper, Arista, Huawei, Nokia, Etc…).
If it is a “pure” RouterOS network, then the chance of it working well is reasonable… I have implemented some of those myself.
But if it needs to exchange labels via LDP, RSVP, or any other protocol with other vendors, RUN AWAY!
If you actually read OP you will see that it has nothing to do with label distribution protocols, there is zero need of such protocols in particular setup.
Also, there are no known problems with LDP interoperability with Cisco or other vendors. LDP is implemented according to RFC the same way as for other vendors. If you have a specific problem report a problem to support and don’t spread misinformation that LDP does not work with other vendors.
Yep! I have read… And I did no say that this problem was related to LDP.
I have said that it is probably related to a wrong behavior related to VRF and Hardware offload.
I just took the opportunity to share my ugly experience with MikroTik and MPLS. And advising a colleague to avoid missing nights of sleep.
About the tickets, I can send a list with several of those(including many before using Jira) that I had received answer like “by now, this is the expected behavior.”