Kathará and the industrial P4 labs

1. From namespaces to orchestration

Computer networks are complex objects: several devices, several interfaces, several protocols running, physical interconnections that originate complex topologies. Performing experiments on a live network is unfeasible — it hosts services that are critical for the company, it would require coordinating different departments, and network equipment is expensive. The answer is a virtual environment for tests, experiments and measures, and the course is careful to distinguish the two flavours:

The basic idea of emulation: several containers are created inside a single host machine, connected to virtual collision domains so they can communicate. Each container can play the role of a regular host, a router, a switch, an application. Chapter 4 built this by hand with network namespaces, and this chapter is where the course explains why that approach stops scaling. Namespaces give isolation for processes, interfaces and routing stacks — they are fine for simple point-to-point or small manual experiments, but they become hard to manage when the lab includes many nodes, startup scripts, multiple images and repeatable experiments.

2. Kathará: containers as network devices

Kathará is based on Docker: each emulated network device is a container. Several container images are available out of the box:

• Base — DNS, web server, network utilities.
• Quagga — standard routing protocols.
• FRRouting — standard routing protocols plus EVPN and MPLS.
• Open vSwitch — OpenFlow-enabled switch.
• Behavioral Model — software implementation of a P4 switch (BMv2).

Each device has a console (a terminal window), a memory, a filesystem and zero, one or more network interfaces. Each interface is connected to a single virtual collision domain, and each virtual collision domain can be connected to several interfaces — so a domain is exactly the shared segment of chapter 4, but created and destroyed by Kathará instead of by hand.

3. Commands, labs and startup files

Kathará provides three sets of commands:

A Kathará lab is a set of preconfigured devices that can be started and halted together. A basic lab is a directory tree containing:

• a lab.conf file describing the network topology;
• a set of subdirectories with the configuration settings of each device;
• <device_name>.startup files describing actions performed when a device starts.

lab.conf contains a list of machine[arg]=value lines: if arg is a number, value is the name of the collision domain to which etharg is attached; if arg is not a number, it is an option and value its argument.

Files can be shared between host and devices in two ways. Mirrored sharing reflects changes in both directions: the /shared directory inside a device points to the lab's shared directory (enabled by default), and /hosthome points to the host's home directory (disabled by default). Copied sharing creates two independent copies, through the device subdirectories. The typical workflow is simple: enter the lab directory, then kathara lstart, kathara lclean, kathara lrestart.

4. Lab 1 — the Modbus secure tunnel testbed

The two industrial labs take the two halves of the course and aim them at one problem. Lab 1 (lab1_P4_modbus.zip) focuses on data-plane programmability: Modbus packet processing inside a P4 switch, using P4 to inspect industrial traffic at packet level and building the foundation for secure conduits with symmetric encryption. Lab 2 (lab2_P4_AAS.7z) focuses on control-plane programmability: using the Asset Administration Shell to expose network elements as assets, treating both data plane and control plane as manageable entities.

The Lab 1 testbed is a Kathará lab: a modbus client and a modbus server (simulating a working machine and a plant controller that collects its data), two P4 switches s1 and s2 running BMv2 between them, plus a wireshark node attached to domains A, B and C with port 3000/tcp published to the host. The switches carry the same pipeline; the secure conduit is realized by the two switches together, exactly as in chapter 10 — the devices are unchanged and speak plain Modbus.

5. Parsing Modbus with P4

The P4 parsing pipeline handles the variable length of the Modbus payload in five steps:

1. The parser extracts the Ethernet and IP headers from each packet.
2. If the Protocol field of the IPv4 header is 6 (TCP), the TCP header is extracted.
3. Knowing the IPv4 Total Length and the TCP Data Offset, the parser computes the actual TCP header length (including options) and the total payload size.
4. If source and destination ports are equal to 502, the Modbus Application (MBAP) header is parsed.
5. Finally, the Modbus payload is extracted depending on the value of the Length field in the MBAP header.

6. P4 externs: AES and HMAC in the data plane

Section 4.3 of the P4 language specification introduces the extern: P4 syntax used to define interfaces between P4 programs and architecture-specific functionality that resides outside those programs. Two varieties exist: extern functions (interface described as a function declaration) and extern objects (interface described as an object providing method declarations, like a C++ class).

The extern interface is declared in P4 and implemented in C++: declaration.p4 defines the extern functions visible to the P4 program; definition.cpp contains the actual implementation; the C++ code is compiled as a shared object library (.so); and the shared library is loaded by BMv2 at switch startup and dynamically linked to the compiled P4 program.

From declaration.p4 the program can invoke four functions:

AES is a symmetric block cipher operating on 128-bit blocks with 128/192/256-bit keys. Each round applies four steps: SubBytes (replace each byte using a lookup table), ShiftRows (move bytes around in the rows), MixColumns (Galois multiplication on the columns), AddRoundKey (XOR with the round key). HMAC (Hash-Based Message Authentication Code) ensures integrity and authenticity using a hash function and a secret key, returning a fixed-size digest. Together, the four externs let the switch build a protected conduit for industrial traffic.

7. Ingress processing and the modbus_sec table

In ingress, the pipeline is deliberately ordered: ipv4_lpm decides basic forwarding first, and modbus_sec is applied only for recognized industrial traffic. The security table matches on standard_metadata.egress_spec — the output port chosen by forwarding — and offers three actions:

• no_cipher — default, traffic passes untouched;
• cipher — encrypt with AES and tag with HMAC;
• decipher — verify the tag and decrypt.

The interpretation is worth stating slowly: forwarding is decided first; security treatment is decided after the egress direction is known. The secure conduit is enforced through table-driven switch behaviour — the same philosophy as chapter 10's in-network encryption, now with an explicit table you can inspect and modify.

table modbus_sec {
    key = {
        standard_metadata.egress_spec: exact;
    }
    actions = {
        no_cipher;
        cipher;
        decipher;
    }
    size = 2;
    default_action = no_cipher();
}

apply {
    if (hdr.ipv4.isValid()) {
        ipv4_lpm.apply();

        if (hdr.tcp.isValid() && hdr.modbus_tcp.isValid()) {
            modbus_sec.apply();
        }
    }
}

The exercise: from egress port to destination address

The lab then asks the question that turns the toy table into a policy: the secure conduit is specified per output port, but a real requirement is per destination. The exercise: make the secure conduit apply only to a specific IP address. Start from the table above, add a second Modbus server with a different IP to the lab, change the client script to connect to it — and remember to update the P4 rules. The solution changes the match key from egress_spec to hdr.ipv4.dstAddr, grows size to 16, and the CLI rules become address-based:

# s1 or s2 — cipher towards the protected servers
table_add modbus_sec cipher 200.1.1.7 =>
table_add modbus_sec cipher 200.1.1.8 =>
table_add modbus_sec cipher 200.1.1.9 =>

# and decipher towards the clients
table_add modbus_sec decipher 195.11.14.5 =>
table_add modbus_sec decipher 195.11.14.6 =>
table_add modbus_sec decipher 195.11.14.7 =>

8. Installing rules: CLI, registers and Wireshark

How are the P4 rules installed? The initial configuration happens at switch startup: s1.startup and s2.startup wait for simple_switch_CLI and then load auto_test_commands.txt. That file installs:

• ipv4_lpm forwarding rules;
• register_write key value commands — the key words written into keys[0..7];
• modbus_sec rules: decipher on port 1, cipher on port 2.

# both s1.startup and s2.startup do, after BMv2 is up:
simple_switch_CLI <<< $(cat auto_test_commands.txt)

# auto_test_commands.txt installs:
#   ipv4_lpm entries
#   register_write keys 0..7 <key words>
#   table_add modbus_sec decipher 1 =>
#   table_add modbus_sec cipher 2 =>

The keys live in registers on the data plane — the same in-memory state chapter 7 introduced — and the externs read them at cipher/decipher time. The client side is a Python script inside the modbusclient node: python3 modbus_client.py --read, --write, --rw, --test-rtt-read 128, --test-rtt-write 256, --test-read no-encryption. The Wireshark node uses the image lscr.io/linuxserver/wireshark, is attached to domains A, B and C, publishes port 3000/tcp to the host, and is reached at http://localhost:3000 after kathara lstart — that is how you verify the payload is ciphertext between the switches and plaintext at the ends.

9. Lab 2 — from programmable packets to programmable assets

Lab 1 focused on packet treatment inside the switch: parsing protocol fields, applying packet-level security treatment, programming the data plane. Lab 2 changes perspective: the network is no longer only a forwarding system — network components become explicitly modelled entities, and control and data plane can be treated as assets. The course states the transition in one line: in the first lab we programmed packet behaviour; in the second lab we program a network that can describe and expose itself.

This is exactly the Asset Administration Shell of chapter 10 applied to the network: the AAS is the standardized digital twin of an asset; it provides a structured digital representation, defines software structure, interfaces and semantics, and describes different aspects through submodels. Submodels are the content of the AAS — each represents one aspect, functional, structural or content-related — so an asset becomes a composition of meaningful views. The reason matters here is stated bluntly in the lab: we do not want a monolithic "network object"; we want separate views for infrastructure, control, and managed behaviour.

What is already implemented

The provided Java project (built with Gradle) already creates the shell and two controllers:

• App.java creates a Network Control Plane AAS;
• NetworkControlPlane.java creates two controller submodels — Controller(1) and Controller(2);
• Controller.java currently exposes GetSwitchRules, DeleteSwitchRules and RefreshRules, plus CreateRules_CNTx submodels populated from getRuleDescribers(...);
• the switch configuration lives in App/app/src/main/resources/net-config.yml: top-level keys identify the switches (s1, s2), under each switch a list of program definitions, each program starting with a program: field and containing a rules: section, each rule specifying the target table, match key values, action and action parameters.

The exercise: extend the Control Plane AAS with program management

The current AAS already allows users to inspect, add, delete and refresh switch rules. The exercise asks to extend the Java code so that each controller asset also exposes:

1. GetCurrentProgram — the currently active program is shown in the AAS;
2. GetAvailablePrograms — the list of installable programs is shown;
3. ChangeProgram — the user activates a selected program from the AAS UI;

with the expected behaviour that after the change, the rule-describer submodel is refreshed — the AAS stays a truthful view of the control plane. Build with gradle build in the App folder after every source change.

10. The nine final project challenges

The final project for this course is a set of nine challenges built on one shared environment: an industrial network composed of 2 hosts with 2 switches plus the Asset Administration Shell management infrastructure. The two hosts are a working machine (client) and a plant controller (server) that collects data of the working machines; they communicate using the Modbus protocol. Every challenge is phrased the same way — implement a P4 behaviour, then implement a new AAS submodel that exposes it — which is chapter 10's note made literal: the submodel is the unit of work in the project.

Check your understanding