H.323 ALG iApps
Problem this snippet solves: This iApps creates H.323 ALG configuration including virtual servers, iRules, LSN pools, etc. This H.323 ALG is implemented using iRules (Tcl). It makes use of new CGNAT ALG Toolkit iRules primitive available in BIG-IP 14.1. The configuration consists of virtual server which intercept H.225 RAS (Registration, Admission, and Status) traffic. The ALG will extract information from H.225 traffic and start listeners for H.225 CS (call signaling) as necessary. The ALG will follow H.245 connection created by H.225 CS if there is any. It will also create flows for media connections based on negotiation happened in H.245 protocol level. The ALG can also intercept H.225 CS call which happens without H.225 RAS. Note that this iApps only support public vlan that is in route-domain 0 (default). How to use this snippet: This H.323 ALG iApps supports 2 main use cases 1. NAT44 2. 464XLAT Note that vlan, route, IP address configuration are not included in the iApps. They may be configured prior to create the application. For vlans, some NAT mode may requires specific cmp-hash mode, for example, PBA and DNAT require cmp-hash as src-ip on private side and cmp-hash as dst-ip on public side. Configuration for NAT44 and 464XLAT use cases are separated. Configuration objects (including virtual servers, LSN pool, etc) will be created separately and are not shared. Both options can be enabled in the same application. * * * To create application for NAT44 use case (see image below), select "yes" in "Enabled H.323 ALG for NAT44" section. Then enter information for private and public side. For private side, add virtual server to intercept H.225 RAS and H.225 CS (enter vlan, route-domain, port). Enter "allowed source" subnet information. To support hairpin call, select "yes" to "Create wildcard virtual..." option if there is no existing wildcard virtual that matches hairpin traffic. For public side, select public vlan, enter LSN pool member addresses and configure translation mode. * * * To create application for 464XLAT use case (see image below), select "yes" in "Enabled H.323 ALG for 464XLAT" section. Follow the same instruction as NAT44 use case. However, use appropriate IPv6 address as needed. The 464XLAT use case also require NAT64 prefix as BIG-IP acts as a PLAT. * * * In addition to configuration sections for NAT44 and 464XLAT use case. There are sections for Advance, Logging and Debug options (see image below). For "Advance Options" section: * Enforce no H.245 Tunnelling : select yes if you want ALG to try to prevent H.245 tunnelling in H.225 CS * Enforce no FastStart : select yes if you want ALG to try to prevent FastStart to be used * Choose action for ALG to take when iRules receives message it could not decode For "Logging Options" section: * Set LSN log destination : choose either to write log to local syslog or none For "Debug Options" section, enable debug log on categories of interest. Note that "per" debug log may produce very detail log information. Debug log option may only be enabled at no load. This iApps is created on "Wed May 09 04:45:14 GMT 2018" Tested this on version: No Version Found
Balance across LSN pools
When using CGNAT and multiple LSN pools are attached to a virtual server, BIG-Ip does not attempt to balance across the LSN pools. Balancing across LSN pools may be desirable in certain situations, such as where the pools correspond to different ISPs. This iRule provides balancing across LSN pools, using an algorithm similar to CARP to statelessly persist clients to pools (this doesnot replace the persistence function of the LSN pools). The iRule contains documentation and offers debugging if needed. You must configure the names of the LSN pools correctly - if the configuration section contains invalid pool names, some connections will be terminated. If this happens an error with the invalid pool name will be logged in /var/log/ltm # lsn-balance # This iRule is intended to balance between two or more LSN pools, with # approximately equal use of all pools # This uses an algorithm similar to CARP to persist clients to pools without # using expensive "table" calls when RULE_INIT { # Configures the names of the LSN pools set static::lsn_balance_pools { "/Common/LSN_split_1" "/Common/LSN_split_2" "/Common/LSN_split_3" } # Enable/disable debugging # 0 = disable, 1 = enable set static::lsn_balance_debug 0 ##### # No configuration past this point ##### # Save an "llength" call per connection set static::lsn_balance_pool_count [llength $static::lsn_balance_pools] } when CLIENT_ACCEPTED { if {$static::lsn_balance_debug} { # More readable version with intermediate vars for debugging # Fetch the client IP set client_ip [IP::client_addr] # Derive the hash we'll use for pool selection from client IP set lsn_select_hash [fasthash $client_ip] # Choose the list index based on hash - hash modulo length of pool list set lsn_select_index [ expr {$lsn_select_hash % $static::lsn_balance_pool_count} ] # Select pool from list of pools and use it set lsn_select_pool [lindex $static::lsn_balance_pools $lsn_select_index] # debug log local0. "lsn-balance: client: $client_ip pool: $lsn_select_pool hash: $lsn_select_hash index: $lsn_select_index" # Set pool selection LSN::pool $lsn_select_pool } else { # "one-line" version, equivalent to above # optimized by avoiding use of intermediate vars # but harder to read and offers no debugging LSN::pool [ lindex $static::lsn_balance_pools [ expr { [fasthash [IP::client_addr]] % $static::lsn_balance_pool_count } ] ] } }
