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.
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 │
└─────────────────────────┘
| Router | AS | Router-ID | Faults |
|---|---|---|---|
R1 | 100 | 1.1.1.1 | Fault 1 |
R2 | 200 | 2.2.2.2 | Faults 2, 3, 4 |
R3 | 300 | 3.3.3.3 | Fault 5 |
R4 | 400 | 4.4.4.4 | Faults 6, 7 |
bgp-troubleshooting-lab.yaml.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.
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
Diagnostic commands — run on R1 and R2! 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
What to look for
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.
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.
Route-map direction in vs out
Diagnostic commands — run on R2! 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
What to look for
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.
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).
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
Diagnostic commands! 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
What to look for
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.
! 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.
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
Diagnostic commands! 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
What to look for
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.
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.
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
Diagnostic commands! 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
What to look for
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.
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.
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
Diagnostic commands! 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
What to look for
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.
! 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.
Address-family scope Weight
Diagnostic commands! 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
What to look for
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.
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.
172.16.10.0/24 from R1 with community 100:10 set (Fault 1)100:10 on 172.16.10.0/24 (Fault 3)172.16.20.0/24 (Fault 4)200:50 (Fault 5)show bgp neighbors … received-routes returns data on R4 (Fault 6)! ── 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
| # | Router | Fault Type | Symptom | Key Command to Diagnose |
|---|---|---|---|---|
| 1 | R1 | Wrong prefix-list mask | Community not set on outbound route | show ip prefix-list CUSTOMER-A detail |
| 2 | R2 | Route-map wrong direction | Local-pref 200 not applied from R3 | show bgp ... neighbors 192.168.23.3 | inc route-map |
| 3 | R2 | Missing send-community | Communities stripped to R3/R4 | show bgp ... neighbors 192.168.23.3 | inc community |
| 4 | R2 | Implicit deny (no permit-all) | R4 missing all prefixes except one | show route-map PREPEND-R4 |
| 5 | R3 | expanded vs standard community-list | Community match unreliable / fails | show ip community-list BAD-COMM-MATCH |
| 6 | R4 | Missing soft-reconfiguration inbound | received-routes returns no data | show bgp ... neighbors 192.168.24.2 | inc soft |
| 7 | R4 | route-map outside address-family | Weight stays at 0 on all routes | show 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