Contents

General Information

This section provides information on basic aspects of configuring an Ethernet interface for the emulator. For details on the configuration parameters used and for additional parameters, please refer to the Configuration File Reference.

The emulated Ethernet interfaces of Charon-PAR can be linked either to a

• physical host interface,
• a TAP interface connected to a virtual bridge on the host, or
• (since Charon-PAR 3.0.9) a MACVTAP interface linked to a physical NIC on the host.

Notes for physical interfaces:

• If used directly as a guest interface, offloading parameters must be turned off using the initialization command parameter in the configuration file.
• In cloud environments, the necessary interface settings are not always reflected correctly on the cloud-provided NICs. For such installation settings a MACVTAP interface can be used to provide a dedicated connection without connecting the emulator directly to the physical interface.

Notes for TAP interfaces:

• A TAP interface can either be created by the user or will be created automatically by the emulator if it does not already exist.
• For automatically created TAP interfaces, the user can specify a name or let the emulator select a name.
• A automatically created TAP interface is not automatically added to a bridge, this must be configured via the initialize_command (see the Ethernet Configuration Parameter table below).
• An automatically created TAP interface is deleted automatically upon emulator stop.
• If used in a cloud environment, only internal virtual bridges (no connection to the cloud LAN) are supported.

Notes for MACVTAP interfaces:

• Introduces a transparent bridge interface associated with on physical NIC on the host, and provides a dedicated interface to the emulator.
• Provides an abstraction layer between physical NIC and emulator.
• Physical interface requires no changes in the offloading configuration.
• Fragmentation is performed by Linux on the MACVTAP interface. Jumbo frames on the physical interface will not cause problems.
• Uses same MAC address as the physical interface.
• Suited for associating a dedicated host Ethernet interface to the emulator in cloud environments.

Notes for network configurations on VMware:

• ESXi has configuration parameters that improve security but may block certain emulator NIC configurations.
• One configuration option allows or blocks promiscuous mode (the default mode of operation for Charon-PAR guest NICs).
• Other configuration options allow or block the change of a MAC address or the use of a different, additional MAC address on the same NIC (MAC address changes, Forged transmits).

By default, emulated models have one Ethernet device. Depending on the model, more Ethernet devices can be added.

A guest HP-UX system will perceive the network card as a 10/100 Mbit/s controller running at 10 Mbit/s half-duplex. If the user tries to change this setting using SAM or the lanadmin command, the command will be accepted but the displayed interface settings will not change.  However, the throughput of the emulated network card depends on the combination of network performance, physical network card characteristics, host system and guest system performance - it is not tied to the displayed interface settings. So the actual throughput will be what can be achieved depending on the conditions listed above.

The emulated network devices

• DE 500 PCI based cards (for 64-bit systems), and

• LASI-82596 cards (for the 32-bit system)

do not support Jumbo frames. For physical interfaces, this feature must be disabled in the emulator configuration (together with any other offloading parameters) using the initialize_command parameter.

Considerations for Cloud Environments

Every cloud environment has specific characteristics that could conflict with the interface configurations made for Charon-PAR. Please refer to the documentation provided by the cloud provider to understand the networking behavior of your cloud instance before you change any interface settings.

Important points that apply to most cloud environments:

• If the Charon host is configured with more than one active IP interface, asymmetric routing can cause connectivity problems. In such cases, policy-based routing (per interface routing tables with associated IP rules) is required.

• Only IP unicast traffic is supported. Non-IP traffic or multicast/broadcast traffic is not supported and requires traffic tunneling.

• Promiscuous interface mode is not supported.
• Only traffic with the MAC address assigned by the cloud provider is allowed across an interface.

• Routing requires special configuration steps (source/destination check disabling) on the cloud instances. Enabling IP forwarding on the Linux host is not enough.

• Cloud specific security rules must allow the relevant traffic. Configuring the Linux firewall correctly is not enough.

• If a host NIC is dedicated to a guest system, the MAC address and IP address assigned to the interface by the cloud provider must be used by the guest.

Basic Configuration Components

Ethernet Interface Names

Names on 64-bit systems:

The name of the Ethernet interface in the emulator configuration file has the format EWXN with the following definitions:

• X  - an uppercase letter starting with A for the first interface and then continues with B, C, etc. for additional interfaces. The possible number of network cards depends on the features of the original physical system. The absolute maximum number is 16.
• N - the device number of the card starting with 0 for each value of x.

Names on 32-bit systems:

The currently supported 32-bit system supports only one Ethernet card:

• Model 720: system.lan0.card
• Model B132L: gsc.lasi.lan.card

Minimal Configuration Parameters

The configuration of each network interface must at least have two basic components as shown below:

64-bit system (example shows the first Ethernet card EWA0):

• Interface definition (EWA0.iface)
• Interface initialization command (EWA0.initialize_command)

32-bit system:

• Interface definition (system.lan0.card.iface or gsc.lasi.lan.card.iface)
• Interface initialization command (system.lan0.card.initialize_command or gsc.lasi.lan.card.initialize_command)

The default configuration assumes that a physical network interface will be used.

Please refer to the Configuration File Reference and the configuration template of your model for more information.

Basic Configuration Example

Example of a basic network card configuration using a physical interface on a 64-bit emulated system:

EWA0.iface="enp0s20f0u3u4"
EWA0.initialize_command="ethtool -K $IFACE rx off ; ethtool -K $IFACE tx off ; ethtool -K $IFACE sg off ; ethtool -K $IFACE gso off ; ethtool -K $IFACE gro off ; ethtool -K $IFACE txvlan off ; ethtool -K $IFACE rxvlan off"

The variable IFACE is set automatically by the emulator upon start. The initialize_command parameter is used to turn off all relevant offloading parameters on the interface used by the emulator.

Adding Additional Emulated Network Cards

Please note: if additional Ethernet controllers can be loaded - and how many - depends on the emulated model.

This section will show an example. Please refer to the section I/O Slot Configuration in the Configuration File Reference chapter and the Emulated Model Hardware Configuration Details chapter for details.

To add an additional Ethernet controller to your emulator configuration, you must perform the following steps:

• Identify a free PCI slot (model configuration template or Emulated Model Hardware Configuration Details).
• Add a load command to the configuration to load an Ethernet module into the identified emulator slot (see the Configuration File Reference chapter for details).
• Add the network card configuration to your configuration file.
• Start the emulator and configure the interface in the guest system.

Step 1: identify a free PCI slot for your emulated model. The available slots depend on your model and the existing configuration.

Example: model "rp7400-1-650" has a PCI I/O expansion slot 4 (device path 0/8/0)

Step 2: Add the load command for the Ethernet module to the configuration file.

Sample configuration command for slot 4:  load ETH tulip PCI 4

Step 3: Add the network card configuration to your configuration file selecting the correct host interface name (example: eth2). Note that the name of the second emulated interface is EWB0.

Example (important: the initialization command must be in one continuous line):

EWB0.iface="eth2" 
EWB0.initialize_command="ethtool -K $IFACE rx off; ethtool -K $IFACE tx off; ethtool -K $IFACE sg off; ethtool -K $IFACE gso off; ethtool -K $IFACE gro off; ethtool -K $IFACE txvlan off; ethtool -K $IFACE rxvlan off" 

Step 4: Start the emulator, boot the guest system and configure the second interface.

• On PA3, use the ISL > ODE > RUN MAPPER2 command (access from console via: Interaction with IPL) to verify the existence of the new interface and the correct device path.
• The above command also works on PA9, but on HP-UX you can also use the lanscan command to verify the existence of the new interface (on HP-UX it is normally lan1).
• Configure the interface.
  • The easiest way on HP-UX is the following:
    • HP-UX before 11.31: use SAM > Network and Communication > Network Interface Cards (Actions > Configure).
    • HP-UX 11.31: use SMH > Networking and Communications-> Network Interfaces Configuration > Network Interface Cards. Please note that at the time of writing SMH only worked with the emulator when being used over the network (not on the serial console).
  • On MPE/iX, the interface must be added via NMMGR (for interactive use, xhpterm can be used to access this tool), and the interface must be started using the NETCONTROL command. Please refer to the documentation of your operating system for further information.

The following image shows a sample of a HP-UX system with two Ethernet interfaces:

The following shows a sample of the second Ethernet interface being configured on device path 0/8/0/0:

On an MPE/iX system, the device path is needed to configure the new network link.

The following shows a sample of two active Ethernet interfaces on MPE/iX:

Supplemental Information: Virtual Bridge and TAP Interfaces

The following sections describe the basic steps for the configuration of virtual bridges and TAP interfaces.

Please note:

• The examples describe a virtual bridge that connects host and guest system to the local LAN via a physical NIC.
• The described virtual bridge configuration is mostly suited for on-premises installations where the host system runs on a physical system.
• For VMware (or similar environments) it is recommended to add additional vNICs for the guest as needed - instead of using a bridge configuration on the host.
• In most cloud environments, a virtual bridge cannot directly link bridge traffic to the LAN via a host NIC. There are usually restrictions regarding the MAC addresses allowed on the NICs of a cloud instance. Also promiscuous mode is usually not possible. Hence, in such environments, traffic between a virtual bridge and the rest of the network must usually be NAT'ed or routed. The virtual bridge is then internal to the Linux host and not connected directly to the LAN.

Basic Bridge Configuration Using ip Commands

The following table shows a simple example of how to create a virtual bridge on Linux and how to add TAP interfaces to it using ip commands:

Please note: The commands above are not persistent. They would need to be scripted and added to the host system startup as required.

To delete TAP and bridge interfaces, you can use the command ip link delete <interface-name>.

Basic Bridge Configuration Using nmcli

The following table shows a simple example of how to create a virtual bridge on Linux and how to add TAP interfaces to it using nmcli commands (NetworkManager command-line interface):

After the bridge has been created, you can let the emulator create a TAP interface automatically and use the initialize command in the emulator configuration to add the TAP interface for the emulator to the bridge.

Please note: By default, nmcli commands are persistent. The connection information is stored in /etc/sysconfig/network-scripts/  if the default plugin in
/etc/NetworkManager/NetworkManager.conf  is ifcfg-rh. It is stored in /etc/NetworkManager/system-connections/ if the default plugin is keyfile. Permanent TAP connection information is always stored in the NetworkManager directory unless the network-scripts package is used for configuration.

Basic Emulator Configuration Using a TAP Interface

The following example shows how to use a TAP interface in the emulator configuration, where the interface is automatically created and removed by the emulator. The initialization command adds the interface to an existing bridge named my_bridge:

EWA0.mapping_mode="TAP"
EWA0.initialize_command="ip link set ${IFACE} master my_bridge"

Please refer to the Configuration File Reference and the configuration template of your model for more information.

Linux Firewalls and Virtual Bridges

If firewall rules are to be used for bridged traffic, the kernel can be instructed to apply iptables (also arptables and ip6tables) rules to bridged traffic. In older versions, this option was included in the bridge functionality itself. Starting with kernel 3.18, the filtering functionality in the form of the br_netfilter module was moved into a separate module that can be loaded by the user if required. If the module is not loaded, no firewall rules are applied to bridge traffic and no further actions are required to pass the bridged traffic through the Linux host system.

To check, if the module is loaded use the command

# lsmod | grep netfilter

To use the firewall for bridged traffic on newer Linux kernels, the module must be loaded using the command

# modprobe br_netfilter

or by defining an iptables rule that uses the physdev module.

If the module has been loaded, the following system configuration parameters are available:

• net.bridge.bridge-nf-call-iptables
• bridge-nf-call-arptables
• bridge-nf-call-ip6tables

They are set to 1 by default (equivalent to echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables). This value enables iptables rules for bridged traffic (and by default blocks bridged traffic).

Setting the parameters to 0 will disable the firewall for bridged traffic. They can be set permanently via /etc/sysctl.conf.

To allow bridged traffic through the enabled firewall, use commands like the following:

# firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 \

-m physdev --physdev-is-bridged -j ACCEPT

# firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 1 \

-m physdev --physdev-is-bridged -j ACCEPT

# firewall-cmd --reload

Please refer to the documentation of your host system for more detailed information.

Please note: at the time of writing, this feature is not yet available for nftables.

Supplemental Information: MACVTAP Interfaces (since version 3.0.9)

In some cloud environments, interface settings on the Linux level are not passed properly to the NIC on the cloud level. This can cause problems with network connectivity and, in particular, with network performance. The problem can be solved by using a virtual bridge between host and guest, and by configuring routing or NAT to allow guest communication with other systems. However, such configurations are often complex due to the fact that only the cloud-assigned MAC and IP addresses can be used. On a virtual bridge to which host and guest are attached, this condition cannot be met.
MACVTAP interfaces provide an alternative solution - they are linked to a host NIC and are TAP based. However, when used in passthrough mode, they can use the same MAC and IP address as assigned by the cloud provider.

Basic (non-persistent) configuration of a MACVTAP interface on the Linux host system:

Basic (persistent) configuration of a MACVTAP interface on the Linux host system using nmcli commands:

Basic emulator configuration using a MACVTAP interface:

EWA0.mapping_mode = "MACVTAP"
EWA0.iface = "macvtap0"