It seems once people master the basics of containers, networking is one of the first aspects they begin experimenting with. And regarding networking, it takes very little experimentation before ending up on the deep end of the pool. The following guide shows the most common network setups for Podman rootful and rootless containers. Each setup is supported with an example.
OpenWISP is a modular network management system built on top of OpenWRT (but designed to allow supporting multiple embedded operating systems) that allows managing and automating several aspects of IT network deployment, monitoring and management:
- registration/provisioning of new nodes
- creation of VPN tunnels
- possibility of defining configuration templates and configuration variables to make the maintenance of configurations easier and faster
- possibility of configuring mesh networks as well as wireless access points using WPA2, WPA3, 802.1x (WPA enterprise) , WPS, WEP, multiple SSIDs, etc.
- possibility of deploying any network configuration supported by OpenWRT
- monitoring, collection of metrics, active checks, threshold definition and alerts
- RADIUS (eg: for wifi access / hotspot systems or ISPs)
- responsive captive page with features like user registration, SMS verification, social login
- firmware upgrades
- web and email notifications for important events happening in the network
- network topology visualization for mesh networks and VPN networks
The preceding list is not an exhaustive list but more like an overview of what OpenWISP can do.
Kea is open source, shared under MPL2.0 licensing. Kea is developed in the open on ISC’s GitLab; we welcome you to open issues and submit patches there. Kea runs on most Linux and Unix platforms, as well as MacOS. If you don’t want to build from our source distribution, we also provide a repository of pre-built packages for most popular operating systems.
ISC distributes and maintains TWO open source, standards-based DHCP server distributions: Kea DHCP and ISC DHCP. Kea includes all the most-requested features, is far newer, and is designed for a more modern network environment.
How is the Kea DHCP server different from the older ISC DHCP?
-
Modular Component Design, Extensible with Hooks Modules. The Kea distribution includes separate daemons for a DHCPv4 server, a DHCPv6 server, and a dynamic DNS (DDNS) module. Many optional features are enabled with dynamically-loaded “Hooks Modules,” which you need run only if you are using them. You can write your own hooks modules (in C++) or try some of the hooks we offer.
-
On-line Re-configuration with REST API Kea uses a JSON configuration file that can be modified remotely via set commands and reloaded without stopping and restarting the server, an operation that could take quite a while with ISC DHCP.
-
Designed to Integrate with Your Existing Systems. Kea allows you to separate the data from the execution environment, enabling new deployment options. Your network data - leases, host reservation definitions, and most configuration data - can be located separately from the DHCP server itself, using a Kea “backend.”
-
Web-based graphical dashboard Kea now has a graphical dashboard for monitoring multiple Kea servers. This system, called Stork, uses agents deployed on the Kea servers to relay information to a centralized management platform, providing the administrator with an easy-to-use quick view of system status and activity.
Kea supports two database backends; MySQL and PostgreSQL. Choose to store leases, host reservations, or shared configuration data in a separate database backend. Benefits of this include:
-
Integrate it more easily with your other systems - provisioning systems, IPAMS and so on - by storing critical data in a separate database.
-
Use the same hosts reservations backend for multiple DHCP servers.
-
Administer global options from a centralized configuration backend.
-
Manage large address pools in a database rather than a text file.


Network booting is cool. Once you have setup everything you can stop juggling iso images in your virtual machine configs. Instead you just kick a network boot and pick whatever you want install from the boot menu delivered by the boot server.
This article is not about the basics of setting up a boot server. The internet has tons of tutorials on how to install a tftp server and how to boot your favorite OS from tftp. This article will focus on configuring network boot for libvirt-managed virtual machines.
Network automation to screen-scraping devices is primarily concerned with gathering output from show commands and with making configuration changes.
Netmiko aims to accomplish both of these operations and to do it across a very broad set of platforms. It seeks to do this while abstracting away low-level state control (i.e. eliminate low-level regex pattern matching to the extent practical).
Nornir is an automation framework written in python to be used with python. Most automation frameworks hide the language they are written in by using some cumbersome pseudo-language which usually is almost Turing complete, but lacks tooling to debug and troubleshoot. Integrating with other systems is also usually quite hard as they usually have complex APIs if any at all. Some of the other common problems of those pseudo-languages is that are usually quite bad at dealing with data and re-usability is limited.
Nornir aims to solve those problems by providing a pure python framework. Just imagine Nornir as the Flask of automation. Nornir will take care of dealing with the inventory where you have your host information, it will take care of dispatching the tasks to your devices and will provide a common framework to write “plugins”.
Fabio is an HTTP and TCP reverse proxy that configures itself with data from Consul.
Traditional load balancers and reverse proxies need to be configured with a config file. The configuration contains the hostnames and paths the proxy is forwarding to upstream services. This process can be automated with tools like consul-template that generate config files and trigger a reload.
Fabio works differently since it updates its routing table directly from the data stored in Consul as soon as there is a change and without restart or reloading.
When you register a service in Consul all you need to add is a tag that announces the paths the upstream service accepts, e.g. urlprefix-/user or urlprefix-/order and fabio will do the rest.
At Cloudflare we pride ourselves in our global network that spans more than 200 cities in over 100 countries. To handle all the traffic passing through our network, there are multiple technologies at play. So let’s have a look at one of the cornerstones that makes all of this work… ASICs. No, not the running shoes.
ifupdown-ng is a network device manager that is largely compatible with Debian ifupdown, BusyBox ifupdown and Cumulus Networks' ifupdown2.
For more information read the admin guide.
OpenSource-Tools for network and automation - Eine kleine Reise durch den Zoo - Falk Stern
Oxidized is a network device configuration backup tool. It's a RANCID replacement!
Light and extensible, Oxidized supports more than 120 operating system types.
Feature highlights:
Automatically adds/removes threads to meet configured retrieval interval
Restful API to a move node immediately to head-of-queue (GET/POST /node/next/[NODE])
Syslog udp+file example to catch config change events (IOS/JunOS) and trigger a config fetch
Will signal which IOS/JunOS user made the change, can then be used by output modules (via POST)
The git output module uses this info - 'git blame' will show who changed each line, and when
Restful API to reload list of nodes (GET /reload)
Restful API to fetch configurations (/node/fetch/[NODE] or /node/fetch/group/[NODE])
Restful API to show list of nodes (GET /nodes)
Restful API to show list of version for a node (/node/version[NODE]) and diffsThe DroneBot Workshop is the place to be if you are interested in working with Arduino, Raspberry Pi, Electronics, Robotics, Internet of Things, Quadcopters and other high tech fun things. You'll learn how components work and how you can use them in your experiments, as well as fascinating projects you can build yourself.
Romana is a network and security automation solution for cloud native applications. Romana automates the creation of isolated cloud native networks, secures applications using microsegmentation and enforces access control policies on all endpoints, wherever they run.
Romana is network agnostic and secures applications using standard networking techniques so they can be deployed easily on public and private clouds, and even across the Internet.
Applications that run with Romana are easier to operate and deliver higher performance than when using a virtual network overlay. With Romana, an overlay is never required, even across availability zone boundaries. Romana’s innovative approach enables seamless hybrid cloud deployment and lets container orchestration systems transparently scale capacity across private and public clouds worldwide.
Integration with Kubernetes and other cloud orchestration systems lets application developers use their existing tools and workflow to secure their applications with the deployment flexibility they need.
Romana is all open source and is deployed successfully today on servers running thousands of container workloads by operators of some of the largest on-line applications. Romana lets you deploy cloud native applications securely on isolated networks with policy based control. Romana runs in any IaaS, so developers running Kubernetes in a public cloud now have a way to apply network and security policies to all pod communications.
Traditional SDNs are complex, making them hard to deploy and troubleshoot. Calico removes that complexity, with a simplified networking model designed for the demands of today's cloud-native applications.
Unlike SDNs that require a central controller, limiting scalability, Calico is built on a fully distributed, scale-out architecture. So it scales smoothly from a single developer laptop to large enterprise deployments.
Defining secure network policy used to be reserved for skilled network engineers. Calico's powerful micro-segmentation capabilities build on a simple policy language that naturally expresses the developer's intent.
NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support) is a Python library that implements a set of functions to interact with different network device Operating Systems using a unified API.
NAPALM supports several methods to connect to the devices, to manipulate configurations or to retrieve data.
Weave Net - Weaving Containers into Applications
Weave Net creates a virtual network that connects Docker containers across multiple hosts and enables their automatic discovery. With Weave Net, portable microservices-based applications consisting of multiple containers can run anywhere: on one host, multiple hosts or even across cloud providers and data centers. Applications use the network just as if the containers were all plugged into the same network switch, without having to configure port mappings, ambassadors or links.
Services provided by application containers on the weave network can be exposed to the outside world, regardless of where they are running. Similarly, existing internal systems can be opened to accept connections from application containers irrespective of their location.
On layer 2 networks, high availability can be achieved by:
- antique protocols, like the Spanning Tree Protocol,
- proprietary protocols, like Juniper’s virtual chassis, Cisco’s virtual port channel and other MC-LAG implementations,1
- standardized protocols, like Shortest Path Bridging Protocol or TRILL, or
- the underlying network (in the case of an overlay network, like VXLAN).