BGP—the protocol that powers the internet.

BGP, the routing protocol that powers the internet, is behind everything from notifications on your phone to funny cat videos and streaming services. It ensures you can binge-watch your favorite shows on demand and access content seamlessly.

In a service provider environment, it's crucial to not only understand the fundamentals of BGP but also know how to manipulate BGP routes using the various attributes at your disposal—think of these as a ninja's toolkit, always ready for action. This lab is designed to closely mimic a real-world service provider environment, allowing us to experiment effectively. I've also included multivendor technologies, so you'll not only deepen your understanding of BGP but also gain experience navigating different command-line interfaces across platforms.

Let’s start with the basics.

IGP (Interior Gateway Protocol) and EGP (Exterior Gateway Protocol) are two categories of routing protocols used in networking.

• IGP operates within a single autonomous system (AS), such as within an organization’s internal network. Common IGP protocols include OSPF, IS-IS, and RIP. They focus on optimizing routing inside the AS for efficiency and speed.

• EGP, like BGP (Border Gateway Protocol), is used to exchange routing information between different autonomous systems, such as between ISPs or large networks. EGPs ensure that data can travel across the global internet by handling external routing.

In summary, IGP manages internal routing, while EGP handles external or inter-AS routing.

BGP has two main types: iBGP (Internal BGP) and eBGP (External BGP).

• iBGP (Internal BGP): This is used for routing within a single autonomous system (AS). It allows BGP routers in the same AS to share routing information. iBGP ensures that all routers inside the AS have a consistent view of external routes. However, it does not advertise routes learned from one iBGP peer to another unless certain rules (like route reflection or confederations) are used.

• eBGP (External BGP): This is used for exchanging routing information between different autonomous systems. eBGP is responsible for external routing, ensuring that networks from different ASes can communicate over the internet. eBGP neighbors are typically directly connected, and the routes they exchange are used for global traffic forwarding.

In essence, iBGP handles internal routing coordination, while eBGP manages external routing between networks.

In networking, Administrative Distance (AD) is a value that routers use to select the most reliable route when multiple routing protocols provide information about the same destination. Lower values are preferred over higher ones.

Administrative Distance Values:

• Cisco:

  • EBGP: 20

  • IBGP: 200

  • OSPF: 110

  • IS-IS: 115

  • RIP: 120

  • Static route: 1

• Juniper:

  • EBGP: 170

  • IBGP: 200

  • OSPF: 10 (internal), 150 (external)

  • IS-IS: 15

  • RIP: 100

  • Static route: 5

• Huawei:

  • EBGP: 255 (lowered manually for preference)

  • IBGP: 255 (lowered manually for preference)

  • OSPF: 10 (internal), 150 (ASE)

  • IS-IS: 15

  • RIP: 100

  • Static route: 60

---

Key characteristics of BGP:

1. Path Vector Protocol: Uses a path vector mechanism to track the route information.

2. Inter-domain Routing: Manages routing between different autonomous systems (ASes).

3. AS Path Attribute: Helps in loop prevention and route selection by listing ASes a route has traversed.

4. Policy-based Routing: Allows for detailed routing policies based on various attributes.

5. Scalability: Handles large numbers of routes and scales well with the growing internet.

6. Incremental Updates: Sends only changes in routing information to reduce bandwidth usage.

7. Support for CIDR: Facilitates efficient IP address usage and route aggregation.

8. Multiple Path Support: Can manage multiple routes to a destination for load balancing and redundancy.

---

In BGP, establishing a connection between routers (known as BGP peers) requires the following:

1. Explicitly Mentioning Neighbor IP: BGP requires manual configuration of the IP addresses of its neighbors. This means that each BGP router must be explicitly told which IP addresses it should use to connect with its peers. This setup ensures that the routers know where to send and receive BGP updates.

BGP Neighborship over TCP Session: BGP establishes its neighborship through a TCP session, which involves a three-way handshake:

1. SYN: The initiating BGP router sends a TCP SYN packet to the peer to start the connection.

2. SYN-ACK: The receiving BGP router responds with a SYN-ACK packet, acknowledging the initiation request.

3. ACK: The initiating BGP router sends an ACK packet back to the receiver, completing the handshake.

Once this TCP connection is established on port 179, BGP begins exchanging routing information and establishing the BGP session.

---

What is an AS Number?

An Autonomous System (AS) Number is a unique identifier assigned to each Autonomous System (AS) on the internet. An AS is a network or a collection of networks under a single administrative domain that uses BGP to communicate with other ASes. The AS number helps BGP routers identify the origin of routing updates and ensures proper routing between different networks.

Why is an AS Number Required?

• Route Identification: It helps differentiate between different networks and their paths. AS numbers are used in the AS Path attribute in BGP to show the list of ASes that a route has passed through.

• Routing Policies: BGP uses AS numbers to apply routing policies and control traffic flow between networks.

• Loop Prevention: AS numbers are critical for preventing routing loops by ensuring that a route is not advertised back into the AS from which it originated.

Public and Private AS Numbers

1. Public AS Numbers:

   • Range: 1 to 64,495 (16-bit) and 131,072 to 419,999 (32-bit).

   • Usage: Public AS numbers are globally unique and are required for ASes that need to communicate with other ASes on the internet. These are assigned by regional internet registries (RIRs) like ARIN, RIPE, or APNIC.

   • Example: A service provider or large enterprise that connects to the internet via multiple ISPs will use a public AS number for external routing.

2. Private AS Numbers:

   • Range: 64,512 to 65,535 (16-bit) and 4,200,000 to 4,294,967 (32-bit).

   • Usage: Private AS numbers are used within private networks or for communication between networks that don’t require global routing. These AS numbers are not advertised to the global internet and are typically used for internal BGP (iBGP) setups.

   • Example: A company with multiple internal networks or data centers can use private AS numbers for routing without needing a public AS number

Path Selection:

RIP (Routing Information Protocol):

• Path Selection: Based on hop count. The route with the fewest number of hops to the destination is selected.

• Metric: Hop count, with a maximum limit of 15 hops.

• OSPF (Open Shortest Path First):

  • Path Selection: Based on cost, which is calculated according to the bandwidth of the links. The route with the lowest cumulative cost is chosen.

  • Metric: Cost, where the cost is derived from the bandwidth of the links.

• EIGRP (Enhanced Interior Gateway Routing Protocol):

  • Path Selection: Uses a composite metric that includes bandwidth, delay, load, and reliability. The route with the lowest composite metric is preferred.

  • Metric: Composite metric based on multiple factors (bandwidth, delay, load, reliability).

BGP Path Selection: Unlike RIP, OSPF, and EIGRP, which rely on single metrics (hop count, cost, or composite metrics) for path selection, BGP uses a variety of path attributes such as AS Path, Local Preference, and MED (Multi-Exit Discriminator) to determine the best route. These attributes provide a flexible and detailed approach to route selection, allowing for complex routing policies and decisions.

---

BGP Path Flexibility: While other routing protocols like RIP, OSPF, and EIGRP focus primarily on finding the shortest path to a destination network, BGP offers greater flexibility by allowing network administrators to influence both inbound and outbound routes through various attributes and policies. This capability enables more granular control over routing decisions and traffic engineering.

BGP states:

Idle:

• Description: The initial state where BGP has not yet started the process of establishing a connection with its peer.

• Details: The router is waiting for the user to configure a BGP neighbor or for the interface to come up. No BGP messages are exchanged in this state.

1. Connect:

   • Description: The router has detected a BGP neighbor and is attempting to establish a TCP connection.

   • Details: The router waits for a TCP connection to be established with the peer on port 179. If successful, it transitions to the "Active" state; otherwise, it remains in "Connect" or returns to "Idle" if there is an issue.

2. Active:

   • Description: The router is actively trying to establish a BGP session but has not yet received an acknowledgment from the peer.

   • Details: The router attempts to open a TCP connection to the peer. If the connection is established, it moves to the "OpenSent" state; if not, it may retry or return to "Idle."

3. OpenSent:

   • Description: The router has sent an OPEN message to the peer and is waiting for an OPEN message in return.

   • Details: In this state, the router has sent its OPEN message, which includes information about its BGP version, AS number, and other parameters. It waits to receive a valid OPEN message from the peer to move to the "OpenConfirm" state.

4. OpenConfirm:

   • Description: The router has received a valid OPEN message from the peer and is waiting for a KEEPALIVE message.

   • Details: The router processes the peer's OPEN message and sends a KEEPALIVE message to confirm the session. If it receives a KEEPALIVE in response, it transitions to the "Established" state. If there are issues, it may return to "Idle" or "Active."

5. Established:

   • Description: The BGP session is fully established, and the routers can exchange routing information.

   • Details: In this state, the BGP session is operational, and both routers can exchange UPDATE, NOTIFICATION, and KEEPALIVE messages. The routers perform route advertisements and updates, and the BGP session remains in this state until a disruption occurs or configuration changes necessitate a transition to another state.

BGP uses four main types of messages to communicate between peers:

1. OPEN:

   • Purpose: Establish a BGP session between peers.

   • Details: Contains information such as the BGP version, AS number, router ID, and optional parameters. It is sent once when the session is being established.

2. UPDATE:

   • Purpose: Advertises new routes or withdraws previously advertised routes.

   • Details: Includes the path attributes and network prefixes being advertised or withdrawn. It is used to update the routing information between peers.

3. KEEPALIVE:

   • Purpose: Maintains the connectivity of the BGP session.

   • Details: Sent periodically to confirm that the BGP session is still active and to keep the connection alive. It helps prevent session timeouts.

4. NOTIFICATION:

   • Purpose: Indicates an error or problem in the BGP session.

   • Details: Contains an error code and subcode to specify the nature of the problem. It triggers the termination of the BGP session and helps diagnose issues.

These messages ensure that BGP peers can establish and maintain a stable routing relationship, exchange routing information, and handle errors.

---

BGP attributes:

These attributes are used to determine the best path for routing and to influence routing decisions. Here’s a brief overview of 8 key BGP attributes that are widely used in a production environment:

1. Weight:
   A locally significant, Cisco-specific parameter that a router can set when receiving updates. A higher Weight is preferred. Commonly used to influence outbound routing decisions.

2. Local Preference:
   A parameter communicated throughout a single AS. A higher Local Preference is preferred. Commonly used to influence outbound routing decisions.

3. Originate:
   Paths sourced locally are preferred.

4. AS Path :
   The number of autonomous systems in the AS_ PATH path attribute. Lower AS path lengths are preferred. Commonly used to influence inbound routing decisions.

5. Origin Type:
   Indicates how the route was injected into BGP: i (network command), e (EGP), or ? (redistributed). i is preferred to e, and e is preferred to ?.

6. Multi-Exit Discriminator (MED):
   A parameter set and advertised by routers in one AS to influence the BGP path selection decisions of routers in another AS. A lower MED is preferred.

7. Paths:
   Prefer eBGP path over iBGP path.

8. Router ID:
   A tie-breaker, where the route received from the router with the lowest router ID is the Router ID preferred.

   A simple and catchy mantra to remember BGP attributes is:

   WE : (Weight)
   LOVE: (Local Preference)
   ORANGES: (Originate)
   AS: (AS Path)
   ORANGES: (Origin)
   MEAN: (MED - Multi-Exit Discriminator)
   PURE: (Paths)
   REFRESHMENT: (Router ID).

   This mantra helps recall the key BGP attributes in the order of their influence on route selection also additionally I have attached a list of all the BGP attributes in the image below.

---

Let’s start with the lab now

The lab is straightforward in total we have in total 4 service providers AKAMAI, TATA, Airtel, and Pioneer-SP being our ground for the experiment.

AKAMAI

The Cisco IOSv router model is primarily used for simulation purposes. We use a prefix list to match networks for BGP route advertisement, which provides a more granular and precise control over route distribution.

Prefix-Lists:

A prefix list is a method used in networking to filter or control which IP prefixes (subnets or addresses) are permitted or denied in routing decisions, such as route advertisements or route acceptance. It's commonly used in protocols like BGP to specify which routes should be advertised or received. Prefix lists offer more granular control compared to simple access lists, allowing specific matches based on subnet length and the IP address itself.

Comparison: Prefix List vs Access List

Route-map:

A route map in BGP (Border Gateway Protocol) is used to set or modify various BGP attributes, among other things. By applying a route map, you can influence the BGP route selection process or control routing policies in a more granular way. Route maps are applied to routes in BGP, OSPF, and other routing protocols to implement custom routing policies.

---

ip prefix-list ADVERTISE-NETWORKS-BHARTI-TATA seq 5 permit 60.60.60.60/32
ip prefix-list ADVERTISE-NETWORKS-BHARTI-TATA seq 10 permit 192.168.6.0/30
ip prefix-list ADVERTISE-NETWORKS-BHARTI-TATA seq 15 permit 192.168.7.0/30
ip prefix-list ADVERTISE-NETWORKS-BHARTI-TATA seq 20 permit 1.1.1.1/32
ip prefix-list ADVERTISE-NETWORKS-BHARTI-TATA seq 25 permit 4.4.4.4/32
ip prefix-list ADVERTISE-NETWORKS-BHARTI-TATA seq 30 permit 8.8.8.8/32
!
route-map ADVERTISE-FOR-BHARTI-TATA permit 10
 match ip address prefix-list ADVERTISE-NETWORKS-BHARTI-TATA

The configuration includes a prefix list named ADVERTISE-NETWORKS-BHARTI-TATA, which specifies the networks to be advertised. We then create a route map to match this prefix list. Notably, no attributes have been added to the route map at this stage. This approach ensures a more granular level of control compared to using the network command for advertisement. It also provides the flexibility to later apply attributes to these networks if needed.

---

router bgp 32787
 bgp router-id 60.60.60.60
 bgp log-neighbor-changes
 redistribute connected route-map ADVERTISE-FOR-BHARTI-TATA
 neighbor Bharti-Airtel peer-group
 neighbor Bharti-Airtel remote-as 9498
 neighbor TATA peer-group
 neighbor TATA remote-as 4755
 neighbor 192.168.6.1 peer-group Bharti-Airtel
 neighbor 192.168.7.2 peer-group TATA

The configuration begins by specifying the autonomous system number along with the router ID 60.60.60.60. Next, we redistribute the directly connected networks, as defined in the previously created prefix list and route map. Additionally, two peer groups, TATA and Bharti-Airtel, were established with their respective IP addresses for peering, since manual neighbor configuration is required, as mentioned earlier in the article.

Airtel:

---

ip prefix-list ADVERTISE-NETWORKS-AKAMAI-PIONEER-SP seq 5 permit 40.40.40.40/32
ip prefix-list ADVERTISE-NETWORKS-AKAMAI-PIONEER-SP seq 10 permit 192.168.4.0/30
ip prefix-list ADVERTISE-NETWORKS-AKAMAI-PIONEER-SP seq 15 permit 192.168.6.0/30
!
route-map ADVERTISE-FOR-AKAMAI-PIONEER-SP permit 10
 atch ip address prefix-list ADVERTISE-NETWORKS-AKAMAI-PIONEER-SP

The Airtel configuration is straightforward, involving the advertisement of directly connected networks and the router ID. Once again, we maintain granularity by using a prefix list and route map for precise control.

---

router bgp 9498
 bgp router-id 40.40.40.40
 bgp log-neighbor-changes
 redistribute connected route-map ADVERTISE-FOR-AKAMAI-PIONEER-SP
 neighbor AKAMAI peer-group
 neighbor AKAMAI remote-as 32787
 neighbor PIONEER-SP peer-group
 neighbor PIONEER-SP remote-as 134192
 neighbor 192.168.4.2 peer-group PIONEER-SP
 neighbor 192.168.6.2 peer-group AKAMAI

Next, we specify the autonomous system number for Airtel and redistribute the networks into BGP using the prefix list and route map. We also create two peer groups and configure their IP addresses for manual neighbor relationships.

TATA:

---

ip prefix-list ADVERTISE-NETWORK-AKAMAI-PIONEER-SP seq 5 permit 50.50.50.50/32
ip prefix-list ADVERTISE-NETWORK-AKAMAI-PIONEER-SP seq 10 permit 192.168.5.0/30
ip prefix-list ADVERTISE-NETWORK-AKAMAI-PIONEER-SP seq 15 permit 192.168.7.0/30
!
route-map ADVERTISE-FOR_AKAMAI-PIONEER-SP permit 5
 match ip address prefix-list ADVERTISE-NETWORK-AKAMAI-PIONEER-SP

The TATA configuration is similar, utilizing the prefix list and route map for network advertisement

---

router bgp 4755
 bgp router-id 50.50.50.50
 bgp log-neighbor-changes
 redistribute connected route-map ADVERTISE-FOR_AKAMAI-PIONEER-SP
 neighbor AKAMAI peer-group
 neighbor AKAMAI remote-as 32787
 neighbor PIONEER-SP peer-group
 neighbor PIONEER-SP remote-as 134192
 neighbor 192.168.5.1 peer-group PIONEER-SP
 neighbor 192.168.7.1 peer-group AKAMAI

We again specify the AS number, redistribute the networks, and configure the peering group with the designated IP addresses.

PIONEER-SP:

The Pioneer-SP network integrates a combination of multivendor technologies, including routers like Juniper vMX and Huawei NE40. The configuration of the Huawei NE40 closely resembles that of Cisco (IOSV), with a similar command-line structure. On the other hand, Juniper's configuration commands differ significantly and will be explored in detail later. Let's begin with the Pioneer-SP configuration.

Before we move ahead there are a few topics that we need to cover.

BGP Split Horizon Rule: In BGP, the split horizon rule prevents a router from advertising routes back to the same neighbor it learned them from, which helps avoid routing loops in iBGP sessions.To overcome this we are gonna use route-reflectors.

BGP Route Reflector: A route reflector overcomes the split horizon rule by allowing routes learned from one iBGP peer to be advertised to other iBGP peers, reducing the need for a full iBGP mesh and improving scalability while maintaining loop-free routing.so in our lab we have configured RID 10.10.10.10 to become the Route-reflector server and RID 20.20.20.20 Route-reflector client and also RID 30.30.30.30.

The above image confirms our Route-reflector server and clients for ease.

RID 20.20.20.20

---

[~NE40-134192-20.20.20.20] route-policy ADVERTISE-FOR-AIRTEL permit node 5
 [~NE40-134192-20.20.20.20] if-match ip-prefix IP-POOL-FOR-AIRTEL
#
[~NE40-134192-20.20.20.20] ip ip-prefix IP-POOL-FOR-AIRTEL index 5 permit 192.168.3.0 30
[~NE40-134192-20.20.20.20] ip ip-prefix IP-POOL-FOR-AIRTEL index 10 permit 20.20.20.20 32
[~NE40-134192-20.20.20.20] ip ip-prefix IP-POOL-FOR-AIRTEL index 15 permit 10.10.10.10 32

As you can see the config looks similar to Cisco CLI we created a prefix-list and route-policy to advertise only specified networks

---

bgp 134192
 router-id 20.20.20.20
 peer 192.168.3.1 as-number 134192
 peer 192.168.4.1 as-number 9498
 #
 ipv4-family unicast
  undo synchronization
  import-route direct route-policy ADVERTISE-FOR-AIRTEL
  peer 192.168.3.1 enable
  peer 192.168.3.1 next-hop-local
  peer 192.168.4.1 enable

• ipv4-family unicast: Specifies the BGP address family for IPv4 unicast routing.

• undo synchronization: Disables BGP synchronization, allowing BGP to advertise routes before they are learned by the IGP (Interior Gateway Protocol).

• import-route direct route-policy ADVERTISE-FOR-AIRTEL: Redistributes directly connected routes into BGP using the specified route policy ADVERTISE-FOR-AIRTEL.

• peer 192.168.3.1 enable: Enables BGP peering with the neighbor at IP address 192.168.3.1.

• peer 192.168.3.1 next-hop-local: Sets the next hop for routes advertised to this peer (192.168.3.1) to the local router's IP address.

• peer 192.168.4.1 enable: Enables BGP peering with the neighbor at IP address 192.168.4.1.

• The peer IP address 192.168.3.1 is an IBGP peership since both the routers belong in the same As-number.

---

RID 10.10.10.10

---

[~NE40-134192-10.10.10.10] ip ip-prefix NETWORKS-FOR-IBGP-NEIGHBORS index 5 permit 10.10.10.10 32
[~NE40-134192-10.10.10.10] ip ip-prefix NETWORKS-FOR-IBGP-NEIGHBORS index 10 permit 192.168.3.0 30
[~NE40-134192-10.10.10.10] ip ip-prefix NETWORKS-FOR-IBGP-NEIGHBORS index 15 permit 192.168.2.0 30
[~NE40-134192-10.10.10.10] route-policy ADV-FOR-IBGP permit node 5
[~NE40-134192-10.10.10.10] if-match ip-prefix NETWORKS-FOR-IBGP-NEIGHBORS

[~NE40-134192-10.10.10.10] bgp 134192
[~NE40-134192-10.10.10.10] router-id 10.10.10.10
[~NE40-134192-10.10.10.10] peer 192.168.2.1 as-number 134192
[~NE40-134192-10.10.10.10] peer 192.168.3.2 as-number 134192
 #
[~NE40-134192-10.10.10.10] ipv4-family unicast
[~NE40-134192-10.10.10.10] undo synchronization
[~NE40-134192-10.10.10.10] import-route direct route-policy ADV-FOR-IBGP
[~NE40-134192-10.10.10.10] peer 192.168.2.1 enable
[~NE40-134192-10.10.10.10] peer 192.168.2.1 reflect-client
[~NE40-134192-10.10.10.10] peer 192.168.3.2 enable
[~NE40-134192-10.10.10.10] peer 192.168.3.2 reflect-client

Here's a breakdown:

1. IP Prefix Lists:

   • Three specific prefixes are defined under the IP prefix list NETWORKS-FOR-IBGP-NEIGHBORS:

     • index 5: Permits 10.10.10.10/32

     • index 10: Permits 192.168.3.0/30

     • index 15: Permits 192.168.2.0/30 These define networks or IPs that will be used in route advertisements.

2. Route Policy:

   • route-policy ADV-FOR-IBGP: A route policy that permits routes matching the prefix list NETWORKS-FOR-IBGP-NEIGHBORS. This is applied when importing routes into BGP.

3. BGP Configuration:

   • AS Number: The local BGP instance is running in AS 134192.

   • Router ID: The BGP router ID is set to 10.10.10.10.

   • Peers: Two iBGP neighbors are defined:

     • 192.168.2.1 (AS 134192)

     • 192.168.3.2 (AS 134192)

4. IPv4 Unicast BGP Settings:

   • undo synchronization: Disables BGP synchronization with the IGP.

   • import-route direct route-policy ADV-FOR-IBGP: Imports directly connected routes into BGP using the ADV-FOR-IBGP route policy.

   • Route Reflection: Both peers (192.168.2.1 and 192.168.3.2) are configured as route reflection clients, which means this router will reflect routes between these clients in the iBGP topology.

This configuration essentially sets up iBGP with route reflection, and uses the route policy to control which directly connected routes are advertised to the iBGP neighbors.

RID 30.30.30.30

---

root@JNP-134192-30.30.30.30# set policy-options policy-statement ADV-LOOPBACK term 1 from route-filter 30.30.30.30/32 exact
root@JNP-134192-30.30.30.30# set policy-options policy-statement ADV-LOOPBACK term 1 then accept
root@JNP-134192-30.30.30.30# set policy-options policy-statement ADV-LOOPBACK term 2 from route-filter 10.10.10.10/32 exact
root@JNP-134192-30.30.30.30# set policy-options policy-statement ADV-LOOPBACK term 2 then accept
root@JNP-134192-30.30.30.30# set policy-options policy-statement ADV-LOOPBACK-FOR-TATA term 1 from route-filter 192.168.2.0/30 exact
root@JNP-134192-30.30.30.30# set policy-options policy-statement ADV-LOOPBACK-FOR-TATA term 1 then accept
root@JNP-134192-30.30.30.30# set policy-options policy-statement NEXT-HOP-SELF term 1 then next-hop self
root@JNP-134192-30.30.30.30# set protocols bgp group EBGP-4755-TATA export ADV-LOOPBACK
root@JNP-134192-30.30.30.30# set protocols bgp group EBGP-4755-TATA export ADV-LOOPBACK-FOR-TATA
root@JNP-134192-30.30.30.30# set protocols bgp group EBGP-4755-TATA peer-as 4755
root@JNP-134192-30.30.30.30# set protocols bgp group EBGP-4755-TATA local-as 134192
root@JNP-134192-30.30.30.30# set protocols bgp group EBGP-4755-TATA neighbor 192.168.5.2 local-address 192.168.5.1
root@JNP-134192-30.30.30.30# set protocols bgp group IBGP-134192-PIONEER-SP export NEXT-HOP-SELF
root@JNP-134192-30.30.30.30# set protocols bgp group IBGP-134192-PIONEER-SP export ADV-LOOPBACK
root@JNP-134192-30.30.30.30# set protocols bgp group IBGP-134192-PIONEER-SP peer-as 134192
root@JNP-134192-30.30.30.30# set protocols bgp group IBGP-134192-PIONEER-SP local-as 134192
root@JNP-134192-30.30.30.30# set protocols bgp group IBGP-134192-PIONEER-SP neighbor 192.168.2.2 local-address 192.168.2.1

Here's a breakdown:

Policy Statements:

1. ADV-LOOPBACK:

   • Term 1: Matches the exact route 30.30.30.30/32 and accepts it.

   • Term 2: Matches the exact route 10.10.10.10/32 and accepts it. This policy controls the advertisement of loopback addresses.

2. ADV-LOOPBACK-FOR-TATA:

   • Term 1: Matches the exact route 192.168.2.0/30 and accepts it. This policy is specific to advertising routes for the peer associated with TATA (AS 4755).

3. NEXT-HOP-SELF:

   • Changes the next hop to self for the routes being advertised in the BGP session, ensuring that this router’s IP is the next hop for IBGP neighbors.

BGP Configuration:

1. EBGP with TATA (AS 4755):

   • A BGP session is established with an external peer (192.168.5.2) in AS 4755.

   • Export Policies: ADV-LOOPBACK and ADV-LOOPBACK-FOR-TATA are applied to control which routes are advertised.

   • Local AS: 134192

   • Peer AS: 4755

   • Local Address: 192.168.5.1

2. IBGP with PIONEER-SP (AS 134192):

   • An IBGP session is established with a peer (192.168.2.2) in the same AS (134192).

   • Export Policies: NEXT-HOP-SELF and ADV-LOOPBACK are applied for route advertisement.

   • Local AS and Peer AS: Both are set to 134192, indicating an internal BGP session.

   • Local Address: 192.168.2.1

Summary:

• Two BGP groups are configured: an EBGP session with AS 4755 (TATA) and an IBGP session with a peer in AS 134192.

Specific routing policies control the advertisement of loopback addresses and next-hop settings.

---

As we can see to reach PIONEER-SP from AKAMAI there are two redundant links AIRTEL and TATA and vice-versa.

Let's consider a scenario where the links between PIONEER-SP and AIRTEL are operating at a slower speed of 100 Mbps, whereas the link between TATA and PIONEER-SP is running at a faster speed of 1 Gbps.

PIONEER-SP is currently using the AIRTEL route, which operates on a slower link, to reach the 60.60.60.60 route of the AKAMAI CDN.

To optimize this, we need to adjust the routing to prioritize the TATA link over the AIRTEL link.

As we discussed earlier, weight is a Cisco-specific BGP attribute and isn't effective in a multivendor environment. However, by using local preference, we can influence outbound routing decisions to ensure traffic prefers the TATA link over AIRTEL.

Let's create a route policy on RID 30.30.30.30 that applies local preference when importing the 60.60.60.60 route from our TATA peer. This will enable us to shift traffic from AIRTEL to TATA.

---

set policy-options policy-statement ADD-LOCAL-PRF term 1 from route-filter 60.60.60.60/32 exact
set policy-options policy-statement ADD-LOCAL-PRF term 1 then local-preference 3000
set policy-options policy-statement ADD-LOCAL-PRF term 1 then accept
set protocols bgp group EBGP-4755-TATA import ADD-LOCAL-PRF

1. set policy-options policy-statement ADD-LOCAL-PRF term 1 from route-filter 60.60.60.60/32 exact:

   • This command specifies that the policy statement ADD-LOCAL-PRF should apply to the route 60.60.60.60/32 with an exact match. It identifies the route you want to act on.

2. set policy-options policy-statement ADD-LOCAL-PRF term 1 then local-preference 3000:

   • This sets the local preference value for the matched route (60.60.60.60/32) to 3000. The local preference is used to influence the BGP path selection process within the autonomous system (AS). Higher values are preferred.

3. set policy-options policy-statement ADD-LOCAL-PRF term 1 then accept:

   • After setting the local preference, the route is accepted, meaning it will be installed in the routing table.

4. set protocols bgp group EBGP-4755-TATA import ADD-LOCAL-PRF:

   • This command applies the ADD-LOCAL-PRF policy to the BGP group EBGP-4755-TATA, which ensures that when routes are received from this BGP peer, the local preference of 3000 is applied to the route 60.60.60.60/32.

This configuration ensures that the specific route 60.60.60.60/32 coming from the BGP peer EBGP-4755-TATA is imported with a local preference of 3000, making it more preferable than routes with the default local preference (usually 100).

---

And voilà, as seen in the routing table, PIONEER-SP is now preferring the TATA link for the 60.60.60.60 route.

lets consider one more scenario

We can see that AKAMAI is selecting the AIRTEL link, which is the slower option, for the 10.10.10.10 route.

As engineers at PIONEER-SP, we can manipulate routes within our own AS, but we cannot make changes within the AKAMAI AS.

To address this situation, let's recall the BGP attributes we've learned. By applying AS-PATH prepending on specific routes, we can influence inbound traffic. Considering this, we can create another route policy to prepend the AS-PATH on the AIRTEL route for 60.60.60.60.

This will encourage AKAMAI to prefer the faster TATA link over AIRTEL. Let's go ahead and implement this

[~NE40-134192-10.10.10.10] ip ip-prefix RID-PRF-FROM-TATA index 5 permit 10.10.10.10 32
[~NE40-134192-10.10.10.10]route-policy RID-PRF-FROM-TATA permit node 5
[~NE40-134192-10.10.10.10]if-match ip-prefix RID-PRF-FROM-TATA
[~NE40-134192-10.10.10.10]apply as-path 134192 134192 additive
[~NE40-134192-10.10.10.10]bgp 134192
[~NE40-134192-10.10.10.10]ipv4-family unicast
[~NE40-134192-10.10.10.10]peer 192.168.3.2 route-policy RID-PRF-FROM-TATA export

1. ip ip-prefix RID-PRF-FROM-TATA index 5 permit 10.10.10.10 32:

   • This creates an IP prefix list named RID-PRF-FROM-TATA. The prefix list will permit the IP address 10.10.10.10/32, meaning it matches routes with this specific IP.

2. route-policy RID-PRF-FROM-TATA permit node 5:

   • This creates a route policy named RID-PRF-FROM-TATA and defines a permit node (or sequence) 5. A route policy is used to filter and modify routes in BGP.

3. if-match ip-prefix RID-PRF-FROM-TATA:

   • This condition matches routes based on the IP prefix list RID-PRF-FROM-TATA. Any route that matches this prefix (10.10.10.10/32) will be processed according to the actions defined in the policy.

4. apply as-path 134192 134192 additive:

   • This applies an action to prepend the AS path 134192 twice to the matched route. The keyword additive ensures the new AS path is added to the existing AS path instead of replacing it. This is commonly done to influence route selection by making the AS path longer.

5. bgp 134192:

   • This enters the BGP configuration mode for autonomous system (AS) 134192.

6. ipv4-family unicast:

   • Specifies that the BGP configuration is for the IPv4 unicast address family, which handles normal unicast IP routing.

7. peer 192.168.3.2 route-policy RID-PRF-FROM-TATA export:

   • This applies the route policy RID-PRF-FROM-TATA to routes being exported (sent) to the BGP peer 192.168.3.2. This ensures that the AS path prepending and route filtering (based on 10.10.10.10/32) only applies when advertising routes to this peer.

Summary:

This configuration sets up a route policy that matches the route 10.10.10.10/32, applies AS path prepending, and exports this policy to the BGP neighbor 192.168.3.2. This influences how the peer views the routes advertised by your AS.

as we observed we can see that our route-policy allowed us to prefer TATA link for the route of 10.10.10.10 over AIRTEL without making changes in AKAMAI AS additionally we can see the prepended as-path attribute for the Airtel route which influenced the inbound routing process in PIONEER-SP.

With that, I conclude my BGP lab. My goal was to simulate a service provider's environment using multivendor technologies while highlighting the significance of BGP.

I hope this has been helpful, and I'd love to hear your feedback and thoughts on the experience.

Happy Learning :)