1.7 denog18 2026-11-15 2026-11-17 3 00:05 https://cfp.denog.de Europe/Berlin Workshop Room #1# Workshop 2026-11-15T11:00:00+01:00 11:00 06:00 Workshop about the basics of BGP. Topics include: * Prefixes and Autonomous Systems * Why you also need an IGP (like OSPF, IS-IS) * iBGP: BGP within your network * eBGP: Talking to your neighbours * Multihoming and Peering * BGP Best Path Selection Bonus-Topics, if time permits: * BGP Communities * BGP Security Lab experiments will be done using FRRouting, so participants do need a laptop. No special software is needed, but make sure your web-browser can access a HTTPS page on ports 7002-7099. denog18-7-bgp-for-networks-who-peer Wolfgang Tremmel en true https://cfp.denog.de/denog18/talk/M9H8P7/ https://cfp.denog.de/denog18/talk/M9H8P7/feedback/ Workshop Room #2# Workshop 2026-11-15T11:00:00+01:00 11:00 06:00 Want to perform the bgp handshake in real life based on a realistic topology? We got you covered ... in this workshop for intermediates we will dive into some network basics of bgp driven networks and also explore route filtering best practices (mainly for the DfZ = default free zone). After some theory every attendee will receive one network node to configure. The fellow participants will be your peers. You will depend on the peers to reach your goals. Teams work together in small groups. One group jointly manages an AS consisting of 3 routers and a customer downlink router. Troubleshooting takes place across groups in order to verify the corresponding availability within the lab topology. Warning: You will have to socialise with the peers around you! Topics Covered: - Introduction into Internet/Routing Hierarchy - Routing/Announcement Basics/Strategy - Route Filtering - Lab Introduction Pre-requisites: - Network Fundamentals, user level UNIX and maybe some system administration, - Some use of network design preferably TCP/IP-based is also helpful. - Dynamic routing Fundamentals (BGP, ISIS/OSPF is a plus) - Participants must have technical hands on experience of routers. Some experience with EOS or a comparable CLI will be helpful. denog18-11-bgp-workshop-5-0 Vincentz PetzholtzPeter SieversSebastian GrafBenedikt Heuser en true https://cfp.denog.de/denog18/talk/TEXXSQ/ https://cfp.denog.de/denog18/talk/TEXXSQ/feedback/ Workshop Room #3# Workshop 2026-11-15T11:00:00+01:00 11:00 06:00 How hard can it be to NOT use wires? Sometimes pretty hard! But it doesn't need to be! In this workshop you will learn what needs to be done to have a great wireless network. And how you can achieve that without getting bankrupt. denog18-10-poor-man-great-wifi Ulf Weikert en For the better half of a decade I have been doing professional work around wifi. WLAN on a campus or office complex, logistic warehouses, hospitals etc. have been my bread and butter for more than 5 years. With a change in employment my responsibilities shifted, but the passion never died. And for the last couple of years I helped with wifi deployments on smaller gigs like Nordlicht Demoparty, medium festivals like Stemweder Open Air and bigger events like Chaos Communication Congress or WHY2025. In this workshop I will give an overview and introduction of what is possible with today's free (and maybe open source) tools for getting great reliable wifi at home. My goal for the full day workshop is for you to; - being able to differentiate between good wifi and bad wifi - being able to articulate your requirements for your own wifi environment - being able to better put the big players in the market into context - being able to successfully implement small projects (e.g. wifi at your or your friends home) - being able to better work as an intermediary for wifi consultants in case your project got bigger The main focus will be on practical applications. With a short sidequest on the theoretical side. While all of this is applicable in a broader context, we will NOT dive deep into every single nuance of wifi tuning. The tradeoff in this workshop will be to invest less of hard cash for a bit more of personal work hours. true https://cfp.denog.de/denog18/talk/ASK3LK/ https://cfp.denog.de/denog18/talk/ASK3LK/feedback/ Workshop Room #4# Workshop 2026-11-15T11:00:00+01:00 11:00 05:00 This workshop gives an overview about modern management of OpenPGP Keys. Online documentation suggests that you have an offline key and subkeys, the latter preferably on a hardware device. But there is hardly one place where there are hands-on instructions to create those. This workshop intends to have participants aquire that experience. denog18-75-openpgp-key-management-hopefully-done-right Marc Haber en This workshop will not give more than a "you know that already" appraoch to public key cryptography. It will begin with OpenPGP basics. The speaker is a Debian Developer, so his main application of OpenPGP is signing things, but of course encryption will be handled as well. The practical exercises will be done on Linux. The participants will get an overview about what are best practises regarding OpenPGP keys: - an offline (certification only) primary key that will never see the internet and - subkeys (signature, encryption, authentication) that will be created on the offline system and then transfered to a OpenPGP Smart Card (such as a Yubikey). - how to build and use an offline, immutable Linux system (based on Debian Live on a Raspberry Pi 4) - Introduction to OpenPGP Smart Cards The workshop will also suggest workarounds for the numerous gotchas the speaker experienced on his own journey to OpenPGP best practises. Af the end of the talk, participants will have a primary key with subkeys and will have had the experience of exchanging keys, signatures and encrypted messages via a pad. It is suggested to throw away all key material after the workshop and to start over again in a quiet place with lots of concentration about doing things right. true https://cfp.denog.de/denog18/talk/CEXYQV/ https://cfp.denog.de/denog18/talk/CEXYQV/feedback/ Workshop Room #5# Workshop 2026-11-15T10:30:00+01:00 10:30 02:00 Modern optics incorporate WDM technology out of the box, 100G-LR4, 100G-CWDM4 and other variants are common to everyone. But what does that mean and how does CWDM and DWDM work, if not already in a box. denog18-81-wdm-basics Nicola 'nicoduck' von Thadden en I'll give an overview about different WDM types, channels and hardware. I'll also bring some devices to show, but I currently do not think it will be a hand-on session on some switches (that could change, if there is a benefit, which I currently do not see). true https://cfp.denog.de/denog18/talk/PJYNNC/ https://cfp.denog.de/denog18/talk/PJYNNC/feedback/ Workshop Room #5# Workshop 2026-11-15T13:30:00+01:00 13:30 03:30 How can network infrastructure be described centrally, versioned consistently, and deployed automatically? In this hands-on introductory workshop, participants build and automate a small service provider network using NetBox, Git, Ansible, and a virtual lab environment. Working in small teams, they use **NetBox** as the Source of Truth for devices, interfaces, IP addresses, and routing information. The structured data is then transformed into network configurations using Jinja2 templates and deployed through an automated workflow. The workshop focuses on the practical interaction between network data, templates, version control, and automation. Participants will learn about network data modeling in NetBox, create and modify existing data and templates, execute the deployment process, and validate the resulting configurations. The workshop is explicitly designed not only for participants who already have experience with NetBox or network automation, but also for curious network engineers who want to gain their first practical experience in a guided and approachable environment. It provides an opportunity to explore the concepts hands-on, understand how the individual components interact, and experience a complete automation workflow without having to build the underlying lab platform themselves. After this workshop, participants should be able to explain the role of a Source of Truth within a network automation workflow, model and maintain basic network data in NetBox, understand how Git, Jinja2, and Ansible work together. Most importantly, they will leave with a practical understanding of how Source-of-Truth-driven automation can provide a foundation for more reproducible, consistent, and scalable network operations in their own environments. This workshop is not a comprehensive NetBox, Ansible, Jinja2 or Python training, nor does it present a production-ready automation platform. Instead, it offers a guided introduction to the core principles of Source-of-Truth-driven network automation and demonstrates how the individual components work together in a simplified end-to-end workflow. #### Topics Covered: - Introduction to Network Source of Truth - Netbox Data Model - Possible Deployment Pipelines - Jinja2 configuration templating #### Prerequisits: - No previous experience with NetBox or network automation is required. - No extensive programming experience is required. - Basic knowledge of IP networking and routing is recommended. The lab environment and all required tools are provided. Participents are expected to bring - Their own laptop with a working Browser and ssh client denog18-60-from-netbox-to-network-a-hands-on-isp-automation-workshop-for-beginners Michael FischerJohannes Störmer en true https://cfp.denog.de/denog18/talk/KGB9PT/ https://cfp.denog.de/denog18/talk/KGB9PT/feedback/ Workshop Room #6# Workshop 2026-11-15T11:00:00+01:00 11:00 05:00 Dieser praxisorientierte Workshop vermittelt den Aufbau, die Installation und die Qualifizierung moderner passiver Netzwerkinfrastrukturen in einer realitätsnahen Datacenter-Umgebung. Die Teilnehmer planen, installieren und prüfen eigenständig eine strukturierte Verkabelung. Vom mechanischen Aufbau über das Spleissen und Patchen bis hin zur professionellen Abnahmemessung werden alle wesentlichen Arbeitsschritte praxisnah durchgeführt. Ziel des Workshops ist es, den Teilnehmern nicht nur theoretisches Wissen zu vermitteln, sondern ihnen die Möglichkeit zu geben, typische Aufgaben aus dem Rechenzentrums-Umfeld selbstständig durchzuführen sowie moderne Mess- und Prüftechnologien in realen Anwendungsszenarien kennenzulernen. denog18-91-build-it-test-it-fix-it-datacenter-verkabelung-inklusive-messung-und-fehlersuche Marc RühlJuergen RummelsbergerRobin Bartelsen en Workshop-Konzept Im Mittelpunkt des Workshops steht der eigenständige Aufbau eines passiven Netzwerks in einer realitätsnahen Datacenter-Umgebung. Die Teilnehmer übernehmen typische Aufgaben aus den Bereichen Spleissen, Verkabelung und Installation. Nach dem erfolgreichen Aufbau werden sämtliche Verbindungen professionell geprüft, analysiert und dokumentiert. Dabei führen die Teilnehmer typische Abnahme-, Qualifizierungs- und Fehlersuchmaßnahmen durch, wie sie im täglichen Betrieb moderner Rechenzentren und Unternehmensnetzwerke erforderlich sind. Gemeinsam mit ConnectCom und EXFO stellen wir die erforderliche Infrastruktur, moderne Messtechnik sowie das Expertenwissen für einen erfolgreichen Infrastrukturaufbau bereit. Die Umsetzung erfolgt anhand eines vorgegebenen Verkabelungs- und Dokumentationskonzepts. Die praktischen Aufgaben umfassen unter anderem: • Spleissen von Glasfaserverbindungen in Patchfeldern • Anschließen von Netzwerkkabeln • Montage von Patchfeldern und Infrastrukturkomponenten • Patchen von Glasfaser- und Kupferverbindungen • Aufbau einer strukturierten passiven Verkabelung • Inspektion und Bewertung von Steckverbindungen • Dämpfungsmessungen der installierten Strecken • Durchführung von IOLM-Messungen zur Streckenanalyse und Fehlerlokalisierung • Systematische Fehlersuche und Fehlerbehebung • Dokumentation der aufgebauten Infrastruktur und der Messergebnisse Mehrwert für die Teilnehmer • Praxisnahe Hands-on-Erfahrung statt reiner Theorie • Eigenständiger Aufbau einer passiven Netzwerkinfrastruktur • Kennenlernen aktueller Glasfaser- und Messtechnik • Durchführung realer Aufbau-, Prüf- und Abnahmeverfahren • Systematische Fehlersuche, Analyse und Fehlerbehebung • Erfahrungs- und Wissensaustausch mit Experten • Verständnis für Planung, Installation, Qualifizierung und Dokumentation moderner Netzwerk- und Datacenter-Infrastrukturen true https://cfp.denog.de/denog18/talk/YYFF9Y/ https://cfp.denog.de/denog18/talk/YYFF9Y/feedback/ Workshop Room #7# Workshop 2026-11-15T11:00:00+01:00 11:00 06:00 In this workshop session, we will explore how the high-performance protocol gRPC can be used to interact with a modern network OS: monitoring, configuration, operations, and even beyond! ## Content The workshop will touch on what gRPC is, and which gRPC services are available for managing networks. We will try out the full suite of gNxI protocols using open source tools, namely: - **gNMI**: used for network management and monitoring - **gNOI**: for operational tasks, like image upgrades and reboots - **gNSI**: security-related tasks, e.g. gRPC access policy and certificate rotation - **gRIBI**: manipulating the RIB programmatically, injecting routes on-demand ## Prerequisites We will be providing participants with a VM pre-loaded with all necessary tools and network topology. **No previous programming or gRPC experience required for this beginner-friendly workshop!** denog18-64-mastering-grpc-for-network-management-monitoring-and-automation /media/denog18/submissions/JXFHES/image_vJ73ojc.webp Gordon GidófalvyFlorian SchwarzMathis Bramkamp en true https://cfp.denog.de/denog18/talk/JXFHES/ https://cfp.denog.de/denog18/talk/JXFHES/feedback/ Workshop Room #8# Workshop 2026-11-15T11:00:00+01:00 11:00 06:00 MPLS once was the center of attention in many network talks, workshops and training. Still today it is a predominant technology in use in many networks. However, those who joined the network community in the past years or almost a decade now from enterprise and datacenter angles, have found very little opportunity to dive into the topic of MPLS. Many perceive the communities still working with expert level MPLS topics hard to engage with. This workshop tries to go back in time and provide a guided journey through the development of MPLS and how it evolved over the years. It wants to cover original ideas, what became of them and how various protocols over time solved problems of their time and ultimately resulted in the most modern use of MPLS and related technologies for those who were not around when all this was heavily discussed in every other training course. This workshop is addressed to absolute beginners and those who heard little about MPLS and have a few working assumptions but no solid background. It does not aim to go to expert level, rather give a solid structure and overview so that context exists for the concepts in play. The talk will mainly focus on the history, theories and how protocol implemented them as well as some hands-on components of label exchange and packet forwarding in groups while applying various protocols. Participants should be beginner level or completely new to MPLS. Basic knowledge of networking concepts is recommended. denog18-80-behind-the-label-how-mpls-network-transport-really-works Christian GieseElmar Kirchner en true https://cfp.denog.de/denog18/talk/MWJXKM/ https://cfp.denog.de/denog18/talk/MWJXKM/feedback/ Workshop Room #9# Workshop 2026-11-15T10:30:00+01:00 10:30 04:00 You already know how to generate keys and authenticate securely. But SSH can do so much more. In this advanced workshop, we'll explore the powerful features that transform SSH from a simple login tool into an essential part of your workflow—port forwarding, proxy jumping, SSH certificates, control channel reuse, and crafting bulletproof ssh_config files. Walk out with the techniques that turn SSH from a necessity into a superpower. denog18-108-advanced-ssh Felix Schüren en Many SSH users hit the same frustrations: managing dozens of hosts with repetitive parameters, struggling with multi-hop networks, or wasting time on repeated connection overhead. This workshop directly addresses these pain points. We'll start by diagnosing the problems in a typical ssh_config, then systematically solve them through five core techniques: Port Forwarding — Local and remote variants for securely accessing databases on private networks and exposing local services to remote machines. You'll understand when to use each and why it matters for security. Proxy Jumping — Build practical multi-hop scenarios (2-3 hops) and see how ProxyJump eliminates the bastion-host dance. SSH Certificates — A game-changer for teams managing multiple servers. We'll cover generation, deployment, and why they're superior to key-per-host approaches. Control Channel Reuse — Understand connection multiplexing and how ControlMaster/ControlPath cuts SSH connection overhead dramatically. ssh_config Mastery — Build a comprehensive config from scratch using Host patterns, wildcard matching, conditional includes, and automation that grows with your infrastructure. By the end, you'll have working examples you can adapt immediately. true https://cfp.denog.de/denog18/talk/QWSNGK/ https://cfp.denog.de/denog18/talk/QWSNGK/feedback/ Workshop Room #9# Workshop 2026-11-15T15:00:00+01:00 15:00 02:00 The network engineering industry is rich with technical talent but remains surprisingly underrepresented in the world of product-driven startups. In 2025 Thomas Weible (CTO and Co-Founder, FLEXOPTIX) and Moritz Frenzel (CEO and Co-Founder, EdgeOps) started to share their entrepreneurial journeys, each shaped by a deep technical background and a commitment to building products instead of pursuing the traditional consulting route. One year later at EdgeOps (Y 2) and FLEXOPTIX (Y 18) a lot of things did happen in their product companies. The session offers an exciting journey surging awesome highlights and annoying pitfalls we've experienced in the last year timeframe. If you weren't convinced in the first edition of this workshop in 2025, maybe now? This workshop aims to inspire and equip engineers, founders, and future entrepreneurs with the confidence and perspective to transition from services to products, still shifting from billing hours to building something that lasts, while also fostering connections between existing and aspiring founders. On more thing, Bernd Sontheimer (formerly sdt.net, now TNG) committed to share his experiences of the merge and acquisition process in 2023. denog18-70-from-networks-to-products-breaking-the-consulting-mold-2026-edition Thomas WeibleMoritz Frenzel en true https://cfp.denog.de/denog18/talk/TGXGP9/ https://cfp.denog.de/denog18/talk/TGXGP9/feedback/ Workshop Room #10# Workshop 2026-11-15T11:00:00+01:00 11:00 02:00 _“I’m a perfectionist”_ is a popular humble brag answer to the classic interview question _“What’s your biggest weakness?”_ – a weakness that conveniently sounds like a strength. While perfectionism lures us in with its promise to help, most of us know that it can have some very real downsides. In this **hands-on workshop**, we’ll unpack what we actually mean when we talk about “perfectionism”, where it might be helpful – and where it starts getting in our way. We’ll explore how perfectionism can show up as procrastination, overthinking, endless tweaking, fear of getting things wrong, or simply never feeling like something is good enough. Most importantly, we’ll look at practical tools and exercises to help break those patterns and make it easier to take action, even when things aren’t perfect. The aim isn’t to lower your standards – it’s to become more intentional about when high standards are useful, and when they’re holding you back. denog18-115-death-to-perfectionism-get-unstuck Susi Bauer en ## What You’ll Learn: - **Spotting Perfectionism in Disguise**: Recognise the less obvious ways perfectionism can show up – from procrastination and over-preparing to endlessly tweaking work that was already good enough. - **Understanding the Cost:** Explore how perfectionism can affect productivity, confidence, creativity, decision-making, and our willingness to take risks or try something new. - **Getting Out of the Overthinking Loop**: Learn practical techniques for making decisions, getting started, and taking action before you feel completely ready. - **Redefining “Good Enough”**: Learn how to set more useful definitions of done, rather than relying on an impossible feeling of “perfect”. - **Taking Imperfect Action**: Leave with a small, concrete action you can put into practice straight away – because sometimes the best way to beat perfectionism is to start. ## Why Attend? This workshop is for anyone who has ever spent far too long tweaking something that was probably fine already, put something off because they didn’t know how to do it “right”, or found themselves stuck trying to make the perfect decision. You’ll leave with a better understanding of your own perfectionist patterns and a toolbox of practical strategies for getting unstuck. Because the goal isn’t to stop caring about doing good work – it’s to make sure that the pursuit of perfect doesn’t stop you from doing the work at all. true https://cfp.denog.de/denog18/talk/EA73XB/ https://cfp.denog.de/denog18/talk/EA73XB/feedback/ Saal A Talk 2026-11-16T09:30:00+01:00 09:30 00:20 Welcome to your first DENOG conference. In this session, we will guide you through the community, the event and everything DENOG! denog18-109-newcomer-sessions Patrick Bußmann en false https://cfp.denog.de/denog18/talk/AVHF39/ https://cfp.denog.de/denog18/talk/AVHF39/feedback/ Saal A Talk 2026-11-16T10:00:00+01:00 10:00 00:30 Welcome to DENOG18! denog18-104-denog18-opening Patrick Bußmann en Welcome to DENOG18! false https://cfp.denog.de/denog18/talk/UB3PVV/ https://cfp.denog.de/denog18/talk/UB3PVV/feedback/ Saal A Talk 2026-11-16T10:30:00+01:00 10:30 00:30 Configuring a router via text CLI and configuration file editing is not very 2026. In BIRD, we are trying to catch the departing train and implement a CORECONF variant of an IETF-standardized YANG-based API. We've created a prototype but getting things right is harder than it seems. This is a report on what has already gone wrong and what is expected to fail in the future. denog18-51-retrofitting-api-into-a-routing-software Maria Matejka en While a standardized API looks simple on surface, the reality is much more convoluted. There are three standards for communication, NETCONF, RESTCONF and emerging CORECONF, each of these with slightly different semantics. Lots of the YANG modules are not yet finalized and implementation specifics are leaking into them from their authors. In the best case, we end up with the implementations slightly differing in what is implemented, and being mostly compatible for automated access. Yet, the actual future may be much more dire, with the users having to cater for three different protocols and vastly diverse implementation status of the standardized API. All of that is spiced up by performance challenges. With BIRD, we are kinda late to the party. Everybody has some API working. That brings a disadvantage on the market, but it also allows us to study the previous attempts, see possible problems and implement our API to our standards, including high performance and stability. We can also see emerging compatibility issues and there are some attempts to develop proxies and convertors to bridge the gaps. false https://cfp.denog.de/denog18/talk/3BJJKY/ https://cfp.denog.de/denog18/talk/3BJJKY/feedback/ Saal A Talk 2026-11-16T11:05:00+01:00 11:05 00:30 Modern service provider networks are evolving rapidly: transports like VXLAN, MPLS, Segment Routing and SRv6 are being used while many legacy control plane protocols are still in operation. This often results in unnecessary complexity, multiple signalling mechanisms and operational overhead. In this talk, I’ll explore how BGP EVPN has evolved into a transport-agnostic control plane capable of unifying services across MPLS, VXLAN, SR, and SRv6. The goal is simple: move away from fragmented legacy protocols and toward a single, scalable control plane for L2 and L3 services. We’ll look at recent EVPN innovations and discuss how service providers can benefit from simplifying their architectures while preparing their networks for future transport technologies. denog18-45-evpn-one-control-plane-to-rule-them-all Patrick Prangl en false https://cfp.denog.de/denog18/talk/VCQLXW/ https://cfp.denog.de/denog18/talk/VCQLXW/feedback/ Saal A Talk 2026-11-16T11:40:00+01:00 11:40 00:30 EVPN is everywhere, be it datacenter, service provider or campus - and every vendor says you need it. But EVPN rightfully has a reputation problem. It is rarely truly understood, even by vendors themselves, and often treated as a black box. The RFCs read like tax law, and the quality of vendor documentation doesn’t help either. This talk aims to be nothing less than a gentle introduction and a deep dive into EVPN at the same time. We‘ll explore the abstract concepts and frequently misused terminology in order to build an intuitive mental model. We will also look into the often overlooked origins of EVPN, which explain many of its design decisions and behaviours. Finally, we’ll take a look at tricky mechanisms like Anycast Gateways and Multihoming, so your next EVPN debugging session doesn’t become another unplanned nightshift. denog18-93-evpn-for-humans Robin Christ en false https://cfp.denog.de/denog18/talk/YTBLUH/ https://cfp.denog.de/denog18/talk/YTBLUH/feedback/ Saal A Talk 2026-11-16T14:05:00+01:00 14:05 00:30 This talk examines latency as an end-to-end property of enterprise networks, not just a wireless problem. While wireless networks often receive the most attention, the actual user experience is shaped by the interaction between radio conditions, roaming, access layer design, switching behavior, QoS handling, and overall WAN & LAN architecture. Using Wi-Fi 7 as a current reference point, the session shows why bandwidth alone is not a meaningful success metric and why latency, jitter, and responsiveness must be evaluated across the full network path. The goal is to provide network operators and engineers with a practical lens for understanding where user experience breaks down — and how to design networks that behave well under real operational conditions. denog18-66-beyond-bandwidth-why-it-doesn-t-solve-user-experience-in-wi-fi-wan-and-lan-environments Falk Bachmann en false https://cfp.denog.de/denog18/talk/FUCBPB/ https://cfp.denog.de/denog18/talk/FUCBPB/feedback/ Saal A Talk 2026-11-16T14:40:00+01:00 14:40 00:30 While everyone talked about the DENIC outage this year, we monitored the critical stuff higher up the stack. The football world championship was a challenge for streamers and network operators. So, how did they actually perform under pressure? Beyond live events, we put different access technologies to the test in our lab to analyze how factors like latency, jitter, and bandwidth caps directly impact Quality of Experience (QoE) on the web and beyond. Let's have a data-driven look at the Unexpected of 2026. denog18-68-qoe-riosities-of-2026-what-we-saw-on-the-internet-this-year Alexander Dethof en false https://cfp.denog.de/denog18/talk/ZCXTKW/ https://cfp.denog.de/denog18/talk/ZCXTKW/feedback/ Saal A Lightning Talk 2026-11-16T15:25:00+01:00 15:25 00:10 Routing loops and the amplification of looping packets are known problems on the IPv6 Internet. In a recent measurement study, we found that both problems are still present, potentially harming Internet stability. Although routing loops are often easy to fix, they receive limited attention from the network operator community. Since 2025, we aim to raise awareness of routing loops and amplification at network operator events. In 2026, we started to weekly measure the deployment of routing loops and amplifications on the IPv6 Internet. In this talk, we present how community outreach has helped significantly reduce the impact of these network misconfigurations. We further provide an update on the current state of these issues on the IPv6 Internet with a particular focus on the RIPE and DE region. We hope these misconfigurations will eventually disappear and encourage the DENOG community to spread the word, check their networks, and help eliminate routing loops from the IPv6 Internet. Until then, we will continue measuring, reporting, and raising awareness. To assist in resolving these problems, we have made our findings publicly available at https://ipv6-sra.realmv6.org/routingloops, allowing operators to check whether their networks are affected by routing loops. denog18-85-ipv6-routing-loops-a-call-to-fix-router-configurations Maynard Koch en false https://cfp.denog.de/denog18/talk/PRRFUN/ https://cfp.denog.de/denog18/talk/PRRFUN/feedback/ Saal A Lightning Talk 2026-11-16T15:35:00+01:00 15:35 00:10 There are many ways for career starters to get into IT: apprenticeships, university degrees, dual study programs, or through self-study. But how do they learn networking and IT infrastructure? With this lightning talk, I’d like to inspire you to teach young people how networking works! What are the most difficult topics to explain? What about practical experience? I've been teaching the basics of networking for several years now, and I'd like to share my experience with you. denog18-94-teach-networking Vanessa Gaube en false https://cfp.denog.de/denog18/talk/E7UDUC/ https://cfp.denog.de/denog18/talk/E7UDUC/feedback/ Saal A Talk 2026-11-16T16:45:00+01:00 16:45 00:15 Routing IPv4 packets using IPv6 next-hops has been around for some time now. It offers great opportunities to reduce IPv4 address usage in the distribution and access layer, and enables providing IPv4 as a pure add-on, keeping a clean IPv6 address structure underneath. Despite its benefits, major challenges for deploying IPv4-with-IPv6 next-hops in practice persist. While, e.g., BGP supports such routes using RFC8950, many other IGPs still lack support. Other major issues are 'the last mile', i.e., auto-configuring clients (or, for this use-case, more likely servers), and the impact of IPv4-with-IPv6 next-hop usage on traceroutes. In this talk, we will go over some current developments in these areas, which should make IPv4-with-IPv6 next-hops a viable option for practical deployments in the coming years. We will also expand further on possible deployment scenarios, where IPv4-with-IPv6 next-hops can remove further legacy Layer-2 infrastructure, e.g., LACP. denog18-99-ipv4-with-ipv6-next-hops-at-least-faster-progress-than-linux-on-the-desktop Tobias Fiebig en false https://cfp.denog.de/denog18/talk/V7Y3X9/ https://cfp.denog.de/denog18/talk/V7Y3X9/feedback/ Saal A Talk 2026-11-16T17:00:00+01:00 17:00 00:15 What actually changes in your network when you stop treating IPv4 as infrastructure and start treating it as a service? draft-vanmook-intarea-ipv6-resolved-gateway (presented at IETF 126, WG adoption call pending) defines a single sentinel gateway address, provisionally 192.0.0.11 (requested from the IANA Special-Purpose Registry, not yet assigned), handed out as the ordinary DHCPv4 default gateway. Updated hosts resolve their first hop from the IPv6 neighbour cache; unmodified hosts ARP for the sentinel once and the router answers. That's the whole mechanism. Everything downstream of it is the interesting part. This talk is about what that does to a running network: no IPv4 subnets anywhere, no ARP, no FHRP, IPv4 address pools that go flat — any /32 works anywhere in the footprint, nothing stranded by subnet sizing. The core forwards v4-via-v6 (RFC 8950) with no IPv4 configured on any router interface. On the implementation side: host implementations for Linux (userspace daemon and native systemd-networkd), FreeBSD, macOS and Windows, with prebuilt packages; a namespace conformance lab with a zero-ARP assertion; verified unmodified-host behaviour across seven operating systems; and vendor configuration examples for IOS XR, JunOS, SR OS, EOS and RouterOS. On the router side, three working deployment models: a single-gateway reference, an active/active anycast VRRP pair, and a BGP-orchestrated multi-gateway fabric — fungible gateways, host /32s injected from inventory, and the entire DHCPv4 path carried as IPv4 values over IPv6 next-hops, with no IPv4 management network at all. Plus the failure modes, the ND health prerequisites, and what breaks when you get it wrong. No tunnels. No translation. No flag day. Keep the shape, change what it means. denog18-89-killing-arp-running-ipv4-as-a-service-on-an-ipv6-only-network Remco van Mook en false https://cfp.denog.de/denog18/talk/SYTTEC/ https://cfp.denog.de/denog18/talk/SYTTEC/feedback/ Saal A Talk 2026-11-16T17:40:00+01:00 17:40 00:10 That's a wrap on Day1, time for the social! denog18-106-day-1-closing Tim Kleefass en That's a wrap on Day1, time for the social! false https://cfp.denog.de/denog18/talk/EQ7KVJ/ https://cfp.denog.de/denog18/talk/EQ7KVJ/feedback/ Saal B Talk 2026-11-16T10:30:00+01:00 10:30 00:30 KML, KMZ, DXF - hat wahrscheinlich schon jede:r mal in der Hand gehabt, nach dem man redundante Leitungen bestellt hat. Aber was macht man eigentlich sinnvolles damit? KML, KMZ, DXF - everyone knows or used those file formats, at least after asking the carrier where the redundant circuits are. But is there anything useful you can do with those files? denog18-61-geoinformation-systems-internet-infrastructure /media/denog18/submissions/97DCW3/image_jBkNhBm.webp Dominik Bay en Geoinformationsdaten sind eine der Grundlagen für stabil funktionierende Infrastruktur. Egal ob Glasfasern im Boden, Glasfasern an Hochspannungsmasten oder Richtfunkstrecken. Wie funktioniert die Trassenplanung- und Instandhaltung, und welche Vorteile habe ich als Nutzer:in um meinen Netz zu verstehen und den Netzbetrieb zu optimieren? Geo information data are the basis for reliable infrastructure. Not only for fiber in the ground, but even fiber on power lines or microwave links are planned this way. How does the planning of new fiber routes and their maintenance work, and which benefits do I get from geo data for my own network? false https://cfp.denog.de/denog18/talk/97DCW3/ https://cfp.denog.de/denog18/talk/97DCW3/feedback/ Saal B Talk 2026-11-16T11:05:00+01:00 11:05 00:30 Every server depends on firmware to boot and most also rely on firmware for remote management. U-Boot, EDK2 (UEFI), OpenBMC, you name it. And they all share the same issue: IPv6 support ranges from half-baked to non-existent. Why is this still the case in 2026? In this talk I'll go into two areas of server firmware that operatores rarely look at closely: the one that boots the server, and the one that allows out-of-band management via the Baseboard Management Controller (BMC). On the boot side: Do PXE and HTTP boot actually work over IPv6? And what unexpected side effects do you might see? On the management side: How does IPv6 support look on a BMC today, and what's still broken? Nobody's going to fix what nobody complains about. Let's find out how broken this is and what we can do about it. denog18-54-ipv6-in-firmware-still-booting-in-the-wrong-decade sinuscosinustan en false https://cfp.denog.de/denog18/talk/XPH3W7/ https://cfp.denog.de/denog18/talk/XPH3W7/feedback/ Saal B Talk 2026-11-16T14:05:00+01:00 14:05 00:30 Network operators share a vocabulary built on VRFs, EVPN-VXLAN, and BGP underlays. What doesn't travel is how it gets written down. Every vendor and orchestrator has its own dialect, and most automation tools still push device-specific config from an orchestrator down to all involved devices. Translation, not domain-specific problems, becomes a bottleneck. We build _Wire-API_ with a different model in mind: Instead of targeting devices, operators declare the state they want and controllers work out which devices are affected and what config to push. In the case of an EVPN fabric for example: describe it with objects like `Network`, `RoutingDomain`, and `ExternalConnection`, and adding a network becomes one object rather than a coordinated change across every leaf and firewall that participates. The shift is in what gets declared: desired state instead of a device's running config. From there, drift correction and HA-aware maintenance stop being separate runbooks and become properties of the reconcile loop, and the same model extends to anything else on the network expressed as intent. The core is Kubernetes. _Wire-API_ is a set of CRDs and controllers that reuse the contract that made Kubernetes work in "compute"—declared state, continuous reconciliation, honest status—and apply it to the network domain. The presentation argues for the _Wire-API_ model and walks through a live EVPN-VXLAN example—one intent object, vendor-specific config on Cisco NX-OS and Nokia SR Linux—then covers design decisions and partial-failure handling. Wire-API already operates production fabrics across multiple availability zones; the model works today even as the framework continues to grow. _Wire-API_ is Apache-2.0 and is being contributed to the NeoNephos Foundation (Linux Foundation Europe) as part of the ApeiroRA workstream under the EU IPCEI-CIS program. denog18-86-wire-api-fleet-wide-vendor-neutral-network-automation Enric PujolSebastian Wagner en Here is the link to the GitHub resources: https://github.com/ironcore-dev/network-operator And the detailed description on the website: https://ironcore.dev/network-operator/ true https://cfp.denog.de/denog18/talk/8YL9JB/ https://cfp.denog.de/denog18/talk/8YL9JB/feedback/ Saal B Talk 2026-11-16T14:40:00+01:00 14:40 00:30 Existing automation solutions are usually monolithic and require you to migrate all of your existing infrastructure at once to the automation. I wanted to introduce automation step by step and wanted to continue to use our existing sources of truth. So I have built a modular automation solution that allows us to build a completely separated automation module for everything we want to automate in our network. denog18-50-modular-nokia-sr-os-automation-from-scratch Jennifer Graul en Existing automation solutions are usually monolithic and require you to migrate all of your existing infrastructure at once to the automation. But I wanted to continue using our existing sources of truth and wanted to introduce automation in our network step by step and not in one big step. Additionally, there is the security perspective: do you really want to grant an automation solution that you don't fully understand internally unrestricted access to all of your routers? The solution: modular network automation from scratch: write a module for any aspect you want to automate in your network. Want to automate your peerings with Peering-Manager? Write a module for it. Want to automate your base router interfaces with NetBox? Write a module for it. The modules itself are isolated from each other in the configuration by using one config group for each module (basically a separate config tree for each module). This by design eliminates the possibility of collisions between modules and makes consecutive deployments easier by fully replacing the config group on each run. It additionally allows you to minimize the permissions of an automation user to the absolute required minimum by only granting them access to the config group. Furthermore, the use of config groups allows you to override the automation on any given time in the main config tree or even exclude some parts of the main config tree from it. Although this solution was developed for Nokia SR OS, it can in principle be extended to any platform that is transactional and supports something like config groups. false https://cfp.denog.de/denog18/talk/KPYWEU/ https://cfp.denog.de/denog18/talk/KPYWEU/feedback/ Saal B Talk 2026-11-16T15:15:00+01:00 15:15 00:30 Anycast is easy to explain and notoriously difficult to observe. Announce the same IP address from multiple locations, allow BGP to choose a path, and traffic should reach the "nearest" instance, although BGP's idea of nearest often has little to do with geography. ProVision (formerly 6connect) operates an anycast DNS platform spanning six prefixes, 39 BGP nodes, 13 regions, and five continents. For years, we knew the platform worked because queries were answered. What we could not prove was how it worked: which users reached which nodes, how quickly packets arrived, and where traffic quietly disappeared. This presentation tells the story of how we turned one of anycast's most frustrating behaviors-ICMP replies returning to the "wrong" node-into a measurement. That insight grew into an automated pipeline running 117,000 probes per second across 2.6 million targets, measuring latency, loss, jitter, routing behavior, path MTU failures, ECMP paths, and visibility at 845 Internet Exchanges. It is also the story of how two network engineers who are not full-time developers built the system through intensive collaboration with AI coding models. AI supplied much of the implementation capacity; the humans supplied decades of network intuition, architectural direction, validation, and the authority to say when the code was confidently wrong. denog18-82-you-can-t-make-everybody-equally-happy-measuring-anycast-with-ai-as-the-third-member-of-a-two-person-team Jan Zorz en Anycast underpins critical Internet services, including DNS, content delivery networks, and DDoS mitigation platforms. The model appears simple: announce the same IP address from multiple locations and allow BGP to direct traffic toward the best available path, but the operational reality is far less transparent. ProVision (formerly 6connect operates an anycast DNS platform built around six prefixes announced by 39 BGP nodes in 13 regions across five continents. The platform answered queries reliably, yet ordinary service monitoring could reveal only part of the story. It could tell us that a DNS request succeeded, but not always which node handled it, whether BGP selected the node we expected, how latency differed across the catchment, or where packets were being lost without causing a visible outage. Measuring the network from inside the platform created a chicken-and-egg problem. Anycast is designed to make many distributed instances appear to be one destination, so the topology we wanted to study was the same topology the service was designed to conceal. We could not simply ask the Internet which node it would reach. We needed a way to make the network reveal its own routing decisions. The breakthrough came from a behavior that initially appeared to undermine the measurements. We sent probes from the production anycast source addresses and observed that ICMP errors frequently returned to the "wrong" node rather than the node that originated the probe. That wrong node was the answer. The node receiving the ICMP response was the node BGP had selected as the return path for the router generating it. By recording those responses across the network, we could begin mapping real anycast catchments from the perspective of the infrastructure itself. The apparent flaw became the core measurement primitive. From that insight, we built a fully automated daily measurement pipeline capable of: Running 117,000 probes per second across 2.6 million targets Measuring round-trip time, packet loss, and jitter for 1.4 million addresses Detecting path MTU discovery black holes Performing ECMP-aware traceroutes Correlating active measurements with BGP monitoring Measuring platform visibility at 845 Internet Exchanges Attendees will leave with a practical understanding of why anycast is so difficult to measure, how asymmetric ICMP routing can reveal real BGP catchments, and what it takes to turn that observation into a large-scale monitoring system. They will also see a grounded example of AI-assisted engineering in which coding models expanded the capacity of a very small team without replacing the network judgment required to build something trustworthy. false https://cfp.denog.de/denog18/talk/MRZYPH/ https://cfp.denog.de/denog18/talk/MRZYPH/feedback/ Saal B Talk 2026-11-16T16:45:00+01:00 16:45 00:30 Physical points of presence (PoPs) are expensive to deploy and often limit how quickly service providers can respond to customer demand in new regions. To address this challenge, Deutsche Telekom developed a virtual PoP architecture that extends carrier-grade MPLS L3VPN services into AWS. This talk presents the technical architecture behind the solution, including AWS Direct Connect Gateway, Cisco 8000v virtual routers, MP-BGP, and VPNv4/VPNv6 integration. We explain the design decisions, operational considerations, and routing principles that enabled the realization of a cloud-based PoP. Attendees will learn how cloud infrastructure can be integrated into a traditional service provider network while maintaining routing control, operational standards, and rapid service deployment. denog18-53-how-deutsche-telekom-built-a-carrier-grade-virtual-pop-in-aws Gabor AdamHolger ThösinkAdam Orosz en Customer demand increasingly requires network services in regions where no physical Point of Presence exists. Building new PoPs is costly and time-consuming, making it difficult to respond to short-term requests. In this session, we present how Deutsche Telekom designed a vPoP architecture running in AWS that extends our MPLS backbone into cloud regions while preserving carrier-grade routing and operational principles. We will discuss the architecture, including AWS Direct Connect Gateway, Cisco 8000v virtual routers, MP-BGP (VPNv4/VPNv6), IPv4/IPv6 routing, management separation, and throughput considerations. Particular attention will be given to the design choices that enabled regional routing while avoiding AWS transit and maintaining full control over the routing domain. The talk also covers the practical experience gained during the project, including proof of concept implementation, operational challenges, automation aspects, and lessons learned from integrating cloud infrastructure into a service provider environment. The session is aimed at network operators, architects, and engineers interested in MPLS, BGP, cloud networking, and carrier-grade network design. Attendees will gain practical insights into extending traditional backbone services into hyperscaler environments. false https://cfp.denog.de/denog18/talk/SUN8ER/ https://cfp.denog.de/denog18/talk/SUN8ER/feedback/ Saal A Talk 2026-11-17T09:30:00+01:00 09:30 00:30 As network architectures transition towards open, disaggregated hardware, Open Source Switch Operating Systems (like SONiC) have unlocked unprecedented access to hardware telemetry. Concurrently modern transceivers offer advanced Vendor Digital Monitoring (VDM) capabilities that go far beyond classic Digital Diagnostic Monitoring (DDM). However the industry still struggles to utilize this data for proactive operations. This presentation demonstrates how to leverage open VDM interfaces within Open Source Switch OS architectures to establish a continuous, high-frequency telemetry pipeline. By analyzing realtime physical layer metrics - such as pre-FEC bit error rates, laser bias current shifts and optical signal degradation - we showcase how to move from reactive troubleshooting to predictive maintenance. Attendees will learn how open software paradigms enable operators to detect impending Layer 1 failures before packet loss occurs ensuring maximum network uptime without vendor lock-in. denog18-69-democratizing-layer-1-telemetry-open-source-switch-os-and-vdm-for-predictive-network-maintenance Thomas WeibleDr. Gerhard Stein en false https://cfp.denog.de/denog18/talk/J3QAZC/ https://cfp.denog.de/denog18/talk/J3QAZC/feedback/ Saal A Lightning Talk 2026-11-17T10:05:00+01:00 10:05 00:10 With BMP (BGP Monitoring Protocol) readily available on all major routing platforms, operators have the opportunity to get a view of their networks that's more comprehensive than ever before. Crucially, one needs to collect all this information and make sense of it, ideally without having to invest too much time. In this lightning talk, we present Rotonda, enabling operators to do just that: get started with BMP effortlessly, while providing the scalability and flexibility to monitor any network, any use case. Rotonda is free and open source route collection and analysis software developed by NLnet Labs. We'll introduce BMP, highlight and showcase the main features of Rotonda, and hopefully spark interest to continue the conversation afterwards. denog18-72-enjoying-bmp-with-rotonda-in-600-seconds Luuk Hendriks en false https://cfp.denog.de/denog18/talk/E7HWCA/ https://cfp.denog.de/denog18/talk/E7HWCA/feedback/ Saal A Lightning Talk 2026-11-17T10:15:00+01:00 10:15 00:10 OpenRoaming promises seamless and secure Wi-Fi access, but what does it mean for real network operations? This short talk explains the technology, the federation model, and the practical benefits and limitations of OpenRoaming from an operator’s point of view. Using real-world examples, it shows where OpenRoaming fits, where it does not, and why it is becoming relevant for public, enterprise, and venue networks. denog18-67-openroaming-explained-what-it-solves-and-why-operators-should-care Falk Bachmann en false https://cfp.denog.de/denog18/talk/JRR8WV/ https://cfp.denog.de/denog18/talk/JRR8WV/feedback/ Saal A Talk 2026-11-17T10:40:00+01:00 10:40 00:30 BGP routing security relies on many technologies, both old and new, such as IRR-based Route Filters and RPKI Technologies like Route Origin Authorizations (ROAs) or Autonomous System Provider Authorization (ASPA-s). While these technologies are well-known, they are still used together, and accurate route filter generation remains a challenging task with significant operational implications for large-scale router filter generation at major tier-1 ISPs. We show that AS-Set documentation in RIR databases is still critical yet systematically overlooked. We evaluate the scope and patterns of these issues - including missing documentation, AS-Set explosive expansion, and cyclic dependencies - demonstrating that accurate AS-Set documentation remains a foundational requirement for operational filtering. We present the toolchain and technologies like Route Query Specification (RQSpec) we use for route filter generation at scale, compensating for the complexity introduced by poor documentation. denog18-97-route-filtering-at-scale Fedor VompeSebastian Becker en false https://cfp.denog.de/denog18/talk/KXMLXN/ https://cfp.denog.de/denog18/talk/KXMLXN/feedback/ Saal A Talk 2026-11-17T11:15:00+01:00 11:15 00:30 Overview of AI's impact on the optical industry and why scale across will driving an insane bandwidth increase in optical networks. The presentation will also cover how we expect that AI agents will impact how service providers manage & automate their networks in a near future. denog18-31-ai-s-impact-on-bandwidth-and-automation-in-optical-networks Kent Lidstrom en false https://cfp.denog.de/denog18/talk/DRTW8K/ https://cfp.denog.de/denog18/talk/DRTW8K/feedback/ Saal A Lightning Talk 2026-11-17T11:45:00+01:00 11:45 00:10 Free-Space Optical (FSO) communication is a wireless technology that uses laser beams to provide high-speed data transmission between two locations with a clear line of sight. This presentation introduces the evolution of FSO from large-scale experimental systems in the 1970s to modern commercial and mission-critical applications such as satellite, military, and drone communications. Advances in optical components, sensors, control technologies, and software have significantly improved system performance, reliability, and usability. Current FSO systems are compact, lightweight, support automatic tracking, and typically achieve data rates of 25 Gbps. denog18-83-fso-essentials /media/denog18/submissions/BSEFX3/image_tcbSOOC.webp Takaya Nakagawa en Contents - What is FSO - History of FSO - Current FSO Technology - Progress in Enabling Technologies - Key Features of Today's FSO System - Things to Keep in Mind When Using Lasers false https://cfp.denog.de/denog18/talk/BSEFX3/ https://cfp.denog.de/denog18/talk/BSEFX3/feedback/ Saal A Talk 2026-11-17T13:00:00+01:00 13:00 00:30 News from IXPs in Germany As introduced 2021 we collect some parameters from all IXPs, which are active in Germany. This talk aggregates the Updates for all the IXPs in a common format and will be presented in a neutral way. denog18-110-ixp-update Tim Kleefass en false https://cfp.denog.de/denog18/talk/LEHAXX/ https://cfp.denog.de/denog18/talk/LEHAXX/feedback/ Saal A Talk 2026-11-17T13:35:00+01:00 13:35 00:30 Internet exchanges have presented as shared layer 2 networks for thirty years. I will show the mechanisms that silently blackhole exchange traffic or forward it to the wrong port: missing or incorrect neighbour entries, and unknown unicast flooding. In each case BGP stays established to the route servers and nothing reports a fault. A large exchange stated in writing that it gives no guarantee traffic sent to a peering LAN goes to, and only to, the port of the network it was meant for, and that it knows of no exchange that does. I do not know how many members expect that answer. The rest of the industry has spent years dismantling large layer 2 domains in favour of routed ones. Perhaps it is time for internet exchanges to forward at layer 3, rather than running a layer 2 forwarding domain with a route server making routing decisions. In many cases this needs no new hardware. The switches already used to build exchange fabrics forward at layer 2 and at layer 3 at line rate. Route scale is where careful consideration is needed. The shape of a layer 3 internet exchange switch is already commonplace: each PNI switch a CDN or ISP operates is a routed exchange with several settlement-free peers and one customer on it. Running at layer 3 gives participants complete isolation between ports, the same model that already applies to every other upstream connection that networks buy. RTBH works at the exchange rather than depending on a peer to honour it. Debugging becomes possible from the participant side, because traceroute shows the exchange hop. denog18-95-maybe-it-is-time-to-consider-layer-3-internet-exchanges James Rice en false https://cfp.denog.de/denog18/talk/EMHXW7/ https://cfp.denog.de/denog18/talk/EMHXW7/feedback/ Saal A Talk 2026-11-17T14:10:00+01:00 14:10 00:30 DDoS defense strategies must evolve because modern botnet campaigns combine high-volume, direct-path pressure with stealthier tailored attack components that attempt to overload and evade mitigation systems. In the past, most DDoS attacks were easier for ISPs to identify and block. The hardest cases were botnet-based Layer 7 attacks because they were more difficult to detect and mitigate. Successfully blocking DDoS attacks today requires more than the techniques that worked in the past. Over the past months, botnet size and firepower have increased dramatically. These botnets now drive some of the largest and most effective attacks, not only against individual applications but also against entire network infrastructures, cloud providers, and CDNs. At the end of 2025, we observed record-breaking attacks. This talk explains why we believe those attacks happened, why they continue, and what they reveal about the evolution of botnet-driven DDoS campaigns. Multi-terabit attacks have become much more common, but it is not just the volume of DDoS traffic that is taking down web sites and other targets around the world. The real problem is the tailored, targeted, and dynamic attack components that knock servers offline while remaining below the visibility threshold of many traditional defenses. Today’s large-scale, direct-path attacks increasingly include multiple attack vectors, blending volumetric, state-exhaustion and application-layer components. These botnet-based attacks are designed to overload mitigation capabilities and resources. This talk explains what enabled the expansion of botnets behind today’s attack campaigns and where these new bots are located. For network operators, this matters because these bots now require inbound, outbound, and cross-bound DDoS detection and mitigation. These insights are based on ATLAS, our worldwide DDoS monitoring system. Attendees will leave with a clearer understanding of why botnet-driven DDoS campaigns now demand mitigation strategies that account for visible volumetric pressure and lower-profile attack components at the same time. denog18-98-the-new-botnet-era-rethinking-your-ddos-strategy Stefan Meinders en false https://cfp.denog.de/denog18/talk/XBCBZT/ https://cfp.denog.de/denog18/talk/XBCBZT/feedback/ Saal A Talk 2026-11-17T14:45:00+01:00 14:45 00:30 In the last two decades network automation has gone from a fringe concept reserved for global players to the industry standard at almost every system size. The tooling and concepts have evolved and grown, and an ecosystem has formed and normalized around a few core systems. In this talk, we want to propose a natural next step in the evolution from manual work over templating to driving the system with sources of truth. As the technological and business complexity of networks grows, the data model becomes more and more of a focal point of how we look at the reality of our system. We need to understand our data and our models better than ever before, and make our decisions based on how we model the world, without being constrained by the limits of our pre-fabricated documentation systems. We will speak about what it means for an automation to be driven by your actual data model and how you conceptualize the network, motivated by an actual software system. Over the course of the talk, we will not just talk about concepts, but anchor our ideas in concrete implementation. Nonetheless, this is not a talk about a solution. It’s a talk about an idea and an approach, and, hopefully, the start of a conversation. denog18-9-network-automation-for-the-modern-age Veit Heller en The talk builds on our previous work and talks around network automation and data modeling. We want to make the case that “source of truth” is a useful step, but not the end state: the more interesting question is whether the model itself can become the driver of automation. The talk will use alembic (https://github.com/cyberwitchery/alembic) as the concrete anchor. We plan to show how a model-first system can represent network concepts, derive operational artifacts, and fit alongside existing DCIM/IPAM/source-of-truth tools without being constrained by their object model. Expected structure: - short history: from manual work to templates to source-of-truth automation - why we end up with our own data model most of the time and what that means - concrete examples from alembic - trade-offs, open questions, and caveats The talk is intended for network engineers, automation engineers, and people maintaining source-of-truth or orchestration systems. false https://cfp.denog.de/denog18/talk/U3Q97T/ https://cfp.denog.de/denog18/talk/U3Q97T/feedback/ Saal A Talk 2026-11-17T15:30:00+01:00 15:30 00:30 It's a wrap! denog18-105-denog18-closing Patrick Bußmann en It's a wrap! false https://cfp.denog.de/denog18/talk/XXSCSP/ https://cfp.denog.de/denog18/talk/XXSCSP/feedback/ Saal B Talk 2026-11-17T09:30:00+01:00 09:30 00:30 Modern telco operators increasingly require continuous active performance monitoring across thousands or even tens of thousands of access nodes. While TWAMP has become the de facto standard for active IP performance measurements, implementing it at carrier scale is far from trivial. This presentation explains how a carrier-scale TWAMP monitoring platform can be built using commodity x86 servers together with DPDK-based userspace packet processing that completely bypasses the Linux networking stack. The talk discusses the architectural decisions required to support massive numbers of concurrent TWAMP sessions, including packet processing, session scheduling, timer management, CPU affinity, NUMA awareness and resource optimization. Real benchmark results and operational experience from large-scale deployments demonstrate the achievable scalability and identify the practical limitations of this approach. Attendees will gain practical insight into designing highly scalable active monitoring systems without relying on proprietary hardware appliances. denog18-49-carrier-scale-twamp-monitoring-with-dpdk-and-commodity-x86-servers Mario Jurcevic en **Why carrier-scale TWAMP is difficult** Most existing TWAMP implementations are designed for relatively small deployments. Scaling active measurements to tens of thousands of simultaneously monitored access nodes introduces significant challenges in packet processing, timing accuracy, scheduling and resource management. **Why DPDK** The presentation explains why bypassing the Linux kernel networking stack is essential for achieving deterministic latency and high packet processing rates. It discusses how DPDK enables direct NIC access, reduces interrupt overhead and provides predictable packet forwarding performance. **System architecture** Topics include: - Userspace packet processing architecture - DPDK forwarding engine and application-to-engine communication - TWAMP session management - Timestamping offload and packet pacing - Multi-core scalability on commodity x86 hardware **Performance** Real benchmark results will be presented, including: - maximum number of concurrent TWAMP sessions - packets per second - CPU utilisation - memory consumption - scaling across multiple CPU cores - practical deployment limits **Operational lessons learned** The presentation concludes with practical experience gained from deploying large-scale active monitoring systems in carrier environments, including common pitfalls, optimisation techniques and recommendations for future deployments. false https://cfp.denog.de/denog18/talk/39VKX7/ https://cfp.denog.de/denog18/talk/39VKX7/feedback/ Saal B Talk 2026-11-17T10:05:00+01:00 10:05 00:30 We are all well aware of BGP as our protocol to run the Internet. As we sometimes notice (e.g. in the Talk by Wolfgang Tremmel at DENOG17) BGP still has ties to its predecessor EGP and can still claim it learned things from that protocol (Sometimes for nefarious reasons). Follow me on a journey to find out what we need to do in order to still run the EGP Protocol in 2026. How far back in time do we need to go in order to legitimately put the E into the Origin of BGP updates? Why? Because We do what we must because we can! denog18-43-you-want-egp-you-get-egp-denog-mad-scientist-edition Tobias Heister en false https://cfp.denog.de/denog18/talk/YUWRSZ/ https://cfp.denog.de/denog18/talk/YUWRSZ/feedback/ Saal B Talk 2026-11-17T10:40:00+01:00 10:40 00:30 IPv6 deployment is well underway in Germany—some of it visible, much of it happening behind the scenes. So, what’s actually going on? How much progress has the public sector made? Where does our economy stand? And what does having IPv6 at home really means for users? This talk provides an overview of IPv6 deployment across Germany. Here’s a little preview: we’re doing better than you might think. denog18-100-quo-vadis-ipv6-in-germany Wilhelm Boeddinghaus en false https://cfp.denog.de/denog18/talk/G37JXN/ https://cfp.denog.de/denog18/talk/G37JXN/feedback/ Saal B Talk 2026-11-17T11:15:00+01:00 11:15 00:30 Securing our Infrastructure against Cryptoanalysis with Quantum Computers This talk gives an overview of the topic of post quantum cryptography. It explains the problem these algorithms try to solve, shows underlying mechanisms and takes a look at developments of the past few years. The presentation is intended as a summary of the of the topic from a network engineer's point of view: what's going to be on our schedules in the not too distant future? Which solutions are already available, which topics are still under discussion, and what will be required from our infrastructure by industry standards and regulatory bodies? denog18-74-post-quantum-secure-networking Lara Hallaczek en false https://cfp.denog.de/denog18/talk/HJXTTT/ https://cfp.denog.de/denog18/talk/HJXTTT/feedback/ Saal B Talk 2026-11-17T13:00:00+01:00 13:00 00:30 Since 18 August 2026, a prosecutor in another EU country can demand your users' data directly from you — ten days to comply, eight hours if they're in a hurry. No mutual legal assistance, no local court in between: just an order in your inbox and a clock. This talk is the E-Evidence Regulation for the people who actually run the infrastructure: which data you can be forced to produce, how fast, and whether the systems you already operate could even answer in time. A few months in, we'll look at what's working, what's on fire, and what you should have built before the first order arrives. denog18-42-a-prosecutor-in-another-country-wants-your-data-in-8-hours-now-what Mathias Handsche en Most coverage of the EU E-Evidence Regulation is written for lawyers. This one isn't. If you operate an ISP, a hosting platform, a cloud, or a registrar, you are the *addressee* of these orders — and the obligations are technical and time-boxed long before they're legal. We'll start with the 90-second operator edition: European Production Orders (EPOC) and European Preservation Orders (EPOC-PR), who can issue them, which data categories are in play (subscriber, traffic, content), and the deadlines that turn this into an on-call problem rather than a policy memo. Then we get to the parts nobody warns you about: that you must designate an establishment or legal representative, that liability is joint and several with fines reaching into a percentage of global turnover, and that there's an actual machine interface behind all this — a decentralised IT system, a transport spec, a hard size limit, and a rollout that may not be finished when the orders start arriving. The practical core is simpler than the crypto-heavy forensics literature suggests. Evidence just needs to be trustworthy: the right data, demonstrably unchanged, anchored in time, and traceable back to where it came from. You don't need a forensics lab for that — you need to know whether the logs and exports you already produce would survive someone asking "how do you know this is genuine?" We'll cover the idea at a level you can act on, then look at how it usually falls apart in practice: data that's already been rotated away, mutable logs, a screenshot instead of a record, no idea who pulled what or when. We close with a field report from the first months of the regime — readiness across the EU, what early orders actually look like, and a pragmatic checklist so that when (not if) one lands in your inbox, you can produce the right data, in a defensible form, within the deadline — without it turning into a fire drill every time. This session is for ISP, hosting, cloud, and registrar engineers, DevOps, abuse/LI-interface teams, and anyone who owns logging or will be the one woken up at 2 a.m. by an 8-hour emergency order. No legal background required; bring your healthy disrespect for bureaucracy. false https://cfp.denog.de/denog18/talk/J9DJVF/ https://cfp.denog.de/denog18/talk/J9DJVF/feedback/ Saal B Talk 2026-11-17T13:35:00+01:00 13:35 00:30 Laser safety is important for everyone, yet knowledge widely differs on what's applicable and and required to do before conducting work on live fibers. This talk will give a brief introduction into laser classes in networking equipment and safety equipment. denog18-40-do-not-look-into-beam-with-remaining-eye Nicola 'nicoduck' von Thadden en false https://cfp.denog.de/denog18/talk/EVWTHX/ https://cfp.denog.de/denog18/talk/EVWTHX/feedback/ Saal B Talk 2026-11-17T14:10:00+01:00 14:10 00:30 The global routing system was built on a foundation of trust — often exploited by route leaks and hijacks. This session breaks down how a trio of complementary security mechanisms shifts the internet from a model of blind faith to strict verification. We will examine how BGP Roles and the Only-To-Customer (OTC) attribute proactively block leaks multiple hops from the source. Next, we will cover how RPKI Route Origin Authorizations (ROAs) secure the origin point, and how Autonomous System Provider Authorization (ASPA) ensures the entire AS_PATH remains valley-free. Attendees will leave understanding exactly how these tools turn the hope that "BGP speakers behaved" into proof that they did. denog18-30-the-leak-proof-routing-table-mastering-bgp-roles-roas-and-aspa Anton Elita en false https://cfp.denog.de/denog18/talk/3FWLT7/ https://cfp.denog.de/denog18/talk/3FWLT7/feedback/ Saal B Talk 2026-11-17T14:45:00+01:00 14:45 00:30 SRv6 divides opinion — somewhere between visionary promises and the suspicion that it's yet another overly complex protocol the world doesn't need. This talk cuts through both extremes and uses concrete scenarios to show where SRv6 actually delivers today. We start with a compact overview of SRv6 fundamentals: segment types, uSID encoding, and what structurally sets SRv6 apart from MPLS and VXLAN — and when those differences actually matter. Building on that, we examine three practical use cases: routing in the DC fabric (Clos/spine-leaf with BGP underlay), seamless data center interconnect without MPLS overlay complexity, and SRv6 as the transport plane for AI/GPU cluster fabrics with demanding requirements around load spreading and low latency. The throughline: what is production-ready today, what remains theoretical — and where is the added complexity actually worth it? denog18-27-srv6-in-the-data-center-crazy-ideas-or-real-use-cases Andreas Roeder en The Goal of this talk is to give a Technology Introduction into SRv6 and how this will be applicable for DataCenter Usecases and compares towards existing Technologies like EVPN/VXLAN. The Goal is to educate the audience about this technology and provide examples of usecases. false https://cfp.denog.de/denog18/talk/E8TQM8/ https://cfp.denog.de/denog18/talk/E8TQM8/feedback/