Manual Chapter :
Operation Modes
Applies To:
Show Versions
BIG-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, 14.0.1, 14.0.0
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> }
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
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.
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:
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:
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.
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: |
"" |
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.
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.
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. |
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.
|
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.
|
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
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
- Message arrives on a Virtual Server (VS)
- Message is disaggregated to TMM-0
- TMM-0 is connected to the correct server so the message is sent
Performance impacted scenario
- Message arrives on a Virtual Server (VS)
- Message is disaggregated to TMM-1
- TMM-1 is not connected to Server 1 so message must be forwarded to the correct TMM. This will introduce latency.
- 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
- Message arrives on a Virtual Server (VS)
- Message is disaggregated to TMM-0
- TMM-0 is connected to the correct server so the message is sent
- Second message arrives
- Message is disaggregated to TMM-1
- 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.
- Message arrives on Blade 0
- Blade 0 opens a connection to Server 1 and forwards the message
- Second message arrives
- 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
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
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> }
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 |
