Define rules: Define route characteristics for route matching. Specifically, you need to define a set of matching rules based on route attributes, such as the destination address and the address of the router that advertises the routes. For details, see Route-Filters.
Apply rules: Apply the matching rules to route advertisement, acceptance, and import.
Global variable set: A global variable set is a group of frequently used values that are defined as global variables. Global variables are variables that can be referenced by all route-filters on a device. To enable a route-filter to reference a global variable, enter $+variable name, for example, $glovar1. The global variables on a device must be unique. A new global variable will override an existing global variable with the same name.
Route attribute set: A route attribute set is a group of data concerning a route attribute. If the routes to be filtered have the same or similar route attribute, for example, they are destined for the same network segment or originate from the same AS, you can configure a route attribute set for the routes as matching rules. The application scopes and matching items vary with the route attribute set. Table 1 shows the application scopes and matching items of different route attribute sets.
Sets do not have the permit or deny function as routing policies do. Instead, sets are only groups of data used as matching rules, and the actions to be applied are specified in route-filters.
Name |
Application Scope |
Matching Attribute |
---|---|---|
IPv4 prefix set |
Routes of all dynamic routing protocols |
Source, destination, and next hop IP addresses |
IPv6 prefix set |
Routes of all dynamic routing protocols |
Source, destination, and next hop IP addresses |
AS_Path set |
BGP routes |
AS_Path |
Community set |
BGP routes |
Community |
Large-Community set |
BGP routes |
Large-Community |
Extended community set |
VPN routes |
Route target and Site-of-Origin |
RD set |
VPN routes |
RD |
Figure 1 shows how a route-filter is used to filter routes. For details about condition and action clauses, see XPL Statements.
XPL statements are used to convert matching rules to sets and route-filters. XPL statements include the remark, set definition, set element, condition clause, action clause, and route-filter with pre-defined variables.
Remark
A remark is an explanation attached to an XPL policy configuration line, beginning with an exclamatory mark (!). NOTE:
If the list is not empty, no remarks can be configured in the last line (the line above the end-list). |
xpl ip-prefix-list prefix-list1 ! prefix-list1 is the name of an ip-prefix-list. 10.0.1.0 24, 10.0.3.0 24 eq 26, 10.0.2.0 24 le 28, 10.0.4.0 24 ge 26 le 30 end-list |
Set definition
A set definition specifies matching rules and begins and ends with apparent clauses. |
For example, an IPv4 prefix set begins with xpl ip-prefix-list and ends with end-list, with a group of IPv4 prefixes in between. xpl ip-prefix-list prefix-list2 10.0.1.0 24, 10.0.3.0 24 eq 26, 10.0.2.0 24 le 28, 10.0.4.0 24 ge 26 le 30 end-list |
Set element
Set elements include elements such as IP prefixes, AS_Path values, and communities. The elements are separated with commas. Elements in a route-filter must have the same type as the route-filter. |
xpl ip-prefix-list prefix-list3 10.0.1.0 24, ! element 10.0.3.0 24 eq 26, ! element 10.0.2.0 24 le 28, ! element 10.0.4.0 24 ge 26 le 30 end-list |
Condition clause
Condition clauses are used in route-filters. Condition clauses can be used with sets to define matching rules. Condition clauses can be if, elseif, or else clauses. Condition clauses may include eq (equal to), ge (greater than or equal to), le (less than or equal to), and in (included in) expressions, which can be used in conjunction with the Boolean condition not, and, or or. in can be followed by a set so that the elements in the set are used as matching rules. |
xpl route-filter route-filter1 ! route-filter1 is the name of Route-Filter if med eq 20 then apply community { 100:1 } additive endif end-filter |
Action clause
Action clauses specify the actions to be applied to given routes and include the following clauses:
|
xpl route-filter route-filter2 ! Name of Route-Filter if med eq 10 then approve endif end-filter |
Route-filter with pre-defined variables
XPL supports route-filters with pre-defined variables. Route-filters with pre-defined variables can be referenced during route-filter configuration through call clauses. |
xpl route-filter param-route-filter ($mytag) ! Configure a route-filter with a pre-defined variable. apply community { 1234:$mytag } additive end-filter xpl route-filter origin-10 ! Reference the route-filter with the pre-defined variable. if med eq 20 then call route-filter param-route-filter (10) else permit endif end-filter |