Hi there,

Is it possible to run bgp within a VRF similar to what you would see in a cisco with the address-family ipv4
If you have tried this before or have any pointers or information on whether or not this will work let me know.
From what i have tried, even after setting the routing table for the peering or even trying to add the VRF to the BGP instance for the VRF, the peering stays in connect
I can ping across the VRF with no issues just seems the BGP neighbourship will not come up

F.Y.I this is lab stuff mostly for research not anything to be used in production

Yes this works. I use it every day.

Make sure you set the instance to the correct routing-mark and the peer to the right instance

Hi nz_monkey,

I noticed a very common issue while doing this and managed to hack my way out of it although doesn't feel ideal.
The syn packet is received in the VRF but the response was being sent via the main routing table for some reason and not using the VRF which has the directly connected interface
In the end i had to add a mangle rule in the output chain forcing traffic destined to the remote BGP peer to be placed in the VRF routing table
This also required me to enable multi-hop on the BGP peer and everything started to work properly.

I see you mentioned you have this running without having to fiddle around with the mangle rule... I do have the instance to the correct routing-mark and the peer in the right instance
i'm curious how you got it working without the mangle rule i think i might be missing something.

You will need to create an instance and specify the router-id to be used for that instance and also the specify the vrf for that particular instance under the 'routing-table' parameter.
For the configuration of the peering, make sure to select the instance you created instead of the default.
Find below an example:

[admin@CLIENT] > routing bgp instance print detail
0 * name="default" as=ABCD router-id=0.0.0.0 redistribute-connected=yes redistribute-static=no redistribute-rip=no redistribute-ospf=no redistribute-other-bgp=no
out-filter="" client-to-client-reflection=no ignore-as-path-len=no routing-table=""

1 name="INTERNET-GH" as=ABCD router-id=192.168.2.2 redistribute-connected=no redistribute-static=no redistribute-rip=no redistribute-ospf=no
redistribute-other-bgp=no out-filter="" client-to-client-reflection=yes ignore-as-path-len=no routing-table=INTERNET

[admin@CLIENT] > routing bgp peer print detail
Flags: X - disabled, E - established
3 E name="access-sec" instance=INTERNET remote-address=192.168.2.2 remote-as=EFGH tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no
hold-time=3m ttl=255 in-filter=connected-in out-filter="" address-families=ip update-source=192.168.2.1 default-originate=never remove-private-as=no
as-override=no passive=no use-bfd=no

sidenote: you might also notice that you won't see the advertised prefixes in bgp advertisements as vrf advertised prefixes aren't shown there.

I too have been struggling with the issue of iBGP peer sessions not establishing between multiple MT routers when I force them (all) to use a non-default routing table other than main, i.e. I force the sessions into a table called backbone (incidentily, I'm doing this as some MT PPPoE ACs are on this backbone also, and the PPPoE session termination is not VRF aware, thus we have to settle for those sessions ending up in main (unfortunately mangle pre-routing to "shift" this PPPoE session traffic to another table doesn't help me for my use case)).

Having packet-captured, tinkered with output mangle rules, and researched extensively, the only viable (and actually clean) solution I found for this issue was to set IP Route Rule entries to force the lookup of BGP peer addresses via the correct alternative routing-table. Without this, the peers exchange TCP SYNs on 179, however they never progress beyond this state. I have observed that it is *only* a problem when both peers share a non-default (i.e. not main) routing table for the peering sessions; in an eBGP example, if one peer is using a non-default table and the other is using main, there is no need for any IP Route Rules and the peers establish without issue.

For our use case we're actually just defining a simple catch-all Route Rule of "0.0.0.0/0 lookup table:backbone" as this of course also takes care of issues with some other non-VRF aware management/control plane protocols. You could just specify /32 rules for the BGP peer IPs though if that is all that's required.

Stripped/simplified configuration example:
A mirrored Route Rule configuration on the other peer is required.

As others have also observed, OSPF appears to be unaffected by this quirk. I haven't had the time to look into this further, and am just putting the BGP issue down to a "MikroTik-ism" regarding VRF awareness of some management and control plane protocols.

Hope this helps someone else someday!

Might be a tad late but the loopback address isn't part of backbone in your compact config, which it needs, including any subnets that connect the routers.

For our use case we're actually just defining a simple catch-all Route Rule of "0.0.0.0/0 lookup table:backbone" as this of course also takes care of issues with some other non-VRF aware management/control plane protocols. You could just specify /32 rules for the BGP peer IPs though if that is all that's required.
...
Hope this helps someone else someday!

Thanks Tom, this has helped me a lot! I ran into the same issue with iBGP sessions not being established on version 6.40.4.

The "IP Route Rule" solves the problem.

Regards

Oliver

Well this is one of those cases where only after hours of troubleshooting and working out the problem was "wrong outbound interface for SYN in BGP connect" through packet capture I finally found this article! For me the output mangle rule fixed the problem (after trying various PBR solutions) and it certainly appears this is only an issue with packet marks and iBGP where both sides are in this situation. Even then it is not consistent however as I have one peer which is working correctly.
This bug needs resolving but at least we have a workaround.

praise to @tomranson

indeed the criteria: two MTs having both their BGP-peers in VRFs then you _must_ use the routing rule to do a forced lookup for the other BGP peer IP and then force the policy-route to be resolved via the specific routing-table.

I believe in version 7, MikroTik is using the native VRF capability of the Linux Kernel, so it will be interesting to see if this is resolved once BGP is released in the beta