DOCSLIB.ORG

Linux Networking Documentation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Linux Networking Documentation Linux Networking Documentation The kernel development community Jul 14, 2020 CONTENTS i ii Linux Networking Documentation Contents: CONTENTS 1 Linux Networking Documentation 2 CONTENTS CHAPTER ONE NETDEV FAQ 1.1 Q: What is netdev? A: It is a mailing list for all network-related Linux stuff. This includes anything found under net/ (i.e. core code like IPv6) and drivers/net (i.e. hardware specific drivers) in the Linux source tree. Note that some subsystems (e.g. wireless drivers) which have a high volume of traffic have their own specific mailing lists. The netdev list is managed (like many other Linux mailing lists) through VGER (http://vger.kernel.org/) and archives can be found below: • http://marc.info/?l=linux-netdev • http://www.spinics.net/lists/netdev/ Aside from subsystems like that mentioned above, all network-related Linux de- velopment (i.e. RFC, review, comments, etc.) takes place on netdev. 1.2 Q: How do the changes posted to netdev make their way into Linux? A: There are always two trees (git repositories) in play. Both are driven by David Miller, the main network maintainer. There is the net tree, and the net-next tree. As you can probably guess from the names, the net tree is for fixes to existing code already in the mainline tree from Linus, and net-next is where the new code goes for the future release. You can find the trees here: • https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git • https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git 3 Linux Networking Documentation 1.3 Q: How often do changes from these trees make it to the mainline Linus tree? A: To understand this, you need to know a bit of background information on the cadence of Linux development. Each new release starts off with a two “week merge window”where the main maintainers feed their new stuff to Linus for merging into the mainline tree. After the two weeks, the merge window is closed, and it is called/tagged -rc1. No new features get mainlined after this – only fixes to the rc1 content are expected. After roughly a week of collecting fixes to the rc1 content, rc2 is released. This repeats on a roughly weekly basis until rc7 (typically; sometimes rc6 if things are quiet, or rc8 if things are in a state of churn), and a week after the last vX.Y-rcN was done, the official vX.Y is released. Relating that to netdev: At the beginning of the 2-week merge window, the net-next tree will be closed - no new changes/features. The accumulated new content of the past ~10 weeks will be passed onto mainline/Linus via a pull re- quest for vX.Y – at the same time, the net tree will start accumulating fixes for this pulled content relating to vX.Y An announcement indicating when net-next has been closed is usually sent to netdev, but knowing the above, you can predict that in advance. IMPORTANT: Do not send new net-next content to netdev during the period dur- ing which net-next tree is closed. Shortly after the two weeks have passed (and vX.Y-rc1 is released), the tree for net-next reopens to collect content for the next (vX.Y+1) release. If you aren’t subscribed to netdev and/or are simply unsure if net-next has re-opened yet, simply check the net-next git repository link above for any new networking-related commits. You may also check the following website for the current status: http://vger.kernel.org/~davem/net-next.html The net tree continues to collect fixes for the vX.Y content, and is fed back to Linus at regular (~weekly) intervals. Meaning that the focus for net is on stabilization and bug fixes. Finally, the vX.Y gets released, and the whole cycle starts over. Q: So where are we now in this cycle? Load the mainline (Linus) page here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git and note the top of the “tags”section. If it is rc1, it is early in the dev cycle. If it was tagged rc7 a week ago, then a release is probably imminent. 4 Chapter 1. netdev FAQ Linux Networking Documentation 1.4 Q: How do I indicate which tree (net vs. net-next) my patch should be in? A: Firstly, think whether you have a bug fix or new“next-like”content. Then once decided, assuming that you use git, use the prefix flag, i.e. git format-patch --subject-prefix='PATCH net-next' start..finish Use net instead of net-next (always lower case) in the above for bug-fix net con- tent. If you don’t use git, then note the only magic in the above is just the subject text of the outgoing e-mail, and you can manually change it yourself with whatever MUA you are comfortable with. 1.5 Q: I sent a patch and I’m wondering what happened to it? Q: How can I tell whether it got merged? A: Start by looking at the main patch- works queue for netdev: http://patchwork.ozlabs.org/project/netdev/list/ The “State”field will tell you exactly where things are at with your patch. 1.6 Q: The above only says “Under Review”. How can I find out more? A: Generally speaking, the patches get triaged quickly (in less than 48h). So be patient. Asking the maintainer for status updates on your patch is a good way to ensure your patch is ignored or pushed to the bottom of the priority list. 1.7 Q: I submitted multiple versions of the patch series Q: should I directly update patchwork for the previous versions of these patch series? A: No, please don’t interfere with the patch status on patchwork, leave it to the maintainer to figure out what is the most recent and current version that should be applied. If there is any doubt, the maintainer will reply and ask what should be done. 1.4. Q: How do I indicate which tree (net vs. net-next) my patch should5 be in? Linux Networking Documentation 1.8 Q: I made changes to only a few patches in a patch series should I resend only those changed? A: No, please resend the entire patch series and make sure you do number your patches such that it is clear this is the latest and greatest set of patches that can be applied. 1.9 Q: I submitted multiple versions of a patch series and it looks like a version other than the last one has been accepted, what should I do? A: There is no revert possible, once it is pushed out, it stays like that. Please send incremental versions on top of what has been merged in order to fix the patches the way they would look like if your latest patch series was to be merged. 1.10 Q: How can I tell what patches are queued up for backporting to the various stable releases? A: Normally Greg Kroah-Hartman collects stable commits himself, but for network- ing, Dave collects up patches he deems critical for the networking subsystem, and then hands them off to Greg. There is a patchworks queue that you can see here: http://patchwork.ozlabs.org/bundle/davem/stable/?state=* It contains the patches which Dave has selected, but not yet handed off to Greg. If Greg already has the patch, then it will be here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git A quick way to find whether the patch is in this stable-queue is to simply clonethe repo, and then git grep the mainline commit ID, e.g. stable-queue$ git grep -l 284041ef21fdf2e releases/3.0.84/ipv6-fix-possible-crashes-in-ip6_cork_release.patch releases/3.4.51/ipv6-fix-possible-crashes-in-ip6_cork_release.patch releases/3.9.8/ipv6-fix-possible-crashes-in-ip6_cork_release.patch stable/stable-queue$ 6 Chapter 1. netdev FAQ Linux Networking Documentation 1.11 Q: I see a network patch and I think it should be backported to stable. Q: Should I request it via [email protected] like the references in the kernel’s Documentation/process/stable-kernel-rules.rst file say? A: No, not for networking. Check the stable queues as per above first to see if it is already queued. Ifnot, then send a mail to netdev, listing the upstream commit ID and why you think it should be a stable candidate. Before you jump to go do the above, do note that the normal stable rules in Documentation/process/stable-kernel-rules.rst still apply. So you need to explic- itly indicate why it is a critical fix and exactly what users are impacted. In addition, you need to convince yourself that you really think it has been overlooked, vs. hav- ing been considered and rejected. Generally speaking, the longer it has had a chance to“soak”in mainline, the better the odds that it is an OK candidate for stable. So scrambling to request a commit be added the day after it appears should be avoided. 1.12 Q: I have created a network patch and I think it should be backported to stable. Q: Should I add a Cc: [email protected] like the references in the kernel’s Documentation/ directory say? A: No. See above answer. In short, if you think it really belongs in stable, then ensure you write a decent commit log that describes who gets impacted by the bug fix and how it manifests itself, and when the bugwas introduced.
Load more

  1327
Copy Link
Recommended publications
  • Device Tree 101
    Device Tree 101 Device Tree 101 Organized in partnership with ST February 9, 2021 Thomas Petazzoni embedded Linux and kernel engineering [email protected] © Copyright 2004-2021, Bootlin. Creative Commons BY-SA 3.0 license. Corrections, suggestions, contributions and translations are welcome! - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 1/56 Who is speaking ? I Thomas Petazzoni I Chief Technical Officer at Bootlin I Joined in 2008, employee #1 I Embedded Linux & Linux kernel engineer, open-source contributor I Author of the Device Tree for Dummies talk in 2013/2014 I Buildroot co-maintainer I Linux kernel contributor: ≈ 900 contributions I Member of Embedded Linux Conference (Europe) program committee I Based in Toulouse, France - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 2/56 Agenda I Bootlin introduction I STM32MP1 introduction I Why the Device Tree ? I Basic Device Tree syntax I Device Tree inheritance I Device Tree specifications and bindings I Device Tree and Linux kernel drivers I Common properties and examples - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 3/56 Bootlin I In business since 2004 I Team based in France I Serving customers worldwide I 18% revenue from France I 44% revenue from EU except France I 38% revenue outside EU I Highly focused and recognized expertise I Embedded Linux I Linux kernel I Embedded Linux build systems I Activities
    [Show full text]
  • Improving Route Scalability: Nexthops As Separate Objects
    Improving Route Scalability: Nexthops as Separate Objects September 2019 David Ahern | Cumulus Networks !1 Agenda Executive Summary ▪ If you remember nothing else about this talk … Driving use case Review legacy route API Dive into Nexthop API Benefits of the new API Cumulus Networks !2 Performance with the Legacy Route API route route route prefix/lenroute prefix/lendev prefix/lendev gatewayprefix/len gatewaydev gatewaydev gateway Cumulus Networks !3 Splitting Next Hops from Routes Routes with separate Nexthop objects Legacy Route API route route prefix/len nexthop route nexthop id dev route gateway prefix/lenroute prefix/lendev prefix/lendev gatewayprefix/len gatewaydev gatewaydev gateway route prefix/len nexthop nexthop nexthop id group nexthopdev nexthop[N] gatewaydev gateway Cumulus Networks !4 Dramatically Improves Route Scalability … Cumulus Networks !5 … with the Potential for Constant Insert Times Cumulus Networks !6 Networking Operating System Using Linux APIs Routing daemon or utility manages switchd ip FRR entries in kernel FIBs via rtnetlink APIs SDK userspace ▪ Enables other control plane software to use Linux networking APIs rtnetlink Data path connections, stats, troubleshooting, … FIB notifications FIB Management of hardware offload is separate kernel upper devices tunnels ▪ Keeps hardware in sync with kernel ... eth0 swp1 swp2 swpN Userspace driver with SDK leveraging driver driver driver kernel notifications NIC switch ASIC H / W Cumulus Networks !7 NOS with switchdev Driver In-kernel switchdev driver ip FRR Leverages
    [Show full text]
  • MLNX OFED Documentation Rev 5.0-2.1.8.0
    MLNX_OFED Documentation Rev 5.0-2.1.8.0 Exported on May/21/2020 06:13 AM https://docs.mellanox.com/x/JLV-AQ Notice This document is provided for information purposes only and shall not be regarded as a warranty of a certain functionality, condition, or quality of a product. NVIDIA Corporation (“NVIDIA”) makes no representations or warranties, expressed or implied, as to the accuracy or completeness of the information contained in this document and assumes no responsibility for any errors contained herein. NVIDIA shall have no liability for the consequences or use of such information or for any infringement of patents or other rights of third parties that may result from its use. This document is not a commitment to develop, release, or deliver any Material (defined below), code, or functionality. NVIDIA reserves the right to make corrections, modifications, enhancements, improvements, and any other changes to this document, at any time without notice. Customer should obtain the latest relevant information before placing orders and should verify that such information is current and complete. NVIDIA products are sold subject to the NVIDIA standard terms and conditions of sale supplied at the time of order acknowledgement, unless otherwise agreed in an individual sales agreement signed by authorized representatives of NVIDIA and customer (“Terms of Sale”). NVIDIA hereby expressly objects to applying any customer general terms and conditions with regards to the purchase of the NVIDIA product referenced in this document. No contractual obligations are formed either directly or indirectly by this document. NVIDIA products are not designed, authorized, or warranted to be suitable for use in medical, military, aircraft, space, or life support equipment, nor in applications where failure or malfunction of the NVIDIA product can reasonably be expected to result in personal injury, death, or property or environmental damage.
    [Show full text]
  • Storage Administration Guide Storage Administration Guide SUSE Linux Enterprise Server 12 SP4
    SUSE Linux Enterprise Server 12 SP4 Storage Administration Guide Storage Administration Guide SUSE Linux Enterprise Server 12 SP4 Provides information about how to manage storage devices on a SUSE Linux Enterprise Server. Publication Date: September 24, 2021 SUSE LLC 1800 South Novell Place Provo, UT 84606 USA https://documentation.suse.com Copyright © 2006– 2021 SUSE LLC and contributors. All rights reserved. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”. For SUSE trademarks, see https://www.suse.com/company/legal/ . All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its aliates. Asterisks (*) denote third-party trademarks. All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its aliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof. Contents About This Guide xii 1 Available Documentation xii 2 Giving Feedback xiv 3 Documentation Conventions xiv 4 Product Life Cycle and Support xvi Support Statement for SUSE Linux Enterprise Server xvii • Technology Previews xviii I FILE SYSTEMS AND MOUNTING 1 1 Overview
    [Show full text]
  • The Linux Kernel Module Programming Guide
    The Linux Kernel Module Programming Guide Peter Jay Salzman Michael Burian Ori Pomerantz Copyright © 2001 Peter Jay Salzman 2007−05−18 ver 2.6.4 The Linux Kernel Module Programming Guide is a free book; you may reproduce and/or modify it under the terms of the Open Software License, version 1.1. You can obtain a copy of this license at http://opensource.org/licenses/osl.php. This book is distributed in the hope it will be useful, but without any warranty, without even the implied warranty of merchantability or fitness for a particular purpose. The author encourages wide distribution of this book for personal or commercial use, provided the above copyright notice remains intact and the method adheres to the provisions of the Open Software License. In summary, you may copy and distribute this book free of charge or for a profit. No explicit permission is required from the author for reproduction of this book in any medium, physical or electronic. Derivative works and translations of this document must be placed under the Open Software License, and the original copyright notice must remain intact. If you have contributed new material to this book, you must make the material and source code available for your revisions. Please make revisions and updates available directly to the document maintainer, Peter Jay Salzman <[email protected]>. This will allow for the merging of updates and provide consistent revisions to the Linux community. If you publish or distribute this book commercially, donations, royalties, and/or printed copies are greatly appreciated by the author and the Linux Documentation Project (LDP).
    [Show full text]
  • Gigabit Ethernet - CH 3 - Ethernet, Fast Ethernet, and Gigabit Ethern
    Switched, Fast, and Gigabit Ethernet - CH 3 - Ethernet, Fast Ethernet, and Gigabit Ethern.. Page 1 of 36 [Figures are not included in this sample chapter] Switched, Fast, and Gigabit Ethernet - 3 - Ethernet, Fast Ethernet, and Gigabit Ethernet Standards This chapter discusses the theory and standards of the three versions of Ethernet around today: regular 10Mbps Ethernet, 100Mbps Fast Ethernet, and 1000Mbps Gigabit Ethernet. The goal of this chapter is to educate you as a LAN manager or IT professional about essential differences between shared 10Mbps Ethernet and these newer technologies. This chapter focuses on aspects of Fast Ethernet and Gigabit Ethernet that are relevant to you and doesn’t get into too much technical detail. Read this chapter and the following two (Chapter 4, "Layer 2 Ethernet Switching," and Chapter 5, "VLANs and Layer 3 Switching") together. This chapter focuses on the different Ethernet MAC and PHY standards, as well as repeaters, also known as hubs. Chapter 4 examines Ethernet bridging, also known as Layer 2 switching. Chapter 5 discusses VLANs, some basics of routing, and Layer 3 switching. These three chapters serve as a precursor to the second half of this book, namely the hands-on implementation in Chapters 8 through 12. After you understand the key differences between yesterday’s shared Ethernet and today’s Switched, Fast, and Gigabit Ethernet, evaluating products and building a network with these products should be relatively straightforward. The chapter is split into seven sections: l "Ethernet and the OSI Reference Model" discusses the OSI Reference Model and how Ethernet relates to the physical (PHY) and Media Access Control (MAC) layers of the OSI model.
    [Show full text]
  • Oracle Database Licensing Information, 11G Release 2 (11.2) E10594-26
    Oracle® Database Licensing Information 11g Release 2 (11.2) E10594-26 July 2012 Oracle Database Licensing Information, 11g Release 2 (11.2) E10594-26 Copyright © 2004, 2012, Oracle and/or its affiliates. All rights reserved. Contributor: Manmeet Ahluwalia, Penny Avril, Charlie Berger, Michelle Bird, Carolyn Bruse, Rich Buchheim, Sandra Cheevers, Leo Cloutier, Bud Endress, Prabhaker Gongloor, Kevin Jernigan, Anil Khilani, Mughees Minhas, Trish McGonigle, Dennis MacNeil, Paul Narth, Anu Natarajan, Paul Needham, Martin Pena, Jill Robinson, Mark Townsend This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.
    [Show full text]
  • Lecture 04 Linear Structures Sort
    Algorithmics (6EAP) MTAT.03.238 Linear structures, sorting, searching, etc Jaak Vilo 2018 Fall Jaak Vilo 1 Big-Oh notation classes Class Informal Intuition Analogy f(n) ∈ ο ( g(n) ) f is dominated by g Strictly below < f(n) ∈ O( g(n) ) Bounded from above Upper bound ≤ f(n) ∈ Θ( g(n) ) Bounded from “equal to” = above and below f(n) ∈ Ω( g(n) ) Bounded from below Lower bound ≥ f(n) ∈ ω( g(n) ) f dominates g Strictly above > Conclusions • Algorithm complexity deals with the behavior in the long-term – worst case -- typical – average case -- quite hard – best case -- bogus, cheating • In practice, long-term sometimes not necessary – E.g. for sorting 20 elements, you dont need fancy algorithms… Linear, sequential, ordered, list … Memory, disk, tape etc – is an ordered sequentially addressed media. Physical ordered list ~ array • Memory /address/ – Garbage collection • Files (character/byte list/lines in text file,…) • Disk – Disk fragmentation Linear data structures: Arrays • Array • Hashed array tree • Bidirectional map • Heightmap • Bit array • Lookup table • Bit field • Matrix • Bitboard • Parallel array • Bitmap • Sorted array • Circular buffer • Sparse array • Control table • Sparse matrix • Image • Iliffe vector • Dynamic array • Variable-length array • Gap buffer Linear data structures: Lists • Doubly linked list • Array list • Xor linked list • Linked list • Zipper • Self-organizing list • Doubly connected edge • Skip list list • Unrolled linked list • Difference list • VList Lists: Array 0 1 size MAX_SIZE-1 3 6 7 5 2 L = int[MAX_SIZE]
    [Show full text]
  • Information Specification ** INF-8474I Rev 3.0 Xenpak 10
    ** Information Specification ** INF-8474i Rev 3.0 SFF Committee documentation may be purchased in hard copy or electronic form SFF specifications are available at ftp://ftp.seagate.com/sff SFF Committee INF-8474i Specification for Xenpak 10 Gigabit Ethernet Transceiver Rev 3.0 September 18 2002 Secretariat: SFF Committee Abstract: This specification describes the Xenpak 10 Gigabit Ethernet Transceiver. It was developed by the MSA (Multiple Source Agreement) group in which the following companies participated: Agilent Technologies Mitsubishi Electric Blaze Network Products Molex ExceLight NEC Extreme Networks OpNext Finisar Optillion Hitachi Cable PicoLight Ignis Optics Stratos Lightwave Infineon Technologies Tyco Electronics JDS Uniphase Vitesse Semiconductor Luminent This Information Specification was not developed or endorsed by the SFF Committee but was submitted for distribution on the basis that it is of interest to the storage industry. The copyright on the contents remains with the contributor. Contributors are not required to abide by the SFF patent policy. Readers are advised of the possibility that there may be patent issues associated with an implementation which relies upon the contents of an 'i' specification. SFF accepts no responsibility for the validity of the contents. POINTS OF CONTACT: Dan Rausch I. Dal Allan Technical Editor Chairman SFF Committee Avago Technologies 14426 Black Walnut Court 350 West Trimble Rd Saratoga San Jose CA 95131 CA 95070 408-435-6689 408-867-6630 [email protected] [email protected] Xenpak 10 Gigabit Ethernet Transceiver Page 1 ** Information Specification ** INF-8474i Rev 3.0 EXPRESSION OF SUPPORT BY MANUFACTURERS The following member companies of the SFF Committee voted in favor of this industry specification.
    [Show full text]
  • Redbooks Paper Linux on IBM Zseries and S/390
    Redbooks Paper Simon Williams Linux on IBM zSeries and S/390: TCP/IP Broadcast on z/VM Guest LAN Preface This Redpaper provides information to help readers plan for and exploit Internet Protocol (IP) broadcast support that was made available to z/VM Guest LAN environments with the introduction of the z/VM 4.3 Operating System. Using IP broadcast support, Linux guests can for the first time use DHCP to lease an IP address dynamically from a DHCP server in a z/VM Guest LAN environment. This frees the administrator from the previous method of having to hardcode an IP address for every Linux guest in the system. This new feature enables easier deployment and administration of large-scale Linux environments. Objectives The objectives of this paper are to: Review the z/VM Guest LAN environment Explain IP broadcast Introduce the Dynamic Host Configuration Protocol (DHCP) Explain how DHCP works in a z/VM Guest LAN Describe how to implement DHCP in a z/VM Guest LAN environment © Copyright IBM Corp. 2003. All rights reserved. ibm.com/redbooks 1 z/VM Guest LAN Attention: While broadcast support for z/VM Guest LANs was announced with the base z/VM 4.3 operating system, the user must apply the PTF for APAR VM63172. This APAR resolves several issues which have been found to inhibit the use of DHCP by Linux-based applications running over the z/VM Guest LAN (in simulated QDIO mode). Introduction Prior to z/VM 4.2, virtual connectivity options for connecting one or more virtual machines (VM guests) was limited to virtual channel-to-channel adapters (CTCA) and the Inter-User Communications Vehicle (IUCV) facility.
    [Show full text]
  • Version 7.8-Systemd
    Linux From Scratch Version 7.8-systemd Created by Gerard Beekmans Edited by Douglas R. Reno Linux From Scratch: Version 7.8-systemd by Created by Gerard Beekmans and Edited by Douglas R. Reno Copyright © 1999-2015 Gerard Beekmans Copyright © 1999-2015, Gerard Beekmans All rights reserved. This book is licensed under a Creative Commons License. Computer instructions may be extracted from the book under the MIT License. Linux® is a registered trademark of Linus Torvalds. Linux From Scratch - Version 7.8-systemd Table of Contents Preface .......................................................................................................................................................................... vii i. Foreword ............................................................................................................................................................. vii ii. Audience ............................................................................................................................................................ vii iii. LFS Target Architectures ................................................................................................................................ viii iv. LFS and Standards ............................................................................................................................................ ix v. Rationale for Packages in the Book .................................................................................................................... x vi. Prerequisites
    [Show full text]
  • Firewalld ↔ Iptables (Continued)
    firewalld ↔ iptables (continued) Or, better said as, Understanding Linux Firewall Changes and Tools A firewall evolution and system management process Presented to SLUUG By David Forrest August 9, 2017 Bio I am David Forrest, a businessman in the housing and construction materials industry. Always keen to use the open and supportable solution even if it means getting my hands dirty. I was there, I did that, I have the t-shirt. And, I'm retired so now I can work on the “bleeding edge” - so on to the testing kernel! Why tonight? Why should we switch to firewalld? I felt a continuation was in order to address the problems that are caused by the virtual world and the interaction of processes within today's machines. Our various distributions seem to be jumping to the systemd init setup as it appears to offer better administration control to Linux Kernel machines. Firewalld just one of many efforts to see the future. In recent years, operating system virtualization has taken the industry by storm. But I'm still on CentOS7 and it uses firewalld as its default firewall along with systemd https://wiki.debian.org/Debate/initsystem/systemd firewalld It's a daemon and a command line interface to all the backends! One can start it as a service with a default setup and change it dynamically with a command line or with the daemon using D-Bus or NetworkManager. And with the new nftables release, we'll be able to combine several rules in one rich rule. The firewalld Architecture Firewalld and nft Systems have also moved toward Software Defined Networking (SDN) and system density has increased.
    [Show full text]