BGP Path Selection and Advanced Routing for CCIE EI
Introduction
Imagine you are managing a multi-homed enterprise network with dozens of eBGP and iBGP peerings spread across multiple autonomous systems. A routing change upstream suddenly shifts traffic onto a congested link, and your monitoring tools light up. The root cause? An overlooked BGP path selection attribute that silently overrode your intended traffic engineering policy. Scenarios like this are not hypothetical -- they appear regularly in production networks and on the CCIE Enterprise Infrastructure lab exam.
BGP is the protocol that holds the Internet together, and mastering its path selection algorithm is non-negotiable for any engineer pursuing the CCIE EI certification. Beyond the well-known weight, local preference, and AS-path length attributes, CCIE-level proficiency demands a thorough understanding of community attributes, confederations, route reflectors, Bidirectional Forwarding Detection (BFD), private AS number handling, and the local-AS feature. Each of these mechanisms gives you surgical control over how routes propagate and which paths traffic follows.
In this article, we will walk through each of these advanced BGP topics with detailed configuration examples drawn directly from hands-on lab exercises. Whether you are building your first confederation or fine-tuning community-based filtering, this guide provides the depth you need. If you are looking for foundational BGP coverage before diving in, start with the BGP Fundamentals course and the BGP Path Selection course on NHPREP.
How Does BGP Path Selection Work at the CCIE Level?
At its core, BGP path selection is a deterministic, ordered process. When a BGP speaker receives multiple paths to the same prefix, it evaluates those paths step by step until a single best path emerges. While CCNA and CCNP candidates learn the high-level order -- weight, local preference, locally originated, AS-path length, origin type, MED, and so on -- CCIE candidates must understand how to manipulate every step using route-maps, prefix lists, and community attributes.
The key distinction at the CCIE level is not merely knowing the order but knowing how to apply policy tools to influence each step. For example:
- Route-maps let you match specific prefixes and set attributes such as community values.
- Prefix lists provide precise prefix matching, including exact length or range-based matching.
- Community attributes enable you to tag routes and make downstream policy decisions based on those tags without modifying the AS path or other standard attributes.
Every configuration example in the sections that follow demonstrates a specific technique for influencing BGP path selection or controlling route propagation -- the exact skills tested on the CCIE EI lab exam.
What Are BGP Community Attributes and Why Do They Matter for BGP Path Selection?
BGP communities are 32-bit values attached to routes that act as labels. They allow network operators to group routes and apply routing policy based on those groupings. Communities are an optional transitive attribute, meaning they can be passed between autonomous systems -- but only if the sending router is explicitly configured to do so with the send-community command.
Two well-known community values are especially important for CCIE preparation: no-export and no-advertise. Both directly influence how far a route propagates, making them powerful tools for controlling BGP path selection across a multi-AS topology.
The No-Export Community
The no-export community tells a receiving BGP speaker that it must not advertise the tagged route to any eBGP peer. The route can still be propagated within the local autonomous system via iBGP, but it stops at the AS boundary.
Consider a scenario where AS 110 wants the 111.0.0.0/8 network to reach AS 2000 but does not want AS 2000 to export that route any further. The configuration uses a route-map to match the prefix and set the no-export community before sending the update to the eBGP neighbor.
R11 Configuration (AS 110):
ip prefix-list PL1 permit 111.0.0.0/8
!
route-map SETCOMM permit 10
match ip address prefix PL1
set community no-export
route-map SETCOMM permit 20
!
router bgp 110
neighbor 192.1.190.9 route-map SETCOMM out
neighbor 192.1.190.9 send-community standard
There are several critical details in this configuration:
- Prefix list PL1 matches exactly the 111.0.0.0/8 prefix.
- Route-map SETCOMM sequence 10 matches that prefix and applies the no-export community.
- Route-map SETCOMM sequence 20 is a permit-all catch-all -- without it, every other prefix would be implicitly denied.
- The
send-community standardcommand is required; without it, the community value is stripped from the update before it is sent to the neighbor.
On the receiving side within AS 110, internal peers must also be configured to propagate the community:
R9 Configuration (AS 110):
router bgp 110
neighbor 10.7.7.7 send-community standard
neighbor 10.8.8.8 send-community standard
Pro Tip: Forgetting the
send-communitycommand is one of the most common BGP community configuration mistakes. Always verify it on every neighbor statement where community propagation is required.
The No-Advertise Community
The no-advertise community is even more restrictive than no-export. A route tagged with no-advertise must not be advertised to any BGP peer -- not eBGP peers, and not even iBGP peers within the same AS.
In the lab scenario, AS 110 wants the 112.112.112.0/24 network to reach R9 only. R9 should not forward this network to anyone, including its own iBGP neighbors. The configuration follows the same pattern but uses the no-advertise community value:
R11 Configuration (AS 110):
ip prefix-list PL2 permit 112.112.112.0/24
!
route-map SETCOMM permit 5
match ip address prefix PL2
set community no-advertise
This is applied outbound toward R9 in the same route-map structure. Once R9 receives the route with the no-advertise community attached, it will keep the route in its own BGP table but will not send it to any peer.
| Community Value | eBGP Propagation | iBGP Propagation | Use Case |
|---|---|---|---|
| no-export | Blocked | Allowed | Keep route within the receiving AS |
| no-advertise | Blocked | Blocked | Keep route on the receiving router only |
Understanding when to use each community value is a critical BGP path selection skill. The no-export community is ideal when you want an entire AS to know about a route but not leak it further. The no-advertise community is appropriate when you need to restrict knowledge of a route to a single router.
How to Handle Private AS Numbers in BGP
Private AS numbers (64512-65534 in the 2-byte range) are commonly assigned to customer routers that peer with a service provider via eBGP. While they work perfectly for the customer-provider peering, they should not leak into the global BGP table or toward other providers. The remove-private-as command strips private AS numbers from the AS-path attribute before advertising routes to an eBGP neighbor.
Configuring a Customer with a Private AS
In this lab topology, R12 is a customer router using private AS 65012, peering with R8 in AS 800:
R8 Configuration (AS 800 -- Provider):
router bgp 800
neighbor 192.1.80.12 remote-as 65012
R12 Configuration (AS 65012 -- Customer):
router bgp 65012
neighbor 192.1.80.8 remote-as 800
network 12.0.0.0
At this point, when R8 advertises R12's 12.0.0.0 route toward AS 1000, the AS path will contain 65012 -- a private AS number that should not appear in the path seen by other autonomous systems.
Removing the Private AS
To clean up the AS path before advertising toward AS 1000, R8 is configured with:
R8 Configuration:
router bgp 800
neighbor 192.1.48.4 remove-private-as
This command instructs R8 to strip private AS numbers from the AS-path attribute in updates sent to the neighbor at 192.1.48.4 (in AS 1000). The resulting AS path seen by AS 1000 will show AS 800 only, with no trace of the private AS 65012.
Pro Tip: The
remove-private-ascommand only works when the AS path contains exclusively private AS numbers (aside from the local AS). If the path contains a mix of public and private AS numbers, the private AS numbers will not be removed by default on many IOS versions.
What Is the BGP Local-AS Feature and When Should You Use It?
The local-as command solves a specific operational challenge: an organization has migrated from one AS number to another, but certain BGP neighbors have not yet updated their peering configuration. The local-as feature allows a router to present a different (old) AS number to a specific neighbor while running BGP under its new AS number.
The Migration Scenario
Consider this progression from the lab:
- Initial state: R11 runs BGP under private AS 65011 and peers with R5 in AS 500.
- Migration: R11 acquires public AS 110 and needs to transition.
- Constraint: R5 cannot change its neighbor configuration for another five days (maintenance window).
- Requirement: R11 must establish a new eBGP peering with a new provider using AS 110 while maintaining the existing peering with R5 using AS 65011.
Initial Configuration -- R5 (AS 500):
router bgp 500
neighbor 192.1.50.11 remote-as 65011
Initial Configuration -- R11 (AS 65011):
router bgp 65011
neighbor 192.1.50.5 remote-as 500
network 11.0.0.0
R5 Private AS Removal toward AS 1000:
router bgp 500
neighbor 192.1.15.1 remove-private-as
After Migration with Local-AS
R11 removes the old BGP configuration and starts fresh under AS 110, but uses local-as to maintain backward compatibility with R5:
R11 Configuration (Post-Migration):
no router bgp 65011
router bgp 110
network 1.11.1.0 mask 255.255.255.0
neighbor 192.1.50.5 remote-as 500
neighbor 192.1.50.5 local-as 65011
With this configuration, R11 presents AS 65011 to R5 in its BGP OPEN message, so R5 continues to peer without any configuration change. Meanwhile, R11 is free to establish new peerings with other providers using its real AS number (110). Once R5 updates its configuration in the maintenance window to point at AS 110, the local-as statement can be removed.
| Feature | Purpose | Scope |
|---|---|---|
remove-private-as | Strip private ASNs from AS path | Per-neighbor outbound |
local-as | Present alternate AS number to a neighbor | Per-neighbor inbound/outbound |
Both features relate to AS number management but serve different purposes. The remove-private-as command cleans up the AS path in outbound updates. The local-as command changes the AS number the local router presents during BGP session establishment with a specific peer.
Configuring BFD for BGP: Achieving Sub-Second Failure Detection
Bidirectional Forwarding Detection (BFD) provides a lightweight, sub-second failure detection mechanism that operates independently of the routing protocol. By default, BGP relies on its own keepalive and hold timers for neighbor failure detection -- typically 60 seconds for keepalives and 180 seconds for the hold timer. In modern networks, three minutes of blackholing traffic is unacceptable. BFD closes this gap dramatically.
BFD Configuration for BGP Path Selection Resilience
The lab configures BFD across four eBGP peerings (R1-R5, R2-R6, R3-R7, R4-R8) using consistent parameters: a send and receive interval of 350 milliseconds, with a multiplier of 3 (meaning a neighbor is declared dead after 3 missed BFD hellos -- approximately 1.05 seconds).
R1 Configuration (AS 1000):
interface E0/2
bfd interval 350 min_rx 350 multiplier 3
!
router bgp 1000
neighbor 192.1.15.5 fall-over bfd
R5 Configuration (AS 500):
interface E0/0
bfd interval 350 min_rx 350 multiplier 3
!
router bgp 500
neighbor 192.1.15.1 fall-over bfd
The same pattern is applied to the remaining peerings:
R2 (AS 1000) to R6 (AS 600):
! R2
interface E0/2
bfd interval 350 min_rx 350 multiplier 3
!
router bgp 1000
neighbor 192.1.26.6 fall-over bfd
! R6
interface E0/0
bfd interval 350 min_rx 350 multiplier 3
!
router bgp 600
neighbor 192.1.26.2 fall-over bfd
R3 (AS 1000) to R7 (AS 700):
! R3
interface E0/2
bfd interval 350 min_rx 350 multiplier 3
!
router bgp 1000
neighbor 192.1.37.7 fall-over bfd
! R7
interface E0/0
bfd interval 350 min_rx 350 multiplier 3
!
router bgp 700
neighbor 192.1.37.3 fall-over bfd
R4 (AS 1000) to R8 (AS 800):
! R4
interface E0/2
bfd interval 350 min_rx 350 multiplier 3
!
router bgp 1000
neighbor 192.1.48.8 fall-over bfd
! R8
interface E0/0
bfd interval 350 min_rx 350 multiplier 3
!
router bgp 800
neighbor 192.1.48.4 fall-over bfd
Key BFD Configuration Details
There are two separate configuration steps for BFD with BGP:
- Interface-level: The
bfd intervalcommand sets the transmit interval, minimum receive interval, and the detection multiplier on the physical or logical interface facing the neighbor. - BGP-level: The
neighbor ... fall-over bfdcommand tells the BGP process to register with BFD for that specific neighbor. If BFD declares the neighbor down, BGP immediately tears down the session without waiting for the hold timer to expire.
| Parameter | Value in Lab | Meaning |
|---|---|---|
| interval | 350 ms | BFD hello transmit interval |
| min_rx | 350 ms | Minimum acceptable receive interval |
| multiplier | 3 | Number of missed hellos before declaring down |
| Detection time | ~1.05 seconds | 350 ms x 3 = 1050 ms |
Pro Tip: BFD must be configured on both sides of the peering. If only one side has BFD enabled, the BFD session will not establish, and BGP will fall back to its default hold-timer-based failure detection.
BFD dramatically improves convergence in any network that relies on BGP path selection to reroute traffic after a link failure. When a primary path fails, BFD triggers an immediate BGP session teardown, allowing the BGP best-path algorithm to select an alternate path in seconds rather than minutes.
BGP Confederations: Scaling iBGP Without Full Mesh
One of the most complex and heavily tested BGP topics on the CCIE EI exam is confederations. A BGP confederation divides a single autonomous system into multiple sub-autonomous systems. Within each sub-AS, routers peer via iBGP (and can use route reflectors to avoid a full mesh). Between sub-ASes, routers peer using a special type of eBGP that preserves iBGP-like behavior -- most importantly, the next-hop, MED, and local preference attributes are preserved across confederation eBGP boundaries.
Confederation Architecture from the Lab
The lab topology uses AS 1000 as the confederation identifier, divided into three sub-ASes:
| Sub-AS | Routers | Route Reflector | Underlay IGP |
|---|---|---|---|
| 65001 | R1, R4, R5 | R1 | EIGRP 65001 |
| 65002 | R2, R6, R7 | R2 | EIGRP 65002 |
| 65003 | R3, R8, R9 | R3 | EIGRP 65003 |
The inter-sub-AS connectivity runs between R1, R2, and R3 using EIGRP 1000 as the underlay IGP. This EIGRP process provides reachability between the sub-AS border routers.
Step 1: Configure the Underlay IGP Between Sub-AS Border Routers
Before any BGP confederation peering can work, the border routers (R1, R2, R3) need IP reachability to each other's loopback addresses. EIGRP AS 1000 handles this:
R1:
router eigrp 1000
network 192.168.12.0
network 192.168.13.0
network 172.16.1.0 0.0.0.255
R2:
router eigrp 1000
network 192.168.12.0
network 192.168.23.0
network 172.16.1.0 0.0.0.255
R3:
router eigrp 1000
network 192.168.13.0
network 192.168.23.0
network 172.16.1.0 0.0.0.255
Step 2: Configure the Underlay IGP Within Each Sub-AS
Each sub-AS runs its own EIGRP instance for internal reachability. For sub-AS 65001 (R1, R4, R5):
R1:
router eigrp 65001
network 192.168.14.0
network 192.168.15.0
network 172.16.1.0 0.0.0.255
R4:
router eigrp 65001
network 192.168.14.0
network 192.168.45.0
network 172.16.1.0 0.0.0.255
R5:
router eigrp 65001
network 192.168.15.0
network 192.168.45.0
network 172.16.1.0 0.0.0.255
The same pattern applies to sub-AS 65002 (R2, R6, R7 using EIGRP 65002) and sub-AS 65003 (R3, R8, R9 using EIGRP 65003). Each sub-AS advertises its internal links and Loopback 10 addresses into its own EIGRP process.
Step 3: Configure BGP Confederation with Route Reflectors
This is where the confederation-specific commands come into play. Each sub-AS must declare the confederation identifier (the real AS number visible to the outside world) and list its confederation peers (the other sub-ASes within the same confederation).
R1 Configuration (Sub-AS 65001, Route Reflector):
router bgp 65001
bgp confederation identifier 1000
bgp confederation peer 65002
network 1.0.0.0
neighbor IBGP peer-group
neighbor IBGP remote-as 65001
neighbor IBGP update-source Loopback10
neighbor IBGP next-hop-self
neighbor IBGP route-reflector-client
neighbor 172.16.1.4 peer-group IBGP
neighbor 172.16.1.5 peer-group IBGP
R4 Configuration (Sub-AS 65001, RR Client):
router bgp 65001
bgp confederation identifier 1000
network 4.0.0.0
neighbor 172.16.1.1 remote-as 65001
neighbor 172.16.1.1 update-source Lo10
neighbor 172.16.1.1 next-hop-self
R5 Configuration (Sub-AS 65001, RR Client):
router bgp 65001
bgp confederation identifier 1000
network 5.0.0.0
neighbor 172.16.1.1 remote-as 65001
neighbor 172.16.1.1 update-source Lo10
neighbor 172.16.1.1 next-hop-self
R2 Configuration (Sub-AS 65002, Route Reflector):
router bgp 65002
bgp confederation identifier 1000
bgp confederation peer 65001 65003
network 2.0.0.0
Notice that R2 lists both 65001 and 65003 as confederation peers because sub-AS 65002 (being centrally located) connects to both of the other sub-ASes. R1, on the other hand, only lists 65002 because it connects directly only to that sub-AS.
Key Confederation Concepts for CCIE
Understanding the following principles is essential for success with confederation questions on the CCIE exam:
bgp confederation identifier: This is the real AS number (1000 in our lab) that external peers see. All sub-ASes within the confederation use the same identifier.bgp confederation peer: Lists the sub-AS numbers that are part of the same confederation. Routes received from confederation peers are treated similarly to iBGP routes in terms of attribute handling.- Peer-groups: The lab uses a peer-group named IBGP to simplify configuration. All iBGP neighbors within the sub-AS share the same parameters (remote-as, update-source, next-hop-self, route-reflector-client).
- Route reflectors within sub-ASes: Each sub-AS designates one router as a route reflector (R1 for 65001, R2 for 65002, R3 for 65003), eliminating the need for a full iBGP mesh within each sub-AS.
update-source Loopback10: Peerings are established using Loopback 10 addresses for stability, since loopback interfaces do not go down unless the router itself fails.next-hop-self: Applied within each sub-AS so that the route reflector rewrites the next-hop attribute, ensuring clients can reach the next hop via the internal IGP.
Pro Tip: When designing a confederation, draw out the sub-AS topology and clearly identify which sub-ASes need to be listed as confederation peers on each border router. A common exam mistake is listing all sub-ASes on every router rather than only the directly connected ones.
BGP Route-Maps and Prefix Lists: The Policy Building Blocks
Throughout every advanced BGP configuration, two tools appear repeatedly: route-maps and prefix lists. These are the fundamental building blocks of BGP policy and are central to any BGP path selection manipulation.
Prefix List Mechanics
A prefix list matches routes based on their network address and prefix length. In the lab configurations, we see two examples:
ip prefix-list PL1 permit 111.0.0.0/8
ip prefix-list PL2 permit 112.112.112.0/24
- PL1 matches exactly the 111.0.0.0/8 prefix -- the network must be 111.0.0.0 with a mask of /8.
- PL2 matches exactly the 112.112.112.0/24 prefix.
Prefix lists are more efficient than access lists for route filtering because they are stored in a tree structure optimized for prefix matching.
Route-Map Structure
Route-maps are ordered sequences of match/set statements. Each sequence has a permit or deny action:
route-map SETCOMM permit 10
match ip address prefix PL1
set community no-export
route-map SETCOMM permit 20
- Sequence 10: If the route matches PL1, apply the no-export community and permit the route.
- Sequence 20: A bare permit with no match statement acts as a catch-all, permitting all other routes without modification.
The second sequence is critically important. Without it, the implicit deny at the end of the route-map would block all routes that do not match PL1. This is a frequent configuration error that can cause unexpected route filtering.
| Component | Purpose | Example |
|---|---|---|
| Prefix list | Match specific prefixes | ip prefix-list PL1 permit 111.0.0.0/8 |
| Route-map match | Select routes for policy | match ip address prefix PL1 |
| Route-map set | Apply attribute changes | set community no-export |
| Route-map permit (empty) | Catch-all for unmatched routes | route-map SETCOMM permit 20 |
Understanding BGP Conditional Advertisement
BGP conditional advertisement is another advanced feature covered in the CCIE EI lab track. This feature allows a router to advertise or withdraw a route based on the presence or absence of another route in the BGP table. It provides a mechanism for dynamic, condition-based routing policy that responds to changes in the network topology.
The conditional advertisement feature uses two route-maps:
- An advertise-map that identifies the routes to be conditionally advertised.
- A condition-map (either exist-map or non-exist-map) that specifies the condition that must be met (or not met) for the advertisement to occur.
This feature is particularly useful in multi-homed environments where you want to advertise a backup route only when the primary path is unavailable -- a sophisticated form of BGP path selection control.
BGP Multi-Path: eBGP and iBGP Load Sharing
By default, BGP selects a single best path for each prefix. However, in environments with multiple equal-cost paths, you may want to install multiple paths into the routing table for load sharing. BGP multi-path allows this for both eBGP and iBGP paths.
The CCIE EI lab track covers configuring BGP multi-path for both eBGP and iBGP scenarios. When multi-path is enabled, BGP can install multiple paths into the forwarding table while still selecting a single best path for advertisement to peers. This distinction is important: multi-path affects the local forwarding decision, not what the router advertises to its neighbors.
Multi-path configuration works hand-in-hand with the BGP path selection algorithm. The best-path algorithm still runs to select the single best path for advertisement, but additional paths that meet the multi-path criteria are also installed in the routing table for traffic forwarding purposes.
Redistributing iBGP Routes into IGP: Risks and Configuration
Redistributing iBGP routes into an IGP is generally discouraged because it can create routing loops. However, there are specific scenarios -- particularly in MPLS VPN environments or during migrations -- where this redistribution is necessary. The CCIE EI lab track includes this topic to ensure candidates understand both the configuration and the risks involved.
The key risk with iBGP-to-IGP redistribution is that the IGP may re-advertise routes back into BGP, creating a feedback loop. Administrative distance and route filtering must be carefully managed to prevent this. Understanding these interactions is part of the deeper BGP path selection knowledge expected at the CCIE level.
Lab Topology Reference: IP Addressing for Practice
For those building out these configurations in their own lab, the following table provides the complete IP addressing scheme used across the lab exercises. Having consistent, documented addressing makes troubleshooting significantly easier.
Core Routers (AS 1000 Confederation)
| Router | Loopback 0 | Loopback 10 | Key Interfaces |
|---|---|---|---|
| R1 | 1.1.1.1/8 | 172.16.1.1/32 | E0/0: 192.168.12.1, E0/1: 192.168.13.1, E0/2: 192.168.14.1, E0/3: 192.168.15.1 |
| R2 | 2.2.2.2/8 | 172.16.1.2/32 | E0/0: 192.168.12.2, E0/1: 192.168.23.2, E0/2: 192.168.26.2, E0/3: 192.168.27.2 |
| R3 | 3.3.3.3/8 | 172.16.1.3/32 | E0/0: 192.168.23.3, E0/1: 192.168.13.3, E0/2: 192.168.38.3, E0/3: 192.168.39.3 |
| R4 | 4.4.4.4/8 | 172.16.1.4/32 | E0/0: 192.168.14.4, E0/1: 192.168.45.4, E0/2: 192.1.40.4 |
| R5 | 5.5.5.5/8 | 172.16.1.5/32 | E0/0: 192.168.15.5, E0/1: 192.168.45.5, E0/2: 192.1.50.5 |
Provider and Customer Routers
| Router | AS | Loopback 0 | Interface |
|---|---|---|---|
| R6 | 600 | 6.6.6.6/8 | E0/0: 192.168.26.6, E0/1: 192.168.67.6, E0/2: 192.1.60.6 |
| R7 | 700 | 7.7.7.7/8 | E0/0: 192.168.27.7, E0/1: 192.168.67.7, E0/2: 192.1.70.7 |
| R8 | 800 | 8.8.8.8/8 | E0/0: 192.168.38.8, E0/1: 192.168.89.8, E0/2: 192.1.80.8 |
| R9 | 110 | 9.9.9.9/8 | E0/0: 192.168.39.9, E0/1: 192.168.89.9, E0/2: 192.1.90.9 |
| R10 | -- | 100.100.100.100/8 | E0/0: 192.1.40.10 |
| R11 | 110 | 111.111.111.111/8 | E0/0: 192.1.50.11 |
| R12 | 65012 | 112.112.112.112/8 | E0/0: 192.1.60.12 |
| R13 | -- | 113.113.113.113/8 | E0/0: 192.1.70.13 |
| R14 | -- | 114.114.114.114/8 | E0/0: 192.1.80.14 |
| R15 | -- | 115.115.115.115/8 | E0/0: 192.1.90.15 |
This topology provides a rich environment for practicing every aspect of BGP path selection manipulation, from community-based filtering to confederation peering and BFD-accelerated convergence.
Frequently Asked Questions
What is the difference between the no-export and no-advertise BGP communities?
The no-export community prevents a route from being advertised to eBGP peers but allows it to propagate within the local AS via iBGP. The no-advertise community is more restrictive -- it prevents the route from being advertised to any BGP peer, including iBGP neighbors. Use no-export when you want an entire AS to have the route but not leak it externally. Use no-advertise when you want only the directly receiving router to have the route.
Why do I need the send-community command for BGP communities to work?
By default, BGP strips community attributes from updates before sending them to neighbors. The send-community standard command explicitly tells the router to include standard community values in its BGP updates to a specific neighbor. Without this command on every relevant neighbor statement, community values set by route-maps will be silently removed and the downstream policy will have no effect.
What is the purpose of bgp confederation identifier versus bgp confederation peer?
The bgp confederation identifier command specifies the real AS number that the outside world sees -- in our lab, AS 1000. Every router in every sub-AS uses the same confederation identifier. The bgp confederation peer command lists the other sub-AS numbers that belong to the same confederation. A given router only needs to list the sub-ASes it directly peers with, not every sub-AS in the confederation.
How does BFD improve BGP convergence, and what timers should I use?
BFD provides sub-second failure detection independent of BGP's keepalive and hold timers. Without BFD, a BGP session typically takes up to 180 seconds (the default hold time) to detect a neighbor failure. With BFD configured at 350 ms intervals and a multiplier of 3 (as in our lab), failure detection drops to approximately 1.05 seconds. The neighbor ... fall-over bfd command under the BGP process registers the neighbor with BFD, and the bfd interval command on the interface sets the timing parameters.
When should I use the local-as command versus remove-private-as?
Use remove-private-as when you are a provider and want to strip a customer's private AS number from the AS path before advertising routes to your other peers. Use local-as when a router has migrated to a new AS number but needs to maintain backward compatibility with a neighbor that still expects the old AS number. The local-as command makes the router present the specified AS number in its BGP OPEN message to that specific neighbor.
Can I use route reflectors inside a BGP confederation sub-AS?
Yes, and this is the recommended approach demonstrated in the lab. Each sub-AS in the confederation uses a route reflector to avoid requiring a full iBGP mesh among all routers within that sub-AS. In the lab topology, R1 is the route reflector for sub-AS 65001, R2 for sub-AS 65002, and R3 for sub-AS 65003. The route reflector uses the route-reflector-client command under the peer-group or individual neighbor statements, and clients simply peer with the reflector using standard iBGP configuration.
Conclusion
Mastering BGP path selection and the advanced routing features covered in this article is essential for anyone preparing for the CCIE Enterprise Infrastructure exam. The topics we explored -- community attributes (no-export and no-advertise), private AS handling with remove-private-as, AS migration with local-as, sub-second failure detection with BFD, and the full confederation architecture with route reflectors -- represent the depth of knowledge the exam demands.
The key takeaways are:
- Community attributes give you granular control over route propagation without modifying the AS path. Always remember the
send-communitycommand. - Private AS removal keeps your AS paths clean when peering with customers who use private AS numbers.
- The local-as feature enables graceful AS migrations without requiring simultaneous changes on all peers.
- BFD reduces failure detection from minutes to approximately one second, dramatically improving convergence.
- Confederations with route reflectors scale iBGP while maintaining the appearance of a single AS to external peers.
- Route-maps and prefix lists are the policy tools that tie everything together -- mastering their syntax and sequence logic is fundamental.
Every configuration example in this article comes from hands-on lab exercises designed for CCIE-level preparation. To build a strong BGP foundation before tackling these advanced topics, explore the BGP Fundamentals course on NHPREP. For focused practice on path manipulation techniques, the BGP Path Selection course provides structured labs that reinforce these concepts through hands-on practice.