Manual Chapter :
Service Function Chaining Tasks
Applies To:
Show VersionsBIG-IP LTM
- 17.1.2, 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.2, 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
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.
- Use ssh to connect to BIG-IP.
- Typetmshto ensure you are at the tmsh prompt.
- 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} }
- 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.
- Log in to the BIG-IP Configuration utility.
- On the Main tab, click.
- UnderService 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
.- On the Main tab, click.
- Create a new iRule.
- 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 }
- ClickUpdate.
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 titledBIG-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 }