Manual Chapter : Frequently-asked Questions

Applies To:

Show Versions Show Versions


  • 17.1.0, 17.0.0, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.10, 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, 14.0.1, 14.0.0
Manual Chapter

Frequently-asked Questions

These answers to frequently-asked questions might help you when configuring the BIG-IP system to function as a lightweight SFC controller.
Which BIG-IP platforms support the lightweight SFC controller feature?
The lightweight SFC controller feature is available on any BIG-IP device (physical or virtual) running BIG-IP version 14.1 or later.
What kinds of interfaces do I need for communication between a service function forwarder (SFF) and an associated service function (SF)?
In a service chain configuration, any service function (SF) that is NSH-aware requires a minimum of single prerequisite VXLAN-GPE tunnel for ingress and egress communication with its associated SFF. A non-NSH-aware SF requires two prerequisite VLANs, one for ingress and one for egress communication.
Do I need to create a VXLAN-GPE tunnel and a virtual server for communication between SFFs in the service chain?
No. When you use the SFC controller to create a service chain configuration, the BIG-IP system automatically creates the tunnel that the SFFs need to forward traffic to one another. As an option, you can tell the system to create a default Performance (Layer4) virtual server as well.
What does a REST trust group contain?
A REST trust group contains any BIG-IP devices that you designate as service nodes from within the SFC controller. It’s important to note that if the BIG-IP device that’s designated as the SFC controller is a member of a high-availability Sync-Failover device group, then you must add all members of that device group to the REST trust group as well.
Where do service functions “live”?
Any SF of type IP or Pool must reside on a device that’s separate from its associated SFF. Any SF of type Virtual must reside on its associated SFF.
Can SFs reside on non-BIG-IP devices?
Yes. You can configure SFs on any appropriate network device, not just BIG-IP devices.
What if the BIG-IP SFC controller is a member of a Sync-Failover device group for high availability?
If the BIG-IP device that’s configured as an SFC controller is a member of a high-availability Sync-Failover device group, only the configuration data that defines the SFC controller itself is synced to all devices in the device group.
What about data synchronization from the SFC controller to other service nodes in the chain?
Configuration data for classifiers and SFFs is propagated from the SFC controller to the relevant service node only, at the time that the classifier or SFF is created. Unlike classifier and SFF data, any configuration data for service functions (SFs), such as an SF-to-SFF association, is not propagated to the SF, but is propagated only to the associated SFF.
Can I configure a single service node in a service chain configuration to serve different functions?
Yes. A single BIG-IP device can function as a classifier, an SFC controller, and an SFF simultaneously. However, the configuration described in this document uses a separate BIG-IP device for the SFC controller function.
Can the SFC controller configure network devices that will function as SFs?
No. SFs in the service chain must already be configured with prerequisite network objects, such as tunnels or VLANs, before you use the SFC controller to add the device as an SF to the service chain. For more information, see the list of prerequisite tasks in this document.
Can I modify a service chain object after I’ve created it?
No. In general, you cannot modify a service chain object after it’s created, although you can change the PEM classifier policies associated with it.
Can a classifier include more than one PEM classifier policy?
Yes, a classifier in a service chain can include multiple policies, each with a set of rules.