@@ -1042,3 +1042,74 @@ vi) Angenommen, der Lehrstuhl verlangt hohe Gebühren für den Transit Ihrer Nac
vii) Konfigurieren Sie nun Router4 anstatt Router1 als BGP-Router Ihres AS, wobei die externen AS weiterhin an Router1 angeschlossen bleiben. Erläutern Sie anhand Ihrer Beobachtungen, inwiefern sich die beiden Szenarien unterscheiden. Theorie: Nennen Sie mindestens 2 Gründe, die für ein solches Szenario sprechen würden.
vii) Konfigurieren Sie nun Router4 anstatt Router1 als BGP-Router Ihres AS, wobei die externen AS weiterhin an Router1 angeschlossen bleiben. Erläutern Sie anhand Ihrer Beobachtungen, inwiefern sich die beiden Szenarien unterscheiden. Theorie: Nennen Sie mindestens 2 Gründe, die für ein solches Szenario sprechen würden.
3.**Total number of fragments** Each fragment can carry Sdata_per_fragmentS_{\text{data\_per\_fragment}} bytes of data. The total number of fragments required is:
This chapter introduces Software-defined Networks (SDN) as a new networking approach in contrast to traditional networks. In order to understand the principles of SDN, the layer views of network functionality in traditional networks and in SDN are juxtaposed, the SDN architecture is then presented. The concepts of flow commonly used in the SDN literature is analysed in this text. A deployment example with P4-based SDN is followed. The exercise illustrates how to employ SDN to “program” a network, revealing a new way of performing network control and management.
There are different ways to layer networked systems. Two well-known ones are the ISO OSI (Open Systems Interconnection) and the TCP/IP reference models. Figure 4.1 shows an example of a switch and a router through the OSI view. The switch spans two OSI layers, namely Physical and Data Link whereas the router implements an additional Network layer. A network device is classified into its highest layer, which means that the switch belongs to the Data Link layer and the router to the Network layer. The OSI layering mechanism provides a common basis for the coordination of networking standards’ development as well as facilitates the understanding of these standards and the interaction of networked systems.
In another view, a traditional network device can be seen as being composed of the three planes (or layers) depicted in Figure 4.2: management plane, control plane, and data plane.
- The data plane consists of various ports for receiving and transmitting packets based on its forwarding table, and switching fabrics for transferring packets from an input buffer to an output buffer.
- The control plane represents protocols used for populating forwarding tables in the data plane, e.g., the routing protocols like RIP, OSPF, BGP in a router.
控制平面表示用于填充数据平面中转发表的协议，例如路由协议，如RIP、OSPF、BGP。
- The management plane includes software services used by a network administrator (manager) to monitor and configure the control functionalities.
管理平面包括网络管理员（管理者）用于监控和配置控制功能的软件服务。
Figure 4.3 describes the roles of these planes and their interactions.
Although traditional IP networks have widespread adoption, they are complex and hard to manage. To make any change to a network, operators need to configure each individual network device separately using low-level and vendor-specific commands. The vertical integration of the control and data plane in each network device reduces the flexibility and hinders the innovation and evolution of networking infrastructure. These limitations pose a question of new networking paradigms, leading to the introduction of Software-Defined Networking (SDN).
Some key ideas of SDN are the introduction of dynamic programmability in forwarding devices, the decoupling of the control and data planes, and the global view of the network by logical centralization of the “network brain” [KRV+ 15] in a single place, namely the controller.
Having explained the three-plane view of traditional networks, we will now go deeper into the SDN architecture.
在解释了传统网络的三平面视图之后，我们现在将深入探讨SDN架构。
SDN is a network architecture where network control is decoupled from forwarding and is directly programmable [Foun 12].
SDN是一种网络架构，其网络控制与转发解耦并直接可编程 [Foun 12]。
A comparison of a traditional network and an SDN in the three-plane view is illustrated in Figure 4.4. In the traditional network, the routing table at the data plane of a router is populated by its control plane residing in the same device, such as the OSPF routing protocol running on the router’s operating system in this example. In SDN, the controller acts as a "network operating system," and the OSPF routing protocol runs atop the controller, which instructs the controller to populate flow tables in the SDN devices via the southbound API. The mapping of the management plane’s services in these two networks is not relevant in terms of network control and is not portrayed in this example to avoid unnecessary confusion.
Kreutz et al. [KRV+ 15] define SDN as a network architecture with four pillars:Kreutz等人 [KRV+ 15] 将SDN定义为一种具有以下四个支柱的网络架构：
1. The control and data planes are decoupled. Control functionality is removed from network devices that will become simple (packet) forwarding elements.
控制平面和数据平面解耦。控制功能从网络设备中移除，使这些设备变成简单的（数据包）转发元素。
2. Forwarding decisions are flow-based, instead of destination-based (refer to Section 4.3 for the explanation of the flow concept).
转发决策基于流而不是基于目的地（详见第4.3节对流的概念的解释）。
3. Control logic is moved to an external entity, the so-called SDN controller.
控制逻辑迁移到一个外部实体，即所谓的SDN控制器。
4. The network is programmable through software applications running on top of the controller that interacts with underlying data plane devices.
通过运行在控制器之上的软件应用程序对网络进行编程，这些应用程序与底层数据平面设备交互。
Another important characteristic of SDN mentioned in [RFC 7426] is the standardization of the interfaces between the control and data planes.
[RFC 7426] 中提到的SDN的另一个重要特性是控制平面和数据平面之间接口的标准化。
### 4.2.1 Components
The main components of a SDN include devices in the data plane and one or more controllers.
SDN的主要组件包括数据平面的设备和一个或多个控制器。
#### SDN-devices
SDN devices, also commonly referred to as SDN switches, are simple forwarding elements without embedded control or software to take autonomous decisions like routing protocols or default/fixed forwarding behavior. The network intelligence is removed from them to a logically centralized controller. Packets are handled in these switches based on their flow tables, whose entries contain control information of different layers (e.g., layer 2 - 4). Standardized interfaces are introduced between the controller and the switches, which provide a means for the controller to install flow tables in these switches.
The controller is a software stack that controls SDN devices. One important function of the controller is the provision of topology service, which maintains a consistent overview of the network. Any change in the network, such as new devices being added or some devices being removed, or some links being down, should be reflected immediately in the network overview at the controller. The controller changes the configuration of network devices based on applications’ requests.
According to Goransson et al. [GoBl 14], four fundamental functions of an SDN controller are:
根据Goransson等人 [GoBl 14] 的说法，SDN控制器的四个基本功能是：
- **End-user device discovery**,
**终端用户设备发现**，
- **Network device discovery**,
**网络设备发现**，
- **Network device topology management**, which maintains information about the interconnection details of the network devices to each other and to the end-user devices to which they are directly attached,
**网络设备拓扑管理**，维护网络设备彼此之间以及与直接连接的终端用户设备之间的互联细节信息，
- **Flow management**, which maintains a database of the flows being managed by the controller and performs all necessary coordination with the devices to ensure synchronization of the device flow entries with that database.
Further functions of the network are realized by SDN applications (see Section 4.2.3).
网络的进一步功能由SDN应用程序实现（见第4.2.3节）。
### 4.2.2 Interfaces
The SDN architecture introduces two interfaces: the northbound APIs lying between the applications and the controller, and the southbound APIs between the controller and the SDN devices. While OpenFlow [MAB+ 08] and P4Runtime [P4RTSpec] appear to be the most dominant southbound APIs, there are no such counterparts for northbound APIs so far. Each controller has its own northbound APIs.
The control functions of the network (e.g., MAC learning of switches, routing, enforcement of QoS, security...) are programmed in applications, which logically reside above the controller. Applications can change the configuration of switches via the controller’s northbound API.
Taking a simple routing application as an example [KRV+ 15]: the logic of this application is to define the path through which packets flow from a point A to a point B. To achieve this goal, the routing application must, based on the topology input, decide on the path to use and instruct the controller to install the respective forwarding rules in all devices on the chosen path from A to B.
Once the controller has finished initializing devices and reported the network topology to the application, the application spends most of its processing time responding to events. Application behavior is driven by events from the controller as well as external inputs. The application affects the network by responding to the events as modeled in Figure 4.6.
The SDN application registers as a listener for certain events, and the controller invokes the application’s callback method whenever such an event occurs. Some examples of events handled by an SDN application are:
In the first two cases, events are sent to the SDN application when a new end-user device (e.g., a MAC address) or a new network device (e.g., a switch, router, or wireless access point) is discovered. Incoming packet events are sent to the SDN application when a packet is received from an SDN device either due to a flow entry instructing the device to forward the packet to the controller or because no matching flow entry exists in the SDN device.
When there is no matching flow entry, the default action is usually to forward the packet to the controller. However, depending on the nature of the application, the packet may instead be dropped [GoBl 14].
In SDN, forwarding decisions are flow-based, instead of destination-based as in traditional networks. There is often confusion between the two concepts of path and flow, which need to be clearly distinguished and used correctly.
A **path** is the sequence of communication links and devices connecting two endpoints. It is also known as a route and is the foundation of IP routing. The concept of path is topology-oriented, meaning it focuses only on the way through the network, without considering the type of traffic or its content (payload).
A **flow**, or data stream, is a sequence of packets that share the same attributes. These attributes include fields in the protocol header, such as IP address, MAC address, status bit, etc.; they can also include the ingress port of a packet arriving at a network device. Thus, the concept of flow encompasses traffic types and possibly traffic content (payload). Flows are unidirectional and are determined by:
- In a traditional network, data streams destined for the same destination are typically routed along the same path because the routing mechanism is destination-based.
在传统网络中，发送到同一目的地的数据流通常沿同一路径路由，因为路由机制是基于目的地的。
- In SDN, these data streams are routed based on their flows’ attributes, which means they may traverse different paths from the source to the destination.
It is important to note that a flow can be reflected differently in each device along the path. For instance, one network device might handle the flow based on the first attribute (e.g., destination IP address), while another might base its handling on the second attribute (e.g., destination TCP port number).
An SDN device stores information about flows in tables, referred to as flow tables or rule tables. Each table entry contains:
SDN设备将流的信息存储在表中，称为流表或规则表。每个表条目包含：
- **Match fields**, which define the flow based on protocol fields (e.g., IP, MAC, port, VLAN, etc.). **匹配字段**，基于协议字段（例如IP、MAC、端口、VLAN等）定义流。
- **Actions**, which are executed when the match fields are satisfied. **操作**，当匹配字段满足时执行相应的操作。
A match field can be wildcarded to match any value, thereby reducing the number of table entries.
匹配字段可以使用通配符匹配任意值，从而减少表条目的数量。
The actions applied to a matched flow can include:
匹配流所应用的操作可能包括：
- Sending the packets of that flow to a specific port (interface of the SDN device). 将该流的数据包发送到指定端口（SDN设备的接口）。
- Dropping the packets. 丢弃数据包。
- Forwarding the packets to the controller. 将数据包转发到控制器。
- Sending packets to some or all ports (flooding, broadcast, multicast). 将数据包发送到部分或所有端口（泛洪、广播、多播）。
- Modifying the packets. 修改数据包。
- A combination of the above actions. 以上操作的某种组合。
**Priority** 优先级
Table entries are organized in rows, each with a specified priority. More specific entries should have higher priority than general ones (which have more masked fields).
OpenFlow assumes that SDN devices have fixed behavior. It supports populating the rule tables in these devices but is constrained by their fixed capabilities. OpenFlow cannot be used to deploy a rule that influences a new packet header not yet available in these fixed-function devices.
P4 was introduced to address this limitation by providing a mechanism to program devices' behavior. P4Runtime enables communication between SDN controllers and P4 devices.P4的引入旨在解决这一问题，它提供了一种编程设备行为的机制。P4Runtime实现了SDN控制器与P4设备之间的通信。
### 4.4.1 P4
P4 is a language for programming the data plane of network devices. The name P4 comes from the original paper that introduced the language: *“Programming Protocol-independent Packet Processors”* [BDG+ 14]. The version of P4 introduced in 2014 is named P414, and the language was revised in 2016 to P416, which is used in this assignment.
- Processing control packets (e.g., routing protocol packets), 处理控制数据包（例如路由协议数据包），
- Handling asynchronous events (e.g., link state changes or learning notifications). 处理异步事件（例如链路状态变化或学习通知）。
A P4-programmable switch differs from a traditional switch in two essential ways:
P4可编程交换机与传统交换机有两个主要区别：
1.**Data plane functionality is not predefined**: The functionality is defined by a P4 program. The data plane is configured at initialization to implement the behavior described by the P4 program and has no built-in knowledge of existing network protocols.
2.**Dynamic communication with the control plane**: The control plane communicates with the data plane using the same channels as in fixed-function devices, but the tables and objects in the data plane are not fixed. Instead, they are defined by a P4 program. The P4 compiler generates the API used by the control plane to interact with the data plane.
**Figure 4.8** shows a typical tool workflow for programming a target using P4. A *target* is defined as a packet-processing system capable of executing a P4 program. The term *target* is used interchangeably with *device* in most P4 specifications and in this manuscript.
Target manufacturers provide the hardware or software implementation framework, an architecture definition, and a P4 compiler for the target. P4 programmers write programs specific to a target architecture, which defines a set of P4-programmable components and their external data plane interfaces.
Compiling a set of P4 programs produces two artifacts:
编译一组P4程序会生成两个成果：
1. A **data plane configuration** implementing the forwarding logic described in the program.
**数据平面配置**，用于实现输入程序中描述的转发逻辑。
2. An **API** for managing the state of the data plane objects from the control plane.
**API**，用于从控制平面管理数据平面对象的状态。
#### Architecture Model
The P4 architecture identifies the P4-programmable blocks (e.g., parser, ingress control flow, egress control flow, deparser, etc.) and their data plane interfaces.
P4架构定义了P4可编程模块（例如解析器、入口控制流、出口控制流、反解析器等）及其数据平面接口。
The P4 architecture can be thought of as a contract between the program and the target. Each manufacturer must provide both a P4 compiler and an accompanying architecture definition for their target.
**Figure 4.9** illustrates the data plane interfaces between P4-programmable blocks. It depicts a target with two programmable blocks (#1 and #2), each of which is programmed through a separate fragment of P4 code. The target interfaces with the P4 program via a set of control registers or signals:
- **Input controls** provide information to P4 programs (e.g., the input port a packet was received from). **输入控制** 为P4程序提供信息（例如，接收到数据包的输入端口）。
- **Output controls** can be written to by P4 programs to influence the target’s behavior (e.g., the output port where a packet should be directed). **输出控制** 可由P4程序写入以影响目标设备的行为（例如，数据包应被引导到的输出端口）。
Control registers/signals are represented in P4 as **intrinsic metadata**, while P4 programs can also define and manipulate **user-defined metadata** to store data related to each packet.
There are various architectures, such as **V1Model**, **SimpleSumeSwitch**, and the **Portable Switch Architecture (PSA)** [PSADraft]. In this assignment, we use the **V1Model** on the BMv2 (Behavioral Model version 2) Simple Switch target because of its ease of deployment as a software switch.
**Figure 4.10** illustrates the programmable blocks of the V1Model architecture. The **standard metadata** in V1Model includes:
```c++
struct standard_metadata_t {
bit<9> ingress_port;
bit<9> egress_spec;
bit<9> egress_port;
bit<32> clone_spec;
bit<32> instance_type;
bit<1> drop;
bit<16> recirculate_port;
bit<32> packet_length;
bit<32> enq_timestamp;
bit<19> enq_qdepth;
bit<32> deq_timedelta;
bit<19> deq_qdepth;
bit<48> ingress_global_timestamp;
bit<32> lf_field_list;
bit<16> mcast_grp;
bit<1> resubmit_flag;
bit<16> egress_rid;
bit<1> checksum_error;
bit<3> priority;
}
```
The **ingress_port** is the port on which a packet arrived. The **egress_spec** specifies the port to which the packet should be sent. The **egress_port** denotes the port from which the packet is departing and is read-only in the egress pipeline.
The file `v1model.p4` is extensively commented, providing details on these and other fields of the standard metadata.
文件 `v1model.p4` 中有详细的注释，提供了关于这些字段及其他标准元数据字段的详细信息。
The **P416 program template** for the V1Model architecture includes:
**P416程序模板** 适用于V1Model架构，包含以下部分：
- **头部规范 (HEADER specification)**
- **解析器 (PARSER)**
- **校验和验证 (CHECKSUM VERIFICATION)**
- **入口处理 (INGRESS PROCESSING)**
- **出口处理 (EGRESS PROCESSING)**
- **校验和更新 (CHECKSUM UPDATE)**
- **反解析器块 (DEPARSER blocks)**
- **V1Switch包**
```c++
#include <core.p4>
#include <v1model.p4>
/* 头部定义 */
struct metadata { ... }
struct headers {
ethernet_t ethernet;
ipv4_t ipv4;
}
/* 解析器 */
parser MyParser(packet_in packet,
out headers hdr,
inout metadata meta,
inout standard_metadata_t smeta) {
...
}
/* 校验和验证 */
control MyVerifyChecksum(in headers hdr,
inout metadata meta) {
...
}
/* 入口处理 */
control MyIngress(inout headers hdr,
inout metadata meta,
inout standard_metadata_t std_meta) {
...
}
/* 出口处理 */
control MyEgress(inout headers hdr,
inout metadata meta,
inout standard_metadata_t std_meta) {
...
}
/* 反解析器 */
control MyDeparser(packet_out packet,
in headers hdr) {
...
}
control MyEgress(inout headers hdr,
inout metadata meta,
inout standard_metadata_t std_meta) {
...
}
/* CHECKSUM UPDATE */
control MyComputeChecksum(inout headers hdr,
inout metadata meta) {
...
}
/* DEPARSER */
control MyDeparser(inout headers hdr,
inout metadata meta) {
...
}
/* SWITCH */
V1Switch(
MyParser(),
MyVerifyChecksum(),
MyIngress(),
MyEgress(),
MyComputeChecksum(),
MyDeparser()
) main;
```
P4_{16} defines various data types, such as `bit`, `bool`, `int`, `string`, `struct`, `enum`, and `header_union`. These data types are described in its specification [P4Spec] (see Section 7 of the specification).
Another useful reference is the [**P4 Language Cheat Sheet**](https://github.com/p4lang/tutorials/blob/master/p4-cheat-sheet.pdf), which outlines the basic building blocks of P4.
另一个有用的参考资料是 **[P4语言速查表](https://github.com/p4lang/tutorials/blob/master/p4-cheat-sheet.pdf) (P4 Language Cheat Sheet)**，其中概述了P4的基本构建模块。
An example of compiling a P4 source file into a **P4 Device Config** file, which can be executed in BMv2 switches, is provided in a later section.
The **P4Runtime API** [P4RTSpec] is a control plane specification for managing the data plane elements of a device defined or described by a P4 program.
**Figure 4.11** illustrates the P4Runtime reference architecture. The device or target to be controlled is at the bottom, while one or more controllers are shown at the top. P4Runtime grants **write access** to only a single **primary controller** for each read/write entity.
The P4Runtime API defines the messages and semantics of the interface between the client(s) and the server. The API is specified in the `p4runtime.proto` [Protobuf file](https://github.com/p4lang/p4runtime).
P4Runtime API 定义了客户端和服务器之间接口的消息和语义。该API在 `p4runtime.proto` Protobuf文件中进行了规范化。
The controller can access P4 entities that are declared in the **P4Info metadata**.
控制器可以访问在 **P4Info元数据** 中声明的P4实体。
The **P4Info structure** is defined in the `p4info.proto` file, another Protobuf file included as part of the P4Runtime standard.
The **P4Runtime API** is implemented by a program running a gRPC server that binds to an auto-generated P4Runtime Service interface. This program is called the **P4Runtime server**. By default, the server must listen on **TCP port 9559**, allocated by IANA for the P4Runtime service. However, servers should allow users to override the default port using a configuration file or a startup flag.
In this assignment, we follow the **“idealized workflow”** described in the P4Runtime specification [P4RTSpec] (Section 3.2). This workflow includes:在本次作业中，我们遵循P4Runtime规范 [P4RTSpec] 中描述的 **“理想化工作流程”**（参见规范第3.2节）。该工作流程包括：
1. Compiling a P4 source program to produce: 将P4源程序编译为：
- A **P4 device config**. **P4设备配置**。
- **P4Info metadata**. **P4Info元数据**。
These together comprise the **ForwardingPipelineConfig** message.
这些共同组成 **ForwardingPipelineConfig** 消息。
2. The P4Runtime controller selects an appropriate configuration for a particular target and installs it via the **SetForwardingPipelineConfig RPC**.
**P4Runtime** supports the use of multiple controllers. A controller can either be embedded in a P4 target or operate separately. For P4-based SDN, the preferred approach is to deploy controllers separately from the targets, as shown in **Figure 4.12**.
A single **logically centralized controller** can control multiple targets simultaneously.
一个 **逻辑集中式控制器** 可以同时控制多个目标设备。
### 4.4.3 Test-bed
The provided infrastructure for this assignment includes an **“outer” virtual machine** (`gruppeX.rnp.lab.nm.ifi.lmu.de`), which hosts seven **“inner” virtual machines**. These inner machines include:
The connections between these machines are illustrated in **Figure 4.13**: 这些机器之间的连接如 **图4.13** 所示：
- **Dashed lines**: Represent the management network, used for accessing and configuring the inner machines. **虚线**：表示管理网络，用于访问和配置内部机器。
- **Solid lines**: Represent the data network, used for communication between the inner machines.
All `eth0` interfaces of the inner machines are connected to the same switch in the management network. **实线**：表示数据网络，用于内部机器之间的通信。所有内部机器的 `eth0` 接口都连接到管理网络的同一交换机。
The infrastructure is pre-configured with all the software necessary for this assignment. The **P4 compiler** is installed only on the controller (`router4`). As a result, P4 source files must be compiled on the controller to generate: 基础设施已预装完成该作业所需的所有软件。**P4编译器**仅安装在控制器（`router4`）上。因此，P4源文件必须在控制器上编译，以生成：
- **P4 Device Config**: Consumed by P4 switches. **P4设备配置文件**：供P4交换机使用。
- **P4Info files**: Consumed by controllers. **P4Info文件**：供控制器使用。
Instructions for installing P4-related software are provided in the **[P4 language tutorials](https://github.com/p4lang/tutorials)**, which include a sample deployment on [**Ubuntu 20.04**](https://github.com/p4lang/tutorials/blob/master/vm-ubuntu-20.04/root-release-bootstrap.sh). Additionally, the development team has facilitated P4 installation via the [**p4lang repository**](http://download.opensuse.org/repositories/home:/p4lang/) for package managers on **Debian 11** and **Ubuntu 22.04**. Installation can also be performed directly from the **[source code](https://github.com/p4lang/tutorials/blob/master/vm-ubuntu-20.04/user-dev-bootstrap.sh)**.
We demonstrate how to execute P4 switches and have them controlled by a controller using a simple **repeater application**. This example reuses material provided by the **[ETH Networked Systems Group](https://github.com/nsg-ethz/p4-learning/tree/master/exercises/02-Repeater/p4runtime)**.
As mentioned earlier, the P4 compiler is installed on the controller (`router4` in this case). To compile `repeater.p4` and generate the **P4 Device config** and **P4Info files**, execute the following commands:
The `simple_switch_grpc` command creates a [**SimpleSwitchGrpc target**,](https://github.com/p4lang/behavioral-model/blob/main/targets/simple_switch_grpc/README.md) which is a version of **SimpleSwitch** with P4Runtime support.
- `--nanolog ipc:///log.ipc`: Specifies the IPC socket for nanomsg pub/sub logs. `--nanolog ipc:///log.ipc`: 指定 nanomsg 发布/订阅日志的 IPC 套接字。
- `--device-id 1`: Sets the device ID for identifying the device in IPC messages. `--device-id 1`: 设置设备 ID，用于在 IPC 消息中标识设备。
- `--log-console`: Enables logging to stdout. `--log-console`: 启用标准输出的日志记录。
- `--thrift-port 9090`: Sets the TCP port for the Thrift runtime server. `--thrift-port 9090`: 设置 Thrift 运行时服务器的 TCP 端口。
- `--grpc-server-addr 0.0.0.0:50051`: Binds the gRPC server to the specified address. `--grpc-server-addr 0.0.0.0:50051`: 将 gRPC 服务器绑定到指定地址。
- `--cpu-port 255`: Specifies the logical port where a switch can communicate with a controller (packet-in/out). `--cpu-port 255`: 指定逻辑端口，交换机和控制器可以通过该端口通信（数据包输入/输出）。
For additional information, use the command: 如需更多信息，请使用命令：
```bash
simple_switch_grpc --help
```
At Switch S2
To create a P4 switch on `S2`, use similar commands: 在 `S2` 上创建 P4 交换机的命令类似：
The **[p4-utils library](https://github.com/p4lang/behavioral-model/blob/main/targets/simple_switch_grpc/README.md)** is used (with some modifications for packet-in, packet-out, and idle timeout support) to implement control applications. It acts as a wrapper for **[p4runtime-shell](https://github.com/p4lang/p4runtime-shell)**, simplifying controller plane development.
Useful API information (e.g., `table_add`, `table_delete_match`) is available on the linked [GitHub repository](https://nsg-ethz.github.io/p4-utils/p4utils.utils.sswitch_p4runtime_API.html).
The **repeater application** uses the network topology information encoded in `topo_repeater.json`. For other control applications, you need to provide the relevant topology information in a similar file.
After deploying the repeater application, you can test its functionality by generating traffic between `PC1` and `PC2`. 部署 repeater 应用程序后，可以通过在 `PC1` 和 `PC2` 之间生成流量来测试其功能。
1. Configure the `eth1` interface on **PC1**:
```bash
ssh root@pc1
ip addr add 192.168.1.1/24 broadcast 192.168.1.255 dev eth1
ip link set eth1 up
```
2. Configure the `eth1` interface on **PC2** and generate traffic using the `ping` command:
```bash
ssh root@pc2
ip addr add 192.168.1.2/24 broadcast 192.168.1.255 dev eth1
ip link set eth1 up
ping 192.168.1.1
```
If the PCs successfully communicate via `ping`, the deployment of the repeater application is confirmed.
#### Debugging the Data Plane Using `simple_switch_CLI`
The `simple_switch_CLI` command is useful for debugging the data plane. For example, while `S1` is running, open another terminal to observe or manipulate its rule tables: `simple_switch_CLI` 命令可用于调试数据平面。例如，当 `S1` 正在运行时，可以打开另一个终端窗口观察或操作其规则表：
1. Access **switch S1**:
```bash
ssh root@s1
simple_switch_CLI
```
2. Use commands to debug:
- Show existing tables:
```bash
show_tables
```
- Show contents of a specific rule table (e.g., `repeater` ):
```bash
table_dump repeater
```
- Add a rule to the `repeater` table:
```bash
table_add repeater forward 1 => 2
```
This adds a rule with `match key = 1` , `action = forward`, and `action parameter = 2 `.
More commands and details can be found in the [P4 language GitHub repository](https://github.com/p4lang/behavioral-model/blob/main/docs/runtime_CLI.md).
更多命令和详细信息可在 [P4 language GitHub 仓库](https://github.com/p4lang/behavioral-model/blob/main/docs/runtime_CLI.md) 中找到。
**English:**
### 4.4.5 Other P4 Sources and Control Applications for Reference
An advanced control application, **`arpcache.py`**, is provided on `router4` alongside the earlier example. Its corresponding P4 source file is **`packetinout.p4`**.
Additional useful examples are available in the **MNM-GitHub repository** [MNM-GitHub](https://github.com/mnm-team/p4-sdn.git). These examples should be practiced in the order specified on the repository’s main page (`README.md`) for a better understanding and smooth progression. Start with the **simple_demo application**, then proceed to **simple_switch**, and so on.
The network containing these servers is shown in **Figure 4.15**.
- The **E-learning Server** is underutilized since the service is in the testing phase.
- The **web server** experiences high loads, especially during university entrance exam result publications.
包含这些服务器的网络如 **图 4.15** 所示：
- 由于服务仍处于测试阶段，**E-learning 服务器** 的资源大部分时间处于空闲状态。
- 在大学发布入学考试结果时，**Web 服务器** 的负载意外地增加。
**Temporary solution:**
1. Deploy an additional instance of the AAO-Website on the **E-learning Server**.
2. Perform **load balancing** at the gateway to distribute traffic flows alternately between the two servers.
3. If the traffic volume reaches **80% of the link bandwidth**, drop the highest-load traffic flow.
The internal network of University A is **SDN-based**. Students, acting as network administrators, will program the network to achieve these requirements.
**临时解决方案：**
1. 在 **E-learning 服务器** 上部署 AAO 网站的额外实例。
2. 在网关执行 **负载均衡**，将流量交替转发到两个服务器。
3. 如果流量达到 **链路带宽的 80%**，丢弃负载最高的流量。
大学 A 的内部网络基于 **SDN**。学生将作为网络管理员，编程网络以实现这些需求。
#### 4.5.2 Demo
For demonstration purposes, the scenario is simplified, as shown in **Figure 4.16**:
- **PC1** represents the external party.
- **Switch S1** acts as the gateway.
- **Switches S2, S3** and **PC2, PC3** form the internal network.
1. If the traffic volume from **PC1 to PC2** is ≥ **512 Kbps**:
- Perform **load balancing** at the gateway. Traffic flows will alternately be delivered to **PC3** and **PC2**, as PC3 also provides the same service as PC2.
- The response traffic from **PC3 to PC1** must be modified at the gateway, changing its **source IP address** and **source MAC address** to those of **PC2**.
2.**Optional**: If the traffic volume from **PC1** to either **PC2** or **PC3** is ≥ **768 Kbps**, drop the traffic flow causing the highest load.
**Note:** The traffic mentioned refers only to the direction from **PC1 to PC2**. Traffic in the reverse direction (**PC2 to PC1**) or other directions can be ignored.
Submission of the **final source code** and the **manual**.
提交 **最终源代码** 和 **手册**。
- **21.01.2025 14:00**:
**Demo** presentation
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
