Version notice:
FLOW::create_related¶
Description¶
This iRule command 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
FLOW::peer
- String representation of a flow without a tunnel (when a local_addr is specified):
local_addr%route_domain,local_port,remote_addr%route_domain,remote_port,vlan_id,protocol
- 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
Syntax¶
FLOW::create_related [-translation-loose] [-hairpin] {
[proto <protocol number>]
clientflow [-local-ip <local_addr>] [-local-port <local_port>] <remote_addr> <remote_port> <vlan>
serverflow [-local-ip <local_addr>] [-local-port <local_port>] <remote_addr> <remote_port> <vlan>
[inherit-vs <virtual server name>]
}
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.
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 <SERVER_CONNECTED>: 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 <SERVER_CONNECTED>: 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 <SERVER_CONNECTED>: 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]"
}
}
Related Information¶
Warning
The links to the sample code below are remnants of the old DevCentral wiki and will result in a 404 error. For best results, please copy the link text and search the codeshare directly on DevCentral.
Sample Code:
- Introduced: BIGIP-14.1
The BIG-IP API Reference documentation contains community-contributed content. F5 does not monitor or control community code contributions. We make no guarantees or warranties regarding the available code, and it may contain errors, defects, bugs, inaccuracies, or security vulnerabilities. Your access to and use of any code available in the BIG-IP API reference guides is solely at your own risk.