BGP
BGP (Border Gateway Protocol) is defined in RFC 4271.
Uses TCP port 179.
The router with the highest router-id is used as the TCP client.
Best Path Selection
| # | Attribute | Rule | Default | Notes | Affects Traffic | Applies to route-map |
|---|---|---|---|---|---|---|
| 1 | Prefix Length | Longest match | Always checked | inbound & outbound | ||
| 2 | Cost Community | Lowest Cost Community Number Lowest Cost Community ID |
2147483647 | Checked if "set extcommunity cost pre-bestpath" is configured. Skipped if "bgp bestpath cost-community ignore" is configured. | ||
| 3 | WEIGHT | Highest Weight | 32768 | Local to the router. Local originated prefixes have weight 32768 by default. Only for Cisco; not recommended for general use. | ||
| 4 | LOCAL PREFERENCE | Highest Local Preference | 100 | Used for separating customer/peering/transit traffic. | outbound | inbound |
| 5 | Prefer local-sourced routes | Everything announced through network/aggregate commands or redistribution is considered as local-sourced. | ||||
| 6 | AS-PATH | Shortest as-path | Ignored if "bgp bestpath as-path ignore" is configured. | inbound | outbound | |
| 7 | ORIGIN | Lowest Origin Type (IGP<EGP<Incomplete) | ||||
| 8 | MED | Lowest Multi-Exit Discriminator (MED) | 1st AS must be the same, unless "bgp always-compare-med" is configured. | inbound | outbound | |
| 9 | Prefer eBGP over iBGP | |||||
| 10 | Lowest IGP metric to the BGP next hop | |||||
| 11 | Cost Community | Lowest Cost Community Number Lowest Cost Community ID |
2147483647 | Checked if "set extcommunity cost igp" is configured. Skipped if "bgp bestpath cost-community ignore" is configured. | ||
| 12 | Check for BGP Multipath | |||||
| 13 | If both paths are external, prefer the path received first | |||||
| 14 | Lowest BGP router-id | |||||
| 15 | If the originator-id or the router-id is the same for multiple paths, prefer path with minimum cluster list length | Only for route reflectors | ||||
| 16 | Prefer the path with the lowest neighbor address |
MED
- bgp deterministic-med
- compare MED when choosing routes advertised by different neighbors in the same autonomous system
- routes from the same autonomous system are grouped together and the best entries of each group are compared
- bgp always-compare-med
- compare MED when choosing routes advertised by different neighbors in different autonomous systems
"bgp deterministic-med" and "bgp always-compare-med" are recommended in order to alway have a standard best path selection algorithm.
In order to avoid mis-interpreting a missing MED (zero vs infinity), when setting MED on a peering, it's best to set it also on all other peerings. Otherwise the command "bgp bestpath med missing-as-worst" can be used.
Common Comparisons
- Prefix Length
- Highest Local Preference
- Shortest as-path
- Lowest Multi-Exit Discriminator (MED)
- Prefer eBGP over iBGP
- Lowest IGP metric to the BGP next hop
- Lowest BGP router-id
origin
The origin attribute indicates how BGP learned about a particular route.
- i (IGP)
- interior to the originating AS (i.e. when the network configuration command is used to inject the route into BGP)
- e (EGP)
- learned via EGP (rarely seen)
- ? (incomplete)
- unknown or learned via some other way (i.e. redistributed into BGP, or from eBGP)
Address Families
AFIs
- 1 (IPv4)
- 2 (IPv6)
- 25 (L2VPN)
SAFIs
- 1 (Unicast)
- 2 (Multicast)
- 4 (NLRI with MPLS labels)
- 65 (VPLS)
- 128 (VPN with MPLS labels (VRFs))
Configuration
IOS
router bgp 2
no synchronization
bgp log-neighbor-changes
network 5.5.5.5 mask 255.255.255.255
neighbor 20.4.5.4 remote-as 1
no auto-summary
IOS-XR
router bgp 1
bgp log neighbor changes detail
address-family ipv4 unicast
network 4.4.4.4/32
!
neighbor 20.4.5.5
remote-as 2
address-family ipv4 unicast
In IOS-XR, if there is no loopback configured with an ipv4 address, the BGP session won't come up, until you explicitly configure the bgp router-id.
BGP is designed to refuse a session with itself because of the router-id check. You can use a per-vrf assignment of BGP router-id in order to have a VRF-to-VRF peering on the same router.
In IOS-XR, every eBGP session requires an explicit route-policy in order to allow incoming/outgoing updates. It's good practice to create one named PASS-RPL with default action "pass" and use it when first activating each eBGP session. Afterwards you can create the required route-policy and use that instead.
When told to advertise a prefix into BGP, prefer to use the "network" statement, unless told to do otherwise. Also prefer to do the "network" advertisements to another AS on routers running eBGP to that AS.
You can use the "network x.x.x.x backdoor" command in order to change the admin distance of an eBGP route (default 20) to that of iBGP (200), so that the equivalent IGP route can be preferred.
Route Aggregation
- redistribution of static or IGP
- aggregate-address
- summary-only
- suppress-map
- unsuppress-map (per neighbor)
- advertise-map
- inject-map
A more specific prefix must exist in the BGP table before doing aggregation.
Communities
- Standard Communities (32-bit)
- Used for well-known communities and for specific communities of type $ASN:$TAG in BGP
- send-community (IOS)
- send-community-ebgp (IOS-XR)
- Extended Communities (64-bit) are defined in
- Used in MPLS VPNs for RT and SOO
- send-community extended (IOS)
- send-extended-community-ebgp (IOS-XR)
Communities are configured through community lists.
When regular expressions are required, expanded (standard or extended) community lists must be used.
Configuration
- Standard
- ip community-list 1 permit 100:10
- ip community-list standard X-COMMLIST permit 100:10
- Expanded Standard
- ip community-list 100 permit 100:*
- ip community-list expanded X-COMMLIST permit 100:*
- Extended
- ip extcommunity-list 1 permit rt 200:20
- ip extcommunity-list standard X-COMMLIST permit rt 200:20
- Expanded Extended
- ip extcommunity-list 100 permit rt 200:*
- ip extcommunity-list expanded X-COMMLIST permit rt 200:*
In IOS, all communities are not sent by default to iBGP or eBGP sessions.
In IOS-XR, all communities are sent by default on iBGP sessions, but not on eBGP sessions.
Well-known communities
- internet
- no-export (don't advertise to eBGP neighbor)
- local-as (don't advertise to other confederation sub-AS)
- no-advertise(don't advertise to any neighbor)
Delete communities
IOS
route-map DELCOMM1-ROUTEMAP permit 10
set comm-list 1 delete
!
route-map DELCOMM2-ROUTEMAP permit 10
set community none
!
route-map DELCOM3-ROUTEMAP permit 10
set extcomm-list 1 delete
IOS-XR
route-policy DELCOM1-RPL
delete community in (*:*)
end-policy
!
route-policy DELCOM3-RPL
delete extcommunity rt all
end-policy
Use the "additive" keyword to add communities to existing ones.
Links
Synchronization
A BGP router with synchronization enabled does not install iBGP learned routes into its routing table and propagate them to an eBGP peer, if it is not able to validate those routes in its IGP first. It's used to ensure that there are no black holes inside the AS caused by intermediate routers that do not run BGP.
It's disabled by default ("no synchronization"), because nowadays most networks run iBGP or MPLS.
Route Reflectors
Route Reflectors modify iBGP split-horizon rules.
Routes learned on a RR from a RR-Client are propagated to other RR-Clients and Non-Clients
Routes learned on a RR from a Non-Client are propagated only to RR-Clients
RRs can be assigned per address-family.
RRs do not modify the next-hop of advertised routes by default.
RRs can be in the forwarding path or not.
Use "no bgp client-to-client reflection" on RRs, when their clients are also fully meshed.
An RR reflecting a route received from an RR-Client adds the following attributes:
- Originator ID
- the Router ID of the originator of the route
- if the update comes back to the originator (so the local Router-ID is the same as the Originator-ID), the update is ignored
- Cluster List
- a list of Cluster IDs that an update has passed through
- when an RR reflects a route from a client to a non-client, the local Cluster ID is appended to the Cluster List
- if the update comes back to the RR (so the local Cluster-ID is contained in the prefix Cluster List) the update is ignored
Originator and Cluster List are used to prevent loops in RR environments.
By default Cluster-ID = RR Router-ID. In case of two RRs, two different Cluster-IDs will be used. This increases memory utilization, because the same route is stored multiple times, each one with a different Cluster-ID.
You can use a common Cluster-ID in redundant RRs (in order to decrease memory utilisation, although rarely needed), only when you're sure that connectivity for RR clients won't break if the RR client looses one of its RR connections.
IOS
router bgp 100
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 update-source Loopback 0
neighbor 2.2.2.2 route-reflector-client
IOS-XR
router bgp 100
neighbor 2.2.2.2
remote-as 100
update-source Loopback0
address-family ipv4 unicast
route-reflector-client
Links
Confederations
The AS is split into smaller autonomous systems in order to reduce the number of iBGP sessions.
It's common practice to use the private AS range (64512 – 65535) to denote a sub-autonomous system.
These internal ASNs are hidden and only a single external ASN is announced to eBGP neighbors.
BGP confederations modify iBGP as-path processing
When sending:
- updates to iBGP neighbors
- as-path is not changed
- updates to intra-confederation eBGP neighbors
- the intra-confederation ASN is prepended to the as-path
- updates to eBGP neighbors
- the intra-confederation ASNs are removed and the external ASN is prepended to the as-path
Intra-confederation eBGP session is:
- like eBGP session when establishing the session (ebgp-multihop)
- like iBGP session when sending routing updates (local pref, next-hop, etc.)
IOS
router bgp INTERNAL-ASN-100
bgp confederation identifier EXTERNAL-ASN-1
bgp confederation peers INTERNAL-ASN-200 INTERNAL-ASN-300
neighbor 2.2.2.2 remote-as INTERNAL-ASN-200
neighbor 3.3.3.3 remote-as INTERNAL-ASN-300
neighbor 9.9.9.9 remote-as EXTERNAL-ASN-9
IOS-XR
router bgp INTERNAL-ASN-100
bgp confederation peers
INTERNAL-ASN-200
INTERNAL-ASN-300
!
bgp confederation identifier EXTERNAL-ASN-1
!
neighbor 2.2.2.2
remote-as INTERNAL-ASN-200
!
neighbor 3.3.3.3
remote-as INTERNAL-ASN-300
!
neighbor 9.9.9.9
remote-as EXTERNAL-ASN-9
EXTERNAL-ASNs define the ASNs used for eBGP sessions between different ASNs.
INTERNAL-ASNs define the ASNs used for eBGP sessions between different sub-ASNs of the same ASN.
Example
IOS
router bgp 65100
bgp confederation identifier 1
bgp confederation peers 65200 65300
neighbor 2.2.2.2 remote-as 65200
neighbor 3.3.3.3 remote-as 65300
neighbor 9.9.9.9 remote-as 9
IOS-XR
router bgp 65100
bgp confederation peers
65200
65300
!
bgp confederation identifier 1
!
neighbor 2.2.2.2
remote-as 65200
!
neighbor 3.3.3.3
remote-as 65300
!
neighbor 9.9.9.9
remote-as 9
Links
Next-Hop
- advertisement to eBGP peer
- next-hop changes to self
- use "next-hop-unchanged" to not change
- advertisement to iBGP peer
- next-hop doesn't change
- use "next-hop-self" to change
You can't use the next-hop-self for setting the next-hop in reflected iBGP routes. Instead use an outbound route map.
In IOS-XR, you can use "ibgp policy out enforce-modifications" in combination with an outbound route-map in order to force modification of the routes attributes (including next-hop) when sent to an iBGP neighbor.
keepalive & holdtime
Neighbor holdtime timers are negotiated while initially setting the BGP session and the smaller one gets used by both neighbors. Keepalive timers are then based on that holdtime value. It's not recommended to have less than 3 secs as a holdtime.
The fastest convergence on a BGP session that can be achieved by changing the keepalive/holdtime timers is 3 sec.
In order to protect the control-plane, you can put a limit on the lowest holdtime number accepted by using the "min-holdtime" command. If the neighbor doesn't comply, then the BGP session is rejected.
Mass Neighbor Configuration
In order to minimize neighbor configuration regarding the BGP session parameters you can use the following:
peer groups (IOS)
router bgp 100
neighbor PEER-GROUP peer-group
neighbor PEER-GROUP remote-as 100
neighbor PEER-GROUP update-source Loopback0
!
neighbor 1.1.1.1 peer-group PEER-GROUP
!
address-family vpnv4
neighbor PEER-GROUP send-community extended
neighbor 1.1.1.1 activate
neighbor groups (IOS-XR)
router bgp 100
neighbor-group NEI-GROUP
remote-as 100
update-source Loopback0
!
neighbor 1.1.1.1
use neighbor-group NEI-GROUP
peer session templates (IOS)
router bgp 100
template peer-session PEER-TEMPLATE
remote-as 100
update-source Loopback0
!
neighbor 1.1.1.1 inherit peer-session PEER-TEMPLATE
eBGP Peerings & TTL
IOS
router bgp 100
neighbor 2.2.2.2 ttl-security hops X
neighbor 3.3.3.3 ebgp-multihop Y
IOS-XR
router bgp 100
neighbor 2.2.2.2
ttl-security
neighbor 3.3.3.3
ebgp-multihop Y
IOS
R1#sh bgp nei | i TTL|Session
Session: 2.2.2.2
Mininum incoming TTL 255-X, Outgoing TTL 255
Session: 3.3.3.3
Mininum incoming TTL 0, Outgoing TTL Y
eBGP Multihop
It allows a neighbor connection between two external peers that do not have direct connection. You should also configure an IGP or static routing to allow the neighbors without direct connection to reach each other.
TTL Security Check
It's a lightweight security mechanism to protect eBGP neighbor sessions from CPU utilization-based attacks (DoS attacks that flood the network with IP packets that contain forged source IP addresses).
IOS
When configured for an eBGP neighbor, the router accepts only IP packets with a TTL count that is greater or equal to maximum TTL value (255) minus the hop count that is configured locally for the relevant eBGP session. If the TTL value in the IP packet is less than the maximum TTL value (255) minus the hops configured value, the incoming packet is silently discarded.
Supports both directly connected neighbor sessions and multihop eBGP neighbor sessions
IOS-XR
When configured for a directly adjacent eBGP neighbor, the router accepts only IP packets with a TTL count that is equal to the maximum TTL value (255). If the TTL value in the IP pakcet is less than the maximum TTL value (255), the incoming packet is silently discarded.
TTL values according to BGP setup:
- R1 config: neighbor R2
- R1 sends packets to R2 with TTL=1
- R1 config: neighbor R2 ttl-security hops X
- R1 sends packets to R2 with TTL=255
- R1 config: neighbor R2 ebgp-multihop X
- R1 sends packets to R2 with TTL=X
ebgp-mutlihop combined with ttl-security on two eBGP routers
R1: ebgp-multihop X (<255)
R2: ttl-security hops Y (<254)
- R1 sends packets to R2 with TTL=X
- R2 doesn't reply back
- R2 accepts packets with TTL < 255-Y
- R2 sends packets to R1 with TTL=255
- R1 replies back
- R1 accepts packets with any TTL
General Rule
If ( X - ActualHops >= 255 - Y ) then the eBGP session can be established.
Interesting Cases
R1: ebgp-multihop X
R2: ttl-security hops 254
- R1 sends packets to R2 with TTL=X
- R2 replies back
- R2 sends packets to R1 with TTL=255
- R1 replies back
R1: ebgp-multihop 255
R2: ttl-security hops Y
- R1 sends packets to R2 with TTL=255
- R2 replies back
- R2 accepts packets with TTL < 255-Y
- R2 sends packets to R1 with TTL=255
- R1 replies back
- R2 accepts packets with any TTL
If ebgp-multihop is set to 255 or ttl-security is set to 254 (aka when at least one of these parameters is set to its max), then the eBGP session can be established, as long as their packets can reach each other.
R1: ttl-security hops X
R2: ttl-security hops Y
- R1 sends packets to R2 with TTL=255
- R2 replies back
- R2 accepts packets with TTL < 255-Y
- R2 sends packets to R1 with TTL=255
- R1 replies back
- R1 accepts packets with TTL < 255-X
If both routers use ttl-security, then the eBGP session can be established regardless of the hop values used, as long as their packets can reach each other.
R1: ebgp-multihop X
R2: ebgp-multihop Y
- R1 sends packets to R2 with TTL=X
- R2 replies back
- R2 accepts packets with any TTL
- R2 sends packets to R1 with TTL=Y
- R1 replies back
- R1 accepts packets with any TTL
If both routers use ebgp-multihop, then the eBGP session can be established regardless of the hop values used, as long as their packets can reach each other.
If loopback interfaces are used to connect single-hop eBGP peers, you can configure the "neighbor disable-connected-check" command before you can establish the eBGP peering session.
PMTUD
IOS
R2#sh bgp vpnv4 unicast all nei 19.19.19.19 | i tcp|segment
Transport(tcp) path-mtu-discovery is enabled
Datagrams (max data segment is 1432 bytes):
If you have BGP PMTUD enabled (by default in most releases), BGP packets will be sent with DF bit set.
You can disable BGP PMTUD (either for all neighbors or for a specific neighbor) with the following commands.
IOS
router bgp 100
no bgp transport path-mtu-discovery
neighbor 19.19.19.19 transport path-mtu-discovery disable
If global command "ip tcp path-mtu-discovery" is disabled (default) and BGP PMTUD is disabled too, then the default MSS (536) is used for BGP neighbors.
If "ip tcp path-mtu-discovery" is enabled but BGP PMTUD is disabled, then the maximum MSS is used for BGP neighbors.
You can use "ip tcp mss X" to change the global TCP MSS.
IOS-XR
tcp path-mtu-discovery
Links
