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)
Update / Modify a Traffic Group of a Virtual Address using F5-SDK
Problem this snippet solves: I have an Active-Active LTM Deployment. Virtual Servers ( and Virtual Addresses ) are split between two units. I am trying to use F5-SDK to update traffic group so that VS/VA will move between two units. How to use this snippet: Environment Python : 3.6 F5 SDK : 3.0.20 LTM : 12.1.2 HF2 Code : from f5.bigip import ManagementRoot import sys # This will update a traffic group on a virtual address on the same bigip # Vars New_BigIP_IP = "10.10.10.10" Virt_Addr = "192.168.13.151" Traffic_Group = '/Common/traffic-group-2' # Connect f5_mgmt = ManagementRoot(New_BigIP_IP, username, password) # load Virtual Address v_a_info = f5_mgmt.tm.ltm.virtual_address_s.virtual_address.load(name=Virt_Addr,partition='Common') # Verify if traffic group needs to be updated if v_a_info.trafficGroup == Traffic_Group: print ("Traffic groups are same - no need to update - \nexiting ... ") sys.exit() #Capture the Old Traffic Group Old_Traffic_Group = v_a_info.trafficGroup print("\nOld Traffic Group : {} \nNew Traffic Group:}".format(Old_Traffic_Group,Traffic_Group)) input("Press any key to Continue.. ") # Update the New Traffic Group v_a_info.modify(trafficGroup=Traffic_Group) print ("== Traffic Group has been updated ==\n") Tested this on version: 12.1F5-SDK : How to update Virtual Address Traffic Group
I have an Active-Active LTM Deployment. Virtual Servers ( and Virtual Addresses ) are split between two units. I am trying to use F5-SDK to update traffic group so that VS/VA will move between two units. Vars BigIP_IP = "10.10.100.100" V_IP = "172.31.13.151:80" New_TG = "/Common/traffic-group-2" Connect new_mgmt = ManagementRoot(BigIP_IP, username, password) Load v_a_info = new_mgmt.tm.ltm.virtual_address_s.load(name=V_IP, partition='Common') Assign new TG v_a_info.trafficGroup = New_TG Update Virtual Address v_a_info.modify(v_a_info.trafficGroup) But getting this Error : Traceback (most recent call last): File "update-virtual-address-traffic-group.py", line 13, in v_a_info = new_mgmt.tm.ltm.virtual_address_s.load(name=V_IP, partition='Common') File "/usr/lib/python3.6/site-packages/f5/bigip/resource.py", line 655, in load raise InvalidResource(error_message) f5.sdk_exception.InvalidResource: Only Resources support 'load'. Then found out that "Virtual Addresses" are "Collections" and I able to read them fine using below command and loop through all attributes of a Virtual Address: v_a_info = new_mgmt.tm.ltm.virtual_address_s.get_collection() But then questions comes up how to update an Attribute of a "Virtual Address" in a Collection and push it back to the LTM to implement the change Versions F5-SDK : 3.0.20 LTM : 12.1.2 HF2 I highly appreciate any help or link to resolve this issue -Muhammad