F5 Logo MyF5
Search
  1. MyF5 Home
  2. BIG-IP System: Service Function Chaining Deployment
  3. Service Function Chaining Tasks
Manual Chapter : Service Function Chaining Tasks

Applies To:

Show Versions Show Versions

BIG-IP LTM

  • 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0

BIG-IP PEM

  • 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
Manual Chapter

Service Function Chaining Tasks

Configuring a service classifier function (SCF)

To configure a node as a service classifier function (SCF), you must create a service chain on the node, and then either use a PEM module or write an iRule, to match policies to traffic flows, specify a service chain, and insert Network Service Header (NSH) encapsulation.
If you intend to use PEM to configure the policy for matching traffic flows, you must have an existing PEM policy on the system that you can modify for classification.

Create a service chain by using TMSH

The first step in configuring a BIG-IP node as a service classifier function (SCF) is to create a service chain on the node by using TMSH.
You must configure a separate service chain on each SCF node in the configuration. These service chains can have different names, but must have the same path ID.
To create a service chain you must specify the path ID, a next hop, and a service index.
  1. Use ssh to connect to BIG-IP.
  2. Type
    tmsh
     to ensure you are at the tmsh prompt.
  3. Type the following, substituting your values for the values listed here.
    create net sfc chain demo_chain path-id 789 hops add { hop1 { nexthop-endpoint-ip 7.100.63.5 service-index 255} }
  4. Press Enter.
To confirm that the service chain was created successfully, type
list net sfc
. The result should be similar to this:
net sfc chain demo_chain {
    hops {
        hop1 {
            nexthop-endpoint-ip 7.100.63.5
            service-index 255
        }
    }
    path-id 789
}
After creating a service chain on the SCF node, you can modify a PEM policy to associate the policy with the service chain.
If you do not have PEM licensed and provisioned on the SCF system, see the topic called
Associate a service chain with a traffic flow by modifying an iRule
.

Service chain TMSH details

Below are the descriptions of each service chain property that you can configure for a chain on a an SCF node.
Setting
Description
Name
A unique name for the chain. This option is required for the commands
create
 and
delete
.
Description
A user-defined description.
Hops
The list of next-hops.
Hops > Name
A unique name for the hop. This option is required for the TMSH commands
create
 and
delete
.
Hops > Hopkey
The type of hop, service-index or interface.
The default is service-index.
Hops > nexthop-endpoint-ip
If nexthop-endpoint-ip is specified, then it is assumed that the next hop is NSH-enabled. Only one of nexthop-endpoint-ip, nexthop-service, nexthop-terminate may be specified.
Hops > nexthop-service
The service function (SF) name of the next hop. Only one of nexthop-endpoint-ip, nexthop-service, nexthop-terminate may be specified.
Hops > nexthop-terminate
If nexthop-terminate is specified, then the chain is terminated and the NSH header is removed. Only one of nexthop-endpoint-ip, nexthop-service, nexthop-terminate may be specified.
Hops > service-index
The service-index is required when hopkey is service-index.
Hops > source-interface
The interface name, a tunnel or vlan, to match on ingress for this hop. The source-interface is required when hopkey is interface.
Hops > path-id
The service path identifier that uniquely identifies the service function path.

Associate the PEM policy with the service chain

You can update the PEM policy to include the service chain.
  1. Log in to the BIG-IP Configuration utility.
  2. On the Main tab, click
    Policy Enforcement
    Policies
    .
  3. Under
    Service Function Classifier
    , select the service chain name.
Alternately, you can use tmsh, for example:
modify pem policy demo_pem_policy rules modify { rule { precedence 1 sfc-action { path-name demo_chain } } }
To confirm the policy was updated, type
list pem policy
.
The result should be like this:
pem policy demo_pem_policy {
    rules {
        rule {
flow-info-filters {
         	    filter0 {
                    src-ip-addr 10.10.10.10/32
                }
            }
            precedence 1
            sfc-action {
                path-name demo_chain
            }
        }
    }
}

Associate a service chain with a traffic flow by modifying an iRule

If you do not have PEM provisioned, you can modify an existing traffic-matching iRule to associate the newly-created service chain with a particular traffic flow. To do this, you must edit the iRule to specify the iRule command
NSH::chain
.
  1. On the Main tab, click
    Local Traffic
    iRules
    .
  2. Create a new iRule.
  3. If the chain name was demo_chain, the iRule would be something like this:
     
    when CLIENT_ACCEPTED {
        log local0. "Hitting [virtual name]"
        NSH::chain serverside_egree /Common/demo_chain
}
  4. Click
    Update
    .

Configuring a service function (SF)

A
service function
 (SF) is responsible for specific treatment of received packets. An SF can act at various layers of a protocol stack (for example, at the network layer or other OSI layers).
An SF can be NSH-encapsulation-aware (that is, the SF receives and acts on information in the NSH encapsulation) or NSH-encapsulation-unaware (that is, data forwarded to the SF does not contain NSH encapsulation). This encapsulation state is often referred to as
NSH-aware
 and
NSH-unaware
, respectively.
An SF has some prerequisite objects that you must create, depending on the SF type:
NSH-encapsulation-unaware SF
Before creating this type of SF, you must create a pair of VLANs. One is for ingress traffic, and the other is for egress traffic. The BIG-IP system can be configured as an external SFC-unaware SF. For information on creating VLANs, see the product guide on AskF5 titled
BIG-IP TMOS: Routing Administration
.
NSH-encapsulation-aware SF
Before creating this type of SF, you must create a single VXLAN-GPE tunnel or a pair of VXLAN-GPE tunnels.
XLAN-GPE is the only tunnel type that the BIG-IP system supports to carry the NSH encapsulation.

Configuring a service function forwarder (SFF)

A
service function forwarder
 (SFF) is responsible for forwarding traffic to one or more connected service functions, according to information carried in the NSH encapsulation. The SFF also handles traffic coming back from an SF.
On an SFF node, you need to configure a service chain and all SF details.
You need to configure a separate service chain on each SFF node in a configuration. These service chains can have different names, but must have the same path ID.
The following shows TMSH output for a sample chain configuration when you run the command
list net sfc chain
.

net sfc chain mix3 {
    hops {
        myhop1 {
            nexthop-service sf1_nsh_v4
            service-index 100
        }
        myhop2 {
            nexthop-service sf2_non_nsh_v4
            service-index 99
        }
        myhop3 {
            hopkey interface
            nexthop-service virtual1_v4
            source-interface sf2_ip_in
        }
        myhop4 {
            nexthop-service sf_pool_non_nsh_v4
            service-index 97
        }
        myhop5 {
            hopkey interface
            nexthop-service virtual2_v4
            source-interface sf_pool_in
        }
        myhop6 {
            nexthop-terminate
            service-index 95
        }
    }
    path-id 789
    start-service-index 100
}

Service function TMSH details

Below are the descriptions of each SF property that you can configure on a node.
Setting
Description
Name
A unique name for the SF. This option is required for the TMSH commands
create
,
delete
, and
modify
.
Description
A user-defined description.
egress-interface
The egress interface.
ingress-interface
The ingress interface.
ip-address
The IP address of the SF. Only one of ip-address, pool-name, virtual-name may be specified.
nsh-aware
Indicates if the SF is capable of receiving and acting on network service header (NSH) packets.
pool-name
The name of the pool associated with the SF node. Only one of ip-address, pool-name, virtual-name may be specified. If pool-name is specified, both ingress and egress interface, VLAN name, need to be specified and of the same type. If nsh-aware is enabled, then ingress and egress VXLAN-GPE tunnel names can be the same or different.
virtual-name
Only one of ip-address, pool-name, virtual-name may be specified.
If virtual-name is specified, then no ingress or egress interface should be specified. nsh-aware cannot be specified with virtual-name defined.

Configuring a service function forwarder (SFF)

A
service function forwarder
 (SFF) is responsible for forwarding traffic to one or more connected service functions, according to information carried in the NSH encapsulation. The SFF also handles traffic coming back from an SF.
On an SFF node, you need to configure a service chain and all SF details.
You need to configure a separate service chain on each SFF node in a configuration. These service chains can have different names, but must have the same path ID.
The following shows TMSH output for a sample chain configuration when you run the command
list net sfc chain
.

net sfc chain mix3 {
    hops {
        myhop1 {
            nexthop-service sf1_nsh_v4
            service-index 100
        }
        myhop2 {
            nexthop-service sf2_non_nsh_v4
            service-index 99
        }
        myhop3 {
            hopkey interface
            nexthop-service virtual1_v4
            source-interface sf2_ip_in
        }
        myhop4 {
            nexthop-service sf_pool_non_nsh_v4
            service-index 97
        }
        myhop5 {
            hopkey interface
            nexthop-service virtual2_v4
            source-interface sf_pool_in
        }
        myhop6 {
            nexthop-terminate
            service-index 95
        }
    }
    path-id 789
    start-service-index 100
}
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information