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


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


Configuration Guide - SFC

CloudEngine 6800 and 5800 V200R002C50

This document describes the configurations of Service function chain (SFC).

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 an SFF

Configuring an SFF


An SFF forwards packets from a network to multiple SFs associated with the SF based on NSH encapsulation information. After parsing and processing packets, the SFs return them to the associated SFF. When the last SF on the SFC returns the processed packet to the SFF, the SFF removes NSH encapsulation information in the packet and sends it back to the network.

In most cases, gateways are used as SFFs. On a centralized VXLAN network, the SC and SFF are deployed both on the centralized VXLAN gateway. On a distributed VXLAN network, VXLAN gateways connected to SFs are used as SFFs.

  • When an SFF connects to an NSH-unaware SC, you need to configure a traffic classifier and direct traffic to the SFP on the SFF. In this case, the NSH-unaware SC and the first SFF are on the same device.

  • When an SFF connects to NSH-unaware SFs, the SFC proxy is required between the SFF and NSH-unaware SFs associated with the SFF. The SFC proxy receives packets from the SFF on behalf of SFs. After deleting NSH encapsulation information, the SFC proxy sends packets to NSH-unaware SFs. When receiving packets from NSH-unaware SFs, the SFC proxy adds NSH encapsulation information to the packets by decreasing the SI by 1 and sends them to the SFF. In practice, SFFs usually provide the SFC proxy function.


  1. Run system-view

    The system view is displayed.

  2. Run service-chain enable

    The SFC function is enabled.

    By default, the SFC function is disabled.

  3. Run commit

    The configuration is committed.

  4. Run service-chain service-path path-id

    An SFP is created and the service chain view is displayed.

  5. (Optional) Run description description-content

    Description is configured for the SFP.

  6. Run service-index si-id next-hop { sff | sf [ nsh-proxy ] } { vtep-ip vtep-ip-address vni vni-id | remote-ip remote-ip-address [ vpn-instance vpn-instance-name ] }

    The type and forwarding information are configured for a next hop on the SFP.

    You can run this command for multiple times to configure a complete SFP.

    When the next hop is an NSH-unaware SF, configure the sf nsh-proxy parameter.

  7. (Optional) Run service-index si-id path-terminal [ vpn-instance vpn-instance-name ]

    The SFF is configured as the last hop of the SFP, and the VPN domain after NSH termination is defined.

    You only need to perform this step on the SFF connected to the last SF of the SFP.

  8. Configure MQC in the following scenarios:

    • Configure a traffic classifier and direct traffic to the SFP on the first SFF associated with an NSH-unaware SC.

    • Classify packets received from SFs and decrease the SI by 1 on the SFF associated with NSH-unaware SFs.

    For details, see Step 8 through Step 11 in Configuring an SC on the SFF.

  9. Run commit

    The configuration is committed.

Updated: 2019-03-21

Document ID: EDOC1000166642

Views: 8721

Downloads: 184

Average rating:
This Document Applies to these Products

Related Version

Related Documents

Previous Next