On Thu, Jun 23, 2011 at 1:32 PM, Anonymous `M` <[email protected]> wrote: > hi fooler, > thanks for the informative response. > i wonder what is your "elegant" solution to that. =) does the bug still > exists even today after recent kernel release? > thanks!
hi anonymous, the bug that i discovered in linux was in 2008... linux properly recieved the RST segment coming from loadbalancer as seen from tcpdump inside linux server... by the time loadbalancer tried to reuse that socket pair to reconnect again to linux (initiate to complete 3-way handshake).. linux send invalid response... im not sure if that bug is still in there but i guess it is still in there as i havent check it lately.. it requires for me to make raw socket programming to simulate that kind of connectivity (which is not my priority right now) to show here in plug... the reason why i didn't bother to report this bug aside from it takes time to fix the bug.. the source port from loadbalancer is going to exhaust eventually as more and more users are using that service as time pass by... source ip is the load balancer ip, destination IPs are linux servers and destination port is port 80... since port is 16 bit... maximum is 64k... 64k is not enough at extremly high loads.. simple and elegant solution is create another IP address inside loadbalancer.. with that... per IP creates another set of 64k of source ports for unique socket pair :-> fooler. > > ________________________________ > From: fooler mail <[email protected]> > To: Philippine Linux Users' Group (PLUG) Technical Discussion List > <[email protected]> > Sent: Thursday, June 23, 2011 10:22 AM > Subject: Re: [plug] tcp_tw_reuse > > On Wed, Jun 22, 2011 at 11:36 PM, hard wyrd <[email protected]> wrote: >> If you're referring to tcp_fin_timeout, then I agree it's a strict >> violation >> of the TCP spec (which honestly is just a guide anyway and not a >> contract). >> Vendors violate spec from time to time (eg. put your favorite vendor >> here). > > nope.. RFCs guide vendors to comply and not to violate it.. thats the > main purpose of RFC... vendors fix it if they violated a > specification... > >> I'm asking about tcp_tw_reuse not tcp_fin_timeout which I'm not using >> (yet). > > im not even talking of tcp_fin_timeout... maybe you are just confuse > of other respondents... > >> Going back to my question. Why should you or should you not use >> tcp_tw_reuse? Let's not focus on what my purposes for asking this >> question >> for now :). Your thoughts will be appreciated. >> Ciao! > > sure... let me explain the mechanics of time wait state so that you > can decide later on if you really wanted to use it or not... > > in tcp.. there are two kinds to release a connection... > > 1. abortive release > 2. orderly release > > in abortive release.. either of the end hosts can send a reset (RST) > segment to abort the connection immediately... > > in orderly release.. both sides send finish (FIN) segments and > acknowledge (ACK) it for normal release of their connection... > > time wait state occured in number 2.. diagram below show the orderly > release of a connection... > > 1) Host A -----> FIN -----> Host B > 2) Host A <----- ACK <----- Host B > 3) Host A <------ FIN <----- Host B > 4) Host A -----> ACK -----> Host B > > the one who first send FIN segment is the one doing the active close > and the other side is doing the passive close.. host A is doing the > active close.. host A can either be a client or a server.. either of > them can initiate an active close (as well as simultaneous active > close) > > time wait state occured in number 3 when host A recieved FIN segment > of host B.. after that... host A send the final ACK to host B (number > 4).... > > when host B received the final ACK from host A... it destroys the > socket pair that created for that connection and return the resource > back to the kernel.. > > but in host A.... socket is not yet destroyed until time to wait is > over (expired)... > > the main purpose of time wait state is that in case host B didnt > receive the final ACK of host A (eg. lost in transit).. host B > retransmit or resend its FIN segment again to host A... host A cannot > destroy its socket pair immediately after sending the final ACK as > there is no way for host A to determined if host B received its final > acknowledgment.. that is why host A *must* wait before destroying its > socket pair according to RFC TCP specification... that is why a direct > violation of TCP specification and that is why a note in tcp_tw-reuse > documenation warns you of using that feature... > > another purpose of time wait state is to prevent from socket pair reuse.. > > socket pair is consist of source ip, source port, destination ip and > destination port... time wait state preventing to reuse the same value > of socket pair... > > that is why im asking you what are you trying to accomplish as time > wait reuse is not the soluton to your problem in the sense that it > already violated the TCP specification... > > i bump this kind of problem when i joined a global company offering a > new service where millions (and perhaps billions) of transactions per > day occured... the aggressive host doing a socket pair reuse because > it can easily runs out those ephemeral ports (64k) due to extremely > high transactions... the aggressive host is a cisco loadbalancer > communicating to a cluster of linux servers on the same network > segment... i discovered this problem when they escalated the problem > to me and i asked them a 1 minute tcpdump on that network segment.... > the problem here is not the loadbalancer as it is using an abortive > release to destroy the conneciton immediately towards linux servers > (so no time wait state occured here) so that it can reuse the same > socket pair again.. the problem is on linux servers having a bug on > its tcp/ip stack... i havent submit a bug to redhat as it will takes > time to fix the bug but instead i provided an elegant solution to > their problem... > > so you know now the mechanics and you have sound judgement if you want > to use that time wait reuse or not... > > fooler. > > >> >> >> >> On Wed, Jun 22, 2011 at 10:50 AM, fooler mail <[email protected]> >> wrote: >>> >>> On Tue, Jun 21, 2011 at 5:11 PM, hard wyrd <[email protected]> wrote: >>> > Hi all, >>> > Would enable set /proc/sys/net/ipv4/tcp_tw_reuse ? Why or why not? >>> > Your thoughts will be appreciated. Thanks! >>> > - HW >>> >>> if you can give us an idea what are you trying to accomplish and we >>> will let you understand if this time wait reuse is good for you or >>> not... perhaps you have a problem that time wait reuse is not the >>> actual solution... >>> >>> basically, time wait reuse is a direct violation of TCP specification... >>> >>> fooler. >>> _________________________________________________ >>> Philippine Linux Users' Group (PLUG) Mailing List >>> http://lists.linux.org.ph/mailman/listinfo/plug >>> Searchable Archives: http://archives.free.net.ph >> >> >> >> -- >> ------------------------------------------------------------- >> "Penguin, penguin, and more penguin !" >> >> http://www.webhostadmins.com >> http://www.madforubuntu.com >> http://baudizm.blogsome.com >> >> _________________________________________________ >> Philippine Linux Users' Group (PLUG) Mailing List >> http://lists.linux.org.ph/mailman/listinfo/plug >> Searchable Archives: http://archives.free.net.ph >> > _________________________________________________ > Philippine Linux Users' Group (PLUG) Mailing List > http://lists.linux.org.ph/mailman/listinfo/plug > Searchable Archives: http://archives.free.net.ph > > > _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List http://lists.linux.org.ph/mailman/listinfo/plug Searchable Archives: http://archives.free.net.ph
