Migration projects - how to avoid IP conflicts
Hi, Wonder if there is smarter/easier way to avoid IP conflicts during migrations - in the phase when production and new service should listen on the same IP. Scenario: All VIPs in 192.168.1.0/24 subnet All traffic to VIPs is coming via external router (no clients in 192.168.1.0/24 subnet) Production device IP: 192.168.1.254 Production VIP: 192.168.1.100 New device IP: 192.168.1.253 New VIP: 192.168.1.100 Traffic from any client except test station (192.168.10.100) should hit VIP at production device BIG-IP setup: Floating IP: 192.168.1.253 VIP: 192.168.1.100; ARP disabled External router setup: Route: From 192.168.10.100 to 192.168.1.100/32 gw 192.168.1.253 One important note: virtual-address object for VS has to be created in advance via tmsh. For example using tmsh load sys config from-terminal merge and similar config: ltm virtual-address 192.168.1.100 { address 192.168.1.100 arp disabled mask 255.255.255.255 traffic-group traffic-group-1 } or of course any other suitable way. Reason for that is simple - auto created virtual-address objects (created when VS is created) always has ARP enabled. After finishing testing all virtual-address objects can be updated with ARP enabled using simple bash script like below: !/bin/sh $1 contains source file with VIP to place in array $2 contains enable or disable to turn on and off ARP fro VIP if [ -z "$1" ] then bad arguments - quit echo "Syntax: vip_arp_enable-disable_from-file.sh " else mapfile -t myArray < $1 local count = 0 for vip in "${myArray[@]}" do echo "Vip is: $vip"; tmsh modify ltm virtual-address $vip arp $2; ((++count)); done echo "$count processed" fi With above script it's possible to both enable and disable ARP, file with list of virtual-addresses to be processed. Result: Traffic from any client (except sourced from 192.168.10.100) is just send to 192.168.1.100 based on MAC in ARP Reply send to 192.168.1.0/24 subnet by router. BIG-IP never responds to ARP Request for 192.168.1.100 (ARP disabled on this VIP) Traffic from sourced from 192.168.10.100 is send to 192.168.1.253 (next hop, using 192.168.1.253 MAC as target and 192.168.1.100 as target IP), then internally BIG-IP is able to route this packet to configured VS with 192.168.1.100. Tested and working, but maybe not optimal approach? What I am afraid is if ARP cache on router will not be issue - like when production traffic is routed MAC of production VIP is cached, then when test traffic is processed (to the same IP as production) this cached entry will be used - traffic will reach production instead of test VIP - never happened in my lab but it's not 100% confirmation it would not fail. Router simulated using other BIG IP with two VSs: Wildcard (Forwarding IP) accepting traffic to subnet 192.168.1.0/24 Wildcard (PerformanceL4): Source Address: 192.168.10.100/32 Destination Address/Mask: 192.168.1.0/24 All ports All protocols Address Translation and Port Translation: disabled Pool with Pool Member: 192.168.1.253 (Floating IP of other BIG-IP)
Migration projects - how to avoid IP conflicts
Hi, Wonder if there is smarter/easier way to avoid IP conflicts during migrations - in the phase when production and new service should listen on the same IP. Scenario: All VIPs in 192.168.1.0/24 subnet All traffic to VIPs is coming via external router (no clients in 192.168.1.0/24 subnet) Production device IP: 192.168.1.254 Production VIP: 192.168.1.100 New device IP: 192.168.1.253 New VIP: 192.168.1.100 Traffic from any client except test station (192.168.10.100) should hit VIP at production device BIG-IP setup: Floating IP: 192.168.1.253 VIP: 192.168.1.100; ARP disabled External router setup: Route: From 192.168.10.100 to 192.168.1.100/32 gw 192.168.1.253 One important note: virtual-address object for VS has to be created in advance via tmsh. For example using tmsh load sys config from-terminal merge and similar config: ltm virtual-address 192.168.1.100 { address 192.168.1.100 arp disabled mask 255.255.255.255 traffic-group traffic-group-1 } or of course any other suitable way. Reason for that is simple - auto created virtual-address objects (created when VS is created) always has ARP enabled. After finishing testing all virtual-address objects can be updated with ARP enabled using simple bash script like below: !/bin/sh $1 contains source file with VIP to place in array $2 contains enable or disable to turn on and off ARP fro VIP if [ -z "$1" ] then bad arguments - quit echo "Syntax: vip_arp_enable-disable_from-file.sh " else mapfile -t myArray < $1 local count = 0 for vip in "${myArray[@]}" do echo "Vip is: $vip"; tmsh modify ltm virtual-address $vip arp $2; ((++count)); done echo "$count processed" fi With above script it's possible to both enable and disable ARP, file with list of virtual-addresses to be processed. Result: Traffic from any client (except sourced from 192.168.10.100) is just send to 192.168.1.100 based on MAC in ARP Reply send to 192.168.1.0/24 subnet by router. BIG-IP never responds to ARP Request for 192.168.1.100 (ARP disabled on this VIP) Traffic from sourced from 192.168.10.100 is send to 192.168.1.253 (next hop, using 192.168.1.253 MAC as target and 192.168.1.100 as target IP), then internally BIG-IP is able to route this packet to configured VS with 192.168.1.100. Tested and working, but maybe not optimal approach? What I am afraid is if ARP cache on router will not be issue - like when production traffic is routed MAC of production VIP is cached, then when test traffic is processed (to the same IP as production) this cached entry will be used - traffic will reach production instead of test VIP - never happened in my lab but it's not 100% confirmation it would not fail. Router simulated using other BIG IP with two VSs: Wildcard (Forwarding IP) accepting traffic to subnet 192.168.1.0/24 Wildcard (PerformanceL4): Source Address: 192.168.10.100/32 Destination Address/Mask: 192.168.1.0/24 All ports All protocols Address Translation and Port Translation: disabled Pool with Pool Member: 192.168.1.253 (Floating IP of other BIG-IP)
Convert HTTP Class iRules for version 11.5.1 or later
Hello Folks, I had a customer who is using the old version of iRules, which contains HTTP Class selected commands, and now they want to upgrade to 11.5.1. The command is no longer supporting in that version and I am not able to convert it to compatible way to accept that iRule in 11.5.1 Sample iRule from the customer setup is as following. ltm rule /Common/Ems_staging_admins { when HTTP_REQUEST { if { [class match [IP::client_addr] equals "disable_asm_ip_ranges"] }{ HTTP::class select /Common/cls_EMS_staging_admin } else { HTTP::class select /Common/cls_EMS_staging } } } ltm rule /Common/efax_smtp_allow { when CLIENT_ACCEPTED { if { [class match [IP::client_addr] equals "allowed_ip_efax"] }{ log local0. "allowed to relay from [IP::client_addr]" } else { drop log local0. "Not allowed to relay from [IP::client_addr]" } } There are 2 iRules, and many more which needs to get edited. Can anyone shed some light on how can I modify the iRule in a way where it can be applied on 11.5.1 I have tried to follow the article, however I couldn't fix it. Thank you, DarshanHTTP Class to iRule Migration for 11.4.0 or later.
Hello Folks, I am working on a migration project for one of the customers who is running 11.2.1 HF8 currently and upgrading to 11.6.0. I have converted most of the HTTP Classes/iRule for 11.6.0 however there is one iRule is causing trouble. Current HTTP Class looks as following. paths { /geoportal(/.*)\? /arcgis(/.*)\? /directories(/.*)\? /mapviewer(/.*)\? /mapviewerar(/.*)\? /mapviewerbeta(/.*)\? /geoportalbeta(/.*)\? /proxy(/.*)\? /arcgis_js_api(/.*)\? /ogc(/.*)\? /tokenservice(/.*)\? /rest(/.*)\? /OntologyService(/.*)\? /services(/.*)\? } pool /Common/SDI_Pool_8085 Since the HTTP Path needs to be defined which matches the regex, I couldn't make further progress. Can anyone help me to configure an iRule to achieve the above? Any help will be highly appreciated. Thanks, Darshan
Migrating older F5 BIG-IP has 3 partitions & Route Domains (RD) to new F5 BIG-IP with 2 partion & RD
Hi everyone, I have an old appliance with 3 partitions and each partition has its own route domain. I want to terminate one of the partitions in the new appliance due to a change in the design. Is there any way to remove the partition before moving it to the new appliances? Rather than migrating the configuration to the new appliance and starting deleting the configuration for a specific partition.
Migrate APM Config between versions
Hi everyone! I've been performing a large migration for a customer and all has been going fine. However, I'm now working on a set of appliances that have the APM feature enabled. What is the best way to perform an APM migration between two systems of different versions? The source is version 12.1.5.3. The destination appliance is version 14.1.4.1. The other caveat is that the source appliance's configuration resides in the Common partition. The destination appliance has a few partitions and I need to migrate this APM configuration into a partition. Not sure if that'll make a difference. I've been using the config file to perform these migrations. I've been parsing the configuration file and making modifications so that it imports into the correct partition on the new appliance. However, this is my first time migrating an APM configuration and the configuration seems a bit more complicated than LTM. Again, what is the best way to migrate this configuration? I've already read that I can't simply export/import if the versions are different. Should I just do it all manually? Thanks in advance for any suggestions you can provide.
BigIP 5000 appliance upgrade to 11400 DS
Hi, We are upgrading our existing BigIP 5000 appliance (In HA) to the new 11400 DS appliance and have a few questions regarding the best approach. Should we use the Migration assistant tool? It looks like it has not been updated since 2018. We are familar with how to re-key and restore using UCS. Our On-prem DNS is sync with an Azure F5 ve to perform DNS load balancing/fall back to a maintenance webpage. My question is what is the best way to upgrade/migrate the existing BigIP 5000 appliance to the new 11400 DS? I was wondering if it is possible to add the 11400 (in HA) guests to the sync group, configure another different DNS listener IP, set up NAT, and update the global DNS side ?Migrating two physical devices to one virtual appliance
There are two separate standalone physical devices, one with LTM APM ASM and another one with LTM and GTM(DNS). Both the devices with huge configurations. Please let me know what all options we have in order to migrate these two physical devices to one virtual appliance.
BIG-IP LTM VE virtual hardware upgrade: Migrate to new virtual appliance or upgrade in place?
We have 2 instances of BIG-IP LTM VE deployed in separate environments and both were deployed to their respective vSphere environments several years ago and are still running at VMware HW Version 7, though the BIG-IP LTM versions running on them are currently 14.1.6. We have been upgrading them by ISO files (standard software upgrade procedure) without changing the VMs' configurations or virtual hardware versions. We have since upgraded our vSphere environments to 6.7 U3, and we plan to upgrade the BIG-IP LTM VE appliances we have to version 15.1.x from 14.1.x (and later, our physical F5 BIG-IP nodes from 13.1.x to 15.1.x). What is the best approach or path to upgrading both the virtual hardware and software versions running on them? Do I just upgrade the virtual HW in place to the latest available, or is it better/easier to deploy the 15.1.x VE OVA and just backup/copy/migrate the configs (UCS..?) over to the new appliance? If upgrading HW in place, does the VM need to be powered off? I want the most stable upgrade method possible, since the HW upgrade is a big jump up, especially when also upgrading a major OS version. Note, we can easily power the virtual F5 appliances down as these are in test environments.