Forum Discussion

smp_86112's avatar
Icon for Cirrostratus rankCirrostratus
Apr 15, 2011

Virtual Server/Server IP Address Conflict

We encountered an unusual situation yesterday where a server in an internal LTM VLAN suddenly became inaccessible. The server became inaccessible because it had been rebooted and saw an IP address conflict, which prevented networking from starting. It turns out that a Standard-type TCP port 80 virtual server was assigned the same IP address as the server in the internal VLAN. To resolve, we removed the VS and restarted networking on the server.


The server was not a member of any LTM pools, but should have been accessible via a wildcard VS.


I have never heard of this configuration before, where a VS address in the external VLAN was assigned the same address as a server in an internal VLAN. I read through the doc on VS types, and my configuration did not seem to match any of those types. It seems that everything was working fine from an application and accessiblity standpoint, up until the server was rebooted and saw the address conflict. We suspect the VS was assigned the conflicting address some time after the last time the server was rebooted. It's difficult to say as both those events were a long time ago.


I have a couple of general questions about this situation, though I am finding it a little difficult to verbalize. So feel free to interject any additional thoughts.


1) Is this a "valid" configuration? By valid, I mean should this configuration be expected to work? It seems to me that any IP address conflict is bad.


2) As I mentioned, the services that were running on this system seemed to be functioning fine up until it was rebooted, and I'm trying to understand why. My theory is that everything other than the VS traffic (i.e. TCP port 80) was being processed by the lower-priority wildcard VS. Is that plausible?


3) We did not receive an IP address conflict notification from the LTM when the server rebooted, nor was there a log message. I have received these notifications in the past, so I'm wondering why not this time? Could it be that the LTM doesn't consider it a conflict if the two addresses are in different VLANs?



I'd appreciate any thoughts or comments on this weird situation. Thanks.


5 Replies

  • Hi SMP,



    I don't have exact answers for all of your questions, but...



    If you already had a wildcard VS which allowed access to the server, there shouldn't be a need to have a more specific VS defined.



    If you did want to allow access by original IP (without destination address translation) through LTM to that specific host, you can define a host VS on port 0 or a specific port with the destination address set to the original IP. You'd set the type to forwarding and ensure ARP and destination address translation are disabled. You'd then need to configure clients with a static ARP entry for that destination IP pointing to an LTM self IP. The key there is the ARP config on LTM and clients. You do not want LTM answering ARP broadcasts for the destination IP or you'll get IP conflicts. Clients would need to know that LTM will answer for the destination IP without getting an ARP response. They'd also need a route for the destination IP pointing to an LTM self IP.



    I think it's simpler to either use a network forwarding virtual server or a one to one VS on a new IP pointing to a pool with a single member of the server address you want them to reach.



  • Hi hoolio, thanks for your response.



    If you already had a wildcard VS which allowed access to the server, there shouldn't be a need to have a more specific VS defined.



    Yes, I believe I understand that. I may have not made it clear though that assigning the same IP to both the VS and the server was a mistake - it was not anyone's intention. We just did not know it until the server was restarted and suddenly became inaccessible. We did not want traffic to/from the server to be processed by anything other than the wildcard VS.



    The scenario you laid out seems plausible, but doesn't seem like something anyone would want to do in that way.
  • Yep, I got that :). I just wanted to explain that a config "like" the one you described can be valid. But it's a bit convoluted as you need to have static ARP entries on each client.



  • Hello Experts,



    Can you please advise, what is the solution to the above issue? I have no Knowledge on F5, but we are facing same issue with our linux machine after reboot. Once we took off the IP from F5, then I was able to bring my server back in network.
  • I just answered your other similar post without reading this one first. Can you elaborate on your issue? Did you intentionally assign the same IP address to the Linux server and F5 virtual server?