LogoفارسیFA

Hands-On Lab: Configuring eBGP Between Two Autonomous Systems (CCNP Depth)

This hands-on lab configures eBGP between two routers in different autonomous systems with a full verification workflow, examining the BGP table, AS-path attribute, and confirming routes are correctly installed with eBGP's default administrative distance.

eBGP Neighbor ConfigurationAS-Path AttributeBGP Table Verification

~3 min read · Updated Sep 24, 2026

Lab Objective

Configure eBGP peering between two routers in different autonomous systems, advertise a network from each side, and thoroughly verify the BGP table, AS-path information, and the resulting IP routing table entries.

Lab Purpose

eBGP was introduced briefly earlier in this series as part of network fundamentals; this lab revisits it with the deeper verification workflow expected at the CCNP level — examining not just whether the route works, but the specific BGP attributes that explain why it was selected and how it will be advertised further.

Lab Topology

R1 (AS 65001) ---- Serial0/0/0 ------ Serial0/0/0 ---- R2 (AS 65002)

R1: 10.200.200.1/30, LAN 192.168.200.0/24
R2: 10.200.200.2/30, LAN 192.168.201.0/24

Task 1: Configure Basic Addressing

Configure the serial interfaces and each router's LAN.

Task 2: Configure BGP on R1

Enable BGP AS 65001 on R1, establish a neighbor relationship with R2, and advertise R1's LAN network.

Task 3: Configure BGP on R2

Enable BGP AS 65002 on R2, establish a neighbor relationship with R1, and advertise R2's LAN network.

Task 4: Verify the BGP Neighbor Relationship

Confirm the neighbor reaches Established state.

Task 5: Examine the BGP Table and AS-Path

Display the BGP table and identify the AS-path attribute for the learned route.

Task 6: Verify the Route in the IP Routing Table

Confirm the route appears with BGP's default administrative distance for external routes.

Solution and Verification

R1(config)# interface serial0/0/0
R1(config-if)# ip address 10.200.200.1 255.255.255.252
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# interface gigabitethernet0/0
R1(config-if)# ip address 192.168.200.1 255.255.255.0
R1(config-if)# no shutdown

R2(config)# interface serial0/0/0
R2(config-if)# ip address 10.200.200.2 255.255.255.252
R2(config-if)# clock rate 64000
R2(config-if)# no shutdown
R2(config-if)# exit
R2(config)# interface gigabitethernet0/0
R2(config-if)# ip address 192.168.201.1 255.255.255.0
R2(config-if)# no shutdown

R1(config)# router bgp 65001
R1(config-router)# neighbor 10.200.200.2 remote-as 65002
R1(config-router)# network 192.168.200.0 mask 255.255.255.0

R2(config)# router bgp 65002
R2(config-router)# neighbor 10.200.200.1 remote-as 65001
R2(config-router)# network 192.168.201.0 mask 255.255.255.0

R1# show ip bgp summary

Neighbor        V   AS  MsgRcvd  MsgSent  State/PfxRcd
10.200.200.2    4   65002   15    14       1
-- A number in State/PfxRcd (1, not a state
-- name) confirms Established with one
-- prefix received

R1# show ip bgp

   Network            Next Hop        Metric  LocPrf  Weight  Path
*> 192.168.200.0/24   0.0.0.0         0               32768   i
*> 192.168.201.0/24   10.200.200.2    0                   0   65002 i
-- The AS-path for the remote network
-- explicitly shows "65002" -- as this route
-- propagates further, R1 will prepend its
-- own AS number, building a path history
-- any future recipient can use for loop
-- detection

R1# show ip route bgp

B    192.168.201.0/24 [20/0] via 10.200.200.2, 00:02:15
-- Administrative distance of 20, the
-- standard default for eBGP-learned routes,
-- distinct from the 200 used for iBGP

Key Takeaway

The AS-path attribute serves two purposes simultaneously: it is BGP's primary loop-prevention mechanism, since a router rejects any route whose AS-path already contains its own AS number, and it also functions as a metric of sorts during best-path selection, where a shorter AS-path is generally preferred — reading this single attribute in the BGP table explains both why a route was chosen and how far it has traveled through the autonomous system topology.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring iBGP and the Full-Mesh Requirement

This hands-on lab configures iBGP among three routers within a single autonomous system, demonstrating the full-mesh peering requirement by deliberately omitting one peering relationship and observing the resulting route propagation failure.

Continue

Hands-On Lab: Configuring Policy-Based Routing (PBR)

This hands-on lab configures Policy-Based Routing on a router to send traffic from a specific source subnet out a different path than the normal routing table would select, overriding the destination-based forwarding decision that every previous routing lab in this series relied on.

Continue

Hands-On Lab: Configuring Route Leaking Between VRFs

This hands-on lab configures selective route leaking between two VRFs using route targets and a shared services VRF, allowing specific routes to cross the otherwise strict isolation boundary established in the previous VRF-Lite lab.

Continue

Hands-On Lab: Configuring VRF-Lite

This hands-on lab configures VRF-Lite on a router to maintain two completely separate routing tables for two different customer networks sharing the same physical router, verifying each VRF's traffic remains isolated despite using overlapping IP address space.

Continue

Hands-On Lab: Configuring Layer 3 EtherChannel

This hands-on lab configures a routed EtherChannel between two Layer 3 switches, bundling two physical links into a single logical routed interface rather than a switched trunk, and verifies OSPF forms a single neighbor relationship across the bundle rather than one per physical link.

Continue

Hands-On Lab: Configuring LACP Fast Rate

This hands-on lab configures LACPDU fast rate on an EtherChannel bundle, reducing the interval between LACP control packets to accelerate detection of a failed member link compared to the default slow rate.

Continue
Previous ArticleNext Article