Я тоже сталкивался с проблемой, когда iBGP-сессии между несколькими MT-роутерами не устанавливаются, если заставить их (все) использовать нестандартную таблицу маршрутизации, отличную от main. То есть я вынуждаю сессии работать в таблице под названием backbone (к слову, я делаю это, потому что некоторые MT PPPoE AC тоже находятся в этом backbone, а завершение PPPoE-сессий не «знает» про VRF, поэтому приходится мириться с тем, что эти сессии оказываются в main (к сожалению, mangle prerouting, чтобы «перебросить» трафик PPPoE-сессий в другую таблицу, для моей задачи не подходит)).
Покапав трафик, поковыряв правила mangle output и сделав много исследований, я нашёл единственное приемлемое (и действительно чистое) решение — это настроить IP Route Rule, чтобы принудительно смотреть адреса BGP пиров через правильную альтернативную таблицу маршрутизации. Без этого пиры обмениваются TCP SYN на порту 179, но дальше обмен не идёт.
Я заметил, что проблема возникает только тогда, когда оба пира используют нестандартную (то есть не main) таблицу маршрутизации для сессий. В случае eBGP, если один пир работает через нестандартную таблицу, а другой — через main, IP Route Rules не нужны, и сессия устанавливается без проблем.
В нашем случае мы просто настроили простой универсальный Route Rule с «0.0.0.0/0 lookup table:backbone», что к тому же решает проблемы с некоторыми другими протоколами управления, не умеющими работать с VRF. Можно было бы задать и /32 правила точно для IP пиров BGP, если нужно только это.
Упрощённый пример конфигурации:
/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
На другом пире нужно зеркально прописать такие же Route Rule. Как и у других, у меня OSPF от этого бага никак не страдает.
Дальше углубляться времени не было, поэтому проблему BGP списываю на «мартовщину» MikroTik — не очень хорошую VRF-осведомлённость у некоторых протоколов управления и контрольной плоскости.
Надеюсь, кому-нибудь это когда-нибудь поможет!
