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 | [ 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.

          • 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 { number | 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 times ]

      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.

      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.

Copyright © Huawei Technologies Co., Ltd.
Copyright © Huawei Technologies Co., Ltd.
< Previous topic Next topic >