ltm rule command FLOW create related
iRule(1) BIG-IP TMSH Manual iRule(1)
FLOW::create_related
Creates a related client side and server side flow.
SYNOPSIS
FLOW::create_related (((-translation-loose) (-hairpin))#)? (FLOW_CREATE_RELATED_SUBCMDS)+
DESCRIPTION
Creates a related connection. Each related connection has two flows in it, a clientside flow and a serverside
flow. The clientside flow is created using the information provided in "clientflow" and serverside flow is
created using the information provided in the "serverflow". Both these flows are linked together and form a
connection. BIGIP excepts that the the first packet always comes from the client side of the connection for
all protocols except UDP. The returned TCL handle points to the clientside flow. [FLOW::peer] command can be
used to get a handle to the peer flow. By default the related connections use the fastL4 profile and are
hardware accelerated. Related flows do not get mirrored automatically. The iRule must create them on the next-
active with flow key returned after creating the flows. This allows the standby to store the handles for the
created flows and manage them correctly on failover. Related connections can only be setup between the hosts
the parent flow is connecting.
Syntax: FLOW::create_related [-translation-loose] [-hairpin] {
[proto ]
clientflow [-local-ip ] [-local-port ]
serverflow [-local-ip ] [-local-port ]
[inherit-vs ] }
* Input arguments:
+ -hairpin: To create a hairpin related connection. This option is supported with LSN and SECURITY-DYNAMIC-PAT source translation config only. This option should be used when hairpin connections from other subscribers using LSN or SECURITY-DYNAMIC-PAT are anticipated, as such the incoming subscriber flow (does not have to be the same as listener subscriber) must match an existing virtual-server with a LSN or SECURITY-DYNAMIC-PAT source translation pool attached.
+ -translation-loose: If -local-ip and/or -local-port values are used as a suggestion. If available they are picked, else another available endpoint is picked.
+ proto: Related flow protocol. When inherit-vs is used this must match the transport profile configured on the virtual.
+ clientflow: Flow key for the client side of the connection. For TCP connections the first syn must come from the clientside of the connection.
+ serverflow: Flow key for the server side of the connection
+ -local-ip: Source IP for packets generated by the BIGIP. This is optional and we recommend that this is not be specified. BIGIP will choose a valid IP which conforms to the config and is more efficient. For picking the local_addr the command looks at the supplied remote_addr to determine the parent flow. Source translation used by the parent is applied to the child flow too. If local_addr is specified, then it must conform to the source translation config of the parent, else the command will fail.
+ -local-port: Source port for packets generated by the BIGIP. This is optional and we recommend that this is not be specified. BIGIP will choose a valid port which conforms to the config and is more efficient. For picking the local_port the command looks at the supplied remote_addr to determine the parent flow. Source translation used by the parent is applied to the child flow too. If local_port is specified, then it must conform to the source translation config of the parent, else the command will fail.
+ Destination IP for the packets generated by the BIGIP.
+ Destination port for the packets generated by the BIGIP.
+ VLAN id or the name on which the packets are received.
+ inherit-vs: Inherit the profiles from a virtual server. This allows the related connections to use the parent virtual server profile and allows inspection of TCP/UDP packet payload. Currently this option is supported only for simple virtuals with TCP/UDP profiles only.
RETURN VALUE
TCL handle for the client side flow. On error an exception is thrown with a message indicating the cause of
failure. The string representation of the TCL handle can be used to retrieve the flow details. String
representation of a flow without a tunnel:
"local_addr%route_domain,local_port,remote_addr%route_domain,remote_port,vlan_id,protocol" When a local_addr
is specified String representation of a flow with a tunnel:
"local_addr%route_domain,local_port,remote_addr%route_domain,remote_port,vlan_id,protocol,tunnel_local_addr%route_domain,tunnel_local_port,tunnel_remote_addr%route_domain,tunnel_remote_port,tunnel_vlan_id,tunnel_protocol"
Route domain is not printed when zero.
VALID DURING
SERVER_CONNECTED, CLIENT_DATA, SERVER_DATA
EXAMPLES
when SERVER_CONNECTED {
# LSN pool with prefix 4.4.4.0/30,port-range=2000-2005 and NAPT mode is configured. Parent connection is translated as follows
# 10.10.0.1%1:60412 -> 10.20.0.1%1:9000 TO 4.4.4.1:1084 10.20.0.1:9000 tcp
# Subscriber side: 10.10.0.1%1:60412 -> 10.20.0.1%1:9000
# Internet side: 4.4.4.1:1084 10.20.0.1:9000
# Below is an example of couple of related connections
# Connection-1:
# Objective is to create a related TCP connection. The first SYN packet will be received from the subscriber side. local_addr/local_port on
# both sides is not specified and is picked by the command. A skeleton structure of the connection looks like this.
# 10.10.0.1:9999 -> (not specified):(not specified) TO (not specified):(not specified) -> 200.1.1.1:80
#
# The command uses the parent flow to determine the related flow's local_addr/local_port. This is done by comparing the remote_addr's of
# the parent connection with the clientflow/serverflow information. For this example clientflow is the "Subscriber side" of the related
# connection and "serverflow" is the "Internet side" of the related connection. For e.g. serverflow valid
# local_addr:local_port=4.4.4.1:2000-2005(LSN pool port-range).
#
# Nov 13 13:55:50 bigip1 info tmm1[28205]: Rule /Common/doc_examples : Connection-1: 10.20.0.1%1,58374,10.10.0.1%1,9999,4094,6 TO 4.4.4.1,2012,10.20.0.1,8889,4093,6
# Nov 13 13:55:50 bigip1 info tmm1[28205]: Rule /Common/doc_examples : Connection-2: 4.4.4.1,2006,10.20.0.1,1221,4093,6 TO 10.20.0.1%1,33518,10.10.0.1%1,1221,4094,6
# Nov 13 13:55:50 bigip1 info tmm1[28205]: Rule /Common/doc_examples : Connection-3: 11.11.11.11%1,2323,10.10.0.1%1,9999,4094,6 TO 4.4.4.0,2005,10.20.0.1,8889,4093,6
# Sys::Connections
# 10.10.0.1%1:60424 10.20.0.1%1:9000 4.4.4.1:2002 10.20.0.1:9000 tcp 10 (tmm: 1) none none <- Parent
# 10.10.0.1%1:9999 10.20.0.1%1:58374 4.4.4.1:2012 10.20.0.1:8889 tcp 11 (tmm: 1) none none <- Connection-1
# 10.20.0.1:1221 4.4.4.1:2006 10.20.0.1%1:33518 10.10.0.1%1:1221 tcp 11 (tmm: 1) none none <- Connection-2
# 10.10.0.1%1:9999 11.11.11.11%1:2323 4.4.4.0:2005 10.20.0.1:8889 tcp 11 (tmm: 1) none none <- Connection-3
if {[catch { FLOW::create_related {
proto 6
clientflow [clientside {IP::remote_addr}] 9999 [clientside {LINK::vlan_id}]
serverflow [IP::remote_addr] 8889 [LINK::vlan_id]
} } result] } {
log local0. "Couldn't create the connection, error:$result"
} else {
log local0. "Connection-1: $result TO [FLOW::peer $result]"
}
# Connection-2:
# Similar to Connection-1 but the first SYN is expected from the "Internet side"
if {[catch { FLOW::create_related {
proto 6
clientflow [IP::remote_addr] 1221 [LINK::vlan_id]
serverflow [clientside {IP::remote_addr}] 1221 [clientside {LINK::vlan_id}]
} } result] } {
log local0. "Couldn't create the connection, error:$result"
} else {
log local0. "Connection-2: $result TO [FLOW::peer $result]"
}
# Connection-3:
# Similar to Connection-1 but the -local-ip and -local-port parameters are specified.
# Interesting point to note here is clientflow -local-ip is set to a completely unrelated address 11.11.11.11.
# The command does not care because source is not being translated and does not need to conform to the
# source translation config. If however serverflow -local-ip is set to something outside the LSN pool, the
# command will thrown an exception.
if {[catch { FLOW::create_related {
proto 6
clientflow -local-ip 11.11.11.11 -local-port 2323 [clientside {IP::remote_addr}] 9999 [clientside {LINK::vlan_id}]
serverflow -local-ip 4.4.4.0 -local-port 2005 [IP::remote_addr] 8889 [LINK::vlan_id]
} } result] } {
log local0. "Couldn't create the connection, error:$result"
} else {
log local0. "Connection-3: $result TO [FLOW::peer $result]"
}
# Connection-4: Hairpin connection.
if {[catch { FLOW::create_related -hairpin {
proto 6
clientflow [clientside {IP::remote_addr}] 9999 [clientside {LINK::vlan_id}]
serverflow 10.10.0.3 8889 [clientside {LINK::vlan_id}]
} } result] } {
log local0. "Couldn't create the connection, error:$result"
} else {
log local0. "Connection-1: $result TO [FLOW::peer $result]"
}
}
HINTS
SEE ALSO
relate_client,relate_server
CHANGE LOG
@BIGIP-14.1.0 --First introduced the command.
BIG-IP 2020-06-23 iRule(1)