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?
Re: BGP local pref announcement
Code: Select all
/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=""Code: Select all
/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
Code: Select all
/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
Code: Select all
/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
Re: BGP local pref announcement
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].
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].
Re: BGP local pref announcement
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.
Who is online
Users browsing this forum: No registered users and 8 guests