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

ME60 V800R010C10SPC500 Feature Description - WAN Access 01

This is ME60 V800R010C10SPC500 Feature Description - WAN Access
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

Implementation

Routing policies are implemented in the following steps:
  1. Define rules. Characteristics of routing information to which routing policies are applied need to be defined. Specifically, you need to define a set of matching rules regarding different attributes of routing information, such as the destination address and AS number.
  2. Apply rules. Matching rules are applied to advertise, receive, or import routes.

Filter

A filter is the core of a routing policy and is defined using a set of matching rules. The ME60 provides the filters listed in Table 10-2.

Table 10-2 Comparisons between filters

Filter

Application Scope

Matching Rules

Access control list (ACL)

Dynamic routing protocols

Inbound interface, source or destination IP address, protocol type, and source or destination port number

IP prefix list

Dynamic routing protocols

Source and destination IP addresses and next hop address

AS_Path

BGP

AS_Path attribute

Community

BGP

Community attribute

Extended community

VPN

Extended community attribute

Route distinguisher (RD)

VPN

RD attribute

Route-policy

Dynamic routing protocols

Destination IP address, next hop address, cost, interface information, route type, ACL, IP prefix list, AS_Path, community, extended community, and RD.

The ACL, IP prefix list, AS_Path, community, Extended community, and RD filters can be used to filter routes but cannot modify route attributes. A route-policy is a comprehensive filter and can use the matching rules of the ACL, IP prefix list, AS_Path, community, Extended community, and RD filters to filter routes and change route attributes.

ACL

An ACL is a set of sequential filtering rules. Users can define rules based on packet information, such as inbound interfaces, source or destination IP addresses, protocol types, or source or destination port numbers and specify an action to deny or permit packets. After an ACL is configured, the system classifies received packets based on the rules defined in the ACL and denies or permits the packets accordingly.

An ACL only classifies packets based on defined rules and filters packets only after it is applied to a routing policy.

ACLs can be configured for both IPv4 packets and IPv6 packets. Based on the usage, ACLs are classified as interface-based ACLs, basic ACLs, or advanced ACLs. Users can specify the IP address and subnet address range in an ACL to match the source IP address, destination network segment address, or the next hop address of a route.

ACLs can be configured on access or core devices to:
  • Protect the devices against IP, TCP, and Internet Control Message Protocol (ICMP) packet attacks.
  • Control network access. For example, ACLs can be used to control the access of enterprise network users to external networks, the specific network resources that users can access, and the period for which users can access networks.
  • Limit network traffic and improve network performance. For example, ACLs can be used to limit bandwidth for upstream and downstream traffic, charge for the bandwidth that users have applied for, and fully use high-bandwidth network resources.

For details about ACL features, see ACL.

IP Prefix List

An IP prefix list contains a group of route filtering rules. Users can specify the prefix and mask length range to match the destination network segment address or the next hop address of a route. An IP prefix list is used to filter routes that are advertised and received by various dynamic routing protocols.

An IP prefix list is easier and more flexible than an ACL. However, if a large number of routes with different prefixes need to be filtered, configuring an IP prefix list to filter the routes is complex.

IP prefix lists can be configured for both IPv4 routes and IPv6 routes, and they share the same implementation process. An IP prefix list filters routes based on the mask length or mask length range.
  • Mask length: An IP prefix list filters routes based on IP address prefixes. An IP address prefix is defined by an IP address and the mask length. For example, for route 10.1.1.1/16, the mask length is 16 bits, and the valid prefix is 16 bits (10.1.0.0).
  • Mask length range: Routes with the IP address prefix and mask length within the range defined in the IP prefix list meet the matching rules.
NOTE:
0.0.0.0 is a wildcard address. If the IP prefix is 0.0.0.0, specify either a mask or a mask length range, with the following results:
  • If a mask is specified, all routes with the mask are permitted or denied.
  • If a mask length range is specified, all routes with the mask length in the range are permitted or denied.

AS_Path

An AS_Path is used to filter BGP routes based on AS_Path attributes contained in BGP routes. The AS_Path attribute is used to record in distance-vector (DV) order the numbers of all ASs through which a BGP route passes from the local end to the destination. Therefore, AS_Path attributes can be used to filter BGP routes.

The matching condition of an AS_Path is specified using a regular expression. For example, ^30 indicates that only the AS_Path attribute starting with 30 is matched. Using a regular expression can simplify configurations. For details about regular expressions, see Configuration Guide - Basic Configurations.

NOTE:

The AS_Path attribute is a private attribute of BGP and is therefore used to filter BGP routes only. For details about the AS_Path attribute, see BGP Fundamentals.

Community

A community is used to filter BGP routes based on the community attributes contained in BGP routes. The community attribute is a set of destination addresses with the same characteristics. Therefore, community attributes can be used to filter BGP routes.

In addition to the well-known community attributes, users can define community attributes using digits. The matching condition of a community filter can be specified using a community ID or a regular expression.

NOTE:

Like AS_Path filters, community filters are used to filter only BGP routes because the community attribute is also a private attribute of BGP. For details about the community attribute, see Community Attribute.

Extended Community

An extended community is used to filter BGP routes based on extended community attributes. BGP extended community attributes are classified into two types:
  • VPN target: A VPN target controls route learning between VPN instances, isolating routes of VPN instances from each other. A VPN target may be either an import or export VPN target. Before advertising a VPNv4 or VPNv6 route to a remote MP-BGP peer, a PE adds an export VPN target to the route. After receiving a VPNv4 or VPNv6 route, the remote MP-BGP peer compares the received export VPN target with the local import VPN target. If they are the same, the remote MP-BGP peer adds the route to the routing table of the local VPN instance.

  • Source of Origin (SoO): Several CEs at a VPN site may be connected to different PEs. The VPN routes advertised from the CEs to the PEs may be re-advertised to the VPN site where the CEs reside after the routes have traversed the backbone network, causing routing loops at the VPN site. In this situation, configure an SoO attribute for VPN routes. With the SoO attribute, routes advertised from different VPN sites can be distinguished and will not be advertised to the source VPN site, preventing routing loops.

The formats of a VPN target attribute and an SoO attribute are the same. The matching condition of an extended community can be specified using an extended community ID or a regular expression.

NOTE:

An extended community is used to filter only BGP routes because the extended community attribute is also a private attribute of BGP. For details about the extended community attribute, see BGP/MPLS IP VPN Fundamentals.

RD

An RD is used to filter BGP routes based on RDs in VPN routes. RDs are used to distinguish IPv4 and IPv6 prefixes in the same address segment in VPN instances. An RD filters specify matching rules regarding RD attributes.

For details about how to configure an RD, see HUAWEI ME60 Multiservice Control Gateway Configuration Guide – VPN.

Route-Policy

A route-policy is a comprehensive filter. It is used to match attributes of specified routes and change route attributes when specific conditions are met. A route-policy can use the preceding six filters to define its matching rules.

  • Composition of a Route-Policy

    As shown in Figure 10-1, a route-policy consists of node IDs, matching mode, if-match clauses, goto next-node clauses and apply clauses.
    Figure 10-1 Composition of a route-policy

    • Node ID

      A route-policy consists of one or more nodes. Node IDs are specified as indexes in the IP prefix list. In a route-policy, routes are filtered based on the following rules:
      • Sequential matching: The system checks entries based on node IDs in ascending order. Therefore, specifying the node IDs in the required sequence is recommended.
      • One-time matching: The relationship between the nodes of a route-policy is "OR". If a route matches one node, the route matches the route-policy and will not be matched against the next node.
    • Matching mode

      Either of the following matching modes can be used:
      • permit: specifies the permit mode of a node. If a route matches the if-match clauses of a node, all the actions defined by apply clauses are performed, and the matching is complete. If a route does not match the if-match clauses of the node, the route continues to match against the next node.
      • deny: specifies the deny mode of a node. In deny mode, the apply clauses are not used. If a route matches all the if-match clauses of the node, the route is denied by the node and no longer matches against the next node. If the route does not match any of the if-match clauses, the route continues to match against the next node.
      NOTE:
      To allow other routes to pass through, a route-policy that contains no if-match or apply clause in permit mode needs to be configured for a node next to multiple nodes in deny mode.
    • if-match clause

      The if-match clause defines the matching rules.

      Each node of a route-policy can comprise multiple if-match clauses or no if-match clause at all. If no if-match clause is configured for a node in permit mode, all IPv4 and IPv6 routes match the node. If an if-match clause is configured to match only IPv4 routes for a node in permit mode, matching IPv4 routes and all IPv6 routes match the node. If an if-match clause is configured to match only IPv6 routes for a node in permit mode, matching IPv6 routes and all IPv4 routes match the node.

    • apply clause

      The apply clauses specify actions. When a route matches a route-policy, the system sets some attributes for the route based on the apply clause.

      Each node of a route-policy can comprise multiple apply clauses or no apply clause at all. The apply clause is not used when routes need to be filtered but attributes of the routes do not need to be changed.

    • goto next-node clause

      goto next-node clauses further match routes against a specified node after the routes match the current node.

  • Matching results of a route-policy

    The matching results of a route-policy are obtained based on the following aspects:
    • Matching mode of the node, either permit or deny
    • Matching rules (either permit or deny) contained in the if-match clause (such as ACLs or IP prefix lists)
    The matching results are listed in Table 10-3.
    Table 10-3 Matching results of a Route-Policy
    Rule (Matching Rule Contained in if-match Clauses) Mode (Matching Mode of a Node) Matching Result
    permit permit
    • Routes matching the if-match clauses of the node match the route-policy, and the matching is complete.
    • Routes not matching the if-match clauses of the node continue to match against the next node of the route-policy.
    deny
    • Routes matching the if-match clauses of the node are denied by the route-policy, and the matching is complete.
    • Routes not matching the if-match clauses of the node continue to match against the next node of the route-policy.
    deny permit
    • Routes matching the if-match clauses of the node are denied by the route-policy and continue to match against the next node.
    • Routes not matching the if-match clauses of the node continue to match against the next node of the route-policy.
    deny
    • Routes matching the if-match clauses of the node are denied by the route-policy and continue to match against the next node.
    • Routes not matching the if-match clauses of the node continue to match against the next node of the route-policy.
    NOTE:

    If all if-match clauses and nodes of the route-policy are in deny mode, all the routes to be filtered are denied by the route-policy.

    NOTE:
    On the HUAWEI ME60, all routes that fail to match a route-policy are denied by the route-policy by default. If more than one node is defined in a route-policy, at least one of them must be in permit mode. The reason is as follows:
    • If a route fails to match any of the nodes, the route is denied by the route-policy.
    • If all the nodes in the route-policy are set in deny mode, all the routes to be filtered are denied by the route-policy.

Other Functions

In addition to the preceding functions, routing policies have an enhanced feature: BGP to IGP.

In some scenarios, when an IGP uses a routing policy to import BGP routes, route attributes, the cost for example, can be set based on private attributes, such as the community in BGP routes. However, without the BGP to IGP feature, BGP routes are denied because the IGP fails to identify private attributes, such as community attributes in these routes. As a result, apply clauses used to set route attributes do not take effect.

With the BGP to IGP feature, route attributes can be set based on private attributes, such as the community, extended community, and AS_Path attributes in BGP routes. The BGP to IGP implementation process is as follows:

  • When an IGP imports BGP routes through a route-policy, route attributes can be set based on private attributes, such as the community attribute in BGP routes.

  • If BGP routes carry private attributes, such as community attributes, the system filters the BGP routes based on the private attributes. If the BGP routes meet the matching rules, the routes match the route-policy, and apply clauses take effect.

  • If BGP routes do not carry private attributes, such as community attributes, the BGP routes fail to match the route-policy and are denied, and apply clauses do not take effect.

Translation
Download
Updated: 2019-01-04

Document ID: EDOC1100059473

Views: 14419

Downloads: 10

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next