ExamFinch.com My Study

Study guide

10.2 BGP Path Attributes & Best Path Selection Algorithm

Practice this exam

CCNP Enterprise ENCOR 350-401

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Enterprise Architecture & Hierarchical Design

1.1 Enterprise Network Design Models & Hierarchical Campus Architecture 1.2 On-Premises, Cloud & Hybrid Infrastructure Deployment Models 1.3 Hardware Switching Architecture & Packet Forwarding

2 Chapter 2: Enterprise Quality of Service (QoS)

2.1 QoS Components: Classification, Marking & Trust Boundaries 2.2 QoS Policy: Queuing, Shaping, Policing & Interpreting MQC Output

3 Chapter 3: Software-Defined WAN (Catalyst SD-WAN)

3.1 Cisco Catalyst SD-WAN Architecture & Orchestration 3.2 SD-WAN Policies, Traffic Engineering & Application-Aware Routing

4 Chapter 4: Software-Defined Access (Catalyst SD-Access)

4.1 Catalyst SD-Access Fabric Architecture & Plane Separation 4.2 Cisco TrustSec, Security Group Tags (SGT), SXP & MACsec

5 Chapter 5: Device & Data Path Virtualization

5.1 Server & Network Device Virtualization 5.2 VRF-Lite & Virtual Routing Multi-Tenancy 5.3 GRE & IPsec Tunnel Virtualization Mechanics

6 Chapter 6: Network Virtualization & Overlay Technologies

6.1 LISP Architecture & EID-to-RLOC Mapping Mechanics 6.2 VXLAN & EVPN Overlay Architecture

7 Chapter 7: Layer 2 Infrastructure & Switching

7.1 VLANs, 802.1Q Trunking & VTPv3 7.2 Spanning Tree Protocol Mechanics 7.3 Advanced STP Protection Mechanisms 7.4 EtherChannel Link Aggregation

8 Chapter 8: Layer 3 Routing Foundations & EIGRP

8.1 IP Routing Foundations & Administrative Distance 8.2 Enhanced Interior Gateway Routing Protocol (EIGRP)

9 Chapter 9: OSPFv2 & OSPFv3 Operations

9.1 OSPFv2 Architecture & Neighbor State Machine 9.2 OSPF LSA Types & Multi-Area Design 9.3 OSPFv3 for IPv4 and IPv6 Address Families

10 Chapter 10: Border Gateway Protocol (BGP)

10.1 BGP Architecture, Neighbor States & Peering 10.2 BGP Path Attributes & Best Path Selection Algorithm

11 Chapter 11: Policy-Based Routing & Route Redistribution

11.1 Policy-Based Routing (PBR) & Route Maps 11.2 Route Redistribution & Loop Prevention

12 Chapter 12: IP Services & High Availability

12.1 First Hop Redundancy Protocols (HSRP, VRRP & GLBP) 12.2 Network Time Protocol (NTPv4) & Precision Time Protocol (PTP) 12.3 Network Address Translation (NAT/PAT) & VRF-Aware NAT

13 Chapter 13: IP Multicast Operations

13.1 IP Multicast Addressing, Group Management (IGMPv1/v2/v3) & IGMP Snooping 13.2 Protocol Independent Multicast (PIM-SM, PIM-SSM & Bidir-PIM) 13.3 Rendezvous Point (RP) Distribution Mechanisms

14 Chapter 14: Network Assurance & Monitoring

14.1 Diagnostic Utilities, Conditional Debugging & Path MTU Discovery 14.2 Syslog Architecture, Logging Facilities & Severity Levels 14.3 SNMPv1/v2c/v3 Security & Flexible NetFlow (FNF) Architecture 14.4 Switched Port Analyzer (SPAN, RSPAN, ERSPAN) & IP SLA Object Tracking

15 Chapter 15: Catalyst Center Assurance & Controller Operations

15.1 Cisco Catalyst Center (DNA Center) Assurance & AI Network Analytics 15.2 Cisco Catalyst Center Device Onboarding & Software Image Management (SWIM)

16 Chapter 16: Enterprise Security & Access Control

16.1 Device Hardening, AAA Architecture & RADIUS/TACACS+ 16.2 Access Control Lists (ACLs) for Infrastructure Security 16.3 Control Plane Policing (CoPP) & Control Plane Protection (CPPr) 16.4 Layer 2 Infrastructure Security Features 16.5 IEEE 802.1X Port-Based Authentication & MAB

17 Chapter 17: Threat Defense & API Security

17.1 Enterprise VPN Technologies (DMVPN Phase 1/2/3 & FlexVPN) 17.2 Next-Generation Threat Defense & Secure Access Service Edge (SASE)

18 Chapter 18: Network Automation, Programmability & Data Modeling

18.1 Python Fundamentals for Network Engineers & Cisco Libraries 18.2 YANG Data Modeling Language (RFC 6020/7950) & Model Types 18.3 REST API Architecture, HTTP Verbs, Security & Cisco Controller APIs 18.4 Model-Driven Telemetry (MDT) & NETCONF/RESTCONF Operations

19 Chapter 19: Orchestration, EEM & AI Operations

19.1 Configuration Management & Infrastructure as Code (Ansible & Terraform) 19.2 Cisco Embedded Event Manager (EEM) & Intent-Based Networking

10.2 BGP Path Attributes & Best Path Selection Algorithm

Key Takeaways Explain This Topic AI

BGP path attributes are classified into four distinct categories: Well-Known Mandatory (ORIGIN, AS_PATH, NEXT_HOP), Well-Known Discretionary (LOCAL_PREF, ATOMIC_AGGREGATE), Optional Transitive (COMMUNITY, AGGREGATOR), and Optional Non-Transitive (MED, ORIGINATOR_ID, CLUSTER_LIST).

The BGP Best Path Selection Algorithm evaluates candidate paths deterministically through a 13-step hierarchy, prioritizing Highest Weight (Cisco local, 0–65535), Highest Local Preference (AS-wide, default 100), Locally Injected routes, Shortest AS_PATH, Lowest Origin code (IGP < EGP < Incomplete), Lowest MED, eBGP over iBGP, Lowest IGP metric to Next-Hop, and tie-breakers.

Weight is local to a single router and never propagated in BGP updates, whereas Local Preference is advertised throughout the entire Autonomous System across all iBGP peers to control outbound traffic egress points.

Multi-Exit Discriminator (MED) is an optional non-transitive attribute sent across eBGP boundaries to influence how external neighbors enter the local Autonomous System, by default compared only between paths from the same neighboring AS unless 'bgp always-compare-med' is enabled.

Route Reflectors (RR) and BGP Confederations overcome the N ( N − 1 ) / 2 N(N-1)/2 N ( N − 1 ) /2 iBGP full-mesh scaling limitation: Route Reflectors forward iBGP routes using ORIGINATOR_ID and CLUSTER_LIST attributes for loop prevention, while Confederations divide an AS into private sub-AS domains.

Last updated: August 2026

10.2 BGP Path Attributes & Best Path Selection Algorithm

Unlike Interior Gateway Protocols that compute routing metrics based solely on link bandwidth or composite delays, Border Gateway Protocol is an administrative policy engine. BGP attaches rich metadata—termed Path Attributes (PAs) —to every Network Layer Reachability Information (NLRI) prefix advertised in an UPDATE message. By systematically evaluating these path attributes through a deterministic 13-step decision algorithm , BGP selects a single best path to install into the Routing Information Base (RIB) and advertise to downstream peers. +-----------------------------------------------------------------------------------+

  • | BGP PATH ATTRIBUTE CLASSIFICATION |
  • +-----------------------------------------------------------------------------------+
  • | |
  • | 1. WELL-KNOWN MANDATORY |
  • | - Must be recognized by ALL standard BGP implementations. |
  • | - MUST be included in EVERY BGP UPDATE message. |
  • | - Attributes: ORIGIN (Type 1), AS_PATH (Type 2), NEXT_HOP (Type 3) |
  • | |
  • | 2. WELL-KNOWN DISCRETIONARY |
  • | - Must be recognized by ALL standard BGP implementations. |
  • | - OPTIONAL to include in UPDATE messages (sent only when relevant). |
  • | - Attributes: LOCAL_PREF (Type 5), ATOMIC_AGGREGATE (Type 6) |
  • | |
  • | 3. OPTIONAL TRANSITIVE |
  • | - May or may not be recognized by all BGP implementations. |
  • | - If unrecognized, the router MUST ACCEPT and FORWARD it to downstream peers. |
  • | - Attributes: COMMUNITY (Type 8), AGGREGATOR (Type 7) |
  • | |
  • | 4. OPTIONAL NON-TRANSITIVE |
  • | - May or may not be recognized by all BGP implementations. |
  • | - If unrecognized, the router SILENTLY DISCARDS the attribute. |
  • | - Recognized attributes are NEVER forwarded outside the local AS. |
  • | - Attributes: MED / MULTI_EXIT_DISC (Type 4), ORIGINATOR_ID (9), CLUSTER_LIST (10)|
  • | |
  • +-----------------------------------------------------------------------------------+
  • 1. Path Attribute Classifications & Taxonomy

Every BGP path attribute falls into one of four standardized categories defined in RFC 4271 based on two criteria: whether recognition is mandatory across all vendors, and whether unrecognized attributes must be propagated to downstream peers.

Comprehensive BGP Path Attributes Reference Table

Attribute Name Code Category Scope / Propagation Architectural Purpose

ORIGIN 1 Well-Known Mandatory Global (All peers) Identifies how the route was injected (IGP i , EGP e , Incomplete ? ).

AS_PATH 2 Well-Known Mandatory Global (All peers) Ordered sequence of Autonomous System Numbers traversed.

NEXT_HOP 3 Well-Known Mandatory Global (All peers) Next-hop IP address to reach the destination prefix.

MED (Multi-Exit Disc) 4 Optional Non-Transitive Single Egress AS Influences inbound traffic from a neighboring AS (metric).

LOCAL_PREF 5 Well-Known Discretionary Local AS Only (iBGP) Influences outbound egress path selection for the entire AS.

ATOMIC_AGGREGATE 6 Well-Known Discretionary Global (All peers) Flags that NLRI prefixes were summarized and path details lost.

AGGREGATOR 7 Optional Transitive Global (All peers) Specifies the BGP Router ID and ASN of the aggregating router.

COMMUNITY 8 Optional Transitive Global / Policy Numeric tags ( AS:val ) used for granular routing policy application.

ORIGINATOR_ID 9 Optional Non-Transitive Local AS Only (iBGP) Loop prevention in Route Reflector topologies (carries creator RID).

CLUSTER_LIST 10 Optional Non-Transitive Local AS Only (iBGP) Loop prevention in Route Reflector topologies (records RR cluster IDs).

WEIGHT — Cisco Proprietary Local Router Only Highest priority path selector (never transmitted in BGP updates).

Loading diagram... BGP 13-Step Best Path Selection Algorithm Decision Pipeline

2. The Comprehensive 13-Step BGP Best Path Selection Algorithm

When a BGP router receives multiple candidate routes for the exact same destination prefix and prefix length, it evaluates the paths sequentially through the following 13-step hierarchy until a single winner is determined. +-----------------------------------------------------------------------------------+

  • | BGP BEST PATH SELECTION MEMONIC / SUMMARY |
  • +-----------------------------------------------------------------------------------+
  • | MNEMONIC: "We Love Really Sophisticated Organizations, Never Ever Lowering Old |
  • | Route-reflector Cluster Numbers" |
  • +-----------------------------------------------------------------------------------+
  • | 0. Prerequisite : Next-Hop Reachability (Must be reachable via IGP / RIB) |
  • | 1. W : Highest WEIGHT (Cisco local: 0 to 65,535; default 32,768/0) |
  • | 2. L : Highest LOCAL_PREFERENCE (AS-wide: default 100) |
  • | 3. R (Originate): Locally Originated (network/redistribute > aggregate-address) |
  • | 4. S (AS-Path) : Shortest AS_PATH length (AS_SET counts as 1) |
  • | 5. O (Origin) : Lowest ORIGIN code (IGP 'i' < EGP 'e' < Incomplete '?') |
  • | 6. N (MED) : Lowest MULTI_EXIT_DISCRIMINATOR (MED, default 0) |
  • | 7. E (eBGP) : Prefer eBGP over iBGP paths |
  • | 8. L (IGP Cost) : Lowest IGP metric to BGP Next-Hop (Shortest internal exit) |
  • | 9. Multi-Path : Maximum-Paths installed if ECMP configured |
  • | 10. O (Oldest) : Oldest (most stable) eBGP path |
  • | 11. R (Router ID): Lowest BGP Router ID of advertising peer (or Originator ID) |
  • | 12. C (Cluster) : Shortest CLUSTER_LIST length (Route Reflector environment) |
  • | 13. N (Neighbor) : Lowest Neighbor IP Address (peering address) |
  • +-----------------------------------------------------------------------------------+
  • Detailed Step-by-Step Analysis

Step 0: Next-Hop Reachability (Prerequisite): Before evaluating any path attributes, BGP verifies that the IP address specified in the NEXT_HOP attribute is resolvable in the local Routing Information Base (RIB). If the next-hop is unreachable, the route is marked inaccessible ( r RIB-failure or non-valid) and immediately disqualified.

Step 1: Highest Weight (Cisco Proprietary):

Scope: Strictly local to the router ; never transmitted in BGP updates to any peer.

Value Range: 0 to 65,535 . Routes originated locally default to 32,768 ; routes learned from peers default to 0 .

Higher values are preferred.

Step 2: Highest Local Preference ( LOCAL_PREF ):

Scope: AS-wide ; advertised to all iBGP peers within the local AS, but stripped from updates sent to external eBGP peers.

Value Range: 0 to 4,294,967,295 . Default value is 100 ( bgp default local-preference <val> ).

Primary tool for influencing outbound egress traffic from the local Autonomous System.

Step 3: Prefer Locally Injected Routes:

Paths originated locally on the router are preferred over paths learned from peers.

Order of precedence among local routes: network / redistribute > aggregate-address \text{network} \; / \; \text{redistribute} \; > \; \text{aggregate-address} network / redistribute > aggregate-address

Step 4: Shortest AS_PATH Length:

Evaluates the number of autonomous systems listed in the AS_PATH attribute.

An AS_SEQUENCE (e.g., 100 200 300 ) counts each ASN as 1 hop (total length 3).

An AS_SET (unordered set generated during route aggregation, e.g., {100, 200} ) counts as 1 single hop , regardless of how many ASNs are in the set.

Can be bypassed globally via bgp bestpath as-path ignore (not recommended in production).

Step 5: Lowest Origin Code:

Evaluates how the prefix was initially introduced into BGP. Order of preference:

IGP ( i ): Injected via the network command under BGP (Most Preferred).

EGP ( e ): Learned via the legacy Exterior Gateway Protocol (Historical).

Incomplete ( ? ): Injected via redistribute from another protocol (Least Preferred).

Step 6: Lowest Multi-Exit Discriminator (MED / Metric):

Scope: Optional Non-Transitive attribute sent to external AS peers to influence their inbound ingress path into the local AS.

Value Range: 0 to 4,294,967,295 . Lower values are preferred (default is 0 ).

The Comparison Rule: By default, BGP only compares MED values if the routes were received from the EXACT SAME neighboring Autonomous System (first ASN in AS_PATH matches). To force comparison across routes from different ASNs, configure bgp always-compare-med .

Step 7: Prefer eBGP over iBGP:

An external eBGP path is preferred over an internal iBGP path. Within confederations, the hierarchy is: eBGP Path > Confederation External Path > iBGP Path \text{eBGP Path} \; > \; \text{Confederation External Path} \; > \; \text{iBGP Path} eBGP Path > Confederation External Path > iBGP Path

Step 8: Lowest IGP Metric to BGP Next-Hop:

Evaluates the internal IGP route cost (OSPF cost or EIGRP metric) required to reach the BGP NEXT_HOP IP address. This implements "hot-potato routing" , directing packets to the closest egress border router to offload transit traffic immediately.

Step 9: Multipath (ECMP) Evaluation:

If maximum-paths <n> (for eBGP) or maximum-paths ibgp <n> (for iBGP) is configured and candidate routes tie on steps 1 through 8, BGP installs multiple equal-cost paths into the forwarding table (FIB).

Step 10: Oldest (Most Stable) eBGP Route:

For eBGP paths, BGP prefers the route that has been present the longest to prevent route flapping. This step is skipped if bgp bestpath compare-routerid is enabled.

Step 11: Lowest BGP Router ID (RID):

Prefers the route advertised by the peer with the lowest numeric 32-bit BGP Router ID. If a Route Reflector is present, the ORIGINATOR_ID replaces the advertising router's RID in this comparison.

Step 12: Shortest Cluster List Length:

In Route Reflector networks, BGP prefers the path that has traversed the fewest Route Reflector clusters ( CLUSTER_LIST length).

Step 13: Lowest Neighbor IP Address:

The final deterministic tie-breaker: prefers the path received from the peer with the lowest numerical IP address defined in the neighbor statement.

3. Administrative Traffic Engineering: Attributes in Practice

Network architects manipulate specific BGP attributes depending on whether they need to control outbound (egress) or inbound (ingress) enterprise traffic flows. +-----------------------------------------------------------------------------------+

  • | BGP TRAFFIC STEERING MATRIX |
  • +-----------------------------------------------------------------------------------+
  • | OBJECTIVE | PRIMARY ATTRIBUTE | SECONDARY ATTRIBUTE | SCOPE |
  • +-----------------------------+-------------------+---------------------+-----------|
  • | Control Outbound (Egress) | LOCAL_PREF (100) | WEIGHT (Cisco only) | AS / Local|
  • | Control Inbound (Ingress) | AS-PATH Prepend | MED (Metric) | Inter-AS |
  • | Granular Policy Tagging | COMMUNITY | EXTENDED COMMUNITY | Policy |
  • +-----------------------------------------------------------------------------------+

1. Controlling Outbound Traffic: Local Preference vs. Weight ! Example 1: Use Weight (Local Router Scope) to prefer Primary ISP

  • Edge-1(config)# route-map SET-WEIGHT-PRIMARY permit 10
  • Edge-1(config-route-map)# set weight 50000
  • Edge-1(config)# router bgp 65001
  • Edge-1(config-router-af)# neighbor 203.0.113.2 route-map SET-WEIGHT-PRIMARY in
  • ! Example 2: Use Local Preference (AS-Wide Scope) to steer all internal routers to Primary ISP
  • Edge-1(config)# route-map SET-LP-PRIMARY permit 10
  • Edge-1(config-route-map)# set local-preference 200
  • Edge-1(config)# router bgp 65001
  • Edge-1(config-router-af)# neighbor 203.0.113.2 route-map SET-LP-PRIMARY in

2. Controlling Inbound Traffic: AS-Path Prepending vs. MED ! Example 1: AS-Path Prepending on Secondary ISP (Makes path 3 hops longer to external peers)

  • Edge-2(config)# route-map PREPEND-BACKUP permit 10
  • Edge-2(config-route-map)# set as-path prepend 65001 65001 65001
  • Edge-2(config)# router bgp 65001
  • Edge-2(config-router-af)# neighbor 198.51.100.2 route-map PREPEND-BACKUP out
  • ! Example 2: Set MED to 50 on Primary Link and 100 on Secondary Link to same ISP AS 65100
  • Edge-1(config)# route-map SET-MED-PRIMARY permit 10
  • Edge-1(config-route-map)# set metric 50
  • Edge-1(config)# router bgp 65001
  • Edge-1(config-router-af)# neighbor 203.0.113.2 route-map SET-MED-PRIMARY out
  • 3. BGP Communities (RFC 1997)

A BGP Community is a 32-bit attribute formatted as AA:NN (where AA is the AS number and NN is a policy integer). BGP defines four well-known communities:

no-export ( 0xFFFFFF01 ): Do not advertise this route to external eBGP peers (retained within local AS / sub-confederation).

no-advertise ( 0xFFFFFF02 ): Do not advertise this route to any peer (neither eBGP nor iBGP).

local-AS / no-export-subconfed ( 0xFFFFFF03 ): Do not advertise this route outside the local sub-confederation AS.

internet ( 0x00000000 ): Standard community; advertise to all peers.

Loading diagram... BGP Route Reflector Architecture and Reflection Rules

4. Scaling iBGP: Route Reflectors & Confederations

To overcome the quadratic N ( N − 1 ) / 2 N(N-1)/2 N ( N − 1 ) /2 full-mesh iBGP scaling barrier, enterprise networks deploy BGP Route Reflectors or BGP Confederations .

1. BGP Route Reflectors (RFC 4456)

A Route Reflector (RR) is a central BGP router that is permitted to re-advertise (reflect) routes learned from one iBGP peer to other iBGP peers, eliminating the need for a full mesh of internal sessions.

The Three Peering Classifications

Route Reflector Server: The router configured with reflection policies.

RR Client: An iBGP neighbor designated as a client using neighbor <ip> route-reflector-client on the RR. (The client itself requires no special RR configuration; it operates as a standard iBGP peer).

Non-Client: A standard iBGP peer that is not configured as an RR client.

The Three Deterministic Reflection Rules +-----------------------------------------------------------------------------------+

  • | ROUTE REFLECTION PROPAGATION RULES |
  • +-----------------------------------------------------------------------------------+
  • | SOURCE OF ROUTE | REFLECTED TO CLIENTS? | REFLECTED TO NON-CLIENTS?|
  • +--------------------------------+-----------------------+--------------------------|
  • | Learned from eBGP Peer | YES | YES |
  • | Learned from RR Client | YES | YES |
  • | Learned from Non-Client | YES | NO (Split-Horizon preserved)|
  • +-----------------------------------------------------------------------------------+

Core Principle: Routes learned from a Non-Client are never reflected to other Non-Clients . Non-Clients must maintain a full mesh of iBGP sessions among themselves!

Route Reflector Loop Prevention Mechanisms

Because Route Reflectors bypass the iBGP split-horizon rule, BGP introduces two specialized path attributes to prevent internal routing loops:

ORIGINATOR_ID (Attribute Type 9, Optional Non-Transitive):

A 4-byte attribute created by the first RR that reflects a route. It carries the BGP Router ID of the originating router in the local AS that first injected the prefix.

If a router receives an iBGP update where the ORIGINATOR_ID matches its own local Router ID, it immediately drops the update .

CLUSTER_LIST (Attribute Type 10, Optional Non-Transitive):

A sequence of Cluster IDs ( bgp cluster-id <id> , default: RR's Router ID) representing the path of Route Reflectors through which the route has passed.

When an RR reflects a route, it prepends its local Cluster ID to the CLUSTER_LIST .

If an RR receives an update containing its own Cluster ID within the CLUSTER_LIST , it knows the route has looped and silently discards it .

2. BGP Confederations (RFC 5065)

A BGP Confederation divides a massive Autonomous System (e.g., AS 65000) into multiple smaller, private Sub-Autonomous Systems (e.g., Sub-AS 65001, 65002, 65003).

External Perspective: Outside external eBGP peers see only the single public Confederation Identifier (AS 65000). The internal sub-AS structure is completely hidden.

Intra-Confederation Peering: Peering sessions between sub-ASes (e.g., Sub-AS 65001 to Sub-AS 65002) behave like eBGP for loop prevention (recording sub-AS numbers in an AS_CONFED_SEQUENCE inside AS_PATH), but preserve NEXT_HOP , LOCAL_PREF , and MED attributes exactly like iBGP.

Confederation Stripping: When an edge router advertises a route to a true external eBGP peer, all sub-AS numbers ( AS_CONFED_SEQUENCE / AS_CONFED_SET ) are automatically stripped from the AS_PATH.

5. Cisco IOS-XE Configuration & Route Reflector Verification

1. Core Route Reflector Configuration (IOS-XE) ! Configure Central Route Reflector (Core-RR, Cluster ID 10.0.0.1)

  • Core-RR(config)# router bgp 65001
  • Core-RR(config-router)# bgp router-id 10.0.0.1
  • Core-RR(config-router)# bgp cluster-id 10.0.0.1
  • Core-RR(config-router)# no bgp default ipv4-unicast
  • ! Define Client Neighbors
  • Core-RR(config-router)# neighbor 10.1.1.1 remote-as 65001
  • Core-RR(config-router)# neighbor 10.1.1.1 update-source Loopback0
  • Core-RR(config-router)# neighbor 10.2.2.2 remote-as 65001
  • Core-RR(config-router)# neighbor 10.2.2.2 update-source Loopback0
  • ! Define Non-Client Core Neighbor
  • Core-RR(config-router)# neighbor 10.3.3.3 remote-as 65001
  • Core-RR(config-router)# neighbor 10.3.3.3 update-source Loopback0
  • ! Configure IPv4 Unicast Address Family with RR Clients
  • Core-RR(config-router)# address-family ipv4 unicast
  • Core-RR(config-router-af)# neighbor 10.1.1.1 activate
  • Core-RR(config-router-af)# neighbor 10.1.1.1 route-reflector-client
  • Core-RR(config-router-af)# neighbor 10.2.2.2 activate
  • Core-RR(config-router-af)# neighbor 10.2.2.2 route-reflector-client
  • Core-RR(config-router-af)# neighbor 10.3.3.3 activate
  • Core-RR(config-router-af)# exit-address-family
  • 2. Route Reflector BGP Prefix Inspection ( show ip bgp <prefix> ) Core-RR# show ip bgp 198.51.100.0/24
  • BGP routing table entry for 198.51.100.0/24, version 8
  • Paths: (1 available, best #1, table default)

Advertised to update-groups:

  • 1 2
  • Refresh Epoch 1
  • 65100
  • 10.1.1.1 (metric 20) from 10.1.1.1 (1.1.1.1)
  • Origin IGP, metric 0, localpref 100, valid, internal, best
  • Originator: 1.1.1.1, Cluster list: 10.0.0.1
  • rx path info: flag 0x41, msgflags 0x0, prio 0