F5 is upgrading its customer support chat feature on My.F5.com. Chat support will be unavailable from 6am-10am PST on 1/20/26. Refer to K000159584 for details.

Forum Discussion

Paolo_125657's avatar
Paolo_125657
Icon for Nimbostratus rankNimbostratus
Jan 07, 2014

LTM cluster duplicating IP

Hi I have an issue with a cluster of two nodes LTM BIG-IP 11.2.1 Build 1042.0 Hotfix HF3 active-stby. What is happening is well weird:

 

Problem: Some of the VIPS are actually getting traffic on the ST-by node

 

So from a server in the same vlan I have sniffed the arp requests and sadly i receive an arp reply from both unit saying that they are the vip ip. Hence first to answer first to be served.

 

In the logs on the active node I have found: Wed Jan 8 10:03:32 ICT 2014 warning HKG1-AG-LB-04 tmm[7280] 01190004 address conflict detected for 10.117.192.229 (00:01:d7:e0:92:83) on vlan 4093 Wed Jan 8 10:03:33 ICT 2014 warning HKG1-AG-LB-04 tmm[7280] 01190004 address conflict detected for 10.117.192.232 (00:01:d7:e0:92:83) on vlan 4093 Wed Jan 8 10:03:33 ICT 2014 warning HKG1-AG-LB-04 tmm[7280] 01190004 address conflict detected for 10.117.192.214 (00:01:d7:e0:92:83) on vlan 4093 Wed Jan 8 10:03:33 ICT 2014 warning HKG1-AG-LB-04 tmm[7280] 01190004 address conflict detected for 10.117.192.229 (00:01:d7:e0:92:83) on vlan 4093 Wed Jan 8 10:03:34 ICT 2014 warning HKG1-AG-LB-04 tmm[7280] 01190004 address conflict detected for 10.117.192.232 (00:01:d7:e0:92:83) on vlan 4093 Wed Jan 8 10:03:34 ICT 2014 warning HKG1-AG-LB-04 tmm[7280] 01190004 address conflict detected for 10.117.192.214 (00:01:d7:e0:92:83) on vlan 4093 Wed Jan 8 10:03:34 ICT 2014 warning HKG1-AG-LB-04 tmm[7280] 01190004 address conflict detected for 10.117.192.229 (00:01:d7:e0:92:83) on vlan 4093 Wed Jan 8 10:03:35 ICT 2014 warning HKG1-AG-LB-04 tmm[7280] 01190004 address conflict detected for 10.117.192.232 (00:01:d7:e0:92:83) on vlan 4093 Wed Jan 8 10:03:35 ICT 2014 warning HKG1-AG-LB-04 tmm[7280] 01190004 address conflict detected for 10.117.192.214 (00:01:d7:e0:92:83) on vlan 4093 Wed Jan 8 10:04:01 ICT 2014 warning HKG1-AG-LB-04 tmm[7280] 01190004 address conflict detected for 10.117.192.233 (00:01:d7:e0:92:83) on vlan 4093 Wed Jan 8 10:04:02 ICT 2014 warning HKG1-AG-LB-04 tmm[7280] 01190004 address conflict detected for 10.117.192.233 (00:01:d7:e0:92:83) on vlan 4093 Wed Jan 8 10:04:03 ICT 2014 warning HKG1-AG-LB-04 tmm[7280] 01190004 address conflict detected for 10.117.192.233 (00:01:d7:e0:92:83) on vlan 4093 Wed Jan 8 10:04:04 ICT 2014 warning HKG1-AG-LB-04 tmm[7280] 01190004 address conflict detected for 10.117.192.233 (00:01:d7:e0:92:83) on vlan 4093 Wed Jan 8 10:04:05 ICT 2014 warning HKG1-AG-LB-04 tmm[7280] 01190004 address conflict detected for 10.117.192.233 (00:01:d7:e0:92:83) on vlan 4093

 

and the mac here (00:01:d7:e0:92:83) is actually the mac of the st-by unit.

 

Possible cause:

 

I think some of the administrator here have created those vips in the first place on the st-by nit ? I have no other explanation this is the first time i see this kind of behavior. Any Idea ?

 

Action taken so far:

 

Delete the VIP, sync the conf, re create the vip on the primary node and sync back.

 

Delete the VIP on the st-by unit only , sync the conf back from the primary.

 

Well so far no success.

 

I'm thinking about enabling mac masquerading, but that would require a MW because it will impact arp on the whole vlan and for all the VIPS.

 

Any help would be much appreciated.

 

Paolo

 

availability
deployment
management
TMSH

3 Replies

  • nitass's avatar
    nitass
    Icon for Employee rankEmployee
    Jan 08, 2014

    have you checked virtual address? what traffic group does it belong to?

    e.g.

    root@(ve11a)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm virtual-address
ltm virtual-address 172.28.20.15 {
    address 172.28.20.15
    mask 255.255.255.255
    traffic-group traffic-group-1
}
ltm virtual-address any {
    address any
    arp disabled
    icmp-echo disabled
    mask any
    traffic-group traffic-group-1
}
  • Paolo_125657's avatar
    Paolo_125657
    Icon for Nimbostratus rankNimbostratus
    Jan 09, 2014

    Sorry just seen the answer. So what actually happened was after an upgrade 3 out of my 6 clusters were with the common partition set to none ( actually inherit it from root), despite root partition has a default traffic group configured.

     

    I had to manually re assign the virtual addressees and reconfigure the common partition to have the traffic group 1 as a default instead to inherit none by root.

     

    This is weird as it happened only on three of the 6 clusters upgraded to 11.

     

    Anyway that caused massive problems with the SSL vips falling the TSL handshake, to solve which I had to change the floating ip used for snat as cleaning up all the sessions wasn't enough.

     

    Many thanks Paolo

     

    • Dan_G's avatar
      Dan_G
      Icon for Nimbostratus rankNimbostratus
      Apr 18, 2016
      I, recently, had the same issue. 1 of my clusters, when upgraded from 10.x to 11.x, ended up with some of the virtual addresses set to 'traffic-group none'. Fixed this by setting them to correct traffic group.