← Back to portfolio
network-labs / bgp / BGP-RouteMap-Troubleshooting
📄 README.md 7 Faults CML Lab

🔍 BGP Route Map Troubleshooting Lab

🔴 Advanced ⏱ ~2 hours 🎓 CCNP / CCIE prep 🐛 7 injected faults

This lab ships with seven deliberately broken BGP configurations spread across four routers. Each fault is a realistic mistake drawn from real-world troubleshooting scenarios — wrong mask lengths, missing clauses, misapplied directions, and subtle community-list type errors.

🚫

Lab Rule: Do not start with show running-config. Use only BGP verification and diagnostic commands to locate each fault first, then confirm with the config. This is how you troubleshoot in production.

🗺️ Topology

  Loopbacks: 172.16.10.0/24                  Loopbacks: 10.3.1.0/24
             172.16.20.0/24                             10.3.2.0/24
                   │                                         │
       ┌───────────┴──────────┐              ┌──────────────┴───────┐
       │         R1            │              │         R3            │
       │       AS 100          │              │       AS 300          │
       │      1.1.1.1/32       │              │      3.3.3.3/32      │
       └────────────┬──────────┘              └────────────┬─────────┘
                    │ 192.168.12.0/24                      │ 192.168.23.0/24
                    │                                      │
       ┌────────────┴──────────────────────────────────────┤
       │                        R2                          │
       │                     AS 200                         │
       │                   2.2.2.2/32                       │
       └────────────────────────────────┬───────────────────┘
                                        │ 192.168.24.0/24
                                        │
                           ┌────────────┴──────────┐
                           │          R4             │
                           │        AS 400           │
                           │       4.4.4.4/32        │
                           │  Loopbacks:             │
                           │   10.4.1.0/24           │
                           │   10.4.2.0/24           │
                           └─────────────────────────┘
RouterASRouter-IDFaults
R11001.1.1.1Fault 1
R22002.2.2.2Faults 2, 3, 4
R33003.3.3.3Fault 5
R44004.4.4.4Faults 6, 7

🚀 Getting Started

  1. Log in to CML, click Labs → Import, upload bgp-troubleshooting-lab.yaml.
  2. Start the lab and wait for all nodes to reach Running state (≈ 2–3 min).
  3. Open a console to each router.
  4. Run the baseline check below on every router before starting.

Baseline — Run on all routers

show bgp ipv4 unicast summary
show bgp ipv4 unicast
ℹ️

All BGP sessions will form (no TCP/neighbour faults here). The issues are purely at the policy / attribute layer. If a session is down, check your CML node status first.


🐛 Fault Scenarios

FAULT 1

Community never set on outbound advertisements

R1 — AS100
Symptom: R2 receives 172.16.10.0/24 from R1 but the route has no community value. R2's community-based policy for this prefix never triggers.

Prefix-list Wrong mask

! On R1 — check what is being advertised to R2
R1# show bgp ipv4 unicast neighbors 192.168.12.2 advertised-routes

! On R2 — check received routes and look for communities
R2# show bgp ipv4 unicast neighbors 192.168.12.1 received-routes
R2# show bgp ipv4 unicast 172.16.10.0/24

! On R1 — verify the prefix-list itself
R1# show ip prefix-list CUSTOMER-A
R1# show route-map TAG-OUTBOUND

The route-map TAG-OUTBOUND should match 172.16.10.0/24. Check whether the prefix-list CUSTOMER-A actually matches that prefix using:

R1# show ip prefix-list CUSTOMER-A detail

Pay attention to the hit count. Zero hits means the match condition is never satisfied.

Reveal fault & fix
Broken config
ip prefix-list CUSTOMER-A seq 10 permit 172.16.10.0/25
!                                                    ^^^
!  /25 does not match the /24 network being advertised
Fixed config
no ip prefix-list CUSTOMER-A seq 10
ip prefix-list CUSTOMER-A seq 10 permit 172.16.10.0/24

! Soft reset to re-advertise with correct community
R1# clear ip bgp 192.168.12.2 soft out

Root cause: The prefix-list used /25 instead of /24, so 172.16.10.0/24 never matched. The route-map permitted clause was never evaluated, and the community 100:10 was never set. The route still went out via the implicit seq 20 permit, just without any community.

FAULT 2

Route-map applied in wrong direction — local preference never set

R2 — AS200
Symptom: R2 receives prefixes from R3 but their local preference stays at the default value of 100. The intended local preference of 200 is never applied.

Route-map direction in vs out

! Check best path detail for a prefix from R3
R2# show bgp ipv4 unicast 10.3.1.0/24

! Check what route-maps are applied to the R3 neighbour and in which direction
R2# show bgp ipv4 unicast neighbors 192.168.23.3 | include route-map|policy

! Check the route-map itself to understand its intent
R2# show route-map SET-LOCPREF

In the show bgp ... 10.3.1.0/24 output, note the localpref field. If it shows 100 (default), the inbound policy is not working. Then check which direction the route-map is applied to neighbour 192.168.23.3.

Reveal fault & fix
Broken config
neighbor 192.168.23.3 route-map SET-LOCPREF out
!                                            ^^^
! Applied outbound — but local-pref is set on RECEIVED routes (inbound)
Fixed config
R2(config)# router bgp 200
R2(config-router)# address-family ipv4
R2(config-router-af)#  no neighbor 192.168.23.3 route-map SET-LOCPREF out
R2(config-router-af)#  neighbor 192.168.23.3 route-map SET-LOCPREF in
R2(config-router-af)#  end
R2# clear ip bgp 192.168.23.3 soft in

Root cause: local-preference is set on routes received from a peer — it is an inbound attribute from the perspective of the router processing it. Applying the route-map outbound means it runs against routes being sent to R3, where setting local-pref has no effect (local-pref is not propagated over eBGP).

FAULT 3

Communities silently stripped at eBGP boundary — send-community missing

R2 — AS200
Symptom: R1 tags 172.16.10.0/24 with community 100:10, and R2 receives it correctly. However, R3 and R4 receive the prefix with no community. Any community-based policy on R3/R4 for this prefix fails silently.

send-community Communities

! On R2 — confirm community is received from R1
R2# show bgp ipv4 unicast 172.16.10.0/24

! On R3 — check if community arrives from R2
R3# show bgp ipv4 unicast 172.16.10.0/24

! On R2 — check neighbour capability and send-community config
R2# show bgp ipv4 unicast neighbors 192.168.23.3 | include community|Community
R2# show bgp ipv4 unicast neighbors 192.168.24.4 | include community|Community

On R2 the community 100:10 should be visible. On R3 it should be absent. Confirm that R2's neighbour statements to R3 and R4 are missing send-community.

Reveal fault & fix
Broken config
! R2 address-family ipv4:
neighbor 192.168.23.3 activate
! ← send-community missing
neighbor 192.168.24.4 activate
! ← send-community missing
Fixed config
R2(config)# router bgp 200
R2(config-router)# address-family ipv4
R2(config-router-af)#  neighbor 192.168.23.3 send-community
R2(config-router-af)#  neighbor 192.168.24.4 send-community
R2(config-router-af)#  end
R2# clear ip bgp 192.168.23.3 soft out
R2# clear ip bgp 192.168.24.4 soft out

Root cause: By default, IOS/IOS-XE does not advertise communities to eBGP peers. The send-community command must be explicitly configured per neighbour. Without it, all community values are stripped before the UPDATE is sent — there is no error or log message.

FAULT 4

Implicit deny — missing permit-all at end of route-map blocks all other prefixes

R2 — AS200
Symptom: R4 receives 172.16.20.0/24 with the AS-path prepend as intended. However, R4 receives no other prefixes from R2 — all other routes are missing from R4's BGP table.

Implicit deny Route-map structure

! On R4 — how many prefixes received from R2?
R4# show bgp ipv4 unicast summary
R4# show bgp ipv4 unicast

! On R2 — what is being sent to R4?
R2# show bgp ipv4 unicast neighbors 192.168.24.4 advertised-routes

! On R2 — inspect the route-map structure
R2# show route-map PREPEND-R4

The show route-map PREPEND-R4 output should reveal that the route-map has only one sequence (seq 10). With no permit catch-all at the end, every route that does not match the prefix-list is implicitly denied and not advertised.

Reveal fault & fix
Broken config
route-map PREPEND-R4 permit 10
 match ip address prefix-list PREPEND-PREFIX
 set as-path prepend 200 200
! ← no seq 20 permit — implicit deny blocks everything else
Fixed config
R2(config)# route-map PREPEND-R4 permit 20
R2(config-route-map)#  exit
R2# clear ip bgp 192.168.24.4 soft out

Root cause: Route-maps, like ACLs, have an implicit deny all at the end. When a route-map is used for BGP advertisement filtering, any route not matched by an explicit permit sequence is blocked. Adding an empty permit sequence at a higher sequence number passes all unmatched routes unchanged.

FAULT 5

Expanded community-list used where standard is required — regex mismatch

R3 — AS300
Symptom: R3 should match community 200:50 and apply local-preference 150. The community arrives correctly but the route-map match never fires — or fires unexpectedly on unintended prefixes.

community-list type standard vs expanded

! On R3 — check received routes and their communities
R3# show bgp ipv4 unicast neighbors 192.168.23.2 received-routes

! Check a specific prefix for community value
R3# show bgp ipv4 unicast 2.2.2.2/32

! Inspect the community-list
R3# show ip community-list BAD-COMM-MATCH

! Test if the community-list matches a prefix
R3# show bgp ipv4 unicast community 200:50

Note whether the community-list type is standard or expanded. An expanded list uses regular expressions. The value 200:50 as a regex pattern could unintentionally match communities like 2000:500 or 1200:50, or may not match at all depending on IOS regex anchoring behaviour.

Reveal fault & fix
Broken config
ip community-list expanded BAD-COMM-MATCH permit 200:50
!              ^^^^^^^^
!  'expanded' treats the value as a regex pattern, not a literal community
!  '200:50' as a regex matches substrings — unintended and unreliable
Fixed config
R3(config)# no ip community-list expanded BAD-COMM-MATCH
R3(config)# ip community-list standard GOOD-COMM-MATCH permit 200:50
!
R3(config)# route-map MATCH-COMMUNITY permit 10
R3(config-route-map)#  match community GOOD-COMM-MATCH
R3(config-route-map)#  set local-preference 150
R3(config-route-map)#  exit
R3# clear ip bgp 192.168.23.2 soft in

Root cause: ip community-list standard matches exact community values. ip community-list expanded matches using POSIX extended regular expressions against the community string. Using expanded with a plain community value like 200:50 treats the colon as a regex literal and may produce unreliable results across IOS versions. Always use standard for exact community matches.

FAULT 6

soft-reconfiguration inbound not enabled — cannot view pre-policy RIB

R4 — AS400
Symptom: When troubleshooting on R4, running show bgp ipv4 unicast neighbors 192.168.24.2 received-routes returns no output or the error "Inbound soft reconfiguration not performed". You cannot see what R2 is actually sending before policy is applied.

Troubleshooting capability soft-reconfiguration

! On R4 — attempt to view pre-policy received routes
R4# show bgp ipv4 unicast neighbors 192.168.24.2 received-routes

! Compare with post-policy view
R4# show bgp ipv4 unicast neighbors 192.168.24.2 routes

! Check neighbour capabilities
R4# show bgp ipv4 unicast neighbors 192.168.24.2 | include soft|refresh|Refresh

The received-routes command requires either soft-reconfiguration inbound to be enabled (which stores a copy of the pre-policy Adj-RIB-In) or the neighbour to support route-refresh capability. In this lab, confirm which is missing and enable the correct one.

Reveal fault & fix
Broken config
! address-family ipv4 on R4:
neighbor 192.168.24.2 activate
! ← soft-reconfiguration inbound missing
Fixed config
R4(config)# router bgp 400
R4(config-router)# address-family ipv4
R4(config-router-af)#  neighbor 192.168.24.2 soft-reconfiguration inbound
R4(config-router-af)#  end

! Trigger a soft reset to populate the Adj-RIB-In
R4# clear ip bgp 192.168.24.2 soft in

! Now this should return data
R4# show bgp ipv4 unicast neighbors 192.168.24.2 received-routes

Root cause: Without soft-reconfiguration inbound, IOS does not store a separate copy of the pre-policy received routes. This makes it impossible to compare what a peer sent versus what survived inbound policy — a critical troubleshooting capability. On IOS-XE with route-refresh capability negotiated, a soft reset can dynamically re-request routes, but storing the Adj-RIB-In with soft-reconfiguration inbound is best practice in lab environments.

FAULT 7

Weight route-map applied outside address-family — silently ignored

R4 — AS400
Symptom: R4 is intended to set weight 500 on all routes received from R2. However, routes in R4's BGP table all show the default weight of 0. The route-map appears to be configured but has no effect.

Address-family scope Weight

! On R4 — check weight on received routes
R4# show bgp ipv4 unicast neighbors 192.168.24.2 routes
! (look for 'weight' column — default is 0 for eBGP learned routes)

R4# show bgp ipv4 unicast 2.2.2.2/32
! (detailed output shows weight field)

! Check where the route-map is applied
R4# show bgp ipv4 unicast neighbors 192.168.24.2 | include route-map|policy|Weight

! Inspect the route-map
R4# show route-map SET-WEIGHT

Confirm that the route-map SET-WEIGHT exists and is correctly defined. Then determine whether the neighbor route-map statement appears under the global BGP router context or inside address-family ipv4. On IOS, neighbour policy commands must be inside the address-family block to take effect for IPv4 unicast.

Reveal fault & fix
Broken config
router bgp 400
 neighbor 192.168.24.2 remote-as 200
 neighbor 192.168.24.2 route-map SET-WEIGHT in
 !                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 !  Applied at global level — ignored for IPv4 unicast address-family
 !
 address-family ipv4
  neighbor 192.168.24.2 activate
 exit-address-family
Fixed config
R4(config)# router bgp 400
R4(config-router)# no neighbor 192.168.24.2 route-map SET-WEIGHT in
R4(config-router)# address-family ipv4
R4(config-router-af)#  neighbor 192.168.24.2 route-map SET-WEIGHT in
R4(config-router-af)#  end
R4# clear ip bgp 192.168.24.2 soft in

Root cause: In modern IOS/IOS-XE with address-family support, neighbor route-map must be configured inside the address-family where it applies. A neighbor route-map statement at the global BGP level may be accepted by the parser but is effectively a no-op for IPv4 unicast — it is silently ignored with no error message, making this one of the harder faults to spot without reading the config carefully.


✅ Completion Checklist

1Prefix-list mask
2Route-map direction
3send-community
4Implicit deny
5Community-list type
6soft-reconfig
7Address-family scope

🔧 Essential Troubleshooting Commands

! ── Verify BGP table and best-path detail ──────────────────────────
show bgp ipv4 unicast
show bgp ipv4 unicast <prefix/len>

! ── Neighbour session and policy overview ──────────────────────────
show bgp ipv4 unicast summary
show bgp ipv4 unicast neighbors <ip>
show bgp ipv4 unicast neighbors <ip> | include route-map|policy|community

! ── Pre/post policy views ──────────────────────────────────────────
show bgp ipv4 unicast neighbors <ip> received-routes   ! pre-policy (needs soft-reconfig)
show bgp ipv4 unicast neighbors <ip> routes             ! post-policy (best paths)
show bgp ipv4 unicast neighbors <ip> advertised-routes  ! what we send out

! ── Route-map and prefix-list inspection ───────────────────────────
show route-map <name>
show ip prefix-list <name>
show ip prefix-list <name> detail                        ! shows hit counts
show ip community-list <name>

! ── Test prefix-list match ─────────────────────────────────────────
show ip prefix-list <name> <prefix/len>

! ── Filter BGP table by community ──────────────────────────────────
show bgp ipv4 unicast community <value>
show bgp ipv4 unicast community <value> exact-match

! ── Soft resets (no session drop) ──────────────────────────────────
clear ip bgp <ip> soft in
clear ip bgp <ip> soft out
clear ip bgp * soft

! ── Debug (use sparingly — high CPU impact) ────────────────────────
debug ip bgp <ip> updates
no debug all

📊 Fault Summary Reference

#RouterFault TypeSymptomKey Command to Diagnose
1R1Wrong prefix-list maskCommunity not set on outbound routeshow ip prefix-list CUSTOMER-A detail
2R2Route-map wrong directionLocal-pref 200 not applied from R3show bgp ... neighbors 192.168.23.3 | inc route-map
3R2Missing send-communityCommunities stripped to R3/R4show bgp ... neighbors 192.168.23.3 | inc community
4R2Implicit deny (no permit-all)R4 missing all prefixes except oneshow route-map PREPEND-R4
5R3expanded vs standard community-listCommunity match unreliable / failsshow ip community-list BAD-COMM-MATCH
6R4Missing soft-reconfiguration inboundreceived-routes returns no datashow bgp ... neighbors 192.168.24.2 | inc soft
7R4route-map outside address-familyWeight stays at 0 on all routesshow bgp ... 2.2.2.2/32 (weight field)

🏆

Challenge: After fixing all 7 faults, introduce your own fault on one router without looking at the config, hand the lab to a colleague, and time how long it takes them to diagnose it using only show commands.

Lab version 1.0  ·  Platform: Cisco Modeling Labs 2.x  ·  Node type: IOSv  ·  Topology: 4 routers / 3 eBGP sessions / 7 injected faults