Table of Contents

Chapter 1 IP Route Policy Configuration. 1-1

1.1 Introduction to IP Route Policy. 1-1

1.1.1 Filter 1-1

1.1.2 Route Policy Application. 1-3

1.2 Configuring IP Route Policy. 1-3

1.2.1 Configuring a Route-policy. 1-3

1.2.2 Configuring an IP Prefix List 1-7

1.2.3 Configuring the AS Path List 1-8

1.2.4 Configuring a Community Attribute List 1-8

1.2.5 Applying Route Policy on Redistributed Routes. 1-9

1.2.6 Applying Route Policy on Received or Advertised Routes. 1-9

1.3 Displaying and Debugging Route Policy. 1-10

1.4 IP Route Policy Configuration Example. 1-11

1.4.1 Configuring to Filter the Received Routing Information. 1-11

1.5 Troubleshooting Route Policy. 1-12

 

Chapter 1  IP Route Policy Configuration

When configuring routing policy, go to these sections for information you are interested in:

l           Introduction to IP Route Policy

l           Configuring IP Route Policy

l           Displaying and Debugging Route Policy

l           IP Route Policy Configuration Example

l           Troubleshooting Route Policy

 

 

1.1  Introduction to IP Route Policy

When a router advertises or receives routing information, it possibly needs to implement some policies to filter the routing information, so as to receive or advertise the routing information which can meet the specified condition only. A routing protocol, e.g. RIP, may need import the routing information discovered by other protocols to enrich its routing knowledge. While redistributing the routing information, it possibly only needs import the information meeting the conditions and set some special attributes to make them meet its requirement.

For implementing the route policy, you need define a set of matching rules by specifying the characteristics of the routing information to be filtered. You can set the rules based on such attributes like destination address and source address of the information. The matching rules can be set in advance and then used in the route policy to advertise, receive and import the route information.

1.1.1  Filter

In the S9500 series, five filters, Route-policy, ACL, AS-path, Community-list, and IP-prefix, are provided to be used by the routing protocols. The following sections introduce these filters respectively.

I. ACL

The access control lists (ACLs) used by route policy can be divided into the following types:

l           Number-based basic ACLs

l           Name-based basic ACLs

l           Number-based advanced ACLs

l           Name-based advanced ACLs

l           Number-based L2 ACLs

l           Name-based L2 ACLs

For routing information filtering, the basic ACL is generally used. When users define the ACL, they will define the range of an IP address or subnet to the destination network segment address or the next-hop address of the routing information. If an advanced ACL is used, perform the matching operation by the specified source address range.

II. IP-prefix

The function of the IP-prefix is similar to that of ACL, but it is more flexible and easy for the users to understand. When the IP-prefix is applied to the routing information filtering, its matching objects are the destination address information domain of the routing information.

An IP-prefix is identified by the IP-prefix name. Each IP-prefix can include multiple list items, and each list item can independently specify the match range of the network prefix forms and is identified with an index-number. The index-number designates the matching check sequence in the IP-prefix.

During the matching, the router checks list items identified by the sequence-number in the ascending order. Once a single list item meets the condition, it means that it has passed the IP-prefix filtering and will not enter the testing of the next list item.

III. AS-path

The AS-path list is only used in BGP. The routing information packet of BGP includes an autonomous system path domain (During the process of routing information exchanging of BGP, the autonomous system paths the routing information has passed through will be recorded in this domain). Targeting at the AS path domain, the AS-path specifies the match condition.

IV. Community-list

The community-list is only used in BGP. The routing information packet of BGP includes a community attribute domain to identify a community. Targeting at the community attribute, the community-list specifies the match condition.

1.1.2  Route Policy Application

Two route policy applications are as follows:

When advertising/receiving routing information, the router filters the information according to the route policy, and receives or advertises the routing information which can meet the specified condition only.

When redistributing other routes detected by other routing protocol, the router only redistributes the routing information, which can meet the specified condition only, according to the route policy.

1.2  Configuring IP Route Policy

The route policy configuration includes:

1)         Filter configuration includes:

l           Configuring a Route-policy

l           Configuring an IP Prefix List

l           Configuring the AS Path List

l           Configuring a Community Attribute List

 

 

2)         Applications of routing policies include:

l           Applying Route Policy on Redistributed Routes

l           Applying Route Policy on Received or Advertised Routes

1.2.1  Configuring a Route-policy

A route-policy can comprise multiple nodes. Each node is a unit for matching operation. The nodes will be tested against by node-number.

Each node consists of a group of if-match clauses and apply clauses.

l           The if-match clauses define the matching rules. The different if-match clauses for a node have the relationship of “AND”. That is, the route must satisfy all the if-match clauses for the node to match the node before passing this node.

l           The apply clauses define the executed action after the routing information passes the matching test. That is, the clause sets the routing information attribute.

I.  Defining a route-policy

Perform the following configuration in system view to define/remove a route-policy:

To do...	Use the command...
Enter Route policy view	route-policy route-policy-name { permit | deny } node node-number
Remove the specified route-policy	undo route-policy route-policy-name [ permit | deny | node node-number ]

 

The permit keyword specifies the matching mode for a defined node in the route-policy to be in permit mode. If a route satisfies all the if-match clauses of the node, it will pass the filtering of the node, and the apply clauses for the node will be executed without taking the test of the next node. If not, however, the route should take the test of the next node.

The deny keyword specifies the matching mode for a defined node in the route-policy to be in deny mode. In this mode, the apply clauses will not be executed. If a route satisfies all the if-match clauses of the node, it will be denied by the node and will not take the test of the next node. If not, however, the route will take the test of the next node.

The nodes have the “OR” relationship. In other words, the router will test the route against the nodes in the route-policy in sequence. Once a node is matched, the route-policy filtering will be passed.

By default, the route-policy is not defined.

Note: If multiple nodes are defined in a route-policy, at least one of them should be in permit mode. Apply the route-policy to filter routing information. If the routing information does not match any node, the routing information will be denied by the route-policy. If all the nodes in the route-policy are in deny mode, all routing information will be denied by the route-policy.

II. Defining if-match clauses for a route-policy

The if-match clauses define the matching rules. That is, the filtering conditions that the routing information should satisfy for passing the route-policy. The matching objects are some attributes of routing information.

Perform the following configuration in route policy view:

To do...	Use the command...
Match the AS path domain of the BGP routing information	if-match as-path acl-number
Disable matching the AS path domain of the BGP routing information	undo if-match as-path
Match the community attribute of the BGP routing information	if-match community { basic-community-number [ whole-match ] | adv-community-number }
Disable matching the community attribute of the BGP routing information	undo if-match community
Match the destination address of the routing information	if-match { acl acl-number | ip-prefix ip-prefix-name }
Disable matching the destination address of the routing information	undo if-match { acl | ip-prefix }
Match the next-hop interface of the routing information	if-match interface interface-type interface-number
Disable matching the next-hop interface of the routing information	undo if-match interface
Match the next-hop of the routing information	if-match ip next-hop { acl acl-number | ip-prefix ip-prefix-name }
Disable matching the next-hop of the routing information set by ACL	undo if-match ip next-hop
Disable matching the next-hop of the routing information set by address prefix list	undo if-match ip next-hop ip-prefix
Match the routing cost of the routing information	if-match cost value
Disable matching the routing cost of the routing information	undo if-match cost
Match the tag domain of the OSPF routing information	if-match tag value
Cancel the tag domain of the matched OSPF routing information	undo if-match tag

 

 

By default, no matching will be performed.

Note the following:

The if-match clauses for a node in the route-policy have the relationship of “AND” for matching. That is, the route must satisfy all the clauses to match the node before the actions specified by the apply clauses can be executed.

If no if-match clauses are specified, all the routes will pass the filtering on the node.

III. Defining apply clauses for a route-policy

The apply clauses specify actions, which are the configuration commands executed after a route satisfies the filtering conditions specified by the if-match clauses. Thereby, some attributes of the route can be modified.

Perform the following configuration in route policy view:

To do...	Use the command...
Add the specified AS number before the AS-path series of the BGP routing information	apply as-path as-number-1 [ as-number-2 [ as-number-3 ... ] ]
Cancel the specified AS number added before the AS-path series of the BGP routing information	undo apply as-path
Set the community attribute in the BGP routing information	apply community [ aa:nn ]* [ [ no-export-subconfed | no-export | no-advertise ] * [ additive ] | additive | none ]
Cancel the set community attribute in the BGP routing information	undo apply community
Set the extended community attribute for BGP routes	apply extcommunity { rt { as-number : nn | ip-address : nn } [ additive ] }&<1-16>
Remove the apply clause	undo apply extcommunity
Set the next-hop address of the routing information	apply ip next-hop ip-address
Cancel the next-hop address of the routing information	undo apply ip next-hop
Specifies to import routes to IS-IS Level-1, Level-2 or Level-1-2	apply isis [ level-1 | level-2 | level-1-2 ]
Cancel the IS-IS level setting for route import	undo apply isis
Set the local preference of the BGP routing information	apply local-preference local-preference-value
Cancel the local preference of the BGP routing information	undo apply local-preference
Set the routing cost of the routing information	apply cost value
Cancel the routing cost of the routing information	undo apply cost
Set the cost type of the routing information	apply cost-type [ internal | external ]
Remove the setting of the cost type	undo apply cost-type
Set the route origin of the BGP routing information	apply origin { igp | egp as-number | incomplete }
Cancel the route origin of the BGP routing information	undo apply origin
Set the tag domain of the OSPF routing information	apply tag value
Cancel the tag domain of the OSPF routing information	undo apply tag

 

 

By default, perform no settings.

Note that if the routing information meets the match conditions specified in the route-policy and also notifies the MED value configured with the apply cost-type internal when notifying the IGP route to the EBGP peers, then this value will be regarded as the MED value of the IGP route. The preference configured with the apply cost-type internal command is lower than that configured with the apply cost command, but higher than that configured with the default med command.

1.2.2  Configuring an IP Prefix List

An IP-prefix list is identified by an ip-prefix-name. Each IP-prefix-list can include multiple entries with each specifying an IP prefix matching range. IP prefix entries are identified by index-numbers. The order in which IP prefix entries are matched against depends on the order of their index numbers.

Perform the following configuration in system view define/remove an IP prefix list:

To do...	Use the command...
Define prefix-list	ip ip-prefix ip-prefix-name [ index index-number ] { permit | deny } network len [ greater-equal greater-equal ] [ less-equal less-equal ]
Remove prefix-list	undo ip ip-prefix ip-prefix-name [ index index-number | permit | deny ]

 

During the matching, the router checks list items identified by the index-number in the ascending order. If only one list item meets the condition, it means that it has passed the IP-prefix filtering (will not enter the testing of the next list item).

Note that if more than one ip-prefix item are defined, then the match mode of at least one list item should be the permit mode. The list items of the deny mode can be firstly defined to rapidly filter the routing information not satisfying the requirement, but if all the items are in the deny mode, no route will pass the ip-prefix filtering. You can define an item of permit 0.0.0.0/0 greater-equal 0 less-equal 32 after the multiple list items in the deny mode so as to let all the other routes pass.

1.2.3  Configuring the AS Path List

The BGP routing information packet includes an autonomous system path domain. The as path-list can be used to match with the autonomous system path domain of the BGP routing information so as to filter the routing information, which does not conform to the requirements.

Perform the following configuration in the system view to define/delete the AS path list:

To do...	Use the command...
Define the AS path list	ip as-path-acl acl-number { permit | deny } as-regular-expression
Delete the specified AS path list	undo ip as-path-acl acl-number

 

By default, no AS path list is defined.

1.2.4  Configuring a Community Attribute List

In BGP, community attribute is optional and transitive. Some community attributes known globally are called standard community attributes. Some community attributes are for special purpose. You can also define expanded community attribute.

A route can have one more community attributes. The speakers of multiple community attributes of a route can act according to one, several or all attributes. A router can select community attribute modification before transmitting routes to other peers.

Community lists, which identify community information, can be divided into basic-community-lists and advanced-community-lists. Basic-community-lists range from 1 to 99, while advanced-community-lists range from 100 to 199.

Perform the following configuration in system view:

To do...	Use the command...
Configure a basic community-list	ip community-list basic-comm-list-number { permit | deny } [ aa:nn ]* [ internet | no-export-subconfed | no-advertise | no-export ]*
Configure an advanced community-list	ip community-list adv-comm-list-number { permit | deny } comm-regular-expression
Cancel a community-list	undo ip community-list { basic-comm-list-number | adv-comm-list-number }

 

By default, a BGP community attribute list is not configured.

1.2.5  Applying Route Policy on Redistributed Routes

A routing protocol can redistribute the routes discovered by other routing protocols to enrich its route information. The route-policy can be used for route information filtering to implement the purposeful redistribution. If the destination routing protocol importing the routes cannot directly reference the route costs of the source routing protocol, you should satisfy the requirement of the protocol by specifying a route cost for the redistributed route.

 

 

1.2.6  Applying Route Policy on Received or Advertised Routes

I. Configuring to filter the received routes

Perform the following configuration in routing protocol view.

Define a policy to filter the routing information not satisfying the conditions while receiving routes with the help of an ACL or address prefix-list. gateway specifies that only the update packets from a particular neighboring router will be received.

Follow these steps to configure the filtering of received routes:

To do...	Use the command...
Configure to filter the received routing information advertised by the specified address	filter-policy gateway ip-prefix-name import
Cancel the filtering of the received routing information advertised by the specified address	undo filter-policy gateway ip-prefix-name import
Configure to filter the received global routing information	filter-policy { acl-number | ip-prefix ip-prefix-name [ gateway ip-prefix-name] } import
Cancel the filtering of the received global routing information	undo filter-policy { acl-number | ip-prefix ip-prefix-name [ gateway ip-prefix-name] } import

 

II. Configuring to filter the advertised routes

You may define a route advertisement policy to filter advertised routing information. This can be done by referencing an ACL or IP prefix-list to filter routing information that does not meet the conditions, or by specifying a protocol to filter routing information of that protocol only.

Perform the following configuration in routing protocol view:

To do...	Use the command...
Configure to filter the routes advertised by the protocol	filter-policy { acl-number | ip-prefix ip-prefix-name } export [ routing-protocol ]
Cancel the filtering of the routes advertised by the protocol	undo filter-policy { acl-number | ip-prefix ip-prefix-name } export [ routing-protocol ]

 

By far, the route policy supports redistributing the routes discovered by the following protocols into the routing table:

direct, static, rip, ospf, ospf-ase, ospf-nssa, isis, bgp, and nat

By default, the filtering of the received and advertised routes will not be performed.

 

 

1.3  Displaying and Debugging Route Policy

To do…	Use the command…	Remarks
Display route policy	display route-policy [ route-policy-name ]	Available in any view
Display BGP AS path ACL information	display ip as-path-acl [ acl-number ]	Available in any view
Display the address prefix list information	display ip ip-prefix [ ip-prefix-name ]	Available in any view

 

1.4  IP Route Policy Configuration Example

1.4.1  Configuring to Filter the Received Routing Information

I. Network requirements

Switch A communicates with Switch B, running OSPF protocol. The router ID of Switch A is 1.1.1.1, and that of Switch B is 2.2.2.2.

Import three static routes through enabling the OSPF protocol on the Switch A.

The route filtering rules can be configured on Switch B to make the received three static routes partially visible and partially shielded. It means that routes in the network segments 20.0.0.0 and 40.0.0.0 are visible while those in the network segment 30.0.0.0 are shielded.

II. Network diagram

Figure 1-1 Network diagram for filtering the received routing information

III. Configuration procedure

1)         Configure Switch A.

# Configure the IP address of the VLAN interface.

[Switch A] interface vlan-interface 100

[Switch A-Vlan-interface100] ip address 10.0.0.1 255.0.0.0

[Switch A] interface vlan-interface 200

[Switch A-Vlan-interface200] ip address 12.0.0.1 255.0.0.0

# Configure three static routes.

[Switch A] ip route-static 20.0.0.1 255.0.0.0 12.0.0.2

[Switch A] ip route-static 30.0.0.1 255.0.0.0 12.0.0.2

[Switch A] ip route-static 40.0.0.1 255.0.0.0 12.0.0.2

# Enable the OSPF protocol and specify the number of the area to which the interface belongs.

[Switch A] router id 1.1.1.1

[Switch A] ospf

[Switch A-ospf-1] area 0

[Switch A-ospf-1-area-0.0.0.0] network 10.0.0.0 0.255.255.255

# Redistribute the static routes.

[Switch A-ospf-1] import-route static

2)         Configure Switch B.

# Configure the IP address of the VLAN interface.

[Switch B] interface vlan-interface 100

[Switch B-Vlan-interface100] ip address 10.0.0.2 255.0.0.0

# Configure the access control list.

[Switch B] acl number 2000

[Switch B-acl-basic-2000] rule deny source 30.0.0.0 0.255.255.255

[Switch B-acl-basic-2000] rule permit source any

# Enable OSPF protocol and specify the number of the area to which the interface belongs.

[Switch B] router id 2.2.2.2

[Switch B] ospf

[Switch B-ospf-1] area 0

[Switch B-ospf-1-area-0.0.0.0] network 10.0.0.0 0.255.255.255

# Configure OSPF to filter the external routes received.

[Switch B-ospf-1] filter-policy 2000 import

1.5  Troubleshooting Route Policy

Symptom 1: Routing information filtering cannot be implemented in normal operation of the routing protocol

Solution: Check for the following faults:

l           The if-match mode of at least one node of the Route-policy should be the permit mode. When a Route-policy is used for the routing information filtering, if a piece of routing information does not pass the filtering of any node, then it means that the route information does not pass the filtering of the Route-policy. When all the nodes of the Route-policy are in the deny mode, then all the routing information cannot pass the filtering of the Route-policy.

l           The if-match mode of at least one list item of the ip-prefix should be the permit mode. The list items of the deny mode can be firstly defined to rapidly filter the routing information not satisfying the requirement, but if all the items are in the deny mode, any routes will not pass the ip-prefix filtering. You can define an item of permit 0.0.0.0/0 less-equal 32 after the multiple list items in the deny mode so as to let all the other routes pass the filtering (If less-equal 32 is not specified, only the default route will be matched).