You can use route maps for route redistribution. Route map entries consist of a list of match and set criteria. The match criteria specify match conditions for incoming routes or packets, and the set criteria specify the action taken if the match criteria are met.
You can configure multiple entries in the same route map. These entries contain the same route map name and are differentiated by a sequence number.
You create a route map with one or more route map entries arranged by the sequence number under a unique route map name. The route map entry has the following parameters:
Sequence number
Permission—permit or deny
Match criteria
Set changes
By default, a route map processes routes or IP packets in a linear fashion (that is, starting from the lowest sequence number). You can configure the route map to process in a different order using the continue statement, which allows you to determine which route map entry to process next.
You can use route maps to control the redistribution of routes between routing domains. Route maps match on the attributes of the routes to redistribute only those routes that pass the match criteria. The route map can also modify the route attributes during this redistribution using the set changes.
The router matches redistributed routes against each route map sequences. If there are multiple match statements under a route-map sequence, then the route must pass all the match criteria under that route-map sequence. If a route passes the match criteria defined in a route map sequence, then the set-actions defined in that sequences are executed. If the route does not match the criteria in a route-map sequence, then the router compares the route against subsequent route map sequence. This route evaluation against the route-map continues until a match is made, or the route is evaluated by all the sequences in the route map. Finally, if the route does not match against any of the route-map sequences, then the router denies acceptance of the route (for inbound route maps) or denies forwarding of the route (for outbound route maps).
Any[String[Regex: (?i)^(?:e|eth(?:ernet)?)\d(?:\/\d+){1,2}$] or String[Regex: (?i)^(?:e|eth(?:ernet)?)\d(?:\/\d+){1,2}\.\d{1,4}$] or String[Regex: (?i)^(po|port-channel)([1-9]|[1-9][0-9]{1,2}|[1-3][0-9]{3}|40[0-8][0-9]|409[0-6])$] or String[Regex: (?i)^(?:po|port-channel:?)((?:[1-9]|[1-9]\d{1,2}|[1-3]\d{3}|40[0-8]\d|409[0-6]:?)\.(?:[1-9]|[1-9]\d{1,2}|[1-3]\d{3}|40[0-8]\d|409[0-3]:?))$] or String[Regex: (?i)^(lo|loopback)([0-9]|[1-9][0-9]{1,2}|10[0-1][0-9]|102[0-3])$] or String[Regex: (?i)^(v|vlan)([1-9]|[1-9][0-9]{1,2}|1[0-9][0-9]{1,2}|2[0-9][0-9]{1,2}|3[0-9][0-7]{1,2})$] or String[Regex: (?i)^(n|null)([0])$]]
Any[String[Regex: (?i)^(?:e|eth(?:ernet)?)\d(?:\/\d+){1,2}$] or String[Regex: (?i)^(?:e|eth(?:ernet)?)\d(?:\/\d+){1,2}\.\d{1,4}$] or String[Regex: (?i)^(po|port-channel)([1-9]|[1-9][0-9]{1,2}|[1-3][0-9]{3}|40[0-8][0-9]|409[0-6])$] or String[Regex: (?i)^(?:po|port-channel:?)((?:[1-9]|[1-9]\d{1,2}|[1-3]\d{3}|40[0-8]\d|409[0-6]:?)\.(?:[1-9]|[1-9]\d{1,2}|[1-3]\d{3}|40[0-8]\d|409[0-3]:?))$] or String[Regex: (?i)^(lo|loopback)([0-9]|[1-9][0-9]{1,2}|10[0-1][0-9]|102[0-3])$] or String[Regex: (?i)^(v|vlan)([1-9]|[1-9][0-9]{1,2}|1[0-9][0-9]{1,2}|2[0-9][0-9]{1,2}|3[0-9][0-7]{1,2})$] or String[Regex: (?i)^(n|null)([0])$]]
String[Regex: ^[a-f0-9]{1}\.[a-f0-9]{1}\.[a-f0-9]{1}$] or String[Regex: ^[a-f0-9]{4}\.[a-f0-9]{4}\.[a-f0-9]{4}$] or String[Regex: ^[a-f0-9]{2}:[a-f0-9]{2}:[a-f0-9]{2}:[a-f0-9]{2}:[a-f0-9]{2}:[a-f0-9]{2}$] or String[Regex: ^[a-f0-9]{2}-[a-f0-9]{2}-[a-f0-9]{2}-[a-f0-9]{2}-[a-f0-9]{2}-[a-f0-9]{2}$]
Any[String[Regex: ^((?!0)[0-9]{1,10}:[0-9]{1,5})$] or String[Regex: ^((?!0)[0-9]{1,5}:[0-9]{1,10})$] or String[Regex: ^((25[0-5]|(2[0-4]|1\d|[1-9]|)\d)\.?){4}:\d{1,5}$]]
In this route-map rm-community-list with have two permit entries.
route-map rm-community-list permit 10:
Match Community: match community commsac-community
Behavior: This entry matches any route that contains at least one of the communities listed in the commsac-community community list. It is not necessary for the route to have all the communities specified in commsac-community; having just one is sufficient for a match.
route-map rm-community-list permit 20:
Match Community: match community commsac-community exact-match
Behavior: This entry requires an exact match of the community list commsac-community. This means that the route must have exactly the same set of communities as listed in commsac-community, with no more and no less. All communities in the route must match the list exactly for it to be considered a match.
In a route-map, the match as-number statement is used to filter routes based on their AS (Autonomous System) numbers. The two route-map entries you provided specify different criteria for matching AS numbers. Here’s an explanation of each:
route-map rm-as_number permit 10:
Match AS Number: match as-number 65000
Behavior: This entry matches any route that has an AS path containing the AS number 65000. This means that if the AS number 65000 appears anywhere in the AS path of a route, this route-map entry will consider it a match.
route-map rm-as_number2 permit 10:
Match AS Number: match as-number 64000, 65000-66000
Behavior: This entry matches any route that has an AS path containing:
The AS number 64000, or
Any AS number within the range 65000 to 66000 inclusive.
This means that if a route’s AS path contains either AS 64000 or any AS between 65000 and 66000 (inclusive), this route-map entry will consider it a match.
In a route-map, different match statements are used to filter routes based on various criteria. The route-maps you provided use IP prefix lists to match routes based on specific attributes. Here’s an explanation of each:
route-map rm-ip_addr_pfxlist permit 10:
Match Statement: match ip address prefix-list sac-prefix-list
Behavior: This route-map entry matches routes based on their destination IP addresses. It uses the sac-prefix-list to determine which destination prefixes are considered a match. If a route’s destination address falls within any of the prefixes listed in sac-prefix-list, this entry will match the route.
route-map rm-ip_nh_pfxlist permit 10:
Match Statement: match ip next-hop prefix-list sac-prefix-list
Behavior: This route-map entry matches routes based on their next-hop IP addresses. It uses the sac-prefix-list to identify which next-hop addresses are considered a match. If a route’s next-hop address matches any of the prefixes in sac-prefix-list, this entry will match the route.
route-map rm-ip_route_src_pfxlist permit 10:
Match Statement: match ip route-source prefix-list sac-prefix-list
Behavior: This route-map entry matches routes based on their source of origination, specifically the IP address of the router or device that originated the route. It uses the sac-prefix-list to determine which source addresses are considered a match. If the route’s source address matches any prefixes in sac-prefix-list, this entry will match the route.
The route-map rm-interfaces is designed to match routes based on the interfaces they are associated with. Here’s a breakdown of its components:
Route-Map Name and Sequence:
route-map rm-interfaces permit 10: This specifies the name of the route-map (rm-interfaces) and the sequence number (10). The sequence number determines the order in which route-map entries are evaluated.
Description:
description Match interfaces: This is a comment or annotation within the route-map. It provides a human-readable explanation of the purpose of this entry, which in this case is to match routes based on specific interfaces.
Match Interface Statement:
match interface Ethernet1/10 loopback100 Null0 port-channel100: This line specifies the interfaces to match against. The route-map will match routes that are received on or associated with any of the listed interfaces:
Ethernet1/10: A specific physical Ethernet interface.
loopback100: A loopback interface, which is typically used for management or routing purposes.
Null0: A virtual interface that discards traffic; often used for route summarization or to prevent routing loops.
port-channel100: An aggregated interface, typically used to combine multiple physical links into a single logical link for redundancy and increased bandwidth.
Each of these route-map entries is designed to match routes based on specific attributes or conditions. Here’s an explanation of each:
route-map rm-tags permit 10:
Match Tag: match tag 10 20
Behavior: This entry matches routes that are tagged with either the tag value 10 or 20. Tags are used in routing to add metadata to routes, often for policy or redistribution purposes.
route-map rm-evpn permit 10:
Match EVPN Route-Type: match evpn route-type 2-mac-ip 5
Behavior: This entry matches EVPN (Ethernet VPN) routes of specific types. The route-type 2-mac-ip refers to routes that distribute both MAC and IP addresses. The number 5 refers to EVPN type-5 routes, also known as IP Prefix routes.
route-map rm-mac-list permit 10:
Match MAC List: match mac-list FILTER_MAC_AAA
Behavior: This entry matches routes based on a MAC address list named FILTER_MAC_AAA. This is used in environments where MAC-based filtering is necessary, such as in Layer 2 VPNs or network security configurations.
route-map rm-metric permit 10:
Match Metric: match metric 1000
Behavior: This entry matches routes with a metric value exactly equal to 1000. Metrics are used in routing protocols to determine the best path; matching based on metrics allows for policy decisions based on route cost.
route-map rm-metric permit 20:
Match Metric with Range: match metric 1000 +- 10
Behavior: This entry matches routes with a metric value within the range of 990 to 1010 (1000 plus or minus 10). This is useful for matching routes that have a metric close to a specific value but allowing for some variance.
route-map rm-ospf-area permit 10:
Match OSPF Area: match ospf-area 0
Behavior: This entry matches routes that are learned from OSPF (Open Shortest Path First) within area 0, which is the backbone area in OSPF networks.
route-map rm-sourceproto permit 10:
Match Source Protocol: match source-protocol EXTERNAL
Behavior: This entry matches routes that are sourced from another protocol instance named EXTERNAL. This is typically used in scenarios involving route redistribution from one routing protocol to another.
The route-map entries rm-set-comm-list and rm-set-community are designed to modify the BGP community attributes of routes they process. Here’s an explanation of each entry:
First Entry: route-map rm-set-comm-list permit 10:
Description: description comm-list
This is a comment indicating that the entry deals with community lists.
Set Comm-List Statement: set comm-list mycommunitylist delete
This command specifies that the communities matching mycommunitylist should be removed from the route. Community lists are used to group together community attributes for easier management and policy application. This entry delete any communities that match the list named mycommunitylist from the routes processed by this route-map.
Second Entry: route-map rm-set-community permit 10:
Description: description community
This is a comment indicating that the entry deals with setting community attributes.
Set Community Statement:
set community internet 65000:42 65000:43 no-export no-advertise local-AS graceful-shutdown blackhole additive
This command sets various BGP community attributes for the matched routes. The communities are used to tag routes with specific attributes that can be used for routing policies and decisions. Here’s a breakdown of the communities being set:
internet: A well-known community that typically means the route is advertised to the internet.
65000:42 65000:43: These are custom community values that can be used for specific routing policies or traffic engineering.
no-export: Prevents the route from being advertised outside the local AS.
no-advertise: Prevents the route from being advertised to any BGP peers.
local-AS: Prevents the route from being advertised outside the local confederation.
graceful-shutdown: Used to indicate that a route is being withdrawn gracefully.
blackhole: Typically used to indicate that traffic matching the route should be discarded.
additive: Ensures that these communities are added to any existing communities on the route rather than replacing them.
The route-map entry rm-set-extcomm-list is designed to modify the extended community attributes of BGP (Border Gateway Protocol) routes. Here’s an explanation of its components:
Route-Map Name and Sequence:
route-map rm-set-extcomm-list permit 10: This specifies the name of the route-map (rm-set-extcomm-list) and the sequence number (10). The sequence number determines the order in which this entry is applied within the route-map.
Set Extcomm-List Statement:
set extcomm-list extcommunity-list delete: This command specifies that any extended communities matching the list named extcommunity-listshould be removed from the route.
Extended Communities: Extended communities are an extension of the standard BGP community attribute, allowing for a wider range of attributes and use cases. They are often used in more advanced BGP scenarios, such as MPLS VPNs, where they can carry additional information like route target and route origin information.
Removing Extended Communities: By using this route-map entry, any extended communities associated with a route that match those specified in extcommunity-list will be deleted. This can be useful for controlling the propagation of specific attributes that might influence routing decisions
Terminal window
route-maprm-set-extcomm-listpermit10
setextcomm-listextcommunity-listdelete
The route-map rm-set-extcommunity is designed to set various extended community attributes for BGP routes. Extended communities provide additional granularity and flexibility for controlling routing policies, especially in environments such as MPLS VPNs and EVPNs. Here’s a breakdown of each route-map entry:
Permit 10:
set extcommunity 4byteas-generic additive: Sets a generic extended community for 4-byte AS numbers, with the additive keyword indicating that this community should be added to existing communities rather than replacing them.
Permit 11:
set extcommunity 4byteas-generic transitive 65000:10 additive: Sets a transitive extended community with a specific value 65000:10, meaning it should be preserved across AS boundaries. The additive keyword ensures it is added to existing communities.
Permit 12:
set extcommunity 4byteas-generic transitive 65000:10 non-transitive 65000:42 additive: Sets both a transitive community (65000:10) and a non-transitive community (65000:42), with additive indicating they should be added to existing communities.
Permit 21:
set extcommunity color 100: Sets a color extended community with a value of 100, often used in Segment Routing and MPLS for policy routing.
Permit 22:
set extcommunity color 100 co-flag 01: Sets a color community with a co-flag, which might be used for specific routing or traffic engineering purposes, depending on the network’s configuration.
Permit 31:
set extcommunity cost igp 100 1000: Sets a cost community related to IGP metrics, possibly used for traffic engineering by influencing path selection based on cost.
Permit 32:
set extcommunity cost pre-bestpath 100 1000: Sets a cost community affecting pre-best path calculations, allowing for advanced routing decisions based on cost before the best path is determined.
Permit 35:
Complex cost settings: Sets multiple cost communities, both pre-bestpath and igp, for fine-grained control over routing decisions based on cost metrics.
Permit 40 to 42:
set extcommunity evpn rmac: Sets EVPN-related RMAC (Router MAC) extended communities with specified MAC addresses, used in EVPN configurations for identifying router MAC addresses in the control plane.
Permit 50:
set extcommunity rt 10:20 10:21 additive: Sets route target (RT) extended communities 10:20 and 10:21, using additive to retain existing communities. RTs are crucial in MPLS VPNs for defining which VRFs import/export routes.
Permit 51:
set extcommunity rt 20:20 20:21: Sets RT communities 20:20 and 20:21, replacing any existing RT communities.
Permit 52:
set extcommunity rt 30:20: Sets a single RT community 30:20, replacing any existing RT communities.
The route-map rm-set-aspath is designed to manipulate the AS (Autonomous System) path attribute in BGP (Border Gateway Protocol) updates. The AS path is a critical component in BGP routing decisions, as it helps determine the best path to a destination and avoid routing loops. Here’s an explanation of each route-map entry:
Permit 5:
set as-path 65000 65001: This is likely a placeholder or example indicating that the AS path can be set to a specific sequence of AS numbers.
Permit 6:
set as-path 65000.10: Sets the AS path to a specific AS sequence, where 65000.10 is treated as a single AS entry.
Permit 7:
set as-path 65000.10 65001: Sets the AS path to include two AS entries, 65000.10 and 65001.
Permit 10:
set as-path prepend last-as 3: Prepends the last AS in the path three times. AS path prepending is used to make a path less preferred by increasing its length.
Permit 11:
set as-path prepend 65000: Prepends the AS number 65000 to the AS path, making it appear less preferred to BGP peers.
Permit 12:
set as-path prepend 65000 65000.1: Prepends two AS numbers, 65000 and 65000.1, to the path.
Permit 21:
set as-path replace 65000 with 65000.10: Replaces occurrences of AS 65000 in the path with 65000.10.
Permit 22:
set as-path replace 65000 with none: Removes AS 65000 from the AS path.
Permit 23:
set as-path replace 65000 with remote-as: Replaces AS 65000 with the remote AS number (the AS number of the BGP peer).
Permit 30:
set as-path replace private-as: Removesprivate AS numbers from the AS path.
Permit 31:
set as-path replace private-as with 65000.10: Replacesprivate AS numbers in the path with 65000.10.
Permit 32:
set as-path replace private-as with none: Removesprivate AS numbersentirely from the path.
Permit 33:
set as-path replace private-as with remote-as: Replacesprivate AS numbers with the remote AS number.
Permit 40:
set as-path tag: Tags the AS path, potentially for internal use or policy identification.
Permit 50:
set as-path none: Sets the AS path to none.
Permit 60:
set as-path local-as: Sets the AS path to the local AS number.
Permit 70:
set as-path remote-as: Sets the AS path to the remote AS number.
The route-map entry you provided, rm-set-dampening, is configured to apply route dampening parameters to routes that it matches. Here’s a breakdown of its components:
Route-Map Name and Sequence:
route-map rm-set-dampening permit 10: This specifies the name of the route-map (rm-set-dampening) and the sequence number (10). The sequence number indicates the order in which this entry is processed within the route-map.
Description:
description community: This is an annotation or comment within the route-map entry. While it doesn’t affect the functionality, it serves as a note for network administrators, indicating that this entry is related to community handling or tagging.
Set Dampening Statement:
set dampening 1 2 3 4: This line specifies the route dampening parameters. Route dampening is a mechanism used to stabilize the network by suppressing the advertisement of flapping routes (routes that frequently go up and down). The parameters provided typically represent:
Half-life (1): The time, in minutes, it takes for the penalty assigned to a flapping route to be reduced by half.
Reuse Threshold (2): The penalty value below which a route is unsuppressed and allowed to be advertised again.
Suppress Threshold (3): The penalty value above which a route is suppressed and not advertised.
Maximum Suppress Time (4): The maximum duration, in minutes, that a route can be suppressed.
The route-map entry rm-set-localpref is designed to modify the local preference attribute of routes that it processes. Here’s a detailed explanation:
Route-Map Name and Sequence:
route-map rm-set-localpref permit 10: This specifies the name of the route-map (rm-set-localpref) and the sequence number (10). The sequence number indicates the order in which this entry is applied within the route-map.
Set Local Preference Statement:
set local-preference 110: This command sets the local preference attribute of the matched routes to 110.
BGP Origin Attribute: The origin attribute is one of the path attributes in BGP that indicates how BGP learned about a particular route. It helps in the path selection process. There are three types of origin values:
IGP: The route was learned from an Interior Gateway Protocol (IGP).
EGP: The route was learned from the Exterior Gateway Protocol (EGP), a predecessor of BGP.
Incomplete: The origin of the route is unknown or learned by some other means, often set when routes are redistributed into BGP from other routing protocols.
Setting Origin to Incomplete: By setting the origin to “incomplete,” this route-map entry indicates that the origin of the route is not derived from a BGP or IGP source. This can be useful when redistributing routes from non-BGP sources into BGP and wanting to reflect this in the BGP path attributes.
The route-map entry rm-set-origin is configured to modify the BGP (Border Gateway Protocol) origin attribute for routes it processes. Here’s a detailed explanation:
Route-Map Name and Sequence:
route-map rm-set-origin permit 10: This specifies the name of the route-map (rm-set-origin) and the sequence number (10). The sequence number determines the order in which this entry is applied within the route-map.
Set Origin Statement:
set origin incomplete: This command sets the BGP origin attribute of the matched routes to “incomplete.”
Path Preference: By setting the weight to 1000, this route-map entry ensures that the router prefers paths with this weight over others with lower weights. This is useful when you want to influence outgoing traffic to take a specific path from a particular router. The weight attribute is a Cisco-specific attribute used for path selection within a single router. It is not propagated to other routers.
Route-Map Name and Sequence:
route-map rm-set-weight permit 10: This specifies the name of the route-map (rm-set-weight) and the sequence number (10). The sequence number indicates the order in which this entry is applied within the route-map.
Set Weight Statement:
set weight 1000: This command sets the BGP weight attribute to 1000 for the matched routes.
The route-map rm-set-metric is designed to modify the metric attribute for routes it processes. Each entry specifies different metric values, potentially for different routing protocols or scenarios. Here’s an explanation of each entry:
First Entry: route-map rm-set-metric permit 10:
Set Metric Statement: set metric 1000
Behavior: This entry sets the metric for the matched routes to 1000. The metric is a value used by routing protocols to determine the best path to a destination. A lower metric is generally preferred over a higher one. This simple metric setting is typically used for protocols like OSPF or EIGRP, where a single metric value is sufficient to influence path selection.
Second Entry: route-map rm-set-metric permit 20:
Set Metric Statement: set metric 1000 100 255 255 1500
Behavior: This entry sets a more complex metric, consisting of multiple values. This is likely intended for use with a routing protocol that supports composite metrics, such as EIGRP, which uses multiple components to calculate the overall metric. Here’s a general breakdown of what these values might represent in EIGRP:
Bandwidth: 1000 - Represents the minimum bandwidth (in kilobits per second) along the path.
Delay: 100 - Represents the cumulative delay (in tens of microseconds) along the path.
Reliability: 255 - A value from 0 to 255 indicating the reliability of the path, where 255 is 100% reliable.
Load: 255 - A value from 0 to 255 indicating the load on the path, where 0 is no load.
MTU: 1500 - The maximum transmission unit, which is the size of the largest packet that can be sent over the path.
