No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Configuration Guide - IP Unicast Routing

CloudEngine 12800 and 12800E V200R002C50

This document describes the configurations of IP Unicast Routing, including IP Routing, Static Route, RIP, RIPng, OSPF, OSPFv3, IPv4 IS-IS, IPv6 IS-IS, BGP, Routing Policy, and PBR.

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Understanding Routing Policies

Understanding Routing Policies

A routing policy uses different matching rules and modes to select routes and change route attributes. Six different filters in the routing policy can be used independently to filter routes in specific scenarios. If the device supports the Border Gateway Protocol (BGP) to Interior Gateway Protocol (IGP) function, the BGP private attributes can serve as matching rules when the IGP imports BGP routes.

Implementation of Routing Policies

Figure 10-1 Working mechanism of a routing policy

Figure 10-1 shows that a routing policy consists of N nodes (N ≥ 1). Each node has its own set of if-match clauses that must be matched in order to accept a policy. The if-match clauses define matching rules related to route attributes and six filters. The system checks routes in the nodes of a routing policy in ascending order of node IDs.

When a route matches all if-match clauses in a node, the route enters the matching mode without other nodes checking. The two supported matching modes are:

  • permit: A route is permitted, and actions defined by apply clauses are performed on the route to set its attributes.
  • deny: A route is denied.

If a route does not match any if-match clause in a node, the route is passed to the next node. If the route does not match all of the If-match clauses in any one of the nodes, the route is filtered out.

Filters

The six filters specified in if-match clauses in a routing policy are access control list (ACL), IP prefix list, AS_Path filter, community filter, extended community filter, and route distinguisher (RD) filter. These filters have their own matching rules and modes and can be used independently to filter routes in specific situations. The following offers a brief explanation to each of these filters.

ACL

ACLs filter routes based on the inbound interface, source or destination IP address, source or destination port number, and protocol of packets. They can be used independently when routing protocols advertise and receive routes. The if-match clauses in a routing policy support only basic ACLs.

ACLs can be used in not only a routing policy but other scenarios. For details, see "Understanding ACLs" in the Configuration Guide - Security - ACL Configuration.

IP Prefix List

IP prefix lists filter routes based on the IP prefixes of the source IP address, destination IP address, and next-hop IP address of packets. They can be used independently when routing protocols advertise and receive routes.

Each IP prefix list consists of multiple indexes, and each index matches a node. An IP prefix list checks routes in the nodes of a routing policy in ascending order of node IDs. If a route matches one node, the route is not checked by additional nodes. If a route does not match any one of the nodes, the route is filtered out.

The IP prefix list supports exact matching or matching within a specified mask length.

NOTE:

When an IP address is 0.0.0.0 (a wildcard address), all routes in the mask length range are permitted or denied.

AS_Path Filter

The AS_Path filter uses the AS_Path attribute of BGP to filter routes. It can be used independently when BGP advertises and receives routes.

The AS_Path attribute records all ASs that a BGP route passes through. For details about the AS_Path attribute, see "Understanding BGP - BGP Concepts" in the Configuration Guide - IP Routing - BGP Configuration.

Community Filter

The community filter uses the community attribute of BGP to filter routes. It can be used independently when BGP advertises and receives routes.

The BGP community attribute identifies a group of routes with the same properties. For details about the community attribute, see "Understanding BGP - BGP Concepts" in the Configuration Guide - IP Routing - BGP Configuration.

Extended Community Filter

The extended community filter uses the extended community attribute of BGP to filter routes. It can be used independently when VPN targets are used to identify routes in a VPN.

Currently, the extended community filter applies only to the VPN target attribute in a VPN. On a BGP/MPLS IP VPN, VPN targets are used to control the advertising and receiving of VPN routing information between sites. For details about the VPN target attribute, see "Understanding BGP/MPLS IP VPN - Concepts" in the Configuration Guide - VPN - BGP/MPLS IP VPN Configuration.

RD Filter

The RD filter uses the RD attribute in a VPN to filter routes. It can be used independently when the RD attribute is used to identify routes in a VPN.

A VPN instance uses RDs to separate address spaces and distinguish the IP prefixes with the same address space. For details about the RD attribute, see "Understanding BGP/MPLS IP VPN - Concepts" in the Configuration Guide - VPN - BGP/MPLS IP VPN Configuration.

BGP to IGP Function

The BGP to IGP function enables IGPs to identify private attributes of BGP such as the community, extended community, and AS_Path attributes.

Routing policies can be used when an IGP imports BGP routes. BGP private attributes can be used as matching rules in routing policies only when the device supports the BGP to IGP function. When the device does not support the BGP to IGP function, the IGP cannot identify private attributes of BGP routes. Therefore, matching rules do not take effect.

Translation
Download
Updated: 2019-03-21

Document ID: EDOC1000166601

Views: 274483

Downloads: 161

Average rating:
This Document Applies to these Products

Related Version

Related Documents

Share
Previous Next