Why Passive Path Selection Is Not Always Enough
The BGP best-path selection algorithm, discussed earlier in this series, automatically picks a single best path using its fixed sequence of attributes. In real enterprise and service provider networks, administrators frequently need to actively influence this outcome -- preferring one upstream ISP connection over another for cost reasons, or ensuring traffic enters a network through a specific preferred link -- rather than simply accepting whatever the default algorithm decides.
Route Maps: The Tool for Filtering and Modifying Routes
A Route Map, briefly introduced earlier in this series regarding redistribution loop prevention, is a sequence of match-and-set statements that both filters which routes are affected and modifies specific attributes of those matched routes -- the primary tool used throughout BGP policy configuration.
Router(config)# route-map SET-LOCAL-PREF permit 10
Router(config-route-map)# match ip address prefix-list CUSTOMER-ROUTES
Router(config-route-map)# set local-preference 200
Router(config)# router bgp 65001
Router(config-router)# neighbor 203.0.113.2 route-map SET-LOCAL-PREF in
-- This applies the route map to routes received
-- FROM this specific neighbor ("in" direction),
-- setting Local Preference to 200 for any route
-- matching the specified prefix listLocal Preference: Influencing Outbound Traffic
Recalling the BGP path attribute hierarchy discussed earlier in this series, Local Preference is evaluated second, immediately after Weight, and is shared throughout an AS via iBGP -- making it the primary tool for influencing which exit point an organization's own outbound traffic uses when multiple paths toward the same external destination exist.
Scenario: an enterprise has two internet connections,
a primary high-bandwidth link and a backup
lower-bandwidth link
Router(config)# route-map PREFER-PRIMARY permit 10
Router(config-route-map)# set local-preference 200
Router(config)# router bgp 65001
Router(config-router)# neighbor 203.0.113.2 route-map PREFER-PRIMARY in
-- Applied on the router connected to the
-- primary link, setting a higher Local
-- Preference (200 vs. the default 100)
-- ensures all routers in this AS prefer
-- exiting through the primary linkSince Local Preference is shared via iBGP across the entire AS, this single configuration change on one router influences the outbound path selection of every other router within the same AS -- a powerful, centralized way to steer an organization's own outbound traffic.
MED: Influencing Inbound Traffic from a Neighboring AS
MED (Multi-Exit Discriminator) serves the opposite purpose: rather than influencing this AS's own outbound traffic, it suggests to a neighboring AS which of multiple entry points into this AS should be preferred for inbound traffic.
Scenario: an enterprise has two connections to
the same ISP, and wants inbound traffic to
prefer entering through the primary link
Router(config)# route-map SET-MED permit 10
Router(config-route-map)# set metric 50
Router(config)# router bgp 65001
Router(config-router)# neighbor 203.0.113.2 route-map SET-MED out
-- Applied outbound toward the neighboring AS,
-- a LOWER MED value is preferred, so setting
-- 50 on the primary link (versus a higher
-- default value on the backup) suggests the
-- neighboring AS should prefer the primary
-- link for traffic destined into this ASA critical limitation to understand: unlike Local Preference, MED is only a suggestion to the receiving neighboring AS, which remains free to ignore it entirely based on its own local policy -- MED influences, but does not guarantee, inbound traffic behavior, since the decision ultimately belongs to the neighboring organization's own BGP configuration.
BGP Communities: A Flexible Tagging System
A BGP Community is an optional, transitive attribute that tags a route with an arbitrary numeric value, allowing routers throughout a network (or even across AS boundaries, when appropriately configured) to apply consistent policy based on that tag, rather than needing to match against the route's specific prefix everywhere that policy needs to be applied.
Router(config)# route-map TAG-CUSTOMER permit 10
Router(config-route-map)# match ip address prefix-list CUSTOMER-ROUTES
Router(config-route-map)# set community 65001:100
Router(config)# router bgp 65001
Router(config-router)# neighbor 203.0.113.2 route-map TAG-CUSTOMER in
Router(config-router)# neighbor 203.0.113.2 send-communityThe send-community keyword is easy to forget and essential: without it, community values are not actually sent to the neighbor at all, even though the route map appears to configure them correctly -- a common source of confusion when community-based policy silently fails to take effect on a remote router.
Why Communities Simplify Policy at Scale
Without communities:
Every router that needs to apply special policy
to "customer routes" must independently match
against the actual prefix list of customer
routes, requiring that prefix list to be
maintained and kept synchronized across
every router in the network
With communities:
Routes are tagged once, near the source, with
a community value like 65001:100 meaning
"customer route" -- every other router
throughout the network can then simply match
on this single community value, without
needing its own copy of the actual prefix listThis decoupling of policy from specific prefixes is the core value of communities: as customer routes are added or removed over time, only the single tagging point needs updating, rather than every router throughout the network that applies policy based on that classification.
Well-Known Community Values
NO-EXPORT: routes tagged with this community
should not be advertised to any eBGP neighbor,
keeping them confined within the local AS
(or confederation) entirely
NO-ADVERTISE: routes tagged with this community
should not be advertised to any BGP neighbor
at all, internal or external
Router(config-route-map)# set community no-exportThese standardized, well-known community values provide common, universally understood policy signals that work consistently across different vendors' equipment, distinct from custom organization-specific community values like 65001:100 used in the earlier examples.
Verifying Community and Attribute Application
Router# show ip bgp 192.168.5.0
BGP routing table entry for 192.168.5.0/24
Local
203.0.113.2 from 203.0.113.2 (10.0.0.2)
Origin IGP, localpref 200, metric 50, valid, external, best
Community: 65001:100This detailed per-route output confirms exactly which attributes have actually been applied to a specific route -- the essential verification step after configuring any route map-based policy, confirming the intended Local Preference, MED, and community values actually took effect rather than assuming the configuration worked as intended.
Why Mastering These Tools Distinguishes Advanced BGP Skill
Basic BGP configuration, covered earlier in this series, establishes connectivity and exchanges routes using the protocol's default behavior. Route maps, Local Preference, MED, and communities are what allow an organization to actively express its own business and traffic-engineering policy on top of that basic connectivity -- skills that become essential the moment a network has more than one path to the same external destination and genuinely needs to control, rather than merely observe, how that path selection actually happens.