How to Configure a Multicast Linux Network

By Des Nnochiri

In a world where consumer-level computing technology has been largely dominated by Windows, many users remain unaware of the need for administrators to configure and maintain network hardware and environments based on the Linux operating system. But Linux in its various distributions and the Unix operating system from which they derive have for decades provided the backbone for the core systems that make consumer-level computing and indeed many aspects of daily life possible. Banking, record-keeping, aviation, urban infrastructure; for years, such essential services have been run on the basis of Unix and its offshoots.

As digital technology evolves, networks have been called upon to transmit increasing numbers of video, audio or data streams to multiple destinations, making the need for effective network configuration that much more critical. In this guide, we’ll be looking at how to configure a Linux network, with a particular focus on what’s known as multicast transactions.

Linux Networking Basics

Linux can support multiple devices, easily managing multiple network interface adapters. Laptops set up for Linux will typically include both wired and wireless interfaces, and may also support WiMax interfaces for cellular networks. Not only do Linux desktop systems support multiple network interfaces, but they can also be used as a multi-network client or as a router for an internal network.

By convention, Linux device names are numbered, beginning at zero and counting upwards. So, for example, a system running two Ethernet cards could have two devices, labeled /dev/eth0 and /dev/eth1.

Network Interface Configuration Files

(Image Source: YoLinux.com)

For Linux, every network interface has its own configuration file, which is stored in the /etc/sysconfig/network-scripts directory. Other files in that directory are scripts used to start, stop, and perform various network configuration tasks.

Each network interface has a configuration file named ifcfg-<interface-name>X. Here, X is the number of the interface, starting with zero or 1, depending on the naming convention that’s in use.

This example file defines a static IP address configuration for a CentOS 6 server installation.

(Image Source: opensource.com)

Naming Conventions

Over the years, the naming conventions for Linux network interfaces have evolved from the initial simplicity of “ethX” and its derivatives. Such names are still used by the CentOS 6.x distribution. But the newest naming conventions—as used by Linux distributions such as RHEL 7, CentOS 7, and the more recent releases of Fedora—have forms like eno1 and enp0s3.

These conventions are relevant, as the addition of a new network interface often forces the renaming of existing interfaces , with the attendant risk of breaking links and syntax in associated network scripts and configurations.

Knowing What to Configure

Linux interface configuration files offer a range of options , and as with any network, establishing which aspects to configure constitutes much of the hard work. Options for Red Hat Linux-based distributions will serve as an example. Among the more common configuration options are:

DEVICE: The logical name of the device; e,g., eth0 or enp0s2.
TYPE: The type of network. This is usually Ethernet, but configurations for Token Ring may be encountered on older systems.
HWADDR: The MAC address of the NIC which is bound to the file; e.g., 00:16:76:02:BA:DB.
IPADDR: The IP Address assigned to a particular NIC; e.g., 192.168.0.10.
ONBOOT: An instruction to start the network on this device when the host boots. This is typically set to “no” so that the network doesn’t start until a user logs in to the desktop. Setting this option to “yes” allows the network to start when no one is logged in.
BOOTPROTO: The boot protocol for an interface. The available options are static, DHCP, bootp, or none—with “none” defaulting to “static”.
BROADCAST: The broadcast address for the network; e.g., 192.168.0.255.
NETWORK: The network ID for a subnet, such as the class C ID 192.168.0.0.
NETMASK: The netmask for a subnet; e.g., the class C mask 255.255.255.0.
GATEWAY: The network router or default gateway for a subnet; e.g., 192.168.0.254.
SEARCH: The DNS domain name to search for when doing lookups on unqualified hostnames such as “example.com”.
DNS1: The primary DNS server (e.g., 192.168.0.254), which is a server on the local network.
DNS2: The secondary DNS server (e.g., 8.8.8.8), which is one of the free Google DNS servers. Tertiary DNS servers are not supported in the interface configuration files, but a third server may be configured manually in a non-volatile resolv.conf file.
USERCTL: This option specifies whether non-privileged users may start and stop a network interface. The setting is either yes/no.
IPV6INIT: A yes/no setting to specify whether IPV6 protocols are applied to an interface.

For DHCP networks, the only required options are BOOTPROTO, ONBOOT, and HWADDR. DNS and PEERDNS options may be inserted to override the DNS entries supplied by the DHCP server, where:

PEERDNS: Indicates that /etc/resolv.conf file is to be modified by inserting the DNS server entries specified by DNS1 and DNS2 options, if the “Yes” option is selected. “No” indicates that the resolv.conf file should not be altered. “Yes” is the default setting when DHCP is specified in the BOOTPROTO line.

NetworkManager

In 2004, Red Hat Linux introduced NetworkManager to simplify and automate network configuration and connections—particularly wireless connections. In practice, administrators often need to adjust its settings because of the way that familiar configuration functions are handled by the new layer of configuration files and scripts. This tweak has to be ongoing, as standard configuration files are subject to being overwritten by NetworkManager every time a network is restarted, including each time the system reboots.

The udev Daemon

This is a kernel device manager which is supposed to provide consistent and persistent device naming for all Linux devices, including network devices and removable mass storage devices.

The udev daemon is also used to match network device names to their MAC address on the network interface. Each time a new device is added to the system, the udev device manager creates a rule to identify and name the device if a name does not already exist. The contents of the interface configuration files are used to generate the naming rules.

If an interface configuration file doesn’t exist, plugging in a new device or connecting with a new wireless network causes udev to notify NetworkManager of the presence of a new device or wireless connection. NetworkManager then creates a new interface configuration file to account for this.

Multicast Packet Forwarding and Routing

For the most part, exchanges of data on a network are peer-to-peer unicast transactions. These would include operations such as file transfers using File Transfer Protocol (FTP) under TCP/IP, HTTP requests to a web server, or email via SNMP.

But the increasingly complex nature of modern business communications and the need for networks to cater for large numbers of users or subscribers may dictate a need to transmit video, audio, or data streams to multiple nodes via one transmission stream instead of multiple individual peer to peer connections.

To reduce network loads under such conditions, multicast transmission may be employed. Multicast messages are only “heard” by the nodes on a network that have joined the particular multicast group associated with a transmission and are specifically interested in the information that it contains. Multicast broadcasts occur via User Datagram Protocol (UDP), a protocol which supports a single packet of data with no response, verification, or acknowledgment.

Though Linux may be configured to forward packets and act as a simple router between two networks, this function does not support multicast data packets. In order to enable such packets to be forwarded and routed on the network, multicast routing software must first be installed on the system.

Configuring Linux for Network Multicast

The Linux kernel is Level-2 Multicast-Compliant and meets all the requirements to send, receive, or act as a router for multicast packets or datagrams. The default kernels for Red Hat and Fedora are compiled to support multicast transmission.

Multicasting begins with an application requesting multicast group membership. This request tells a multicast router to enable forwarding on the interface that the request arrived on.

In order for a process to receive multicast datagrams, it has to request the kernel to join the multicast group, and bind the port designated for receiving those datagrams. And if a process is no longer interested in the multicast group, it must send a request to the kernel to leave the group. Note that it’s the kernel or host which joins the multicast group and not the process itself.

The following syntax may be used to configure the Linux kernel to support multicast routing:

CONFIG_IP_MULTICAST=y
CONFIG_IP_ROUTER=y
CONFIG_IP_MROUTE=y
CONFIG_NET_IPIP=y

On systems with more than one IP address or network card (known as “multi-homed” systems), only one device may be configured to handle multicast transmissions. Typically, Class D networks with a range of IP addresses from 224.0.0.0 to 239.255.255.255 are reserved for multicasting.