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 Routing 01

NE05E and NE08E V300R003C10SPC500

This is NE05E and NE08E V300R003C10SPC500 Configuration Guide - IP Routing
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).
Configuring BGP4+ Routing Policies

Configuring BGP4+ Routing Policies

BGP4+ routing policies can be configured to flexibly control the sending and receiving of routes.

Usage Scenario

Routing policies can set or re-set BGP4+ route attributes using some predefined conditions, which provides a flexible and effective method to control BGP4+ route selection. The sending and receiving of routes can be flexibly controlled by applying BGP4+ routing policies.

Based on the import (or export) routing policy specified by the peer, the associated import (or export) routing conditions (if-match clauses) can be configured to filter routes, and apply clauses can be configured to set or modify route attributes. The routes that match the routing policy will be received (or sent).

Pre-configuration Tasks

Before configuring BGP4+ routing policies, complete the following tasks:

Configuration Procedures

Perform one or more of the following configurations as required.

Configuring Related BGP4+ Access Lists

BGP4+ access lists can be used when BGP4+ status is displayed or routing policies are configured.

Context

BGP4+ has two specific access lists, the AS_Path filter and the community filter. Both of them can be used when BGP4+ status is displayed or routing policies are configured.

  • AS_Path filter

    The AS_Path filter filters BGP4+ routes by the AS_Path attribute. Multiple rules (permit or deny) can be specified in a filter.

  • Community filter

    The community filter consists of multiple community attribute lists. There are two types of community attribute lists, the standard community access list and the extended community access list.

Procedure

  • Configure the AS_Path filter.
    1. Run system-view

      The system view is displayed.

    2. Run ip as-path-filter { as-path-filter-number | as-path-filter-name } [ index index-number ] { permit | deny } regular-expression

      The AS_Path filter is configured.

      After the peer as-path-filter command is used to apply a routing policy to BGP4+ routes, the AS-Path filter filters out unqualified routes.

      The AS_Path filter uses the regular expression to define matching rules. A regular expression consists of the following parts:

      • Metacharacter: defines matching rules.

      • General character: defines matching objects.

      Table 11-1 Description of metacharacters

      Special Character

      Function

      \

      Defines an escape character, which is used to mark the next character (common or special) as a common character.

      ^

      Matches the start position of the string.

      $

      Matches the end position of the string.

      *

      Matches the preceding element zero or more times.

      +

      Matches the preceding element once or more times

      ?

      Matches the preceding element zero times or once.

      .

      Matches any single character.

      ()

      Defines a subexpression, which can be empty. Both the expression and the subexpression must match.

      _

      Matches regular expressions with a sign, such as a comma (,), left brace ({), right brace (}), left parenthesis ((), right parenthesis ()), or space. The underscore (_) can be used at the beginning of a regular expression with the same function as the caret (^) or at the end of a regular expression with the same function as the dollar sign ($).

      x|y

      Matches x or y.

      [xyz]

      Matches any character in the regular expression.

      [^xyz]

      Matches any character that is not contained within the brackets.

      [a-z]

      Matches any character within the specified range.

      [^a-z]

      Matches any character beyond the specified range.

      For example, ^10 indicates that only the AS_Path attribute starting with 10 is matched. A circumflex (^) indicates that the beginning of a character string is matched.

      Multiple rules, permit or deny, can be specified in a filter. The relationship between theses rules is "OR". This means that if a route meets one of the matching rules, it will pass the AS_Path-based filtering.

      NOTE:

      For details on the regular expression, see the NE device Mid-End Router Configuration Guide - Basic Configurations.

    3. Run commit

      The configuration is committed.

  • Configure the community filter.

    Community filters are classified into two types, the standard community filter and the advanced community filter. The advanced community filter supports regular expressions and is more flexible than the standard community filter.

    1. Run system-view

      The system view is displayed.

    2. Run the following command as needed.

      • To configure the standard community filter, run ip community-filter basic comm-filter-name [ index index-number ] { permit | deny } [ community-number | aa:nn ] * &<1-9> | basic-comm-filter-num [ index index-number ] { permit | deny } [ community-number | aa:nn ] * &<1-16> } [ internet | no-export-subconfed | no-advertise | no-export ] *

      • To configure the advanced community filter, run ip community-filter { advanced comm-filter-name | adv-comm-filter-num } [ index index-number ] { permit | deny } regular-expression

    3. Run commit

      The configuration is committed.

  • Configure the extended community filter.
    1. Run system-view

      The system view is displayed.

    2. Perform either of the following operations as required to configure an extcommunity filter.

      To configure a VPN-Target extcommunity filter:

      • To configure a basic VPN-Target extcommunity filter, run the ip extcommunity-filter { basic-extcomm-filter-num | basic basic-extcomm-filter-name }[ index index-number ] { deny | permit } { rt { as-number:nn | 4as-number:nn | ipv4-address:nn } } &<1-16> command.

      • To configure an advanced VPN-Target extcommunity filter, run the ip extcommunity-filter { advanced-extcomm-filter-num | advanced advanced-extcomm-filter-name }[ index index-number ] { deny | permit } regular-expressioncommand.

      To configure an SoO extcommunity filter:

      • To configure a basic SoO extcommunity filter, run the ip extcommunity-list soo basic basic-extcomm-filter-name [ index index-number ] { permit | deny } { site-of-origin } &<1-16> command.

      • To configure an advanced SoO extcommunity filter, run the ip extcommunity-list soo advanced advanced-extcomm-filter-name [ index index-number ] { permit | deny } regular-expression command.

      Multiple entries can be defined in an extcommunity filter. The relationship between the entries is "OR". This means that if a route matches one of the rules, the route matches the filter.

    3. Run commit

      The configuration is committed.

Configuring a Route-Policy

A route-policy is used to match routes or route attributes, and to change route attributes when the matching rules are met.

Context

A route-policy is used to match routes or route attributes, and to change route attributes when the matching rules are met.

A route-policy consists of multiple nodes, and each node can comprise the following clauses:

  • if-match clauses

    The clauses define the matching rules of a route-policy. The matching objects are route attributes.

  • apply clauses

    The clauses specify actions. Configuration commands are run after a route meets the matching rules specified by the if-match clauses. The apply clauses can change certain route attributes.

NOTE:

This section describes only the BGP4+ route-policy. For detailed information about route-policy configurations, see "Routing Policy Configuration."

Procedure

  • Create a route-policy.
    1. Run system-view

      The system view is displayed.

    2. Run route-policy route-policy-name { permit | deny } node node

      The node of a route-policy is created, and the view of the route-policy is displayed.

    3. Run commit

      The configuration is committed.

  • Configure if-match clauses.
    1. Run system-view

      The system view is displayed.

    2. Run route-policy route-policy-name { permit | deny } node node

      The route-policy view is displayed.

    3. Run the following command to configure the if-match clause for the current node in the route-policy as required:

      • To use the AS_Path attribute of BGP4+ routes as a match criterion, run if-match as-path-filter { as-path-filter-number | as-path-filter-name } &<1-16>

      • To use the community attribute of BGP4+ routes as a match criterion, run:

        • if-match community-filter { basic-comm-filter-num [ whole-match ] | adv-comm-filter-num }* &<1-16>

        • if-match community-filter comm-filter-name [ whole-match ]

      The commands in Step 3 can be configured in random order. A node may have multiple or no if-match clauses.

      NOTE:
      • The relationship between the if-match clauses for a node of a route-policy is "AND". A route must meet all the matching rules before the action defined by the apply clause is performed.

      • If no if-match clause is specified, all the routes are matched.

    4. Run commit

      The configuration is committed.

  • Configure the apply clause.
    1. Run system-view

      The system view is displayed.

    2. Run route-policy route-policy-name { permit | deny } node node

      The route-policy view is displayed.

    3. Run the following command as needed to configure the apply clause for the current node in the route-policy:

      • To replace the AS number in the AS_Path attribute with the specified AS number or add the specified AS number to the AS_Path attribute of BGP4+ routes, run apply as-path as-number &<1-63> { additive | overwrite | delete }

      • To delete the specified community attribute of BGP4+ routes, run apply comm-filter comm-filter-number delete

        NOTE:

        The apply comm-filter delete command deletes the specified community attribute from routes. Running the ip community-filter command specifies only one community attribute each time. To delete more than one community attribute, run the ip community-filter command multiple times. If multiple community attributes are specified in one filter, none of them can be deleted. For examples, see the NE device Mid-End Router Command Reference.

      • To delete the community attribute of BGP4+ routes, run apply community none
      • To set the community attribute for BGP4+ routes, run apply community { { community-number | aa:nn } &<1-32> | internet | no-advertise | no-export | no-export-subconfed }* [ additive ]
      • To set the MED, run apply cost { [ apply-type ] cost | inherit }
      • To set the MED value of BGP4+ routes as the IGP cost of the next hop, run apply cost-type internal
      • To set the VPN-Target extended community attribute for BGP4+ routes, run apply extcommunity rt { as-number:nn | ipv4-address:nn } [ additive ]
      • To set the local preference for BGP4+ routes, run apply local-preference [ + | - ] preference
      • To set the Origin attribute for BGP4+ routes, run apply origin { igp | egp { as-number-plain | as-number-dot } | incomplete }
      • To set the preferred value for BGP4+ routes, run apply preferred-value preferred-value
      • To set dampening parameters for EBGP routes, run apply dampening half-life-reach reuse suppress ceiling

      The commands in Step 3 can be configured in random order.

    4. Run commit

      The configuration is committed.

Configuring a Policy for Advertising BGP4+ Routes

BGP4+ filters imported routes, and only the routes that meet the matching rules are added to the local BGP4+ routing table and advertised to BGP4+ peers.

Context

BGP4+ can apply a routing policy to all the routes to be advertised or only the routes to be advertised to a certain peer (group). If multiple filter policies are configured, BGP advertises only routes that match all the filter policies.

Procedure

  • Configure BGP to filter all the routes to be advertised.
    1. Run system-view

      The system view is displayed.

    2. Run bgp as-number

      The BGP view is displayed.

    3. Run ipv6-family unicast

      The IPv6 unicast address family view is displayed.

    4. Run filter-policy { acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-prefix-name } export [ direct | isis process-id | ospfv3 process-id | ripng process-id | static | unr ]

      The routes to be advertised are filtered.

      BGP4+ filters the routes imported using the import-route command, and only the routes that meet the matching rules are added to the local BGP4+ routing table and advertised to BGP4+ peers.

      If protocol is specified, only the routing information of a specified protocol is filtered. If protocol is not specified, all BGP routes to be advertised are filtered, including the routes imported using the import-route and network commands.

    5. Run commit

      The configuration is committed.

  • Apply a routing policy to the routes to be advertised to a certain peer (group).
    1. Run system-view

      The system view is displayed.

    2. Run bgp as-number

      The BGP view is displayed.

    3. Run ipv6-family unicast

      The IPv6 unicast address family view is displayed.

    4. Run the following command as needed to configure BGP4+ to use a specified filter to filter the routes to be advertised to a peer.

      • To filter routes based on a basic ACL, perform the following steps:
        1. Run the peer { ipv4-address | ipv6-address | group-name } filter-policy { acl6-number | acl6-name acl6-name } export command to filter routes to be advertised based on an ACL.
        2. Run the quit command to return to the BGP view.

        3. Run the quit command to return to the system view.

        4. Run the acl ipv6 { name basic-acl6-name { basic | [ basic ] number basic-acl6-number } | [ number ] basic-acl6-number } [ match-order { config | auto } ] command to enter the basic ACL view.

        5. Run the rule [ rule-id ] [ name rule-name ] { deny | permit } [ fragment | source { source-ipv6-address { prefix-length | source-wildcard } | source-ipv6-address/prefix-length | any } | time-range time-name | [ vpn-instance vpn-instance-name | vpn-instance-any ] ] * command to configure a rule for the basic ACL.

          When the rule command is run to configure rules for a named ACL, only the source address range specified by source and the time period specified by time-range are valid as the rules.

          When a filtering policy of a routing protocol is used to filter routes:
          • If the action specified in an ACL rule is permit, a route that matches the rule will be received or advertised by the system.

          • If the action specified in an ACL rule is deny, a route that matches the rule will not be received or advertised by the system.

          • If a route has not matched any ACL rules, the route will not be received or advertised by the system.

          • If an ACL does not contain any rules, all routes matching the route-policy that references the ACL will not be received or advertised by the system.

          • If the ACL referenced by the route-policy does not exist, all routes matching the route-policy will be received or advertised by the system.

          • In the configuration order, the system first matches a route with a rule that has a smaller number and then matches the route with a rule with a larger number. Routes can be filtered using a blacklist or a whitelist:

            Route filtering using a blacklist: Configure a rule with a smaller number and specify the action deny in this rule to filter out the unwanted routes. Then, configure another rule with a larger number in the same ACL and specify the action permit in this rule to receive or advertise the other routes.

            Route filtering using a whitelist: Configure a rule with a smaller number and specify the action permit in this rule to permit the routes to be received or advertised by the system. Then, configure another rule with a larger number in the same ACL and specify the action deny in this rule to filter out unwanted routes.

      • To use the AS_Path attribute for route filtering, run peer { ipv4-address | ipv6-address | group-name } as-path-filter { as-path-filter-number | as-path-filter-name } export

      • To use a prefix list for route filtering, run peer { ipv4-address | ipv6-address | group-name } ipv6-prefix ipv6-prefix-name export

      • To use a route-policy for route filtering, run peer { ipv4-address | ipv6-address | group-name } route-policy route-policy-name export

      A peer group and its members can use different export policies when advertising routes. This means that each member in a peer group can select its own policy when advertising routes.

    5. Run commit

      The configuration is committed.

Configuring a Policy for Receiving BGP4+ Routes

BGP4+ filters received routes using a policy. Only the routes that match the policy can be added to a routing table.

Context

BGP4+ can apply a routing policy to all received routes or only routes received from a specific peer (group). If multiple filter policies are configured, BGP accepts only routes that match all the filter policies.

If a device is under malicious attacks or some network configurations are incorrect, the device will receive a large number of routes from its BGP4+ peers, consuming lots of device resources. BGP4+ provides peer-specific route control to limit the number of routes sent from a peer or peer group.

Procedure

  • Configure BGP4+ to filter all received routes.
    1. Run system-view

      The system view is displayed.

    2. Run bgp as-number

      The BGP view is displayed.

    3. Run ipv6-family unicast

      The IPv6 unicast address family view is displayed.

    4. Run filter-policy { acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-prefix-name } import

      A policy is configured to filter all received BGP4+ routes.

      Only the routes that match the policy are added to a routing table.

    5. Run commit

      The configuration is committed.

  • Configure BGP4+ to filter the routes received from a specific peer (group).
    1. Run system-view

      The system view is displayed.

    2. Run bgp as-number

      The BGP view is displayed.

    3. Run ipv6-family unicast

      The IPv6 unicast address family view is displayed.

    4. Run the following commands as needed to configure BGP4+ to use different filters to filter routes received from peers:

      • To filter routes based on a basic ACL, perform the following steps:
        1. Run the peer { ipv4-address | ipv6-address | group-name } filter-policy { acl6-number | acl6-name acl6-name } import command to filter received routes based on an ACL.
        2. Run the quit command to return to the BGP view.

        3. Run the quit command to return to the system view.

        4. Run the acl ipv6 { name basic-acl6-name { basic | [ basic ] number basic-acl6-number } | [ number ] basic-acl6-number } [ match-order { config | auto } ] command to enter the basic ACL view.

        5. Run the rule [ rule-id ] [ name rule-name ] { deny | permit } [ fragment | source { source-ipv6-address { prefix-length | source-wildcard } | source-ipv6-address/prefix-length | any } | time-range time-name | [ vpn-instance vpn-instance-name | vpn-instance-any ] ] * command to configure a rule for the basic ACL.

          When the rule command is run to configure rules for a named ACL, only the source address range specified by source and the time period specified by time-range are valid as the rules.

          When a filtering policy of a routing protocol is used to filter routes:
          • If the action specified in an ACL rule is permit, a route that matches the rule will be received or advertised by the system.

          • If the action specified in an ACL rule is deny, a route that matches the rule will not be received or advertised by the system.

          • If a route has not matched any ACL rules, the route will not be received or advertised by the system.

          • If an ACL does not contain any rules, all routes matching the route-policy that references the ACL will not be received or advertised by the system.

          • If the ACL referenced by the route-policy does not exist, all routes matching the route-policy will be received or advertised by the system.

          • In the configuration order, the system first matches a route with a rule that has a smaller number and then matches the route with a rule with a larger number. Routes can be filtered using a blacklist or a whitelist:

            Route filtering using a blacklist: Configure a rule with a smaller number and specify the action deny in this rule to filter out the unwanted routes. Then, configure another rule with a larger number in the same ACL and specify the action permit in this rule to receive or advertise the other routes.

            Route filtering using a whitelist: Configure a rule with a smaller number and specify the action permit in this rule to permit the routes to be received or advertised by the system. Then, configure another rule with a larger number in the same ACL and specify the action deny in this rule to filter out unwanted routes.

      • To use the AS_Path filter for route filtering, run peer { ipv4-address | ipv6-address | group-name } as-path-filter { as-path-filter-number | as-path-filter-name } import

      • To use an IP prefix list for route filtering, run peer { ipv4-address | ipv6-address | group-name } ip-prefix ipv6-prefix-name import

      • To use a route-policy for route filtering, run peer { ipv4-address | ipv6-address | group-name } route-policy route-policy-name import

      A peer group and its members can use different inbound policies when receiving routes. This means that each member in a peer group can select its own policy to filter received routes.

    5. Run commit

      The configuration is committed.

  • Limit the number of the routes received from a peer.
    1. Run system-view

      The system view is displayed.

    2. Run bgp as-number

      The BGP view is displayed.

    3. Run ipv6-family unicast

      The IPv6 unicast address family view is displayed.

    4. Run peer { group-name | ipv4-address | ipv6-address } route-limit limit [ percentage ] [ alert-only | idle-forever | idle-timeout minutes ]

      The number of routes that can be received from a peer or peer group is set.

      The command provides the limit on the number of received routes based on peers. You can configure specific parameters as required to control BGP after the number of the routes received from a peer exceeds the threshold.

      • alert-only: The peer relationship is kept. No more route is received after the number of received routes exceeds the threshold, and an alarm is generated and recorded in the log.

      • idle-forever: The peer relationship is interrupted. The router does not retry setting up a connection. An alarm is generated and recorded in the log. In this case, run the display bgp peer [ verbose ] command, and you can find that the status of the peer is Idle. To restore the BGP connection, run the reset bgp command.

      • idle-timeout: The peer relationship is interrupted. The router retries setting up a connection after the timer expires. An alarm is generated and recorded in the log. In this case, run the display bgp peer [ verbose ] command, and you can find that the status of the peer is Idle. To restore the BGP connection before the timer expires, run the reset bgp command.

      • If none of the preceding parameters is set, the peer relationship is disconnected. The router retries setting up a connection after 30 seconds. An alarm is generated and recorded in the log.

      NOTE:

      If the number of routes received by the local router exceeds the upper limit and the peer route-limit command is used for the first time, the local router and its peer reestablish the peer relationship, regardless of whether alert-only is set.

    5. Run commit

      The configuration is committed.

Configuring BGP4+ Soft Reset

BGP4+ soft reset allows the system to refresh a BGP4+ routing table dynamically without tearing down any BGP4+ connection if routing policies are changed.

Procedure

  • Enable the route-refresh capability.

    Perform the following steps on a BGP4+ device:

    1. Run system-view

      The system view is displayed.

    2. Run bgp as-number

      The BGP view is displayed.

    3. Run peer { ipv4-address | ipv6-address | group-name } capability-advertise route-refresh

      The route-refresh capability is enabled.

      If the route-refresh capability has been enabled on all BGP4+ NEs and a BGP4+ routing policy is changed, the local NE sends route-refresh messages to its peers. After receiving the messages, the peers resend their routing information to the local NE. Based on the received routing information, the local NE can refresh its BGP4+ routing table dynamically and apply the new routing policy, without tearing down any BGP4+ connections.

      By default, the route-refresh capability is enabled.

    4. Run commit

      The configuration is committed.

  • Configure a BGP4+ device to store all the routing updates received from its peers.

    Perform the following steps on a BGP4+ device:

    1. Run system-view

      The system view is displayed.

    2. Run bgp as-number

      The BGP view is displayed.

    3. Run ipv6-family unicast

      The IPv6 unicast address family view is displayed.

    4. Run peer { ipv4-address | ipv6-address | group-name } keep-all-routes

      The device is configured to store all routing updates received from its peers.

      After this command is used, all routing updates sent by a specified peer are stored, regardless of whether a filtering policy is used. When the local routing policy is changed, the routing updates can be used to regenerate BGP4+ routes.

    5. Run commit

      The configuration is committed.

  • Softly reset a BGP4+ connection.

    Perform the following steps on a BGP4+ device:

    1. Run refresh bgp ipv6 { all | ipv4-address | ipv6-address | group group-name | external | internal } { export | import }

      A BGP4+ connection is softly reset.

      A BGP4+ connection must be softly reset in the user view.

Verifying the Configuration of BGP4+ Routing Policies

After configuring BGP4+ routing policies, check routes that are advertised and received by BGP4+.

Prerequisites

The BGP4+ routing policies have been configured.

Procedure

  • Run the display bgp ipv6 network command to check the routes imported using the network command.
  • Run the display bgp ipv6 routing-table as-path-filter { as-path-filter-number | as-path-filter-name } command to check the routes that match a specified AS_Path filter.
  • Run the display bgp ipv6 routing-table community-filter { { community-filter-name | basic-community-filter-number } [ whole-match ] | advanced-community-filter-number } command to check the routes that match a specified BGP4+ community filter.
  • Run the display bgp ipv6 routing-table peer ipv6-address { advertised-routes | received-routes } [ statistics ] command to view the routes advertised to or received from a specified BGP4+ peer.

Example

# Run the display bgp network command to view the routes imported using the network command.

<HUAWEI> display bgp ipv6 network
 
BGP Local Router ID is 5.5.5.5
Local AS Number is 100(PublicV6)
Network          Mask            Route-policy

2001:db8:100::   64
2001:db8:200::   64
Translation
Download
Updated: 2019-01-14

Document ID: EDOC1100058916

Views: 37487

Downloads: 57

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