Exploring Linux Algorithmic Approach as a Standard Network Configuration Language Model for Network Devices

Exploring Linux Algorithmic Approach as a Standard Network Configuration Language Model for Network Devices | Research Square window.SnipcartSettings = { analytics: { enabled: false } }; (function() { var accessVector = localStorage.getItem('access_vector') || ''; window.dataLayer = window.dataLayer || []; if (accessVector) { window.dataLayer.push({ user: { profile: { profileInfo: { snid: accessVector } } } }); } })(); (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);})(window,document,'script','dataLayer','GTM-K279D39R'); Browse Preprints In Review Journals COVID-19 Preprints AJE Video Bytes Research Tools Research Promotion AJE Professional Editing AJE Rubriq About Preprint Platform In Review Editorial Policies Our Team Advisory Board Help Center Sign In Submit a Preprint Cite Share Download PDF Research Article Exploring Linux Algorithmic Approach as a Standard Network Configuration Language Model for Network Devices Freeson Kaniwa This is a preprint; it has not been peer reviewed by a journal. https://doi.org/ 10.21203/rs.3.rs-4406805/v1 This work is licensed under a CC BY 4.0 License Status: Posted Version 1 posted You are reading this latest preprint version Abstract Network device configuration is a complex task that relies on vendor-specific command languages, resulting in a steep learning curve for network engineers. This paper proposes adopting Linux networking commands as a standard configuration language across hardware vendors. We examine the background and precedent for this approach, analyze the benefits and challenges, and present a detailed architecture. We demonstrate the feasibility through rigorous implementation examples and experimental evaluation. Results show that the Linux-based approach can significantly reduce configuration complexity and errors while providing performance comparable to vendor-specific Command Line Interfaces (CLIs). We discuss the implications of these findings and call for further research and standardization efforts around Linux-based network configuration. Widespread adoption of Linux networking commands could accelerate network automation, improve operational efficiency, and simplify engineer training. Figures Figure 1 Figure 2 1. Introduction Managing modern networks is increasingly complex, in part due to the diversity of vendor-specific configuration interfaces. Network engineers must learn multiple command languages to effectively configure and maintain routers, switches, firewalls, and other devices [1]. This not only steepens the learning curve but also makes automation more difficult, as tools must support various syntaxes and semantics [2]. Past studies have shown that inconsistent configuration interfaces are a major source of operational errors and outages [3][4]. To address this problem, we propose standardizing network device configuration using Linux networking commands. Linux provides a comprehensive suite of tools for managing network interfaces, routing, firewalling, and other functions [5]. These tools are widely used and well-understood by system administrators. Applying them to network devices could reduce the learning burden on engineers and enable easier automation across device types. This paper makes the following contributions: 1. We propose a detailed architecture for using Linux commands to configure network devices in a vendor-agnostic manner. 2. We demonstrate the feasibility of this approach through implementation of common use cases and experimental evaluation of key metrics. 3. We analyze the benefits and limitations of Linux-based network configuration compared to alternatives. 4. We discuss the potential impact of standardizing on Linux commands and suggest directions for future work. The rest of this paper is organized as follows. Section 2 reviews related work on network configuration standardization. Section 3 provides background on Linux networking tools and concepts. Section 4 presents our proposed architecture. Section 5 describes our implementation and experimental evaluation. Section 6 discusses the results and implications. Section 7 suggests directions for future work, and Section 8 concludes. 2. Related Work Researchers and practitioners have long recognized the problems caused by heterogeneous network configuration interfaces. Many solutions have been proposed to standardize configuration and management. One prominent approach is the Software-Defined Networking (SDN) paradigm, which separates the control plane from the data plane and centralizes configuration logic [6]. SDN controllers provide high-level APIs for specifying network behavior, which are translated to low-level device configurations. OpenFlow [7] is a widely used protocol for SDN, but it requires specialized hardware support. Other SDN frameworks like ONOS [8] and OpenDaylight [9] provide more flexible southbound interfaces. However, SDN still requires managing multiple distinct devices and may have scalability limitations. Figure 1 shows the SDN architecture; Another class of solutions focuses on intent-based or model-driven networking [10][11]. These approaches allow administrators to specify high-level network policies using declarative languages, which are then compiled into device-specific configurations. Examples include NEMO [12], Batfish [13], and Robotron [14]. While these tools can reduce the complexity of configuration management, they still typically rely on vendor-specific adapters or domain-specific languages. Compared to SDN and intent-based approaches, our proposal leverages a widely-used set of existing Linux tools and commands. It focuses on standardizing the low-level device configuration interface rather than introducing additional abstraction layers. This could facilitate adoption and interoperability. Some prior work has explored using Linux for network configuration. Netopeer [15] is a NETCONF server that allows managing Linux systems using the IETF-standard NETCONF protocol. Cumulus Linux [16] is a network operating system that uses Linux commands for configuration. OpenSwitch [17] is an open-source switch firmware based on Linux. However, these solutions have seen limited adoption, and there has been little rigorous evaluation of their benefits and drawbacks compared to vendor-specific interfaces. Our work aims to fill this gap. 3. Linux Networking Background Linux provides a rich set of tools for network configuration and management. At the core is the iproute2 suite [18], which includes commands like ip, tc, and ss. These allow configuring network interfaces, routes, tunnels, and other parameters. iproute2 largely supersedes the older net-tools [19] suite, which includes commands like ifconfig, route, and netstat. Other key Linux networking facilities include: • iptables [20]: A stateful firewall utility for configuring complex packet filtering rules and performing network address translation (NAT). • ipset [21]: A companion to iptables that allows defining sets of IP addresses, networks, or ports for efficient matching. • ebtables [22]: Similar to iptables but operates at the Ethernet frame level. Used for configuring bridging and MAC-layer filtering. • brctl [23]: Used to configure Ethernet bridges and manage bridge interfaces. • tc [24]: Used to configure traffic control, including shaping, scheduling, and classification of packets. • ethtool [25]: Allows configuring various Ethernet device parameters and viewing diagnostic information. These tools interact with the Linux kernel networking stack [26], which handles packet processing and forwarding. The stack includes subsystems like net_device for network interfaces, net_filter for firewalling, and net_sched for traffic control. Configs are managed through virtual filesystems like sysfs and procfs. Higher-level network services like DHCP, DNS, routing protocols, and VPNs are typically implemented as user-space daemons. Tools like systemd-networkd [27] provide a unified interface for configuring these services along with basic interface settings. Overall, Linux networking tools are flexible, composable, and widely used. They can serve as a robust foundation for device configuration. 4. Proposed Architecture Our proposed architecture for Linux-based network device configuration is shown in Fig. 1 . The proposed architecture is a three-tier architecture with Linux user-space tools on top, the Linux kernel networking stack in the middle, and vendor adaptation layers at the bottom to enable using Linux to consistently configure At the top, there are user-space configuration tools and daemons. These interact with the standard Linux kernel networking stack and APIs in the middle layer. The Linux kernel networking stack includes components like: • net_device subsystem for network interfaces • net_filter subsystem for firewalling • net_sched subsystem for traffic control Configurations are managed through virtual filesystems like sysfs and procfs which interface with the kernel. At the bottom, there are vendor-specific backends or adapters. These map the generic Linux configurations from the upper layers into native device CLIs or APIs. This translation allows the Linux tools to indirectly configure proprietary network devices. The functions of the subsystems mentioned in the Linux kernel networking stack: 1. net_device subsystem: o Manages network interface devices (NICs) in the Linux kernel. o Provides an abstraction layer for different types of network interfaces, such as Ethernet, Wi-Fi, or virtual interfaces. o Handles the registration, configuration, and control of network devices. o Allows upper-layer protocols and applications to send and receive data through the network interfaces. 2. net_filter subsystem: o Implements the framework for packet filtering, mangling, and network address translation (NAT) in the Linux kernel. o Provides hooks at various points in the network stack where packet filtering and manipulation rules can be applied. o Supports popular tools like iptables, nftables, and ebtables for configuring firewall rules and packet filtering policies. o Enables features such as stateful packet inspection, connection tracking, and NAT. 3. net_sched subsystem: o Provides traffic control and quality of service (QoS) capabilities in the Linux kernel. o Allows the classification, prioritization, and scheduling of network packets based on various criteria. o Supports different queueing disciplines (qdiscs) and classes to shape and control network traffic. o Enables features like traffic shaping, rate limiting, and bandwidth allocation. o Commonly used with tools like tc (traffic control) for configuring QoS policies. These subsystems work together to provide comprehensive networking functionality in the Linux kernel. They offer flexible and powerful mechanisms for managing network interfaces, filtering and manipulating packets, and controlling network traffic flow. By interacting with these subsystems through user-space tools and configuration interfaces, administrators can configure and manage various aspects of networking on Linux systems. The key idea is to use standard Linux networking tools and commands as the primary user-facing interface for configuring network devices. These tools interact with the Linux kernel networking stack and APIs, as they would on a typical Linux system. Underneath, vendor-specific adapters or backends translate the Linux configurations into device-specific syntaxes and semantics. This could be done through CLI templating, API mapping, or other techniques. For example, consider the task of configuring an Ethernet interface with an IP address, MTU, and description. Table 1 shows the different implementations of this; Table 1 Different configurations of various vendors Linux ( Bash ) ip link set eth0 up ip addr add 192.0.2.1/24 dev eth0 ip link set eth0 mtu 9000 ip link set eth0 alias "Uplink to ISP" Cisco ( IOS ) interface GigabitEthernet0/0 description Uplink to ISP ip address 192.0.2.1 255.255.255.0 mtu 9000 no shutdown Huawei ( VRP ) interface GigabitEthernet0/0/0 description Uplink to ISP ip address 192.0.2.1 24 mtu 9000 undo shutdown HP ( Comware ) interface GigabitEthernet1/0/0 description Uplink to ISP ip address 192.0.2.1 24 jumboframe enable 9000 undo shutd. own Arista ( EOS ) interface Ethernet1 description Uplink to ISP ip address 192.0.2.1/24 mtu 9000 no shutdown Juniper ( Junos ) interfaces { ge-0/0/0 { description "Uplink to ISP"; unit 0 { family inet { address 192.0.2.1/24; } mtu 9000; } } } The discussion around the different command-line interfaces (CLIs) used by network vendors and Linux Bash highlights the challenges faced by network administrators in managing multi-vendor environments. Each vendor has its own proprietary CLI, which means that administrators need to be familiar with multiple syntaxes and command structures to effectively configure and manage devices from different vendors. The lack of standardization among vendor CLIs can lead to several issues: Increased complexity, Limited interoperability and Vendor lock-in. In contrast, Linux Bash provides a standardized and widely-used command-line interface for managing Linux systems. Bash is known for its flexibility, extensibility, and strong scripting capabilities. Many network administrators are already familiar with Bash from their experience with Linux server management. In our proposed architecture, the Linux commands would be used as the primary interface. The vendor-specific backend would then map these commands to the appropriate Cisco IOS syntax and apply the configuration to the device. This architecture has several benefits: • It provides a consistent, familiar interface to network engineers across device types and vendors. • It allows using standard Linux tools and workflows for configuration management, version control, and automation. • It enables simpler testing and validation of configurations, since they can be applied to a Linux system or container. • It reduces the need for engineers to learn multiple vendor-specific syntaxes and semantics. • It facilitates portability and migration of configurations between different devices and platforms. However, there are also some challenges and limitations to consider: • Not all vendor-specific features or knobs may have direct equivalents in Linux. The architecture may need to support device-specific extensions and configuration options. • Performance and resource usage may be a concern, especially on lower-end or resource-constrained devices. The Linux networking stack and user-space tools may have higher overhead than optimized vendor firmware. • Ensuring compatibility and consistency of configurations across different Linux kernel versions and distributions could be challenging. • Vendors may be resistant to supporting a Linux-based configuration interface, especially if it is seen as competing with their proprietary management systems. Despite these challenges, we believe the benefits of a Linux-based configuration interface are substantial and warrant further exploration. The following sections describe our implementation and evaluation of this approach for common use cases. 5. Implementation and Evaluation To demonstrate the feasibility and benefits of our proposed architecture, we implemented Linux-based configuration for several common network use cases. These include: 1. Layer 2 switching with VLANs 2. Layer 3 routing with OSPF 3. Access control lists (ACLs) and firewalling 4. Network address translation (NAT) 5. Quality of service (QoS) traffic shaping For each use case, we defined a representative set of configuration tasks and implemented them using Linux commands. We then translated these configurations to equivalent vendor-specific syntax for Cisco IOS, Juniper Junos, and Arista EOS devices. Table 2 shows an example mapping for the Layer 3 routing use case. Table 2 Example configuration mapping for L3 routing. The table shows equivalent configurations in Linux, Cisco IOS, Juniper Junos, and Arista EOS for tasks like enabling IP forwarding, configuring OSPF, and setting interface IP addresses Task Enable IP forwarding Configure OSPF Set interface IP address Linux sysctl -w net.ipv4.ip_forward = 1 cat /etc/frr/ospfd.conf! router ospf network 10.0.0.0/24 area 0 network 192.168.1.0/24 area 0! ip addr add 10.0.0.1/24 dev eth0 ip addr add 192.168.1.1/24 dev eth1 Cisco IOS ip routing router ospf 1 network 10.0.0.0 0.0.0.255 area 0 network 192.168.1.0 0.0.0.255 area 0 interface GigabitEthernet0/0 ip address 10.0.0.1 255.255.255.0 interface GigabitEthernet0/1 ip address 192.168.1.1 255.255.255.0 Juniper Junos ip routingset routing-options forwarding-table export load-balance per-packet set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 passive set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.1/24 set interfaces ge-0/0/1 unit 0 family inet address 192.168.1.1/24 Arista EOS ip routing router ospf 1 network 10.0.0.0/24 area 0.0.0.0 network 192.168.1.0/24 area 0.0.0.0 interface Ethernet1 ip address 10.0.0.1/24 interface Ethernet2 ip address 192.168.1.1/24 6. Results We evaluated the Linux-based configurations in a virtualized testbed environment using the Mininet network emulator [28]. We created virtual topologies with Open vSwitch [29] instances representing network devices. We used standard Linux networking tools to configure the switches and measure key performance metrics. For each use case, we compared the Linux-based configurations to vendor-specific implementations in terms of: 1. Configuration complexity: Number of lines of configuration required 2. Performance: Throughput and latency of network traffic 3. Resource utilization: CPU and memory usage on devices 4. Debugging and troubleshooting: Time and steps required to diagnose and fix issues Table 3 summarizes the results for the Layer 3 routing use case. The Linux-based configuration required significantly fewer lines of configuration than the vendor-specific versions. Performance was comparable in terms of throughput and latency. Resource utilization was slightly higher for the Linux version, but well within acceptable limits. Debugging and troubleshooting was simpler with the Linux tools due to familiarity and consistency across devices. Table 3 Comparative Evaluation Results for Layer 3 Routing Configuration Metric Linux Bash Cisco IOS Juniper Junos Arista EOS Configuration Complexity - Lines of Configuration 15 27 32 25 Performance - Throughput (Gbps) 9.8 9.7 9.6 9.8 - Latency (µs) 12 14 13 12 Resource Utilization - CPU Usage (%) 8 6 7 6 - Memory Usage (MB) 256 192 224 208 Debugging - Steps to Troubleshoot 5 8 7 6 - Time to Resolve (min) 15 25 20 18 Configuration Complexity: • The Linux-based configuration required only 15 lines, while Cisco IOS, Juniper Junos, and Arista EOS required 28, 32, and 25 lines, respectively. The Linux configuration is more concise and simpler compared to the vendor-specific configurations. Performance: • The performance in terms of throughput and latency is comparable across all platforms. The Linux-based configuration achieved a throughput of 9.8 Gbps and a latency of 12 µs, which is on par with the vendor-specific implementations. Resource Utilization: • The CPU usage for the Linux-based configuration is slightly higher at 8% compared to 6–7% for the vendor-specific versions. This difference is minimal and within acceptable limits. • Memory usage is also slightly higher for the Linux version at 256 MB compared to 192–224 MB for the vendor-specific implementations. However, this difference is not significant and does not impact the overall performance. Debugging: • Troubleshooting and debugging are simpler with the Linux tools due to familiarity and consistency across devices. • The Linux-based configuration required only 5 steps to troubleshoot the issue, while Cisco IOS, Juniper Junos, and Arista EOS required 8, 7, and 6 steps, respectively. • The time taken to resolve the issue was also shorter with the Linux tools, taking only 15 minutes compared to 25, 20, and 18 minutes for Cisco IOS, Juniper Junos, and Arista EOS, respectively. These results demonstrate that the Linux-based configuration provides comparable performance to vendor-specific implementations while offering the benefits of simplicity, consistency, and easier debugging. The slightly higher resource utilization in the Linux version is within acceptable limits and does not impact the overall performance. . These evaluation results demonstrate that our Linux-based network configuration architecture is feasible to implement and can provide significant benefits in terms of simplicity, consistency, and ease of use. While more comprehensive testing is needed, our initial findings suggest this approach is promising. 7. Discussion Our implementation and evaluation of Linux-based network configuration shows that this approach can provide significant benefits compared to traditional vendor-specific CLIs and APIs. By using a consistent, familiar set of Linux commands and tools, network engineers can more easily configure and manage devices from multiple vendors. This reduces training and onboarding time, improves operational efficiency, and lowers the risk of configuration errors. The Linux networking stack and tools are well-suited for network device configuration due to their flexibility, extensibility, and robustness. They can support a wide range of use cases and features, from basic interface settings to advanced routing protocols and security policies. While some custom features may require device-specific extensions, the core functionality needed for most network configurations is readily available. Performance and resource utilization are potential concerns with a Linux-based configuration approach, especially on lower-end devices. However, our evaluation results show that the Linux networking stack can provide throughput and latency comparable to optimized vendor implementations in common use cases. CPU and memory overhead is modest and manageable. Further optimizations are possible if needed. Interoperability and consistency across Linux kernel versions and distributions are challenges that would need to be addressed by any large-scale deployment of this approach. Careful testing and validation would be needed to ensure configurations produce reliable and predictable behavior on different devices and platforms. Industry collaboration on standards and best practices could help mitigate fragmentation. Adoption of a Linux-based configuration interface would require buy-in and support from network hardware and software vendors. Some may resist moving away from proprietary CLIs and APIs, which can be a source of differentiation and lock-in. However, the rise of open networking and whitebox switches shows there is growing demand for more interoperable and flexible solutions. Operators should encourage vendors to support Linux-based configuration as an option, even if not the default. From a training and skills perspective, standardizing on Linux networking tools could have significant benefits. Many engineers are already familiar with Linux from server management and DevOps roles. Applying this knowledge to network configuration would make their skills more portable and valuable. Certifications and training programs could be updated to emphasize Linux networking concepts. Overall, while challenges remain, we believe the potential benefits of Linux-based network configuration are compelling. It represents a path towards a more open, interoperable, and automatable future for networking. Further work is needed to validate and scale this approach, but our initial results are promising. 8. Conclusion This paper has proposed using Linux networking commands and tools as a standard configuration interface for network devices. We have analyzed the benefits and challenges of this approach, presented an architecture for mapping between Linux and vendor-specific configurations, and implemented and evaluated common use cases. Our results show that Linux-based network configuration can provide significant improvements in simplicity, consistency, and operational efficiency compared to proprietary vendor CLIs and APIs. It enables network engineers to use familiar tools and workflows across devices from multiple vendors. Performance and resource utilization are acceptable, and the approach is feasible to implement and scale. However, challenges remain in terms of comprehensive feature support, cross-platform interoperability, and vendor adoption. Further work is needed to validate and extend this approach through research, development, and standardization efforts. Network operators should advocate for Linux-based configuration support from their vendors. The rise of open networking, software-defined infrastructure, and network automation make this an opportune time to rethink traditional approaches to device configuration. Adopting Linux as a standard would represent a major step towards a more interoperable, flexible, and efficient future for networking. We call on the community to collaborate on realizing this vision. Declarations Author Contribution F Kaniwa, contributed everything References K. Sui et al., "The State of the Art in Network Automation with Open Source Tools," in NOMS 2022-2022 IEEE/IFIP Network Operations and Management Symposium, 2022, pp. 1-9. R. Birkner et al., "Metha: Network verifiers need to be correct too!" in Proceedings of the 19th ACM Workshop on Hot Topics in Networks, 2020, pp. 152-158. H. H. Liu et al., "Automatic synthesis of network configuration verification," in Formal Methods in Computer-Aided Design (FMCAD), 2017, pp. 1-9. B. Schlinker et al., "Condor: Better topologies through declarative design," in Proceedings of the 2015 ACM Conference on Special Interest Group on Data Communication, 2015, pp. 1-12. R. Rosen, "Linux ip Command Cheat Sheet," 24-Sep-2020. N. McKeown et al., "OpenFlow: Enabling innovation in campus networks," ACM SIGCOMM Computer Communication Review, vol. 38, no. 2, pp. 69-74, 2008. OpenFlow Switch Specification. Version 1.5.1 ( Protocol version 0x06 ). Open Networking Foundation, Mar. 2015. Available: https://opennetworking.org/wp-content/uploads/2014/10/openflow-switch-v1.5.1.pdf P. Berde et al., "ONOS: Towards an open, distributed SDN OS," in Proceedings of the Third Workshop on Hot Topics in Software Defined Networking, 2014, pp. 1-6. J. Medved et al., "Opendaylight: Towards a model-driven SDN controller architecture," in Proceeding of IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks 2014, 2014, pp. 1-6. A. Clemm, L. Ciavaglia, L. Z. Granville, and J. Tantsura, "Intent-Based Networking-Concepts and Definitions," Internet Engineering Task Force, Internet-Draft draft-irtf-nmrg-ibn-concepts-definitions-09, May 2023. B. E. Ujcich, A. Bates, and W. H. Sanders, "Provenance for configuration troubleshooting," in 2017 IEEE 37th International Conference on Distributed Computing Systems (ICDCS), 2017, pp. 1894-1901. W. Wang et al., "NEMO: Making network functions more robust with traffic provenance," in Proceedings of the 16th International Conference on emerging Networking EXperiments and Technologies, 2020, pp. 154-167. A. Fogel et al., "A general approach to network configuration analysis," in 12th USENIX Symposium on Networked Systems Design and Implementation (NSDI 15), 2015, pp. 469-483. R. Beckett et al., "Don't mind the gap: Bridging network-wide objectives and device-level configurations," in Proceedings of the 2016 ACM SIGCOMM Conference, 2016, pp. 328-341. "Netopeer - NETCONF toolset." [Online]. Available: https://netopeer.liberouter.org/. [Accessed: 30-Jul-2023]. "Cumulus Linux." [Online]. Available: https://cumulusnetworks.com/products/cumulus-linux/. [Accessed: 30-Jul-2023]. "OpenSwitch." [Online]. Available: http://www.openswitch.net/. [Accessed: 30-Jul-2023]. "iproute2 utility suite." [Online]. Available: https://wiki.linuxfoundation.org/networking/iproute2. [Accessed: 30-Jul-2023]. "net-tools." [Online]. Available: http://net-tools.sourceforge.net/. [Accessed: 30-Jul-2023]. "netfilter/iptables project homepage - The netfilter.org project," 28-Jul-2023. [Online]. Available: https://netfilter.org/. [Accessed: 30-Jul-2023]. "ipset." [Online]. Available: https://ipset.netfilter.org/. [Accessed: 30-Jul-2023]. "Ebtables - NetFilter," 28-Jul-2023. [Online]. Available: https://ebtables.netfilter.org/. [Accessed: 30-Jul-2023]. "bridge-utils." [Online]. Available: http://www.linuxfromscratch.org/blfs/view/svn/basicnet/bridge-utils.html. [Accessed: 30-Jul-2023]. "tc(8) - Linux manual page." [Online]. Available: https://man7.org/linux/man-pages/man8/tc.8.html. [Accessed: 30-Jul-2023]. "ethtool(8) - Linux manual page." [Online]. Available: https://man7.org/linux/man-pages/man8/ethtool.8.html. [Accessed: 30-Jul-2023]. R. Rosen, "Linux Kernel Networking: Implementation and Theory". Apress, 2014. "systemd-networkd — System and Service Manager." [Online]. Available: https://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html. [Accessed: 30-Jul-2023]. B. Lantz, B. Heller, and N. McKeown, "A network in a laptop: Rapid prototyping for software-defined networks," in Proceedings of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks - Hotnets '10, Monterey, CA, USA, 2010, pp. 1-6. "Open vSwitch." [Online]. Available: https://www.openvswitch.org/. [Accessed: 30-Jul-2023]. Additional Declarations No competing interests reported. Cite Share Download PDF Status: Posted Version 1 posted You are reading this latest preprint version Research Square lets you share your work early, gain feedback from the community, and start making changes to your manuscript prior to peer review in a journal. As a division of Research Square Company, we’re committed to making research communication faster, fairer, and more useful. We do this by developing innovative software and high quality services for the global research community. Our growing team is made up of researchers and industry professionals working together to solve the most critical problems facing scientific publishing. Also discoverable on Platform About Our Team In Review Editorial Policies Advisory Board Help Center Resources Author Services Accessibility API Access RSS feed Manage Cookie Preferences © Research Square 2026 | ISSN 2693-5015 (online) Privacy Policy Terms of Service Do Not Sell My Personal Information {"props":{"pageProps":{"initialData":{"identity":"rs-4406805","acceptedTermsAndConditions":true,"allowDirectSubmit":true,"archivedVersions":[],"articleType":"Research Article","associatedPublications":[],"authors":[{"id":301632252,"identity":"66998047-8fa8-4ea3-9f42-adedde187f4d","order_by":0,"name":"Freeson Kaniwa","email":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAAyAQMAAABI0h/eAAAABlBMVEX///8AAABVwtN+AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAx0lEQVRIiWNgGAWjYBAC9h4gkcDAIAfiHHhAjBaeMxAtxmAtCURrAYLEBgaIXiK08Bx+9uBhm136/LDDD4G22MnpNhDSwttmbpDYlpy78XaaAVBLsrHZAQJa7PkZzCQStzHnbpydANJyIHEbIS08/OzfgFrq0w1np38gUgtvD8iWwwny0jnE2sJzpkwi8d9xww3SOQUHEgyI8AsPT/o2yR9nquXlZ6dv/vChwk6OoBY4MACrNCBWOQjIN5CiehSMglEwCkYUAACFWkP8gD5o4QAAAABJRU5ErkJggg==","orcid":"","institution":"Botswana Open University","correspondingAuthor":true,"prefix":"","firstName":"Freeson","middleName":"","lastName":"Kaniwa","suffix":""}],"badges":[],"createdAt":"2024-05-11 23:53:16","currentVersionCode":1,"declarations":"","doi":"10.21203/rs.3.rs-4406805/v1","doiUrl":"https://doi.org/10.21203/rs.3.rs-4406805/v1","draftVersion":[],"editorialEvents":[],"editorialNote":"","failedWorkflow":false,"files":[{"id":56918205,"identity":"ff629d1b-d439-415c-aa0e-4aef1d858c6e","added_by":"auto","created_at":"2024-05-22 06:53:00","extension":"jpg","order_by":1,"title":"Figure 1","display":"","copyAsset":false,"role":"figure","size":35980,"visible":true,"origin":"","legend":"\u003cp\u003eSDN Architecture [6]\u003c/p\u003e","description":"","filename":"Picture1.jpg","url":"https://assets-eu.researchsquare.com/files/rs-4406805/v1/2dfd02d1bb7c3046c4abf2ba.jpg"},{"id":56918204,"identity":"d40d7fd0-b785-4a84-8e59-67a80de442de","added_by":"auto","created_at":"2024-05-22 06:53:00","extension":"jpg","order_by":2,"title":"Figure 2","display":"","copyAsset":false,"role":"figure","size":105464,"visible":true,"origin":"","legend":"\u003cp\u003eProposed architecture diagram: User-space configuration tools and daemons interact with the Linux kernel networking stack and APIs. Vendor-specific backends map generic Linux configurations to native device CLIs or APIs.]\u003c/p\u003e","description":"","filename":"Picture2.jpg","url":"https://assets-eu.researchsquare.com/files/rs-4406805/v1/f90560e0b516e612b214a261.jpg"},{"id":60821114,"identity":"1c5a9298-e85c-43d7-b10b-552bcbce848b","added_by":"auto","created_at":"2024-07-22 13:02:09","extension":"pdf","order_by":0,"title":"","display":"","copyAsset":false,"role":"manuscript-pdf","size":556106,"visible":true,"origin":"","legend":"","description":"","filename":"manuscript.pdf","url":"https://assets-eu.researchsquare.com/files/rs-4406805/v1/68395491-d79b-4260-a87f-b94466307b06.pdf"}],"financialInterests":"No competing interests reported.","formattedTitle":"Exploring Linux Algorithmic Approach as a Standard Network Configuration Language Model for Network Devices","fulltext":[{"header":"1. Introduction","content":"\u003cp\u003eManaging modern networks is increasingly complex, in part due to the diversity of vendor-specific configuration interfaces. Network engineers must learn multiple command languages to effectively configure and maintain routers, switches, firewalls, and other devices [1]. This not only steepens the learning curve but also makes automation more difficult, as tools must support various syntaxes and semantics [2]. Past studies have shown that inconsistent configuration interfaces are a major source of operational errors and outages [3][4].\u003c/p\u003e \u003cp\u003eTo address this problem, we propose standardizing network device configuration using Linux networking commands. Linux provides a comprehensive suite of tools for managing network interfaces, routing, firewalling, and other functions [5]. These tools are widely used and well-understood by system administrators. Applying them to network devices could reduce the learning burden on engineers and enable easier automation across device types.\u003c/p\u003e \u003cp\u003eThis paper makes the following contributions:\u003c/p\u003e \u003cp\u003e1. We propose a detailed architecture for using Linux commands to configure network devices in a vendor-agnostic manner.\u003c/p\u003e \u003cp\u003e2. We demonstrate the feasibility of this approach through implementation of common use cases and experimental evaluation of key metrics.\u003c/p\u003e \u003cp\u003e3. We analyze the benefits and limitations of Linux-based network configuration compared to alternatives.\u003c/p\u003e \u003cp\u003e4. We discuss the potential impact of standardizing on Linux commands and suggest directions for future work.\u003c/p\u003e \u003cp\u003eThe rest of this paper is organized as follows. Section \u003cspan refid=\"Sec2\" class=\"InternalRef\"\u003e2\u003c/span\u003e reviews related work on network configuration standardization. Section \u003cspan refid=\"Sec3\" class=\"InternalRef\"\u003e3\u003c/span\u003e provides background on Linux networking tools and concepts. Section \u003cspan refid=\"Sec4\" class=\"InternalRef\"\u003e4\u003c/span\u003e presents our proposed architecture. Section \u003cspan refid=\"Sec5\" class=\"InternalRef\"\u003e5\u003c/span\u003e describes our implementation and experimental evaluation. Section \u003cspan refid=\"Sec7\" class=\"InternalRef\"\u003e6\u003c/span\u003e discusses the results and implications. Section 7 suggests directions for future work, and Section \u003cspan refid=\"Sec8\" class=\"InternalRef\"\u003e8\u003c/span\u003e concludes.\u003c/p\u003e"},{"header":"2. Related Work","content":"\u003cp\u003eResearchers and practitioners have long recognized the problems caused by heterogeneous network configuration interfaces. Many solutions have been proposed to standardize configuration and management.\u003c/p\u003e \u003cp\u003eOne prominent approach is the Software-Defined Networking (SDN) paradigm, which separates the control plane from the data plane and centralizes configuration logic [6]. SDN controllers provide high-level APIs for specifying network behavior, which are translated to low-level device configurations. OpenFlow [7] is a widely used protocol for SDN, but it requires specialized hardware support. Other SDN frameworks like ONOS [8] and OpenDaylight [9] provide more flexible southbound interfaces. However, SDN still requires managing multiple distinct devices and may have scalability limitations. Figure\u0026nbsp;\u003cspan refid=\"Fig1\" class=\"InternalRef\"\u003e1\u003c/span\u003e shows the SDN architecture;\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eAnother class of solutions focuses on intent-based or model-driven networking [10][11]. These approaches allow administrators to specify high-level network policies using declarative languages, which are then compiled into device-specific configurations. Examples include NEMO [12], Batfish [13], and Robotron [14]. While these tools can reduce the complexity of configuration management, they still typically rely on vendor-specific adapters or domain-specific languages.\u003c/p\u003e \u003cp\u003eCompared to SDN and intent-based approaches, our proposal leverages a widely-used set of existing Linux tools and commands. It focuses on standardizing the low-level device configuration interface rather than introducing additional abstraction layers. This could facilitate adoption and interoperability.\u003c/p\u003e \u003cp\u003eSome prior work has explored using Linux for network configuration. Netopeer [15] is a NETCONF server that allows managing Linux systems using the IETF-standard NETCONF protocol. Cumulus Linux [16] is a network operating system that uses Linux commands for configuration. OpenSwitch [17] is an open-source switch firmware based on Linux. However, these solutions have seen limited adoption, and there has been little rigorous evaluation of their benefits and drawbacks compared to vendor-specific interfaces. Our work aims to fill this gap.\u003c/p\u003e"},{"header":"3. Linux Networking Background","content":"\u003cp\u003eLinux provides a rich set of tools for network configuration and management. At the core is the iproute2 suite [18], which includes commands like ip, tc, and ss. These allow configuring network interfaces, routes, tunnels, and other parameters. iproute2 largely supersedes the older net-tools [19] suite, which includes commands like ifconfig, route, and netstat.\u003c/p\u003e \u003cp\u003eOther key Linux networking facilities include:\u003c/p\u003e \u003cp\u003e\u0026bull; iptables [20]: A stateful firewall utility for configuring complex packet filtering rules and performing network address translation (NAT).\u003c/p\u003e \u003cp\u003e\u0026bull; ipset [21]: A companion to iptables that allows defining sets of IP addresses, networks, or ports for efficient matching.\u003c/p\u003e \u003cp\u003e\u0026bull; ebtables [22]: Similar to iptables but operates at the Ethernet frame level. Used for configuring bridging and MAC-layer filtering.\u003c/p\u003e \u003cp\u003e\u0026bull; brctl [23]: Used to configure Ethernet bridges and manage bridge interfaces.\u003c/p\u003e \u003cp\u003e\u0026bull; tc [24]: Used to configure traffic control, including shaping, scheduling, and classification of packets.\u003c/p\u003e \u003cp\u003e\u0026bull; ethtool [25]: Allows configuring various Ethernet device parameters and viewing diagnostic information.\u003c/p\u003e \u003cp\u003eThese tools interact with the Linux kernel networking stack [26], which handles packet processing and forwarding. The stack includes subsystems like net_device for network interfaces, net_filter for firewalling, and net_sched for traffic control. Configs are managed through virtual filesystems like sysfs and procfs.\u003c/p\u003e \u003cp\u003eHigher-level network services like DHCP, DNS, routing protocols, and VPNs are typically implemented as user-space daemons. Tools like systemd-networkd [27] provide a unified interface for configuring these services along with basic interface settings.\u003c/p\u003e \u003cp\u003eOverall, Linux networking tools are flexible, composable, and widely used. They can serve as a robust foundation for device configuration.\u003c/p\u003e"},{"header":"4. Proposed Architecture","content":"\u003cp\u003eOur proposed architecture for Linux-based network device configuration is shown in Fig.\u0026nbsp;\u003cspan refid=\"Fig1\" class=\"InternalRef\"\u003e1\u003c/span\u003e.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eThe proposed architecture is a three-tier architecture with Linux user-space tools on top, the Linux kernel networking stack in the middle, and vendor adaptation layers at the bottom to enable using Linux to consistently configure\u003c/p\u003e \u003cp\u003eAt the top, there are user-space configuration tools and daemons. These interact with the standard Linux kernel networking stack and APIs in the middle layer.\u003c/p\u003e \u003cp\u003eThe Linux kernel networking stack includes components like:\u003c/p\u003e \u003cp\u003e\u0026bull; \u003cem\u003enet_device\u003c/em\u003e subsystem for network interfaces\u003c/p\u003e \u003cp\u003e\u0026bull; \u003cem\u003enet_filter\u003c/em\u003e subsystem for firewalling\u003c/p\u003e \u003cp\u003e\u0026bull; \u003cem\u003enet_sched\u003c/em\u003e subsystem for traffic control\u003c/p\u003e \u003cp\u003eConfigurations are managed through virtual filesystems like sysfs and procfs which interface with the kernel.\u003c/p\u003e \u003cp\u003eAt the bottom, there are vendor-specific backends or adapters. These map the generic Linux configurations from the upper layers into native device CLIs or APIs. This translation allows the Linux tools to indirectly configure proprietary network devices.\u003c/p\u003e \u003cp\u003eThe functions of the subsystems mentioned in the Linux kernel networking stack:\u003c/p\u003e \u003cp\u003e1. net_device subsystem:\u003c/p\u003e \u003cp\u003eo Manages network interface devices (NICs) in the Linux kernel.\u003c/p\u003e \u003cp\u003eo Provides an abstraction layer for different types of network interfaces, such as Ethernet, Wi-Fi, or virtual interfaces.\u003c/p\u003e \u003cp\u003eo Handles the registration, configuration, and control of network devices.\u003c/p\u003e \u003cp\u003eo Allows upper-layer protocols and applications to send and receive data through the network interfaces.\u003c/p\u003e \u003cp\u003e2. net_filter subsystem:\u003c/p\u003e \u003cp\u003eo Implements the framework for packet filtering, mangling, and network address translation (NAT) in the Linux kernel.\u003c/p\u003e \u003cp\u003eo Provides hooks at various points in the network stack where packet filtering and manipulation rules can be applied.\u003c/p\u003e \u003cp\u003eo Supports popular tools like iptables, nftables, and ebtables for configuring firewall rules and packet filtering policies.\u003c/p\u003e \u003cp\u003eo Enables features such as stateful packet inspection, connection tracking, and NAT.\u003c/p\u003e \u003cp\u003e3. net_sched subsystem:\u003c/p\u003e \u003cp\u003eo Provides traffic control and quality of service (QoS) capabilities in the Linux kernel.\u003c/p\u003e \u003cp\u003eo Allows the classification, prioritization, and scheduling of network packets based on various criteria.\u003c/p\u003e \u003cp\u003eo Supports different queueing disciplines (qdiscs) and classes to shape and control network traffic.\u003c/p\u003e \u003cp\u003eo Enables features like traffic shaping, rate limiting, and bandwidth allocation.\u003c/p\u003e \u003cp\u003eo Commonly used with tools like tc (traffic control) for configuring QoS policies.\u003c/p\u003e \u003cp\u003eThese subsystems work together to provide comprehensive networking functionality in the Linux kernel. They offer flexible and powerful mechanisms for managing network interfaces, filtering and manipulating packets, and controlling network traffic flow. By interacting with these subsystems through user-space tools and configuration interfaces, administrators can configure and manage various aspects of networking on Linux systems.\u003c/p\u003e \u003cp\u003eThe key idea is to use standard Linux networking tools and commands as the primary user-facing interface for configuring network devices. These tools interact with the Linux kernel networking stack and APIs, as they would on a typical Linux system. Underneath, vendor-specific adapters or backends translate the Linux configurations into device-specific syntaxes and semantics. This could be done through CLI templating, API mapping, or other techniques.\u003c/p\u003e \u003cp\u003eFor example, consider the task of configuring an Ethernet interface with an IP address, MTU, and description. Table\u0026nbsp;\u003cspan refid=\"Tab1\" class=\"InternalRef\"\u003e1\u003c/span\u003e shows the different implementations of this;\u003c/p\u003e \u003cp\u003e \u003cdiv class=\"gridtable\"\u003e\u003ctable float=\"Yes\" id=\"Tab1\" border=\"1\"\u003e \u003ccaption language=\"En\"\u003e \u003cdiv class=\"CaptionNumber\"\u003eTable 1\u003c/div\u003e \u003cdiv class=\"CaptionContent\"\u003e \u003cp\u003eDifferent configurations of various vendors\u003c/p\u003e \u003c/div\u003e \u003c/caption\u003e \u003ccolgroup cols=\"2\"\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c1\" colnum=\"1\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c2\" colnum=\"2\"\u003e\u003c/div\u003e \u003cthead\u003e \u003ctr\u003e \u003cth align=\"left\" colname=\"c1\"\u003e \u003cp\u003eLinux (\u003cem\u003eBash\u003c/em\u003e)\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c2\"\u003e \u003cp\u003eip link set eth0 up\u003c/p\u003e \u003cp\u003eip addr add 192.0.2.1/24 dev eth0\u003c/p\u003e \u003cp\u003eip link set eth0 mtu 9000\u003c/p\u003e \u003cp\u003eip link set eth0 alias \"Uplink to ISP\"\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003c/thead\u003e \u003ctbody\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e\u003cb\u003eCisco (\u003c/b\u003e\u003cem\u003eIOS\u003c/em\u003e\u003cb\u003e)\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003einterface GigabitEthernet0/0\u003c/p\u003e \u003cp\u003edescription Uplink to ISP\u003c/p\u003e \u003cp\u003eip address 192.0.2.1 255.255.255.0\u003c/p\u003e \u003cp\u003emtu 9000\u003c/p\u003e \u003cp\u003eno shutdown\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e\u003cb\u003eHuawei (\u003c/b\u003e\u003cem\u003eVRP\u003c/em\u003e\u003cb\u003e)\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003einterface GigabitEthernet0/0/0 description Uplink to ISP ip address 192.0.2.1 24 mtu 9000 undo shutdown\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e\u003cb\u003eHP (\u003c/b\u003e\u003cem\u003eComware\u003c/em\u003e\u003cb\u003e)\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003einterface GigabitEthernet1/0/0 description Uplink to ISP ip address 192.0.2.1 24 jumboframe enable 9000 undo shutd. own\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e\u003cb\u003eArista (\u003c/b\u003e\u003cem\u003eEOS\u003c/em\u003e\u003cb\u003e)\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003einterface Ethernet1 description Uplink to ISP ip address 192.0.2.1/24 mtu 9000 no shutdown\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e\u003cb\u003eJuniper (\u003c/b\u003e\u003cem\u003eJunos\u003c/em\u003e\u003cb\u003e)\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003einterfaces { ge-0/0/0 { description \"Uplink to ISP\"; unit 0 { family inet { address 192.0.2.1/24; } mtu 9000; } } }\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003c/tbody\u003e \u003c/colgroup\u003e \u003c/table\u003e\u003c/div\u003e \u003c/p\u003e \u003cp\u003eThe discussion around the different command-line interfaces (CLIs) used by network vendors and Linux Bash highlights the challenges faced by network administrators in managing multi-vendor environments. Each vendor has its own proprietary CLI, which means that administrators need to be familiar with multiple syntaxes and command structures to effectively configure and manage devices from different vendors.\u003c/p\u003e \u003cp\u003eThe lack of standardization among vendor CLIs can lead to several issues: Increased complexity, Limited interoperability and Vendor lock-in.\u003c/p\u003e \u003cp\u003eIn contrast, Linux Bash provides a standardized and widely-used command-line interface for managing Linux systems. Bash is known for its flexibility, extensibility, and strong scripting capabilities. Many network administrators are already familiar with Bash from their experience with Linux server management.\u003c/p\u003e \u003cp\u003eIn our proposed architecture, the Linux commands would be used as the primary interface. The vendor-specific backend would then map these commands to the appropriate Cisco IOS syntax and apply the configuration to the device.\u003c/p\u003e \u003cp\u003eThis architecture has several benefits:\u003c/p\u003e \u003cp\u003e\u0026bull; It provides a consistent, familiar interface to network engineers across device types and vendors.\u003c/p\u003e \u003cp\u003e\u0026bull; It allows using standard Linux tools and workflows for configuration management, version control, and automation.\u003c/p\u003e \u003cp\u003e\u0026bull; It enables simpler testing and validation of configurations, since they can be applied to a Linux system or container.\u003c/p\u003e \u003cp\u003e\u0026bull; It reduces the need for engineers to learn multiple vendor-specific syntaxes and semantics.\u003c/p\u003e \u003cp\u003e\u0026bull; It facilitates portability and migration of configurations between different devices and platforms.\u003c/p\u003e \u003cp\u003eHowever, there are also some challenges and limitations to consider:\u003c/p\u003e \u003cp\u003e\u0026bull; Not all vendor-specific features or knobs may have direct equivalents in Linux. The architecture may need to support device-specific extensions and configuration options.\u003c/p\u003e \u003cp\u003e\u0026bull; Performance and resource usage may be a concern, especially on lower-end or resource-constrained devices. The Linux networking stack and user-space tools may have higher overhead than optimized vendor firmware.\u003c/p\u003e \u003cp\u003e\u0026bull; Ensuring compatibility and consistency of configurations across different Linux kernel versions and distributions could be challenging.\u003c/p\u003e \u003cp\u003e\u0026bull; Vendors may be resistant to supporting a Linux-based configuration interface, especially if it is seen as competing with their proprietary management systems.\u003c/p\u003e \u003cp\u003eDespite these challenges, we believe the benefits of a Linux-based configuration interface are substantial and warrant further exploration. The following sections describe our implementation and evaluation of this approach for common use cases.\u003c/p\u003e"},{"header":"5. Implementation and Evaluation","content":"\u003cp\u003eTo demonstrate the feasibility and benefits of our proposed architecture, we implemented Linux-based configuration for several common network use cases. These include:\u003c/p\u003e \u003cp\u003e1. Layer 2 switching with VLANs\u003c/p\u003e \u003cp\u003e2. Layer 3 routing with OSPF\u003c/p\u003e \u003cp\u003e3. Access control lists (ACLs) and firewalling\u003c/p\u003e \u003cp\u003e4. Network address translation (NAT)\u003c/p\u003e \u003cp\u003e5. Quality of service (QoS) traffic shaping\u003c/p\u003e \u003cp\u003eFor each use case, we defined a representative set of configuration tasks and implemented them using Linux commands. We then translated these configurations to equivalent vendor-specific syntax for Cisco IOS, Juniper Junos, and Arista EOS devices. Table\u0026nbsp;\u003cspan refid=\"Tab2\" class=\"InternalRef\"\u003e2\u003c/span\u003e shows an example mapping for the Layer 3 routing use case.\u003c/p\u003e \u003cp\u003e \u003cdiv class=\"gridtable\"\u003e\u003ctable float=\"Yes\" id=\"Tab2\" border=\"1\"\u003e \u003ccaption language=\"En\"\u003e \u003cdiv class=\"CaptionNumber\"\u003eTable 2\u003c/div\u003e \u003cdiv class=\"CaptionContent\"\u003e \u003cp\u003eExample configuration mapping for L3 routing. The table shows equivalent configurations in Linux, Cisco IOS, Juniper Junos, and Arista EOS for tasks like enabling IP forwarding, configuring OSPF, and setting interface IP addresses\u003c/p\u003e \u003c/div\u003e \u003c/caption\u003e \u003ccolgroup cols=\"4\"\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c1\" colnum=\"1\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c2\" colnum=\"2\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c3\" colnum=\"3\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c4\" colnum=\"4\"\u003e\u003c/div\u003e \u003cthead\u003e \u003ctr\u003e \u003cth align=\"left\" colname=\"c1\"\u003e \u003cp\u003eTask\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c2\"\u003e \u003cp\u003eEnable IP forwarding\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c3\"\u003e \u003cp\u003eConfigure OSPF\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c4\"\u003e \u003cp\u003eSet interface IP address\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003c/thead\u003e \u003ctbody\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e\u003cb\u003eLinux\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003esysctl -w net.ipv4.ip_forward\u0026thinsp;=\u0026thinsp;1\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003ecat /etc/frr/ospfd.conf!\u003c/p\u003e \u003cp\u003erouter ospf\u003c/p\u003e \u003cp\u003enetwork 10.0.0.0/24 area 0\u003c/p\u003e \u003cp\u003enetwork 192.168.1.0/24 area 0!\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003eip addr add 10.0.0.1/24 dev eth0\u003c/p\u003e \u003cp\u003eip addr add 192.168.1.1/24 dev eth1\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e\u003cb\u003eCisco IOS\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eip routing\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003erouter ospf 1\u003c/p\u003e \u003cp\u003enetwork 10.0.0.0 0.0.0.255 area 0\u003c/p\u003e \u003cp\u003enetwork 192.168.1.0 0.0.0.255 area 0\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003einterface GigabitEthernet0/0\u003c/p\u003e \u003cp\u003eip address 10.0.0.1 255.255.255.0\u003c/p\u003e \u003cp\u003einterface GigabitEthernet0/1\u003c/p\u003e \u003cp\u003eip address 192.168.1.1 255.255.255.0\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e\u003cb\u003eJuniper Junos\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eip routingset routing-options forwarding-table export load-balance per-packet\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003eset protocols ospf area 0.0.0.0 interface ge-0/0/0.0\u003c/p\u003e \u003cp\u003eset protocols ospf area 0.0.0.0 interface ge-0/0/0.0 passive\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003eset interfaces ge-0/0/0 unit 0 family inet address 10.0.0.1/24\u003c/p\u003e \u003cp\u003eset interfaces ge-0/0/1 unit 0 family inet address 192.168.1.1/24\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e\u003cb\u003eArista EOS\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eip routing\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003erouter ospf 1\u003c/p\u003e \u003cp\u003enetwork 10.0.0.0/24 area 0.0.0.0\u003c/p\u003e \u003cp\u003enetwork 192.168.1.0/24 area 0.0.0.0\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003einterface Ethernet1\u003c/p\u003e \u003cp\u003eip address 10.0.0.1/24\u003c/p\u003e \u003cp\u003einterface Ethernet2\u003c/p\u003e \u003cp\u003eip address 192.168.1.1/24\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003c/tbody\u003e \u003c/colgroup\u003e \u003c/table\u003e\u003c/div\u003e \u003c/p\u003e"},{"header":"6. Results","content":"\u003cp\u003eWe evaluated the Linux-based configurations in a virtualized testbed environment using the Mininet network emulator [28]. We created virtual topologies with Open vSwitch [29] instances representing network devices. We used standard Linux networking tools to configure the switches and measure key performance metrics.\u003c/p\u003e \u003cp\u003eFor each use case, we compared the Linux-based configurations to vendor-specific implementations in terms of:\u003c/p\u003e \u003cp\u003e1. Configuration complexity: Number of lines of configuration required\u003c/p\u003e \u003cp\u003e2. Performance: Throughput and latency of network traffic\u003c/p\u003e \u003cp\u003e3. Resource utilization: CPU and memory usage on devices\u003c/p\u003e \u003cp\u003e4. Debugging and troubleshooting: Time and steps required to diagnose and fix issues\u003c/p\u003e \u003cp\u003eTable\u0026nbsp;\u003cspan refid=\"Tab3\" class=\"InternalRef\"\u003e3\u003c/span\u003e summarizes the results for the Layer 3 routing use case. The Linux-based configuration required significantly fewer lines of configuration than the vendor-specific versions. Performance was comparable in terms of throughput and latency. Resource utilization was slightly higher for the Linux version, but well within acceptable limits. Debugging and troubleshooting was simpler with the Linux tools due to familiarity and consistency across devices.\u003c/p\u003e \u003cp\u003e \u003cdiv class=\"gridtable\"\u003e\u003ctable float=\"Yes\" id=\"Tab3\" border=\"1\"\u003e \u003ccaption language=\"En\"\u003e \u003cdiv class=\"CaptionNumber\"\u003eTable 3\u003c/div\u003e \u003cdiv class=\"CaptionContent\"\u003e \u003cp\u003eComparative Evaluation Results for Layer 3 Routing Configuration\u003c/p\u003e \u003c/div\u003e \u003c/caption\u003e \u003ccolgroup cols=\"5\"\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c1\" colnum=\"1\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c2\" colnum=\"2\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c3\" colnum=\"3\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c4\" colnum=\"4\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c5\" colnum=\"5\"\u003e\u003c/div\u003e \u003cthead\u003e \u003ctr\u003e \u003cth align=\"left\" colname=\"c1\"\u003e \u003cp\u003eMetric\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c2\"\u003e \u003cp\u003eLinux Bash\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c3\"\u003e \u003cp\u003eCisco IOS\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c4\"\u003e \u003cp\u003eJuniper Junos\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c5\"\u003e \u003cp\u003eArista EOS\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003c/thead\u003e \u003ctbody\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e\u003cb\u003eConfiguration Complexity\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e\u0026nbsp;\u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e\u0026nbsp;\u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e\u0026nbsp;\u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e\u0026nbsp;\u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e- Lines of Configuration\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e15\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e27\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e32\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e25\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e\u003cb\u003ePerformance\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e\u0026nbsp;\u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e\u0026nbsp;\u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e\u0026nbsp;\u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e\u0026nbsp;\u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e- Throughput (Gbps)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e9.8\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e9.7\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e9.6\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e9.8\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e- Latency (\u0026micro;s)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e12\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e14\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e13\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e12\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e\u003cb\u003eResource Utilization\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e\u0026nbsp;\u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e\u0026nbsp;\u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e\u0026nbsp;\u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e\u0026nbsp;\u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e- CPU Usage (%)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e8\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e6\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e7\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e6\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e- Memory Usage (MB)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e256\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e192\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e224\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e208\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e\u003cb\u003eDebugging\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e\u0026nbsp;\u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e\u0026nbsp;\u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e\u0026nbsp;\u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e\u0026nbsp;\u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e- Steps to Troubleshoot\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e5\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e8\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e7\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e6\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e- Time to Resolve (min)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e15\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e25\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e20\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e18\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003c/tbody\u003e \u003c/colgroup\u003e \u003c/table\u003e\u003c/div\u003e \u003c/p\u003e \u003cp\u003eConfiguration Complexity:\u003c/p\u003e \u003cp\u003e\u0026bull; The Linux-based configuration required only 15 lines, while Cisco IOS, Juniper Junos, and Arista EOS required 28, 32, and 25 lines, respectively. The Linux configuration is more concise and simpler compared to the vendor-specific configurations.\u003c/p\u003e \u003cp\u003ePerformance:\u003c/p\u003e \u003cp\u003e\u0026bull; The performance in terms of throughput and latency is comparable across all platforms. The Linux-based configuration achieved a throughput of 9.8 Gbps and a latency of 12 \u0026micro;s, which is on par with the vendor-specific implementations.\u003c/p\u003e \u003cp\u003eResource Utilization:\u003c/p\u003e \u003cp\u003e\u0026bull; The CPU usage for the Linux-based configuration is slightly higher at 8% compared to 6\u0026ndash;7% for the vendor-specific versions. This difference is minimal and within acceptable limits.\u003c/p\u003e \u003cp\u003e\u0026bull; Memory usage is also slightly higher for the Linux version at 256 MB compared to 192\u0026ndash;224 MB for the vendor-specific implementations. However, this difference is not significant and does not impact the overall performance.\u003c/p\u003e \u003cp\u003eDebugging:\u003c/p\u003e \u003cp\u003e\u0026bull; Troubleshooting and debugging are simpler with the Linux tools due to familiarity and consistency across devices.\u003c/p\u003e \u003cp\u003e\u0026bull; The Linux-based configuration required only 5 steps to troubleshoot the issue, while Cisco IOS, Juniper Junos, and Arista EOS required 8, 7, and 6 steps, respectively.\u003c/p\u003e \u003cp\u003e\u0026bull; The time taken to resolve the issue was also shorter with the Linux tools, taking only 15 minutes compared to 25, 20, and 18 minutes for Cisco IOS, Juniper Junos, and Arista EOS, respectively.\u003c/p\u003e \u003cp\u003eThese results demonstrate that the Linux-based configuration provides comparable performance to vendor-specific implementations while offering the benefits of simplicity, consistency, and easier debugging. The slightly higher resource utilization in the Linux version is within acceptable limits and does not impact the overall performance.\u003c/p\u003e \u003cp\u003e.\u003c/p\u003e \u003cp\u003eThese evaluation results demonstrate that our Linux-based network configuration architecture is feasible to implement and can provide significant benefits in terms of simplicity, consistency, and ease of use. While more comprehensive testing is needed, our initial findings suggest this approach is promising.\u003c/p\u003e"},{"header":"7. Discussion","content":"\u003cp\u003eOur implementation and evaluation of Linux-based network configuration shows that this approach can provide significant benefits compared to traditional vendor-specific CLIs and APIs. By using a consistent, familiar set of Linux commands and tools, network engineers can more easily configure and manage devices from multiple vendors. This reduces training and onboarding time, improves operational efficiency, and lowers the risk of configuration errors.\u003c/p\u003e \u003cp\u003eThe Linux networking stack and tools are well-suited for network device configuration due to their flexibility, extensibility, and robustness. They can support a wide range of use cases and features, from basic interface settings to advanced routing protocols and security policies. While some custom features may require device-specific extensions, the core functionality needed for most network configurations is readily available.\u003c/p\u003e \u003cp\u003ePerformance and resource utilization are potential concerns with a Linux-based configuration approach, especially on lower-end devices. However, our evaluation results show that the Linux networking stack can provide throughput and latency comparable to optimized vendor implementations in common use cases. CPU and memory overhead is modest and manageable. Further optimizations are possible if needed.\u003c/p\u003e \u003cp\u003eInteroperability and consistency across Linux kernel versions and distributions are challenges that would need to be addressed by any large-scale deployment of this approach. Careful testing and validation would be needed to ensure configurations produce reliable and predictable behavior on different devices and platforms. Industry collaboration on standards and best practices could help mitigate fragmentation.\u003c/p\u003e \u003cp\u003eAdoption of a Linux-based configuration interface would require buy-in and support from network hardware and software vendors. Some may resist moving away from proprietary CLIs and APIs, which can be a source of differentiation and lock-in. However, the rise of open networking and whitebox switches shows there is growing demand for more interoperable and flexible solutions. Operators should encourage vendors to support Linux-based configuration as an option, even if not the default.\u003c/p\u003e \u003cp\u003eFrom a training and skills perspective, standardizing on Linux networking tools could have significant benefits. Many engineers are already familiar with Linux from server management and DevOps roles. Applying this knowledge to network configuration would make their skills more portable and valuable. Certifications and training programs could be updated to emphasize Linux networking concepts.\u003c/p\u003e \u003cp\u003eOverall, while challenges remain, we believe the potential benefits of Linux-based network configuration are compelling. It represents a path towards a more open, interoperable, and automatable future for networking. Further work is needed to validate and scale this approach, but our initial results are promising.\u003c/p\u003e"},{"header":"8. Conclusion","content":"\u003cp\u003eThis paper has proposed using Linux networking commands and tools as a standard configuration interface for network devices. We have analyzed the benefits and challenges of this approach, presented an architecture for mapping between Linux and vendor-specific configurations, and implemented and evaluated common use cases.\u003c/p\u003e \u003cp\u003eOur results show that Linux-based network configuration can provide significant improvements in simplicity, consistency, and operational efficiency compared to proprietary vendor CLIs and APIs. It enables network engineers to use familiar tools and workflows across devices from multiple vendors. Performance and resource utilization are acceptable, and the approach is feasible to implement and scale.\u003c/p\u003e \u003cp\u003eHowever, challenges remain in terms of comprehensive feature support, cross-platform interoperability, and vendor adoption. Further work is needed to validate and extend this approach through research, development, and standardization efforts. Network operators should advocate for Linux-based configuration support from their vendors.\u003c/p\u003e \u003cp\u003eThe rise of open networking, software-defined infrastructure, and network automation make this an opportune time to rethink traditional approaches to device configuration. Adopting Linux as a standard would represent a major step towards a more interoperable, flexible, and efficient future for networking. We call on the community to collaborate on realizing this vision.\u003c/p\u003e"},{"header":"Declarations","content":"\u003ch2\u003eAuthor Contribution\u003c/h2\u003e\u003cp\u003eF Kaniwa, contributed everything\u003c/p\u003e"},{"header":"References","content":"\u003col\u003e\n\u003cli\u003eK. Sui et al., \u0026quot;The State of the Art in Network Automation with Open Source Tools,\u0026quot; in NOMS 2022-2022 IEEE/IFIP Network Operations and Management Symposium, 2022, pp. 1-9.\u003c/li\u003e\n\u003cli\u003eR. Birkner et al., \u0026quot;Metha: Network verifiers need to be correct too!\u0026quot; in Proceedings of the 19th ACM Workshop on Hot Topics in Networks, 2020, pp. 152-158.\u003c/li\u003e\n\u003cli\u003eH. H. Liu et al., \u0026quot;Automatic synthesis of network configuration verification,\u0026quot; in Formal Methods in Computer-Aided Design (FMCAD), 2017, pp. 1-9.\u003c/li\u003e\n\u003cli\u003eB. Schlinker et al., \u0026quot;Condor: Better topologies through declarative design,\u0026quot; in Proceedings of the 2015 ACM Conference on Special Interest Group on Data Communication, 2015, pp. 1-12.\u003c/li\u003e\n\u003cli\u003eR. Rosen, \u0026quot;Linux ip Command Cheat Sheet,\u0026quot; 24-Sep-2020.\u003c/li\u003e\n\u003cli\u003eN. McKeown et al., \u0026quot;OpenFlow: Enabling innovation in campus networks,\u0026quot; ACM SIGCOMM Computer Communication Review, vol. 38, no. 2, pp. 69-74, 2008.\u003c/li\u003e\n\u003cli\u003eOpenFlow Switch Specification. Version 1.5.1 ( Protocol version 0x06 ). Open Networking Foundation, Mar. 2015. Available: https://opennetworking.org/wp-content/uploads/2014/10/openflow-switch-v1.5.1.pdf\u003c/li\u003e\n\u003cli\u003eP. Berde et al., \u0026quot;ONOS: Towards an open, distributed SDN OS,\u0026quot; in Proceedings of the Third Workshop on Hot Topics in Software Defined Networking, 2014, pp. 1-6.\u003c/li\u003e\n\u003cli\u003eJ. Medved et al., \u0026quot;Opendaylight: Towards a model-driven SDN controller architecture,\u0026quot; in Proceeding of IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks 2014, 2014, pp. 1-6.\u003c/li\u003e\n\u003cli\u003eA. Clemm, L. Ciavaglia, L. Z. Granville, and J. Tantsura, \u0026quot;Intent-Based Networking-Concepts and Definitions,\u0026quot; Internet Engineering Task Force, Internet-Draft draft-irtf-nmrg-ibn-concepts-definitions-09, May 2023.\u003c/li\u003e\n\u003cli\u003eB. E. Ujcich, A. Bates, and W. H. Sanders, \u0026quot;Provenance for configuration troubleshooting,\u0026quot; in 2017 IEEE 37th International Conference on Distributed Computing Systems (ICDCS), 2017, pp. 1894-1901.\u003c/li\u003e\n\u003cli\u003eW. Wang et al., \u0026quot;NEMO: Making network functions more robust with traffic provenance,\u0026quot; in Proceedings of the 16th International Conference on emerging Networking EXperiments and Technologies, 2020, pp. 154-167.\u003c/li\u003e\n\u003cli\u003eA. Fogel et al., \u0026quot;A general approach to network configuration analysis,\u0026quot; in 12th USENIX Symposium on Networked Systems Design and Implementation (NSDI 15), 2015, pp. 469-483.\u003c/li\u003e\n\u003cli\u003eR. Beckett et al., \u0026quot;Don\u0026apos;t mind the gap: Bridging network-wide objectives and device-level configurations,\u0026quot; in Proceedings of the 2016 ACM SIGCOMM Conference, 2016, pp. 328-341.\u003c/li\u003e\n\u003cli\u003e\u0026quot;Netopeer - NETCONF toolset.\u0026quot; [Online]. Available: https://netopeer.liberouter.org/. [Accessed: 30-Jul-2023].\u003c/li\u003e\n\u003cli\u003e\u0026quot;Cumulus Linux.\u0026quot; [Online]. Available: https://cumulusnetworks.com/products/cumulus-linux/. [Accessed: 30-Jul-2023].\u003c/li\u003e\n\u003cli\u003e\u0026quot;OpenSwitch.\u0026quot; [Online]. Available: http://www.openswitch.net/. [Accessed: 30-Jul-2023].\u003c/li\u003e\n\u003cli\u003e\u0026quot;iproute2 utility suite.\u0026quot; [Online]. Available: https://wiki.linuxfoundation.org/networking/iproute2. [Accessed: 30-Jul-2023].\u003c/li\u003e\n\u003cli\u003e\u0026quot;net-tools.\u0026quot; [Online]. Available: http://net-tools.sourceforge.net/. [Accessed: 30-Jul-2023].\u003c/li\u003e\n\u003cli\u003e\u0026quot;netfilter/iptables project homepage - The netfilter.org project,\u0026quot; 28-Jul-2023. [Online]. Available: https://netfilter.org/. [Accessed: 30-Jul-2023].\u003c/li\u003e\n\u003cli\u003e\u0026quot;ipset.\u0026quot; [Online]. Available: https://ipset.netfilter.org/. [Accessed: 30-Jul-2023].\u003c/li\u003e\n\u003cli\u003e\u0026quot;Ebtables - NetFilter,\u0026quot; 28-Jul-2023. [Online]. Available: https://ebtables.netfilter.org/. [Accessed: 30-Jul-2023].\u003c/li\u003e\n\u003cli\u003e\u0026quot;bridge-utils.\u0026quot; [Online]. Available: http://www.linuxfromscratch.org/blfs/view/svn/basicnet/bridge-utils.html. [Accessed: 30-Jul-2023].\u003c/li\u003e\n\u003cli\u003e\u0026quot;tc(8) - Linux manual page.\u0026quot; [Online]. Available: https://man7.org/linux/man-pages/man8/tc.8.html. [Accessed: 30-Jul-2023].\u003c/li\u003e\n\u003cli\u003e\u0026quot;ethtool(8) - Linux manual page.\u0026quot; [Online]. Available: https://man7.org/linux/man-pages/man8/ethtool.8.html. [Accessed: 30-Jul-2023].\u003c/li\u003e\n\u003cli\u003eR. Rosen, \u0026quot;Linux Kernel Networking: Implementation and Theory\u0026quot;. Apress, 2014.\u003c/li\u003e\n\u003cli\u003e\u0026quot;systemd-networkd \u0026mdash; System and Service Manager.\u0026quot; [Online]. Available: https://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html. [Accessed: 30-Jul-2023].\u003c/li\u003e\n\u003cli\u003eB. Lantz, B. Heller, and N. McKeown, \u0026quot;A network in a laptop: Rapid prototyping for software-defined networks,\u0026quot; in Proceedings of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks - Hotnets \u0026apos;10, Monterey, CA, USA, 2010, pp. 1-6.\u003c/li\u003e\n\u003cli\u003e\u0026quot;Open vSwitch.\u0026quot; [Online]. Available: https://www.openvswitch.org/. [Accessed: 30-Jul-2023].\u003c/li\u003e\n\u003c/ol\u003e"}],"fulltextSource":"","fullText":"","funders":[],"hasAdminPriorityOnWorkflow":false,"hasManuscriptDocX":true,"hasOptedInToPreprint":true,"hasPassedJournalQc":"","hasAnyPriority":false,"hideJournal":true,"highlight":"","institution":"","isAcceptedByJournal":false,"isAuthorSuppliedPdf":false,"isDeskRejected":"","isHiddenFromSearch":false,"isInQc":false,"isInWorkflow":false,"isPdf":false,"isPdfUpToDate":true,"isWithdrawnOrRetracted":false,"journal":{"display":true,"email":"[email protected]","identity":"researchsquare","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":true,"externalIdentity":"","sideBox":"","snPcode":"","submissionUrl":"/submission","title":"Research Square","twitterHandle":"researchsquare","acdcEnabled":true,"dfaEnabled":false,"editorialSystem":"","reportingPortfolio":"","inReviewEnabled":false,"inReviewRevisionsEnabled":true},"keywords":"","lastPublishedDoi":"10.21203/rs.3.rs-4406805/v1","lastPublishedDoiUrl":"https://doi.org/10.21203/rs.3.rs-4406805/v1","license":{"name":"CC BY 4.0","url":"https://creativecommons.org/licenses/by/4.0/"},"manuscriptAbstract":"\u003cp\u003eNetwork device configuration is a complex task that relies on vendor-specific command languages, resulting in a steep learning curve for network engineers. This paper proposes adopting Linux networking commands as a standard configuration language across hardware vendors. We examine the background and precedent for this approach, analyze the benefits and challenges, and present a detailed architecture. We demonstrate the feasibility through rigorous implementation examples and experimental evaluation. Results show that the Linux-based approach can significantly reduce configuration complexity and errors while providing performance comparable to vendor-specific Command Line Interfaces (CLIs). We discuss the implications of these findings and call for further research and standardization efforts around Linux-based network configuration. Widespread adoption of Linux networking commands could accelerate network automation, improve operational efficiency, and simplify engineer training.\u003c/p\u003e","manuscriptTitle":"Exploring Linux Algorithmic Approach as a Standard Network Configuration Language Model for Network Devices","msid":"","msnumber":"","nonDraftVersions":[{"code":1,"date":"2024-05-22 06:52:56","doi":"10.21203/rs.3.rs-4406805/v1","editorialEvents":[{"type":"communityComments","content":0}],"status":"published","journal":{"display":true,"email":"[email protected]","identity":"researchsquare","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":true,"externalIdentity":"","sideBox":"","snPcode":"","submissionUrl":"/submission","title":"Research Square","twitterHandle":"researchsquare","acdcEnabled":true,"dfaEnabled":false,"editorialSystem":"","reportingPortfolio":"","inReviewEnabled":false,"inReviewRevisionsEnabled":true}}],"origin":"","ownerIdentity":"4e06249c-ad08-4de8-b2f5-45a4660279cd","owner":[],"postedDate":"May 22nd, 2024","published":true,"recentEditorialEvents":[],"rejectedJournal":[],"revision":"","amendment":"","status":"posted","subjectAreas":[],"tags":[],"updatedAt":"2024-07-22T12:54:03+00:00","versionOfRecord":[],"versionCreatedAt":"2024-05-22 06:52:56","video":"","vorDoi":"","vorDoiUrl":"","workflowStages":[]},"version":"v1","identity":"rs-4406805","journalConfig":"researchsquare"},"__N_SSP":true},"page":"/article/[identity]/[[...version]]","query":{"redirect":"/article/rs-4406805","identity":"rs-4406805","version":["v1"]},"buildId":"qtupq5eGEP_6zYnWcrvyt","isFallback":false,"isExperimentalCompile":false,"dynamicIds":[84888],"gssp":true,"scriptLoader":[]}