BGP

Border Gateway Protocol (BGP) Deep Dive

Border Gateway Protocol (BGP) is the **protocol that drives the global internet** and is also widely used in enterprise and cloud networks. It is a **path vector routing protocol** that enables the exchange of routing information between different networks, known as **Autonomous Systems (ASes)**.

Overview of BGP

BGP is classified as an **Exterior Gateway Protocol (EGP)**, meaning it is primarily used to route traffic **between** different autonomous systems (AS). It can also be used internally within an AS, known as **Internal BGP (iBGP)**.

BGP operates over **TCP (port 179)** and is a **policy-based protocol** that makes routing decisions based on attributes rather than simple shortest-path metrics like OSPF or EIGRP.

BGP Message Types

BGP uses four types of messages to establish and maintain sessions:

Message Type	Description
**Open**	Establishes a BGP session between peers by exchanging capabilities and AS numbers.
**Update**	Advertises new routes and withdraws previously advertised routes.
**Keepalive**	Ensures BGP peers remain active. Sent periodically to maintain the session.
**Notification**	Sent when an error is detected, causing the BGP session to be terminated.

BGP Neighbor Relationships (Peering)

BGP routers must form **peer relationships** before exchanging routing information. There are two types of BGP peering:

External BGP (eBGP)

• Peering between routers in **different** autonomous systems.
• Uses **AS-Path** for loop prevention.
• Default TTL is **1**, meaning peers must be **directly connected** unless multihop is configured.

Internal BGP (iBGP)

• Peering between routers in the **same** autonomous system.
• Does **not** modify the AS-Path attribute (loop prevention must be handled manually).
• Requires **full mesh** peering or **route reflectors** to scale.

BGP Path Selection Process

BGP selects the **best route** using a set of attributes in the following order:

1. **Prefer the highest Weight (Cisco-specific)**
2. **Prefer the highest Local Preference (local-pref)**
3. **Prefer the shortest AS-Path**
4. **Prefer the lowest Origin type (IGP < EGP < Incomplete)**
5. **Prefer the lowest Multi-Exit Discriminator (MED)**
6. **Prefer eBGP over iBGP**
7. **Prefer the path with the lowest IGP metric to the next-hop**
8. **Prefer the oldest route (to avoid flapping)**
9. **Prefer the path from the router with the lowest BGP Router ID**
10. **Prefer the path with the lowest neighbor IP address**

Common BGP Attributes

BGP uses various **path attributes** to influence routing decisions:

Attribute	Type	Description
**AS-Path**	Mandatory	Shows the sequence of ASes a route has traversed.
**Next-Hop**	Mandatory	Specifies the next-hop IP address for the route.
**Local Preference**	Optional	Higher values are preferred within an AS (default: 100).
**Multi-Exit Discriminator (MED)**	Optional	Used to influence inbound traffic when multiple links exist.
**Community**	Optional	A tag for policy-based routing decisions.
**Weight**	Cisco-specific	A local attribute where higher values are preferred.

BGP Peering States

A BGP session goes through the following states:

State	Description
**Idle**	Initial state; the router is not actively trying to establish a connection.
**Connect**	TCP connection is being established.
**Active**	The router is actively trying to establish a BGP session.
**OpenSent**	The Open message has been sent to the peer.
**OpenConfirm**	Waiting for a Keepalive message to confirm the session.
**Established**	BGP peering is successful, and routes are exchanged.

BGP Route Advertisement Rules

BGP follows strict rules when advertising routes:

• **iBGP does not advertise iBGP-learned routes to other iBGP peers** (requires route reflectors).
• **eBGP advertises all learned routes**.
• **BGP does not advertise a route unless it is in the local routing table**.

BGP in Cloud Networking

BGP is widely used in **cloud networking** for dynamic routing between **on-premises data centers and cloud providers** such as AWS, Azure, and Google Cloud.

BGP in AWS

• AWS uses BGP for **Direct Connect** and **Site-to-Site VPN**.
• Supports both **eBGP and iBGP** with **Amazon VPC**.
• AWS Transit Gateway (TGW) uses **BGP over VPN or Direct Connect** to propagate routes dynamically.

BGP in Azure

• Azure **ExpressRoute** uses BGP for private and public peering.
• BGP propagates **VNet routes dynamically** between on-prem and Azure.

BGP in Google Cloud

• Google Cloud **Cloud Router** dynamically exchanges routes using BGP.
• Supports **regional dynamic routing** for better traffic control.

Common BGP Issues and Troubleshooting

BGP Neighbor Not Establishing

• Check **AS numbers** (they must match for iBGP, must be different for eBGP).
• Verify **network reachability** (firewalls, ACLs, security groups).
• Ensure **TTL settings** (eBGP requires `ttl 1` unless multihop is configured).
• Check **authentication (MD5)** if configured.

BGP Route Not Being Advertised

• Ensure **route exists in the routing table** (`show ip route` or `show bgp`).
• Check if **iBGP learned route is not being propagated** (route reflectors may be needed).
• Verify **prefix filters and route maps** that may block advertisement.

High BGP Convergence Time

• Use **BFD (Bidirectional Forwarding Detection)** to speed up failure detection.
• Reduce **Keepalive and Hold timers** for faster failover.
• Optimize **route reflectors** to minimize iBGP full-mesh overhead.

Conclusion

BGP is a **complex but powerful** routing protocol that enables inter-domain routing across the Internet and cloud networks. Understanding **BGP attributes, path selection, and troubleshooting techniques** is essential for any **network or cloud engineer**.

Would you like an example BGP configuration for **AWS, Cisco, or Palo Alto Networks**?

How to Establish a BGP Connection, Enable BFD, and Configure BGP Attributes for Path Selection

Border Gateway Protocol (BGP) is a path-vector routing protocol used for exchanging routes between Autonomous Systems (ASes). This guide provides step-by-step instructions to **establish a BGP connection**, **enable Bidirectional Forwarding Detection (BFD)** for fast failure detection, and **configure BGP attributes** for path selection.

1. Establishing a BGP Connection

BGP is a **TCP-based protocol (port 179)** that requires **peer relationships** to exchange routing information. Follow these steps to configure **BGP peering**:

Step 1: Define Autonomous System (AS) Numbers

Each BGP router must have an **AS number (ASN)**. There are two types:

• **Public ASNs (1-64495)** – Assigned by IANA for global internet routing.
• **Private ASNs (64512-65534, 4200000000-4294967294)** – Used in private networks.

Step 2: Configure BGP Neighbor Relationship

Configure **BGP peering** between routers. Example:

Cisco Configuration Example (eBGP between AS 65001 and AS 65002)

<syntaxhighlight lang="cisco"> router bgp 65001

 neighbor 192.168.1.2 remote-as 65002
 neighbor 192.168.1.2 update-source Loopback0
 neighbor 192.168.1.2 description eBGP Peer to AS 65002

</syntaxhighlight>

Palo Alto Configuration Example (eBGP)

1. Navigate to **Network > Virtual Routers > BGP**. 2. Enable **BGP** and enter **Local AS** (65001). 3. Under **BGP Peers**, add a neighbor:

  * Peer Address: `192.168.1.2`
  * Peer AS: `65002`
  * Enable **Multihop** (if not directly connected).

4. Commit the configuration.

Step 3: Verify BGP Session

Check BGP session status:

Cisco Command

<syntaxhighlight lang="cisco"> show ip bgp summary </syntaxhighlight>

Palo Alto Command

<syntaxhighlight lang="bash"> show routing protocol bgp summary </syntaxhighlight>

If the **state** is **Established**, the BGP session is up.

2. Enabling BFD for Fast Failure Detection

• • Bidirectional Forwarding Detection (BFD)** is a lightweight protocol that detects failures **faster than BGP timers**. It allows BGP to react quickly to link failures.

Step 1: Configure BFD on BGP Peers

BFD must be enabled on both routers.

Cisco Configuration Example

<syntaxhighlight lang="cisco"> interface GigabitEthernet0/0

 bfd interval 50 min_rx 50 multiplier 3

router bgp 65001

 neighbor 192.168.1.2 bfd

</syntaxhighlight>

Palo Alto Configuration Example

1. Navigate to **Network > Network Profiles > BFD**. 2. Create a new BFD profile:

  * **Minimum TX/RX Interval**: `50ms`
  * **Multiplier**: `3`

3. Assign the BFD profile to the **BGP neighbor**.

Step 2: Verify BFD Session

Check if BFD is running:

Cisco Command

<syntaxhighlight lang="cisco"> show bfd neighbors </syntaxhighlight>

Palo Alto Command

<syntaxhighlight lang="bash"> show bfd session all </syntaxhighlight>

If the session is **UP**, BFD is working.

3. Configuring BGP Attributes for Path Selection

BGP selects the **best path** based on a set of **attributes**. You can manipulate these attributes to control routing decisions.

Attribute 1: Local Preference (Higher is Preferred)

Used in **iBGP** to influence outbound traffic within an AS.

Cisco Configuration

<syntaxhighlight lang="cisco"> route-map SET_LOCAL_PREF permit 10

 set local-preference 200

router bgp 65001

 neighbor 192.168.1.2 route-map SET_LOCAL_PREF in

</syntaxhighlight>

Attribute 2: AS-Path Prepending (Longer is Less Preferred)

Used in **eBGP** to make a path less desirable by adding AS numbers.

Cisco Configuration

<syntaxhighlight lang="cisco"> route-map AS_PATH_PREPEND permit 10

 set as-path prepend 65001 65001 65001

router bgp 65001

 neighbor 192.168.1.2 route-map AS_PATH_PREPEND out

</syntaxhighlight>

Attribute 3: Multi-Exit Discriminator (MED) (Lower is Preferred)

Used to influence **inbound traffic** when multiple links exist between ASes.

Cisco Configuration

<syntaxhighlight lang="cisco"> route-map SET_MED permit 10

 set metric 50

router bgp 65001

 neighbor 192.168.1.2 route-map SET_MED out

</syntaxhighlight>

Attribute 4: Weight (Cisco-Specific, Higher is Preferred)

Used locally on a Cisco router to **prefer one path over another**.

Cisco Configuration

<syntaxhighlight lang="cisco"> router bgp 65001

 neighbor 192.168.1.2 weight 500

</syntaxhighlight>

Attribute 5: Community Tags (Used for Policy-Based Routing)

Communities are tags that can be used for policy-based decisions.

Cisco Configuration

<syntaxhighlight lang="cisco"> route-map SET_COMMUNITY permit 10

 set community 65001:100 no-export

router bgp 65001

 neighbor 192.168.1.2 route-map SET_COMMUNITY out

</syntaxhighlight>

4. Verifying BGP Path Selection

After applying these attributes, check the **BGP best path selection**.

Cisco Command

<syntaxhighlight lang="cisco"> show ip bgp </syntaxhighlight>

Look for the **">"** symbol, indicating the selected best path.

Palo Alto Command

<syntaxhighlight lang="bash"> show routing protocol bgp rib-out </syntaxhighlight>

Conclusion

To establish a **stable and optimized BGP connection**, follow these best practices:

1. **Ensure BGP peering is established** between routers.
2. **Enable BFD** for rapid failure detection.
3. **Tune BGP attributes** (Local Preference, AS-Path, MED, Weight, and Communities) for optimal routing.
4. **Monitor BGP sessions** regularly with `show bgp summary` and `show bfd neighbors`.

This ensures **efficient, reliable, and scalable BGP routing** for both enterprise and cloud environments.

Juniper BGP Policy Configuration for AWS Direct Connect

This page explains the configuration of Juniper BGP routing policies used to advertise routes to AWS Direct Connect (DX) and to control the route preferences through different communities. It includes how to configure routing policies for advertising static routes and the use of communities to influence routing decisions.

Policy Statement: `ANNOUNCE-TO-AWS:DX:TRANSIT`

The policy statement is responsible for advertising routes to AWS through Direct Connect or a Transit Gateway. It involves several terms and actions to filter and manipulate the routes before they are sent to AWS.

Term: `ALLOW`

This term specifies the conditions under which routes will be advertised to AWS.

• **`from protocol static`**: This condition specifies that only static routes in the routing table will be used by this policy.
• **`from prefix-list-filter FSU-ALL exact`**: This filter restricts the advertisement to the prefixes listed in the **FSU-ALL** prefix list. Only exact matches from this list will be advertised.

Then Actions

• **`then community add AWS:ADV:LOCAL-REGION`**: Adds the **AWS:ADV:LOCAL-REGION** community, indicating that the route is local to a specific AWS region.
• **`then community add AWS:HIGH:PREF`**: Adds the **AWS:HIGH:PREF** community to give the route high preference within AWS, making it more likely to be selected.
• **`then accept`**: Accepts the route into the routing table for advertisement to AWS.

Term: `REJECT`

This term rejects any routes that don't match the criteria defined in the previous term.

• **`then reject`**: Rejects the route if it doesn't meet the conditions and prevents it from being advertised.

Community Definitions

BGP communities are used to add metadata to routes, which can influence routing decisions within AWS. The following communities are defined:

• **`AWS:ADV:ALL-REGIONS-US members 7224:9200`**: Routes with this community are advertised across all AWS regions in the US.
• **`AWS:ADV:GLOBAL members 7224:9300`**: Routes with this community are advertised globally across AWS regions.
• **`AWS:ADV:LOCAL-REGION members 7224:9100`**: Indicates that the route is local to a specific AWS region.
• **`AWS:HIGH:PREF members 7224:7300`**: Marks routes with high preference within AWS.
• **`AWS:LOW:PREF members 7224:7100`**: Marks routes with low preference, typically used for backup routes.
• **`AWS:MED:PREF members 7224:7200`**: Routes with this community have medium preference within AWS.

AS Path Filtering

The AS Path filter ensures that only routes originating from AWS or passing through AWS are impacted by this policy.

• **`set policy-options as-path AWS-ORIGINATE-ASN ".* 16509 .*"`**: This regular expression filters routes that either originate or pass through AS **16509**, which is AWS's Autonomous System Number (ASN).

Full Configuration Example

Router 1
set interfaces et-0/0/2 unit 2600 description AWS-DR::DX::ATL
set policy-options prefix-list AWS-DR 10.166.0.0/16
set policy-options prefix-list AWS-POC 10.167.192.0/18
set policy-options prefix-list AWS 10.168.0.0/14
set policy-options prefix-list AWS 10.174.0.0/15
set policy-options policy-statement ACCEPT-FROM-AWS term ACCEPT from prefix-list-filter AWS-DR orlonger
set policy-options policy-statement ACCEPT-FROM-AWS term ACCEPT from prefix-list-filter AWS-POC orlonger
set policy-options policy-statement ACCEPT-FROM-AWS term ACCEPT from prefix-list-filter AWS orlonger
set policy-options policy-statement ACCEPT-FROM-AWS term ACCEPT then accept
set policy-options policy-statement ACCEPT-FROM-AWS term REJECT then reject
set policy-options policy-statement ANNOUNCE-TO-AWS:DX:TRANSIT term ALLOW from protocol static
set policy-options policy-statement ANNOUNCE-TO-AWS:DX:TRANSIT term ALLOW from prefix-list-filter Onprem-ALL exact
set policy-options policy-statement ANNOUNCE-TO-AWS:DX:TRANSIT term ALLOW then community add AWS:ADV:LOCAL-REGION
set policy-options policy-statement ANNOUNCE-TO-AWS:DX:TRANSIT term ALLOW then community add AWS:HIGH:PREF
set policy-options policy-statement ANNOUNCE-TO-AWS:DX:TRANSIT term ALLOW then accept
set policy-options policy-statement ANNOUNCE-TO-AWS:DX:TRANSIT term REJECT then reject
set policy-options policy-statement RENET-REJECT-FROM-FLR term REJECT-ASN from as-path AWS-ORIGINATE-ASN
set policy-options community AWS:ADV:ALL-REGIONS-US members 7224:9200
set policy-options community AWS:ADV:GLOBAL members 7224:9300
set policy-options community AWS:ADV:LOCAL-REGION members 7224:9100
set policy-options community AWS:HIGH:PREF members 7224:7300
set policy-options community AWS:LOW:PREF members 7224:7100
set policy-options community AWS:MED:PREF members 7224:7200
set policy-options as-path AWS-ORIGINATE-ASN ".* 16509 .*"
set protocols bgp group AWS-DR:DX:ATL type external
set protocols bgp group AWS-DR:DX:ATL import ACCEPT-FROM-AWS
set protocols bgp group AWS-DR:DX:ATL export ANNOUNCE-TO-AWS:DX:TRANSIT
set protocols bgp group AWS-DR:DX:ATL peer-as 64513
set protocols bgp group AWS-DR:DX:ATL neighbor 10.128.255.10 local-address 10.128.255.9
set protocols bgp group AWS-DR:DX:ATL neighbor 10.128.255.10 authentication-key "xxxxxx"
set protocols bgp group AWS-DR:DX:ATL neighbor 10.128.255.10 bfd-liveness-detection minimum-interval 300
set protocols bgp group AWS-DR:DX:ATL neighbor 10.128.255.10 bfd-liveness-detection multiplier 3

router 2
set interfaces xe-0/2/0 unit 2610 description AWS::DX::MIA
set policy-options prefix-list AWS-DR 10.166.0.0/16
set policy-options prefix-list AWS-POC 10.167.192.0/18
set policy-options prefix-list AWS 10.168.0.0/14
set policy-options prefix-list AWS 10.174.0.0/15
set policy-options policy-statement ACCEPT-FROM-AWS term ACCEPT from prefix-list-filter AWS-DR orlonger
set policy-options policy-statement ACCEPT-FROM-AWS term ACCEPT from prefix-list-filter AWS-POC orlonger
set policy-options policy-statement ACCEPT-FROM-AWS term ACCEPT from prefix-list-filter AWS orlonger
set policy-options policy-statement ACCEPT-FROM-AWS term ACCEPT then accept
set policy-options policy-statement ACCEPT-FROM-AWS term REJECT then reject
set policy-options policy-statement ANNOUNCE-TO-AWS:DX:TRANSIT term ALLOW from protocol static
set policy-options policy-statement ANNOUNCE-TO-AWS:DX:TRANSIT term ALLOW from prefix-list-filter Onprem-ALL exact
set policy-options policy-statement ANNOUNCE-TO-AWS:DX:TRANSIT term ALLOW then community add AWS:MED:PREF
set policy-options policy-statement ANNOUNCE-TO-AWS:DX:TRANSIT term ALLOW then community add AWS:ADV:LOCAL-REGION
set policy-options policy-statement ANNOUNCE-TO-AWS:DX:TRANSIT term ALLOW then accept
set policy-options policy-statement ANNOUNCE-TO-AWS:DX:TRANSIT term REJECT then reject
set policy-options policy-statement RENET-REJECT-FROM-FLR term REJECT-ASN from as-path AWS-ORIGINATE-ASN
set policy-options community AWS:ADV:ALL-REGIONS-US members 7224:9200
set policy-options community AWS:ADV:GLOBAL members 7224:9300
set policy-options community AWS:ADV:LOCAL-REGION members 7224:9100
set policy-options community AWS:HIGH:PREF members 7224:7300
set policy-options community AWS:LOW:PREF members 7224:7100
set policy-options community AWS:MED:PREF members 7224:7200
set policy-options as-path AWS-ORIGINATE-ASN ".* 16509 .*"
set protocols bgp group AWS:DX:MIA type external
set protocols bgp group AWS:DX:MIA import ACCEPT-FROM-AWS
set protocols bgp group AWS:DX:MIA export ANNOUNCE-TO-AWS:DX:TRANSIT
set protocols bgp group AWS:DX:MIA peer-as 64513
set protocols bgp group AWS:DX:MIA neighbor 10.128.255.14 local-address 10.128.255.13
set protocols bgp group AWS:DX:MIA neighbor 10.128.255.14 authentication-key "xxxxxxxx"
set protocols bgp group AWS:DX:MIA neighbor 10.128.255.14 bfd-liveness-detection minimum-interval 300
set protocols bgp group AWS:DX:MIA neighbor 10.128.255.14 bfd-liveness-detection multiplier 3

Use Case

This policy configuration is useful when managing BGP sessions with AWS via **Direct Connect** or **Transit Gateway**. The policy ensures that specific routes are advertised with appropriate preferences and communities, allowing for fine-grained control over routing behavior in AWS. For instance, you can prioritize certain routes, advertise them to specific regions, or mark them as local to a given AWS region.

Conclusion

The **Juniper BGP policy** configuration allows for precise control over which routes are advertised to AWS and how they are treated by AWS in terms of preference and region-specific routing. By using **BGP communities** and **AS path filters**, this configuration ensures that routes are advertised with the correct priority, helping to optimize routing decisions for both high and low-priority traffic.

Retrieved from the AWS Networking Wiki