August 2023 - NLNOG - mailman3.nlnog.net

NLNOG Day 2023
by Teun Vink 25 Aug '23

25 Aug '23

Hallo allemaal, hi everyone! (English text can be found below) We hebben ontzettend veel aanmeldingen voor presentaties mogen ontvangen, onze dank daarvoor! Het viel niet mee om daaruit een mooie selectie te maken en we hebben helaas daardoor ook een aantal interessante presentaties moeten afwijzen, maar we kunnen nu met trots melden dat we een prachtige serie presentaties kunnen verwachten van leuke en boeiende sprekers. Een paar keywords om je interesse te wekken: VPP, segment routing, BGP CVE’s, autisme, zeekabels, HSM’s en aftappen. En natuurlijk staat ook de inmiddels befaamde NLNOG Quiz met mooie prijzen weer op het programma. Wacht dus niet te lang met inschrijven want het aantal beschikbare kaarten is beperkt! Hier zijn nogmaals de details: Waar: Podium Mozaïek, Amsterdam Wanneer: dinsdag 26 september Kosten: gratis (betaalde tickets ook zijn beschikbaar om zo NLNOG te sponsoren) Programma en aanmelden: https://nlnog.net/nlnog-day-2023/ We hopen dat jullie net zo enthousiast zijn als wij en we dat jullie dus op de NLNOG Day 2023 mogen ontmoeten. Deel deze uitnodiging vooral met je collega’s, studiegenoten en anderen waarvan je denkt dat ze geïnteresseerd kunnen zijn. En mocht je er onverhoopt niet bij kunnen zijn, dan geen nood: natuurlijk zorgen we voor een live stream en komen alle presentaties weer als videos beschikbaar. (English text) We have received a lot of talk proposals for NLNOG Day 2023, thank you all for that! It was hard to make a good selection of talks and unfortunately we had to turn down a number of very interesting talks, but we’re proud to announce that we have a series of very interesting presentations lined up by some excellent presenters. A few keywords to spark your interest: VPP, segment routing, BGP CVE’s, autism, submarine cables, HSM’s and legal interception. And of course, there will be another edition of the famous NLNOG Quiz with awesome prices! So don’t wait too long to register since the number of tickets available is limited. Here are the details: Where: Podium Mozaïek, Amsterdam When: Tuesday, September 26th Costs: free (but paid tickets are available if you want to sponsor NLNOG) Program and registration: https://nlnog.net/nlnog-day-2023/ We hope that you’re as excited as we are and that we’ll see you at NLNOG Day 2023. Please share this invitation with your coworkers, fellow students and other people you think would be interested. And don’t worry if you can’t make it: we’ll make sure there is a live stream and all presentations will be recorded. Bedankt en met vriendelijke groet, thank you and kind regards, De NLNOG Day 2023 Crew

1 0

Curious problem with connections from Ziggo customers to Linode nodes in some data centers
by Stefan van den Oord 25 Aug '23

25 Aug '23

Dear NLNOG community, I’d like to present to you a problem that we’re experiencing. To us it is very strange, we are out of ideas. Of course solutions would be much appreciated, but also ways of diagnosing this and work-arounds are very much appreciated. Background: we’re a small Dutch company developing the Viduet platform: a platform to help chronically ill patients better manage their wellbeing together with their care providers. Our product is web-based and we also have a mobile app. The problem: since almost two weeks we’re getting reports from users that sometimes (!) get connection timeouts in their browsers/apps when they connect to our web platform. We have narrowed down the potential sources of the issue and found a small setup to reproduce the issue: We setup a clean Linode node in Frankfurt (smallest type, shared CPU) with Apache (just `apt install apache2`). Requesting the default apache index.html using `curl -i http://172.104.202.142` <http://172.104.202.142`/> (or http://172.104.202.142/large.html) causes timeouts more than 1 in 10 tries for some users, who have in common that they are all customers of the Ziggo internet provider. Doing the same with a Linode node in Paris has the same result. Doing the same with a Linode node in London works as you would expect, so does not have this strange behaviour. Running `mtr -rwzbc100 172.104.202.142` (the Frankfurt node mentioned above) shows no packet loss, nothing out of the ordinary. Running nginx instead of apache makes no difference: same issue Forcing apache to use http/1.0 makes no difference: same issue (but frankly I don’t think it goes wrong on this level of the protocol stack) There seems to be a relationship with the content length of the HTTP response. For shorter HTML files like the index.html on the Frankfurt node, it sometimes times out, and sometimes succeeds after a delay of a few seconds (and sometimes returns as fast as you’d expect). Using slightly larger HTML files it just times out. I’m hesitating whether this is relevant at all, but when using HTTPS instead of HTTP, the problem also manifests in TLS handshake errors. We have been in touch with Linode support and they found nothing out of the ordinary on their side. They point to the Ziggo network, saying: > The reason that the issue only exists from to the Frankfurt data center and not London is likely because the problem is related to the particular route that the traffic takes from one place to the other. While the MTRs you shared look good, I did find evidence in another ticket of a particular hop within Ziggo's network showing issues, but we can't say for sure what the issue is. Here is the information about the hop in case that helps with your communication with Ziggo: > AS33915 asd-tr <http://asd-tr0021-cr101-be64.core.as9143.net/>0021 <http://asd-tr0021-cr101-be64.core.as9143.net/>-cr <http://asd-tr0021-cr101-be64.core.as9143.net/>101 <http://asd-tr0021-cr101-be64.core.as9143.net/>-be <http://asd-tr0021-cr101-be64.core.as9143.net/>64 <http://asd-tr0021-cr101-be64.core.as9143.net/>.core.as <http://asd-tr0021-cr101-be64.core.as9143.net/>9143 <http://asd-tr0021-cr101-be64.core.as9143.net/>.net <http://asd-tr0021-cr101-be64.core.as9143.net/> (213.51.64.193) Again, any help is much appreciated! Kind regards, — Stefan van den Oord CTO @ Medicine Men B.V. Not in the office on Wednesdays Regulierenring 22 3981 LB Bunnik The Netherlands +31 85 1307020

5 7

Re: [NLNOG] Curious problem with connections from Ziggo customers to Linode nodes in some data centers
by Boudewijn Visser (nlnog) 25 Aug '23

25 Aug '23

Munging the http urls since the listserver claims they are on a spam list . See if this gets through. Also switched to plain text since html didn't edit the URls properly. > Op 24-08-2023 12:50 CEST schreef Boudewijn Visser (nlnog) <bvisser-nlnog(a)xs4all.nl>: > > > Hi Stefan, > > While I'm quite old skool, I just never really got into irc, so I missed the conversation. > > I've had a look at your packet capture . > It doesn't seem to be an MTU issue . > > Filtering for the traffic captured on the server side : > (ip.src_host == 192.46.232.6 && ip.dst_host == 84.28.119.251 ) ||( ip.dst_host == 192.46.232.6 && ip.src_host == 84.28.119.251 ) > > So it seems your Ziggo public IP is 84.28.119.251 . > And filtering for the capture from the inside client side > (ip.src_host == 192.46.232.6 && ip.dst_host == 192.168.0.107 ) ||( ip.dst_host == 192.46.232.6 && ip.src_host == 192.168.0.107 ) > > I see an OK session using source port 50006 , and then a session that seems to have severe packet loss issues with source port 50007 . > > See al the TCP retransmissions for the source-port 50007 session - and rarely that a packet gets through. > > If you still can use this client (same public IP) try > curl --local-port 50006 http://192.46.232.six > curl --local-port 50007 http://192.46.232.six > > that should replicate the problem exactly, first one always OK, second one always major problems. > Note : some socket timeouts when trying multiple times shorty after each other.(bind failure socket already in use ) > > And - the specific local port that fails or works very likely also depends on the client source IP. > > Sabri's suggestion on for tcp-traceroute is also valuable . > > (normally , traceroute is done using UDP (classic Unix, Cisco) or ICMP - but it can be done with TCP too. ) > With some luck , tcp-traceroute may give a hint for a node or path where the failure starts. > > I've done a quick test (I happen to be behind Ziggo at the moment) but a tcp traceroute isn't too conclusive . > Generally load balancing within a network is deterministic - based on ip/port combination for example. > > IMO, the whole problem still looks like a network link that has severe issues (probably corrups large amount of packets which are then dropped at the neighbor node) , and traffic is load balanced over this link . > So some session flows are impacted and others are not . > > Since it seems limited to Ziggo clients it would likely be somewhere in the Ziggo network . > Something at an exchange point is a remoter possibility - depending on what (other) destinations are impacted it might just not have been noticed either . > > (some caveats : NAT in the Ziggo modem may change source port , esp with repeated tests ) > > I think that to get anything more it will need a quite senior Ziggo network engineer to investigate further. > > Best regards, Boudewijn > > > Op 24-08-2023 08:01 CEST schreef Stefan van den Oord <stefan+nlnog(a)medicinemen.eu>: > > > > > > Thanks Boudewijn! > > > > There was a lively conversation about this on #nlnog yesterday, so I forgot to respond to you. I tried changing the MTU to 1420, that didn’t make a difference. I did a packet capture as well. This was between server 192.46.232.6 and client 192.168.0.107. Command used on the server was: > > > > tcpdump -Aennvvi eth0 -w server.pcap port not 22 > > > > And on the client (because I was connected through VNC): > > > > sudo tcpdump -Aennvvi en1 -w client.pcap port not 22 and port not 5900 > > > > During this capture I did two requests (using curl) to http://192.46.232.six, the first one succeeded and the second one I aborted after half a minute. The result is here: http://192.46.232.six/client+server.pcap > > > > I lack the experience to properly analyse this. Does this contain any clues to you? > > > > -- > > Stefan van den Oord > > CTO @ Medicine Men B.V. > > > > Not in the office on Wednesdays > > > > Regulierenring 22 > > 3981 LB Bunnik > > The Netherlands > >

4 5

Re: [NLNOG] Curious problem with connections from Ziggo customers to Linode nodes in some data centers
by Sander Steffann 24 Aug '23

24 Aug '23

Hi, > Thanks Sander, > > When I’m visiting that website from my colleague’s Ziggo connection, I don’t experience any issues. So it could be unrelated. Thanks for letting me know! Sander

1 0

RIPE87: CFP, fellowship & academic grants
by Vesna Manojlovic 14 Aug '23

14 Aug '23

Dear colleagues, Here is an opportunity to bring your work to the RIPE Community: Join RIPE 87, in Rome, Italy, from 27 November to 1 December 2023. https://ripe87.ripe.net/ The RIPE NCC is giving Fellowship travel grants & academic support. Please apply, or share this announcement with others who could benefit from these opportunities. Kind regards, Vesna Manojlovic (& let's get to Rome by train!) https://forum.ripe.net/t/all-rail-roads-lead-to-rome-for-ripe87/620 ----------- RIPE Fellowship ----------- Having participants with diverse backgrounds, expertise, opinions and experiences enriches the RIPE community. With the RIPE Fellowship, we aim to create opportunities for individuals from underrepresented regions, minority backgrounds, or others who would otherwise be unable to attend without funding, to participate in the RIPE Meetings. The RIPE Fellowship covers the cost of a meeting ticket, travel and accommodation for successful candidates in the RIPE NCC service region. Apply: https://www.ripe.net/participate/forms/apply/ripe-87-fellowship/ *The application deadline is Tuesday, 11 September 2023.* More information: https://www.ripe.net/fellowship ----------- RACI ----------- RIPE Academic Cooperation Initiative (RACI) is supporting talented academics in the field of Internet technology. Successful applicants receive complimentary tickets, accommodation and travel to the meetings and the opportunity to present their research. To apply, submit a short abstract and draft slides via: https://www.ripe.net/participate/forms/apply/raci-application-form-2023/ *The application deadline is Tuesday, 11 September 2023.* More information: https://www.ripe.net/raci Subscribe to the RACI list: https://www.ripe.net/raci/mailing-list ----------- CFP ----------- And finally, if you do not qualify for these grants, you can still propose a talk or a workshop at https://ripe87.ripe.net/cfp/ RIPE 87 will be a hybrid meeting, so both in-person and remote presentations are encouraged and will be accepted. -- Senior Community Builder, RIPE NCC https://labs.ripe.net/author/becha/

1 0

IANA AS Numbers Registry Update
by David Dong 11 Aug '23

11 Aug '23

Hi, The IANA AS Numbers registry has been updated to reflect the allocation of the following blocks to the RIPE NCC: 213404-214427 Assigned by RIPE NCC 2023-08-10 214428-215451 Assigned by RIPE NCC 2023-08-10 215452-216475 Assigned by RIPE NCC 2023-08-10 You can find the registry at: https://www.iana.org/assignments/as-numbers/ The allocation was made in accordance with the Policy for Allocation of ASN Blocks to Regional Internet Registries: https://www.icann.org/resources/pages/global-policy-asn-blocks-2010-09-21-en Best regards, David Dong IANA Services Sr. Specialist

1 0

Spoofer Report for NLNOG for Jul 2023
by CAIDA Spoofer Project 08 Aug '23

08 Aug '23

In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within nld. Inferred improvements during Jul 2023: ASN Name Fixed-By 200019 AlexHost 2023-07-15 54825 PACKET 2023-07-27 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Jul 2023: ASN Name First-Spoofed Last-Spoofed 20847 PREVIDER 2018-04-17 2023-07-27 1136 KPN 2019-09-04 2023-07-10 8587 Infracom 2019-10-28 2023-07-17 207176 OPENFIBER 2020-06-12 2023-07-31 213268 2020-12-07 2023-07-28 212411 2023-03-15 2023-07-13 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=nld&no_block=1 Please send any feedback or suggestions to spoofer-info(a)caida.org

1 0