Forum Discussion

Darly_Senecal_B's avatar
Darly_Senecal_B
Icon for Nimbostratus rankNimbostratus
Jun 02, 2014

F5 Load Balancer and Subversion

Hi Community: Before mentioning the issue, I don't manage any settings on Load Balancer, I just want to understand about reasons of the issue. Thanks

 

My team had migrated/upgraded subversion server into a different location. In comparison with the previous, that server is now running behind of F5 Load Balancer. Based on the setting before mentioned, users access and perform their svn activities using the https via LB. Then the LB will offload the svn traffic and communicates with the svn target server with under the regular http protocol.

 

However, there is a series of issues that we are catching up under https. For example:

 

  1. TSVN 1.7+ and 1.8+ users get the following error while checking out their codes: "An existing connection was forcibly closed by the remote host".
  2. In order to discern that the error (1) was caused by either the server or the LB, I upgraded to the latest version of TSVN (1.8.5). I was checking out the code but after long time of checkouts, I get the Connection timed out error. Which tells me about the LB issue (I don't know which error).
  3. Subclipse (with JavaHL adapter) clients have issue with checking out by mentioning as follows:

!MESSAGE org.apache.subversion.javahl.ClientException: RA layer request failed svn: Commit failed (details follow): svn: Unable to connect to a repository at URL 'https://LB-URL/svn/repo/trunk/darly' svn: OPTIONS of 'https://LB-URL/svn/repo/trunk/darly': could not connect to server (https://LB-URL) So we ended up mention users to change SVNKit client adapter.

 

Some users, either by renaming code file remotely (using TSVN) or branching/merging (Subclipse) get this type of error

 

org.apache.subversion.javahl.ClientException: RA layer request failed svn: Server sent unexpected return value (502 Bad Gateway) in response to COPY request for '/svn/repo/!svn/rvr/revision/trunk'

 

And this is probably because LB somehow didn't redirect the packet headers from https to http (for COPY activities, for example). Is anyone who went with these settings and solved these type of issues?

 

Any idea is welcome.

 

Regards

 

https
svn
tortoise svn

2 Replies

Sort By
  • Patrik_Jonsson's avatar
    Patrik_Jonsson
    Icon for MVP rankMVP
    Jun 03, 2014

    Hi!

    Considering the lack of responses, I guess we could do some brain storming?

    I'd ask your network team to provide some packet captures to understand where the connections are forcibly closed. You can then open the pcap files in ie Wireshark:

    Run this command on the loadbalancer where x.x.x.x is the source and y.y.y.y is the destination:
tcpdump -nni 0.0:nnn -s0 -w /var/tmp/output.pcap host x.x.x.x and host y.y.y.y -v

    You can also ask them to monitor the output of the following command:

    tmsh show /net rst-cause

    Does the SVN servers need to contact themselves via the load balancer for any reason?

    Ie. SVN-SRV-01 -> https://LB-URL/svn/repo/trunk/darly

    If so, you might need to use a SNAT for these requests.

    What do you mean by COPY activities? By packet headers, do you mean HTTP headers, and if so, which one do you suspect is missing?

    /Patrik

  • Patrik_Jonsson's avatar
    Patrik_Jonsson
    Icon for MVP rankMVP
    Jun 04, 2014

    Good article. To replace the destination according to what they suggest you can try this iRule:

    when HTTP_REQUEST {

    if { [HTTP::header exists "Destination"] } {
        HTTP::header replace Destination [string map { "https" "http" } [HTTP::header value Destination] ]
    }

}

    In regards to the resets I'd still recommend trying this command as there can be multiple reasons for a reset:

    tmsh show /net rst-cause

    /Patrik