Forum Discussion

Piotr_Lewandows's avatar
Icon for Altostratus rankAltostratus
Sep 17, 2018

Migration projects - how to avoid IP conflicts


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.


  • All VIPs in subnet
  • All traffic to VIPs is coming via external router (no clients in subnet)
  • Production device IP:
  • Production VIP:
  • New device IP:
  • New VIP:
  • Traffic from any client except test station ( should hit VIP at production device

BIG-IP setup:

  • Floating IP:
  • VIP:; ARP disabled

External router setup:

  • Route: From to gw

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 {
    arp disabled
    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:

$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" ]
     bad arguments - quit
    echo "Syntax:  "
    mapfile -t myArray < $1
    local count = 0

    for vip in "${myArray[@]}"
        echo "Vip is: $vip";
        tmsh modify ltm virtual-address $vip arp $2;


    echo "$count processed"

With above script it's possible to both enable and disable ARP, file with list of virtual-addresses to be processed.


Traffic from any client (except sourced from is just send to based on MAC in ARP Reply send to subnet by router. BIG-IP never responds to ARP Request for (ARP disabled on this VIP)

Traffic from sourced from is send to (next hop, using MAC as target and as target IP), then internally BIG-IP is able to route this packet to configured VS with

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
  • Wildcard (PerformanceL4):

    • Source Address:
    • Destination Address/Mask:
    • All ports
    • All protocols
    • Address Translation and Port Translation: disabled
    • Pool with Pool Member: (Floating IP of other BIG-IP)

1 Reply

  • From Kevin Davies:

    tmsh list ltm virtual-address | awk '/ltm/ { print "create ltm virtual-address "$3" arp disabled" }'

    Just to mark this as answered.