Dieses Jahr versuchen wir uns auf vielfachen Wunsch an einem noch praktischer orientierten Grundlagen-Vortrag. Wir fangen an bei Verkabelung (Kupfer, Glasfasern, Stecker, etc.), gehen weiter zu Ethernet (STP, VLANs, LAGs / Bonding) und enden unseren Ausflug bei IP und Grundlagen des Debugging (Ping, Traceroute).
Dynamische Routingprotokolle Aufzucht und Pflege - BGPMaximilan Wilhelm
Sie möchten Ihr großes internes Netzwerk - ein Autonomes System - mit dem Internet verbinden, eine IP-Fabric aufbauen oder interne Dienste per Anycast in Ihrem Netzwerk anbieten. Für all diese Dinge ist das Border Gateway Protokoll entwickelt worden und auch hervorragend geeignet.
Dieser Vortag vermittelt die Funktionsweise von BGP im externen und internen Einsatz, gibt einen Überblick über die Steuermechanismen und Stellschrauben und zeigt den praktischen Einsatz mit dem Bird Internet Routing Daemon auf.
Nach 20 Jahren IPv6 (RFC2460 erschien im Dezember 1998) und knapp 40% Verbreitung an Deutschlands Internetzugängen stellt sich IPv6 für die meisten Admins immer noch als Mysterium dar. Teilweise wird sogar von führenden Experten empfohlen IPv6 abzuschalten "weil das nur Probleme macht". Warum das nicht so ist, und warum man sich doch auf die "neue" Welt einlassen sollte erklärt dieser praxisorientierte Vortrag.
Der Vortag führt ein in Adresskonzepte, Adressvergabe und -auflösung (SLAAC, DHCPv6, DHCPv6-PD, ND, RDNSS, etc.) und zeigt einen typischen Adressierunsplan auf. Brückentechnologien wie NAT64, DS-lite und Teredo werden vorgestellt und eingeordnet. Die Konfiguration von IPv6 unter Linux wird am Beispiel von iproute2 bzw. Debian Netzwerkkonfiguration sowie sysctls aufgezeigt.
L2/L3 für Fortgeschrittene - Helle und dunkle Magie im Linux-NetzwerkstackMaximilan Wilhelm
Der Switch in meinem Linux-Rechner - was ist eine Bridge und wie benutze ich sie? Was sind VLANs und gar vlan-aware-Bridges? Fesselspiele mit Netzwerkkabeln - Bonding/Channel/Trunks mit und ohne LACP.
Auf Layer 3 tauchen wir ab in die Routingtabellen jedes Linux-Systems (derer gibt’s immer mindestens 3) sowie fortschrittlichere Magie wie policy-based Routing, VRFs und Network Namespaces; Beispiele aus dem echten Leben zeigen, wozu das alles gut ist und wie man damit arbeitet.
Was ist dieses Ethernet, was haben wir da für Geräte und warum? Was tun die? Was hat das mit Bäumen zu tun und wer ist dieses MAC?
Was ist eine IP-Adresse? Wie funktioniert Subnetting mit CIDR und was sind eigentlich diese Netzwerkklassen von denen immernoch Menschen reden? Was sind private und öffentliche IPs und wo bekomme ich die her? Wie konfiguriere ich das alles unter Linux? Was sind Routingtabellen und warum habe ich davon eigentlich mindestens drei Stück?
Dieser Vortrag gibt Antworten auf alle diese Fragen und noch einige mehr. Subnetting nach CIDR bildet die Grundlagen für Routing in heutigen IP-Netzwerken;
RFC1918, RFC3927 und RFC6598 definieren jeweils “private” IP-Bereich für interne Nutzung, für öffentliche IPs haben wir in Europa das RIPE. Eine Einführung in iproute2 zeigt, wie man all das unter Linux “zu Fuß” konfiguriert und wie man die Netzwerkkonfiguration am Beispiel von Debian reboot-save einrichtet.
Dynamische Routingprotokolle Aufzucht und Pflege - OSPFMaximilan Wilhelm
Herzlichen Glückwunsch! Sie dürfen ein Netzwerk mit mehr als 2 Routern administrieren. Dieser Vortrag erläutert, warum statisches Routing keine Lösung ist und schneller als einem lieb ist zum Problem werden kann. Als Einführung in dynamisches Routing und OSPF, erklärt dieser Vortrag wie sich Router gegenseitig finden, Routen austauschen, was eine Area ist und wie die Link-State Datenbank funktioniert.
OSPF wird praktisch am Beispiel des Bird Internet Routing Daemons und in Zusammenspiel mit klassischen Herstellern gezeigt.
Contemporary network configuration for linux - ifupdown-ngMaximilan Wilhelm
There are many different ways to configure networking on Linux. Debian and Alpine use ifupdown1, and Cumulus Networks invented ifupdown2; other distributions have various other systems, such as systemd-networkd and NetworkManager.
This talk will present ifupdown-ng, a new project by the Network Services Association intended as a drop-in replacement for ifupdown1 and ifupdown2 installations. Presently, Alpine and Debian are the primary supported environments. Support for other Linux distributions and BSD is planned.
With its modular design, ifupdown-ng intends to allow flexibility for today's modern networking setups, while being easy to extend.
ifupdown-ng is Open Source and can be found on GitHub at: https://github.com/ifupdown-ng/ifupdown-ng/
Es gibt viele Möglichkeiten hoch verfügbare und/oder skalierbare Dienste zu bauen, die weitläufig im Einsatz sind: DNS Round-Robin, ein Satz Loadbalancer oder Reverse-Proxies, etc. pp. An Anycast und BGP im eigenen Rechenzentrum trauen sich einige Admins und Entscheider nicht heran.
Warum es OK ist, wenn einige bis viele Server die selbe IP-Adresse haben, viele Wege nach Rom führen und wie man so ein Setup aufbaut und betreibt soll in diesem Vortrag praxisnah gezeigt werden. Wir bauen auf Basis von Debian Linux, Bird und Bind einen Cluster von Webservern und spielen ein bisschen damit herum (wenn noch genug Zeit ist).
Intent driven, fully automated deployment of anycasted load balancers with ha...Maximilan Wilhelm
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.
Dynamische Routingprotokolle Aufzucht und Pflege - BGPMaximilan Wilhelm
Sie möchten Ihr großes internes Netzwerk - ein Autonomes System - mit dem Internet verbinden, eine IP-Fabric aufbauen oder interne Dienste per Anycast in Ihrem Netzwerk anbieten. Für all diese Dinge ist das Border Gateway Protokoll entwickelt worden und auch hervorragend geeignet.
Dieser Vortag vermittelt die Funktionsweise von BGP im externen und internen Einsatz, gibt einen Überblick über die Steuermechanismen und Stellschrauben und zeigt den praktischen Einsatz mit dem Bird Internet Routing Daemon auf.
Nach 20 Jahren IPv6 (RFC2460 erschien im Dezember 1998) und knapp 40% Verbreitung an Deutschlands Internetzugängen stellt sich IPv6 für die meisten Admins immer noch als Mysterium dar. Teilweise wird sogar von führenden Experten empfohlen IPv6 abzuschalten "weil das nur Probleme macht". Warum das nicht so ist, und warum man sich doch auf die "neue" Welt einlassen sollte erklärt dieser praxisorientierte Vortrag.
Der Vortag führt ein in Adresskonzepte, Adressvergabe und -auflösung (SLAAC, DHCPv6, DHCPv6-PD, ND, RDNSS, etc.) und zeigt einen typischen Adressierunsplan auf. Brückentechnologien wie NAT64, DS-lite und Teredo werden vorgestellt und eingeordnet. Die Konfiguration von IPv6 unter Linux wird am Beispiel von iproute2 bzw. Debian Netzwerkkonfiguration sowie sysctls aufgezeigt.
L2/L3 für Fortgeschrittene - Helle und dunkle Magie im Linux-NetzwerkstackMaximilan Wilhelm
Der Switch in meinem Linux-Rechner - was ist eine Bridge und wie benutze ich sie? Was sind VLANs und gar vlan-aware-Bridges? Fesselspiele mit Netzwerkkabeln - Bonding/Channel/Trunks mit und ohne LACP.
Auf Layer 3 tauchen wir ab in die Routingtabellen jedes Linux-Systems (derer gibt’s immer mindestens 3) sowie fortschrittlichere Magie wie policy-based Routing, VRFs und Network Namespaces; Beispiele aus dem echten Leben zeigen, wozu das alles gut ist und wie man damit arbeitet.
Was ist dieses Ethernet, was haben wir da für Geräte und warum? Was tun die? Was hat das mit Bäumen zu tun und wer ist dieses MAC?
Was ist eine IP-Adresse? Wie funktioniert Subnetting mit CIDR und was sind eigentlich diese Netzwerkklassen von denen immernoch Menschen reden? Was sind private und öffentliche IPs und wo bekomme ich die her? Wie konfiguriere ich das alles unter Linux? Was sind Routingtabellen und warum habe ich davon eigentlich mindestens drei Stück?
Dieser Vortrag gibt Antworten auf alle diese Fragen und noch einige mehr. Subnetting nach CIDR bildet die Grundlagen für Routing in heutigen IP-Netzwerken;
RFC1918, RFC3927 und RFC6598 definieren jeweils “private” IP-Bereich für interne Nutzung, für öffentliche IPs haben wir in Europa das RIPE. Eine Einführung in iproute2 zeigt, wie man all das unter Linux “zu Fuß” konfiguriert und wie man die Netzwerkkonfiguration am Beispiel von Debian reboot-save einrichtet.
Dynamische Routingprotokolle Aufzucht und Pflege - OSPFMaximilan Wilhelm
Herzlichen Glückwunsch! Sie dürfen ein Netzwerk mit mehr als 2 Routern administrieren. Dieser Vortrag erläutert, warum statisches Routing keine Lösung ist und schneller als einem lieb ist zum Problem werden kann. Als Einführung in dynamisches Routing und OSPF, erklärt dieser Vortrag wie sich Router gegenseitig finden, Routen austauschen, was eine Area ist und wie die Link-State Datenbank funktioniert.
OSPF wird praktisch am Beispiel des Bird Internet Routing Daemons und in Zusammenspiel mit klassischen Herstellern gezeigt.
Contemporary network configuration for linux - ifupdown-ngMaximilan Wilhelm
There are many different ways to configure networking on Linux. Debian and Alpine use ifupdown1, and Cumulus Networks invented ifupdown2; other distributions have various other systems, such as systemd-networkd and NetworkManager.
This talk will present ifupdown-ng, a new project by the Network Services Association intended as a drop-in replacement for ifupdown1 and ifupdown2 installations. Presently, Alpine and Debian are the primary supported environments. Support for other Linux distributions and BSD is planned.
With its modular design, ifupdown-ng intends to allow flexibility for today's modern networking setups, while being easy to extend.
ifupdown-ng is Open Source and can be found on GitHub at: https://github.com/ifupdown-ng/ifupdown-ng/
Es gibt viele Möglichkeiten hoch verfügbare und/oder skalierbare Dienste zu bauen, die weitläufig im Einsatz sind: DNS Round-Robin, ein Satz Loadbalancer oder Reverse-Proxies, etc. pp. An Anycast und BGP im eigenen Rechenzentrum trauen sich einige Admins und Entscheider nicht heran.
Warum es OK ist, wenn einige bis viele Server die selbe IP-Adresse haben, viele Wege nach Rom führen und wie man so ein Setup aufbaut und betreibt soll in diesem Vortrag praxisnah gezeigt werden. Wir bauen auf Basis von Debian Linux, Bird und Bind einen Cluster von Webservern und spielen ein bisschen damit herum (wenn noch genug Zeit ist).
Intent driven, fully automated deployment of anycasted load balancers with ha...Maximilan Wilhelm
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.
This talk will show how to build your own simple, cheap and scalable CGN solutions with stateful-failover with commodity servers with a decent NIC running Linux, nftables, and bird.
We were in need to introduce NAT into the network and a commercial solution would have required a 6 figure invest, so we build it ourselves for <10% of that cost.
Two Dell servers with a recent CPU, two Mellanox NICs and nftables as well as bird do the trick and make for a simple, cheap and scalable CGN box, supporting ECMP, simple draining and orchestration by your usual Linux tool chain as well as stateful-failover.
Video at: https://www.youtube.com/watch?v=qHsHkjhGibA
Overlays & IP-Fabrics - viele Wege führen nach Rom und warum Layer2 keine Lös...Maximilan Wilhelm
SDN ist in aller Munde und Ohren, mindestens auf den Golfplätzen. Welche Technologien Software Defined Netzwerke ermöglichen und warum ein geswitchtes Underlay ab einer bestimmten Größe unhandlich wird und warum Netzwerker gerne Dinge in Dingen einpacken, wird in diesem Vortrag erklärt.
Dieser Vortrag erklärt Begriffe wie GRE, VXLAN und EVPN und erläutert wie man diese unter Linux benutzt, um entsprechende Overlay Strukturen zu etablieren und welchen realweltichen Probleme man damit lösen kann.
Fun with PRB, VRFs and NetNS on Linux - What is it, how does it work, what ca...Maximilan Wilhelm
Linux has become a 1st class Network Citizen for many years and doesn't fall short compared to commercial solutions. It in fact is the very essence many of those are build on and is used as the foundation for nearly all cloud solutions out there.
This talk will touch on methods and features to set up Layer3 network separation and will walk through and show case
* Policy-based routing
* VRFs (with and without MPLS)
* Network Namespaces
We will compare features and options and go through a number of use cases, covering Linux as a router, VPN server, load balancer, etc.
A basic understanding of networking, routing and how the Internet works certainly help, some aha moments will be there in any way.
Best Current Operational Practices - Dos, Don’ts and lessons learnedMaximilan Wilhelm
Max und Falk versammeln knapp 42 Jahre Erfahrung in der Netzwerk- und Open-Source Praxis. In diesem Vortrag stellen sie schmerzhafte Erfahrungen vor und leiten daraus Best Practices für den Netzwerkbetrieb ab. Zusätzlich werden Best Community Practices vorgestellt und der ein oder andere Schwank aus den Anfangszeiten des Internet in Deutschland erzählt.
A novel way of creating overlay networks for OpenNebula is presented here. Using BGP Ethernet VPN (EVPN) with VXLAN data-plane encapsulation. This provides scalable Layer 2 over IP networks.
Building your own sdn with debian linux salt stack and pythonMaximilan Wilhelm
Topics like Infrastructure Automation / Orchestration, Cloud, and Software Defined Networks are on everyones tongue and nearly all network vendors who think highly of themselves provide products and maybe even solutions in this sphere of buzzwords.
Within the last years there has been a paradigm shift towards host and segment routing – think »IP Fabric« – as well as a focus on open protocols and standards like OSPF, IS-IS, BGP & MPLS not only in the data center. This even brought us some new standards like VXLAN and a bunch of open source based “open networking” platforms. Now we aren't always locked to the operating systems of a networking vendor but can choose the control plane software from a variety of Linux based solutions which can be managed and orchestrated by lots of different means.
Thanks to the Linux basis and the Open Source spirit of some vendors, some features (VRFs, MPLS forwarding plane, …) today are part of the upstream Linux kernel and available for everyone! Most notable are the contributions of the Debian Linux based platform from Cumulus Networks, which include the VRF support for Linux, some MPLS patches for FRR and ifupdown2 (which is written in Python :-)).
Putting a bunch of these technologies and ideas together will open up a lot of powerful options for building low budget yet mighty networks. This talk will lay out how to build a SDN based service provide like infrastructure with the help of Salt Stack, some 1000 lines of Python and a bunch of affordable hardware where overlay networks and anycast aren't things to be scared of. The Freifunk Hochstift network and server infrastructure will be used as an example.
The target audience mainly consists of (Linux-) system and network engineers / architects, who already have some experience with the other world. A positive attitude towards automation and magic is a plus.
Demystifying EVPN in the data center: Part 1 in 2 episode seriesCumulus Networks
Network operators are slowly but surely embracing L3-based leaf-spine designs. However, either due to legacy applications or certain multi-tenancy requirements, the need for L2 across racks is still present. How do you solve the problem of providing L2 across multiple racks? EVPN is quickly emerging as the best answer to this question.
In this episode of our 2-part series on EVPN, we start with a discussion of the use cases, a review of the technologies EVPN competes with, and dive into an evaluation of the pros and cons of each.
For a recording of the live event, go to http://go.cumulusnetworks.com/l/32472/2017-09-22/95t27t
VXLAN is a point to point, UDP-based "tunneling" protocol, that enables L2 encapsulation over an L3 "undernet", while also allowing up to 16 million Virtual Networks. One challenge with deploying VXLAN is that by default VXLAN requires multicast support for Broadcast, Unknown and Multi-cast packets. Often this is not possible in customer networks. An alternative approach is to use the Service Node concept where dedicated node(s)/process(es) are responsible for flooding Broadcast, Unknown, and Multicast packets throughout a network.
This removes the need for multi-cast, and greatly simplifies network configuration. However, it does require a scalable, and highly available implementation.
Building DataCenter networks with VXLAN BGP-EVPNCisco Canada
The session specifically covers the requirements and approaches for deploying the Underlay, Overlay as well as the inter-Fabric connectivity of Data Center Networks or Fabrics. Within the VXLAN BGP-EVPN based Overlay, we focus on the insights like forwarding and control plane functions which are critical to the simplicity operation of the architecture in achieving scale, small failure domains and consistent configuration. To complete the overlay view on VXLAN BGP-EVPN, we are going to the insides of BGP and its EVPN address-familiy and extend to about how multiple DC Fabric can be interconnected within, either as stretched Fabrics or with true DCI. The session concludes with a brief overview of manageability functions, network orchestration capabilities and multi-tenancy details. This Advanced session is intended for network, design and operation engineers from Enterprises to Service Providers.
Operationalizing EVPN in the Data Center: Part 2Cumulus Networks
In the second of our two-part series on EVPN, Cumulus Networks Chief Scientist Dinesh Dutt dives into more technical details of network routing, EVPN use cases, and best practices for operationalizing EVPN in the data center.
To view the recording of this webinar, visit http://go.cumulusnetworks.com/l/32472/2017-09-23/95t7xh
AS201701 - Building an Internet backbone with pure 1he servers and LinuxMaximilan Wilhelm
Talk held at May 9th 2017 at #RIPE74 in Budapest about the german Freifunk Backbone running as AS201701 and the efforts it took to build it and keep in running.
See https://ripe74.ripe.net/programme/meeting-plan/plenary/ for a video recording of the talk.
Scaling the Web to Billions of Nodes: Towards the IPv6 “Internet of Things” b...gogo6
gogo6 IPv6 Video Series. Event, presentation and speaker details below:
EVENT
gogoNET LIVE! 4: IPv6 & The Internet of Things. http://gogonetlive.com
November 12 – 14, 201, Silicon Valley, California
Agenda: http://gogonetlive.com/gogonetlive4-agenda.asp
PRESENTATION
Scaling the Web to Billions of Nodes: Towards the IPv6 “Internet of Things”
Abstract: http://www.gogo6.com/profiles/blogs/scaling-the-web-to-billions-of-nodes-towards-the-ipv6-internet-of
Presentation video: http://www.gogo6.com/video/scaling-the-web-to-billions-of-nodes-by-carsten-bormann-at-gogone
Interview video: http://www.gogo6.com/video/interview-with-carsten-bormann-at-gogonet-live-4-ipv6-iot-confere
SPEAKER
Carsten Bormann - Universität Bremen TZI & IETF WG Chair
Bio/Profile: http://www.gogo6.com/profile/CarstenBormann
MORE
Learn more about IPv6 on the gogoNET social network and our online training courses
http://www.gogo6.com/main
Get free IPv6 connectivity with Freenet6
http://www.gogo6.com/Freenet6
Subscribe to the gogo6 IPv6 Channel on YouTube
http://www.youtube.com/subscription_center?add_user=gogo6videos
Follow gogo6 on Twitter
http://twitter.com/gogo6inc
Like gogo6 on Facebook
http://www.facebook.com/pages/IPv6-products-community-and-services-gogo6/161626696777
This talk will show how to build your own simple, cheap and scalable CGN solutions with stateful-failover with commodity servers with a decent NIC running Linux, nftables, and bird.
We were in need to introduce NAT into the network and a commercial solution would have required a 6 figure invest, so we build it ourselves for <10% of that cost.
Two Dell servers with a recent CPU, two Mellanox NICs and nftables as well as bird do the trick and make for a simple, cheap and scalable CGN box, supporting ECMP, simple draining and orchestration by your usual Linux tool chain as well as stateful-failover.
Video at: https://www.youtube.com/watch?v=qHsHkjhGibA
Overlays & IP-Fabrics - viele Wege führen nach Rom und warum Layer2 keine Lös...Maximilan Wilhelm
SDN ist in aller Munde und Ohren, mindestens auf den Golfplätzen. Welche Technologien Software Defined Netzwerke ermöglichen und warum ein geswitchtes Underlay ab einer bestimmten Größe unhandlich wird und warum Netzwerker gerne Dinge in Dingen einpacken, wird in diesem Vortrag erklärt.
Dieser Vortrag erklärt Begriffe wie GRE, VXLAN und EVPN und erläutert wie man diese unter Linux benutzt, um entsprechende Overlay Strukturen zu etablieren und welchen realweltichen Probleme man damit lösen kann.
Fun with PRB, VRFs and NetNS on Linux - What is it, how does it work, what ca...Maximilan Wilhelm
Linux has become a 1st class Network Citizen for many years and doesn't fall short compared to commercial solutions. It in fact is the very essence many of those are build on and is used as the foundation for nearly all cloud solutions out there.
This talk will touch on methods and features to set up Layer3 network separation and will walk through and show case
* Policy-based routing
* VRFs (with and without MPLS)
* Network Namespaces
We will compare features and options and go through a number of use cases, covering Linux as a router, VPN server, load balancer, etc.
A basic understanding of networking, routing and how the Internet works certainly help, some aha moments will be there in any way.
Best Current Operational Practices - Dos, Don’ts and lessons learnedMaximilan Wilhelm
Max und Falk versammeln knapp 42 Jahre Erfahrung in der Netzwerk- und Open-Source Praxis. In diesem Vortrag stellen sie schmerzhafte Erfahrungen vor und leiten daraus Best Practices für den Netzwerkbetrieb ab. Zusätzlich werden Best Community Practices vorgestellt und der ein oder andere Schwank aus den Anfangszeiten des Internet in Deutschland erzählt.
A novel way of creating overlay networks for OpenNebula is presented here. Using BGP Ethernet VPN (EVPN) with VXLAN data-plane encapsulation. This provides scalable Layer 2 over IP networks.
Building your own sdn with debian linux salt stack and pythonMaximilan Wilhelm
Topics like Infrastructure Automation / Orchestration, Cloud, and Software Defined Networks are on everyones tongue and nearly all network vendors who think highly of themselves provide products and maybe even solutions in this sphere of buzzwords.
Within the last years there has been a paradigm shift towards host and segment routing – think »IP Fabric« – as well as a focus on open protocols and standards like OSPF, IS-IS, BGP & MPLS not only in the data center. This even brought us some new standards like VXLAN and a bunch of open source based “open networking” platforms. Now we aren't always locked to the operating systems of a networking vendor but can choose the control plane software from a variety of Linux based solutions which can be managed and orchestrated by lots of different means.
Thanks to the Linux basis and the Open Source spirit of some vendors, some features (VRFs, MPLS forwarding plane, …) today are part of the upstream Linux kernel and available for everyone! Most notable are the contributions of the Debian Linux based platform from Cumulus Networks, which include the VRF support for Linux, some MPLS patches for FRR and ifupdown2 (which is written in Python :-)).
Putting a bunch of these technologies and ideas together will open up a lot of powerful options for building low budget yet mighty networks. This talk will lay out how to build a SDN based service provide like infrastructure with the help of Salt Stack, some 1000 lines of Python and a bunch of affordable hardware where overlay networks and anycast aren't things to be scared of. The Freifunk Hochstift network and server infrastructure will be used as an example.
The target audience mainly consists of (Linux-) system and network engineers / architects, who already have some experience with the other world. A positive attitude towards automation and magic is a plus.
Demystifying EVPN in the data center: Part 1 in 2 episode seriesCumulus Networks
Network operators are slowly but surely embracing L3-based leaf-spine designs. However, either due to legacy applications or certain multi-tenancy requirements, the need for L2 across racks is still present. How do you solve the problem of providing L2 across multiple racks? EVPN is quickly emerging as the best answer to this question.
In this episode of our 2-part series on EVPN, we start with a discussion of the use cases, a review of the technologies EVPN competes with, and dive into an evaluation of the pros and cons of each.
For a recording of the live event, go to http://go.cumulusnetworks.com/l/32472/2017-09-22/95t27t
VXLAN is a point to point, UDP-based "tunneling" protocol, that enables L2 encapsulation over an L3 "undernet", while also allowing up to 16 million Virtual Networks. One challenge with deploying VXLAN is that by default VXLAN requires multicast support for Broadcast, Unknown and Multi-cast packets. Often this is not possible in customer networks. An alternative approach is to use the Service Node concept where dedicated node(s)/process(es) are responsible for flooding Broadcast, Unknown, and Multicast packets throughout a network.
This removes the need for multi-cast, and greatly simplifies network configuration. However, it does require a scalable, and highly available implementation.
Building DataCenter networks with VXLAN BGP-EVPNCisco Canada
The session specifically covers the requirements and approaches for deploying the Underlay, Overlay as well as the inter-Fabric connectivity of Data Center Networks or Fabrics. Within the VXLAN BGP-EVPN based Overlay, we focus on the insights like forwarding and control plane functions which are critical to the simplicity operation of the architecture in achieving scale, small failure domains and consistent configuration. To complete the overlay view on VXLAN BGP-EVPN, we are going to the insides of BGP and its EVPN address-familiy and extend to about how multiple DC Fabric can be interconnected within, either as stretched Fabrics or with true DCI. The session concludes with a brief overview of manageability functions, network orchestration capabilities and multi-tenancy details. This Advanced session is intended for network, design and operation engineers from Enterprises to Service Providers.
Operationalizing EVPN in the Data Center: Part 2Cumulus Networks
In the second of our two-part series on EVPN, Cumulus Networks Chief Scientist Dinesh Dutt dives into more technical details of network routing, EVPN use cases, and best practices for operationalizing EVPN in the data center.
To view the recording of this webinar, visit http://go.cumulusnetworks.com/l/32472/2017-09-23/95t7xh
AS201701 - Building an Internet backbone with pure 1he servers and LinuxMaximilan Wilhelm
Talk held at May 9th 2017 at #RIPE74 in Budapest about the german Freifunk Backbone running as AS201701 and the efforts it took to build it and keep in running.
See https://ripe74.ripe.net/programme/meeting-plan/plenary/ for a video recording of the talk.
Scaling the Web to Billions of Nodes: Towards the IPv6 “Internet of Things” b...gogo6
gogo6 IPv6 Video Series. Event, presentation and speaker details below:
EVENT
gogoNET LIVE! 4: IPv6 & The Internet of Things. http://gogonetlive.com
November 12 – 14, 201, Silicon Valley, California
Agenda: http://gogonetlive.com/gogonetlive4-agenda.asp
PRESENTATION
Scaling the Web to Billions of Nodes: Towards the IPv6 “Internet of Things”
Abstract: http://www.gogo6.com/profiles/blogs/scaling-the-web-to-billions-of-nodes-towards-the-ipv6-internet-of
Presentation video: http://www.gogo6.com/video/scaling-the-web-to-billions-of-nodes-by-carsten-bormann-at-gogone
Interview video: http://www.gogo6.com/video/interview-with-carsten-bormann-at-gogonet-live-4-ipv6-iot-confere
SPEAKER
Carsten Bormann - Universität Bremen TZI & IETF WG Chair
Bio/Profile: http://www.gogo6.com/profile/CarstenBormann
MORE
Learn more about IPv6 on the gogoNET social network and our online training courses
http://www.gogo6.com/main
Get free IPv6 connectivity with Freenet6
http://www.gogo6.com/Freenet6
Subscribe to the gogo6 IPv6 Channel on YouTube
http://www.youtube.com/subscription_center?add_user=gogo6videos
Follow gogo6 on Twitter
http://twitter.com/gogo6inc
Like gogo6 on Facebook
http://www.facebook.com/pages/IPv6-products-community-and-services-gogo6/161626696777
Data center interconnects multimode vs. single modeAngelina Li
The rapid growth in storage and computing services is driving an expansion in both the physical size
and overall computing power of the modern data center. This high-speed data interconnects linking
the individual optical elements within a data center are typically comprised of fiber optical solutions
(multimode or single-mode)
JTOPTICS® 100Gb/s transceiver module, meticulously crafted for optical communication applications in compliance with the 100G 4WDM 10 MSA. This module adeptly converts four input channels of 25Gb/s electrical data into four channels of CWDM optical signals, subsequently multiplexing them into a single channel for 100Gb/s optical transmission. On the receiver side, the module reversely demultiplexes a 100Gb/s optical input into four channels of CWDM optical signals, converting them into four output channels of electrical data. Equipped with high-performance cooled CWDM DFB transmitters and highly sensitive PIN receivers, this module delivers superior performance for 100 Gigabit Ethernet applications, reaching up to 10km.
Key Features:
1. Hot-pluggable QSFP28 form factor for convenient installation.
2. Maximum link length of 10km over single-mode fiber.
3. Incorporates 4 x 26Gb/s DFB-based CWDM cooling transmitters.
4. Features 4 channels PIN ROSA (Receiver Optical Sub-Assembly).
5. Internal Clock and Data Recovery (CDR) circuits for both receiver and transmitter channels.
6. Supports CDR bypass for enhanced flexibility.
7. Transmission data rate of up to 26Gbps per channel.
8. Utilizes a duplex LC connector for streamlined connectivity.
9. Compliant with IEEE 802.3ba 100GBASE LR4, IEEE 802.3bm, SFF 8665, and SFF 8636 standards.
10. Maximum power dissipation of 4W.
11. Operates on a single 3.3V power supply for simplified power management.
12. RoHS 6 compliant, adhering to environmental standards by being lead-free.
The DMM line card is a single-slot line card for use in any of the GigaMux 3200 chassis and is compatible with CWDM and DWDM channels. The module supports 2 x Gigabit Ethernet, 2 x 1G Fibre Channel, or a single port of each protocol. By using the multiplexing features of this card, the operator can double their existing capacity to carry data services more efficiently.
A quick overview of Data Networking that I gave to a technical group who wanted an introduction to data communications. I hope someone finds a use for it. Msg me if you want to the original pres.
The IEEE 802 is a family of IEEE standards dealing with Local Area Networks and Metropolitan Area Networks. The IEEE 802 family of standards is maintained by the IEEE 802 LAN/MAN Standards Committee (LMSC).
The most widely used standards are for the Bridging and Virtual Bridged LANs (802.1), Ethernet family (802.3), Token Ring (802.5) and Wireless LAN (802.11).
The Ethernet physical layer is the physical layer component of the Ethernet standard.
The Ethernet physical layer evolved over a considerable time span and encompasses quite a few physical media interfaces and several magnitudes of speed. The speed ranges from 1 Mbit/s to 100 Gbit/s in speed while the physical medium can range from bulky coaxial cable to twisted pair to optical fiber. In general, network protocol stack software will work similarly on all of the following types.
10 Gigabit Ethernet is becoming more popular in both enterprise and carrier networks, with 40 Gbit/s and 100 Gbit/s Ethernet now ratified. Higher speeds are under development. Metcalfe now believes commercial applications using terabit Ethernet may occur by 2015 though he says existing Ethernet standards may have to be overthrown to reach terabit Ethernet.ThesisScientist.com
ER(Entity Relationship) Diagram for online shopping - TAEHimani415946
https://bit.ly/3KACoyV
The ER diagram for the project is the foundation for the building of the database of the project. The properties, datatypes, and attributes are defined by the ER diagram.
1.Wireless Communication System_Wireless communication is a broad term that i...JeyaPerumal1
Wireless communication involves the transmission of information over a distance without the help of wires, cables or any other forms of electrical conductors.
Wireless communication is a broad term that incorporates all procedures and forms of connecting and communicating between two or more devices using a wireless signal through wireless communication technologies and devices.
Features of Wireless Communication
The evolution of wireless technology has brought many advancements with its effective features.
The transmitted distance can be anywhere between a few meters (for example, a television's remote control) and thousands of kilometers (for example, radio communication).
Wireless communication can be used for cellular telephony, wireless access to the internet, wireless home networking, and so on.
Multi-cluster Kubernetes Networking- Patterns, Projects and GuidelinesSanjeev Rampal
Talk presented at Kubernetes Community Day, New York, May 2024.
Technical summary of Multi-Cluster Kubernetes Networking architectures with focus on 4 key topics.
1) Key patterns for Multi-cluster architectures
2) Architectural comparison of several OSS/ CNCF projects to address these patterns
3) Evolution trends for the APIs of these projects
4) Some design recommendations & guidelines for adopting/ deploying these solutions.
This 7-second Brain Wave Ritual Attracts Money To You.!nirahealhty
Discover the power of a simple 7-second brain wave ritual that can attract wealth and abundance into your life. By tapping into specific brain frequencies, this technique helps you manifest financial success effortlessly. Ready to transform your financial future? Try this powerful ritual and start attracting money today!
3. Who's who Falk Stern
Full Stack Infrastructure Engineer
IPv6 fanboy
Runs his own Kubernetes cluster in his basement
Consultant @ Profi Engineering Systems AG
Contact
@wrf42
falk@fourecks.de
3 / 64
4. Who's who Maximilian Wilhelm
Infrastructure Engineer
OpenSource Hacker
Fanboy of
(Debian) Linux
IPv6
Occupation:
By day: Senior Infrastructure Architect, Uni Paderborn
By night: Infrastructure Archmage, Freifunk Hochstift
In between: Freelance Solution Architect for hire
Contact
@BarbarossaTM
max@sdn.clinic
4 / 64
6. Who's who
Models
Layer models - ISO/OSI, TCP/IP & Hybrid
Physical
Wires, Wireless - 802.3 & 802.11 (Bit)
Data Link
Addressing stations on the same physical medium (Ethernet MAC) (Frame)
Network
Adressing stations somewhere in the entire network (IPv4, IPv6) (Packet)
Transport
How to transport data? (Datagram, Segment)
Session, Presentation, Application
Which data to transport? (SSH, IRC, HTTP, etc.)
6 / 64
8. Who's who
Models
Layer 1
Air
802.11ac
802.11ax
Real copper cables
Usually Category 7 today
Category 6a is usually fine
Fiber
Multi mode fiber (MMF)
Single mode fiber (SMF)
Specials
Direct Attached Cable (DAC)
Active Optical Cable (AOC) Source: Wikimedia commons
The medium is the message
8 / 64
10. Who's who
Models
Layer 1
Wireless
Channels between 20 and 160 MHz
Channels usually overlap
2.4 GHz is dead, as well as 802.11abg
Problem with 5 GHz Channels is Radar DFS (Dynamic Frequency Selection)
Channelwidths above 20 MHz only usable in 5 GHz bands
10 / 64
11. Who's who
Models
Layer 1
Wireless Encryption
Started with a 40 Bit WEP key, 104 bit did cost extra
Currently WPA3 with PSK or EAP
EAP usually authenticates against a RADIUS server
PSK is "safe enough" for home use
11 / 64
13. Who's who
Models
Layer 1
Types of fibers
Multi mode fiber
Single mode fiber
Form factors of connectors
ST
SC
LC
E2000
MTO/MTP
Contact of connectors
PC
APC
Let's talk about bers
13 / 64
14. Who's who
Models
Layer 1
Usually used at 850nm
Attenuation between 1,5 - 3dB/km
Only suited for shorter ranges
Light is bouncing off the "edges"
Category Color code Fiber type
OM1 orange G62,5/125
OM2 orange G50/125
OM3 aqua G50/125
OM4 violet G50/125
OM5 lime G50/125
Acceptance
cone
Cladding
Cladding
Core
Multi mode ber (MMF)
https://de.wikipedia.org/wiki/Lichtwellenleiter#Multimodefaser 14 / 64
15. Who's who
Models
Layer 1
Usually used between 1270nm &
1610nm
Attenuation 0,4 - 1,0dB/km
Suited for long range connections
Light travels "straight"
Category Color code Fiber type
OS1 yellow E9/125
OS2 yellow E9/125
Single mode ber (SMF)
15 / 64
16. Who's who
Models
Layer 1
Maximum ber lengths*
Multi mode values depending on category!
The following values ignore
Use of amplifiers
Use of WDM
Number of patches
Connector types
Contact types
Speed Multi mode Single mode
1Gb/s ≤1000m ≤ 1km
10Gb/s ≤ 500m ≤ 80km
40Gb/s ≤ 150m ≤ 80km
100Gb/s ≤ 100m ≤ 80km
* This is a very rough overview 16 / 64
17. Who's who
Models
Layer 1
ST / Straight Tip (1992)
Still seen in the wild
Legacy infrastructure
SC / Standard connector (1993)
Used on older optics
Still in wide use on panels
24 duplex ports per RU
LC / Lucent/Little connector (2002)
De facto standard today
In wide use on optics & panels
48 duplex ports per RU
Common optical ber connectors
17 / 64
18. Who's who
Models
Layer 1
E2000 / LSH (1997)
Dust caps included
prevents you from looking into
the beam
More expensive
Usually used for MAN/WAN links
Multiple-Fiber Push-On/Pull-off
(MPO/MTP)
Connects up to 24 cores
Usually used within data centers
e.g. rear connection for panels
Source (MTP): Wikimedia commons
Common optical ber connectors (contd.)
18 / 64
19. Who's who
Models
Layer 1
Physical contact (PC)
Slightly convex surface
Mostly blue connectors bodies
Angled physical contact (APC)
Fiber end face polished at 8° angle
Green connector body
Contact type usually denoted as suffix:
LC/PC
E2000/APC
Common optical connectors / contact
https://en.wikipedia.org/wiki/Optical_fiber_connector#Contact 19 / 64
24. Who's who
Models
Layer 1
Transceivers
introduced 2002
slightly smaller than XENPAK
consume less power than XENPAK
obsoleted by XFP, SFP+
connectors
SC
CX4
converter to SFP / SFP+
supported speeds:
1Gb/s (via converter)
10Gb/s
Transceivers - X2
24 / 64
25. Who's who
Models
Layer 1
Transceivers
introduced 2002/2003
much smaller than X2
slightly larger than SFP(+)
obsoleted by SFP+
connectors
LC
supported speeds:
10Gb/s
Source: Wikimedia commons
Transceivers - XFP
25 / 64
26. Who's who
Models
Layer 1
Transceivers
introduced 2006
much smaller than XENPAK, X2
slightly smaller than XFP
same size as SFP
compatible to SFP
connectors:
RJ45
LC
DAC
AOC
supported speeds:
1Gb/s
10Gb/s
Transceivers - SFP+
26 / 64
27. Who's who
Models
Layer 1
Transceivers
Quad SFP+
4 channels of 10Gb/s
slightly larger than SFP
fanout possible to 4x 10Gb/s
connectors:
LC
MTO/MTP
DAC
AOC
supported speeds:
10Gb/s
40Gb/s
Transceivers - QSFP+
27 / 64
28. Who's who
Models
Layer 1
Transceivers
4 channels of 28Gb/s
same size as QSFP(+)
compatible to QSFP+
fanout possible to
4x 10Gb/s
4x 25Gb/s
connectors:
LC
MTO/MTP
DAC
AOC
supported speeds:
10Gb/s
25Gb/s
40Gb/s
100Gb/s
Transceivers - QSFP28
28 / 64
29. Who's who
Models
Layer 1
Transceivers
one channel of 28Gb/s
same size as SFP(+)
compatible to SFP+
connectors:
LC
DAC
AOC
supported speeds:
1Gb/s
10Gb/s
25Gb/s
Transceivers - SFP28
29 / 64
30. Who's who
Models
Layer 1
Transceivers
Double-density Quad-SFP
8 channel of 50Gb/s
same size as QSFP*
fanout possible to
4x 100Gb/s
connectors:
LC
DAC
AOC
MTO/MTP
supported speeds:
400Gb/s
Transceivers - DD-QSFP
30 / 64
31. Who's who
Models
Layer 1
Outlook - CWDM
Coarse Wavelength Division Multiplexing
Using different wavelength on the same fiber
https://community.fs.com/de/blog/wdm-technology-basis-cwdm-vs-dwdm.html 31 / 64
32. Who's who
Models
Layer 1
Outlook - CWDM
Coarse Wavelength Division Multiplexing
Using different wavelength on the same fiber
Requires transceiver with specific "color"
https://community.fs.com/de/blog/wdm-technology-basis-cwdm-vs-dwdm.html 32 / 64
33. Who's who
Models
Layer 1
Copper based cable of fixed length
Transceiver permanently attached
SFP+/SFP28
QSFP/QSFP28
Available from 1Gb/s to 400Gb/s
Pros:
Much cheaper than fiber link
Simple
Cons:
Only useful within one / between
adjacent racks
Slightly higher latency
Susceptible for EM interference
Specials - Direct Attached Cable (DAC)
33 / 64
34. Who's who
Models
Layer 1
Specials - Active Optical Cable (AOC)
Fiber based cable of fixed length
Transceiver permanently attached
SFP+/SFP28
QSFP+/QSFP28
DD-QSFP
Available from 10Gb/s to 400Gb/s
Pros:
Slightly less attenuation than manual optical connection
At higher bandwidth cheaper than transceiver + cable
Cons:
Only useful within one / between adjacent racks
34 / 64
36. Who's who
Models
Layer 1
Layer 2
Ethernet
Developed between 1973 and 1974 at Xerox
Inspired by ALOHAnet, the Packet Radio Network on Hawaii
At first available with 2,94 Mbps, 10 Mbps available commercially since 1980
Further development lead to IEEE standard 802.3 in 1983
CSMA/CD - "Carrier Sense, Multiple Access, Collision Detect"
Ethernet today:
Common access port speed: 1 Gbit/s
Common uplink/server interfaces speed: 10 - 40 Gbit/s
Up to 400-Gbit/s available commercially
Interfaces for copper or multi-mode / single-mode fiber
Preamble SFD
Source
MAC
Address
Destination
MAC
Address
EtherType FCSPayload
Source: Wikimedia Commons
36 / 64
37. Who's who
Models
Layer 1
Layer 2
Ethernet Technology
Repeater
Maximum Segmentlength in on network segment around 100m
Repeater amplify and repeat signals
Extend broadcast domains
Extend collision domains
Bridges
Extend broadcast domains
Limit collision domains
Important Rule: Frames must not be send out on port where they were received
37 / 64
38. Who's who
Models
Layer 1
Layer 2
Ethernet Devices
Hubs
Repeater with many ports
Switches
Bridges with many ports
Three possible actions to happen with any frame:
Forward
Replicate
Drop
38 / 64
39. Who's who
Models
Layer 1
Layer 2
Addresses
Format: AA:BB:CC:DD:EE:FF
Identify stations on the same physical medium
Should be unique (on the medium)
1st octet 2nd octet 3rd octet 4th octet 5th octet 6th octet
6 octets
or
Organisationally Unique
Identifier (OUI)
Network Interface Controller
(NIC) Specific
3 octets 3 octets
b7 b6 b5 b4 b3 b2 b1 b0
8 bits
0:
1:
unicast
multicast
0:
1:
globally unique (OUI enforced)
locally administered
Source: Wikipedia Commons
39 / 64
40. Who's who
Models
Layer 1
Layer 2
Linux command line example
$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN mode DEFAULT group default qlen 1000
link/ether 70:5a:0f:cf:21:f3 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq
state UP mode DORMANT group default qlen 1000
link/ether 64:80:99:cf:66:6f brd ff:ff:ff:ff:ff:ff
11: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 [...]
link/none
40 / 64
41. Who's who
Models
Layer 1
Layer 2
Spanning Tree
Protocol for loop prevention within ethernet networks
Create logical tree of network topology based on BPDUs
Will block connections which will produce loops
Only deactivate STP if you really know better
Seriously!
41 / 64
43. Who's who
Models
Layer 1
Layer 2
LAGs
Link Aggregation
Combine one or more physical links between two peers to one virtual link, to
increase over-all bandwidth
create a redundant Layer 2 link
both
Also know as:
LAG
Bonding (Linux)
Aggregated Ethernet (Juniper)
Port-Channel (Cisco)
Trunk (3Com, HP?)
NIC-Teaming
43 / 64
44. Who's who
Models
Layer 1
Layer 2
LAGs
Link Aggregation - Simple Linux bonding
Just use multiple links and hope the peer does, too.
Drawbacks:
If media converters are involved a link-down event may not propagate
No way to tell it the peer is configured the same way
44 / 64
45. Who's who
Models
Layer 1
Layer 2
LAGs
Link Aggregation - LACP
Link Aggregation Control Protocol (802.3ad / 802.1AX)
De-facto standard within networking world
Use LACP signalling to set up LAG with peer
Maximum of 8 interface per LAG
Keep alive every 1s (fast) or every 30s (slow)
An interface can be on one of two modes:
active: send out LACP packets to activly form the LAG
passive: wait for and only then reply to LACP packets
45 / 64
46. Who's who
Models
Layer 1
Layer 2
LAGs
Multi-Chassis Link Aggregation Groups
Link Aggregation between more than two peers
At least on peer has to do magic to make this work
Also know as:
MC-LAG
MLAG
Virtual Port-Channel (vPC)
Source: Wikipedia
46 / 64
47. Who's who
Models
Layer 1
Layer 2
LAGs
Loadbalancing Tra c over LAGs
Round-Robin
One packet on link 1, one on link 2, ..., and repeat
Hashing of header elds
Layer 2 (src MAC + dst MAC)
Only useful if communication is to multiple stations within local subnet
Layer 2+3 (src MAC + dst MAC + src IP + dst IP)
Might be more useful for communication without local subnet
Layer 3+4 (src IP + dst IP + src Port + dst Port)
Probably most useful when communicating with multiple peers
47 / 64
51. Who's who
Models
Layer 1
Layer 2
Layer 3
IPv4 Adresses
Identify stations within and beyond subnets
Up to - but not limited to - the Internet
32bit long
Composed of 4 octets
127.0.0.1
192.168.178.42
Subdived into network and host part
What is now known as the Internet started as a research project in the 1970s to
design and develop a set of protocols that could be used with many different
network technologies to provide a seamless, end- to-end facility for
interconnecting a diverse set of end systems.
Source: RFC4632, Section 2
51 / 64
52. Who's who
Models
Layer 1
Layer 2
Layer 3
Network Classes (historical!)
Deprecated since 1993 (RFC1519)!!1!
Long live CIDR / VLSM
Correct and complete definition given for historical attribution only!
DO NOT USE IN REAL LIFE ANYMORE! SRSLY!
Class Binary Prefix IP Space Default Mask
A 0... 0.0.0.0 - 127.255.255.255 /8
B 10.. 128.0.0.0 - 191.255.255.255 /16
C 11.. 192.0.0.0 - 223.255.255.255 /24
D 1110 224.0.0.0 - 239.255.255.255
E 1111 240.0.0.0 - 255.255.255.255
52 / 64
53. Who's who
Models
Layer 1
Layer 2
Layer 3
Subnetting - CIDR / VLSM
Classless Interdomain Routing
Variable Length Subnet Mask
Introduced in 1993, RFC4632 (original RFC1519)
Prefix Notation -> Number of bits in network part of address
255.255.255.0 == 24 Bit netmask == /24
53 / 64
54. Who's who
Models
Layer 1
Layer 2
Layer 3
Pre xes to know/ Private stu
Loopback
127.0.0.0/8
RFC1918 - Private Address Space
10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16
RFC3927 - APIPA / Link-Local
169.254.0.0/16
RFC6598 - Shared Address Space (CGN)
100.64.0.0/10
RFC5737 - Documentation prefixes
192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24
RFC8190 - Special-Purpose IP Address Registries
Complete list of special prefixes
54 / 64
55. Who's who
Models
Layer 1
Layer 2
Layer 3
Linuxcommand line example
$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN [...]
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 state DOWN [...]
link/ether 70:5a:0f:cf:21:f3 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP [...]
link/ether 64:80:99:cf:66:6f brd ff:ff:ff:ff:ff:ff
inet 192.168.178.5/24 brd 192.168.178.255 scope global dynamic wlan0
valid_lft 2450sec preferred_lft 2450sec
inet6 fe80::668:0cff:fecf:666f/64 scope link
valid_lft forever preferred_lft forever
11: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 [...]
link/none
inet 10.23.42.8/25 brd 10.23.42.127 scope global ffho-ops
valid_lft forever preferred_lft forever
inet6 fe80::3f59:2a39:b0e1:92ec/64 scope link flags 800
valid_lft forever preferred_lft forever
55 / 64
56. Who's who
Models
Layer 1
Layer 2
Layer 3
ARP - Address Resolution Protocol
Glue between Ethernet and IPv4
Simple protocol to resolve MAC address of IP peer
Two messages types
who-has
is-at
A B
ARP WHO-HAS 192.168.178.8
192.168.178.8 IS-AT 64:80:99:CF:66:6F
A B
56 / 64
57. Who's who
Models
Layer 1
Layer 2
Layer 3
Routing
Every device speaking IP has a routing table
German translation according to IBM: "Leitwegtabelle"
Packets are forwarded according to longest prefix match
Default Gateway or Gateway of last resort used if no entry matches
Hot Potato principle
Packets forwarded to next hop w/o knowledge of their routing table
Asymmetric routing
Path to destination and return path don't have to be identical
57 / 64
58. Who's who
Models
Layer 1
Layer 2
Layer 3
Routing table
Possible routing table of your laptop when using company VPN:
Prefix Iface Next-hop
10.0.0.0/8 tun0 10.23.42.1
10.23.42.0/25 tun0
192.168.178.0/24 wlan0
0.0.0.0/0 wlan0 192.168.178.1
58 / 64
59. Who's who
Models
Layer 1
Layer 2
Layer 3
Source Address Selection
With every routing decision for a locally originated connection a source address is
selected based on the routing table.
Usually the (primary) IP configured on the outgoing interface
May be explicitly set to any IP
For example IP on loopback interface
Prefix Iface Next-hop Src address
10.0.0.0/8 tun0 10.23.42.1
10.23.42.0/25 tun0 10.23.42.8
192.168.178.0/24 wlan0 192.168.178.5
0.0.0.0/0 wlan0 192.168.178.1
59 / 64
60. Who's who
Models
Layer 1
Layer 2
Layer 3
MTU/MSS
Maximum Transmission Unit
Maximum size of a frame
Usually 1500 Bytes in Ethernet networks
Usually >= 9000 Bytes in service provider backbones (Jumbo Frames)
Maximum Segment Size
Maximum size of a segment which fits into a TCP packet
MTU - 60 Bytes
60 / 64
61. Who's who
Models
Layer 1
Layer 2
Layer 3
ICMP - Ping
Echo request / Echo reply messages
Time between request and reply is measured
measures round trip latency
paths can differ
$ ping -c 3 www.heise.de
PING www.heise.de (193.99.144.85): 56 data bytes
64 bytes from 193.99.144.85: icmp_seq=0 ttl=247 time=14.149 ms
64 bytes from 193.99.144.85: icmp_seq=1 ttl=247 time=29.102 ms
64 bytes from 193.99.144.85: icmp_seq=2 ttl=247 time=30.070 ms
--- www.heise.de ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 14.149/24.440/30.070/7.288 ms
61 / 64
62. Who's who
Models
Layer 1
Layer 2
Layer 3
ICMP - Traceroute
Sends echo requests with increasing TTL
Expects ICMP TTL Exceeded in Transit notifications
$ traceroute kilbeggan.fourecks.de
traceroute to kilbeggan.fourecks.de (88.198.54.132), 64 hops max, 52 byte packets
1 fritz.box (192.168.178.1) 2.243 ms 4.264 ms 14.443 ms
2 192.0.0.1 (192.0.0.1) 8.315 ms 8.309 ms 7.171 ms
3 62.214.38.173 (62.214.38.173) 7.167 ms 10.843 ms 14.588 ms
4 62.214.37.134 (62.214.37.134) 13.658 ms
62.214.37.130 (62.214.37.130) 11.569 ms
62.214.37.134 (62.214.37.134) 14.127 ms
5 versatel-gw.hetzner.com (213.239.239.45) 13.212 ms 12.322 ms 17.035 ms
6 core1.fra.hetzner.com (213.239.245.125) 19.927 ms 22.543 ms
core5.fra.hetzner.com (213.239.224.218) 13.700 ms
7 core23.fsn1.hetzner.com (213.239.229.74) 27.851 ms *
core24.fsn1.hetzner.com (213.239.252.42) 50.545 ms
8 ex9k1.dc13.fsn1.hetzner.com (213.239.245.242) 14.976 ms
ex9k1.dc13.fsn1.hetzner.com (213.239.245.238) 16.691 ms 15.347 ms
9 kilbeggan.fourecks.de (88.198.54.132) 17.902 ms 47.793 ms 22.902 ms
62 / 64
63. Who's who
Models
Layer 1
Layer 2
Layer 3
More?
Future Reading
FrOSCon Network Track 2018:
https://myfirst.network/
Introduction to networking by Ben Eater:
https://www.youtube.com/playlist?
list=PLowKtXNTBypH19whXTVoG3oKSuOcw_XeW
How Autonegotiation works:
https://daemons.net/networking/ethernet/auto-negotiation.html
Alles was ihr schon immer über Glasfasern wissen wolltet:
https://media.ccc.de/v/gpn18-13-alles-was-ihr-schon-immer-ber-glasfasern-wissen-
wolltet
Wie kommt eigentlich das Internet von Hamburg nach Stuttgart
https://media.ccc.de/v/gpn17-8524-
wie_kommt_eigentlich_das_internet_von_hamburg_nach_stuttgart
63 / 64