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 8800, 7800, 6800, and 5800 V200R005C10

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).
Configuring PBR

Configuring PBR

Context

PBR can redirect the Layer 3 packets received on an interface to a specified next hop address.

By configuring the redirection action, the device redirects packets matching traffic classification rules to the next hop address.

A traffic policy containing the redirection action can only be used in the inbound direction.

Pre-configuration Tasks

Before configuring PBR, complete the following tasks:
  • Configure IP addresses and routing protocols for interfaces to ensure routing connectivity.

  • Configure an ACL if the ACL needs to be used to classify traffic.

Procedure

  1. Configure a traffic classifier.

    1. Run system-view

      The system view is displayed.

    2. Run traffic classifier classifier-name [ type { and | or } ]

      A traffic classifier is created and the traffic classifier view is displayed, or the view of an existing traffic classifier is displayed.

      and is the logical operator between the rules in a traffic classifier, which means that:
      • If a traffic classifier contains ACL rules, packets match the traffic classifier only if they match one ACL rule and all the non-ACL rules.

      • If a traffic classifier does not contain any ACL rules, packets match the traffic classifier only if they match all the rules in the classifier.

      The logical operator or means that packets match a traffic classifier if they match one or more rules in the classifier.

      By default, the relationship between rules in a traffic classifier is or.

    3. Run if-match

      Matching rules are defined for the traffic classifier.

      For details about matching rules in a traffic classifier, see "Configuring a Traffic Classifier" in "MQC Configuration" of the CloudEngine 8800, 7800, 6800, and 5800 Series SwitchesConfiguration Guide - QoS Configuration Guide.

    4. Run commit

      The configuration is committed.

    5. Run quit

      Exit from the traffic classifier view.

  2. Configure a traffic behavior.

    NOTE:
    • After the TRILL gateway function is configured, when the policy is applied in VLANIF interface of a CE VLAN, the device does not support traffic action of PBR to specify the low-precedence.

    • The CE5810EI, CE5880EI, and CE6880EI do not support traffic action of PBR to specify the low-precedence.

    • Only the CE6855HI, CE6856HI, CE6857EI, CE6865EI, and CE7855EI can import VXLAN service traffic through PBR.
    1. Run traffic behavior behavior-name

      A traffic behavior is created and the traffic behavior view is displayed, or the view of an existing traffic behavior is displayed.

    2. Run the following commands as required.

      • Run redirect [ vpn-instance vpn-instance-name ] nexthop ip-address &<1-16> [ fail-action discard ] [ low-precedence [ source vpn-instance vpn-instance-name ] ]

        Or run redirect ipv6 [ vpn-instance vpn-instance-name ] nexthop ipv6-address &<1-16> [ fail-action discard ] [ low-precedence [ source vpn-instance vpn-instance-name ] ]

        The device is configured to redirect packets matching traffic classification rules to a next hop IP address in a traffic behavior. This action only takes effect in Layer 3 forwarding.

        • If multiple next hop IP addresses are configured, the device redirects packets in active/standby mode. The device determines the primary path and backup paths according to the sequence in which next hop IP addresses have been configured. The next hop IP address that is configured first has the highest priority and this next hop is used as the primary path. Other next hops are used as backup paths. When the primary path is Down, the backup path with the highest priority is used as the primary path. When the high-priority link is recovered, traffic is switched to the high-priority link; when all redirected links are unavailable, packets are forwarded according to the destination address.

        • By default, if all the configured next hops are unreachable, packets are forwarded according to the destination address. If the fail-action discard parameter is configured, packets are discarded if all the configured next hops are unreachable.

        • After you specify the low-precedence parameter, the device forwards packets matching PBR to the next hop/outbound interface of the specific route in its routing table. When the specific route becomes invalid, the device forwards packets to the next hop/outbound interface specified by PBR. When both the next hop of the specific route and next hop specified by PBR become invalid, and the routing table has default routes, the device continues forwarding packets according to the matching default route.

      • Run redirect load-balance [ vpn-instance vpn-instance-name ] nexthop { ip-address [ track nqa admin-name test-name [ reaction probe-failtimes fail-times ] ] } &<1-16> [ fail-action discard ] [ low-precedence [ source vpn-instance vpn-instance-name ] ]

        Or run redirect ipv6 load-balance [ vpn-instance vpn-instance-name ] nexthop { ipv6-address [ track nqa admin-name test-name [ reaction probe-failtimes fail-times ] ] } &<1-16> [ fail-action discard ] [ low-precedence [ source vpn-instance vpn-instance-name ] ]

        The device is configured to redirect packets matching traffic classification rules to multiple next hop IP addresses. This action only takes effect in Layer 3 forwarding.

        • If the outbound interface corresponding to a next hop IP address becomes Down or a route changes, the device switches traffic to the outbound interface corresponding to an available next hop.

        • If the device has no ARP entry matching the specified next hop IP address, the redirect load-balance command can be used but redirection does not take effect. The device still forwards packets to the original destination until the device has the corresponding ARP entry.

        • If an NQA test instance is configured to detect the link for the redirection next hop IP address and the number of NQA link detection failures is larger than or equal to the configured maximum value, the current next hop will be cancelled. If multiple next hops work in load balancing mode, this next hop will not participate in load balancing and the remaining reachable next hops perform load balancing. If multiple next hops work in active/standby mode, traffic will be automatically switched to the next reachable next hop.

        • By default, if all the configured next hops are unreachable, packets are forwarded according to the destination address. If the fail-action discard parameter is configured, packets are discarded if all the configured next hops are unreachable.

        • After you specify the low-precedence parameter, the device forwards packets matching PBR to the next hop/outbound interface of the specific route in its routing table. When the specific route becomes invalid, the device forwards packets to the next hop/outbound interface specified by PBR. When both the next hop of the specific route and next hop specified by PBR become invalid, and the routing table has default routes, the device continues forwarding packets according to the matching default route.

      • Run redirect remote [ vpn-instance vpn-instance-name ] ip-address [ track nqa admin-name test-name [ reaction probe-failtimes fail-times ] ] [ exact ] [ low-precedence [ source vpn-instance vpn-instance-name ] ]

        The action that redirects packets to the remote next hop is created in the traffic behavior.

        • To redirect packets to the IP address of the indirectly-connected next hop, run the redirect remote command. When ip-address specifies the IP address of the indirectly-connected next hop for redirection, the device examines the IP routing table. If the IP routing table contains a route to the IP address, the device forwards the packets according to the route.

        • If an NQA test instance is specified to detect the link for the redirection next hop IP address and the number of NQA link detection failures is larger than or equal to the configured maximum value, the current next hop will be cancelled.

        • When exact is specified, the device redirects packets only when the IP routing table contains the 32-bit host route matching ip-address. For example, when redirect remote 10.1.1.1 exact is configured, the IP routing table of the device must contain a route to 10.1.1.1/32; otherwise, the device cannot redirect packets.

        • After you specify the low-precedence parameter, the device forwards packets matching PBR to the next hop/outbound interface of the specific route in its routing table. When the specific route becomes invalid, the device forwards packets to the next hop/outbound interface specified by PBR. When both the next hop of the specific route and next hop specified by PBR become invalid, and the routing table has default routes, the device continues forwarding packets according to the matching default route.

      NOTE:

      After the TRILL gateway function is configured, when the policy is applied in VLANIF interface of a CE VLAN, the device does not support traffic action of PBR to specify the low-precedence.

    3. Run commit

      The configuration is committed.

    4. Run quit

      Exit from the traffic behavior view.

    5. Run quit

      Exit from the system view.

  3. Configure a traffic policy.

    1. Run system-view

      The system view is displayed.

    2. Run traffic policy policy-name

      A traffic policy is created and the traffic policy view is displayed, or the view of an existing traffic policy is displayed.

    3. Run classifier classifier-name behavior behavior-name [ precedence precedence-value ]

      A traffic behavior is bound to a traffic classifier in the traffic policy.

    4. Run commit

      The configuration is committed.

    5. Run quit

      Exit from the traffic policy view.

    6. Run quit

      Exit from the system view.

  4. Apply the traffic policy.

    NOTE:
    • For details about the configuration guidelines of applying traffic policies in different views on the CE switches excluding CE6870EI and CE6875EI, see Licensing Requirements and Limitations for MQC (CE Switches Excluding CE6870EI and CE6875EI).

    • For details about the configuration guidelines of applying traffic policies in different views on the CE6870EI and CE6875EI, see Licensing Requirements and Limitations for MQC (CE6870EI and CE6875EI).

    • For switches excluding the CE5880EI and CE6880EI, run the display traffic-policy pre-state { global [ slot slot-id ] | interface { interface-type interface-number } | vlan vlan-id | bridge-domain bd-id } policy-name { inbound | outbound } command before committing the configuration to check the information about resources occupied by the traffic policy to be applied and determine whether the traffic policy can be successfully applied based on the information.

    • If a traffic policy needs to be applied to multiple VLANs and interfaces or multiple traffic classifiers for matching packets from different source IP addresses need to be bound to the same traffic policy, you are advised to add these VLANs, source IP addresses, and interfaces to the same QoS group and apply the traffic policy to the QoS group.
    • Applying a traffic policy to an interface
      1. Run system-view

        The system view is displayed.

      2. Run interface interface-type interface-number

        The interface view is displayed.

        NOTE:

        PBR for VXLAN packets on a VXLAN Layer 3 gateway takes effect only on BDIF interfaces.

      3. Run traffic-policy policy-name inbound

        A traffic policy is applied to the interface.

      4. Run commit

        The configuration is committed.

    • Applying a traffic policy to a VLAN
      1. Run system-view

        The system view is displayed.

      2. Run vlan vlan-id

        The VLAN view is displayed.

      3. Run traffic-policy policy-name inbound

        A traffic policy is applied to the VLAN.

        After a traffic policy is applied, the system performs traffic policing for the packets that belong to a VLAN and match traffic classification rules in the inbound direction.

      4. Run commit

        The configuration is committed.

    • Applying a traffic policy to the system
      1. Run system-view

        The system view is displayed.

      2. Run traffic-policy policy-name global [ slot slot-id ] inbound

        A traffic policy is applied to the system.

      3. Run commit

        The configuration is committed.

    • Applying a traffic policy in a VPN instance
      1. Run system-view

        The system view is displayed.

      2. (Optional) Run qos port-group group-id

        A QoS interface group is created and its view is displayed.

      3. (Optional) Run group-member { interface-type interface-number1 [ to interface-type interface-number2 ] }

        Interfaces are added to the QoS interface group.

      4. (Optional) Run quit

        Exit from the QoS interface group view.

      5. Run ip vpn-instance vpn-instance-name

        A VPN instance is created and its view is displayed.

      6. Run traffic-policy policy-name inbound [ exclude qos port-group group-id ]

        The traffic policy is applied to the VPN instance.

      7. Run commit

        The configuration is committed.

    • Applying a traffic policy to a QoS group
      1. Run system-view

        The system view is displayed.

      2. Run qos group group-name

        The QoS group view is displayed.

      3. Run the following commands as required.
        • Run the group-member interface { interface-type interface-number1 [ to interface-type interface-number2 ] } &<1-8> command to add interfaces to the QoS group.

        • Run the group-member vlan { vlan-id1 [ to vlan-id2 ] } &<1-8> command to add VLANs to the QoS group.

        • (Models excluding the CE6870EI) Run the group-member ip source ip-address { mask | mask-length } command to add source IP addresses to the QoS group.

      4. Run traffic-policy policy-name inbound

        A traffic policy is applied to a QoS group.

      5. Run commit

        The configuration is committed.

    • Applying a traffic policy to a BD
      1. Run system-view

        The system view is displayed.

      2. Run bridge-domain bd-id

        The BD view is displayed.

      3. Run traffic-policy policy-name inbound

        A traffic policy is applied to the BD.

      4. Run commit

        The configuration is committed.

Verifying the Configuration

  • Run the display traffic classifier [ classifier-name ] command to check the traffic classifier configuration.
  • Run the display traffic behavior [ behavior-name ] command to check the traffic behavior configuration on the device.
  • Run the display traffic policy [ policy-name [ classifier classifier-name ] ] command to check the traffic policy configuration.

  • Run the display traffic-policy applied-record [ policy-name ] [ global [ slot slot-id ] | interface interface-type interface-number | vlan vlan-id | vpn-instance vpn-instance-name | qos group group-id | bridge-domain bd-id ] [ inbound | outbound ] command to check the application record of a specified traffic policy.

  • Run the display system tcam fail-record [ slot slot-id ] command to display TCAM delivery failures.
  • Run the display system tcam service brief [ slot slot-id ] command to display the group index and rule count occupied by different services.
  • Run the display system tcam service { cpcar slot slot-id | service-name slot slot-id [ chip chip-id ] } command to display IDs of entries that deliver services on the specified chip or in the specified slot.
  • Run one of the following commands to display data of a traffic policy that has been applied:
    • display system tcam service traffic-policy { global | vlan vlan-id | interface interface-type interface-number | vpn-instance vpn-instance-name | qos group group-id | bridge-domain bd-id } policy-name { inbound | outbound } [ slot slot-id [ chip chip-id ] ]
      NOTE:
      • The CE6810LI does not support the vpn-instance vpn-instance-name parameter.
      • The CE5810EI, CE5850EI, CE5850HI, CE5855EI, CE6810LI, and CE6810EI do not support the bridge-domain bd-id parameter.
    • display system tcam service traffic-policy slot slot-id policy-name { inbound | outbound } [ chip chip-id ]
  • (For CE6870EI and CE6875EI) Run the display system tcam match-rules slot slot-id [ [ ingress | egress | group group-id ] | [ chip chip-id ] ] * command to display matched entries.
  • (For CE5880EI and CE6880EI switches) Run the display system tcam match-rules slot slot-id chip chip-id index index-id command to display matched entries.
  • (Models excluding the CE5880EI, CE6870EI, CE6875EI, and CE6880EI) Run the display system tcam match-rules slot slot-id [ [ ingress | egress | group group-id ] | [ delay-time time-value ] ] * command to display matched entries.
Translation
Download
Updated: 2019-04-20

Document ID: EDOC1100074760

Views: 46535

Downloads: 58

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