Forum Discussion
Need to create irule
- Mar 08, 2023
MohammedNadeem I would do the following.
1. On the firewall between the load balancer and the client only allow the ports you want through to the virtual server (VS) IP in order to limit what ports someone can access since the VS will accept traffic on all TCP ports which might not be desired.
2. Configure your VS to listen on all TCP ports assuming you implemented step 1.
3. Configure a data group that has the port to pool mapping for each api which is provided below.
4. Configure an iRule the way it is shown below in order to reduce the amount of line numbers in your iRule.
5. Create one pool for every API so that you can perform a unique health check per port providing you flexibility to know which API is up or down as apposed to your option 2 which wouldn't allow for that.Internal data-group
ltm data-group internal CLASS_api_port_map { records { 64 { data POOL_name2_TCP64 } 67 { data POOL_name4_TCP67 } 68 { data POOL_name3_TCP68 } 98 { data POOL_name1_TCP98 } } type string }
iRule to be created
when CLIENT_ACCEPTED priority 500 { # Checks the TCP local port to see if it matches any port listed in the internal data-group if { [class -- match [TCP::local_port] == CLASS_api_port_map] } { # Creates a POOL variable to match the value to the port field otherwise you have no other way of matching the two values together set POOL_API [class -- match -value [TCP::local_port] == CLASS_api_port_map] pool ${POOL_API} } else { # Rejects all traffic that doesn't have a matching port in the the data-group above reject } }
Again as the comments outline, this will allow you to have a significant amount of port to pool mappings which keeping the iRule at just a couple lines in order to reduce confusion in the iRule and keep that line count low in order to not have to create an additional iRule if you go over the iRule line limit. You will notice that we create a variable called POOL_API inside the if statement because this is the only way you can match the port number to the appropriate pool. Feel free to adjust the data-group as you see fit because I'm sure you provided redacted names of pools and ports as well as change the variable names as long as the syntax remains the same.
MohammedNadeem If you can provide a bit more detail as to what is happening and what you would like to happen we might be able to provide additional information to assist you. Based on what you have put in your comment this is various different HTTP requests destined to 4 different virtual servers and if each had a pool configured under them they should accept those requests so no iRule is necessary to achieve this. If I am misunderstanding what you have put please do go into a bit more detail.
Hi Paulius,
We have 2 servers:
10.10.100.11
10.10.100.12
Both servers will be handling multiple APIs url with diffrent ports so Need to create HA for these URLs.
I have created 2 Virtual Servers:
1. Virtual Server with below Irule and it's working fine.
when CLIENT_ACCEPTED {
if { [TCP::local_port] == 98 } {
pool Name1
} elseif { [TCP::local_port] == 64} {
pool Name2
} elseif { [TCP::local_port] == 68 } {
pool Name3
} elseif { [TCP::local_port] == 67 } {
pool Name4
} else {
reject
}
}
2. Virtual Servers has been created with single pool and selected All services for virtual server and pool memebers.
Both Virtual Servers are working but need to know that which one is recommended and I should go for prodcution to have HA.
- PauliusMar 08, 2023MVP
MohammedNadeem I would do the following.
1. On the firewall between the load balancer and the client only allow the ports you want through to the virtual server (VS) IP in order to limit what ports someone can access since the VS will accept traffic on all TCP ports which might not be desired.
2. Configure your VS to listen on all TCP ports assuming you implemented step 1.
3. Configure a data group that has the port to pool mapping for each api which is provided below.
4. Configure an iRule the way it is shown below in order to reduce the amount of line numbers in your iRule.
5. Create one pool for every API so that you can perform a unique health check per port providing you flexibility to know which API is up or down as apposed to your option 2 which wouldn't allow for that.Internal data-group
ltm data-group internal CLASS_api_port_map { records { 64 { data POOL_name2_TCP64 } 67 { data POOL_name4_TCP67 } 68 { data POOL_name3_TCP68 } 98 { data POOL_name1_TCP98 } } type string }
iRule to be created
when CLIENT_ACCEPTED priority 500 { # Checks the TCP local port to see if it matches any port listed in the internal data-group if { [class -- match [TCP::local_port] == CLASS_api_port_map] } { # Creates a POOL variable to match the value to the port field otherwise you have no other way of matching the two values together set POOL_API [class -- match -value [TCP::local_port] == CLASS_api_port_map] pool ${POOL_API} } else { # Rejects all traffic that doesn't have a matching port in the the data-group above reject } }
Again as the comments outline, this will allow you to have a significant amount of port to pool mappings which keeping the iRule at just a couple lines in order to reduce confusion in the iRule and keep that line count low in order to not have to create an additional iRule if you go over the iRule line limit. You will notice that we create a variable called POOL_API inside the if statement because this is the only way you can match the port number to the appropriate pool. Feel free to adjust the data-group as you see fit because I'm sure you provided redacted names of pools and ports as well as change the variable names as long as the syntax remains the same.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com