[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-05。"],[],[],null,["# BGP route policies overview\n===========================\n\nThis guide is an overview to Cloud Router Border Gateway Protocol (BGP) route\npolicies.\n\nBGP route policies let you set rules to filter BGP routes or modify BGP\nroute attributes. You can apply BGP route policies to both inbound and outbound\nBGP routes. You use the Common Expression Language (CEL) to define the BGP route\npolicies to apply to your BGP routes.\n| **Note:** BGP route policies are not supported for [custom learned\n| routes](/network-connectivity/docs/router/concepts/custom-learned-routes). BGP route policies are only supported for routes learned directly from the BGP peer.\n\nYou can apply BGP route policies to learned routes or advertised routes on\nCloud Router for BGP sessions. BGP route policies are separate from\npolicy-based routes, which are applied to Virtual Private Cloud networks by assigning a\nnext-hop route that is based on a per-example source address, which isn't\nnecessarily based upon a destination address. For more information, see\n[Policy-based routes](/vpc/docs/policy-based-routes).\n\nWe recommend using BGP route policies within a test environment to verify your\nconfiguration prior to rolling your configuration out to your production\nenvironment.\n\nWhat are BGP route policies?\n----------------------------\n\nBGP route policies are defined as an ordered list of terms. Each term is\nevaluated in the order that you specify, and include both a condition and a\ncorresponding action for when a route matches that term. A particular BGP route\npolicy can be applied only in one direction, either inbound for learned routes,\nor outbound for advertised routes, but not both simultaneously. However, BGP\nroute policies can be applied to multiple BGP peers on Cloud Router.\n\nBGP route policies use cases\n----------------------------\n\nYou can use BGP route policies to control which BGP routes are accepted,\nrejected, or modified before the BGP routes are advertised to other BGP peers or\nimported to the VPC routing table.\n\nThe following are example use cases for BGP route policies:\n\n- **Modifying the best-preferred BGP route**: You can use BGP route policies to\n modify the best-preferred BGP route, which is helpful for influencing the\n path that traffic takes through a network. For example, you can use BGP route\n policies to help ensure that BGP routes from a particular peer are preferred\n over other BGP routes by changing the value of the BGP MED attribute.\n\n- **Filtering unwanted BGP routes**: You can use BGP route policies to filter\n unwanted learned routes, or to avoid advertising particular routes to BGP\n peers. This is useful to prevent routing loops or routes that send traffic\n through undesirable paths. For example, you can use BGP route policies to\n filter prefixes within a subnet.\n\n- **Meeting traffic engineering goals** : You can use BGP route policies to meet\n specific traffic engineering goals. To influence traffic distribution,\n prepend one or more values to a route's AS-PATH. For example, for a prefix\n `192.168.2.0/24`, Cloud Router learns the prefix from two peers but\n learns different AS-PATH values from each peer. So `peer1` might provide an\n AS-PATH value of `[1010]` and `peer2` might provide an AS-PATH value of\n `[2020]`. With BGP route policies, you can choose to add one or more values\n to the front of the AS-PATH value.\n\nHow BGP route policies are applied\n----------------------------------\n\nYou apply BGP route policies to BGP configurations on a Cloud Router.\nEach BGP peer has zero or more route import and export policies applied to it.\nImport route policies apply to inbound routes, and export route policies apply\nto outbound routes.\n\nThe following diagram shows route import policies for inbound routes, and\nroute export policies for outbound routes:\n[](/static/network-connectivity/docs/router/images/route-policy-import-export.svg) BGP import policy and export policy directions (click to enlarge).\n\nThe following describes the general rules that\nCloud Router follows when applying BGP route policies:\n\n- BGP route policies are evaluated in the order that you list.\n\n- Terms in each BGP route policy are evaluated in the order of specified\n priority.\n\n- Terms can modify BGP routes. A subsequent term can modify a BGP route made\n by a previous term.\n\n- Evaluation ends when a BGP route is accepted or dropped. BGP routes are\n accepted if all policies and terms are evaluated and the route isn't\n dropped.\n\n- Terms aren't evaluated twice for a route in a single exercise of a BGP route\n policy.\n\nBGP route policy evaluation defaults to fail open. In other words, routes that\naren't explicitly dropped are accepted during BGP route policy evaluation. You\ncan't change this behavior directly, but you can create a \"drop all\" policy that\nyou apply to your last peering, in effect creating a fail closed BGP route\npolicy.\n\nThe following diagram shows how a set of applied policies for a route is\nevaluated:\n[](/static/network-connectivity/docs/router/images/route-policy-process.svg) BGP route policy processing (click to enlarge).\n\nBGP communities and Cloud Router\n--------------------------------\n\nA community value is a 32-bit field divided into two 16-bit sections.\nConventionally, the first 16-bits of the value encode the autonomous system (AS)\nnumber of the network originating the community, but Cloud Router\ndoesn't enforce this convention. The second 16-bits of the value encode a unique\nnumber assigned by the originating AS.\n\nBGP route policies can match and act on standard BGP communities attributes.\nBGP route policies can't match or modify the extended communities attributes.\n\nThe Cloud Router route selection process doesn't use the BGP\ncommunities attribute on prefixes. For example, it doesn't honor the `NO_EXPORT`\nor the `NO_ADVERTISE` BGP communities.\n\nAfter BGP route policies are imported, Cloud Router drops BGP\ncommunities from learned routes, which means that Cloud Router doesn't\nre-advertise communities---that is, Cloud Router treats communities\nas a non-transitive attribute. BGP communities can only be used to influence\nCloud Router ingress match policies. You can add, remove, or replace\nBGP communities on advertised routes to influence what your peer router does.\n\nBecause Cloud Router doesn't recognize well-known communities, you\nmust use literal values for BGP well-known communities, such as `65535:65281`\nfor `NO_EXPORT` or `65535:65282` for `NO_ADVERTISE`.\n\nRelationships between BGP route policy resources\n------------------------------------------------\n\nEach Cloud Router maintains its own list of BGP peers and BGP route\npolicies. The list of BGP peers that belong to a particular\nCloud Router resource can reference BGP route policies by name.\n\nYou can create, modify, and delete BGP route policies as long as the parent\nCloud Router exists.\n\nInteractions with other Cloud Router features\n---------------------------------------------\n\nThe following sections describe how BGP route policies interact with other\nCloud Router features.\n\nCustom advertised routes\n: Export BGP route policies can drop or modify [custom advertised\n routes](/network-connectivity/docs/router/concepts/advertised-routes) before they're advertised\n to BGP peers. BGP route policies can't match or modify custom received routes.\n\nPrefix limits\n\n: The limit of prefixes that Cloud Router accepts from a peer is 5000.\n If a peer advertises more than 5000 prefixes, Cloud Router resets the\n BGP session.\n\n The prefix limit is applied to inbound routes before BGP route policies are\n applied, so using BGP route policies doesn't change this behavior.\n\nSubnets\n\n: Export BGP route policies can filter or modify [Virtual Private Cloud subnets](/vpc/docs/subnets)\n subnet routes before they're advertised to BGP peers.\n\nTransit routes\n\n: BGP route policies can modify transit routes.\n\n Cloud Router doesn't honor the behavior of the\n `NO_EXPORT` and `NO_ADVERTISED` BGP communities.\n\nWhat's next\n-----------\n\n- [Create BGP route policies](/network-connectivity/docs/router/how-to/bgp-route-policies/create-policies)"]]
