Building upon Parts 1 and 2, this final installment explores expert-level BGP features critical for large-scale service provider networks. We'll cover dynamic route refresh capabilities, advanced route aggregation with AS-set preservation, AS path manipulation techniques, backdoor routing scenarios, and culminate with MPLS Layer 3 VPN implementation using BGP as the control plane.
Prerequisites:
- Completed Parts 1 and 2 of this tutorial series
- Functional BGP lab environment from previous parts
- Understanding of BGP path attributes and route maps
- Basic knowledge of MPLS concepts (for L3VPN section)
Lab Expansion:
Some topics in this tutorial may require additional routers or MPLS-capable hardware. We'll indicate when lab expansion is needed and provide alternatives where possible.
BGP Route Refresh Capabilities
Route Refresh, defined in RFC 2918, allows BGP peers to request a full update of all routes without tearing down the BGP session. This is essential for applying policy changes dynamically without service interruption.
Understanding Route Refresh
Traditionally, BGP required a session reset (hard reset) to apply new inbound policies. Route Refresh eliminates this need by allowing peers to request a fresh advertisement of all routes after policy changes.
1 Verify Route Refresh Support
# Check if route refresh is supported
sudo vtysh -c "show ip bgp neighbors 192.168.139.145"
# Look for "Route refresh: advertised and received" in output2 Manual Route Refresh
Manually trigger a route refresh to apply new policies:
# Soft refresh inbound routes (request neighbor to resend)
sudo vtysh -c "clear ip bgp 192.168.139.145 soft in"
# Soft refresh outbound routes (resend to neighbor)
sudo vtysh -c "clear ip bgp 192.168.139.145 soft out"
# Soft refresh both directions
sudo vtysh -c "clear ip bgp 192.168.139.145 soft"3 Dynamic Route Refresh
Configure automatic route refresh when policies change:
# On VM1
sudo vtysh
configure terminal
router bgp 65001
bgp route-reflector allow-outbound-policy
end
writeRoute Refresh Benefits:
- No session interruption when applying policy changes
- Faster convergence compared to hard resets
- Essential for production networks with strict uptime requirements
- Works with both iBGP and eBGP sessions
BGP Aggregate Routes with AS-Set
Route aggregation reduces BGP table size by summarizing multiple routes into a single aggregate. The AS-set option preserves the AS path information of the aggregated routes, preventing routing loops.
Aggregation Without AS-Set
Standard aggregation loses AS path information, which can cause routing issues:
# Standard aggregation (loses AS path info)
router bgp 65001
address-family ipv4 unicast
aggregate-address 10.0.0.0/8
exit-address-family1 Configure AS-Set Aggregation
AS-set preserves the AS numbers from all aggregated routes:
# On VM1
sudo vtysh
configure terminal
router bgp 65001
address-family ipv4 unicast
# Aggregate with AS-set to preserve AS path information
aggregate-address 10.0.0.0/8 as-set
# Suppress more specific routes (optional)
aggregate-address 10.0.0.0/8 as-set summary-only
exit-address-family
end
write2 Verify AS-Set Aggregation
# View aggregate route with AS-set
sudo vtysh -c "show ip bgp 10.0.0.0/8"
# Expected output shows AS path like: {65002,65003} 65001
# The curly braces indicate AS-set3 Selective Route Suppression
Control which routes are suppressed in the aggregate:
# Create prefix list for routes to suppress
ip prefix-list SUPPRESS_ROUTES seq 10 permit 10.5.5.5/32
ip prefix-list SUPPRESS_ROUTES seq 20 permit 10.3.3.3/32
# Aggregate with selective suppression
router bgp 65001
address-family ipv4 unicast
aggregate-address 10.0.0.0/8 as-set suppress-map SUPPRESS_ROUTES
exit-address-familyAS-Set Considerations:
AS-set aggregation increases AS path length, which may affect path selection. Use AS-set when loop prevention is critical, but be aware it may make routes less preferred due to longer AS paths.
Remove Private AS
The Remove Private AS feature strips private AS numbers (64512-65535) from AS paths before advertising routes to external peers. This is essential when using private AS numbers internally but connecting to public internet.
1 Configure Remove Private AS
# On VM1 (if using private AS internally)
sudo vtysh
configure terminal
router bgp 65001
address-family ipv4 unicast
neighbor 192.168.139.145 remove-private-as
exit-address-family
end
write
clear ip bgp 192.168.139.145 soft out2 Remove Private AS with Exceptions
Allow specific private AS numbers to be preserved:
# Remove private AS but allow AS 65000
router bgp 65001
address-family ipv4 unicast
neighbor 192.168.139.145 remove-private-as all
# Exception: keep AS 65000 in path
neighbor 192.168.139.145 remove-private-as all allow-own-as
exit-address-family3 Verify Private AS Removal
# Check routes before removal
sudo vtysh -c "show ip bgp neighbor 192.168.139.145 advertised-routes"
# Routes should not contain private AS numbers in their pathsPrivate AS Number Ranges:
- 64512-65535: Private AS numbers (RFC 6996)
- 4200000000-4294967294: 32-bit private AS numbers
- Remove private AS is typically applied to eBGP sessions only
BGP allowas-in
The allowas-in feature permits routes with your own AS number in the AS path, which normally would be rejected to prevent loops. This is necessary in specific scenarios like hub-and-spoke VPNs or AS migration.
When to Use allowas-in
- Hub-and-Spoke VPNs: Hub receives routes from spoke that already contain hub's AS
- AS Migration: During AS number transition periods
- Route Reflector Scenarios: When RR clients need to accept reflected routes with local AS
- Backdoor Links: When using IGP backdoors with BGP
1 Configure allowas-in
# On VM1 - allow own AS in path (allow once)
sudo vtysh
configure terminal
router bgp 65001
address-family ipv4 unicast
neighbor 192.168.139.225 allowas-in
exit-address-family
end
write2 Allow Multiple AS Occurrences
# Allow own AS to appear up to 3 times in path
router bgp 65001
address-family ipv4 unicast
neighbor 192.168.139.225 allowas-in 3
exit-address-family3 Verify allowas-in
# Check if routes with own AS are accepted
sudo vtysh -c "show ip bgp neighbor 192.168.139.225 received-routes"
# Routes with AS 65001 in path should now be acceptedSecurity Consideration:
allowas-in disables a critical loop prevention mechanism. Use only when absolutely necessary and understand the implications. Misconfiguration can cause routing loops.
Prevent Transit AS
Prevent your AS from becoming a transit provider for routes between two external ASes. This is critical for stub networks or when you don't want to carry transit traffic.
1 Filter Routes with AS Path Length
# On VM1 - prevent transit by filtering long AS paths
sudo vtysh
configure terminal
# Only accept routes originated by direct neighbors
ip as-path access-list 10 permit ^65002$
ip as-path access-list 10 permit ^65003$
ip as-path access-list 20 deny .*
router bgp 65001
address-family ipv4 unicast
neighbor 192.168.139.145 filter-list 10 in
neighbor 192.168.139.17 filter-list 10 in
exit-address-family
end
write
clear ip bgp 192.168.139.145 soft in
clear ip bgp 192.168.139.17 soft in2 Use no-export Community
# Mark all received routes with no-export
route-map PREVENT_TRANSIT permit 10
set community no-export
router bgp 65001
address-family ipv4 unicast
neighbor 192.168.139.145 route-map PREVENT_TRANSIT in
neighbor 192.168.139.17 route-map PREVENT_TRANSIT in
exit-address-family3 Verify Transit Prevention
# Check that routes from VM2 are not advertised to VM5
sudo vtysh -c "show ip bgp neighbor 192.168.139.17 advertised-routes"
# Routes from VM2 (AS 65002) should not appearTransit Prevention Methods:
- AS path filtering: Only accept directly connected AS routes
- no-export community: Prevent re-advertisement to eBGP peers
- Route maps: Selective filtering based on source
- Prefix lists: Filter specific route ranges
Backdoor Routes
Backdoor routes use IGP (OSPF, IS-IS) for preferred paths instead of BGP, typically for directly connected networks. This allows IGP to take precedence over BGP for specific routes.
Understanding Backdoor Scenarios
In a backdoor scenario, you have both BGP and IGP routes to the same destination. By default, BGP routes are preferred, but backdoor configuration makes IGP preferred.
1 Configure IGP for Backdoor
# On VM1 and VM5 - configure OSPF for backdoor link
sudo vtysh
configure terminal
# Add a new interface for backdoor (example)
interface eth1
ip address 172.16.1.1/30
router ospf
network 172.16.1.0/30 area 0
network 10.1.1.1/32 area 0
end
write2 Configure BGP Backdoor
# On VM1 - mark route as backdoor
sudo vtysh
configure terminal
router bgp 65001
address-family ipv4 unicast
network 10.5.5.5/32 backdoor
exit-address-family
end
write3 Verify Backdoor Route Preference
# Check routing table - IGP route should be preferred
sudo vtysh -c "show ip route 10.5.5.5/32"
# Route should show OSPF as the source, not BGP4 Backdoor with Route Maps
# Use route map to set administrative distance
route-map BACKDOOR_ROUTE permit 10
match ip address prefix-list BACKDOOR_NETWORKS
set distance 20
router bgp 65001
address-family ipv4 unicast
neighbor 192.168.139.17 route-map BACKDOOR_ROUTE in
exit-address-family
ip prefix-list BACKDOOR_NETWORKS seq 10 permit 10.5.5.5/32Backdoor Route Use Cases:
- Direct connections between sites that also have BGP
- Preferring IGP for internal routes
- Cost optimization for directly connected networks
- Redundancy with different path preferences
Unsuppress-Map for Route Dampening
The unsuppress-map allows selective unsuppression of dampened routes, overriding the normal dampening behavior for specific routes that should be available immediately.
1 Configure Route Dampening
# On VM1 - enable route dampening
sudo vtysh
configure terminal
router bgp 65001
bgp dampening 15 750 2000 60
end
write2 Create Unsuppress Map
# Define routes that should never be suppressed
ip prefix-list CRITICAL_ROUTES seq 10 permit 10.5.5.5/32
ip prefix-list CRITICAL_ROUTES seq 20 permit 10.1.1.1/32
# Create route map for unsuppression
route-map UNSUPPRESS_CRITICAL permit 10
match ip address prefix-list CRITICAL_ROUTES
# Apply unsuppress map
router bgp 65001
address-family ipv4 unicast
bgp unsuppress-map UNSUPPRESS_CRITICAL
exit-address-family
end
write3 Verify Unsuppress Behavior
# Check dampening status
sudo vtysh -c "show ip bgp dampening"
# Critical routes should not appear in suppressed list
sudo vtysh -c "show ip bgp dampening dampened"Unsuppress-Map Considerations:
Use unsuppress-map carefully. Routes that are frequently flapping but marked as critical will still flap, potentially causing instability. Only use for truly critical routes that must be available.
Advanced Route Reflector Configurations
Beyond basic route reflection from Part 1, advanced RR configurations include hierarchical reflection, cluster IDs, and client-to-client reflection control.
1 Hierarchical Route Reflection
# On VM1 - configure as primary RR
sudo vtysh
configure terminal
router bgp 65001
bgp router-id 1.1.1.1
# Configure secondary RR
neighbor 192.168.139.147 remote-as 65001
neighbor 192.168.139.147 route-reflector-client
# Primary clients
neighbor 192.168.139.225 remote-as 65001
neighbor 192.168.139.225 route-reflector-client
end
write2 Route Reflector Clusters
# Configure cluster ID to prevent loops in multi-RR scenarios
router bgp 65001
bgp cluster-id 1.1.1.1
neighbor 192.168.139.225 route-reflector-client
neighbor 192.168.139.147 route-reflector-client
# On secondary RR (if added)
router bgp 65001
bgp cluster-id 1.1.1.1
neighbor 192.168.139.225 route-reflector-client3 Disable Client-to-Client Reflection
# Prevent clients from learning routes from each other
router bgp 65001
no bgp client-to-client reflection
neighbor 192.168.139.225 route-reflector-client
neighbor 192.168.139.147 route-reflector-client4 Route Reflector with Outbound Policy
# Allow outbound policies on RR
router bgp 65001
bgp route-reflector allow-outbound-policy
neighbor 192.168.139.225 route-reflector-client
neighbor 192.168.139.225 route-map RR_OUT outRoute Reflector Best Practices:
- Use cluster IDs when multiple RRs serve same clients
- Disable client-to-client reflection if clients are meshed
- Place RRs strategically for optimal path distribution
- Monitor RR load and consider hierarchical designs
MPLS Layer 3 VPN with BGP
MPLS L3VPN uses BGP as the control plane to distribute VPN routes between Provider Edge (PE) routers. This is the most advanced topic, combining MPLS forwarding with BGP route distribution.
MPLS L3VPN Architecture
MPLS L3VPN components:
- CE (Customer Edge): Customer router
- PE (Provider Edge): Service provider router with VPN awareness
- P (Provider): Core MPLS router (label switching only)
- VRF (Virtual Routing and Forwarding): Per-customer routing table
- Route Distinguisher (RD): Makes VPN routes unique
- Route Target (RT): Controls route import/export
Lab Topology for MPLS L3VPN
CE1 (VM5) CE2 (New VM)
AS 65003 AS 65004
| |
eBGP | | eBGP
| |
+----+----+ +----+----+
| PE1 | | PE2 |
| (VM1) | | (VM3) |
+----+----+ +----+----+
| |
MPLS | | MPLS
| |
+----+----+ +----+----+
| P | | P |
| (VM4) | | (VM2) |
+---------+ +---------+
| |
+----------------------------+
MPLS Core
1 Enable MPLS on Interfaces
# On VM1 (PE1) - enable MPLS
sudo vtysh
configure terminal
interface enp0s3
mpls enable
router ospf
mpls-te on
end
write2 Configure LDP (Label Distribution Protocol)
# On VM1 - enable LDP
mpls ldp
router-id 1.1.1.1
!
address-family ipv4
discovery transport-address 1.1.1.1
exit-address-family
# Verify LDP neighbors
show mpls ldp neighbor3 Create VRF and Configure VPN
# On VM1 (PE1) - create VRF for customer
vrf CUSTOMER_A
rd 65001:100
route-target import 65001:100
route-target export 65001:100
# Assign interface to VRF
interface eth1
vrf CUSTOMER_A
ip address 192.168.100.1/24
end
write4 Configure BGP VPNv4 Address Family
# On VM1 - enable VPNv4 address family
router bgp 65001
bgp router-id 1.1.1.1
# VPNv4 neighbor (other PE)
neighbor 192.168.139.225 remote-as 65001
neighbor 192.168.139.225 update-source 10.1.1.1
!
address-family vpnv4 unicast
neighbor 192.168.139.225 activate
neighbor 192.168.139.225 route-reflector-client
exit-address-family
!
# IPv4 VRF address family
address-family ipv4 vrf CUSTOMER_A
network 192.168.100.0/24
neighbor 192.168.139.17 remote-as 65003
neighbor 192.168.139.17 activate
exit-address-family
end
write5 Configure PE2 (VM3)
# On VM3 (PE2) - mirror configuration
vrf CUSTOMER_A
rd 65001:100
route-target import 65001:100
route-target export 65001:100
router bgp 65001
address-family vpnv4 unicast
neighbor 192.168.139.115 remote-as 65001
neighbor 192.168.139.115 update-source 10.3.3.3
neighbor 192.168.139.115 activate
exit-address-family
!
address-family ipv4 vrf CUSTOMER_A
neighbor 192.168.200.1 remote-as 65004
neighbor 192.168.200.1 activate
exit-address-family
end
write6 Verify MPLS L3VPN
# Check VPNv4 routes
sudo vtysh -c "show ip bgp vpnv4 all"
# Check VRF routing table
sudo vtysh -c "show ip route vrf CUSTOMER_A"
# Check MPLS labels
sudo vtysh -c "show mpls table"
# Check LDP bindings
sudo vtysh -c "show mpls ldp binding"MPLS L3VPN Route Flow
| Step | Action | Location |
|---|---|---|
| 1 | CE advertises route to PE via eBGP | CE → PE1 |
| 2 | PE adds RD and RT, creates VPNv4 route | PE1 VRF |
| 3 | BGP distributes VPNv4 route to remote PE | PE1 → PE2 (via RR) |
| 4 | PE2 checks RT, imports into VRF | PE2 VRF |
| 5 | PE2 advertises to local CE | PE2 → CE2 |
| 6 | MPLS labels used for forwarding | P routers |
MPLS L3VPN Requirements:
MPLS L3VPN requires MPLS-capable hardware and proper LDP/RSVP-TE configuration. In a lab environment, ensure your routers support MPLS forwarding. FRRouting supports MPLS L3VPN, but hardware acceleration may be needed for production.
Verification and Testing
1 Verify Route Refresh
# Check route refresh capability
sudo vtysh -c "show ip bgp neighbors 192.168.139.145 | grep -i refresh"
# Test soft refresh
sudo vtysh -c "clear ip bgp 192.168.139.145 soft in"2 Verify AS-Set Aggregation
# Check aggregate route
sudo vtysh -c "show ip bgp 10.0.0.0/8"
# Verify AS-set in path
sudo vtysh -c "show ip bgp 10.0.0.0/8 json" | grep -i aspath3 Verify allowas-in
# Check accepted routes with own AS
sudo vtysh -c "show ip bgp neighbor 192.168.139.225 received-routes"
# Routes with AS 65001 should be accepted4 Verify Transit Prevention
# Check that routes are not advertised between external ASes
sudo vtysh -c "show ip bgp neighbor 192.168.139.17 advertised-routes"
sudo vtysh -c "show ip bgp neighbor 192.168.139.145 advertised-routes"5 Verify Backdoor Routes
# Check routing table for backdoor preference
sudo vtysh -c "show ip route 10.5.5.5/32"
# Should show OSPF route, not BGP6 Verify MPLS L3VPN
# Check VPNv4 routes
sudo vtysh -c "show ip bgp vpnv4 all"
# Check VRF routes
sudo vtysh -c "show ip route vrf CUSTOMER_A"
# Test connectivity between CEs
ping -c 4 -I vrf CUSTOMER_A 192.168.200.1Success Indicators:
- Route refresh working without session resets
- AS-set aggregation preserving AS path information
- allowas-in accepting routes with own AS
- Transit prevention blocking unwanted route propagation
- Backdoor routes preferring IGP over BGP
- MPLS L3VPN routes distributed and forwarding correctly
Troubleshooting Advanced BGP Features
Route Refresh Issues
Route Refresh Not Working:
Symptoms: Soft refresh doesn't apply new policies
Solutions:
- Verify route refresh capability:
show ip bgp neighbors - Check if both peers support route refresh
- Ensure BGP session is established
- Try hard reset if soft refresh fails (during maintenance window)
AS-Set Aggregation Issues
AS-Set Not Preserving AS Path:
Symptoms: Aggregate route loses AS path information
Solutions:
- Verify
as-setkeyword is configured - Check that component routes exist in BGP table
- Verify aggregate-address syntax
- Check for conflicting more specific routes
MPLS L3VPN Issues
VPN Routes Not Propagating:
Symptoms: Routes not visible in remote VRF
Solutions:
- Verify Route Target import/export matches
- Check VPNv4 address family is enabled
- Verify RD is configured correctly
- Check MPLS forwarding is working
- Verify LDP/RSVP-TE labels are assigned
Production Best Practices
Route Refresh
- Always use soft refresh in production (avoid hard resets)
- Test policy changes in lab before applying to production
- Monitor BGP session stability after policy changes
- Document all route refresh procedures
AS-Set Aggregation
- Use AS-set when aggregating routes from multiple ASes
- Be aware AS-set increases AS path length
- Consider summary-only for route table reduction
- Test aggregation impact on path selection
MPLS L3VPN
- Use consistent RD format (AS:VALUE recommended)
- Standardize RT naming conventions
- Implement route filtering between VPNs
- Monitor MPLS label usage and exhaustion
- Plan for scale (thousands of VPNs)
Conclusion
Expert-Level BGP Mastery:
- Implemented dynamic route refresh capabilities
- Configured AS-set aggregation for loop prevention
- Applied AS path manipulation techniques
- Implemented transit AS prevention
- Configured backdoor routes for IGP preference
- Used unsuppress-map for selective route dampening
- Deployed advanced route reflector configurations
- Implemented MPLS Layer 3 VPN with BGP control plane
Next Steps
- Explore BGP FlowSpec for DDoS mitigation
- Implement BGP Add-Path for multipath scenarios
- Configure BGP-LS for SDN controller integration
- Deploy BGP EVPN for data center networking
- Explore BGP SR-TE for segment routing traffic engineering
- Implement BGP PIC (Prefix Independent Convergence)
- Configure BGP Graceful Restart for high availability
This three-part series has covered BGP from fundamentals to expert-level implementations. The topics explored here form the foundation of modern service provider and enterprise networks. Mastery of these concepts enables design and operation of scalable, resilient, and efficient BGP-based routing infrastructures.