(plugin-bgp-policy)= # BGP Routing Policies Plugin The **bgp.policy** plugin implements simple BGP routing policies : * Per-neighbor AS-path prepending, BGP link bandwidth, BGP local preference, BGP MED, and BGP weights * Default local preference You can also use this plugin to apply inbound and outbound [generic routing policies](generic-routing-policies) to EBGP neighbors. ```eval_rst .. contents:: Table of Contents :depth: 2 :local: :backlinks: none ``` (plugin-bgp-policy-attributes)= ## Supported BGP Attributes The plugin adds the following BGP link attributes: * **bgp.bandwidth** link attribute sets the BGP Link Bandwidth extended community. It can be an integer (in Mbps), in which case the Link Bandwidth community is attached to inbound EBGP updates[^BCP], a dictionary with **in** and **out** integer values if you want to set the Link Bandwidth community in both directions (or just on the outbound updates), or **auto** keyword if you're going to copy interface bandwidth into incoming EBGP updates[^PSV]. * **bgp.locpref** is an integer attribute that sets default local preference when applied to a node, or sets local preference on BGP updates received from an EBGP neighbor. * **bgp.med** is an integer attribute that sets the MED attribute on BGP updates sent to an EBGP neighbor. * **bgp.policy** is a dictionary that applies [predefined routing policies](generic-routing-policies) to inbound (**in**) or outbound (**out**) BGP updates. * **bgp.prepend** is a dictionary configuring outbound AS-path prepending. It can contain a **count** attribute (number of times the node AS is prepended) or a **path** attribute (the prepended AS-path as a string[^ASPS]) * **bgp.weight** is an integer attribute that sets per-neighbor weight. [^BCP]: _netlab_ configures network devices to propagate BGP Link Bandwidth extended community on IBGP sessions. The value advertised in IBGP updates is device-dependent and could be the value attached to the best path or the aggregate of EBGP values. [^PSV]: The allowed values are platform-dependent. For example, Arista EOS and FRR can set bandwidth values in both directions but cannot add interface bandwidth. In contrast, Cisco IOS/XE can only add interface bandwidth to incoming EBGP updates. [^ASPS]: You must quote a single AS number that you want to prepend with the **path** attribute; otherwise, the YAML parser treats it as an integer. It also adds the following node attributes: * **bgp.locpref** sets the default (node-wide) local preference * **bgp.aggregate** configures [BGP address aggregation](plugin-bgp-policy-aggregate) (route summarization). This attribute can also be applied to a node VRF definition. The following table describes where you could apply individual attributes: | BGP policy | Node | Interface | VRF | |------------|:----:|:---------:|:---:| | aggregate | ✅ | ❌ | ✅ | | bandwidth | ❌ | ✅ | ❌ | | locpref | ✅ | ✅ | ❌ | | med | ❌ | ✅ | ❌ | | policy | ❌ | ✅ | ❌ | | prepend | ❌ | ✅ | ❌ | | weight | ❌ | ✅ | ❌ | ## Platform Support The plugin implements BGP routing policies and individual BGP policy attributes on these devices: | Operating system | Routing
policies | Local
preference | MED | Weight | AS-path
prepend | Link
bandwidth | Address
Aggregation | |---------------------|:-:|:-:|:-:|:-:|:-:|:-:|:-:| | Arista EOS |✅ |✅ |✅ |✅|✅ |✅| ✅| | Aruba AOS-CX |✅ |✅ |✅ |✅|✅ | ❌ | ❌ | | Cisco IOSv/IOSvL2 |✅ |✅ |✅ |✅|✅ |✅[❗](caveats-iosv) |✅| | Cisco IOS-XE[^18v] |✅ |✅ |✅ |✅|✅ |✅[❗](caveats-iosv) |✅| | Cumulus Linux |✅ |✅ |✅ |✅|✅ |✅| ❌ | | Dell OS10 |❌ |✅ |✅ |✅| ❌ | ❌ |✅| | FRR |✅ |✅ |✅ |✅|✅ |✅| ✅| | Junos |✅ |✅ |✅ |✅|✅ | ❌ | ❌ | | Nokia SR Linux |✅ |✅ |✅ | ❌ | ❌ | ❌ | ❌ | | Nokia SR OS |✅ |✅ |✅ | ❌ | ❌ | ✅| ❌ | | VyOS |✅ |✅ |✅ | ❌ | ✅ | ❌ | ❌ | [^18v]: Includes Cisco CSR 1000v, Cisco Catalyst 8000v, Cisco IOS-on-Linux (IOL), and IOL Layer-2 image. ```{tip} See [BGP Policies Test Results](https://release.netlab.tools/_html/coverage.bgp.policy) for more details. ``` **Notes:** * Arista EOS and Aruba CX do not support node-level default local preference. Node-level **bgp.locpref** attribute (if specified) is thus applied to all interfaces that do not have an explicit **bgp.locpref** attribute. That might interfere with the **bgp.policy** interface attributes. ## Applying Routing Policies to EBGP Neighbors You can use **bgp.policy.in** and **bgp.policy.out** interface-level attributes to apply predefined global- or node-level [routing policies](generic-routing-policies) to EBGP sessions. The following lab topology contains a combination of these features: ``` defaults.device: frr module: [ bgp, routing ] plugin: [ bgp.policy ] routing.policy: set_locpref: locpref: 120 nodes: r1: bgp.as: 65000 r2: bgp.as: 65001 routing.policy: set_med: med: 20 links: - r1: bgp.policy.in: set_locpref r2: bgp.policy.out: set_med ``` **Notes:** * R1 uses **set_locpref** routing policy that is not defined on R1. The global **set_locpref** routing policy is copied into R1 node data. * R2 uses **set_med** routing policy that is defined locally. The above lab topology results in the following FRRouting device configuration on R1[^RCP]: [^RCP]: Only the relevant parts of the device configuration are displayed ``` router bgp 65000 bgp router-id 10.0.0.1 neighbor 10.1.0.2 remote-as 65001 neighbor 10.1.0.2 description r2 ! address-family ipv4 unicast network 10.0.0.1/32 neighbor 10.1.0.2 activate no neighbor 10.1.0.2 send-community extended neighbor 10.1.0.2 route-map set_locpref in exit-address-family exit ! route-map set_locpref permit 10 set local-preference 120 ``` ## Applying Individual Policy Attributes You could specify individual BGP policy attributes as interface-level attributes instead of defining and deploying a routing policy. This approach is probably easier to use in simple scenarios without route filters. The plugin's device-specific configuration templates try to apply as many BGP policy attributes as possible directly to EBGP neighbor sessions. For example, **bgp.weight** is usually applied directly to a **neighbor**, as illustrated by the following FRR configuration: ``` router bgp 65000 neighbor 10.1.0.2 remote-as 65100 neighbor 10.1.0.2 description r1 ! address-family ipv4 unicast neighbor 10.1.0.2 activate neighbor 10.1.0.2 weight 10 ``` Most other policy attributes have to be applied through a route map. The plugin device-specific configuration templates create per-neighbor maps using names unique to each EBGP session and apply those route maps to EBGP neighbors: ``` router bgp 65000 bgp default local-preference 37 neighbor 10.1.0.2 remote-as 65100 neighbor 10.1.0.2 description r1 neighbor 10.1.0.6 remote-as 65100 neighbor 10.1.0.6 description r1 ! address-family ipv4 unicast neighbor 10.1.0.2 route-map bp-r1-1-in in neighbor 10.1.0.2 route-map bp-r1-1-out out neighbor 10.1.0.6 activate neighbor 10.1.0.6 route-map bp-r1-2-out out ! route-map bp-r1-1-in permit 10 set local-preference 20 ! route-map bp-r1-1-out permit 10 set metric 101 ! route-map bp-r1-2-out permit 10 set metric 200 ``` ```{warning} * You cannot combine **‌bgp.policy** routing policies with individual policy attributes that require a route map. * Some devices use route maps to implement the device-wide **‌bgp.locpref** attribute. When combined with **‌bgp.policy** routing policies, these auto-generated route maps generate errors. ``` (plugin-bgp-policy-aggregate)= ## BGP Address Aggregation The BGP address aggregation (route summarization) is defined in the **bgp.aggregate** node/VRF attribute. It is a list of IPv4/IPv6 aggregate prefixes, either specified as a single prefix (string) or a dictionary with these attributes: * **ipv4**: Aggregated IPv4 prefix * **ipv6**: Aggregated IPv6 prefix * **summary_only** (bool): Do not advertise the more-specific prefixes * **attributes** (routing policy name): a [routing policy](generic-routing-policies) that sets the attributes of the aggregate prefix * **suppress_policy** (routing policy name): a [routing policy](generic-routing-policies) that matches the prefixes that should be suppressed. Example: the WAN edge router advertises two IPv4 and an IPv6 aggregate. One of the IPv4 aggregates has MED set to 73 and suppresses the advertisement of the more-specific prefixes: ``` nodes: wan_edge: module: [ bgp, vrf, routing ] bgp.as: 65000 bgp.aggregate: - 10.1.0.0/16 - 2001:db8:1001::/48 - ipv4: 10.2.0.0/16 summary_only: True attributes: med_73 routing.policy: med_73: - set.med: 73 ``` ## Sample Topologies The following topology illustrates a simple primary/backup scenario in which a CE-router uses weights and MED to select primary/backup uplinks. ``` --- defaults.device: frr module: [ bgp ] plugin: [ bgp.policy ] nodes: ce: bgp.as: 65000 pe: bgp.as: 65100 links: - ce: bgp.weight: 100 bgp.med: 50 pe: name: Primary uplink - ce: bgp.weight: 50 bgp.med: 100 pe: name: Backup uplink ``` The following topology illustrates AS-path prepending functionality. On the backup link, the CE router prepends its own AS three times, and on the primary link, it prepends another AS. ``` --- defaults.device: frr module: [ bgp ] plugin: [ bgp.policy ] nodes: ce: bgp.as: 65000 pe: bgp.as: 65100 links: - ce: bgp.prepend.path: "65123" pe: name: Primary uplink - ce: bgp.prepend.count: 3 pe: name: Backup uplink ```