Hello all,

I have two border routers running the latest routeros v7. Each connects to a different upstream provider (let's name them A and B) and gets the full internet routing table from its peer provider via eBGP. The two routers are also interconeccted to each other and they also exchange the full table via iBGP, for failover purposes. Therefore, each border router has two routes for each prefix in its main routing table: one directly via its upstream provider and via the other upstream provider which uses the other border router as nexthop.

On top of this, I also get (on both border routers) a summarized 0.0.0.0/0 route, also via eBGP, from a DDOS protection service provider, lets name it Z.

I want each router to prefer routing the outgoing traffic via Z AND the internet to prefer routing the incoming traffic to my AS via Z too. In case the DDOS provider is down, I want traffic to flow through A or B.

Since the summary default route from Z had the same distance as the more specific routes from A and B, the more specific ones were preferred over the generic one. To change this, I added a routing filter which chages the distance of the default Z route from the default 20 to 10. The problem is that the routers still send outgoing traffic via A and B instead of the shorted distance Z. What am I doing wrong?

See the attached images of the top of each router's routing table. Why are the iBGP-obtained routes shown as "unreachable" on the first router (top image)?

Thank you for any help, it will be greatly appreciated!

Anyone? Mikrotik staff?

The most-specific route will always be preferred. Isn't it?

This is supposed to happen if the two routes (the specific ang the generic) have the same distance. If the distance of the generic route is smaller, then it should be preferred, right? Am I wrong?

The most-specific route will always be preferred. Isn't it?

Distance is not the only factor. The scope and target-scope play a role & those are different in some of dynamic routes. See https://help.mikrotik.com/docs/display/ ... eSelection

Routes with a scope greater than the maximum accepted value are not used for next-hop lookup. Each route specifies the maximum accepted scope value for its nexthop in the target-scope property. The default value of this property allows nexthop lookup only through connected routes, with the exception of iBGP routes that have a larger default value and can lookup nexthop also through IGP and static routes.
Routes are processed in scope order, and updates to routes with a larger scope cannot affect the state of nexthop lookup for routes with a smaller scope.

/routing/route/print may offer a better view of what's going on.

Specificity always trumps almost anything else. If provider Z doesn't give you anything but the default route, then you'll need to filter out everything from the other providers except for the default route. With your use case, unless you're saturating one of your providers on outbound, slurping in all routes gives you no benefit. All you need is the default from each of the three providers and you're done.

In my case, I accept routes from my providers that are up to 2 AS's away, then use bgp-local-pref to provide a cascading order of preference for any overlapping/similar routes. If two providers provide an equidistant route to a particular prefix (including the default route), the one with the higher local-pref will be selected.

On the filter for the provider I prefer (in your case Z), I add this filter:

if (dst in 0.0.0.0/0 && dst-len == 0) { set bgp-local-pref 100; accept; }

On the filter for the other two providers, I have this:

if (dst in 0.0.0.0/0 && dst-len == 0) { set bgp-local-pref 95; accept; }

And this:

if (dst in 0.0.0.0/0 && dst-len == 0) { set bgp-local-pref 80; accept; }

Since internally they're using the same ASN and iBGP to speak to each other, local-pref is kept.

Specificity always trumps almost anything else. If provider Z doesn't give you anything but the default route, then you'll need to filter out everything from the other providers except for the default route. With your use case, unless you're saturating one of your providers on outbound, slurping in all routes gives you no benefit. All you need is the default from each of the three providers and you're done.

In my case, I accept routes from my providers that are up to 2 AS's away, then use bgp-local-pref to provide a cascading order of preference for any overlapping/similar routes. If two providers provide an equidistant route to a particular prefix (including the default route), the one with the higher local-pref will be selected.

On the filter for the provider I prefer (in your case Z), I add this filter:

if (dst in 0.0.0.0/0 && dst-len == 0) { set bgp-local-pref 100; accept; }

On the filter for the other two providers, I have this:

if (dst in 0.0.0.0/0 && dst-len == 0) { set bgp-local-pref 95; accept; }

And this:

if (dst in 0.0.0.0/0 && dst-len == 0) { set bgp-local-pref 80; accept; }

Since internally they're using the same ASN and iBGP to speak to each other, local-pref is kept.

Very enlightening answer, thank you so much! Can you also tell me if and how Select Rules (menu Routing/Filters/Select Rules) in v7 can be used to affect route selection? I looked into the documentation, but it is quite sparse on this.

I haven't dug into that myself. I'm still figuring out how to best leverage all these BGP knobs.

The skimpy docs on select-rule has come up before: viewtopic.php?t=206072&hilit=bgp+select

It can't hurt to open a ticket at support@mikrotik.com about the poor docs on BGP's select-rule. I'm not sure what is not covered by the V7 BGP filter language e.g. what can only be done in select-rule, since the BGP rules support jump and if.