Shulou(Shulou.com)06/01 Report--

The following brings you how to use iRule to choose SNAT pool in load balancing, hoping to give you some help in practical application. Load balancing involves more things, there are not many theories, and there are many books on the Internet. Today, we will use the accumulated experience in the industry to do an answer.

Demand:

Use iRule to select SNAT addresses according to different destination addresses or ports, to achieve the same background node, and to access different destination addresses or ports, the source address will be different.

Network Overview:

Intranet:

Backstage node server:192.168.10.71

Corresponding VLAN: Internal-selfIP: 192.168.10.1

Public network:

Client client: 172.16.10.172

Corresponding VLAN: external-selfIP: 172.16.10.1

1. Demand 1: load balancing function (client access server) solution 1. Create a new virtual server: http_VS: 172.16.10.100:80VS associate a load balancer pool: Pool member: 192.168.10.71 virtual server 802. Requirement 2: SNAT function (server accesses client), which translates one or more intranet nodes into a source address Solution 1. New SNAT: out_snat: 172.16.10.71 snat out_snat {translation 172.16.10.71 origin 192.168.10.71 / / only one machine is allowed outbound access} solution 2, snat out_snat2 {translation 172.16.10.250 origin 0.0.0.0 mask 0.0.0.0 / / allow all machines to egress access} solution 3, Snat out_snat3 {translation 172.16.10.188 origin 0.0.0.0 mask 0.0.0.0 vlan internal enable / / only vlan-internal traffic hits} 3. Requirement 3: iSNAT function (server accesses client), which translates one intranet node into multiple source addresses Solution 1. Create the necessary outgoing pool (make the destination address + port of access into pool form) So that iRule can be called): pool http_pool {member 172.16.10.71 pool ftp_pool {member 172.16.10.71 pool ftp_pool 21} New necessary snatpool:snatpool SNATPool_21 {member 172.16.10.21} snatpool SNATPool_80 {member 172.16.10.80} snatpool Internal_SNAT_Pool {member 172.16.10.250} New virtual server: snat_VS: 0.0.0.0:0VS Associates an iRule: iSNAT_Rule The content is as follows: rule iSNAT_Rule {when CLIENT_ACCEPTED {/ * define event * / set MYPORT [TCP::local_port] / * define destination port * / set S_IP [IP::client_addr] / * define the source address for initiating access * / log local0. "Port is $MYPORT" / * logs, printed in / var/log/ltm * / log local0. "S_IP is $S_IP" if {[IP::addr [IP::client_addr] equals 192.168.10.71]} / * set source address filter condition * / {switch $MYPORT {/ * according to different destination port Select a different SNAT address * / 80 {snatpool SNATPool_80 pool http_pool / * finally choose the access destination * /} 21 {snatpool SNATPool_21 pool ftp_pool} Default {snatpool Internal_SNAT_Pool pool other_pool} else {/ * if it is another background node You can freely configure * / snatpool Internal_SNAT_Pool pool http_pool} / / the core of the whole implementation requirement is iRule. After the configuration of this solution is completed, the BIG-IP system will do the following actions:

(for example, accessing client's http service from server)

A HTTP request arrives at the BIG-IP system from the server side and hits VS 0.0.0.0 BIG-IP 0

ISNAT_Rule is referenced, check request packet, BIG-IP system selects SNATPool_80 and load balancer pool http_pool

Using round robin load balancing algorithm, BIG-IP system chooses the next hop address 172.16.10.71 from http_pool.

There is a translation address 172.16.10.80 in SNATPool_80

The BIG-IP system randomly selects an address 172.16.10.80 from this translation address pool (in this case, it is a fixed source address translation, so there is only one translation address pool to choose from)

Finally, the BIG-IP system translates the client source IP address into the address 172.16.10.80 and forwards the request packet to 172.16.10.71 80

In this scheme, the original SNAT must not be invalidated, because the priority is 7 layers first, and then decreases sequentially, so the priority of 0.0.0.0 virtual server is higher than that of ordinary SNAT, so the details should be considered in iRule.

Solution 2. Create the necessary outgoing pool (make the destination address + port of access in the form of pool for iRule calls): pool http_pool {member 172.16.10.71 iRule 80} New virtual server: client_VS: 192.168.10.237:0VS associate an iRule: iSNAT_Rule2, as follows: rule iSNAT_Rule2 {when CLIENT_ACCEPTED {set MYPORT [TCP::local_port] log local0. "Port is $MYPORT" switch $MYPORT {80 {snatpool SNATPool_80 pool http} 21 {snatpool SNATPool_21 pool ftp_pool} default {snatpool Internal_SNAT_Pool pool http}

This solution is suitable for situations where there are a lot of outbound access requirements in the internal network segment.

In this scheme, the virtual server is established in the relative private network segment, so that the access client becomes the virtual server of the private network segment. After being processed by BIGIP, if a SNATpool in the iRule is hit, the source address becomes an optional address in the SNATpool, the destination address is converted to 172.16.10.71 in the pool, and the request packet is forwarded to 172.16.10.71

If other nodes in the internal network segment also need to access the external network, and there is no need for one-to-many source address translation, it can be done in a normal SNAT manner without conflict.

After reading the above about how to use iRule to select SNAT pool in load balancing, if there is anything else you need to know, you can find out what you are interested in in the industry information or find our professional and technical engineers for answers. Technical engineers have more than ten years of experience in the industry. Official website link www.yisu.com

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.