11-05-2023 01:25 AM
Hi.
I am wondering why the well-konwn discretionary may or may not be included in the update packets such as local preferences. Is this all about luck or have a rule?
Experts please help me here.
Solved! Go to Solution.
11-05-2023 06:28 AM - last edited on 11-07-2023 09:30 PM by Translator
If you configure a policy AFTER BGP has converged you will likely need to resend the updates. BGP doesnt send triggered updates when you change a policy (such as adding a LP to routes) towards or from a neighbor. You need to request or send the routes again so the new policy can be applied.
clear ip bgp *soft
or
clear ip bgp neighbor <ip> soft *
-David
11-05-2023 01:37 AM
Hello @Aoi,
In BGP, the inclusion of well-known discretionary attributes, such as the Local Preference, in update packets depends on the specific BGP implementation and the network's configuration. It's not a matter of luck; it's a conscious design choice made by network administrators and the BGP routers they use.
Well-known discretionary attributes are BGP attributes that are well-known, meaning that BGP routers are aware of them, but they are discretionary, meaning they are optional. Local Preference is one such attribute.
11-05-2023 05:48 AM - edited 11-05-2023 05:55 AM
The Path Attributes are Rules and well described in RFC4271 -updated BGP-4
Path attributes fall into four separate categories: 1. Well-known mandatory. 2. Well-known discretionary. 3. Optional transitive. 4. Optional non-transitive.
BGP implementations MUST recognize all well-known attributes. Some of these attributes are mandatory and MUST be included in every UPDATE message that contains NLRI. Others are discretionary and MAY or MAY NOT be sent in a particular UPDATE message. Once a BGP peer has updated any well-known attributes, it MUST pass these attributes to its peers in any updates it transmits. In addition to well-known attributes, each path MAY contain one or more optional attributes. It is not required or expected that all BGP implementations support all optional attributes. The handling of an unrecognized optional attribute is determined by the setting of the Transitive bit in the attribute flags octet. Paths with unrecognized transitive optional attributes SHOULD be accepted. If a path with an unrecognized transitive optional attribute is accepted and passed to other BGP peers, then the unrecognized transitive optional attribute of that path MUST be passed, along with the path, to other BGP peers
Also, Wendell Odom has published this summary in his CCIE RS v4 book
souce: CCIE routing and switching exam certification guide v4, CiscoPress, 2010
Regards, ML
**Please Rate All Helpful Responses **
11-05-2023 06:21 AM - edited 11-05-2023 06:22 AM
Thank you all. So what this means is a BGP implementation with local preference configured must transmit this “well known discretionary” to other peers. Because what I’m getting in my lab is not actually… sometimes the iBGP peers get the updated local preference values but most of the time I need to resend the updates manually.
11-05-2023 06:28 AM - last edited on 11-07-2023 09:30 PM by Translator
If you configure a policy AFTER BGP has converged you will likely need to resend the updates. BGP doesnt send triggered updates when you change a policy (such as adding a LP to routes) towards or from a neighbor. You need to request or send the routes again so the new policy can be applied.
clear ip bgp *soft
or
clear ip bgp neighbor <ip> soft *
-David
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide