What you’re seeing is BGP working as intended, if each peer was a separate AS, the path-length would automatically filter out the longer paths. This doesn’t work if you’re doing things in a single iBGP AS.
If you want to only have traffic follow the direct hop and not fail over if that link is lost, you can filter the export to other nodes entirely with export route-maps.
If you don’t mind if it follows an alternate path but want to preference it towards the direct one within a single AS (or avoid out of order packets), have each receiving peer just adjust the local weight for inbound prefixes appropriately in an import route-map.
Adding the communities is reasonably easy (I usually use large communities, but anything goes here as long as you’re consistent):
If you’re learning the routes from an external peer, add to the upstream import route-map, in each rule matching the prefixes in question, something along the lines of:
routerA# set policy route-map RM-UPSTREAM-IN rule 10 set large-community add 65000:1:1
routerB# set policy route-map RM-UPSTREAM-IN rule 10 set large-community add 65000:1:2
routerC# set policy route-map RM-UPSTREAM-IN rule 10 set large-community add 65000:1:3
If they’re local, you can do this with a route-map in the network statement:
routerA# set policy route-map RM-ANNOUNCED-FROM-A rule 10 action permit
routerA# set policy route-map RM-ANNOUNCED-FROM-A rule 10 set large-community add 65000:1:1
routerA# set protocols bgp address-family ipv4-unicast network 192.168.10.0/24 route-map RM-ANNOUNCED-FROM-A
Be careful if you have aggregate-addresses, they can inconsistently clobber communities and I’ve had difficultly with FRR/VyOS applying communities in aggregate-address route-maps. In that case it’s easier to just filter or apply communities with prefix lists on the export.
For the first scenario, not passing through routes from the other 2 peers, setup an export route-map for the other 2 peers on each router that only allows through the local community string, and apply this to each internal peer link:
routerA# set policy large-community-list CM-ANNOUNCED-FROM-A rule 10 action permit
routerA# set policy large-community-list CM-ANNOUNCED-FROM-A rule 10 regex 65000:1:1
routerA# set policy route-map RM-INTERNAL-OUT rule 10 match large-community large-community-list CM-ANNOUNCED-FROM-A
routerA# set policy route-map RM-INTERNAL-OUT rule 10 action permit
For the second scenario, you do the selection on the import side, which requires a couple more community lists (one for each source) and an import RM for each peer, eg for the RM on routerB’s link to routerA:
routerB# set policy large-community-list CM-ANNOUNCED-FROM-A rule 10 action permit
routerB# set policy large-community-list CM-ANNOUNCED-FROM-A rule 10 regex 65000:1:1
routerB# set policy route-map RM-INTERNAL-A-IN rule 10 description "Accept direct prefixes at high weight"
routerB# set policy route-map RM-INTERNAL-A-IN rule 10 match large-community large-community-list CM-ANNOUNCED-FROM-A
routerB# set policy route-map RM-INTERNAL-A-IN rule 10 set weight 4000
routerB# set policy route-map RM-INTERNAL-A-IN rule 10 action permit
routerB# set policy route-map RM-INTERNAL-A-IN rule 20 description "Accept indirect prefixes at a lower weight"
routerB# set policy route-map RM-INTERNAL-A-IN rule 20 action permit
It does get a bit messy in a failover if there are multiple paths, none of them are preferenced at all, but at least a backup path remains in an outage. You may want to do some other things, like designating a few high-capacity/nearby peers to have slightly higher weights (below 4000, above default) so they end up being a “backbone” for failover traffic. The second scenario also doesn’t require a full mesh, with every node connected to every other node (other considerations apply).
Some of this might be wrong - I’ve done most of it in my head, but the logic should be about right. I’m pretty sure the default weight is 0 or 1, so 4000 should beat that. Distance only applies to the RIB and local-pref is shared across iBGP.
EDIT: Sorry - I’ve just realised I assumed that all 3 peers were in a mesh for your example, so some of this doesn’t apply. But, the examples still show how to tag and block the export of passed-through prefixes.