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 دقیقه مطالعه · آخرین به‌روزرسانی ۲ مهر ۱۴۰۵

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.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه