if destination in [prefix-set] then
Applies route policy actions if the destination prefix matches any prefix in a specified prefix-set.
Overview
The 'if destination in [prefix-set] then' command is a conditional construct used within route-policy configuration on Cisco IOS-XR. It allows network engineers to apply specific actions (like set, drop, or pass) to routes whose destination prefix matches any entry in a predefined prefix-set. This is fundamental for implementing routing policies such as prefix filtering, attribute manipulation, and traffic engineering.
Route policies are essential in BGP and other routing protocols to control the flow of routing information. The 'destination' keyword refers to the network prefix of the route being processed. By combining this condition with prefix-sets, administrators can create granular policies that treat different prefixes differently. For example, you might want to set a higher local preference for routes from a specific customer prefix-set, or drop routes from a known malicious prefix-set.
On Cisco IOS-XR, route-policies are compiled and validated before application. The 'if destination in' condition is evaluated against the prefix-set's entries, which can include exact prefixes, prefix-length ranges, or both. The policy can then execute actions like 'set community', 'set local-preference', 'drop', or 'pass'. This command is typically used in BGP inbound or outbound policies, but can also be applied to other protocols like OSPF or EIGRP via redistribution policies.
In troubleshooting workflows, verifying that the prefix-set contains the expected prefixes is critical. Use 'show prefix-set' to inspect the set. If routes are not being matched as expected, check the prefix-set definition and the order of conditions in the route-policy. The 'if destination in' condition is a powerful tool for scalable and maintainable routing policies.
if destination in [prefix-set-name] thenWhen to Use This Command
- Filtering out specific prefixes from being advertised to a BGP neighbor
- Setting community values for routes matching a prefix-set
- Modifying local preference for routes to a particular destination
- Applying different MED values based on destination prefix
Parameters
| Parameter | Syntax | Description |
|---|---|---|
| prefix-set-name | WORD | The name of a previously defined prefix-set. This set contains one or more prefix entries with optional ge/le operators. The condition matches if the route's destination prefix is in this set. |
Command Examples
Set community for routes matching prefix-set
if destination in CUSTOMER_PREFIXES then
set community (100:200) additive
endifThis route-policy checks if the destination prefix is in the prefix-set CUSTOMER_PREFIXES. If true, it adds community 100:200 to the route. The endif closes the if block.
Drop routes matching a specific prefix
if destination in BOGON_PREFIXES then
drop
endifIf the destination prefix is in BOGON_PREFIXES, the route is dropped (not installed or advertised). This is commonly used for filtering bogon or private prefixes.
Understanding the Output
The 'if destination in [prefix-set] then' command does not produce direct output; it is used within a route-policy configuration. The effect is observed when the policy is applied to a routing protocol (e.g., BGP). To verify the policy, use 'show route-policy' or 'show bgp policy' commands. The policy will either permit, deny, or modify routes based on the condition. Healthy operation means routes matching the prefix-set are handled as intended; problems arise if the prefix-set is empty or misconfigured, causing unintended drops or modifications.
Configuration Scenarios
Filtering Bogon Prefixes in BGP
An ISP wants to filter out bogon prefixes (e.g., private, reserved) from being advertised to customers.
Topology
ISP-Router --- CustomerSteps
- 1.Define a prefix-set named BOGONS with bogon prefixes.
- 2.Create a route-policy that drops routes matching BOGONS.
- 3.Apply the route-policy to the BGP neighbor outbound.
!
prefix-set BOGONS
10.0.0.0/8 ge 8 le 8,
172.16.0.0/12 ge 12 le 12,
192.168.0.0/16 ge 16 le 16
end-set
!
route-policy FILTER_BOGONS
if destination in BOGONS then
drop
else
pass
endif
end-policy
!
router bgp 65000
neighbor 10.1.1.1
address-family ipv4 unicast
route-policy FILTER_BOGONS out
!Verify: Use 'show bgp neighbors 10.1.1.1 advertised-routes' to verify bogon prefixes are not advertised.
Watch out: Ensure the prefix-set includes all necessary bogon prefixes; missing entries may leak unwanted routes.
Setting Community for Customer Prefixes
An enterprise wants to tag routes from a specific customer with community 100:200.
Topology
PE-Router --- CE-RouterSteps
- 1.Define prefix-set CUSTOMER_PREFIXES with the customer's prefixes.
- 2.Create route-policy that sets community for matching routes.
- 3.Apply the policy inbound on the CE neighbor.
!
prefix-set CUSTOMER_PREFIXES
192.0.2.0/24
end-set
!
route-policy SET_COMMUNITY
if destination in CUSTOMER_PREFIXES then
set community (100:200) additive
endif
end-policy
!
router bgp 65000
neighbor 10.2.2.2
address-family ipv4 unicast
route-policy SET_COMMUNITY in
!Verify: Use 'show bgp 192.0.2.0/24' to verify the community is set.
Watch out: The 'additive' keyword preserves existing communities; omit it to overwrite.
Troubleshooting with This Command
When troubleshooting 'if destination in [prefix-set] then' conditions, start by verifying the prefix-set definition. Use 'show prefix-set [name]' to list all entries. Ensure the prefix-set is not empty and that the prefixes are correctly specified with proper ge/le values. Common issues include missing prefixes, incorrect prefix-length ranges, or typos.
Next, check the route-policy itself with 'show route-policy [name]'. This displays the policy structure and confirms it is compiled without errors. If the policy is applied to a BGP neighbor, use 'show bgp neighbors [ip] policy' to see the effective policy. For inbound policies, check 'show bgp [prefix]' to see if attributes are modified as expected. For outbound, use 'show bgp neighbors [ip] advertised-routes' to see what is being sent.
If routes are not being matched, consider the order of conditions. The first match wins; if a previous condition already passed or dropped the route, later conditions are not evaluated. Also, ensure the route-policy is attached to the correct address-family (IPv4 unicast, IPv6 unicast, etc.). Finally, verify that the route-policy is referenced correctly in the BGP configuration. Use 'show running-config router bgp' to confirm.
CCNA Exam Tips
Remember that 'destination' refers to the prefix being evaluated, not the next-hop.
Prefix-sets must be defined before they can be used in a route-policy.
The 'then' keyword is required; omitting it causes a syntax error.
Common Mistakes
Forgetting to close the if block with 'endif' or 'elseif/else'.
Using 'in' without a defined prefix-set, leading to policy failure.
Confusing 'destination' with 'source' in route-policy conditions.
Platform Notes
On Cisco IOS-XR, route-policies are compiled into a binary form and validated at commit time. This is different from Cisco IOS where route-maps are interpreted at runtime. The 'if destination in' construct is specific to IOS-XR; in classic IOS, you would use 'match ip address prefix-list' within a route-map. IOS-XR also supports 'if destination in' for IPv6 using prefix-set with IPv6 prefixes.
In IOS-XR, prefix-sets can include both IPv4 and IPv6 prefixes, but the route-policy must be applied to the appropriate address-family. The 'destination' keyword is used only in route-policy; in other contexts like 'set' actions, you may use 'destination' as well. For example, 'set metric 100' can be conditioned on destination.
Version differences: In early IOS-XR releases, prefix-sets required explicit 'ge' and 'le' for prefix-length ranges; newer versions allow simpler notation like '192.0.2.0/24 exact'. Always check the release notes for syntax changes.
Practice for the CCNA 200-301
Test your knowledge with hundreds of CCNA practice questions covering all exam domains.
Practice CCNA Questions