https://media.ccc.de/c/denog11 This feed contains all events from denog11 as mp4 see video outro Thu, 23 Jan 2025 18:44:21 -0000 https://static.media.ccc.de/media/events/denog/denog11/logo.png https://media.ccc.de/c/denog11 https://media.ccc.de/v/denog11-33-scaling-to-support-thousands-of-bgp-peerings-in-a-saas-environment When analyzing peering traffic and identifying DDoS attacks, BGP provides valuable additional insight to supplement Flow information. In this talk we'll go over the different challenges, actions and learnings from the past four years to enable the support of thousands of peerings in a multi-tenant SaaS platform. Kentik utilizes multiple auxiliary sources, such as SNMP, DNS, RADIUS or Streaming Telemetry, to enrich the ingested flow. The most prominent of these sources though, is BGP. With BGP data, Kentik is able to produce BGP-related analytics such as peering analytics and in addition, utilize the peering bidirectionally to enable DDoS mitigation capabilities such as RTBH and Flowspec. In this presentation we'll start with a short introduction on how Kentik uses BGP, in order to define the technical requirements for the setup. We'll then overview the different generations of the setup through the years: 1. 1 active node (2 nodes in active-backup) - ucarp 2. 4 active nodes with mask-based hashing - RTBH functionality is introduced, exabgp is introduced 3. 10 active nodes with full-tuple hashing and support for balancing IPv6 (current setup - slowly getting deprecated) - Flowspec is introduced 4. 16+ nodes with IPVS+keepalived and easy pooling/depooling setup (now in testing) With the requirement being that the external customer service needs to remain stable and not require any reconfiguration, for each phase we'll illustrate the challenges, examine the options available to Kentik engineers, explain the choice that was made and describe the outcome, leading Kentik to be able to support more than 4000 peerings across 16 nodes today. about this event: https://pretalx.denog.de/denog11/talk/VXVYRP/ Tue, 12 Nov 2019 12:00:00 +0100 https://cdn.media.ccc.de/events/denog/denog11/h264-sd/denog11-33-eng-Scaling_to_support_thousands_of_BGP_peerings_in_a_SaaS_environment_sd.mp4?1573566577 b5445200-4734-523b-ba37-0efa60749018 2019-11-12T12:00:00+01:00 Costas Drogos No denog11, 33, 2019 When analyzing peering traffic and identifying DDoS attacks, BGP provides valuable additional insight to supplement Flow information. In this talk we'll go over the different challenges, actions and learnings from the past four years to enable the support of thousands of peerings in a multi-tenant SaaS platform. Kentik utilizes multiple auxiliary sources, such as SNMP, DNS, RADIUS or Streaming Telemetry, to enrich the ingested flow. The most prominent of these sources though, is BGP. With BGP data, Kentik is able to produce BGP-related analytics such as peering analytics and in addition, utilize the peering bidirectionally to enable DDoS mitigation capabilities such as RTBH and Flowspec. In this presentation we'll start with a short introduction on how Kentik uses BGP, in order to define the technical requirements for the setup. We'll then overview the different generations of the setup through the years: 1. 1 active node (2 nodes in active-backup) - ucarp 2. 4 active nodes with mask-based hashing - RTBH functionality is introduced, exabgp is introduced 3. 10 active nodes with full-tuple hashing and support for balancing IPv6 (current setup - slowly getting deprecated) - Flowspec is introduced 4. 16+ nodes with IPVS+keepalived and easy pooling/depooling setup (now in testing) With the requirement being that the external customer service needs to remain stable and not require any reconfiguration, for each phase we'll illustrate the challenges, examine the options available to Kentik engineers, explain the choice that was made and describe the outcome, leading Kentik to be able to support more than 4000 peerings across 16 nodes today. about this event: https://pretalx.denog.de/denog11/talk/VXVYRP/ 00:22:36 https://media.ccc.de/v/denog11-44-why-should-my-network-facility-ixp-be-listed-at-peeringdb- PeeringDB Update: A look into PeeringDB's data for AT/CH/DE/LU and the latest changes Why should my network/facility/ixp be listed at PeeringDB? * What is PeeringDB * Why should my facility, IXP or network be listed in PeeringDB? * A look into PeeringDBs data: * Stats for Austria, Germany and Switzerland * Peering in Hamburg: Networks, Co-Locations, Internet-Exchanges - where to go in Hamburg? * Whats new * How can I support PeeringDB about this event: https://pretalx.denog.de/denog11/talk/RXJSNL/ Tue, 12 Nov 2019 11:20:00 +0100 https://cdn.media.ccc.de/events/denog/denog11/h264-sd/denog11-44-eng-Why_should_my_network_facility_ixp_be_listed_at_PeeringDB_sd.mp4?1573568436 a5a61e7a-8f36-552d-ac05-8c4f40456315 2019-11-12T11:20:00+01:00 Stefan Funke No denog11, 44, 2019 PeeringDB Update: A look into PeeringDB's data for AT/CH/DE/LU and the latest changes Why should my network/facility/ixp be listed at PeeringDB? * What is PeeringDB * Why should my facility, IXP or network be listed in PeeringDB? * A look into PeeringDBs data: * Stats for Austria, Germany and Switzerland * Peering in Hamburg: Networks, Co-Locations, Internet-Exchanges - where to go in Hamburg? * Whats new * How can I support PeeringDB about this event: https://pretalx.denog.de/denog11/talk/RXJSNL/ 00:12:48 https://media.ccc.de/v/denog11-39-a-short-story-of-a-broken-strict-urpf-implementation At KIT we bought multilayer switches which use NDP and ARP cache information for strict uRPF. This talk shows you how this implementation breaks things. I will start with a short summary how strict uRPF according to RFC3704 works and how it can be used to prevent customers from spoofing source addresses. Afterwards I'll show a implementation of strict uRPF, which only forwards packets of hosts if the IP address is already learned by NDP or ARP. I will show, how this implementation prevents at least current macOS and GNU/Linux systems from connecting to IPv6 addresses outside of the broadcast domain because they do not send unsolicited neighbor solicitations. Furthermore i'll show how this implementation also breaks load balancing setups based on MAC Address Translation and Direct Server Return. about this event: https://pretalx.denog.de/denog11/talk/NGJYFT/ Tue, 12 Nov 2019 11:10:00 +0100 https://cdn.media.ccc.de/events/denog/denog11/h264-sd/denog11-39-eng-A_short_story_of_a_broken_strict_uRPF_implementation_sd.mp4?1573566455 73c58d3c-980f-5457-9fda-e3f9646e6c89 2019-11-12T11:10:00+01:00 Benedikt Neuffer No denog11, 39, 2019 At KIT we bought multilayer switches which use NDP and ARP cache information for strict uRPF. This talk shows you how this implementation breaks things. I will start with a short summary how strict uRPF according to RFC3704 works and how it can be used to prevent customers from spoofing source addresses. Afterwards I'll show a implementation of strict uRPF, which only forwards packets of hosts if the IP address is already learned by NDP or ARP. I will show, how this implementation prevents at least current macOS and GNU/Linux systems from connecting to IPv6 addresses outside of the broadcast domain because they do not send unsolicited neighbor solicitations. Furthermore i'll show how this implementation also breaks load balancing setups based on MAC Address Translation and Direct Server Return. about this event: https://pretalx.denog.de/denog11/talk/NGJYFT/ 00:09:32 https://media.ccc.de/v/denog11-37-400g-and-beyond 400G brings several improvements also towards existing 100G. This lightning talk shall give a slight insight over the the ratified 100G optical standards coming with 400G. 400G brings several improvements also towards existing 100G. This lightning talk shall give a slight insight over the the ratified 100G optical standards coming with 400G. about this event: https://pretalx.denog.de/denog11/talk/X8SYPC/ Tue, 12 Nov 2019 11:00:00 +0100 https://cdn.media.ccc.de/events/denog/denog11/h264-sd/denog11-37-eng-400G_and_beyond_sd.mp4?1573566414 4ee367a1-d868-5a1d-a7e9-cb38b0f2df5c 2019-11-12T11:00:00+01:00 Florian Hibler No denog11, 37, 2019 400G brings several improvements also towards existing 100G. This lightning talk shall give a slight insight over the the ratified 100G optical standards coming with 400G. 400G brings several improvements also towards existing 100G. This lightning talk shall give a slight insight over the the ratified 100G optical standards coming with 400G. about this event: https://pretalx.denog.de/denog11/talk/X8SYPC/ 00:09:29 https://media.ccc.de/v/denog11-28-latest-developments-in-spring-segment-routing- Quick recap on what SPRING is and what problem it tries to address. Afterwards inform about the latest developments in this field. This talk builds upon the SPRING talks from DENOG8 and DENOG10. After a quick recap what the standard is about and what advantages people are seeing in it compared to classical label distribution protocols like LDP and RSvP, we will dive into the new developments in this area like Flexalgo. Afterwards, we will dive into additional dataplane encapsulations besides MPLS, which have shown up in the recent past. While some are still in the draft status we will take a closer look into the different options and their pros and cons including SRv6, SRv6+, SRoUDP. about this event: https://pretalx.denog.de/denog11/talk/CXHDUZ/ Tue, 12 Nov 2019 10:00:00 +0100 https://cdn.media.ccc.de/events/denog/denog11/h264-sd/denog11-28-eng-Latest_Developments_in_SPRING_Segment_Routing_sd.mp4?1573566297 5a0e2c4a-2481-5dd1-a153-7b7106b046f5 2019-11-12T10:00:00+01:00 Sebastian Graf No denog11, 28, 2019 Quick recap on what SPRING is and what problem it tries to address. Afterwards inform about the latest developments in this field. This talk builds upon the SPRING talks from DENOG8 and DENOG10. After a quick recap what the standard is about and what advantages people are seeing in it compared to classical label distribution protocols like LDP and RSvP, we will dive into the new developments in this area like Flexalgo. Afterwards, we will dive into additional dataplane encapsulations besides MPLS, which have shown up in the recent past. While some are still in the draft status we will take a closer look into the different options and their pros and cons including SRv6, SRv6+, SRoUDP. about this event: https://pretalx.denog.de/denog11/talk/CXHDUZ/ 00:32:14 https://media.ccc.de/v/denog11-38-a-wider-shade-of-doh We will look into the topic of encrypted DNS, the mesh of interests, concentration on the Internet, dramatic power shifts and long term architectural and policy consequences. DoH (DNS over https) had been a joke amongst engineers - cynically admitting that "everything" is going to be "tunneled thru" http anyway - long before standardization efforts were launched in the Internet Engineering Task Force (IETF). Consequently, the specification is lean and straightforward, but the idea faced significant pushback from operations and security communities. In parallel, the DNS community in the IETF has been developing two more DNS encryption standards to address "pervasive monitoring". One of the two, DNS over TLS (DoT) is gaining attention and support, but the big question arising is whether the concept of "operating system" can survive the ever growing prevalence of "apps" and whether the name resolution is a function that should be controlled by the device owner, the enterprise network manager or the app vendor. At the same time, DoH accelerates the concentration in the DNS resolver market - a "market" that had only recently emerged and appears to transform a highly distributed technical function into an oligopoly with, in perspective, significant influence over the shape of the DNS namespace. It's time to differentiate between the technology, the policy and the economics and to stop barking the wrong tree(s) when it comes to assessing the bigger picture effects of "DoH" as proposed by the browser industry. about this event: https://pretalx.denog.de/denog11/talk/CYNLWC/ Tue, 12 Nov 2019 12:30:00 +0100 https://cdn.media.ccc.de/events/denog/denog11/h264-sd/denog11-38-eng-A_Wider_Shade_of_DoH_sd.mp4?1573564962 e992da33-f93e-55c3-be05-2fe1ebe2a202 2019-11-12T12:30:00+01:00 Peter Koch No denog11, 38, 2019 We will look into the topic of encrypted DNS, the mesh of interests, concentration on the Internet, dramatic power shifts and long term architectural and policy consequences. DoH (DNS over https) had been a joke amongst engineers - cynically admitting that "everything" is going to be "tunneled thru" http anyway - long before standardization efforts were launched in the Internet Engineering Task Force (IETF). Consequently, the specification is lean and straightforward, but the idea faced significant pushback from operations and security communities. In parallel, the DNS community in the IETF has been developing two more DNS encryption standards to address "pervasive monitoring". One of the two, DNS over TLS (DoT) is gaining attention and support, but the big question arising is whether the concept of "operating system" can survive the ever growing prevalence of "apps" and whether the name resolution is a function that should be controlled by the device owner, the enterprise network manager or the app vendor. At the same time, DoH accelerates the concentration in the DNS resolver market - a "market" that had only recently emerged and appears to transform a highly distributed technical function into an oligopoly with, in perspective, significant influence over the shape of the DNS namespace. It's time to differentiate between the technology, the policy and the economics and to stop barking the wrong tree(s) when it comes to assessing the bigger picture effects of "DoH" as proposed by the browser industry. about this event: https://pretalx.denog.de/denog11/talk/CYNLWC/ 00:35:59 https://media.ccc.de/v/denog11-45-denog11-closing Conference wrap up Conference wrap up about this event: https://pretalx.denog.de/denog11/talk/39NC9W/ Tue, 12 Nov 2019 13:00:00 +0100 https://cdn.media.ccc.de/events/denog/denog11/h264-sd/denog11-45-eng-DENOG11_closing_sd.mp4?1573563776 36e0e01e-0133-5791-96d8-a4c16531a4c8 2019-11-12T13:00:00+01:00 Patrick Bussmann No denog11, 45, 2019 Conference wrap up Conference wrap up about this event: https://pretalx.denog.de/denog11/talk/39NC9W/ 00:10:53 https://media.ccc.de/v/denog11-25-the-fundamentals-of-segment-routing This session will focus on the fundamental building blocks of Segment Routing technology, and an overview of technical and business benefits of Segment Routing deployment. This session provides an overview of the Segment Routing technology and its use cases. This new routing paradigm provides high operational simplicity and maximum network scalability and flexibility. You will get an understanding of the basic concepts behind the Segment Routing technology and its wide applicability ranging from simple transport for MPLS services, traffic engineering and its benefits in the context of software defined networking by introducing a SDN controller as the brain of complex network path calculations. about this event: https://pretalx.denog.de/denog11/talk/EZGJ3M/ Tue, 12 Nov 2019 09:30:00 +0100 https://cdn.media.ccc.de/events/denog/denog11/h264-sd/denog11-25-eng-The_fundamentals_of_Segment_Routing_sd.mp4?1573563697 32222ae0-74e8-5f5c-a151-ca5218747926 2019-11-12T09:30:00+01:00 Leonir Hoxha No denog11, 25, 2019 This session will focus on the fundamental building blocks of Segment Routing technology, and an overview of technical and business benefits of Segment Routing deployment. This session provides an overview of the Segment Routing technology and its use cases. This new routing paradigm provides high operational simplicity and maximum network scalability and flexibility. You will get an understanding of the basic concepts behind the Segment Routing technology and its wide applicability ranging from simple transport for MPLS services, traffic engineering and its benefits in the context of software defined networking by introducing a SDN controller as the brain of complex network path calculations. about this event: https://pretalx.denog.de/denog11/talk/EZGJ3M/ 00:32:27 https://media.ccc.de/v/denog11-27-the-complexity-of-hyper-speed-transceivers-lets-make-it Thomas will describe in detail the structures inside optical transceivers. Insights into the latest 40G up to 400G transceiver developments to optimize your network design. Basics of how FEC compensates for errors caused by PAM4 modulation. Thomas will describe in detail the structures inside optical transceivers. A Transmitter / Receiver Optical Sub Assembly (TOSA / ROSA) is no longer just a diode in a housing handling the light path to and fro to the fiber. The performance increases from 10G to 100G onwards to 400G - are not only giant steps in bandwidth they are matching leaps in manufacturing. How did the optical industry players around the globe make it possible to squeeze everything into the tiny form factors we see today? It is about all precision - a microscope with a calm and competent hand is no longer sufficient, now it is about; nano tolerances, testing, complex transceiver firmware and a shed load of money. This is the high precision optical mechanical engineering revolution which fuels the hyper growth of data centers and optical networking worldwide… If you face design issues with your current optical network design Thomas will give you insights into the latest 40G up to 400G transceiver developments (e.g. long distance 80km) which you can expect in the upcoming month being available. Hopefully this might solve some of your headache. As a small „one more thing" Thomas will dive into the basics of how FEC compensates for errors caused by PAM4 modulation. about this event: https://pretalx.denog.de/denog11/talk/TSETUN/ Tue, 12 Nov 2019 09:00:00 +0100 https://cdn.media.ccc.de/events/denog/denog11/h264-sd/denog11-27-eng-the_complexity_of_hyper_speed_transceivers_-_lets_make_it_sd.mp4?1573552061 61968b0d-63fc-56d8-9500-3cdf7bba9c9e 2019-11-12T09:00:00+01:00 Thomas Weible No denog11, 27, 2019 Thomas will describe in detail the structures inside optical transceivers. Insights into the latest 40G up to 400G transceiver developments to optimize your network design. Basics of how FEC compensates for errors caused by PAM4 modulation. Thomas will describe in detail the structures inside optical transceivers. A Transmitter / Receiver Optical Sub Assembly (TOSA / ROSA) is no longer just a diode in a housing handling the light path to and fro to the fiber. The performance increases from 10G to 100G onwards to 400G - are not only giant steps in bandwidth they are matching leaps in manufacturing. How did the optical industry players around the globe make it possible to squeeze everything into the tiny form factors we see today? It is about all precision - a microscope with a calm and competent hand is no longer sufficient, now it is about; nano tolerances, testing, complex transceiver firmware and a shed load of money. This is the high precision optical mechanical engineering revolution which fuels the hyper growth of data centers and optical networking worldwide… If you face design issues with your current optical network design Thomas will give you insights into the latest 40G up to 400G transceiver developments (e.g. long distance 80km) which you can expect in the upcoming month being available. Hopefully this might solve some of your headache. As a small „one more thing" Thomas will dive into the basics of how FEC compensates for errors caused by PAM4 modulation. about this event: https://pretalx.denog.de/denog11/talk/TSETUN/ 00:28:05 https://media.ccc.de/v/denog11-32-writing-ansible-modules Ansible configuration management is very extensible and it is easy to write own modules for custom tasks with a few lines of Python. Ansible is an established tool for server and network configuration. One reason for it's success is the simple architecture that encourages own customization and extension. Here I want to present how own modules, i.e. single configuration actions on the target host, are implemented with Python or other languages. about this event: https://pretalx.denog.de/denog11/talk/KYMLMU/ Mon, 11 Nov 2019 17:30:00 +0100 https://cdn.media.ccc.de/events/denog/denog11/h264-sd/denog11-32-eng-Writing_Ansible_Modules_sd.mp4?1573551157 1db9ce1c-e9bb-547f-9481-8add961acbdb 2019-11-11T17:30:00+01:00 Martin Schütte No denog11, 32, 2019 Ansible configuration management is very extensible and it is easy to write own modules for custom tasks with a few lines of Python. Ansible is an established tool for server and network configuration. One reason for it's success is the simple architecture that encourages own customization and extension. Here I want to present how own modules, i.e. single configuration actions on the target host, are implemented with Python or other languages. about this event: https://pretalx.denog.de/denog11/talk/KYMLMU/ 00:28:31 https://media.ccc.de/v/denog11-14-intent-driven-fully-automated-deployment-of-anycasted-load-balancers-with-haproxy-and-python This talk will show-case how to build an environment to set up your services (e.g. apache webservers, KDCs, ...), load balancing, routing and monitoring from a simple service configuration. Some lines of YAML and the power of Python are the source for generating configuration for HAproxy, bird (route reflection and anycast nodes), apache2 and Icinga2. Keeping your service configuration aligned over hundreds of hosts is not a simple task. In this talk, we illustrate how we automated the integration of HAProxy into our infrastructure at University of Paderborn. As our current generation of commercial load balancer appliances approached end of life, we thought about replacement options and improving how we manage our services while being at it. The main goal was building a scaleable, consistent, active-active setup of load balancers which could be easily automated with open source tools. We needed a way to define what a service is and how/where it should be configured, balanced and monitored we created a simple service defintion format in YAML and small Python library to help with parsing, inheritence, defaults etc. The automation framework bcfg2 was a given as it was already in use to manage hundreds of Linux and Windows systems and services. As it's written in Python it's easily extendable. As load balacing options we implemented anycast (for examples for Kerberos KDCs) as well balancing by HAproxy nodes where the HAproxy frontend IPs might be anycasted as well. When running production services it's important to know when things break before the user does, so setting up monitoring for frontend and backend services is part of the picture, too. All bits of configuration for HAproxy, anycast, route reflection, monitoring with Icinga2, netfilter (nftables) rules, etc. are automagically generated based on the service configuration. This talk will lay out how all those parts fit together and are generated. Of course, we also explain the pitfalls of this setup and what we (hopefully) learned from it. about this event: https://pretalx.denog.de/denog11/talk/WWJS8N/ Mon, 11 Nov 2019 17:00:00 +0100 https://cdn.media.ccc.de/events/denog/denog11/h264-sd/denog11-14-eng-Intent-driven_fully_automated_deployment_of_anycasted_load_balancers_with_HAProxy_and_Python_sd.mp4?1573551266 e87f50cd-b5eb-59cc-be8c-2991b372e4c3 2019-11-11T17:00:00+01:00 Maximilian Wilhelm No denog11, 14, 2019 This talk will show-case how to build an environment to set up your services (e.g. apache webservers, KDCs, ...), load balancing, routing and monitoring from a simple service configuration. Some lines of YAML and the power of Python are the source for generating configuration for HAproxy, bird (route reflection and anycast nodes), apache2 and Icinga2. Keeping your service configuration aligned over hundreds of hosts is not a simple task. In this talk, we illustrate how we automated the integration of HAProxy into our infrastructure at University of Paderborn. As our current generation of commercial load balancer appliances approached end of life, we thought about replacement options and improving how we manage our services while being at it. The main goal was building a scaleable, consistent, active-active setup of load balancers which could be easily automated with open source tools. We needed a way to define what a service is and how/where it should be configured, balanced and monitored we created a simple service defintion format in YAML and small Python library to help with parsing, inheritence, defaults etc. The automation framework bcfg2 was a given as it was already in use to manage hundreds of Linux and Windows systems and services. As it's written in Python it's easily extendable. As load balacing options we implemented anycast (for examples for Kerberos KDCs) as well balancing by HAproxy nodes where the HAproxy frontend IPs might be anycasted as well. When running production services it's important to know when things break before the user does, so setting up monitoring for frontend and backend services is part of the picture, too. All bits of configuration for HAproxy, anycast, route reflection, monitoring with Icinga2, netfilter (nftables) rules, etc. are automagically generated based on the service configuration. This talk will lay out how all those parts fit together and are generated. Of course, we also explain the pitfalls of this setup and what we (hopefully) learned from it. about this event: https://pretalx.denog.de/denog11/talk/WWJS8N/ 00:18:41 https://media.ccc.de/v/denog11-16-using-rpsl-to-generate-config-templates aut-num objects should contain the peering policy of an ASN. Despite a formal language (RPSL) exists, it become more and more common to describe the policy in vague textual form. This talk encourages the admins to prefer more machine readable format. RPSL was designed to generate router configuration out of the aut-num object. The language is too specific, it's strongly coupled to the router capabilities at the time of writing the standard. While routers evolve, the language struck in development. Consequently the tool chains for RPSL became unmaintain(ed/able) or vanished completely. This talk is about the current possibilities of RPSL. How to write peering specification, so that useful configuration templates can be generated. How to deal with BLACKHOLE and GSHUT. How to offer clear and concise definitions about inter-AS path/metric manipulations communities. Problems with the tool chain and holes in the specification as well as possible solutions are explained. about this event: https://pretalx.denog.de/denog11/talk/97C7BM/ Mon, 11 Nov 2019 16:10:00 +0100 https://cdn.media.ccc.de/events/denog/denog11/h264-sd/denog11-16-eng-Using_RPSL_to_generate_config_templates_sd.mp4?1573550995 430d5ee0-0f57-5635-972e-f7cae81ae533 2019-11-11T16:10:00+01:00 Lutz Donnerhacke No denog11, 16, 2019 aut-num objects should contain the peering policy of an ASN. Despite a formal language (RPSL) exists, it become more and more common to describe the policy in vague textual form. This talk encourages the admins to prefer more machine readable format. RPSL was designed to generate router configuration out of the aut-num object. The language is too specific, it's strongly coupled to the router capabilities at the time of writing the standard. While routers evolve, the language struck in development. Consequently the tool chains for RPSL became unmaintain(ed/able) or vanished completely. This talk is about the current possibilities of RPSL. How to write peering specification, so that useful configuration templates can be generated. How to deal with BLACKHOLE and GSHUT. How to offer clear and concise definitions about inter-AS path/metric manipulations communities. Problems with the tool chain and holes in the specification as well as possible solutions are explained. about this event: https://pretalx.denog.de/denog11/talk/97C7BM/ 00:15:42 https://media.ccc.de/v/denog11-26-automate-yourself-within-six-months A open source solution for automating isp network using GitLab and NetBox Automation shouldn't be hard, and implementing it shouldn't require expensive proprietary tools. Many of us still rely on these tools or on hacky homegrown systems, because in reality writing a bunch of scripts is still the closest some of us ever get to automating their network. In our talk, we'll present an extensible, declarative system that relies on open source components such as Netbox, Gitlab, and Ansible. It is used to manage a real, heterogeneous fleet of devices today, and it's easily customizable to fit your use case. about this event: https://pretalx.denog.de/denog11/talk/YDQFXN/ Mon, 11 Nov 2019 16:30:00 +0100 https://cdn.media.ccc.de/events/denog/denog11/h264-sd/denog11-26-eng-Automate_yourself_within_six_months_sd.mp4?1573492092 24ee7975-3fc2-5ff4-b48c-98800630187f 2019-11-11T16:30:00+01:00 Veit Heller, Christian Dieckhoff No denog11, 26, 2019 A open source solution for automating isp network using GitLab and NetBox Automation shouldn't be hard, and implementing it shouldn't require expensive proprietary tools. Many of us still rely on these tools or on hacky homegrown systems, because in reality writing a bunch of scripts is still the closest some of us ever get to automating their network. In our talk, we'll present an extensible, declarative system that relies on open source components such as Netbox, Gitlab, and Ansible. It is used to manage a real, heterogeneous fleet of devices today, and it's easily customizable to fit your use case. about this event: https://pretalx.denog.de/denog11/talk/YDQFXN/ 00:27:41 https://media.ccc.de/v/denog11-35-challenges-running-a-large-scale-public-wifi-network ADDIX is running one of the biggest public wifi networks in northern germany with allows users a connect once, use anywhere approch with seamless roaming between all kind of accesspoints. this incorperated a hughe pile of technical difficulties running a public wifi network that incorperates own infrastructure at fixed locations, in public transportation and also integrating customer owned wifi equippement can be intresting. in my talks i like share some experiences from technical, operational and organisation challenges we encountered in the last 3 years of operations. technical part will cover some wifi basics and network design challenges. the operational part will focus on support and maintance of the network. the organisational part will include contractional challenges with customers and stake holders and the search for the holy grail of monetizing a wifi network. about this event: https://pretalx.denog.de/denog11/talk/SV3BMZ/ Mon, 11 Nov 2019 14:30:00 +0100 https://cdn.media.ccc.de/events/denog/denog11/h264-sd/denog11-35-eng-challenges_running_a_large_scale_public_wifi_network_sd.mp4?1573489428 a7641e0b-b19f-5fe1-8ced-7bbcd035048e 2019-11-11T14:30:00+01:00 Nils Dohse No denog11, 35, 2019 ADDIX is running one of the biggest public wifi networks in northern germany with allows users a connect once, use anywhere approch with seamless roaming between all kind of accesspoints. this incorperated a hughe pile of technical difficulties running a public wifi network that incorperates own infrastructure at fixed locations, in public transportation and also integrating customer owned wifi equippement can be intresting. in my talks i like share some experiences from technical, operational and organisation challenges we encountered in the last 3 years of operations. technical part will cover some wifi basics and network design challenges. the operational part will focus on support and maintance of the network. the organisational part will include contractional challenges with customers and stake holders and the search for the holy grail of monetizing a wifi network. about this event: https://pretalx.denog.de/denog11/talk/SV3BMZ/ 00:30:46 https://media.ccc.de/v/denog11-31-microcode-updates-as-protection-against-spectre-co- Protection against CPU attacks such as Spectre v2 or ZombieLoad require CPU microcode updates. Performing these updates via BIOS updates is often a painful task - so let's delegate this task to the operating system. Protection against side channel attacks such as Spectre v2, v3a/v4, L1TF or MDS/ZombieLoad requires not only operating system patches but also an update of the CPU microcode. Updating the microcode via the operating system is easier than via a BIOS update - especially when you are running tens, hundreds or even thousands of servers in your datacenter. Join this ignite talk and learn in 5 minutes everything you need to know to protect your Linux, FreeBSD and Windows servers from L1TF, ZombieLoad and the Spectre's of the world :-) about this event: https://pretalx.denog.de/denog11/talk/RM9EFS/ Mon, 11 Nov 2019 16:00:00 +0100 https://cdn.media.ccc.de/events/denog/denog11/h264-sd/denog11-31-eng-Microcode_updates_as_protection_against_Spectre_Co_sd.mp4?1573489015 f2a061d1-6eb5-5522-9384-1ff4f240cc61 2019-11-11T16:00:00+01:00 Werner Fischer No denog11, 31, 2019 Protection against CPU attacks such as Spectre v2 or ZombieLoad require CPU microcode updates. Performing these updates via BIOS updates is often a painful task - so let's delegate this task to the operating system. Protection against side channel attacks such as Spectre v2, v3a/v4, L1TF or MDS/ZombieLoad requires not only operating system patches but also an update of the CPU microcode. Updating the microcode via the operating system is easier than via a BIOS update - especially when you are running tens, hundreds or even thousands of servers in your datacenter. Join this ignite talk and learn in 5 minutes everything you need to know to protect your Linux, FreeBSD and Windows servers from L1TF, ZombieLoad and the Spectre's of the world :-) about this event: https://pretalx.denog.de/denog11/talk/RM9EFS/ 00:11:18 https://media.ccc.de/v/denog11-17-source-routing-on-the-edge How EXARING optimized peering capacity utilization and got rid of Queue Drops using Source Routing. EXARING operates the CDN of waipu.tv, a TV streaming platform. As this causes a lot of traffic it also causes quite some costs. Thus we want to run our network interconnects as hot as possible. We've implemented a system that automates traffic engineering and ensures all our capacity is utilized as good as possible. We will present our technology stack including: MPLS based source routing, MPLS in UDP tunnels, BGP, BMP, Route Optimization, SDN Controllers, Linux and BIO-Routing Software. about this event: https://pretalx.denog.de/denog11/talk/WTRGJA/ Mon, 11 Nov 2019 14:00:00 +0100 https://cdn.media.ccc.de/events/denog/denog11/h264-sd/denog11-17-eng-Source_Routing_on_the_Edge_sd.mp4?1573485975 da04240a-7f2f-53c0-9139-f81a65c4de3c 2019-11-11T14:00:00+01:00 Oliver "takt" Herms No denog11, 17, 2019 How EXARING optimized peering capacity utilization and got rid of Queue Drops using Source Routing. EXARING operates the CDN of waipu.tv, a TV streaming platform. As this causes a lot of traffic it also causes quite some costs. Thus we want to run our network interconnects as hot as possible. We've implemented a system that automates traffic engineering and ensures all our capacity is utilized as good as possible. We will present our technology stack including: MPLS based source routing, MPLS in UDP tunnels, BGP, BMP, Route Optimization, SDN Controllers, Linux and BIO-Routing Software. about this event: https://pretalx.denog.de/denog11/talk/WTRGJA/ 00:31:46 https://media.ccc.de/v/denog11-29-bgp-analytics-with-openconfig-telemetry-and-grpc Extracting BGP Telemetry Information from Network devices using vendor-neutral Openconfig data model and gRPC. Importing BGP metrics like received and advertised routes, total prefixes, session flap and more into TICK Stack and using mathematical models to analyse the data to identify anomalies. This talk will discuss the benefits of streaming telemetry in conjunction with vendor independent data models with Openconfig and structured data for analysis versus SNMP and CLI screen scraping. The further processing of the imported metrics is shown using the TICK Stack and Grafana as a dashboard, for an optical visualization of the metrics, the primary focus is on BGP metrics. Having all this metrics collected one can define statistical models to analyse or to correlate the data. For example to use algorithm like 3-sigma rule or k-means to identify anomalies. Kapacitor together with user-defined-function can do the job. To Sum up, collecting different metrics from network devices can help the operator to have some kind of "network fingerprint", with this fingerprint the operator is able to identify anomalies. To easy analyse data you need it in a vendor-neutral structured format and therefore Openconfig data model is a good match. about this event: https://pretalx.denog.de/denog11/talk/QXYMFW/ Mon, 11 Nov 2019 13:30:00 +0100 https://cdn.media.ccc.de/events/denog/denog11/h264-sd/denog11-29-eng-BGP_Analytics_with_OpenConfig_Telemetry_and_gRPC_sd.mp4?1573484355 466fa15e-1509-5fae-9d83-33cd032bc549 2019-11-11T13:30:00+01:00 Peter Sievers No denog11, 29, 2019 Extracting BGP Telemetry Information from Network devices using vendor-neutral Openconfig data model and gRPC. Importing BGP metrics like received and advertised routes, total prefixes, session flap and more into TICK Stack and using mathematical models to analyse the data to identify anomalies. This talk will discuss the benefits of streaming telemetry in conjunction with vendor independent data models with Openconfig and structured data for analysis versus SNMP and CLI screen scraping. The further processing of the imported metrics is shown using the TICK Stack and Grafana as a dashboard, for an optical visualization of the metrics, the primary focus is on BGP metrics. Having all this metrics collected one can define statistical models to analyse or to correlate the data. For example to use algorithm like 3-sigma rule or k-means to identify anomalies. Kapacitor together with user-defined-function can do the job. To Sum up, collecting different metrics from network devices can help the operator to have some kind of "network fingerprint", with this fingerprint the operator is able to identify anomalies. To easy analyse data you need it in a vendor-neutral structured format and therefore Openconfig data model is a good match. about this event: https://pretalx.denog.de/denog11/talk/QXYMFW/ 00:35:33 https://media.ccc.de/v/denog11-24-rpki-drop-invalids-one-year-later Roughly one year ago we started to drop RPKI invalid routes from our peers. What happened afterwards? In October 2018 we armed our RPKI filters to drop RPKI invalid prefixes. Now a year has passed and it is time to take a look back and see what happened (or didn't happen) after we flipped the switch. Questions that will be answered include: * How much lamentation and hand-wringing was there? * What problems did we face when communicating with the "other side"? * How were the problems fixed? * Do we still filter RPKI invalids or did we go back to the dark ages? about this event: https://pretalx.denog.de/denog11/talk/R3PXYZ/ Mon, 11 Nov 2019 13:00:00 +0100 https://cdn.media.ccc.de/events/denog/denog11/h264-sd/denog11-24-eng-RPKI_drop_invalids_-_one_year_later_sd.mp4?1573481517 2fa1e584-8526-5a6b-8ba7-4f4c2dff71e5 2019-11-11T13:00:00+01:00 Sebastian Wiesinger No denog11, 24, 2019 Roughly one year ago we started to drop RPKI invalid routes from our peers. What happened afterwards? In October 2018 we armed our RPKI filters to drop RPKI invalid prefixes. Now a year has passed and it is time to take a look back and see what happened (or didn't happen) after we flipped the switch. Questions that will be answered include: * How much lamentation and hand-wringing was there? * What problems did we face when communicating with the "other side"? * How were the problems fixed? * Do we still filter RPKI invalids or did we go back to the dark ages? about this event: https://pretalx.denog.de/denog11/talk/R3PXYZ/ 00:33:55 https://media.ccc.de/v/denog11-43-denog11-opening Welcome to DENOG11! Welcome to DENOG11! about this event: https://pretalx.denog.de/denog11/talk/AXL8PH/ Mon, 11 Nov 2019 12:30:00 +0100 https://cdn.media.ccc.de/events/denog/denog11/h264-sd/denog11-43-eng-DENOG11_Opening_sd.mp4?1573478616 0fbb39bb-93d5-54f0-81c5-fa4d49d96db0 2019-11-11T12:30:00+01:00 Patrick Bussmann No denog11, 43, 2019 Welcome to DENOG11! Welcome to DENOG11! about this event: https://pretalx.denog.de/denog11/talk/AXL8PH/ 00:12:08 media.ccc.de / RSS 0.3.1 CCC media team media@c3voc.de CCC media team No CCC Congress Hacking Security Netzpolitik A wide variety of video material distributed by the CCC. All content is taken from cdn.media.ccc.de and media.ccc.de A wide variety of video material distributed by the Chaos Computer Club. This feed contains all events from denog11 as mp4