Manual Chapter : Operation Modes

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, 14.0.1, 14.0.0
Manual Chapter

Operation Modes

Operation Modes

Load Balancing

  • Route SIP control messages, without modifying SIP headers.
  • The following headers can be configured to be automatically modified.
    • VIA Header inserted
    • Record Router Header inserted
    • Decrementing max forwards
  • Any header attribute can be modified via iRule.
  • Natively route messages based on:
    • From URI
    • To URI
    • Request URI
    • Originating Virtual Server
  • Route messages via iRule on any attribute of the message.
  • Response routing natively using data added to the inserted VIA Header.
  • Response routing available via iRule:
    • Add private header to request
    • Insertion of VIA Header to request via iRule
    • Route to upstream device using received VIA Header
    • Remember data from request processing
  • Bi-directional persistence support.
    • Persistence key selection via configuration or custom key via iRule
  • Connection Re-Use Support
  • High Availability (HA)
    • Connection mirroring
    • Persistence table replication

Configuration Objects

Virtual Server
A virtual server is a traffic-management object on the BIG-IP® system that is represented by an IP address and a service. Clients on an external network can send application traffic to a virtual server, which then directs the traffic according to configuration instructions.
All virtuals sharing the same router profile will share the same router instance. This means that they will be able to use connections created by traffic on other virtuals. They will also be able to route message between each other.
The virtual server configuration contains a destination address and mask which specifies what IP addresses and port the virtual server will listen for incoming packets. The virtual server object also contains a source address allowing it to limit packets to those packets that originate from a range of devices.
The behavior of a virtual server is determined by the set of profiles attached to the virtual server. In addition, the behavior of a virtual can further be extended by assigning iRules to the virtual. Furthermore, the transport-config object is used to define the outgoing connection, for example source address translation, and translation modes of the virtual server. Note, the virtual server configuration (e.g. pool and persistence profile) used to select a destination is not used in MRF.
SIP Router Profile
SIP Router Profile Entity-Relationship
  • A SIP router profile provides the router-instance level characteristics such as mode of operation, routes and more. This profile defines attributes that are to be the same across the entire router-instance. In addition, it holds the static routes to be used across the entire router-instance.
  • A route is made of peers, where a peer may have a pool and a transport config
  • If a peer does not contain a pool, the local address of the originating connection is used as the remote address of the outgoing connection
  • If a peer does not contain a transport-config, the settings of the originating connections transport (virtual or transport-config) is used to create the outgoing connection.
  • The router profile binds the multiple virtuals (that clients connect to) and peers (that connect to backend servers), together with common shared states.
  • For ALG, no routes are configured for the router profile. The local address of the originating flow is used as the remote address of the outgoing connection.
ltm message-routing sip profile router siprouter { defaults-from none inherited-traffic-group <true|false> max-pending-bytes <integer> max-pending-messages <integer> max-retries <integer> mirror <enabled|disabled> mirrored-message-sweeper-interval <integer> operation-mode load-balancing routes { <static routes>* } session { max-session-timeout <integer> transaction-timeout <integer> } traffic-group <traffic group name> use-local-connection <enabled|disabled> }
SIP router profile attributes
Attribute
Description
Type
Acceptable Values
Default
operation-mode
Sets the operation mode of the SIP routing instance.
Must be set to load-balancing
ENUM
load-balancing
application-level-gateway
load-balancing
routes
List of references to sip-route object. The ordering of the route entries does not matter.
sip-route
A list of sip-route objects
max-pending-messages
The maximum number of pending messages that are held while waiting for a connection to a peer to be created. Once reached any additional messages to the peer is flagged as undeliverable and returned to the originator.
UINT32
1 to 4294967295 (32-bits)
23768
max-pending-bytes
The maximum number of bytes contained within pending messages that is held while waiting for a connection to a peer to be created. Once reached any additional messages to the peer is flagged as undeliverable and returned to the originator.
UINT32
1 to 4294967295 (32-bits)
64
use-local-connection
Controls whether connections established by the ingress TMM are preferred over connections established by other TMMs when selecting egress connection to destination peer.
BOOL
Enabled/Disabled
Enabled
traffic-group
The traffic group for the router instance. All virtual servers using this router profile will have the their traffic group replaced by the traffic group of the router profile.
traffic-group
default (inherited from partition)
mirror
Enables mirroring of all incoming connections for all virtual servers using this router instance, and all outgoing connection created by this router instance.
BOOL
enabled/disabled
disabled
mirrored-message-sweeper-interval
This attribute sets the frequency of the mirrored message sweeper. For virtual servers where mirroring is enabled, the received messages will be processed on both the active device and the standby device. On the standby device, the messages are not routed, instead they are stored in a message store until the active device sends a notification that the message has been routed to the standby device so that the standby device can deliver the message to the equivalent connection for egress processing. A sweeper has been implemented to drop messages from the message store if they remain in the store longer than the time specified in this attribute. The time shall be in milliseconds.
UINT32
1000(ms)
media-proxy
max-media-sessions
N/A in LB Mode
UINT32
1 to 10 (32-bits)
6
media-inactivity-timeout
N/A in LB Mode
UINT32
1 to 120 (32-bits)
120
session
dialog-establishment-timeout
N/A in LB Mode
UINT32
1 to 4294967295 (32-bits)
32
max-session-timeout
N/A in LB Mode
UINT32
1 to 4294967295 (32-bits)
7200
transaction-timeout
Specifies the maximum time in seconds between request and its response. A provisional response restarts the timer. This may not affect all transactions. The scenarios where a BIG-IP® system waits for response (like final response for REGISTER request), is impacted, by dropping any persistent data maintained for this request.
UINT32
1 to 4294967295 (32-bits)
180
Operation Mode
SIP operation mode
operation-mode
Description
load-balancing
Configures the SIP routing instance to operate in load-balancing mode. See
How to configure DAG Modes
for details.
application-level-gateway
Configures the SIP routing instance to operate in application level gateway mode (ALG). See
Default DAG
for details
SIP Route Table
  • SIP routes are collected into a route table.
  • Each SIP router instance maintains a route table.
  • When the SIP router receives a message for forwarding, the route table is used to determining the best route to use for forwarding the message.
  • The message's to-uri (RFC 3261 section 8.1.1.2), from-uri (RFC 3261 section 8.1.1.3), request-uri (RFC 3261 section 8.1.1.1) attributes and originating virtual is matched against the routes in the route table.
SIP Route table example
Request-URI
From-URI
To-URI
Virtual
Route Value
Default_pool
*.f5.com
Subdomain pool
*@f5.com
F5 domain pool
help@f5.com
Helpdesk pool
*@external.com
External pool
priority.user@isp.net
help@f5.com
Special helpdesk pool
  • The attributes is matched in the following order: to-uri, from-uri, request-uri and virtual.
  • Each URI is matched starting at the end of the attribute.
  • Because a URI key may contain a wildcard, a URI from a messages attribute may match multiple attributes, the longest match for the attribute is tried first.
  • If a matching route does not exist using the longest match, the next longest match is attempted.
  • An empty field is the same as a wildcard (all values are considered to match).
  • Route selection first matches the to-uri then the from-uri, followed by the request-uri and finally the virtual.
  • Each field is matched starting at the end of the field (last character).
  • There can be no characters before a wildcard (asterisk).
Consider a SIP route table with following routes:
SIP route match
To-URI
From-URI
Request-URI
Virtual
Route Value
default-route
*.f5.com
subdomain-route
*af5.com
f5domain-route
help@f5.com
helpdesk-route
it@f5.com
internal_vs
it-route
To route a message with the following attributes:
SIP route match
To-URI
From-URI
Request-URI
Virtual
it@f5.com
top.salesman@vendor.com
it@f5.com
external_vs
  • The SIP route table (refer table 3.3.3) would first look for a match for the to-uri.
  • It would find 3 matches: "" (wildcard), "*@f5.com", and "it@f5.com".
  • The longest match would be "it@f5.com". It would then try to match from-uri, request-uri and virtual.
  • The from-uri attribute would match the wildcard as would the request-uri.
  • The virtual would not match.
  • No match was found using "it@f5.com", so it would return to the next longest matching value, "*@f5.com".
  • It would then try and match from-uri, request-uri and virtual.
  • Matches for all three fields would be found so it would forward the message to a host as specified in the route value of the f5 domain route in table 3.3.3
SIP Route
ltm message-routing sip route siproute { from-uri <string> peer-selection-mode <sequential|ratio> peers { <one or more peer> } request-uri <string> to-uri <string> virtual-server <string> }
The SIP route has the following attributes.
SIP Route Attributes
Attribute
Description
Type
Acceptable Values
Default
name
Specifies the name of the route object
STRING
ASCII string
None
request-uri
Defines the pattern to be matched against the
request-uri
of a sip message. This URI is matched as a case insignificant method. It should be in the form of
user@domain
. The
sip:
prefix should not be present. Any additional modifiers (for example port or transport) should also not be present. It may begin with a wildcard, ‘*’. If empty, it is treated as if the entire URI was a wildcard (matching all Request-URIs).
STRING
ASCII string
format: <user@domain>
""
to-uri
Defines the pattern to be matched against the To field of a sip message. This URI is matched as a case insignificant method. It should be in the form of
user@domain
. The sip: prefix should not be present. Any additional modifiers (for example port or transport) should also not be present. It may begin with a wildcard, ‘*’. If empty, it is treated as if the entire URI was a wildcard (matching all To-URIs).
STRING
ASCII string
format:
<user@domain>
""
from-uri
Defines the pattern to be matched against the From field of a sip message. This URI is matched as a case insignificant method. It should be in the form of
user@domain
. The sip: prefix should not be present. Any additional modifiers (for example port or transport) should also not be present. It may begin with a wildcard, ‘*’. If empty, it is treated as if the entire URI was a wildcard (matching all From-URIs).
STRING
ASCII string
format: <user@domain>
""
virtual-server
Specifies a virtual server that this route is limited to. If no virtual is specified, messages originating on any connection may be routed to the route.
virtual-server
A virtual server instance
None
peers
Specifies the list of peers. The peers attribute is a list of references to mr-peer objects.
mr-peer
An instance or mr-peer
peer-selection-mode
Describes the method of selecting a peer from a list of peers.
sequential
: Peers are selected in the order listed. All traffic is routed to the first peer unless all pool members in the peer are marked down.
ratio
: Peers are selected based on their weights in comparison with other peers.
ENUM
sequential/ratio
sequential
A SIP route specifies a set of peers to use for forwarding messages. Each route contains a route key and a route value. The route key contains attributes that are matched against attributes in a SIP message. The route value contains a list of peers. If the attributes in the route key match, the message is forwarded to a host specified by route value.
Route Key
The route key contains the attributes that are matched against attributes from the SIP message header and optionally a list of virtual servers.
  • The to-uri, from-uri and request-uri attributes are matched against corresponding attributes in a SIP message's header.
  • These values are matched in a case insignificant method.
  • Only the user@host portion of the uri is matched. The protocol prefix and additional modifiers (like port, transport, key, etc) are not included in the match. (see RFC 3261 section 19.1)
  • The uri key in the message may start with a wildcard character, '*' (for example '*@f5.com'). If a uri key starts with a wildcard, this means that any valid pattern of characters at that position in the message's corresponding attribute is considered as matching refer section 3.3.1.1
  • An empty uri key is considered as matching any valid value in the message's corresponding attribute.
  • If virtual server attribute in the route key is empty, the route is applied to all messages. If the virtual server attribute is not empty, the route applies only to messages originating the virtual server specified.
  • A route key with all fields empty (wildcard) is used as a default route.
Filtered URI for Route Key
Example URI
Filtered URI for matching
sip: alice@atlanta.com
alice@atlanta.com
sip: alice:secretword@atlanta.com;transport=tcp
alice@atlanta.com
sips:alice@atlanta.com?subject=project%20x&priority=urgent
alice@atlanta.com
sip:+1-212-555-1212:1234@gateway.com;user=phone
+1-212-555-1212@gateway.com
sips: 1212@gateway.com
1212@gateway.com
sip:alice@192.0.2.4
alice@192.0.2.4
sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com
atlanta.com
sip:alice; day=tuesday@atlanta.com
alice@atlanta.com
Route Value
The route value contains a list of peers and a peer selection mode attribute.
  • The peer selection mode attribute specifies how a peer in the peer list is selected. Available values are sequential and ratio.
  • If the contained peers contain different transport types (ipproto), TCP, UDP, SCTP, only those peers that match the transport type of the originating connection is used for peer selection.
  • In sequential mode, the peers are selected in the order listed. The first peer is used unless all of its members are down.
  • In ratio mode, the ratio value in each peer shall be used to determine the distribution of message to each peer.
  • Once a peer has been selected, a pool member from the peer's pool is selected based on the pool's lb-mode attribute.
  • The peer's transport-config name (MR transport-config object refer to HighperformancemessageroutingframeworkforIMSprotocolsFS#Transport-config) is used to configure the type of connection (transport, security, protocol, rules, snat).
  • If the selected peer does not contain a pool, the destination ip and port of the message's originating connection is used as the destination host.
  • If the selected peer does not contain a transport-config name, the transport type and name of the message's originating connection is used as the destination host.
  • If the selected peer contains a pool with no pool members, the message is returned to the originator marked as unroutable.
  • If the selected peer contains a pool with pool members. one active pool member is selected as per the pool's specified load balancing mode.
SIP Session Profile
This profile is attached to every virtual & associated with each peer of a routing instance. This profile has settings that can affect the SIP message processing. Multiple SIP session profiles can be in use in a single routing instance. The virtual/peer processes the ingress/egress messages per its sip-session profile settings.
ltm message-routing sip profile session sipsession { custom-via <string> defaults-from none do-not-connect-back <enabled|disabled> enable-sip-firewall <yes|no> generate-response-on-failure <enabled|disabled> honor-via <enabled|disabled> insert-record-route-header <enabled|disabled> insert-via-header <enabled|disabled> loop-detection <enabled|disabled> maintenance-mode <enabled|disabled> max-forwards-check <enabled|disabled> max-msg-header-count <integer> max-msg-header-size <integer> max-msg-size <integer> persistence { persist-key <Call-ID|Src-Addr|Custom> persist-timeout <integer> persist-type <session|none> } }
The sip protocol profile has the following attributes.
SIP Session Profile Attributes
Attribute
Description
Type
Acceptable Values
Default
max-msg-size
Specifies the maximum acceptable SIP message size in bytes. The message that exceeds this size is silently discarded.
UINT32
1 to 4294967295 (32-bits)
65535
max-msg-header-count
Specifies the maximum count of expected header fields; The message that exceeds this limit is silently discarded.
UINT32
6 to 4096
64
max-msg-header-size
Specifies the maximum message header size in bytes; The message that exceeds this limit is silently discarded.
UINT32
1 to 4294967295 (32-bits)
16000
generate-response-on-failure
Enables to send failure response messages such as 4xx, 5xx and 6xx, when a SIP request is being dropped; Note: Where it is specified "silently" discarded/dropped, no error response is generated. In any case, a dropped message (request/response) is tracked in appropriate statistics counter.
BOOL
Enabled/Disabled
Disabled
Maintenance Mode
When selected (enabled), sends a SIP response of 503 Service Unavailable for an incoming SIP request. The SIP response to the SIP request is dropped.
BOOL
Enabled/Disabled
Disabled
max-forwards-check
Enables check on max-forwards; If 0, the request is discarded. An error response is sent, if configured.
BOOL
Enabled/Disabled
Enabled
loop-detection
Enables loop-detection check and in case loop detected, the request is discarded. An error response is sent, if configured.
A request is detected as seen before (forwarded/spiraled/looped) only if self inserted Via is found in the message and the value of its branch param plays a key role in detecting loop versus spiral. Hence enabling via insertion becomes a requirement to do loop detection check.
In ALG mode, Via header is not inserted by default and there is no loop detection in this mode.
BOOL
Enabled/Disabled
Disabled
insert-via-header
Enables insertion of top Via; When enabled, custom params to help route the response back are inserted, along with sent-by field of Via. The source address:port of the flow forwarding the request is filled as value for sent-by field of Via unless user provides custom via value. The custom params inserted to help routing, helps improve performance as it facilitates routing without any lookup. The via is inserted at egress side of the flow, after SIP_REQUEST_SEND event.
BOOL
Enabled/Disabled
LB MODE: Enabled
ALG MODE: disabled
custom-via
Specifies the custom value for the sent-by field of Via. Only the sent-by component value is mentioned here not the complete header.
STRING
<IP or FQDN name>[:<port>]
None
honor-via
Enables to honor via that is not inserted by a BIG-IP® system for routing the response.
BOOL
Enabled/Disabled
LB MODE: Enabled
ALG MODE: disabled
insert-record-route-header
Enables insertion of record-route header in requests that establish dialog. When enabled, along with URI, the custom params may be added to facilitate the routing of subsequent requests within this call to avoid route lookup. The record route URI is the local-IP & port of flows that are used for forwarding the message.
BOOL
Enabled/Disabled
Disabled
sip-firewall
Enables application of firewall policy
BOOL
Enabled/Disabled
Disabled
do-not-connect-back
Controls whether connection to a request originator is established (if it no longer exists) in order to deliver response. When disabled, responses that cannot be forward using an existing connection are dropped.
BOOL
Enabled/Disabled
Disabled
persistence
persist-key
Specifies the method to extract the key value that is used to persist on.
  • Call-ID - To persist based on the "Call-ID" header field value in the message.
  • Src-Addr - To persist based on originating IP address in the message
  • Custom - To persist based on the custom key specified using iRule.
ENUM
Call-ID/Src-Addr/Custom
Call-ID
persist-type
Specifies the type of the persistence to be used for the specified "persist-key" attribute value, the currently supported type is session.
  • Session - Uses session DB for storage, no hash is applied. The key used for session DB is value specified in the "persist-key" attribute. Insert-via-header must be enabled when persist-type is set to "Session", if not a validation error is thrown.
  • None - Persistence is disabled
  • Persistence is not applicable for SIP ALG modes.
ENUM
Session/None
Session
persist-timeout
Indicates the timeout value of persistence entries in seconds.
It's recommended to have the persist-timeout to be greater than transaction timeout, specified in the SIP session configuration, as the lesser of the two is used when creating the persist record on receiving of the initial SIP request message. The initial SIP request can be INVITE/SUBSCRIBE/MESSAGE. Upon receiving of the response for the initial SIP Request message the persistence record is updated with the persist-timeout value. (For any subsequent responses received the persist timeout is updated for the persist record.)
UINT32
1 to 4294967295 (32-bits)
180
Peer Object
A peer object is used to define a set of hosts and the the method to connect with them. Peers are used to create static routes. The peer structure is protocol independent while each protocol implementation of MRF will define its own static route structure.
ltm message-routing sip peer <named-object> { app-service <string> auto-initialization <enabled/disabled> auto-initialization-interval <integer> connection-mode <per-peer/per-tmm/per-blade/per-client> description <string> number-connections <integer> partition <string> pool <pool_name> ratio <integer> transport-config <tc_name> }
Peer Attributes
Peer Attributes
Attribute
Description
Default
pool
Pool associated with the peer. If only one peer, then configure a single-member pool. If none, the message will be forwarded to the destination address and port of the originating connection.
none
transport-config
Specifies the transport-config that defines the parameters of the outgoing connection. If none, the parameters of the originating connection will be used to create the outgoing connection.
none
connection-mode
Specifies how the number of connections per peer are to be limited as follows: per-peer, per-blade, per-tmm, per-client.
If a transport config is not specified, the attributes of the originating connection of the message being routed will be used to create the outgoing connection. In this case, the connection-mode in the peer object will be ignored.
per-peer
number-connections
Specifies the number of connections between the BIG-IP® system and a peer.
If a transport config is not specified, the attributes of the originating connection of the message being routed will be used to create the outgoing connection. In this case, the number-connections in the peer object will be ignored.
1
ratio
Used to designate the ratio of this peer when used within a route with a peer-selection-mode of ratio.
1
auto-initialization
If enabled, the BIG-IP® system will automatically create outbound connections to the active pool members in the specified pool using the configuration of the specified transport-config. For auto-initialization to attempt to create a connection, the peer must be included in a route that is attached to a router instance. For each router instance that the peer is contained in, a connection will be initiated. The auto-initialization logic will verify at a configurable interval if the a connection exists between the BIG-IP system and the pool members of the pool. If a connection does not exist, it will attempt to reestablish one.
disabled
auto-initialization-interval
Specifies the interval (in milliseconds) that attempts to initiate a connection occur. Valid ranges are from 500ms to 65535ms
5000ms
Connection Modes
A BIG-IP® system will make just one connection to a peer. This means that only one TMM is connected to each Peer. While this connection mode uses fewer connections it will introduce latency. This will happen when messages are disaggregated to the wrong TMM and must be forwarder. The following diagram provides additional detail.
Optimum scenario
Optimum scenario
  1. Message arrives on a Virtual Server (VS)
  2. Message is disaggregated to TMM-0
  3. TMM-0 is connected to the correct server so the message is sent
Performance impacted scenario
Performance impacted scenario
  1. Message arrives on a Virtual Server (VS)
  2. Message is disaggregated to TMM-1
  3. TMM-1 is not connected to Server 1 so message must be forwarded to the correct TMM. This will introduce latency.
  4. TMM-0 is send message to Server 1
A BIG-IP® system will make a connection from every TMM to the same peer. This means a machine with 8 cores will have 8 connections per peer. While this increases the number of active connections, it also improves performance because there is no need to forward messages between TMMs.
Every TMM is connected to every peer which decreases latency but increases the number of connections
Every TMM is connected to every peer which     decreases latency but increases the number of connections
  1. Message arrives on a Virtual Server (VS)
  2. Message is disaggregated to TMM-0
  3. TMM-0 is connected to the correct server so the message is sent
  4. Second message arrives
  5. Message is disaggregated to TMM-1
  6. TMM-1 is connected to the requested server so the message can be sent directly
A BIG-IP® system creates one connection per blade to each peer. This provides a balanced performance approach between the per peer connection mode (only one connection) and a per tmm connection mode (a connection from each TMM). This mode only makes sense for a hardware chassis with multiple blades.
Each blade will make a single connection to each peer.
Each blade will make a single connection to     each peer.
  1. Message arrives on Blade 0
  2. Blade 0 opens a connection to Server 1 and forwards the message
  3. Second message arrives
  4. Blade 1 opens a connection to server 1 and forwards the message
A connection will not be opened to Server 2 until a message targeted at that server arrives.
Transport Config
A transport config defines the parameters of a new outgoing connection. It is a subset of a virtual server used to define parameters of an outgoing connection. This includes the profiles, iRules and source-address-translation settings.
Since a transport-config may be used in a route that may be used in multiple router instances, the router profile is not defined in a transport-config object. Instead, an outgoing connection inherits the router profile of the router instance that creates an outgoing connection.
Transport Config Attributes
Transport Config Attributes
Attribute
Description
Default
ip-protocol
Specifies the ip protocol. This will be automatically set based on the transport profile added. This value is read-only.
none
source-port
Specifies the source port to be used for the connection being created. If the source-port is zero, an empirical port will be used.
0
profiles
The transport protocol and the protocol-specific profile associated with this outgoing connection.
source-address-translation
Specifies the source-address-translation type and the pool.
rules
List of iRules associated with this outgoing connection.
none
Source Address Translation
Transport Config Attributes
Sub-Attribute
Description
Default
type
Specifies the type of source address translation to perform
automap
pool
Specifies the name of the snap pool
none
Source Address Translation Types
Source Address Translation Types
Type
Description
automap
The self-ip of the outgoing vlan will be used as the source address of the outgoing connection.
snat
A source address will be selected from the named snat pool
none
No source address translation will be performed.

ALG without SNAT (No Address Translation)

  • Snoop control messages flowing through to manage media flows.
  • iRule can be used to rewrite headers.
  • Create media records in session db.
  • Create deny listeners to drop media packets received before the callee responds with its media details.
  • Create media flows to forward packets between caller and callee.
  • High Availability (HA)
    • Call table replication (supports failback)
    • Control connection mirroring (can be recreated on failback by endpoint)
    • Media flow mirroring

Configuration Objects

Virtual Server
A virtual server is a traffic-management object on the BIG-IP® system that is represented by an IP address and a service. Clients on an external network can send application traffic to a virtual server, which then directs the traffic according to configuration instructions.
All virtuals sharing the same router profile will share the same router instance. This means that they will be able to use connections created by traffic on other virtuals. They will also be able to route message between each other.
The virtual server configuration contains a destination address and mask which specifies what IP addresses and port the virtual server will listen for incoming packets. The virtual server object also contains a source address allowing it to limit packets to those packets that originate from a range of devices.
The behavior of a virtual server is determined by the set of profiles attached to the virtual server. In addition, the behavior of a virtual can further be extended by assigning iRules to the virtual. Furthermore, the transport-config object is used to define the outgoing connection, for example source address translation, and translation modes of the virtual server. Note, the virtual server configuration (e.g. pool and persistence profile) used to select a destination is not used in MRF.
SIP Router Profile
SIP Router Profile Entity-Relationship
  • A SIP router profile provides the router-instance level characteristics such as mode of operation, routes and more. This profile defines attributes that are to be the same across the entire router-instance. In addition, it holds the static routes to be used across the entire router-instance.
  • A route is made of peers, where a peer may have a pool and a transport config
  • If a peer does not contain a pool, the local address of the originating connection is used as the remote address of the outgoing connection
  • If a peer does not contain a transport-config, the settings of the originating connections transport (virtual or transport-config) is used to create the outgoing connection.
  • The router profile binds the multiple virtuals (that clients connect to) and peers (that connect to backend servers), together with common shared states.
  • For ALG, no routes are configured for the router profile. The local address of the originating flow is used as the remote address of the outgoing connection.
ltm message-routing sip profile router siprouter { defaults-from none inherited-traffic-group <true|false> max-pending-bytes <integer> max-pending-messages <integer> max-retries <integer> mirror <enabled|disabled> mirrored-message-sweeper-interval <integer> operation-mode load-balancing routes { <static routes>* } session { max-session-timeout <integer> transaction-timeout <integer> } traffic-group <traffic group name> use-local-connection <enabled|disabled> }
SIP router profile attributes
Attribute
Description
Type
Acceptable Values
Default
operation-mode
Sets the operation mode of the SIP routing instance.
Must be set to load-balancing
ENUM
load-balancing
application-level-gateway
load-balancing
routes
List of references to sip-route object. The ordering of the route entries does not matter.
sip-route
A list of sip-route objects
max-pending-messages
The maximum number of pending messages that are held while waiting for a connection to a peer to be created. Once reached any additional messages to the peer is flagged as undeliverable and returned to the originator.
UINT32
1 to 4294967295 (32-bits)
23768
max-pending-bytes
The maximum number of bytes contained within pending messages that is held while waiting for a connection to a peer to be created. Once reached any additional messages to the peer is flagged as undeliverable and returned to the originator.
UINT32
1 to 4294967295 (32-bits)
64
use-local-connection
Controls whether connections established by the ingress TMM are preferred over connections established by other TMMs when selecting egress connection to destination peer.
BOOL
Enabled/Disabled
Enabled
traffic-group
The traffic group for the router instance. All virtual servers using this router profile will have the their traffic group replaced by the traffic group of the router profile.
traffic-group
default (inherited from partition)
mirror
Enables mirroring of all incoming connections for all virtual servers using this router instance, and all outgoing connection created by this router instance.
BOOL
enabled/disabled
disabled
mirrored-message-sweeper-interval
This attribute sets the frequency of the mirrored message sweeper. For virtual servers where mirroring is enabled, the received messages will be processed on both the active device and the standby device. On the standby device, the messages are not routed, instead they are stored in a message store until the active device sends a notification that the message has been routed to the standby device so that the standby device can deliver the message to the equivalent connection for egress processing. A sweeper has been implemented to drop messages from the message store if they remain in the store longer than the time specified in this attribute. The time shall be in milliseconds.
UINT32
1000(ms)
media-proxy
max-media-sessions
N/A in LB Mode
UINT32
1 to 10 (32-bits)
6
media-inactivity-timeout
N/A in LB Mode
UINT32
1 to 120 (32-bits)
120
session
dialog-establishment-timeout
N/A in LB Mode
UINT32
1 to 4294967295 (32-bits)
32
max-session-timeout
N/A in LB Mode
UINT32
1 to 4294967295 (32-bits)
7200
transaction-timeout
Specifies the maximum time in seconds between request and its response. A provisional response restarts the timer. This may not affect all transactions. The scenarios where a BIG-IP® system waits for response (like final response for REGISTER request), is impacted, by dropping any persistent data maintained for this request.
UINT32
1 to 4294967295 (32-bits)
180