BGP local pref announcement

RouterOS Forwarding Protocols
1

I’ve noticed in testing that the way local preference attribute is sent to peers depends on whether the prefix was learned through iBGP or eBGP. If the prefix is learned thorugh eBGP, the local pref is sent unaltered to iBGP peers as you would expect. However, if the prefix is learned from an iBGP peer (& route-reflector client), that prefix is passed on to other iBGP peers with a default local pref value. This seems counter-intuitive.

The test I have set up has a Cisco router as iBGP peer sending dummy prefixes to the MT-1 with a community value applied. MT-1 has a filter incoming from this peer, which looks for that community value and sets the local pref accordingly. This works as intended, and sure enough the local pref is set on those prefixes in the routing table. I have MT-2 configured as an iBGP peer (non-reflected) to MT-1, but it is receiving the local pref as default. In fact, MT-1 is sending the prefixes with a default LP.

Changing the Mikrotiks out for Cisco routers with the exact same filters configured sends the LP value correctly to all iBGP peers.

Is this a bug or is this how it is intended to work?

2 
/routing filter print
chain=bgp-ext-in bgp-communities=65000:65120 invert-match=no action=accept set-bgp-local-pref=120 set-bgp-prepend-path=""




/ip route print detail where bgp-local-pref=120    
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, 
B - blackhole, U - unreachable, P - prohibit 

 1 ADb  dst-address=31.13.90.0/24 gateway=195.66.x.69 gateway-status=195.66.x.69 recursive via 185.130.x.94 SFP1-1G-THN-LR2_gi0/0/1 
        distance=120 scope=40 target-scope=30 bgp-as-path="32934" bgp-local-pref=120 bgp-med=0 bgp-origin=igp 
        bgp-communities=65000:65120,no-export received-from=THN.LR2 

 2 ADb  dst-address=45.58.64.0/20 gateway=195.66.x.182 gateway-status=195.66.x.182 recursive via 185.130.x.94 SFP1-1G-THN-LR2_gi0/0/1 
        distance=120 scope=40 target-scope=30 bgp-as-path="19679" bgp-local-pref=120 bgp-med=0 bgp-origin=igp 
        bgp-communities=65000:65120,no-export received-from=THN.LR2 

 5 ADb  dst-address=45.58.70.0/24 gateway=195.66.x.182 gateway-status=195.66.x.182 recursive via 185.130.x.94 SFP1-1G-THN-LR2_gi0/0/1 
        distance=120 scope=40 target-scope=30 bgp-as-path="19679" bgp-local-pref=120 bgp-med=0 bgp-origin=igp 
        bgp-communities=65000:65120,no-export received-from=THN.LR2

So the filter is working, checks for community 65000:65120 and sets the local pref to 120.

/routing bgp advertisements print peer=THN.CR1 where local-pref=120      
PEER     PREFIX               NEXTHOP          AS-PATH                                                                     ORIGIN     LOCAL-PREF

/routing bgp advertisements print peer=THN.CR1 where local-pref=100
PEER     PREFIX               NEXTHOP          AS-PATH                                                                     ORIGIN     LOCAL-PREF
THN.CR1  45.58.64.0/24        195.66.x.182   19679                                                                       igp               100
THN.CR1  31.13.90.0/24        195.66.x.69    32934                                                                       igp               100
THN.CR1  45.58.70.0/24        195.66.x.182   19679                                                                       igp               100

Doesn’t pass this local pref on to iBGP peers. However, prefixes learned from eBGP peers do pass the local pref on correctly:

/routing bgp advertisements print peer=THN.CR2 where local-pref=200
PEER     PREFIX               NEXTHOP          AS-PATH                                                                                          ORIGIN     LOCAL-PREF
THN.CR2  185.130.x.54/32    10.255.254.10    65001,65007                                                                                      incomplete        200
3

Local pref attribute distribution is implemented exactly as described in RFC 4271


5.1.5. LOCAL_PREF

LOCAL_PREF is a well-known attribute that SHALL be included in all
UPDATE messages that a given BGP speaker sends to other internal
peers. A BGP speaker SHALL calculate the degree of preference for
each external route based on the locally-configured policy, and
include the degree of preference when advertising a route to its
internal peers. The higher degree of preference MUST be preferred.
A BGP speaker uses the degree of preference learned via LOCAL_PREF in
its Decision Process (see Section 9.1.1).

A BGP speaker MUST NOT include this attribute in UPDATE messages it
sends to external peers, except in the case of BGP Confederations
[RFC3065]. If it is contained in an UPDATE message that is received
from an external peer, then this attribute MUST be ignored by the
receiving speaker, except in the case of BGP Confederations
[RFC3065].

4

Hi, yes that’s how local pref works, if you want to set some priority at the router without passing that to the entire iBGP network, then you can use weight.