Applies To:

Show Versions Show Versions

Manual Chapter: Other Application-Layer Profiles
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

BIG-IP® Local Traffic ManagerTM offers several features that you can use to intelligently control your application layer traffic. These features are available through various configuration profiles.
A profile is a group of settings, with values, that correspond to a specific type of traffic, such as FTP traffic. A profile defines the way that you want the BIG-IP system to manage that traffic type.
Note: An additional profile type, SMTP, is available when BIG-IP® Protocol Security ModuleTM is licensed on the system.
In addition to these application layer profiles, Local Traffic Manager includes other features to help you manage your application traffic, such as health monitors for checking the health of an FTP service, and iRules® for querying or manipulating header or content data.
To configure and manage various services profiles, log in to the BIG-IP Configuration utility, and on the Main tab, expand Local Traffic, click HTTP, and from the Services menu, choose a profile type.
Local Traffic Manager includes a profile type that you can use to manage File Transfer Protocol (FTP) traffic. You can tailor FTP profile settings to your specific needs. For those settings that have default values, you can retain those default settings or modify them. You can modify any settings either when you create the profile, or at any time after you have created it.
Specifies the user-supplied name of the profile. Specifying a name for your profile is required.
Ensures compatibility between IP version 4 and IP version 6 clients and servers when using the FTP protocol.
Specifies, when checked (enabled), that the system inspects FTP traffic for security vulnerabilities, by using a security profile in BIG-IP® Protocol Security Module. This option is available only when you are licensed for the module.
Because IP version 6 addresses are not limited to 32 bits (unlike IP version 4 addresses), compatibility issues can arise when using FTP in mixed IP-version configurations.
By default, Local Traffic Manager automatically translates FTP commands when a client-server configuration contains both IP version 4 (IPv4) and IP version 6 (IPv6) systems. For example, if a client system running IPv4 sends the FTP PASV command to a server running IPv6, Local Traffic Manager automatically translates the PASV command to the equivalent FTP command for IPv6 systems, EPSV.
The Data Port setting allows the FTP service to run on an alternate port. The default data port is 20.
When the BIG-IP system includes a license for the BIG-IP Application Security ManagerTM, you can enable a security scan for FTP traffic.
You can create a custom DNS profile to enable various features such as converting IPv6-formatted addresses to IPv4 format, enabling DNS ExpressTM, and enabling DNSSEC.
Local Traffic Manager includes a services profile that you can use to manage Session Initiation Protocol (SIP) traffic. Session Initiation Protocol is an application-layer protocol that manages sessions consisting of multiple participants, thus enabling real-time messaging, voice, data, and video. A session can be a simple two-way telephone call or Instant Message dialogue, or a complex, collaborative, multi-media conference call that includes voice, data, and video.
SIP sessions, which are application level sessions, run through one of three Layer 4 protocols: SCTP, TCP, or UDP. The SIP profile configures how the system handles SIP sessions. The specified Layer 4 protocol profile configures the virtual server to open the required port to allow data to flow through the BIG-IP system. When you assign a SIP profile to a virtual server, you can also assign either an SCTP, TCP, or UDP profile to the server. If you do not assign one of these protocol profiles to the server, Local Traffic Manager automatically assigns one for you.
The SIP profile automatically configures the BIG-IP system to handle persistence for SIP sessions using Call-ID. The Call-ID is a globally unique identifier that groups together a series of messages, which are sent between communicating applications. You can customize how the system handles persistence for SIP sessions.
Table 7.2, lists the configurable settings in a SIP profile, along with a short description of each setting and the default value. Following this table are more detailed descriptions of the settings.
Specifies the maximum SIP message size that the BIG-IP system accepts. The system drops the connection if the SIP message is larger than this value.
Specifies that you want the BIG-IP system to snoop SIP dialog information and forward it to a known SIP dialog. Enabling this setting causes the Community setting to appear on the screen.
Disabled
(Unchecked)
Specifies a string to indicate the proxy functional group to which this profile belongs. This setting appears on the screen only when you have enabled the Dialog Aware setting.
Enables or disables the closing of a connection when a BYE transaction finishes. A BYE transaction is a message that an application sends to another application when it is ready to close the connection between the two. When the BIG-IP system encounters a BYE transaction, if the Terminate on BYE setting is enabled, then the system ends the connection. Use this parameter with UDP connections only, not with TCP connections.
Enabled
(Checked)
Enables or disables the insertion of a Via header into a SIP request. A Via header indicates where the message originated. The response message uses this routing information.
When the Insert Via Header setting is enabled, specifies a string that you want the system to insert as the value for the top Via header in a SIP request. This value specifies the SIP protocol, as well as a virtual address and port.
Enables or disables the insertion of a Secure Via header into a SIP request. A Secure Via Header indicates where the message originated. Use this parameter with SSL/TLS to secure the system. The response message uses this routing information.
Disabled
(Unchecked)
Enables or disables the insertion of a Record-Route SIP header, which indicates the next hop for the following SIP request messages.
Disabled
(Unchecked)
Local Traffic Manager accepts incoming SIP messages that are 65535 bytes or smaller. If a SIP message exceeds this value, the system drops the connection.
Local Traffic Manager can snoop SIP dialog information and automatically forward SIP messages to the known SIP dialog. To forward these messages, you can specify a SIP proxy functional group.
You can specify the name of a proxy functional group. You use this setting in the case where you need multiple virtual servers, each referencing a SIP-type profile, and you want more than one of those profiles to belong to the same proxy functional group.
Local Traffic Manager terminates a SIP connection when either the application that initiated the session (client) or the application that answered the initiated session (server) issues a BYE transaction. This is appropriate when a SIP session is running on UDP. However, if a SIP session is running on a SCTP or TCP connection, you can prevent the system from terminating the SIP connection.
An optional feature in a SIP profile is header insertion. You can specify whether Local Traffic Manager inserts Via, Secure Via, and Record-Route headers into SIP requests. When you assign the configured SIP profile to a virtual server, Local Traffic Manager then inserts the header specified in the profile into any SIP request that Local Traffic Manager sends to a pool or pool member.
You can configure Local Traffic Manager to insert a Via header into SIP requests to indicate where a SIP message originated. The SIP responses use this routing information to locate the session initiator.
When you enable the Insert Via Header setting, you then specify a User Via value. The User Via value is a string that the system inserts as the value of the top Via header value in a SIP request. The string specifies the SIP protocol, as well as a virtual address and port. An example of a User Via string is SIP/2.0/UDP 10.10.10.10:5060.
When you are using SSL/TLS (over TCP) to create a secure channel with the server node, you can configure Local Traffic Manager to insert a Secure Via header into a SIP request. The Secure Via Header setting indicates where the SIP message originated.
You can also configure Local Traffic Manager to insert a Record-Route header into SIP requests. The Insert Record-Route Header setting specifies the next hop for the SIP requests that follow.
Local Traffic Manager includes a type of persistence profile called a SIP persistence profile. You can customize how Local Traffic Manager handles persistence for SIP sessions by configuring both a SIP persistence profile and a SIP profile.
Local Traffic Manager includes a profile type that you can use to manage Real Time Streaming Protocol (RTSP) traffic. Real Time Streaming Protocol (RTSP) is a protocol used for streaming-media presentations. Using RTSP, a client system can control a remote streaming-media server and allow time-based access to files on a server.
The setup of streaming media over UDP. In this case, the control connection opens the required ports to allow data to flow through the BIG-IP system.
A common configuration for the RTSP profile is one that includes RTSP clients and media servers, as well as RTSP proxies to manage accounting and authentication tasks. In this proxied configuration, you most likely want the streaming media from the servers to pass directly to the client, bypassing the RTSP proxy servers.
To implement this configuration, you configure Local Traffic Manager by creating two virtual servers, one for processing traffic to and from the external network, and one for processing traffic to and from the internal network. For each virtual server, you assign a separate RTSP profile.
The RTSP profile on the external virtual server passes client IP address information to the RTSP profile on the internal virtual server.
The RTSP profile on the internal virtual server extracts the client IP address information from the request, processes the media servers response, and opens the specified ports on the BIG-IP system. Opening these ports allows the streaming media to bypass the RTSP proxy servers as the data travels from the server to the client.
The client IP address information is stored in the Proxy Header setting that you specify in the RTSP profile.
Table 7.4 lists the configurable settings in an RTSP profile, along with a short description of each setting and the default values.
Specifies the number of seconds that a UDP connection is idle before the connection is eligible for deletion.
Specifies the largest RTSP request or response header, in bytes, that the BIG-IP system allows before terminating the connection.
Specifies the maximum amount of data, in bytes, that the BIG-IP system buffers, before considering the connection to be unusable and subsequently terminating the connection.
If you are using unicast streams and you enable this setting, the client is able to specify the destination address and port for the streamed data. For security reasons however, the destination address used is the source of the request.
If you are using multicast streams and you enable this setting, the client has permission to supply a different destination for the streamed data.
When this setting is enabled and a disconnected control connection has been resumed, the BIG-IP system persists the resumed control connection to the correct server. Typical clients do not support this behavior.
When this setting is enabled, the system automatically persists Real Networks-tunneled RTSP data over HTTP, which is over the RTSP port. The default value is Enabled. When you disable this setting, a user can override the default behavior with an iRule.
When checked (enabled), specifies that the system examines the origin of the message to determine whether the message came from the client or the server.
Specifies whether the RTSP profile is associated with an RTSP proxy configuration. Possible values are: None, External, and Internal.
Specifies a name for the header that the system inserts into a SETUP request. The name must begin with the string X-. The value of this header typically consists of information about the client IP address and is read by another RTSP profile. Note that the system removes this header from the request prior to sending the request to the server for processing.
Specifies the port number that a Microsoft® Media Services server uses. Normally, Microsoft Media Services uses a fixed Realtime Transport Protocol (RTP) port number. With this setting, you can specify a port number instead of using the fixed RTP port number.
Specifies an RTCP port companion of the RTP Port value. Normally, Microsoft Media Services uses a fixed Real-Time Control Protocol (RTCP) port number. With this setting, you can specify a port number instead of using the fixed RTCP port number.
Local Traffic Manager includes a profile type that you can use to manage Diameter traffic. The Diameter protocol is an enhanced version of the Remote Authentication Dial-In User Service (RADIUS) protocol.
When you configure a Diameter type of profile, the BIG-IP system can send client-initiated Diameter messages to load balancing servers. The BIG-IP system can also ensure that those messages persist on the servers.
Table 7.5 lists and describes the settings of a Diameter type of profile.
Specifies the profile that you want to use as the parent profile. Your new profile inherits all non-custom settings and values from the parent profile specified.
Allows you to select an attribute name or specify a code for an attribute-value pair (AVP). The system uses this value as the persistent key for making a load balancing decision. The default value is Session-Id. If this value is set to None, the session persistence feature is disabled.
Possible values for the Persist Attribute setting are:
If you select Specify, you can type an AVP code, such as 280. In this case, the allowed range is 1 through 4294967295.
Allows you to select or enter a code for an attribute-value pair (AVP). If the value of the Persist Attribute setting is embedded in the grouped AVP, you must specify the Grouped/Parent Attribute value here; otherwise, persistence is disabled.
Configuring the Grouped/Parent Attribute setting means that the parent AVP is a grouped AVP, and its AVP value contains the Persist Attribute AVP. Only one level of embedding as the value of the parent AVP is allowed.
The possible values for the Grouped/Parent Attribute setting are:
If you select Specify, you can type an AVP code, such as 280. In this case, the allowed range is 1 through 4294967295. For example, you can enter code 280 for the Persist Attribute value, combined with 284 for the Grouped/Parent Attribute value.
Specifies whether the system uses the existing host IP address or overwrites the host IP address value in the request with the pool members IP address.
Specifies whether the system uses the existing originating server or overwrites the originating server value in the request with the one specified here. The default is None.
None: Indicates that the system uses the original originating server in the request.
Specify: Presents a box where you can enter a new originating server for the system to use to replace the originating server attribute in the request. A typical value for this attribute is the fully qualified domain name (FQDN) of the server representing the originating server.
Specifies whether the system uses the existing originating realm or overwrites the originating host value in the request with the one specified here. The default is None.
None: Indicates that the system uses the original originating realm in the request.
Specify: Presents a box where you can enter a new originating realm for the system to use to replace the originating realm attribute in the request. A sample value for this attribute is f5.com.
Specifies whether the system uses the existing destination host or overwrites the destination host value in the request with the pool members IP address. The default is enabled. A typical value for this attribute is the hosts fully-qualified domain name (FQDN).
Specifies whether the system uses the existing destination host or overwrites the destination realm value in the request with the pool members IP address. The default is None.
None: Indicates that the system uses the original destination realm in the request.
Specify: Presents a box where you can enter a new destination realm for the system to use to replace the originating realm attribute in the request. A sample value for this attribute is f5.com.
Indicates the number of seconds before the watchdog times out. The default is 0, meaning that the watchdog does not time out.
Indicates the maximum number of failures the watchdog can experience before closing the connection. The default is 10.
Checking this allows the MBLB proxy to establish a connection to all server pool members without actually having traffic. Normally Diameter servers do not process any request until all server handshakes are done, but for better performance, checking this keeps the server connections primed and ready.
Unchecked (Disabled)
The BIG-IP system includes a profile type that you can use to load balance Remote Authentication Dial-In User Service (RADIUS) traffic.
When you configure a RADIUS type of profile, the BIG-IP system can send client-initiated RADIUS messages to load balancing servers. The BIG-IP system can also ensure that those messages are persisted on the servers.
Specifies the profile that you want to use as the parent profile. Your new profile inherits all non-custom settings and values from the parent profile specified.
Note: The BIG-IP system also includes another type of RADIUS profile that you can use to configure remote authentication of application traffic.
You can use the BIG-IP system to perform XML content-based routing whereby the system routes requests to an appropriate pool, pool member, or virtual server based on specific content in an XML document. For example, if your company transfers information in XML format, you could use this feature to examine the XML content with the intent to route the information to the appropriate department.
You can configure content-based routing by creating an XML profile and associating it with a virtual server. In the XML profile, define the matching content to look for in the XML document. Next, specify how to route the traffic to a pool by writing simple iRules. When the system discovers a match, it triggers an iRule event, and then you can configure the system to route traffic to a virtual server, a pool, or a node.
The following example shows a simple XML document that the system could use to perform content-based routing. It includes an element called FinanceObject used in this implementation.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)