swinog April 2019

swinog@lists.swinog.ch

6 participants
5 discussions

Call for Presentations European Peering Forum 14 (EPF14) // SwiNOG

by Arnold Nipper

Dear Community This is the Call for Presentations European Peering Forum 14 (EPF14) AMS-IX, DE-CIX, LINX and Netnod are happy to host the 14th European Peering Forum (EPF) in Tallinn, Estonia from the 16th - 18th September 2019. The event will welcome up to 300 peering managers and coordinators from networks connected to the host Internet exchanges. Besides an interesting topical agenda, the three-day event accommodates room for attendees to meet on a one-to-one basis to discuss bilateral peering business opportunities. The programme committee will be looking for presentations and lightning talks related to peering and technical topics of interconnection. Your presentation should address * Interconnection Automation * Regional Peering * Interconnection / Peering Internet Governance and Regulatory Topics * Economic and Product Trends * Peering / Interconnection strategies * Interesting findings about Peering / Interconnection * 400GE and beyond Submissions =========== Presentations must be of a non-commercial nature. Product or marketing heavy talks are strongly discouraged. Submissions of presentations should be made to the programme committee <epf-pc(a)peering-forum.eu>. Please include: * Author's name and e-mail address * Presentation title * Abstract * Slides (if available) * Time requested (max. 30 minutes incl. Q&A) Deadlines ========= Presentation Abstract Deadline 15/07/2019 12:00 UTC Final Selection of Speakers 26/07/2019 Presentation Slides Submission Deadline 02/09/2019 12:00 UTC More information about the event and other activities around EPF14 may be found at * https://peering-forum.eu/ * https://www.facebook.com/groups/1486607564933665/ Best regards Arnold -- Arnold Nipper email: arnold(a)nipper.de mobile: +49 172 2650958

3 years, 8 months

Strange NTP packet loss

by Stefan Brand

Hi everyone, We[1] are running some public NTP servers that are included in the NTP Pool[2]. In recent months we've had some issues with our servers being marked as unavailable by the monitoring host that tracks availability for the pool. The logs from the NTP pool website showed high packet loss. However we could not see any issues on our side and pings from the looking glass closest to the monitoring host didn't show any packet loss at all. After quite some debugging we realized that the packet loss only occurs for NTP packets via one of our transit providers, namely Liberty Global (AS6830). We queried their support, our theory being that they're trying to do some sort of DDoS protection for NTP reflection attacks. However they aren't aware of anything like this and also couldn't figure out why this is happening. So I was wondering, has anyone else encountered this issue or something similar? We worked around the issues by routing the traffic around AS6830 but this still bothers me somehow. Kind regards and see you soon at Swinog #35, Stefan [1] https://nine.ch [2] https://www.ntppool.org/user/ninech

3 years, 10 months

### SwiNOG#35 - May 8th - Agenda ###

by Simon Ryf

Dear SwiNOGers, I’m happy to present the final agenda of SwiNOG#35 If you have not registered yet, please do it now and let your friends and colleagues know ;-) 08:15 | Registration, Coffee & Gipfeli 09:15 | Welcome, Agenda | Simon Ryf (SwiNOG) 09:20 | How to grow IPv6 only services | Nico Schottelius (ungleich glarus ag) As an IPv6 first Data Center, we are looking at IPv6 from a technological and marketing perspective. In this talk I will show our findings in how users reacted towards IPv6 (only) offers, which challenges we encountered on this path and which strategies aid in building and selling IPv6 only services. IPv6 adoption is often compared to the chicken or the egg problem. At the end of the talk I will present you with 2 (strongly biased) solutions to it. 09:45 | Network Telemetry and Big Data - Part 1 | Thomas Graf, Paolo Lucente & Zongren Liu (Swisscom) This presentation with demo shows the collaboration with Swisscom to advance Network Telemetry and Big Data technologies in two parts. Swisscom explains, from a Service Provider viewpoint, the challenges in virtualization and why Swisscom believes this is a key topic to gain visibility in their networks and improve quality. This includes flow aggregation, BMP and Streaming Telemetry for forwarding-plane, control-plane and topology/device metrics. We will underline the importance of schema conversion and registration and the current challenges to align Big Data (data processing, storage and analytics) and Network Telemetry (data collection). We are going to demo flow aggregation and streaming telemetry. Paolo Lucente is going to present the open source project pmacct. Its versatility to cover flow technologies such as IPFIX, BMP and last but not least streaming telemetry metrics where Paolo and Swissscom co-developing. 10:30 | Coffee Break 11:00 | Network Telemetry and Big Data - Part 2 | Christian Kuster (Huawei) Huawei is going to present the new Swisscom Broadband network Sultan, what part Network Telemetry and Big Data plays there and how Huawei supports Swisscom with their innovations and close collaboration. 11:45 | RIPE RPKI | Massimiliano Stucchi (RIPE) tbd 12:05 | SwissIX Update | Manuel Schweizer (SwissIX) Traditional SwissIX update 12:15 | Lunch 13:45 | The State of Internet Security: 2019 | Rayhaan Jaufeerally There are a wide range of technologies that have been developed to secure core Internet infrastructure, however not all of them have yet been widely deployed to reap their benefits. In this presentation we present a selection of these technologies, investigate what security properties they will provide given sufficient adoption, and look at the current deployment status. Specifically we focus on three core areas: interdomain routing, Public Key Infrastructure, and the Domain Name System. In interdomain routing we look at mechanisms to validate routing control protocol messages (Resource Public Key Infrastructure, and Border Gateway Protocol Security), in PKI we focus on the Certificate Authority ecosystem and Certificate Transparency, and for DNS security we look at DNSSEC, and DNS over HTTPS. 14:15 | machine Learning in action - L7 Behavioral Analysis for DDoS detection | Carine Polaillon (F5) tbd 14:40 | The State of DNSSEC Implementation in Switzerland | Michael Hausding (SWITCH) DNSSEC, the DNS Security Extensions was introduced more than 10 years ago. The adoption of DNSSEC in Switzerland was slow for the last 10 years, but gained some momentum in the last 24 months. What is the reason behind a growing number of DNSSEC signed domain names and more ASNs having validating resolvers in Switzerland? Will the recommendation of ICANN for DNSSEC after the recent attacks help with the implementation of DNSSEC in Switzerland? What can hosters and ISPs do to secure the basic DNS infrastructure in Switzerland. 15:05 | Everything is a Freaking DNS problem - dnsdist to the rescue | Dominic Lüchinger (cyon GmbH) DNS plays a crucial part in any network infrastructure. dnsdist, a DoS- and abuse-aware loadbalancer, can help you mitigate the risk of a downtime that occur during maintenance work, attacks and configuration errors. We share our experience putting dnsdist in front of our nameservers and resolvers. With the help of the many built-in stats, we were able to improve the performance even further. 15:35 | Coffee Break 16:05 | Managing sleep with a resilient DNS infrastructure | Jeroen Massar (Quickline AG) The talk will discuss deploying both an Authoritive and Recursive DNS infrastructure that is resilient against outages of network (DoS, misconfiguration), datacenter and people with the ultimate goal of very rarely having ops folks awake during the night. We'll discuss the combination of various open source projects in combination with the techniques that achieve this goal and how we have deployed the setups without anybody noticing. 16:35 | Buffer Sizing Revisited | Simon Leinen (SWITCH) Routers and switches need buffers to accommodate traffic bursts. But how big should those buffers be? The elders recommended RTT*bottleneck bandwidth[Villamizar1994], but more recent work suggests we can get away with much less. We will look at economic and performance trade-offs of small vs. big buffers in light of recent trends in forwarding hardware and transport protocol evolution. 17:00 | grey energy used by data traffic | Kordian Caplazi The goal of my thesis is to calculate the grey energy imported and exported in Switzerland, which is generated by the data traffic of the internet. Today it is already done for consumer products such as clothes or cars, but not for the internet. For the internet our approach is to map the total traffic and its energy consumption along the route. A more detailed view on the energy consumption and therefore the greenhouse gas production will be achieved by splitting the traffic by country and its sources for energy production. 17:05 | How not to integrate Access CPEs | Pascal Gloor (Quickline AG) you'll see ;-) 17:15 | Roundup | Simon Ryf (SwiNOG) 17:20 | Social Event Many thanks to your sponsors for this event Huawei & F5 Hope to see you on the 8th of May Simon SwiNOG

3 years, 11 months

ipv4 for rent / sale

by sh＠shgh.biz

Anybody looking for ipv4? We have some unused blocks: /21 /22 /23 /23 PI, RIPE Cheers Sebastian

3 years, 11 months

Re: [swinog] SBB.ch / IPv6 MTU / fragmentation problem

by Müller Urs (IT-OM-SDP-SDN)

Hello Nico / everybody Yesterday, I was contacted by Silvia (and others) about that task. I was then not registered with that list. Let me introduce me shortly. My name is Urs Mueller. I am working together with my colleague Hans-Peter at SBB in the IT department. We are the stack owners of network & network security on behalf of the IT department. Our network is built and operated by our colleagues from SBB Telecom. IPv6 is a goal we tried to reach since several years, at least since I attended an IPv6 congress in Hannover many years ago. We were struggling with convincing the management to fund projects until last year. The current solution is more or less a workaround and this year, we are trying to achieve a direct connection to our webservers. Currently, there are seeing around 2 Mbit/s incoming and 20 Mbit/s outgoing on IPv6. This is approx. 20% of the total traffic, we are actually handling for our webserver through regular http/s from browsers. This year, we will give more effort on the subject. But our network is quite complex and grown over the years. So there is no way to "just put a box in between and some cables" ;-) If you Nico, would like to contact me about your thesis, feel free. Perhaps we can arrange something. Regards, Urs -----Ursprüngliche Nachricht----- Von: swinog-bounces(a)lists.swinog.ch <swinog-bounces(a)lists.swinog.ch> Im Auftrag von Nico Schottelius Gesendet: Dienstag, 12. März 2019 15:55 An: Silvia Hagen <silvia.hagen(a)sunny.ch> Cc: Nico Schottelius <nico-swinog-2(a)schottelius.org>; swinog(a)lists.swinog.ch Betreff: Re: [swinog] SBB.ch / IPv6 MTU / fragmentation problem Hey Silvia, thanks a lot for the insight! I did not expect this answer when asking this morning. I am currently doing my master thesis [0] about IPv6 in fully programmable P4 switches (my hardware platform will be Barefoot Tofino in the end) - I assume this might be rather interesting for SBB, as it potentially can solve all problems [tm] in the network. Also I hear the 6.5 TBit/s switches are not that crazy expensive anymore. If you could get me in touch with the right people at SBB, this would be very interesting to talk about their network. Best, Nico [0] https://gitlab.ethz.ch/nicosc/master-thesis Silvia Hagen <silvia.hagen(a)sunny.ch> writes: > Hi guys > > Here's some info from SBB (I was working with them and just spoke with them today). > > . They are aware of the problem. > . The problem only happens when someone uses smaller packet sizes (often when using some tunnelling techniques). > . Currently the webserver is in an IPv4 zone, the Internet router is a Cisco box which does 64 Translation. The packets go through an F5 LB to reach the webserver. > . When the packets go out and the Cisco box asks for fragmention, it sends the ICMP packet to the webserver. The F5 box has a bug, something with the checksum goes wrong and the F5 discards the ICMP packet. > . They have had a neverending incident with F5 and F5 does not seem to be able to fix that. SBB has given up on this incident. > > The plan: > . SBB is currently enabling IPv6 on the routing layer, plan to be accomplished by summer 2019. > . Next step on the plan is to enable v6 out to the datacenter, with priority on the webserver zone. So with that the problems should go away. > > SBB was attending the last swinog event in Switzerland. They will also come again and they offered to have a talk if desired. I can connect to the right person if you are interested. > > Thanks, Silvia > > > -----Ursprüngliche Nachricht----- > Von: swinog-bounces(a)lists.swinog.ch > [mailto:swinog-bounces@lists.swinog.ch] Im Auftrag von Nico > Schottelius > Gesendet: Dienstag, 12. März 2019 10:33 > An: swinog(a)lists.swinog.ch > Betreff: [swinog] SBB.ch / IPv6 MTU / fragmentation problem > > > Good morning, > > is anyone from sbb.ch reading here? > > https://sbb.ch does not load on IPv6 for us. > It seems that packets > 1420 bytes are dropped inside the SBB network, > > Local PMTU / fragmentation seems to work, my local outgoing MTU is 1420. MTR below. > > Best, > > Nico > > > [10:23] line:~% mtr -w -c1 -s 1500 sbb.ch > Start: 2019-03-12T10:24:17+0100 > HOST: line Loss% Snt Last Avg Best Wrst StDev > 1.|-- 2a0a:e5c1:111:111::42 0.0% 1 11.2 11.2 11.2 11.2 0.0 > 2.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 3.|-- 2a0a:e5c0:2:12::7 0.0% 1 69.8 69.8 69.8 69.8 0.0 > 4.|-- 2a0a:e5c0:1:1::9 0.0% 1 74.3 74.3 74.3 74.3 0.0 > 5.|-- 2001:1620:20e6::1 0.0% 1 69.4 69.4 69.4 69.4 0.0 > 6.|-- r1zrh2.core.init7.net 0.0% 1 69.1 69.1 69.1 69.1 0.0 > 7.|-- r1olt2.core.init7.net 0.0% 1 58.0 58.0 58.0 58.0 0.0 > 8.|-- r1brn1.core.init7.net 0.0% 1 62.8 62.8 62.8 62.8 0.0 > 9.|-- r2brn1.core.init7.net 0.0% 1 65.4 65.4 65.4 65.4 0.0 > 10.|-- r1epe1.core.init7.net 0.0% 1 75.2 75.2 75.2 75.2 0.0 > 11.|-- r1qls1.core.init7.net 0.0% 1 78.4 78.4 78.4 78.4 0.0 > 12.|-- r1gva3.core.init7.net 0.0% 1 81.0 81.0 81.0 81.0 0.0 > 13.|-- gw-sunrise.init7.net 0.0% 1 64.4 64.4 64.4 64.4 0.0 > 14.|-- 2001:1700:1:7:120::2 0.0% 1 84.4 84.4 84.4 84.4 0.0 > 15.|-- 2001:1700:4d00:2::2 0.0% 1 81.3 81.3 81.3 81.3 0.0 > 16.|-- 2a00:4bc0:ffff:ff00::1d 0.0% 1 67.0 67.0 67.0 67.0 0.0 > 17.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > [10:24] line:~% mtr -w -c1 -s 1400 sbb.ch > Start: 2019-03-12T10:24:35+0100 > HOST: line Loss% Snt Last Avg Best Wrst StDev > 1.|-- 2a0a:e5c1:111:111::42 0.0% 1 3.2 3.2 3.2 3.2 0.0 > 2.|-- 2a0a:e5c1:100::1 0.0% 1 69.0 69.0 69.0 69.0 0.0 > 3.|-- 2a0a:e5c0:2:12::7 0.0% 1 74.7 74.7 74.7 74.7 0.0 > 4.|-- 2a0a:e5c0:1:1::9 0.0% 1 69.9 69.9 69.9 69.9 0.0 > 5.|-- 2001:1620:20e6::1 0.0% 1 60.5 60.5 60.5 60.5 0.0 > 6.|-- r1zrh2.core.init7.net 0.0% 1 75.3 75.3 75.3 75.3 0.0 > 7.|-- r1olt2.core.init7.net 0.0% 1 70.7 70.7 70.7 70.7 0.0 > 8.|-- r1brn1.core.init7.net 0.0% 1 69.1 69.1 69.1 69.1 0.0 > 9.|-- r2brn1.core.init7.net 0.0% 1 54.6 54.6 54.6 54.6 0.0 > 10.|-- r1epe1.core.init7.net 0.0% 1 75.9 75.9 75.9 75.9 0.0 > 11.|-- r1qls1.core.init7.net 0.0% 1 78.8 78.8 78.8 78.8 0.0 > 12.|-- r1gva3.core.init7.net 0.0% 1 79.8 79.8 79.8 79.8 0.0 > 13.|-- gw-sunrise.init7.net 0.0% 1 69.9 69.9 69.9 69.9 0.0 > 14.|-- 2001:1700:1:7:120::2 0.0% 1 77.5 77.5 77.5 77.5 0.0 > 15.|-- 2001:1700:4d00:2::2 0.0% 1 59.3 59.3 59.3 59.3 0.0 > 16.|-- 2a00:4bc0:ffff:ff00::1d 0.0% 1 70.1 70.1 70.1 70.1 0.0 > 17.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 18.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 19.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 20.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 21.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 22.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 23.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 24.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 25.|-- 2a00:4bc0:ffff:ffff::c296:f58e 0.0% 1 58.3 58.3 58.3 58.3 0.0 > [10:24] line:~% > > [10:25] line:~% mtr -w -c1 -s 1420 sbb.ch > Start: 2019-03-12T10:25:44+0100 > HOST: line Loss% Snt Last Avg Best Wrst StDev > 1.|-- 2a0a:e5c1:111:111::42 0.0% 1 16.3 16.3 16.3 16.3 0.0 > 2.|-- 2a0a:e5c1:100::1 0.0% 1 77.0 77.0 77.0 77.0 0.0 > 3.|-- 2a0a:e5c0:2:12::7 0.0% 1 67.0 67.0 67.0 67.0 0.0 > 4.|-- 2a0a:e5c0:1:1::9 0.0% 1 66.7 66.7 66.7 66.7 0.0 > 5.|-- 2001:1620:20e6::1 0.0% 1 78.8 78.8 78.8 78.8 0.0 > 6.|-- r1zrh2.core.init7.net 0.0% 1 64.5 64.5 64.5 64.5 0.0 > 7.|-- r1olt2.core.init7.net 0.0% 1 68.3 68.3 68.3 68.3 0.0 > 8.|-- r1brn1.core.init7.net 0.0% 1 74.9 74.9 74.9 74.9 0.0 > 9.|-- r2brn1.core.init7.net 0.0% 1 73.6 73.6 73.6 73.6 0.0 > 10.|-- r1epe1.core.init7.net 0.0% 1 62.2 62.2 62.2 62.2 0.0 > 11.|-- r1qls1.core.init7.net 0.0% 1 74.3 74.3 74.3 74.3 0.0 > 12.|-- r1gva3.core.init7.net 0.0% 1 63.6 63.6 63.6 63.6 0.0 > 13.|-- gw-sunrise.init7.net 0.0% 1 69.1 69.1 69.1 69.1 0.0 > 14.|-- 2001:1700:1:7:120::2 0.0% 1 77.4 77.4 77.4 77.4 0.0 > 15.|-- 2001:1700:4d00:2::2 0.0% 1 78.8 78.8 78.8 78.8 0.0 > 16.|-- 2a00:4bc0:ffff:ff00::1d 0.0% 1 75.7 75.7 75.7 75.7 0.0 > 17.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 18.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 19.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 20.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 21.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 22.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 23.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 24.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 25.|-- 2a00:4bc0:ffff:ffff::c296:f58e 0.0% 1 83.8 83.8 83.8 83.8 0.0 > [10:25] line:~% mtr -w -c1 -s 1430 sbb.ch > Start: 2019-03-12T10:25:55+0100 > HOST: line Loss% Snt Last Avg Best Wrst StDev > 1.|-- 2a0a:e5c1:111:111::42 0.0% 1 7.3 7.3 7.3 7.3 0.0 > 2.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > 3.|-- 2a0a:e5c0:2:12::7 0.0% 1 60.4 60.4 60.4 60.4 0.0 > 4.|-- 2a0a:e5c0:1:1::9 0.0% 1 61.9 61.9 61.9 61.9 0.0 > 5.|-- 2001:1620:20e6::1 0.0% 1 72.2 72.2 72.2 72.2 0.0 > 6.|-- r1zrh2.core.init7.net 0.0% 1 65.2 65.2 65.2 65.2 0.0 > 7.|-- r1olt2.core.init7.net 0.0% 1 64.9 64.9 64.9 64.9 0.0 > 8.|-- r1brn1.core.init7.net 0.0% 1 64.9 64.9 64.9 64.9 0.0 > 9.|-- r2brn1.core.init7.net 0.0% 1 71.7 71.7 71.7 71.7 0.0 > 10.|-- r1epe1.core.init7.net 0.0% 1 64.4 64.4 64.4 64.4 0.0 > 11.|-- r1qls1.core.init7.net 0.0% 1 63.2 63.2 63.2 63.2 0.0 > 12.|-- r1gva3.core.init7.net 0.0% 1 77.9 77.9 77.9 77.9 0.0 > 13.|-- gw-sunrise.init7.net 0.0% 1 64.5 64.5 64.5 64.5 0.0 > 14.|-- 2001:1700:1:7:120::2 0.0% 1 63.5 63.5 63.5 63.5 0.0 > 15.|-- 2001:1700:4d00:2::2 0.0% 1 81.7 81.7 81.7 81.7 0.0 > 16.|-- 2a00:4bc0:ffff:ff00::1d 0.0% 1 74.4 74.4 74.4 74.4 0.0 > 17.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 > [10:26] line:~% > > > icmp6, frag works locally: > > 10:29:44.919328 IP6 2a0a:e5c1:111:111:3185:e802:6548:658c > > 2a00:4bc0:ffff:ffff::c296:f58e: frag (0|1368) ICMP6, echo request, seq > 33000, length 1368 > 10:29:44.919368 IP6 2a0a:e5c1:111:111:3185:e802:6548:658c > > 2a00:4bc0:ffff:ffff::c296:f58e: frag (1368|92) -- Your Swiss, Open Source and IPv6 Virtual Machine. Now on www.datacenterlight.ch. _______________________________________________ swinog mailing list swinog(a)lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

3 years, 11 months

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

swinog April 2019