Hands-On Lab: Configuring BGP AS-Path Prepending

This hands-on lab configures AS-path prepending on one outbound BGP path to make it appear artificially longer to external peers, influencing an upstream AS's inbound path selection without that AS needing any configuration change of its own.

AS-Path PrependingInbound Traffic EngineeringMulti-Homed AS Path Manipulation

~4 دقیقه مطالعه · آخرین به‌روزرسانی ۴ مهر ۱۴۰۵

Lab Objective

Configure a route-map that prepends extra AS numbers to a specific outbound route advertisement, verify the resulting AS-path length increase as seen by an external peer, and confirm that peer now prefers the shorter, non-prepended path via the alternate connection.

Lab Purpose

Local preference and weight, covered in the previous lab, only influence how routers within one's own AS choose among multiple outbound paths. Neither can influence how an external AS chooses among multiple paths back into the local AS. AS-path prepending solves this specific inbound traffic engineering problem by making one path look artificially less attractive from the outside.

Lab Topology

AS 65040 is multi-homed to the internet via
two connections:

R1 (AS 65040) ---- eBGP ---- ISP-A (AS 65100)
R2 (AS 65040) ---- eBGP ---- ISP-B (AS 65200)

Goal: make the ISP-B path the secondary/
backup path, with ISP-A preferred for
inbound traffic toward AS 65040's network
192.168.240.0/24

Task 1: Verify Both Paths Appear Equally Attractive Initially

Confirm ISP-A and ISP-B currently see the AS-path for 192.168.240.0/24 as the same length.

Task 2: Configure AS-Path Prepending on the R2-ISP-B Path

Configure a route-map on R2 that prepends AS 65040 three extra times to routes advertised toward ISP-B.

Task 3: Apply the Route-Map to the Outbound Advertisement

Apply the prepending route-map as an outbound policy toward ISP-B.

Task 4: Verify the Prepended AS-Path from ISP-B's Perspective

Confirm ISP-B now sees an artificially lengthened AS-path for this route.

Task 5: Verify ISP-B Now Prefers the Alternate Path (If One Exists on Their Side)

Confirm, from a router simulating a third-party AS receiving both paths, that the shorter (ISP-A) path is now preferred.

Solution and Verification

ThirdPartyAS# show ip bgp 192.168.240.0

   Network              Next Hop       Path
*> 192.168.240.0/24    [via ISP-A]     65100 65040 i
*  192.168.240.0/24    [via ISP-B]     65200 65040 i
-- Both paths currently show AS-path length
-- 2, appearing equally attractive by this
-- metric before prepending

R2(config)# route-map PREPEND-TO-ISPB permit 10
R2(config-route-map)# set as-path prepend 65040 65040 65040

-- Prepending R2's OWN AS number (65040)
-- three additional times, since AS-path
-- prepending always adds copies of the
-- advertising AS's own number, never a
-- fabricated or third-party AS

R2(config)# router bgp 65040
R2(config-router)# neighbor [ISP-B address] route-map PREPEND-TO-ISPB out

ISPB-Router# show ip bgp 192.168.240.0

   Network              Next Hop       Path
*> 192.168.240.0/24    [via R2]        65040 65040 65040 65040 i
-- ISP-B now sees an AS-path of length 4
-- instead of 1 (from their direct
-- perspective) -- three prepended copies
-- plus the original AS number

ThirdPartyAS# show ip bgp 192.168.240.0

   Network              Next Hop       Path
*> 192.168.240.0/24    [via ISP-A]     65100 65040 i
*  192.168.240.0/24    [via ISP-B]     65200 65040 65040 65040 65040 i
-- The ISP-A path (AS-path length 2) is now
-- clearly shorter than the ISP-B path
-- (AS-path length 5), so any third party
-- applying BGP's standard shortest-AS-path
-- preference rule will choose the ISP-A
-- path for traffic destined to
-- 192.168.240.0/24

Key Takeaway

AS-path prepending works precisely because it exploits BGP's own standard best-path rule preferring a shorter AS-path — rather than requesting ISP-B to change its own configuration, AS 65040 makes its own advertised route look objectively less attractive using a rule every BGP-speaking router in the world already applies by default, making this the standard technique for influencing inbound traffic engineering across an AS boundary an administrator does not control.

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

مقالات مرتبط

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.

ادامه