This content has been marked as final. Show 5 replies
Wow what a useless way to find "closest". I can't think of any real-world network I've been in where that would actually work reliably.
I suggest using the "Ping time" option instead. Then your agent will pick the repository with the lowest ping time.
Say my client IP is 10.1.16.89.
I've got some repositories setup covering specific user subnets:
Repo1 - 10.1.15.0/23
Repo2 - 10.7.15.0/23
Repo3 - 10.45.15.0/23
Using "closest subnet" I can always be assured I will be pulling from the assigned respository, or at least trying it first. If you're using "fastest ping" what happens if your local respository (Repo1) has a momentary glitch or network hiccup and the repository (Repo3) waaaay on the other side of your WAN (potentially across the country/world) has a quick response? Then you potentially have a fair amount of traffic traversing the WAN instead of the LAN.
Thats just my $.02 - using "closest subnet" has worked well for me.
Maybe I misunderstand how "subnet distance" is supposed to work? For example, say that in your situation:
Repo1 is in Seattle, WA
Repo2 is in Australia
Repo3 is in San Jose, CA
If Repo1 goes down, then using "subnet distance" your client will update from Australia instead of San Jose, correct?
However, if you use "ping time" then the client should update from San Jose, right?
at first i think set it as select repo by ping time is easy to set and understand.
but if the subnet distance is work like mr. bxs said it should better than ping time, right?