Cisco 300-410: BGP Policy, Scalability and Path Selection — Study Guide

By Laurynas Brazys · 16 August 2026 · #cisco #300-410 #certification #exam-prep #study-guide

Part of the Cisco CCNP Enterprise 300-410 ENARSI — Study Guide. Practice with verified answers in the Cisco exam hub, or take timed practice tests on ExamRoll.io.

Overview

Border Gateway Protocol (BGP) governs interdomain routing policy and scalable distribution of reachability. Designing resilient sessions, understanding next-hop and update behavior, and applying policy with full awareness of the best-path algorithm are foundational. At scale, iBGP relies on route reflectors or confederations, while advanced tools such as conditional advertisement, default-origination, multipath, and dampening refine behavior. This section details the operational mechanics, design trade-offs, and failure modes you must anticipate, and provides a systematic troubleshooting approach for both missing prefixes and unexpected path selection.

Session Design and Neighbor Establishment

• eBGP vs. iBGP adjacency
  • eBGP peers are in different ASNs and by default use TTL 1, requiring single-hop adjacency unless configured otherwise.
  • iBGP peers are in the same ASN and require a full mesh or a scaling alternative (route reflectors or confederations). iBGP uses TTL 255, and sessions frequently use loopback interfaces for stability.
• TCP reachability and BGP FSM
  • BGP runs over TCP port 179; session formation depends on generic IP/TCP reachability and the BGP finite state machine (Idle → Connect/Active → OpenSent → OpenConfirm → Established).
  • Common blockers: ACLs/firewalls on TCP/179, Control-Plane Policing (CoPP) that rate-limits BGP, and asymmetric routing that breaks TCP.
  • Practical check: show ip bgp summary; if flapping, inspect show policy-map control-plane to validate CoPP. During policy validation, set conform/exceed actions to transmit to avoid unintended drops.
• Authentication and TTL hardening
  • MD5 authentication (neighbor x password y) protects against spoofed sessions; mismatches hold the session in Active.
  • GTSM/TTL security (neighbor x ttl-security hops n) mitigates CPU-based attacks; do not combine it with ebgp-multihop on the same neighbor.
• Loopback peering, update-source, and multihop
  • Loopback-to-loopback peering is more resilient to interface failures; require unique sourcing and TTL extension:
    • neighbor 203.0.113.2 update-source Loopback0
    • neighbor 203.0.113.2 ebgp-multihop 2
  • Ensure unicast reachability to loopbacks via static or IGP. Lack of recursion to the loopback silently prevents establishment.
• Next-hop processing and next-hop-self
  • eBGP sets next hop to the advertising neighbor by default.
  • iBGP does not change next hop by default; edge routers must set next-hop-self on iBGP to avoid third-party next-hop blackholes.
    • address-family ipv4 neighbor 10.0.0.2 next-hop-self

Next-Hop Processing and Best-Path Selection

BGP best-path selection on Cisco platforms (high to low significance):

1. Weight (Cisco-only, local to router; higher is preferred). Defaults: 32768 for locally injected routes, 0 otherwise.
2. Local Preference (intra-AS; higher is preferred). Default 100; propagated in iBGP.
3. Locally originated (network/aggregate/redistribute) preferred over learned.
4. AS-path length (shorter is preferred). Prepending increases perceived distance.
5. Origin code (IGP < EGP < Incomplete).
6. MED (lower is preferred). Compared only among paths from the same neighboring AS unless bgp always-compare-med is enabled; bgp deterministic-med ensures consistent MED comparison across peers.
7. Prefer eBGP over iBGP.
8. Lowest IGP metric to BGP next hop (hot-potato).
9. Prefer oldest route to reduce churn (if enabled, subject to dampening/multipath).
10. Tie-breakers: minimum cluster-list length, lowest originator-ID, lowest neighbor BGP router-ID, and finally lowest neighbor IP address.

Design notes and pitfalls:

• Next-hop reachability is foundational. A path can win in BGP but still fail CEF recursion if the next hop is unresolved.
• When advertising into iBGP after learning from eBGP, do not forget next-hop-self; otherwise iBGP routers may see an unreachable eBGP next hop and drop traffic.
• MED is often misunderstood; without always-compare-med, MED across different neighbor ASes will not be evaluated, leading to seemingly “ignored” values.

Policy Tools: Attributes, Communities, and Filtering

• Local Preference, Weight, AS-path prepending, MED
  • Prefer a low-delay ISP by raising LOCAL_PREF for those routes (for example, set local-preference 200). This changes outbound traffic selection throughout the AS without touching the IP data plane.
  • Weight is local only; use for router-specific preferences (neighbor 198.51.100.1 weight 50 or via route-map set weight).
  • AS-path prepending (set as-path prepend 65000 65000 …) makes a path less attractive inbound to your AS by increasing perceived distance. Apply selectively; overuse reduces reachability.
  • MED (set metric) suggests an egress into your AS to your neighbor. Its effect is neighbor-policy dependent.
• Community policy
  • Sending communities is not automatic; enable with neighbor x send-community [both | extended].
  • Well-known communities: no-export, no-advertise, internet, local-AS, and no-export-subconfed (useful with confederations).
  • Standard communities are 32-bit values (AA:NN format with ip bgp community new-format).
  • Extended communities (64-bit) carry additional semantics (for example, route-targets in VPNv4).
  • Large communities (96-bit, A:B:C) provide scalability and clarity in 4-byte ASNs.
  • Example: match community and set attributes
    • ip community-list standard PREFERED permit 65000:100
    • route-map INBOUND-POLICY permit 10 match community PREFERED set local-preference 200
• Prefix and AS-path filtering
  • ip prefix-list controls NLRI granularity; as-path access-list uses regex to constrain AS paths. Both are attached with route-maps or directly with neighbor … prefix-list/as-path access-group.
  • Inbound vs. outbound:
    • Inbound filtering shapes what enters your BGP table and influences best-path.
    • Outbound filtering controls what you advertise; a misapplied outbound route-map can unexpectedly alter attributes on locally originated routes (for example, prepending the local AS on all advertisements causes external neighbors to see your prefix as two AS hops away rather than one). Always constrain route-maps with explicit matches.
  • Minimal, targeted policy reduces churn and avoids blackholing. Always include a final permit in prefix-lists to avoid unintended denials.

Short, targeted configuration examples:

• Increase local preference for routes from ISP-A:
  • route-map SET-LP permit 10 set local-preference 200
  • neighbor 203.0.113.1 route-map SET-LP in
• AS-path prepend for a specific outbound advertisement:
  • ip prefix-list OUT-ONLY permit 192.0.2.0/24
  • route-map PREPEND permit 10 match ip address prefix-list OUT-ONLY set as-path prepend 65000 65000
  • neighbor 198.51.100.1 route-map PREPEND out

Scaling iBGP and Advanced Behaviors

• Route reflectors (RRs)
  • Replace the iBGP full mesh by designating RRs that reflect routes between clients and non-clients. Loops are prevented with originator-ID and cluster-list attributes.
  • Cluster ID defaults to the RR’s router ID; when multiple RRs exist, use unique cluster IDs to prevent persistent loops and to improve path diversity.
  • Trade-offs: RRs can cause suboptimal path selection (path hiding). Mitigate with client placement, diverse clusters, add-path, and tuning bestpath knobs.
• Confederations
  • Partition a large AS into sub-ASes that speak eBGP internally but appear as a single AS externally.
  • Pros: reduces iBGP mesh and policy blast-radius; Cons: operational complexity, and potential MED/next-hop subtleties across sub-AS boundaries.
• Conditional advertisement and defaults
  • Conditional advertisement lets you advertise a route only when some other route is absent/present.
    • router bgp 65000 neighbor 198.51.100.1 advertise-map ADV non-exist-map PRIMARY route-map ADV permit 10 match ip address prefix-list DEFAULT route-map PRIMARY permit 10 match ip address prefix-list PRIMARY-PFXS
  • Default-origination:
    • neighbor 198.51.100.1 default-originate [route-map RM] advertises 0.0.0.0/0 regardless of having it in the RIB (with RM controlling conditions). Alternatively, network 0.0.0.0 requires a matching RIB route.
• Multipath
  • Load share across multiple equal-cost BGP paths with maximum-paths [ebgp|ibgp] n. Use bgp bestpath as-path multipath-relax to allow eBGP multipath across different AS-paths under controlled conditions. In MPLS L3VPNs, maximum-paths ibgp n enables PE-to-PE ECMP.
• Route recursion and RIB failures
  • BGP installs a path only if the next hop can recurse to a valid forwarding entry and no route with a lower administrative distance already owns the prefix.
  • Common RIB-failure causes:
    • Better AD route exists (connected/static/IGP).
    • Next hop unresolved (no IGP/static route to next hop).
    • Longer, more specific route is present (traffic matches the more specific).
  • Useful checks: show ip bgp , show ip bgp rib-failure, show ip route [vrf NAME] , and CEF lookups for recursion validation.
• Dampening
  • bgp dampening penalizes flapping prefixes and suppresses them until stable. Parameters: half-life, reuse, suppress, max-suppress-time.
  • Trade-offs: can hide legitimate recovery and slow convergence. Apply narrowly to unstable edges, and avoid dampening core reachability or customer-critical space.

Systematic troubleshooting (missing prefixes and wrong paths):

1. Verify BGP session health: show ip bgp summary; if flapping, inspect CoPP and TCP/179 reachability.
2. Confirm policy admission: show ip bgp neighbors x received-routes/advertised-routes; ensure soft-reconfiguration or route refresh when needed.
3. Validate next-hop: show ip bgp and show ip route [vrf NAME] ; fix IGP/recursion before tuning attributes.
4. Check filters: prefix-lists, as-path access-lists, and communities; confirm neighbor send-community.
5. Inspect attributes: weight/local-pref/AS-path/origin/MED; enable deterministic/always-compare MED where appropriate.
6. Examine RIB-failure and specificity: a connected/static/IGP route with lower AD or a more-specific route will override BGP.
7. Confirm scale mechanisms: on RRs, watch for path hiding and cluster-list loops; on confeds, validate no-export-subconfed usage.

Practical Problem Scenario

Acme Manufacturing operates AS 65010 with two ISPs: ISP-A (low delay) and ISP-B (backup). Acme runs iBGP across three core routers with two route reflectors and advertises 203.0.113.0/24. After adding an outbound route-map on the ISP-B edge, remote sites report increased latency and some paths prefer ISP-B unexpectedly.

Approach:

1. Confirm session and policy health

   • show ip bgp summary and show policy-map control-plane to ensure no BGP flaps due to CoPP. Rationale: unstable control plane produces churn that masks policy effects.

2. Verify next-hop reachability

   • show ip bgp 203.0.113.0/24 and show ip route . Rationale: next-hop recursion must succeed before attributes matter.

3. Inspect outbound policy on ISP-B

   • show run | sec router bgp; review neighbor … route-map OUT out. Rationale: broad route-maps can inadvertently modify all announced prefixes, including locally originated ones.

4. Constrain AS-path prepending to targeted NLRI

   • ip prefix-list ACME-PUB permit 203.0.113.0/24
   • route-map B-PREPEND permit 10 match ip address prefix-list ACME-PUB set as-path prepend 65010 65010 65010
   • route-map B-PREPEND permit 20
   • neighbor 198.51.100.2 route-map B-PREPEND out Rationale: Specific matching limits prepending to the intended prefix and avoids altering attributes of other announcements. The explicit permit 20 ensures unmatched routes are not dropped.

5. Prefer ISP-A globally for outbound traffic

   • route-map SETLP permit 10 set local-preference 200
   • neighbor 203.0.113.1 route-map SETLP in Rationale: LOCAL_PREF influences egress choice across the entire AS (higher is better) and is the cleanest lever to prefer the low-delay ISP.

6. Ensure communities propagate intended behavior

   • ip community-list standard AVOID-B permit 65010:90
   • route-map TAG-B permit 10 match ip address prefix-list ACME-PUB set community 65010:90 additive
   • neighbor 198.51.100.2 send-community Rationale: Tagging allows downstream policy decisions (for example, RR-based preference) and requires send-community to propagate.

7. Validate RR behavior and avoid path hiding

   • On both RRs, confirm unique cluster-ids and client assignments; enable bgp additional-paths send receive select best 2 where supported. Rationale: In a multi-exit environment, RRs can hide a better path. Additional-paths or careful client topology reduces suboptimality.

8. Verify outcomes and install state

   • show ip bgp 203.0.113.0/24 to confirm weight/local-pref/AS-path/MED; confirm eBGP over iBGP selection and IGP metric to next hop.
   • show ip bgp rib-failure to ensure the chosen path installs in the RIB. Rationale: Confirms that both the control and data planes reflect the intended design.

This sequence corrects the unintended AS-path changes (ensuring external ASes see Acme’s prefix at the desired distance), enforces ISP-A preference via LOCAL_PREF, preserves policy visibility with communities, and validates next-hop and installation so the final forwarding matches the design.

← EIGRP Design · All domains · Route Redistribution and Policy-Based Routing →

Practice these questions → · Timed practice on ExamRoll.io →