- NLNOG - mailman3.nlnog.net

Use of NLNOG RING nodes on HE's supertraceroute tool
by Teun Vink 19 Oct '23

19 Oct '23

Hi everyone, In the last couple of days, NLNOG RING admins and the NLNOG board have received a number of questions about the new Hurricane Electric supertraceroute tool (hosted on bgp.he.net) using NLNOG RING nodes as a datasource. To our disappointment, Hurricane Electric has not asked permission for or even announced the use of the NLNOG RING for this purpose before releasing the tool. A number of RING node owners have indicated that they're not happy with their node being publicly accessible for this purpose, on a website hosted by a third party. This conflicts with the philosophy that the RING is built on mutual trust and managed as a community. As NLNOG Board, we understand these concerns and have requested Hurricane Electric to stop using NLNOG RING nodes this way. In addition, the SSH keys identified as used for this purpose will be disabled by NLNOG RING admins. In general, NLNOG encourages people to use the NLNOG RING to provide services for the good of the internet and especially RING owners. The way this was done by Hurricane Electric violated the trust on which the RING is built and the community spirit. We will try to see if there's a way we can make an arrangement with Hurricane Electric to enable use of RING nodes in a way that meets expectations of RING node owners, for example by using an opt-in model. Please don't hesistate to contact the board or the RING admin team if you have any questions on this subject. On behalf of the NLNOG Board, Teun Vink

2 1

DENOG15 in Berlin (Workshop registration open)
by Stefan Funke 18 Oct '23

18 Oct '23

Good Morning NLNOG! DENOG15 (19.-21.11.2023) in Berlin will be held in the Estrel Congress Center (Sonnenallee 225, 12057 Berlin). Like every year, we are happy to invite all our neighboring friends and colleagues from the NLNOG region! The agenda is fixed now, and we already opened workshop registrations. Since there is limited space for all workshops, please register now to have a spot! https://www.denog.de/de/meetings/denog15/workshop_registration.html Ticket sales end on October 28th. If you haven't ordered your ticket until now, please do so at: https://www.denog.de/de/meetings/denog15/tickets.html We are excited about DENOG15 in November and look forward to seeing you all again. For the Event Orga, Stefan

1 0

Spoofer Report for NLNOG for Sep 2023
by CAIDA Spoofer Project 08 Oct '23

08 Oct '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 Sep 2023: ASN Name Fixed-By 212370 2023-09-15 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Sep 2023: ASN Name First-Spoofed Last-Spoofed 20847 PREVIDER 2018-04-17 2023-09-28 213268 2020-12-07 2023-09-24 207176 OPENFIBER 2022-09-30 2023-09-27 12414 NL-SOLCON 2023-05-22 2023-09-04 28685 ASN-ROUTIT 2023-08-23 2023-09-28 61254 ITSUPPORT 2023-09-14 2023-09-29 64404 EVENTINFRA 2023-09-26 2023-09-26 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

[Jobs] Leiter*in Business Development/Geschäftsstelle (80–100%) // SwissIX
by Arnold Nipper 15 Sep '23

15 Sep '23

SwissIX zoekt iemand met BizDev ervaring die weet wat een IXP is. Jij kent zeker iemand over zes hoeken heen 😄 Hier is mijn bericht op LinkedIn [0]. Voel je vrij om het te delen! Hartelijke groeten Arnold [0] https://www.linkedin.com/posts/arnoldnipper_leiterin-business-developmentge… -- Keep calm, keep distance, keep connected! Arnold Nipper email: arnold(a)nipper.de mobile: +49 172 2650958

1 0

unable to use ns1/2-dedi0010.zxcs.nl, ns1/2.superserver07.zxcs.nl
by Thomas Mieslinger 12 Sep '23

12 Sep '23

Hi, anyone around here from zxcs.nl or vimexx.nl? My customers complain that they can not sent emails to npsdriven.com or watersnip.nl. My recursor source addresses are 2607:f1c0:5c0:53::/64 2607:f1c0:5c1:53::/64 2001:8d8:5c0:453::/64 2001:8d8:5c1:453::/64 2001:ba0:5c0::/64 2a00:da00:5c0::/64 2a00:da00:5c0:3::/64 2a00:da00:5c0:4::/64 74.208.114.128/26 74.208.114.192/26 77.68.65.64/26 82.165.226.0/26 82.165.226.64/26 88.208.254.128/26 82.223.158.0/26 213.171.202.197/27 please remove firewall drop rules or low hashlimits (<50 qps) for the listed prefixes on your gear to allow your customers to communicate with my customers. I run the DNS for IONOS (incl. arsys, fasthosts, home.pl) 1&1, gmx.net, mail.com, web.de. (>100M email accounts) In case of any problems please contact abuse(a)ionos.com first. The emails sent there are read and reacted to. Cheers Thomas

2 3

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

08 Sep '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 Aug 2023: ASN Name Fixed-By 213268 2023-08-03 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Aug 2023: ASN Name First-Spoofed Last-Spoofed 20847 PREVIDER 2018-04-17 2023-08-31 8587 Infracom 2019-10-28 2023-08-28 207176 OPENFIBER 2020-06-12 2023-08-31 213268 2020-12-07 2023-08-31 28685 ASN-ROUTIT 2023-08-23 2023-08-30 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

NLNOG Day 2023 is SOLD OUT!
by Teun Vink 08 Sep '23

08 Sep '23

Hallo allemaal, hi everyone! (English text can be found below) Inmiddels zijn alle beschikbare kaarten voor NLNOG Day 2023 vergeven. Mooi om te zien dat er zoveel interesse in ons event is! Omdat er mensen zijn die naast een kaart gegrepen hebben willen we iedereen die een kaartje heeft maar er niet bij kan zijn verzoeken om het ticket zo snel mogelijk te annuleren, zodat anderen een kans krijgen te komen. Dit kan via de Eventbrite pagina. En voor iedereen die naast een ticket gegrepen heeft geldt natuurlijk: er is een livestream beschikbaar en alle presentaties worden opgenomen. All available tickets for NLNOG Day 2023 have been reserved. It’s nice to see so many of you are interested in visiting our event! Of course, some people are now missing out, so if you have a ticket but are unable to visit, please cancel your ticket via the Eventbrite website so we can give it to someone else. And if you were unable to get a ticket please keep in mind that we will be providing a livestream of the event and all presentations will be recorded. Tot snel, see you soon! On behalf of the NLNOG Day 2023 crew, Teun

1 0

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 8

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