Forum Discussion

aits_network_pr's avatar
aits_network_pr
Icon for Nimbostratus rankNimbostratus
Feb 08, 2017

Loadbalancing based on source IP

Hi all,

 

Thank you to have a look on the issue I am facing.

 

For PRTG, I created 2 virtual servers (UDP / 2055). POOL containing server PRTG 1> POOL containing server PRTG 2>

 

the idea is to loadbalanced the traffic based on the source IP. I used the field "source" in the general settings of the VS. I didn't create irules.

 

-> this configuration works.

 

BUT I created a new VS and I now get the below configuration POOL containing server PRTG 1> POOL containing server PRTG 2> POOL containing server PRTG 1>

 

Unfortunately, I cannot see any traffic crossing the VS PRTG03. (stats = zero traffic). I wonder if the LB matches the VS PRTG02 first (like a firewall would do). Do it mean I have to delete PRTG02 and recreate it?

 

any help would be appreciared.

 

A+

 

3 Replies

  • Hi A+,

     

    the "source address" matching criteria is performed via "best-match" and does not follow the order of creation. So you definately don't need to reorder / delete / recreate your Virtual Servers.

     

    By best bet is that your PRTG clients have already established an active connection to VS-PRTG02 (SRC=0.0.0.0/0) before you've added the VS-PRTG03 (SRC=10.2.0.0/16). In this case the clients will still stick to the previous configuration until the underlying connection gets closed and established again (see K13253 for further information).

     

    Cheers, Kai

     

  • That's very clear. thank you. but the issue is that this is not a TCP established session that really ends after a while. The PRTG clients push netflow traffic all the time to the LB via UDP 2055. We set the new VS 2 days ago and we still don't see traffic arriving to it. I don't know how to reset the LB so that it can take this new config into account.

     

    • Kai_Wilke's avatar
      Kai_Wilke
      Icon for MVP rankMVP

      Hi A+,

      The F5 handles UDP in a stateful manner. So as long as the client port of the PRTG clients remains the same, the the individual UDP-datagrams will match the existing "UDP-connection" entry and configuration change won't become active.

      To kill the existing "UDP-connection" entry issue the command below...

      [root@hostname:Standalone] config  tmsh delete sys connection cs-server-addr 10.104.100.1 cs-server-port 2055
      

      After killing the connection entries to your VS-PRTGXX virtual, the very next UDP-datagramm will create a new session using the updated configuration.

      Cheers, Kai