
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">HI Alarig, <div class=""><br class=""></div><div class="">Thank you for sharing your experiences. I don’t have the MSS currently but if that was the case, wouldn’t have experienced the drops more frequently?</div><div class="">Currently it happens once per month (or 0.8 per month) and contrary to your case which was 100% network related, in our case we don’t even see the</div><div class="">reply packet being generated and leaving the box. </div><div class=""><br class=""></div><div class="">What puzzles me also and based on the capture, is that I don’t see the TCP-ACK messages being sent to the customer. If BIRD opens a TCP socket </div><div class="">(not a simple RAW socket), I assume that the TCP connection will be handled by the OS and BIRD will push data segments (BGP keep alive messages) when ready.</div><div class=""><br class=""></div><div class="">But as per output, I don’t see the TCP ack messages at all. Is BIRD handling the TCP communication as well? </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">But good point the MSS, I will try to check it as well in the next incident. Thanks </div><div class=""><br class=""></div><div class=""><br class=""><div class="">

<div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Best regards,<br class=""><br class="">Stavros Konstantaras | Sr. Network Engineer | AMS-IX <br class="">M +31 (0) 620 89 51 04 | T +31 20 305 8999<br class=""><a href="http://ams-ix.net" class="">ams-ix.net</a></div>

</div><div class=""><br class="webkit-block-placeholder"></div><div class=""><br class=""></div><div class=""><br class=""></div>

<div><br class=""><blockquote type="cite" class=""><div class="">On 28 Feb 2020, at 14:12, Alarig Le Lay <<a href="mailto:alarig@swordarmor.fr" class="">alarig@swordarmor.fr</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Stavros,<br class=""><br class="">On ven. 28 févr. 12:41:24 2020, Stavros Konstantaras wrote:<br class=""><blockquote type="cite" class="">Hi Bird community,<br class=""><br class="">We are investigating a weird customer issue regarding our Bird Route<br class="">Servers (version 1.6.3) and a specific IPv6 session. Customer reports<br class="">a sudden drop of his IPv6 session and -until now- we could not relate<br class="">those drops with any issue or instability. Everything seems normal and<br class="">no other customer complained at the moment of the incident. <br class=""><br class=""><br class=""><br class="">After some packet capturing at the moment of the event, we discovered<br class="">that BIRD does not send a response messages to the customer’s BGP<br class="">keepalive messages (see attached picture), which result to the BGP<br class="">hold timer to expire and the sessions to be dropped. We observed this<br class="">anomaly with both RSs but at different time slots and the tcpdump<br class="">capture was running at the Interface were Bird is sending all BGP<br class="">traffic for customers. At the moment of the event, we didn’t do any<br class="">maintenance or other RS related work.<br class=""><br class="">Has any of you experienced this in the past? If yes, how did you solve<br class="">this?<br class="">Any related feedback is welcomed. <br class=""></blockquote><br class="">Do you have the MSS used to establish the session? I had an issue about<br class="">a session flapping with edgecast (verizonmedia) flapping on AMS-IX<br class="">because both were having a MTU at 9216 on our port. But some switch<br class="">didn’t like it well and sometime a packet is loss. If it’s the one<br class="">containing the keepalive, the session goes down.<br class=""><br class="">I resolved it by setting a MTU of 1514 on my side (which should have<br class="">been since always).<br class=""><br class="">Also, note that I’m not directly connected to the IXP, I’m using a<br class="">reseller.<br class=""><br class="">Regards,<br class="">-- <br class="">Alarig<br class=""></div></div></blockquote></div><br class=""></div></body></html>