I have a BGP route that has an incorrect immediate gateway
192.168.100.0/24 is supposed to route via 10.32.1.2 - I can ping 10.32.1.2
10.32.1.2 routes via 10.32.1.0/30 / gre-tunnel2 - this is correct and I can ping 10.32.2.1 (which is the GRE tunnel interface on the other end)
I cannot ping 192.168.19.1 and in the screenshot above its immediate gateway is 10.32.1.2%lte1 - this is incorrect.
What have I done wrong?
/routing bgp template
set default disabled=no router-id=10.32.2.2 routing-table=main
/routing bgp connection
add as=65530 disabled=no input.filter=bgp-chr-in local.address=10.32.2.2 \
.role=ibgp name=bgp1 output.filter-chain=bgp-ool-out .redistribute=\
connected remote.address=10.32.2.1/32 .as=65530 router-id=10.32.2.2 \
routing-table=main templates=default
/routing filter rule
add chain=bgp-ool-out disabled=no rule="if (dst==192.168.19.0/24) {accept}"
add chain=bgp-chr-in disabled=no rule=\
"if (dst==192.168.100.0/24) {accept}\
\nif (dst in 10.32.0.0/16) {accept}"
Can you make the Scope and Target Scope columns visible in the table too?
Yes, it’s as I expected. You can read more about nexthop lookup here: https://help.mikrotik.com/docs/spaces/ROS/pages/328084/IP+Routing#IPRouting-NexthopLookup
When looking for the next hop for the route with destination 192.168.100.0/24 gateway 10.32.1.2 (the one at the bottom of the screenshot), the router will only consider the possible routes with the scope value not greater than the target-scope value of the route (in this case 30).
The route with destination 10.32.1.0/30 gateway 10.32.2.1 while having a “better” destination (longer prefix) has scope value of 40 (which is default for BGP). That value is greater than 30, as a result, that route will not be used to determine the next hop.
The only acceptable candidate is the route with destination 0.0.0.0/0 gateway lte1 at the top of the table, because the destination is ok (whole IPv4 range) and the scope is low enough (30). That’s why the immediate gateway is listed as 10.32.1.2%lte1.
You might need to add a static route with lower scope to work around that.
Using BGP filters to set the scope target of the 192.168.100.0/24 to 40 resolves the issue for me. I figured I’d leave the 10.32.0.0/16 routes as standard and just increase the target scope on the 192.168.100.0/24 route. Not sure if this is the correct way to go about it.
