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:
Code: Select all
/ip address
add address=10.1.254.1 comment=Loopback0 interface=lo0 network=10.1.254.1
/routing ospf instance
set [ find default=yes ] disabled=yes
add comment="Backbone instance" name=ospf1-backbone router-id=10.1.254.1 routing-table=backbone
/routing ospf area
add comment="Backbone area 0.0.0.0" instance=ospf1-backbone name=area0
/routing ospf interface
add authentication=md5 authentication-key="blahblah" comment="VLAN0900 Backbone" dead-interval=4s hello-interval=1s interface=vlan0900-lag1 network-type=broadcast priority=255 use-bfd=yes
add authentication=md5 authentication-key="blahblah" comment=Loopback0 interface=lo0 network-type=point-to-point passive=yes
/routing ospf network
add area=area0 comment="VLAN0900 Backbone" network=192.168.0.0/24
add area=area0 comment=Loopback0 network=10.1.254.1/32
/routing bgp instance
set default disabled=yes
add as=65500 client-to-client-reflection=no comment="AS65500" name=as65500 router-id=10.1.254.1 routing-table=backbone
/routing bgp peer
add comment="Peer 1" default-originate=if-installed instance=blah multihop=yes name=peer1 nexthop-choice=force-self remote-address=10.1.254.2 remote-as=65500 tcp-md5-key="blahblah" ttl=default update-source=lo0 use-bfd=yes
/ip route vrf
add interfaces=lo0,vlan0900-lag1 routing-mark=backbone
/ip route rule
add dst-address=0.0.0.0/0 table=backbone
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!