In my network, i've got two PE (PR1 and PR2) routers each with a transit and some peering attached. They both connect to a core router (CR1) which in turn connects to multiple access routers (It advertises these a default).

Despite the transit on PR2 having a lower med, when all things are equal (Path length, local pref etc) routes are continually preferred toward PR1 - seemingly because it has a lower routerID or the BGP session has been up longer. I'd be expecting routes toward PR2 to be taking preference, when everything else is equal and the MED becomes the tie breaker.

As you can see here. Below is the output from my route collector (Sorry, but ROS7 is almost unusable for any type of bgp troubleshooting) which shows PR1 (.1) PR2 (.2) and the view of the CR1 (.3) at the end. You can clearly see PR2 there has a med of 0, and PR1 has a med of 10. The CR1 router is seeing the best path as the route with a med of 10.

On the CR1 box directly you can see both routes, with the one to PR2 being inactive (.21 as the next hop).

This seems to be the behavior for prefixes with multiple ASNs in the path at least.

However, if I pick a route i'm learning from a peer (With a single ASN in the path e.g. originated by the ASN I'm peering with), I can successfully move the active route between the two PR routers on the CR by modifying the MED. The specific context here is where I have the same external network connected via two Internet Exchanges, one into PR1 and one into PR2.

Worth noting that between the PR1, PR2 and CR1 this is iBGP route reflection (CR1 is the RR)

I noted in the route selection algo that MED is only considered for the left most ASN in the path - which confirms what I'm seeing above. Different to other router vendors which is a shame (Cisco and Juniper both compare MED for iBGP peers regardless of AS_PATH).

Is there a recommended way to overcome this? Allowing me to select the transit on the second router, when everything else is equal (e.g. use transit 1 when the AS_PATH is shorter - so simply changing LOCAL_PREF isn't a solution here since that'd ignore AS_PATH etc). Or do I really have to break the network, and make the connections between the PR and CR devices eBGP so MED is taken into consideration regardless of path - or be really crazy, and physically move the preferred transit to the lower routerID device

That is not entirely true. Cisco by default works similarly. You have to explicitly enable "bgp always-compare-med".

Read more here:
https://www.cisco.com/c/en/us/support/d ... p-med.html

RouterOS currently do not have such options to play with.

For now, I've made the router with the preferred transit have a lower routerID, which whilst a complete bodge has enabled mostly what I'm looking todo. Any plans to implement a Cisco like option, to allow the user to choose how MED works on iBGP, so it matches eBGP?

Is there a roadmap for BGP features I can read? The BGP support on these things is pretty lacking at times (To see received routes from a peer, or advertised routes and all of their attributes such as communities etc).

You already can see routes received by specific peer before and after filters and all the attributes. See /routing/route menu

Example? I don’t see communities or AS_PATH in there, even when specifying “detail”

Any roadmap for BGP features you can share? The forum is peppered with inconsistencies between V4 and V6, and eBGP vs iBGP - I’ve got mostly everything I want working, RTBH, Customer communities, RPKI - happy to document and share if that’s useful along with some of the issues I’ve found too.

I do not know why you cannot see bgp parameters unless those routes are not BGP routes"