BGP¶
BGP is one of the Exterior Gateway Protocols and the de facto standard interdomain routing protocol. The latest BGP version is 4. BGP-4 is described in RFC 1771 and updated by RFC 4271. RFC 2858 adds multiprotocol support to BGP.
VyOS makes use of FRR and we would like to thank them for their effort!
Basic Concepts¶
Autonomous Systems¶
From RFC 1930:
An AS is a connected group of one or more IP prefixes run by one or more network operators which has a SINGLE and CLEARLY DEFINED routing policy.
Each AS has an identifying number associated with it called an ASN. This is a two octet value ranging in value from 1 to 65535. The AS numbers 64512 through 65535 are defined as private AS numbers. Private AS numbers must not be advertised on the global Internet. The 2-byte AS number range has been exhausted. 4-byte AS numbers are specified in RFC 6793, and provide a pool of 4294967296 AS numbers.
The ASN is one of the essential elements of BGP. BGP is a distance vector routing protocol, and the AS-Path framework provides distance vector metric and loop detection to BGP.
Address Families¶
Multiprotocol extensions enable BGP to carry routing information for multiple network layer protocols. BGP supports an Address Family Identifier (AFI) for IPv4 and IPv6.
Route Selection¶
The route selection process used by FRR’s BGP implementation uses the following decision criterion, starting at the top of the list and going towards the bottom until one of the factors can be used.
Weight check
Prefer higher local weight routes to lower routes.
Local preference check
Prefer higher local preference routes to lower.
Local route check
Prefer local routes (statics, aggregates, redistributed) to received routes.
AS path length check
Prefer shortest hop-count AS_PATHs.
Origin check
Prefer the lowest origin type route. That is, prefer IGP origin routes to EGP, to Incomplete routes.
MED check
Where routes with a MED were received from the same AS, prefer the route with the lowest MED.
External check
Prefer the route received from an external, eBGP peer over routes received from other types of peers.
IGP cost check
Prefer the route with the lower IGP cost.
Multi-path check
If multi-pathing is enabled, then check whether the routes not yet distinguished in preference may be considered equal. If
bgp bestpath as-path multipath-relaxis set, all such routes are considered equal, otherwise routes received via iBGP with identical AS_PATHs or routes received from eBGP neighbours in the same AS are considered equal.Already-selected external check
Where both routes were received from eBGP peers, then prefer the route which is already selected. Note that this check is not applied if
bgp bestpath compare-routeridis configured. This check can prevent some cases of oscillation.Router-ID check
Prefer the route with the lowest router-ID. If the route has an ORIGINATOR_ID attribute, through iBGP reflection, then that router ID is used, otherwise the router-ID of the peer the route was received from is used.
Cluster-List length check
The route with the shortest cluster-list length is used. The cluster-list reflects the iBGP reflection path the route has taken.
Peer address
Prefer the route received from the peer with the higher transport layer address, as a last-resort tie-breaker.
Capability Negotiation¶
When adding IPv6 routing information exchange feature to BGP. There were some proposals. IETF IDR adopted a proposal called Multiprotocol Extension for BGP. The specification is described in RFC 2283. The protocol does not define new protocols. It defines new attributes to existing BGP. When it is used exchanging IPv6 routing information it is called BGP-4+. When it is used for exchanging multicast routing information it is called MBGP.
bgpd supports Multiprotocol Extension for BGP. So if a remote peer supports the protocol, bgpd can exchange IPv6 and/or multicast routing information.
Traditional BGP did not have the feature to detect a remote peer’s capabilities, e.g. whether it can handle prefix types other than IPv4 unicast routes. This was a big problem using Multiprotocol Extension for BGP in an operational network. RFC 2842 adopted a feature called Capability Negotiation. bgpd use this Capability Negotiation to detect the remote peer’s capabilities. If a peer is only configured as an IPv4 unicast neighbor, bgpd does not send these Capability Negotiation packets (at least not unless other optional BGP features require capability negotiation).
By default, FRR will bring up peering with minimal common capability for the both sides. For example, if the local router has unicast and multicast capabilities and the remote router only has unicast capability the local router will establish the connection with unicast only capability. When there are no common capabilities, FRR sends Unsupported Capability error and then resets the connection.
BGP Router Configuration¶
First of all you must configure BGP router with the ASN. The AS number is an identifier for the autonomous system. The BGP protocol uses the AS number for detecting whether the BGP connection is internal or external. VyOS does not have a special command to start the BGP process. The BGP process starts when the first neighbor is configured.
Peers Configuration¶
Defining Peers¶
protocols
bgp <asn> command the connection will be denied.protocols
bgp <asn> command the connection will be denied.Capability Negotiation¶
Suppress sending Capability Negotiation as OPEN message optional parameter to the peer. This command only affects the peer is configured other than IPv4 unicast configuration.
When remote peer does not have capability negotiation feature, remote peer will not send any capabilities at all. In that case, bgp configures the peer with configured capabilities.
You may prefer locally configured capabilities more than the negotiated
capabilities even though remote peer sends capabilities. If the peer is
configured by override-capability, VyOS ignores received
capabilities then override negotiated capabilities with configured values.
Additionally you should keep in mind that this feature fundamentally disables the ability to use widely deployed BGP features. BGP unnumbered, hostname support, AS4, Addpath, Route Refresh, ORF, Dynamic Capabilities, and graceful restart.
This command forces strictly compare remote capabilities and local capabilities. If capabilities are different, send Unsupported Capability error then reset connection.
You may want to disable sending Capability Negotiation OPEN message
optional parameter to the peer when remote peer does not implement
Capability Negotiation. Please use disable-capability-negotiation
command to disable the feature.
Peer Parameters¶
This command accept incoming routes with AS path containing AS number with the same value as the current system AS. This is used when you want to use the same AS number in your sites, but you can’t connect them directly.
The number parameter (1-10) configures the amount of accepted occurences of the system AS number in AS path.
This command is only allowed for eBGP peers. It is not applicable for peer groups.
This command override AS number of the originating router with the local AS number.
Usually this configuration is used in PEs (Provider Edge) to replace the incoming customer AS number so the connected CE ( Customer Edge) can use the same AS number as the other customer sites. This allows customers of the provider network to use the same AS number across their sites.
This command is only allowed for eBGP peers.
This command removes the private ASN of routes that are advertised to the configured peer. It removes only private ASNs on routes advertised to EBGP peers.
If the AS-Path for the route has only private ASNs, the private ASNs are removed.
If the AS-Path for the route has a private ASN between public ASNs, it is assumed that this is a design choice, and the private ASN is not removed.
Changes in BGP policies require the BGP session to be cleared. Clearing has a large negative impact on network operations. Soft reconfiguration enables you to generate inbound updates from a neighbor, change and activate BGP policies without clearing the BGP session.
This command specifies that route updates received from this neighbor will be stored unmodified, regardless of the inbound policy. When inbound soft reconfiguration is enabled, the stored updates are processed by the new policy configuration to create new inbound updates.
Note
Storage of route updates uses memory. If you enable soft reconfiguration inbound for multiple neighbors, the amount of memory used can become significant.
ttl-security hops.Specify an alternate AS for this BGP process when interacting with the specified peer or peer group. With no modifiers, the specified local-as is prepended to the received AS_PATH when receiving routing updates from the peer, and prepended to the outgoing AS_PATH (after the process local AS) when transmitting local routes to the peer.
If the no-prepend attribute is specified, then the supplied
local-as is not prepended to the received AS_PATH.
If the replace-as attribute is specified, then only the supplied
local-as is prepended to the AS_PATH when transmitting local-route
updates to this peer.
Note
This command is only allowed for eBGP peers.
ebgp-multihop.Peer Groups¶
Peer groups are used to help improve scaling by generating the same update information to all members of a peer group. Note that this means that the routes generated by a member of a peer group will be sent back to that originating peer with the originator identifier attribute set to indicated the originating peer. All peers not associated with a specific peer group are treated as belonging to a default peer group, and will share updates.
This command defines a new peer group. You can specify to the group the same parameters that you can specify for specific neighbors.
Note
If you apply a parameter to an individual neighbor IP address, you override the action defined for a peer group that includes that IP address.
Network Advertisement Configuration¶
This command is used for advertising IPv4 or IPv6 networks.
Note
By default, the BGP prefix is advertised even if it’s not present in the routing table. This behaviour differs from the implementation of some vendors.
route-map you can inject the
default route to given neighbor only if the conditions in the route map are
met.Route Aggregation Configuration¶
Redistribution Configuration¶
General Configuration¶
Common parametrs¶
no-client-to-client-reflection command
to disable client-to-client reflection.Administrative Distance¶
Timers¶
Route Dampening¶
When a route fails, a routing update is sent to withdraw the route from the network’s routing tables. When the route is re-enabled, the change in availability is also advertised. A route that continually fails and returns requires a great deal of network traffic to update the network about the route’s status.
Route dampening wich described in RFC 2439 enables you to identify routes that repeatedly fail and return. If route dampening is enabled, an unstable route accumulates penalties each time the route fails and returns. If the accumulated penalties exceed a threshold, the route is no longer advertised. This is route suppression. Routes that have been suppressed are re-entered into the routing table only when the amount of their penalty falls below a threshold.
A penalty of 1000 is assessed each time the route fails. When the penalties reach a predefined threshold (suppress-value), the router stops advertising the route.
Once a route is assessed a penalty, the penalty is decreased by half each time a predefined amount of time elapses (half-life-time). When the accumulated penalties fall below a predefined threshold (reuse-value), the route is unsuppressed and added back into the BGP routing table.
No route is suppressed indefinitely. Maximum-suppress-time defines the maximum time a route can be suppressed before it is re-advertised.
Route Selection Configuration¶
Ensure that when comparing routes where both are equal on most metrics, including local-pref, AS_PATH length, IGP cost, MED, that the tie is broken based on router-ID.
If this option is enabled, then the already-selected check, where already selected eBGP routes are preferred, is skipped.
If a route has an ORIGINATOR_ID attribute because it has been reflected, that ORIGINATOR_ID will be used. Otherwise, the router-ID of the peer the route was received from will be used.
The advantage of this is that the route-selection (at this point) will be more deterministic. The disadvantage is that a few or even one lowest-ID router may attract all traffic to otherwise-equal paths because of this check. It may increase the possibility of MED or IGP oscillation, unless other measures were taken to avoid these. The exact behaviour will be sensitive to the iBGP and reflection topology.
Route Filtering Configuration¶
In order to control and modify routing information that is exchanged between peers you can use route-map, filter-list, prefix-list, distribute-list.
For inbound updates the order of preference is:
- route-map
- filter-list
- prefix-list, distribute-list
For outbound updates the order of preference is:
- prefix-list, distribute-list
- filter-list
- route-map
Note
The attributes
prefix-listanddistribute-listare mutually exclusive, and only one command (distribute-list or prefix-list) can be applied to each inbound or outbound direction for a particular neighbor.
export and import
specify the direction in which the access list are applied.export and import
specify the direction in which the prefix list are applied.export and import
specify the direction in which the route map are applied.export and import
specify the direction in which the AS path access list are applied.receive keyword configures a router to advertise ORF
receive capabilities. The send keyword configures a router to
advertise ORF send capabilities. To advertise a filter from a sender, you
must create an IP prefix list for the specified BGP peer applied in inbound
derection.BGP Scaling Configuration¶
BGP routers connected inside the same AS through BGP belong to an internal BGP session, or IBGP. In order to prevent routing table loops, IBGP speaker does not advertise IBGP-learned routes to other IBGP speaker (Split Horizon mechanism). As such, IBGP requires a full mesh of all peers. For large networks, this quickly becomes unscalable.
There are two ways that help us to mitigate the BGPs full-mesh requirement in a network:
- Using BGP route-reflectors
- Using BGP confederation
Route Reflector Configuration¶
Introducing route reflectors removes the need for the full-mesh. When you configure a route reflector you have to tell the router whether the other IBGP router is a client or non-client. A client is an IBGP router that the route reflector will “reflect” routes to, the non-client is just a regular IBGP neighbor. Route reflectors mechanism is described in RFC 4456 and updated by RFC 7606.
Confederation Configuration¶
A BGP confederation divides our AS into sub-ASes to reduce the number of required IBGP peerings. Within a sub-AS we still require full-mesh IBGP but between these sub-ASes we use something that looks like EBGP but behaves like IBGP (called confederation BGP). Confederation mechanism is described in RFC 5065
Operational Mode Commands¶
Show¶
BGP table version is 10, local router ID is 10.0.35.3, vrf id 0
Default local pref 100, local AS 65000
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 198.51.100.0/24 10.0.34.4 0 0 65004 i
*> 203.0.113.0/24 10.0.35.5 0 0 65005 i
Displayed 2 routes and 2 total paths
BGP routing table entry for 198.51.100.0/24
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
10.0.13.1 10.0.23.2 10.0.34.4 10.0.35.5
65004
10.0.34.4 from 10.0.34.4 (10.0.34.4)
Origin IGP, metric 0, valid, external, best (First path received)
Last update: Wed Jan 6 12:18:53 2021
IPv4 Unicast Summary:
BGP router identifier 10.0.35.3, local AS number 65000 vrf-id 0
BGP table version 11
RIB entries 5, using 920 bytes of memory
Peers 4, using 82 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.13.1 4 65000 148 159 0 0 0 02:16:01 0
10.0.23.2 4 65000 136 143 0 0 0 02:13:21 0
10.0.34.4 4 65004 161 163 0 0 0 02:16:01 1
10.0.35.5 4 65005 162 166 0 0 0 02:16:01 1
Total number of neighbors 4
Reset¶
soft this command initiates a soft reset. If
you do not specify the in or out options, both
inbound and outbound soft reconfiguration are triggered.Configuration Examples¶
IPv4¶
A simple eBGP configuration:
Node 1:
set protocols bgp 65534 neighbor 192.168.0.2 ebgp-multihop '2'
set protocols bgp 65534 neighbor 192.168.0.2 remote-as '65535'
set protocols bgp 65534 neighbor 192.168.0.2 update-source '192.168.0.1'
set protocols bgp 65534 address-family ipv4-unicast network '172.16.0.0/16'
set protocols bgp 65534 parameters router-id '192.168.0.1'
Node 2:
set protocols bgp 65535 neighbor 192.168.0.1 ebgp-multihop '2'
set protocols bgp 65535 neighbor 192.168.0.1 remote-as '65534'
set protocols bgp 65535 neighbor 192.168.0.1 update-source '192.168.0.2'
set protocols bgp 65535 address-family ipv4-unicast network '172.17.0.0/16'
set protocols bgp 65535 parameters router-id '192.168.0.2'
Don’t forget, the CIDR declared in the network statement MUST exist in your routing table (dynamic or static), the best way to make sure that is true is creating a static route:
Node 1:
set protocols static route 172.16.0.0/16 blackhole distance '254'
Node 2:
set protocols static route 172.17.0.0/16 blackhole distance '254'
IPv6¶
A simple BGP configuration via IPv6.
Node 1:
set protocols bgp 65534 neighbor 2001:db8::2 ebgp-multihop '2'
set protocols bgp 65534 neighbor 2001:db8::2 remote-as '65535'
set protocols bgp 65534 neighbor 2001:db8::2 update-source '2001:db8::1'
set protocols bgp 65534 neighbor 2001:db8::2 address-family ipv6-unicast
set protocols bgp 65534 address-family ipv6-unicast network '2001:db8:1::/48'
set protocols bgp 65534 parameters router-id '10.1.1.1'
Node 2:
set protocols bgp 65535 neighbor 2001:db8::1 ebgp-multihop '2'
set protocols bgp 65535 neighbor 2001:db8::1 remote-as '65534'
set protocols bgp 65535 neighbor 2001:db8::1 update-source '2001:db8::2'
set protocols bgp 65535 neighbor 2001:db8::1 address-family ipv6-unicast
set protocols bgp 65535 address-family ipv6-unicast network '2001:db8:2::/48'
set protocols bgp 65535 parameters router-id '10.1.1.2'
Don’t forget, the CIDR declared in the network statement MUST exist in your routing table (dynamic or static), the best way to make sure that is true is creating a static route:
Node 1:
set protocols static route6 2001:db8:1::/48 blackhole distance '254'
Node 2:
set protocols static route6 2001:db8:2::/48 blackhole distance '254'
Route Filter¶
Route filter can be applied using a route-map:
Node1:
set policy prefix-list AS65535-IN rule 10 action 'permit'
set policy prefix-list AS65535-IN rule 10 prefix '172.16.0.0/16'
set policy prefix-list AS65535-OUT rule 10 action 'deny'
set policy prefix-list AS65535-OUT rule 10 prefix '172.16.0.0/16'
set policy prefix-list6 AS65535-IN rule 10 action 'permit'
set policy prefix-list6 AS65535-IN rule 10 prefix '2001:db8:2::/48'
set policy prefix-list6 AS65535-OUT rule 10 action 'deny'
set policy prefix-list6 AS65535-OUT rule 10 prefix '2001:db8:2::/48'
set policy route-map AS65535-IN rule 10 action 'permit'
set policy route-map AS65535-IN rule 10 match ip address prefix-list 'AS65535-IN'
set policy route-map AS65535-IN rule 10 match ipv6 address prefix-list 'AS65535-IN'
set policy route-map AS65535-IN rule 20 action 'deny'
set policy route-map AS65535-OUT rule 10 action 'deny'
set policy route-map AS65535-OUT rule 10 match ip address prefix-list 'AS65535-OUT'
set policy route-map AS65535-OUT rule 10 match ipv6 address prefix-list 'AS65535-OUT'
set policy route-map AS65535-OUT rule 20 action 'permit'
set protocols bgp 65534 neighbor 2001:db8::2 address-family ipv4-unicast route-map export 'AS65535-OUT'
set protocols bgp 65534 neighbor 2001:db8::2 address-family ipv4-unicast route-map import 'AS65535-IN'
set protocols bgp 65534 neighbor 2001:db8::2 address-family ipv6-unicast route-map export 'AS65535-OUT'
set protocols bgp 65534 neighbor 2001:db8::2 address-family ipv6-unicast route-map import 'AS65535-IN'
Node2:
set policy prefix-list AS65534-IN rule 10 action 'permit'
set policy prefix-list AS65534-IN rule 10 prefix '172.17.0.0/16'
set policy prefix-list AS65534-OUT rule 10 action 'deny'
set policy prefix-list AS65534-OUT rule 10 prefix '172.17.0.0/16'
set policy prefix-list6 AS65534-IN rule 10 action 'permit'
set policy prefix-list6 AS65534-IN rule 10 prefix '2001:db8:1::/48'
set policy prefix-list6 AS65534-OUT rule 10 action 'deny'
set policy prefix-list6 AS65534-OUT rule 10 prefix '2001:db8:1::/48'
set policy route-map AS65534-IN rule 10 action 'permit'
set policy route-map AS65534-IN rule 10 match ip address prefix-list 'AS65534-IN'
set policy route-map AS65534-IN rule 10 match ipv6 address prefix-list 'AS65534-IN'
set policy route-map AS65534-IN rule 20 action 'deny'
set policy route-map AS65534-OUT rule 10 action 'deny'
set policy route-map AS65534-OUT rule 10 match ip address prefix-list 'AS65534-OUT'
set policy route-map AS65534-OUT rule 10 match ipv6 address prefix-list 'AS65534-OUT'
set policy route-map AS65534-OUT rule 20 action 'permit'
set protocols bgp 65535 neighbor 2001:db8::1 address-family ipv4-unicast route-map export 'AS65534-OUT'
set protocols bgp 65535 neighbor 2001:db8::1 address-family ipv4-unicast route-map import 'AS65534-IN'
set protocols bgp 65535 neighbor 2001:db8::1 address-family ipv6-unicast route-map export 'AS65534-OUT'
set protocols bgp 65535 neighbor 2001:db8::1 address-family ipv6-unicast route-map import 'AS65534-IN'
We could expand on this and also deny link local and multicast in the rule 20 action deny.