Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0
Gyan Mishra <hayabusagsm@gmail.com> Sun, 20 December 2020 17:23 UTC
Return-Path: <hayabusagsm@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A6E3A110B for <idr@ietfa.amsl.com>; Sun, 20 Dec 2020 09:23:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAihSQrGxphi for <idr@ietfa.amsl.com>; Sun, 20 Dec 2020 09:23:49 -0800 (PST)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5423A1161 for <idr@ietf.org>; Sun, 20 Dec 2020 09:23:48 -0800 (PST)
Received: by mail-pg1-x52f.google.com with SMTP id 15so4906099pgx.7 for <idr@ietf.org>; Sun, 20 Dec 2020 09:23:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XJrK8I6rEd6m8FY5DXxCfwABAwir2LT0LDZfGBhh/E8=; b=sZf/MoGwctPbgWIil5yfsXi5e8b/ps8TRZmO/FCYoYE65vrTmTw4v5zg1iIYsG+Gr5 FJSh2EChbxU9Uj95idNHS3vKUnL50ymtXlQgAsGvrpq3Ak++JC9bCTB9BI0aDNTCj2S+ +wMDe1HPTLgv2YeKUNdtpgJAfIeu2uOQWQMY+uqkugwVYT/4Lb/k0d7ZYiJhcUPLHM80 CKNiKhCIu3W4TNsD6gcLEajNGalHdd4wLkAQrflUayTSXCqK4oJ/94KlQO1iKe6zppng Mo9OKeUhX7wILW+PSdnmhDEX24tW/HSEAxe0Y+7YXN9ag6p6D81fdmLSNT61IGhHjS9D +ntQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XJrK8I6rEd6m8FY5DXxCfwABAwir2LT0LDZfGBhh/E8=; b=f4A6GNIgLn0dpWaLuQIbSD4zN7v5MJJzbhtc07l+ScN12vqqqzjw533F4J049x/mD6 rlsi+8OZdMpZBbiKmWsXJqd0SNX4xT6FXlan/rYovsGSnTMPwR5GL6eETkJxNgie7LTc f2qey2rZRgmohnxlNaGRaN1Q34ww4/Gre+7e85k86tMUWB57pOsshH0THz94Lq/4YBI4 lzCeg3WxUWYrzct9OAmGWPwM2r0ANvEcHHS0gf5UKa75GtPd05ha9BDzaWAhLsmNuEBT NrD4ULRCL2yFWvUmZOWMA9viIlXSCuA0QTIr9/CzuQym8X7OtSJmKSfglbaG9Kg2kqA7 4gPA==
X-Gm-Message-State: AOAM531EcMQX00krVpQUwonvhXnV5kAAgo5TCz2ISnVOJg6gYbvaRZtA tJ3dG8pht8+pVr7Nw0KjD3DbZVVWlw9TN9ABAh4=
X-Google-Smtp-Source: ABdhPJw6uBqBphfhM7ZXcRIE1STOb/daUhEPFHaKfKAli4IISkRmjrAI8l1gl5lgJnteLqQNayF8ZHsA5lUrjehEWtw=
X-Received: by 2002:a65:5547:: with SMTP id t7mr12213524pgr.50.1608485027988; Sun, 20 Dec 2020 09:23:47 -0800 (PST)
MIME-Version: 1.0
References: <CANJ8pZ-WMDotkQvhN-NuP7ivZkPRR-9S2KJSar=6463U0VKkow@mail.gmail.com> <EFC56A31-1276-4DAB-9526-9C2F24814D2C@pfrc.org> <CANJ8pZ_LnDna_jtipcLJq9rrS3MM32rLdxRW8ntC2aEi9VvzMg@mail.gmail.com> <722A787A-5B83-4802-A9F4-AB2957BB3305@juniper.net> <CA+eZshBse4g6jUBMxs4bJiE+uvWScwv7ggLNOMJbUiL1YsaisQ@mail.gmail.com> <CABNhwV1ikHAknsfNDw6GJ8BngHDNjNdCxmgipJvJ7G3rxmnZVA@mail.gmail.com> <CAOj+MMHM0bHHL9UfVZC2QWy6=W5F7QtEq9v-rndcUG0u7CLi1Q@mail.gmail.com> <CABNhwV3CaWn5gsFGr4HNi_qoE4V1N1CA44KN+fFFvVCYr1YMgw@mail.gmail.com> <CAOj+MMHfn0cPhxNmXNprGdMRVkpSv0cJJrL=fq7rHb89owj6zA@mail.gmail.com> <CABNhwV27cmF4Z=_cRa_VRLwPDV_-0s27HNaAz5QkmXRVuab2jA@mail.gmail.com> <CAOj+MMEDuUBqo2UOj8OnbEkgwTvfioD_k2t-y9S_V+59=jMURA@mail.gmail.com>
In-Reply-To: <CAOj+MMEDuUBqo2UOj8OnbEkgwTvfioD_k2t-y9S_V+59=jMURA@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sun, 20 Dec 2020 12:23:36 -0500
Message-ID: <CABNhwV0L1sphL0H0Vn4aAxeVgvjh4QO0mZLGgxahBbFm+SG-zQ@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: Enke Chen <enchen@paloaltonetworks.com>, John Scudder <jgs=40juniper.net@dmarc.ietf.org>, William McCall <william.mccall@gmail.com>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b8478805b6e89a4d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/lzIh4KYUNaIggIrz5URquB5N31Y>
Subject: Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Dec 2020 17:23:59 -0000
Hi Robert Sorry I mis spoke my last note as it was not complete. I reread the thread again and the mail archive from 2010 below. I agree with everything you stated in your initial reply. Reiterating what you have stated on possible solution(s) so I am in sync with you I am using the mail archive problem statement visual depictions below. https://mailarchive.ietf.org/arch/msg/idr/q0Sx5d3zZjfOmOQ4lO2OZAHh9Lc/ So the main problem is the 1 way BGP being up and working from rtr-A to rtr-B and the TCP stuck state of BGP from rtr-B to rtr-A due to control plane or management plane congestion on rtr-A. On rtr-B the TCP socket for BGP is stuck and cannot write to the socket to send the BGP notification hold time expired. “Mechanics proposed seems to be to keep per peer HOLD_SEND timer and start it at each socket write failure then stop+reset it at each socket write success.” So what is being proposed is a method to detect the 1-way stuck peer with a new per peer “HOLD_SEND” different from the “HOLD_RECEIVE” to trigger a BGP session reset if we cannot write to the TCP socket for N second within the new “HOLD_SEND” interval. So after the first socket write failure a manual stop event and TCP RST to recover the peer immediately. So if the send buffer TCP socket can be written to successfully, don’t do anything, but as soon as a socket write failure occurs for the first byte attempted to be written, “stuck detected”, that would be the trigger for the BGP session reset. As far as GR if enabled discussed, rtr-A to RTs-B is still sending BGP updates, so we would set F flag to flush the BGP rib as we can’t trust the routes from A as they could be stale due to its control plane congestion. Correct? In an example topology: rtr-A rtr-B (congested c-p) (uncongested c-p) send window: >0 send window: 0 recv window: 0 recv window: >0 In this case we expect: a) rtr-B does not send any BGP packet (KEEPALIVE/UPDATE/NOTIFICATION) to rtr-A in normal operating circumstances. b) rtr-A does not expect any KEEPALIVE/UPDATE packets from rtr-B. The session remains established even if no packet is received in the holdtime. c) rtr-A continues to send KEEPALIVE packets to rtr-B. 1) rtr-A signals control plane congestion through means of setting the TCP recv window to 0, but continues to send KEEPALIVEs to rtr-B 2) rtr-B does not send any KEEPALIVE/UPDATE to rtr-A and indicates this fact through CLI output. 3) After t=HOLDTIME, rtr-B sends NOTIFICATION to rtr-A indicating that the hold time has expired. On Sun, Dec 20, 2020 at 7:25 AM Robert Raszuk <robert@raszuk.net> wrote: > Gyan, > > Not sure what you are really trying to highlight in your last note, but If > we would apply the same HOLD TIME used today to detect BGP liveness to > detect "stuck" peer it would be pretty bad choice for obvious reasons. > > Thx, > R > > On Sun, Dec 20, 2020 at 8:47 AM Gyan Mishra <hayabusagsm@gmail.com> wrote: > >> >> Hi Robert >> >> Thank you for the summarization. >> >> I agree this is a critical issue to be solved as it can happen to any >> global routing system. >> >> +1 with Tony, Jeff and others to apply the hold time to the transmit >> size, and plan to updated text for RFC 4271 section 6.5 to reflect. >> >> Excerpt from Tony: >> >> “More generally, the proposal is that we apply the HOLD TIME on the >> transmit side as well as the receive side. If we are not able to transmit >> for that period of time, the receiver should give up and so should the >> transmitter. The session is broken, updates cannot flow, and we no longer >> have (eventual) consistency.” >> >> Kind Regards >> >> Gyan >> >> On Sat, Dec 19, 2020 at 6:46 PM Robert Raszuk <robert@raszuk.net> wrote: >> >>> Hi Gyan, >>> >>> > Something simple otter then messing with TCP parameters, if instead of >>> using the default 90 second BGP dead timer, if that was reduced down a bit >>> to like 10 / 30 >>> >>> Sorry but again this is not the issue here. >>> >>> The issue is that rcv peer is not terminating the session after holdtime >>> expires. >>> >>> The sender can still keep receiving updates or keepalives just fine. >>> This is unidirectional issue. >>> >>> The ask here is to have BGP trigger session RST or termination at TCP >>> level when we can no longer write to a TCP socket for N seconds. >>> >>> - - - >>> >>> To summarize watching this thread it seems that most folks agree that if >>> we do that the HOLD_SEND should be different then HOLD_RCV. >>> >>> There is ongoing discussion to keep this at TCP level. >>> >>> There is an apparent ask to make it a default with a knob to disable it. >>> >>> Mechanics proposed seems to be to keep per peer HOLD_SEND timer and >>> start it at each socket write failure then stop+reset it at each socket >>> write success. >>> >>> The other day I asked how often BGP is retrying to write to socket in >>> most widely deployed implementations - but did not get any answer :( >>> >>> Best, >>> R. >>> >>> >>> On Sun, Dec 20, 2020 at 12:20 AM Gyan Mishra <hayabusagsm@gmail.com> >>> wrote: >>> >>>> >>>> Hi Robert >>>> >>>> On the other thread it was not quite clear. >>>> >>>> So if this scenario is completely devoid of link congestion and purely >>>> a management plane TCP control plane processing BGP socket processing issue >>>> then I agree BFD won’t help at all. >>>> >>>> I agree with the poor RP design of management plane that either lead to >>>> RP being overwhelmed high cpu and memory and or possibly memory leak or >>>> bug. >>>> >>>> Do we know which vendor? >>>> >>>> Something simple otter then messing with TCP parameters, if instead of >>>> using the default 90 second BGP dead timer, if that was reduced down a bit >>>> to like 10 / 30, that could limit the time traffic is black hole and not >>>> rerouted to alternate path until the hold timer expires. >>>> >>>> >>>> Kind Regards >>>> >>>> Gyan >>>> >>>> On Sat, Dec 19, 2020 at 5:18 PM Robert Raszuk <robert@raszuk.net> >>>> wrote: >>>> >>>>> Hi Gyan, >>>>> >>>>> > Going down this path of does seem a lot more complicated and risker >>>>> then using BFD. >>>>> >>>>> But BFD is not going to help at all to the problem at hand. >>>>> >>>>> BFD is in the vast majority of cases distributed (and that is feature >>>>> not a bug) and responses are handled by line cards. >>>>> >>>>> Here we are dealing with RE/RP based subsystems bugs regardless if >>>>> those are in TCP or BGP layer. >>>>> >>>>> Thx, >>>>> R. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sat, Dec 19, 2020 at 10:36 PM Gyan Mishra <hayabusagsm@gmail.com> >>>>> wrote: >>>>> >>>>>> >>>>>> Here is the RFC 5482 TCP User timeout options from TCPM WG. >>>>>> >>>>>> https://tools.ietf.org/html/rfc5482 >>>>>> >>>>>> TCPM has a bis draft update to 793 that has more info then the >>>>>> original. >>>>>> >>>>>> https://datatracker.ietf.org/wg/tcpm/documents/ >>>>>> >>>>>> https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-19#page-42 >>>>>> >>>>>> >>>>>> From quick read there are caveats with devices supporting or not >>>>>> supporting the option. >>>>>> >>>>>> Also I guess setting the value is tricky as well not too low or too >>>>>> high that either could make matters worse with instability. >>>>>> >>>>>> Going down this path of does seem a lot more complicated and risker >>>>>> then using BFD. >>>>>> >>>>>> >>>>>> Kind Regards >>>>>> >>>>>> Gyan >>>>>> >>>>>> >>>>>> On Sat, Dec 19, 2020 at 5:38 AM William McCall < >>>>>> william.mccall@gmail.com> wrote: >>>>>> >>>>>>> On Fri, Dec 18, 2020 at 10:33 PM John Scudder >>>>>>> <jgs=40juniper.net@dmarc.ietf.org> wrote: >>>>>>> > >>>>>>> > On Dec 18, 2020, at 1:09 PM, Enke Chen < >>>>>>> enchen@paloaltonetworks.com> wrote: >>>>>>> > > >>>>>>> > > No, I am not assuming that packets are getting somewhere. The >>>>>>> TCP_USER_TIMEOUT would work as long as there is "pending data" (either >>>>>>> unacked, or locally queued). The data can be from the local BGP Keepalives >>>>>>> or the TCP_KEEPALIVE. >>>>>>> > >>>>>>> > Apart from the other objections to relying on TCP_USER_TIMEOUT, >>>>>>> which I think are sufficient, it’s not clear to me that implementations >>>>>>> will provide the desired semantics. RFC 793 seems like it specifies the >>>>>>> right semantics (“get this data to the peer within N seconds or close”): >>>>>>> > >>>>>>> > The timeout, if present, permits the caller to set up a >>>>>>> timeout >>>>>>> > for all data submitted to TCP. If data is not successfully >>>>>>> > delivered to the destination within the timeout period, >>>>>>> the TCP >>>>>>> > will abort the connection. The present global default is >>>>>>> five >>>>>>> > minutes. >>>>>>> > >>>>>>> > However the Linux man page documents different semantics: >>>>>>> > >>>>>>> > TCP_USER_TIMEOUT (since Linux 2.6.37) >>>>>>> > This option takes an unsigned int as an argument. >>>>>>> When the >>>>>>> > value is greater than 0, it specifies the maximum >>>>>>> amount of >>>>>>> > time in milliseconds that transmitted data may remain >>>>>>> > unacknowledged before TCP will forcibly close the >>>>>>> > corresponding connection and return ETIMEDOUT to the >>>>>>> > application. If the option value is specified as 0, >>>>>>> TCP will >>>>>>> > use the system default. >>>>>>> > >>>>>>> > The important difference being that whereas 793 implies data >>>>>>> written to the socket, the Linux man page says “transmitted” data, which >>>>>>> seems like it must mean data TCP has written to the network. These are two >>>>>>> very different things! If Linux (or another stack) implements what the man >>>>>>> page seems to say, it’s not useful for our purposes. >>>>>>> > >>>>>>> > —John >>>>>>> > _______________________________________________ >>>>>>> > Idr mailing list >>>>>>> > Idr@ietf.org >>>>>>> > https://www.ietf.org/mailman/listinfo/idr >>>>>>> >>>>>>> I was curious too. I read the manpage, relevant linux kernel code, >>>>>>> the >>>>>>> RFC, and hacked up a test case (unicast me if you want the code). >>>>>>> Also, Cloudflare published a relevant blog entry[0]. For this >>>>>>> specific >>>>>>> scenario, see under the sub-heading "Zero window ESTAB is... >>>>>>> forever?". >>>>>>> >>>>>>> TCP_USER_TIMEOUT doesn't appear to kick in until there is unACKed >>>>>>> data, meaning that it has already been transmitted from TCP's >>>>>>> perspective. Stuff hanging around in the buffers due to persist state >>>>>>> doesn't seem to count, per the test results and the docs. Confirms >>>>>>> your thoughts from the reading I think. >>>>>>> >>>>>>> [0] https://blog.cloudflare.com/when-tcp-sockets-refuse-to-die/ >>>>>>> >>>>>>> -- >>>>>>> William McCall >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Idr mailing list >>>>>>> Idr@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/idr >>>>>>> >>>>>> -- >>>>>> >>>>>> <http://www.verizon.com/> >>>>>> >>>>>> *Gyan Mishra* >>>>>> >>>>>> *Network Solutions A**rchitect * >>>>>> >>>>>> >>>>>> >>>>>> *M 301 502-134713101 Columbia Pike >>>>>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver >>>>>> Spring, MD >>>>>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g> >>>>>> >>>>>> _______________________________________________ >>>>>> Idr mailing list >>>>>> Idr@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/idr >>>>>> >>>>> -- >>>> >>>> <http://www.verizon.com/> >>>> >>>> *Gyan Mishra* >>>> >>>> *Network Solutions A**rchitect * >>>> >>>> >>>> >>>> *M 301 502-134713101 Columbia Pike >>>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver >>>> Spring, MD >>>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g> >>>> >>>> -- >> >> <http://www.verizon.com/> >> >> *Gyan Mishra* >> >> *Network Solutions A**rchitect * >> >> >> >> *M 301 502-134713101 Columbia Pike >> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver >> Spring, MD >> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g> >> >> -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
- [Idr] TCP & BGP: Some don't send terminate BGP wh… Job Snijders
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Tony Li
- Re: [Idr] TCP & BGP: Some don't send terminate BG… John Scudder
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jeff Tantsura
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Robert Raszuk
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Robert Raszuk
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jakob Heitz (jheitz)
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Job Snijders
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Tony Li
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Keyur Patel
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jeff Tantsura
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Robert Raszuk
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Keyur Patel
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jakob Heitz (jheitz)
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Enke Chen
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jakob Heitz (jheitz)
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Robert Raszuk
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Christoph Loibl
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jakob Heitz (jheitz)
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Christoph Loibl
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jared Mauch
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jared Mauch
- Re: [Idr] TCP & BGP: Some don't send terminate BG… William McCall
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Job Snijders
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jared Mauch
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Enke Chen
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Randy Bush
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jared Mauch
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Tony Li
- Re: [Idr] TCP & BGP: Some don't send terminate BG… John Scudder
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Christoph Loibl
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jakob Heitz (jheitz)
- Re: [Idr] TCP & BGP: Some don't send terminate BG… John Scudder
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Job Snijders
- Re: [Idr] TCP & BGP: Some don't send terminate BG… John Scudder
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Robert Raszuk
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jakob Heitz (jheitz)
- Re: [Idr] TCP & BGP: Some don't send terminate BG… john heasley
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Keyur Patel
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Keyur Patel
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Brian Dickson
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Claudio Jeker
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Claudio Jeker
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jakob Heitz (jheitz)
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Job Snijders
- Re: [Idr] TCP & BGP: Some don't send terminate BG… John Heasley
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jakob Heitz (jheitz)
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Claudio Jeker
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jakob Heitz (jheitz)
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Brian Dickson
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jakob Heitz (jheitz)
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Job Snijders
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jakob Heitz (jheitz)
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Robert Raszuk
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Job Snijders
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Job Snijders
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Brian Dickson
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jeffrey Haas
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jeffrey Haas
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jeffrey Haas
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jeffrey Haas
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Brian Dickson
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Enke Chen
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Robert Raszuk
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Gert Doering
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Claudio Jeker
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jeffrey Haas
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jeffrey Haas
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Enke Chen
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Robert Raszuk
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Brian Dickson
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jakob Heitz (jheitz)
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Enke Chen
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jeffrey Haas
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Enke Chen
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Brian Dickson
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jeffrey Haas
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jakob Heitz (jheitz)
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Gyan Mishra
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jeffrey Haas
- Re: [Idr] TCP & BGP: Some don't send terminate BG… John Scudder
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Gyan Mishra
- Re: [Idr] TCP & BGP: Some don't send terminate BG… William McCall
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Gyan Mishra
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Robert Raszuk
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Gyan Mishra
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Gyan Mishra
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Robert Raszuk
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Jeffrey Haas
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Gyan Mishra
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Robert Raszuk
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Gyan Mishra
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Gyan Mishra
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Enke Chen
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Enke Chen
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Enke Chen
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Enke Chen
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Enke Chen
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Job Snijders
- Re: [Idr] TCP & BGP: Some don't send terminate BG… Enke Chen