Fedora and Red Hat Leftovers
-
Red Hat Official ☛ Is your organization ready for the future? Why skills matter
Organizations across all industries and regions are facing a growing shortage of IT skills, whether in security, cloud, IT service management or AI. Fast-changing technologies are creating a strategic need for new skills, and innovative approaches are required to meet this demand effectively. Reskilling and upskilling are leading to emerging roles to specifically manage the opportunities and risks of new and emerging technologies.
-
Peter 'CzP' Czanik ☛ Syslog-ng is coming to EPEL 10
Last December, I added support for EPEL 10 in my unofficial syslog-ng Git snapshot repository. This week, I call for testing the official syslog-ng EPEL 10 package.
-
Hackaday ☛ Retro Big Iron For You
Many of us used “big iron” back in the day. Computers like the IBM S/360 or 3090 are hard to find, transport, and operate, so you don’t see many retrocomputer enthusiasts with an S/370 in their garages. We’ve known for a while that the Hercules emulators would let you run virtual copies of these old mainframes, but every time we’ve looked at setting any up, it winds up being more work than we wanted to spend. Enter [Ernie] of [ErnieTech’s Little Mainframes]. He’s started a channel to show you how to “build” your own mainframe — emulated, of course.
-
Adam Williamson: New laptop experience (Fedora on HP Omnibook Ultra 14 - Ryzen Hey Hi (AI) 365, "Strix Point")
New year, new blog post! Fedora's going great...41 came out and seems to be getting good reviews, there's exciting stuff going on with atomic/bootc, we're getting a new forge, it's an exciting time to be alive...
Personally I've spent a large chunk of the last few weeks bashing my head against two awkward bugs - one kernel bug, one systemd bug. It's a bit of a slog, but hey. Also now working up to our next big openQA project, extending test coverage for the new installer.
-
Red Hat ☛ An overview of virtual routing and forwarding (VRF) in Linux
Virtual routing and forwarding (VRF) is a network virtualization technique allowing traffic isolation at the layer 3 (L3) of the OSI model by creating independent routing and forwarding domains. It is essentially the combination of a separate routing table and associated network interfaces.
Other networking techniques exist but are operating at a different levels—such as VLAN and network namespaces, respectively at the layer 2 and at the device level. Those techniques can be combined, e.g., a VRF can be part of a network namespace and/or VLANs can be attached to a VRF. Note that a network namespace might look like a way to emulate a VRF but they differ in how traffic is handled, notably VRF does not impact layer 2 (L2) traffic.
In the Linux kernel VRF is supported under the
CONFIG_NET_VRFbuild configuration option.Use cases
As we saw, a VRF is used to isolate L3 traffic. As such it can be used in multi-tenancy environments to isolate customers or to support overlapping networks, as L3 addresses and routes are scoped to a given VRF. When VRF was introduced, it was used in combination with MultiProtocol Label Switching (MPLS), which can be used to allow overlapping traffic to be routed in the same backbone. Because of this, strictly speaking, when VRF is used without MPLS it is called "VRF Lite". We'll keep referring to "VRF" in this article.
Another use case is to have a clear separation between the management network and the data plane. In short and depending on the requirements, VRF has value for both routing packets and at the endpoints.
Linux implementation
In Linux, a VRF domain is represented by a virtual L3 network device and packets (ingress and egress) are flowing through it. This has the advantage of providing a single point to attach TC and netfilter rules, to dump non-forwarding traffic for debugging or for making applications "VRF-aware" by binding sockets to the VRF device. The VRF device also acts as a parent for interfaces part of the domain (note that a given network interface can only be part of a single domain). It can also be nested under a network namespace to combine both features.
In addition to the VRF interface, a number of techniques are used which are not specific to VRF: a dedicated routing table per VRF domain and routing policy (ip rules), for instance.
This design—mixing VRF specific techniques and non-VRF ones—is a key point to understand how VRF is implemented in Linux: the VRF implementation is not entirely isolated from the rest of the stack. As such, configuring a VRF implies managing its associated network interface but also handling policy rules and routing tables. The combination of all those techniques provides the routing and forwarding domains.
Under the hood
When a packet is received on an interface, the route lookup is redirected to the right table using policy routing. When a packet is sent, the device is set to the VRF parent device which will ensure the right table is used for the lookup.
VRF in action
As a VRF domain is represented by a virtual interface on Linux, adding a new VRF domain is similar and as simple as adding other kinds of virtual interfaces. The usual tools can be used, such as
iproute2ornmcli. When adding a new VRF device, a dedicated routing table and (if it does not exist yet) special L3 FIB rule (policy routing) are automatically added. The policy routing rule will direct lookups for matching packets to the routing table associated with the VRF domain.L3-enabled network devices that should be part of the VRF domain are then added by making them children of the VRF device. Their local and connected routes are automatically moved to the VRF associated routing table but other routes depending on the device are dropped. Note that because of backward compatibility, global IPv6 addresses are lost by default (this is controlled by the
net.ipv6.conf.all.keep_addr_on_downparameter).Let's add a VRF domain and see what happens: [...]