Compare commits
10 Commits
5085b3e2e8
...
main
| Author | SHA1 | Date | |
|---|---|---|---|
|
c0d67ceec0 | ||
|
|
c3202e229a | ||
|
|
958e0b9ef0 | ||
|
|
9962ec0738 | ||
|
|
67b40fe8af | ||
| bd47073bf4 | |||
|
|
29b6a69a70 | ||
|
|
2ba65bb11c | ||
|
|
000d0b90fb | ||
|
|
3ac91d6da8 |
@@ -73,61 +73,74 @@ IPv4的后继者IPv6同样重要,现在还没有像ipv4那么广泛
|
||||
#### Adressierung
|
||||
|
||||
Für die Adressierung in einem IPv4-Netz werden hierarchische 32-Bit Nummern verwendet.
|
||||
|
||||
对于在一个IPv4网络中,用一个32位的分层数字进行寻址
|
||||
|
||||
Das heißt IPv4-Adressen (kurz: IP-Adressen) **dienen** sowohl der **Identifizierung der Gegenstellen**, als auch der Strukturierung des Adressraums.
|
||||
|
||||
这意味着IPv4地址（简称IP地址）既用于标识**通信对端**，也用于组织地址空间的结构。
|
||||
|
||||
IP-Adressen setzen sich aus einer Netz-ID und einer Host-ID zusammen. IP-Adressen mit der selben Netz-ID gehören zum selben Subnetz.
|
||||
|
||||
IP地址由网络ID和主机ID组成。具有相同网络ID的IP地址属于同一子网.
|
||||
|
||||
Ursprünglich wurden IP-Adressen in Subnetzklassen fester Größe eingeteilt (vgl. Vorlesung RNVS), wodurch die Anzahl von IP-Adressen in einem Subnetz immer 256, 65536 oder 16777216 betrug.
|
||||
|
||||
最初，IP地址被划分为固定大小的子网类（参见RNVS课程），因此每个子网中的IP地址数量总是256、65536或16777216。”
|
||||
|
||||
In heutigen Implementierungen ist die Länge der Netz-ID variabel, um Subnetze unterschiedlicher Größe anlegen zu können.
|
||||
|
||||
在目前的实施中，网络 ID 的长度是可变的，这样就可以创建不同大小的子网。
|
||||
|
||||
|
||||
Dadurch kann bei der Vergabe von Adressblöcken die Anzahl der IP-Adressen besser an die tatsächlich benötigte Menge angepasst werden, wodurch weniger „Verschnitt” (ungenutzte IP-Adressen) entsteht.
|
||||
|
||||
Dieser Ansatz ist als Classless Inter-Domain Routing (CIDR) in [RFC 1519] spezifiziert.
|
||||
这意味着在分配地址块时，IP 地址的数量可以更好地适应实际需要，从而减少 “浪费”（未使用的 IP 地址）。
|
||||
|
||||
Dieser Ansatz ist als Classless Inter-Domain Routing (CIDR) in \[RFC 1519\] spezifiziert.
|
||||
|
||||
该方法在\[RFC 1519\]中指定为无类别间路由（CIDR）。
|
||||
|
||||
In jedem Subnetz sind zwei Adressen reserviert: die Netzadresse und die Broadcast-Adresse.
|
||||
|
||||
Die Netzadresse ist die IP-Adresse, bei der alle Bits der Host-ID 0 sind. Die Netzadresse ist die Adresse mit dem numerisch kleinsten Wert im Subnetz.
|
||||
|
||||
Im Gegensatz dazu sind die Bits der Host-ID in der Broadcast-Adresse alle 1.
|
||||
|
||||
Somit ist die Broadcast-Adresse die IP-Adresse mit dem numerisch höchsten Wert im Subnetz.
|
||||
|
||||
每个子网保留两个地址：网络地址和广播地址。
|
||||
|
||||
|
||||
In jedem Subnetz sind zwei Adressen reserviert: die Netzadresse und die Broadcast- Adresse. Die Netzadresse ist die IP-Adresse, bei der alle Bits der Host-ID 0 sind. Die Netzadresse ist die Adresse mit dem numerisch kleinsten Wert im Subnetz. Im Gegensatz dazu sind die Bits der Host-ID in der Broadcast-Adresse alle 1. Somit ist die Broadcast- Adresse die IP-Adresse mit dem numerisch höchsten Wert im Subnetz.
|
||||
在每个子网中，有两个地址是保留的：网络地址和广播地址。网络地址是主机ID的所有位都为0的IP地址。网络地址是子网中数值最小的地址。与此相反，广播地址的主机ID的所有位都为1。因此，广播地址是子网中数值最大的IP地址。
|
||||
|
||||
Die Einträge einer Routing-Tabelle geben anhand von Zieladressen Routing-Entscheidungen vor. Aufgrund der hierarchischen Vergabe von IP-Adressen muss eine Routing-Tabelle nicht einen Eintrag pro IP-Adresse enthalten, sondern einen Eintrag pro Subnetz. So- mit benötigt der Router aus Abbildung 1.2 drei Einträge in seiner Routing-Tabelle, um Nachrichten an alle fünf dargestellten Rechner weiterleiten zu können:
|
||||
|
||||
路由表中的条目根据目标地址做出路由决策。由于IP地址是分层分配的，路由表不需要为每个IP地址包含一个条目，而是为每个子网包含一个条目。因此，图1.2中的路由器只需要在其路由表中有三个条目，就能将消息转发给所有显示的五台计算机。
|
||||
|
||||
Ein Eintrag besteht aus einem Ziel-Subnetz und der IP-Adresse der Komponente, die das Ziel erreichen kann (next-hop). Da der Router über eine direkte Verbindung in jedes der drei Subnetze verfügt, sind alle next-hop-Einträge auf der rechten Seite der Routing- Tabelle die eigenen IP-Adressen des Routers. Der Router kann in diesem Fall jedes Ziel *direkt*, d.h. ohne Zwischenschritte (engl. hops), erreichen.
|
||||
|
||||
一个条目由目标子网和可以到达该目标的组件的IP地址（下一跳，next-hop）组成。由于路由器直接连接到三个子网中的每一个，因此路由表右侧的所有下一跳条目都是路由器自身的IP地址。在这种情况下，路由器可以直接到达每个目标，也就是说，不需要中间步骤（英文：hops）。
|
||||
|
||||
Die Rechner in Abbildung 1.2 sind mit genau einem Subnetz direkt verbunden. Sendet einer davon eine Nachricht, muss der Router diese Nachricht zwischen Sender und Empfänger vermitteln. Sollen Nachrichten zwischen 10.0.0.3 und 10.0.1.3 ausgetauscht werden, so benötigen die Rechner (mindestens) Routing-Tabellen wie in Tabelle 1.1.
|
||||
|
||||
图1.2中的计算机每台都直接连接到一个子网。如果其中一台计算机发送消息，路由器必须在发送方和接收方之间进行消息的转发。如果要在10.0.0.3和10.0.1.3之间交换消息，那么这些计算机需要（至少）如表1.1中的路由表。
|
||||
|
||||
In manchen Situationen ist es nicht sinnvoll oder möglich für jedes erreichbare Subnetz einen eigenen Eintrag in der Routing-Tabelle anzulegen. Man kann z.B. auf dem Rechner zuhause kaum für jedes über das Internet erreichbare Subnetz einen Eintrag anlegen. Für diesen Fall legt man einen Standard-Eintrag in der Routing-Tabelle an, der genau dann ausgelesen wird, wenn kein anderer Eintrag für eine IP-Adresse gefunden werden kann. Dieser Eintrag wird häufig *default-Route* genannt und enthält als next-hop das *Standard-Gateway* (engl. default gateway). Umgekehrt ist es unter Umständen erwünscht Nachrichten an einen bestimmten Rechner über einen speziellen Pfad zu schicken. Solche Einträge in der Routing-Tabelle, die für genau einen Rechner gelten, heißen *Host-Routen*. Host-Routen können als Subnetz mit genau einer IP-Adresse gesehen werden, also als ein Subnetz mit 32 festen Bits (/32).
|
||||
|
||||
在某些情况下，为每个可访问的子网在路由表中创建单独的条目既不现实也不可能。例如，你很难在家用电脑上为每个可通过互联网访问的子网创建一个条目。在这种情况下，我们会在路由表中创建一个标准条目，当某 IP 地址找不到其他条目时，就会读出该条目。该条目通常被称为*默认路由*，包含作为下一跳的*默认网关*。相反，也可能需要通过特殊路径向特定计算机发送信息。路由表中的此类条目恰好适用于一台计算机，称为*主机路由*。主机路由可以看作是具有一个 IP 地址的子网，即具有 32 个固定位（/32）的子网。
|
||||
|
||||
|
||||
|
||||
#### Wegewahl
|
||||
|
||||
Bei der Einteilung von IP-Adressen in Subnetzklassen ist der Algorithmus zur Auswahl einer Route vergleichsweise einfach (vgl. Folien RNVS): die ersten (bis zu vier) Bits einer IP-Adresse bestimmen die Subnetzklasse und damit die Länge der Netz-ID. Die Netz-ID wird ausgelesen und der nächste Zwischenschritt (next hop) in der Routing-Tabelle nachgeschlagen.
|
||||
|
||||
在将IP地址划分为子网类时，路由选择算法相对简单（参见RNVS幻灯片）：IP地址的前（最多四个）比特确定子网类，从而确定网络ID的长度。网络ID被读取后，路由表中会查找下一跳（next hop）。
|
||||
|
||||
Mit der Einführung von CIDR ist der Entscheidungsprozess komplexer geworden. Die beiden wichtigsten Neuerungen diesbezüglich sind, dass Subnetze nicht mehr zu einer bestimmten Klasse gehören und die Länge der Netz-ID variabel ist. Die Folge dieser Veränderungen ist, dass die Länge der Netz-ID nicht mehr an der IP-Adresse selbst abgelesen werden kann, sondern durch die Einträge in der Routing-Tabelle gegeben werden muss. Anstatt einmal die Netz-ID auszulesen und einen passenden Eintrag dafür zu suchen muss nun die variable Länge berücksichtigt werden.
|
||||
|
||||
随着CIDR（无类域间路由）的引入，决策过程变得更加复杂。最重要的两个变化是，子网不再属于某个特定的类，并且网络ID的长度是可变的。这些变化的结果是，网络ID的长度不再能直接从IP地址中读取，而是需要通过路由表中的条目来指定。现在，不再是简单地读取网络ID并找到相应的条目，而是必须考虑到可变的长度。
|
||||
|
||||
#### Longest prefix match
|
||||
|
||||
Empfängt ein Router ein IP-Paket, das an die Ziel-IP-Adresse 10.0.0.3 adressiert ist, so liest der Router die Ziel-IP-Adresse aus und durchsucht die Routing-Tabelle nach dem präzisesten zutreffenden Eintrag.
|
||||
|
||||
最长前缀匹配（Longest prefix match）：当路由器接收到一个发送到目标IP地址为10.0.0.3的IP包时，路由器会读取目标IP地址，并在路由表中搜索最精确匹配的条目.这段话的翻译如下：
|
||||
|
||||
|
||||
@@ -145,7 +158,6 @@ Empfängt ein Router ein IP-Paket, das an die Ziel-IP-Adresse 10.0.0.3 adressier
|
||||
10.0.0.0/24 10.0.20.1
|
||||
|
||||
|
||||
|
||||
“两个条目都可以应用于目标IP地址10.0.0.3：IP地址10.0.0.3的前20位匹配第一个条目，同样的，前24位匹配第二个条目。在这种情况下，将选择更精确的条目，也就是具有更长网络ID的条目。这种策略称为‘最长前缀匹配’（Longest Prefix Match）。”
|
||||
|
||||
## 1.3 RNP 基础设施、Linux 和工具
|
||||
|
||||
BIN
Blatt01/PDFsam_merge.pdf
Normal file
BIN
Blatt01/PDFsam_merge.pdf
Normal file
Binary file not shown.
BIN
Blatt03/A300 (1).pdf
Normal file
BIN
Blatt03/A300 (1).pdf
Normal file
Binary file not shown.
@@ -0,0 +1,3 @@
|
||||
|
||||
|
||||
|
||||
@@ -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.
|
||||
现在将 router4 配置为您自治系统的 BGP 路由器，而外部自治系统仍然连接到 router1。根据您的观察，说明这两种场景有何不同。
|
||||
理论：列出至少两个支持这种场景的理由。
|
||||
|
||||
|
||||
|
||||
## Appendix
|
||||
|
||||
### Mathematical Explanation of the Fragmentation Process
|
||||
|
||||
#### Definitions of Symbols
|
||||
|
||||
- **StotalS_{\text{total}}**: Total size of the IP packet (in bytes), Stotal=9000S_{\text{total}} = 9000.
|
||||
- **SheaderS_{\text{header}}**: Size of the IP header (in bytes), Sheader=20S_{\text{header}} = 20.
|
||||
- **SMTUS_{\text{MTU}}**: Size of the MTU (in bytes), SMTU=1500S_{\text{MTU}} = 1500.
|
||||
- **Sdata_per_fragmentS_{\text{data\_per\_fragment}}**: Maximum data size per fragment (in bytes).
|
||||
- **NfragmentsN_{\text{fragments}}**: Total number of fragments.
|
||||
|
||||
#### Calculation Steps
|
||||
|
||||
1. **Maximum data size per fragment**
|
||||
|
||||
Sdata_per_fragment=SMTU−SheaderS_{\text{data\_per\_fragment}} = S_{\text{MTU}} - S_{\text{header}}
|
||||
|
||||
Substituting values:
|
||||
|
||||
Sdata_per_fragment=1500−20=1480 bytesS_{\text{data\_per\_fragment}} = 1500 - 20 = 1480 \text{ bytes}
|
||||
|
||||
2. **Total size of the data section**
|
||||
|
||||
Sdata_total=Stotal−SheaderS_{\text{data\_total}} = S_{\text{total}} - S_{\text{header}}
|
||||
|
||||
Substituting values:
|
||||
|
||||
Sdata_total=9000−20=8980 bytesS_{\text{data\_total}} = 9000 - 20 = 8980 \text{ bytes}
|
||||
|
||||
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:
|
||||
|
||||
Nfragments=⌈Sdata_totalSdata_per_fragment⌉N_{\text{fragments}} = \lceil \frac{S_{\text{data\_total}}}{S_{\text{data\_per\_fragment}}} \rceil
|
||||
|
||||
Substituting values:
|
||||
|
||||
Nfragments=⌈89801480⌉=⌈6.068⌉=7N_{\text{fragments}} = \lceil \frac{8980}{1480} \rceil = \lceil 6.068 \rceil = 7
|
||||
|
||||
4. **Data size of the last fragment** The total data size carried by the first Nfragments−1N_{\text{fragments}} - 1 fragments is:
|
||||
|
||||
Sdata_used=(Nfragments−1)⋅Sdata_per_fragmentS_{\text{data\_used}} = (N_{\text{fragments}} - 1) \cdot S_{\text{data\_per\_fragment}}
|
||||
|
||||
Substituting values:
|
||||
|
||||
Sdata_used=(7−1)⋅1480=8880 bytesS_{\text{data\_used}} = (7 - 1) \cdot 1480 = 8880 \text{ bytes}
|
||||
|
||||
The data size of the last fragment is:
|
||||
|
||||
Sdata_last=Sdata_total−Sdata_usedS_{\text{data\_last}} = S_{\text{data\_total}} - S_{\text{data\_used}}
|
||||
|
||||
Substituting values:
|
||||
|
||||
Sdata_last=8980−8880=100 bytesS_{\text{data\_last}} = 8980 - 8880 = 100 \text{ bytes}
|
||||
|
||||
5. **Validation of total size** The total size of all fragments, including the header, should equal the original IP packet size:
|
||||
|
||||
Stotal=Sdata_total+SheaderS_{\text{total}} = S_{\text{data\_total}} + S_{\text{header}}
|
||||
|
||||
Verification:
|
||||
|
||||
8980+20=9000 bytes8980 + 20 = 9000 \text{ bytes}
|
||||
|
||||
#### Summary
|
||||
|
||||
- Total number of fragments: Nfragments=7N_{\text{fragments}} = 7.
|
||||
- Data size per fragment:
|
||||
- The first Nfragments−1=6N_{\text{fragments}} - 1 = 6 fragments carry Sdata_per_fragment=1480S_{\text{data\_per\_fragment}} = 1480 bytes of data.
|
||||
- The last fragment carries Sdata_last=100S_{\text{data\_last}} = 100 bytes of data.
|
||||
858
Blatt04/Notes04.md
Normal file
858
Blatt04/Notes04.md
Normal file
@@ -0,0 +1,858 @@
|
||||
# 4 Software Defined Networks
|
||||
|
||||
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.
|
||||
本章介绍了软件定义网络（SDN）作为一种与传统网络形成对比的新型网络方法。
|
||||
为了理解SDN的原理，本文将传统网络和SDN的网络功能分层视图进行对比，并随后介绍了SDN的架构。
|
||||
本文还分析了SDN文献中常用的流的概念，并提供了一个基于P4的SDN部署示例。
|
||||
该练习展示了如何利用SDN来“编程”网络，揭示了一种新的网络控制和管理方式。
|
||||
|
||||
## 4.1 Introduction
|
||||
|
||||
|
||||
|
||||
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.
|
||||
网络系统的分层方式有多种。两个众所周知的模型是ISO OSI（开放系统互连）模型和TCP/IP参考模型。图4.1展示了通过OSI视图观察交换机和路由器的示例。交换机跨越了OSI的两层，即物理层和数据链路层，而路由器实现了额外的网络层。网络设备按照其最高层进行分类，这意味着交换机属于数据链路层，而路由器属于网络层。OSI分层机制为协调网络标准的开发提供了一个共同的基础，同时也促进了对这些标准的理解以及网络系统的交互。
|
||||
|
||||
|
||||
|
||||
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.
|
||||
从另一种视角来看，传统网络设备可以看作由图4.2所示的三个平面（或层）组成：管理平面、控制平面和数据平面。
|
||||
|
||||
- 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.
|
||||
图4.3描述了这些平面的角色及其交互关系。
|
||||
|
||||
|
||||
|
||||
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).
|
||||
|
||||
尽管传统的IP网络被广泛采用，但它们复杂且难以管理。要对网络进行任何更改，操作员需要使用底层且特定于供应商的命令单独配置每个网络设备。控制平面和数据平面在每个网络设备中的垂直集成降低了灵活性，并阻碍了网络基础设施的创新和发展。这些限制提出了关于新网络范式的问题，从而引入了软件定义网络（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.
|
||||
|
||||
SDN的一些关键理念包括在转发设备中引入动态可编程性、解耦控制平面和数据平面，以及通过逻辑集中化将“网络大脑”集中在单一位置（即控制器）以实现网络的全局视图 [KRV+ 15]。
|
||||
|
||||
## 4.2 Architecture
|
||||
|
||||
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.
|
||||
|
||||
图4.4展示了传统网络和SDN在三平面视图中的对比。在传统网络中，路由器的数据平面的路由表由其控制平面填充，控制平面位于同一设备中，例如运行在路由器操作系统上的OSPF路由协议。而在SDN中，控制器扮演“网络操作系统”的角色，OSPF路由协议运行在控制器之上，并通过南向API指示控制器填充SDN设备中的流表。在这一示例中，管理平面服务的映射与网络控制无关，因此未呈现，以避免不必要的混淆。
|
||||
|
||||
|
||||
|
||||
The general SDN architecture is illustrated in Figure 4.5.
|
||||
|
||||
图4.5展示了通用的SDN架构。
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
SDN设备，也常被称为SDN交换机，是简单的转发元素，没有嵌入的控制功能或用于做出自主决策的软件，如路由协议或默认/固定的转发行为。网络智能从这些设备中被移到逻辑集中化的控制器中。这些交换机根据其流表处理数据包，流表中的条目包含不同层（如第2层至第4层）的控制信息。在控制器和交换机之间引入了标准化接口，控制器可以通过这些接口向交换机安装流表。
|
||||
|
||||
#### Controller
|
||||
|
||||
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.
|
||||
|
||||
控制器是一个控制SDN设备的软件栈。控制器的一个重要功能是提供拓扑服务，它维护网络的一致概览。网络中的任何变化，例如新设备的添加、某些设备的移除或某些链路的中断，都应立即反映在控制器的网络概览中。控制器根据应用程序的请求更改网络设备的配置。
|
||||
|
||||
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.
|
||||
|
||||
SDN架构引入了两种接口：位于应用程序与控制器之间的北向API，以及控制器与SDN设备之间的南向API。尽管OpenFlow [MAB+ 08] 和P4Runtime [P4RTSpec] 是最为主流的南向API，但目前北向API尚无类似的标准化对等接口。每个控制器都有其独特的北向API。
|
||||
|
||||
### 4.2.3 SDN Applications
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
网络的控制功能（例如交换机的MAC学习、路由、QoS实施、安全性等）由应用程序编程实现，这些应用程序逻辑上位于控制器之上。应用程序可以通过控制器的北向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.
|
||||
|
||||
以一个简单的路由应用为例 [KRV+ 15]：该应用程序的逻辑是定义从A点到B点的数据包流经的路径。为了实现这一目标，路由应用程序需要根据拓扑输入确定要使用的路径，并指示控制器在所选路径上的所有设备中安装相应的转发规则，从A到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.
|
||||
|
||||
一旦控制器完成设备初始化并将网络拓扑报告给应用程序，应用程序的大部分处理时间将用于响应事件。应用程序的行为由来自控制器的事件以及外部输入驱动。通过响应事件，应用程序影响网络的行为，这在图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:
|
||||
SDN应用程序注册为某些事件的侦听器，控制器在这些事件发生时会调用应用程序的回调方法。SDN应用程序处理的事件包括：
|
||||
|
||||
- End-user device discovery,
|
||||
- Network device discovery,
|
||||
- Incoming packets.
|
||||
|
||||
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.
|
||||
|
||||
在前两种情况下，当发现新的终端用户设备（例如MAC地址）或新的网络设备（例如交换机、路由器或无线接入点）时，事件会发送到SDN应用程序。当从SDN设备接收到数据包时，也会发送数据包事件到SDN应用程序，这可能是由于流表条目指示SDN设备将数据包转发到控制器，或者因为SDN设备中没有匹配的流表条目。
|
||||
|
||||
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].
|
||||
|
||||
当没有匹配的流表条目时，默认操作通常是将数据包转发到控制器。然而，根据应用程序的性质，也可能选择丢弃数据包 [GoBl 14]。
|
||||
|
||||
## 4.3 Flows
|
||||
|
||||
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.
|
||||
|
||||
在SDN中，转发决策是基于流而非传统网络中的基于目的地。路径和流这两个概念经常被混淆，需要明确区分并正确使用。
|
||||
|
||||
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).
|
||||
|
||||
**路径** 是连接两个端点的通信链路和设备的序列。它也被称为路由，是IP路由的基础。路径的概念是拓扑导向的，这意味着它只关注通过网络的路径，而不关注流量的类型和内容（有效负载）。
|
||||
|
||||
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:
|
||||
**流** 或数据流，是一系列共享相同属性的数据包。这些属性包括协议头中的字段，例如IP地址、MAC地址、状态位等；也可以包括到达网络设备的数据包的入口端口。因此，流的概念包含流量类型，甚至可能包括流量内容（有效负载）。流是单向的，由以下三个方面决定：
|
||||
|
||||
- The path(路径),
|
||||
- The concerned attributes(相关属性),
|
||||
- The direction (which can be considered a special case of the attributes, like address)方向（可视为属性的特殊情况，例如地址）.
|
||||
|
||||
**Example:** Traffic between two endpoints A and B exchanging audio streams and HTTP traffic can be seen as four different flows:
|
||||
|
||||
1. A flow for audio traffic along the path from A to B,
|
||||
2. A flow for audio traffic along the path from B to A,
|
||||
3. A flow for HTTP traffic along the path from A to B,
|
||||
4. A flow for HTTP traffic along the path from B to A.
|
||||
|
||||
**示例：** 在两个端点A和B之间交换音频流和HTTP流量时，可以看作四个不同的流：
|
||||
|
||||
1. 从A到B的音频流量流，
|
||||
2. 从B到A的音频流量流，
|
||||
3. 从A到B的HTTP流量流，
|
||||
4. 从B到A的HTTP流量流。
|
||||
|
||||
**Figure 4.7** [Danc 15] illustrates how four data streams are routed in a traditional network (left picture) and in an SDN (right picture).
|
||||
|
||||
**图4.7** [Danc 15] 说明了四个数据流如何在传统网络（左图）和SDN（右图）中路由。
|
||||
|
||||
- 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.
|
||||
在SDN中，这些数据流是根据其流的属性路由的，因此它们可能沿不同路径从源到达目的地。
|
||||
|
||||
|
||||
|
||||
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).
|
||||
|
||||
需要注意的是，一个流在路径上的每个设备中可能有不同的表现。例如，一个网络设备可能基于流的第一个属性（例如目的地IP地址）处理流，而另一个设备可能基于第二个属性（例如目的地TCP端口号）处理流。
|
||||
|
||||
**Specification of Flow ** **流的规范**
|
||||
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).
|
||||
表条目按行组织，每行具有指定的优先级。更具体的条目应比更一般的条目（即具有更多掩码字段的条目）具有更高的优先级。
|
||||
|
||||
## 4.4 SDN Deployment Example with P4 and P4Runtime
|
||||
|
||||
The most common implementations of SDN include those based on OpenFlow [MAB+ 08] and P4 [BDG+ 14].
|
||||
SDN最常见的实现包括基于OpenFlow [MAB+ 08] 和P4 [BDG+ 14] 的实现。
|
||||
|
||||
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.
|
||||
OpenFlow假设SDN设备具有固定的行为。它支持在这些设备中填充规则表，但受其固定功能的限制。无法使用OpenFlow部署影响固定功能设备中尚未支持的新数据包头的规则。
|
||||
|
||||
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.
|
||||
P4是一种用于编程网络设备数据平面的语言。P4的名称来源于该语言的原创论文：*“Programming Protocol-independent Packet Processors”* [BDG+ 14]。2014年发布的P4版本被称为P414，该语言在2016年进行了修订，被称为P416，本次作业中使用的就是P416版本。
|
||||
|
||||
In a traditional switch, the manufacturer defines the data-plane functionality. The control plane manages the data plane by:
|
||||
在传统交换机中，数据平面的功能由制造商定义。控制平面通过以下方式管理数据平面：
|
||||
|
||||
- Managing entries in their rule tables (e.g., routing tables), 管理规则表（例如路由表）中的条目，
|
||||
- Configuring specialized objects (e.g., meters), 配置专用对象（例如计量器），
|
||||
- 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.
|
||||
**数据平面的功能不是预先定义的**：其功能由P4程序定义。数据平面在初始化时配置，以实现P4程序描述的行为，并且对现有网络协议没有内置知识。
|
||||
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.
|
||||
**与控制平面的动态通信**：控制平面通过与固定功能设备相同的通道与数据平面通信，但数据平面中的表和对象不再固定，而是由P4程序定义的。P4编译器生成控制平面与数据平面交互所使用的API。
|
||||
|
||||
|
||||
|
||||
**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.
|
||||
**图4.8** 展示了使用P4编程目标设备的典型工具工作流程。*目标设备* 被定义为能够执行P4程序的数据包处理系统。在大多数P4规范以及本手稿中，*目标设备* 与*设备*的术语可以互换使用。
|
||||
|
||||
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.
|
||||
目标设备的制造商提供硬件或软件实现框架、架构定义和针对目标设备的P4编译器。P4程序员为特定的架构编写程序，该架构定义了目标设备上可用的一组P4可编程组件及其外部数据平面接口。
|
||||
|
||||
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.
|
||||
|
||||
P4架构可以被视为程序与目标设备之间的契约。因此，每个制造商必须为其目标设备提供P4编译器及其配套的架构定义。
|
||||
|
||||
|
||||
|
||||
**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:
|
||||
**图4.9** 展示了P4可编程模块之间的数据平面接口。图中显示了一个包含两个可编程模块（#1和#2）的目标设备，每个模块通过一个独立的P4代码片段进行编程。目标设备通过一组控制寄存器或信号与P4程序交互：
|
||||
|
||||
- **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.
|
||||
|
||||
控制寄存器/信号在P4中表示为**内在元数据**，而P4程序还可以定义并操作**用户定义元数据**以存储与每个数据包相关的数据。
|
||||
|
||||
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.
|
||||
|
||||
存在多种架构，例如 [**V1Model**](https://github.com/p4lang/p4c/blob/main/p4include/v1model.p4)、[**SimpleSumeSwitch**](https://github.com/NetFPGA/P4-NetFPGA-public/wiki) 和 **可移植交换架构 (PSA)** [PSADraft]。在本次作业中，由于易于作为软件交换机部署，我们使用了 **BMv2（行为模型第2版）[Simple Switch](https://github.com/p4lang/behavioral-model/blob/main/docs/simple_switch.md)目标** 上的 **V1Model**。
|
||||
|
||||
#### V1Model
|
||||
|
||||
|
||||
|
||||
**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.
|
||||
**ingress_port** 是数据包到达的端口。**egress_spec** 指定数据包应被发送到的端口。**egress_port** 表示数据包离开的端口，在出口管道中是只读的。
|
||||
|
||||
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).
|
||||
|
||||
P416定义了多种数据类型，例如 `bit`、`bool`、`int`、`string`、`struct`、`enum` 和 `header_union`。这些数据类型在其规范 [P4Spec]（参见规范第7节）中有详细说明。
|
||||
|
||||
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.
|
||||
|
||||
有关将P4源文件编译为**P4设备配置 (P4 Device Config)** 文件，并在BMv2交换机中执行的示例，将在后续章节中提供。
|
||||
|
||||
### 4.4.2 P4Runtime
|
||||
|
||||
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.
|
||||
|
||||
**P4Runtime API** [P4RTSpec] 是一种控制平面规范，用于管理由P4程序定义或描述的设备数据平面元素。
|
||||
|
||||
|
||||
|
||||
**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.
|
||||
|
||||
**图4.11** 展示了P4Runtime参考架构。需要控制的设备或目标位于底部，而一个或多个控制器位于顶部。对于每个读/写实体，P4Runtime仅授予一个**主控制器**的**写访问权限**。
|
||||
|
||||
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.
|
||||
|
||||
**P4Info结构** 定义在 `p4info.proto` 文件中，这是P4Runtime标准的一部分。
|
||||
|
||||
The controller can set the **ForwardingPipelineConfig**, which involves:
|
||||
|
||||
控制器可以设置 **ForwardingPipelineConfig**，包括以下内容：
|
||||
|
||||
- Installing and running the compiled P4 program output included in the `p4_device_config` field of the Protobuf message.
|
||||
安装并运行包含在 Protobuf 消息 p4_device_config 字段中的已编译P4程序输出。
|
||||
- Installing the associated **P4Info metadata**.
|
||||
安装相关的 **P4Info元数据**。
|
||||
|
||||
The controller can also query the target for the **ForwardingPipelineConfig** to retrieve the device configuration and the P4Info.
|
||||
|
||||
控制器还可以查询目标设备的 **ForwardingPipelineConfig** 以获取设备配置和P4Info。
|
||||
|
||||
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.
|
||||
|
||||
**P4Runtime API** 通过运行一个绑定自动生成的 P4Runtime 服务接口的 gRPC 服务器实现。这个程序被称为 **P4Runtime服务器**。默认情况下，服务器必须监听 **TCP端口9559**，这是IANA为P4Runtime服务分配的端口。不过，服务器应允许用户通过配置文件或启动标志覆盖默认端口。
|
||||
|
||||
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控制器选择适合特定目标设备的配置，并通过 **SetForwardingPipelineConfig RPC** 安装它。
|
||||
|
||||
The **P4Info metadata** describes: **P4Info元数据** 描述了：
|
||||
|
||||
- The overall program itself (**PkgInfo**). 整个程序本身（**PkgInfo**）。
|
||||
- All entity instances derived from the P4 program, such as **tables** and **extern instances**. 所有从P4程序派生的实体实例，例如 **表** 和 **外部实例**。
|
||||
|
||||
Each entity instance is assigned a numeric ID by the P4 compiler, which serves as a concise "handle" for use in API calls.
|
||||
每个实体实例由P4编译器分配一个数字ID，用作API调用中使用的简洁“句柄”。
|
||||
|
||||
In this workflow, **P4 compiler backends** are developed for each unique type of target and generate two outputs:
|
||||
在此工作流程中，为每种独特类型的目标设备开发了 **P4编译器后端**，并生成两个输出：
|
||||
|
||||
- **P4Info**: A schema that is target- and architecture-independent, although its specific contents are likely to be architecture-dependent.
|
||||
**P4Info**：一个目标和架构无关的模式，但其具体内容可能与架构相关。
|
||||
- A **target-specific device config**.
|
||||
**特定目标设备的配置**。
|
||||
|
||||
The compiler ensures that the P4 program is compatible with the specific target and rejects incompatible code.
|
||||
编译器确保P4程序与特定目标兼容，并拒绝不兼容的代码。
|
||||
|
||||
|
||||
|
||||
**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**.
|
||||
**P4Runtime** 支持多个控制器的使用。控制器可以嵌入在P4目标设备中，也可以独立运行。对于基于P4的SDN，我们选择将控制器与目标设备分离部署，如 **图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:
|
||||
该作业提供的基础设施包括一个 **“外部”虚拟机** (`gruppeX.rnp.lab.nm.ifi.lmu.de`)，其中创建了七个 **“内部”虚拟机**，包括：
|
||||
|
||||
- Hosts: `pc1`, `pc2`, `pc3`.
|
||||
- Switches: `S1`, `S2`, `S3`.
|
||||
- A controller deployed at `router4`.
|
||||
|
||||
|
||||
|
||||
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)**.
|
||||
|
||||
有关安装P4相关软件的说明，可以参考 **P4语言教程**，其中包括 **Ubuntu 20.04** 上的示例部署。此外，开发团队还通过 **p4lang 仓库** 提供了适用于 **Debian 11** 和 **Ubuntu 22.04** 的包管理器安装方式。也可以直接从 **源代码** 安装。
|
||||
|
||||
### 4.4.4 Example: deploying a simple repeater
|
||||
|
||||
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)**.
|
||||
|
||||
我们通过一个简单的 **中继器应用 (repeater application)** 演示如何运行P4交换机，并由控制器进行控制。本示例复用了 **ETH网络系统组 (ETH Networked Systems Group)** 提供的材料。
|
||||
|
||||
|
||||
|
||||
**Figure 4.14** illustrates the network topology used in this example, which includes:
|
||||
|
||||
- Two switches: **S1** and **S2**.
|
||||
- Two endpoints: **PC1** and **PC2**.
|
||||
- A **controller**.
|
||||
|
||||
The **P4 source files** and the **controller applications** are stored on the controller (`router4`) in the directories `p4` and `app`, respectively.
|
||||
|
||||
**P4源文件** 和 **控制器应用程序** 分别存储在控制器 (`router4`) 的 `p4` 和 `app` 目录中。
|
||||
|
||||
#### Compiling repeater.p4
|
||||
|
||||
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:
|
||||
|
||||
如前所述，P4编译器安装在控制器上（在本例中为 `router4`）。要编译 `repeater.p4` 并生成 **P4设备配置文件** 和 **P4Info文件**，请执行以下命令：
|
||||
|
||||
```bash
|
||||
ssh root@router4
|
||||
cd p4
|
||||
p4c-bm2-ss --p4v 16 --p4runtime-files build/repeater.p4info.txt \
|
||||
-o build/repeater.json repeater.p4
|
||||
```
|
||||
|
||||
This produces two files:
|
||||
|
||||
- **`repeater.json`**: The P4 Device config file for the P4 switches.
|
||||
- **`repeater.p4info.txt`**: The P4Info file for the controller application `repeater_controller.py`.
|
||||
|
||||
生成的两个文件分别是：
|
||||
|
||||
- **`repeater.json`**：用于P4交换机的P4设备配置文件。
|
||||
- **`repeater.p4info.txt`**：控制器应用程序 `repeater_controller.py` 使用的P4Info文件。
|
||||
|
||||
#### Distributing the P4 Device Config File
|
||||
|
||||
The **`repeater.json`** file needs to be copied to the switches `S1` and `S2`. This can be done from the outer machine using the following commands:
|
||||
|
||||
需要将 **`repeater.json`** 文件复制到交换机 `S1` 和 `S2`。可以通过外部机器执行以下命令：
|
||||
|
||||
```bash
|
||||
scp -3 root@router4:p4/build/repeater.json root@s1:
|
||||
scp -3 root@router4:p4/build/repeater.json root@s2:
|
||||
```
|
||||
|
||||
#### Creating P4 Switches
|
||||
|
||||
At Switch S1
|
||||
|
||||
Use the following commands to create a P4 switch on `S1`:
|
||||
|
||||
使用以下命令在 `S1` 上创建一个 P4 交换机：
|
||||
|
||||
```bash
|
||||
ssh root@s1
|
||||
ip link set eth1 up
|
||||
ip link set eth2 up
|
||||
simple_switch_grpc -i 1@eth1 -i 2@eth2 --pcap pcaps \
|
||||
--nanolog ipc:///log.ipc --device-id 1 repeater.json \
|
||||
--log-console --thrift-port 9090 \
|
||||
-- --grpc-server-addr 0.0.0.0:50051 --cpu-port 255
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
`simple_switch_grpc` 命令创建了一个 **[SimpleSwitchGrpc 目标](https://github.com/p4lang/behavioral-model/blob/main/targets/simple_switch_grpc/README.md)**，这是支持 **P4Runtime** 的 **SimpleSwitch** 版本。
|
||||
|
||||
Explanation of parameters:
|
||||
|
||||
- `-i 1@eth1 -i 2@eth2`: Binds the switch ports to the "physical" interfaces of the virtual machine. `-i 1@eth1 -i 2@eth2`: 将交换机端口绑定到虚拟机的“物理”接口。
|
||||
- `--pcap pcaps`: Generates PCAP files for interfaces. `--pcap pcaps`: 为接口生成 PCAP 文件。
|
||||
- `--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 交换机的命令类似：
|
||||
|
||||
```bash
|
||||
ssh root@s2
|
||||
ip link set eth1 up
|
||||
ip link set eth2 up
|
||||
simple_switch_grpc -i 1@eth1 -i 2@eth2 --pcap pcaps \
|
||||
--nanolog ipc:///log.ipc --device-id 2 repeater.json \
|
||||
--log-console --thrift-port 9090 \
|
||||
-- --grpc-server-addr 0.0.0.0:50051 --cpu-port 255
|
||||
```
|
||||
|
||||
#### Executing the Control Application
|
||||
|
||||
To execute the control application: 运行控制应用程序：
|
||||
|
||||
```bash
|
||||
ssh root@router4
|
||||
cd app
|
||||
python3 repeater_controller.py
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
**[p4-utils库](https://github.com/p4lang/behavioral-model/blob/main/targets/simple_switch_grpc/README.md)**（经过一些修改以支持 packet-in、packet-out 和 idle timeout）用于实现控制应用程序。它作为 **[p4runtime-shell](https://github.com/p4lang/p4runtime-shell)** 的封装器，简化了控制平面的开发。
|
||||
|
||||
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).
|
||||
|
||||
有关 API（如 `table_add`、`table_delete_match`）的详细信息，可以在 [GitHub 仓库](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.
|
||||
|
||||
**repeater 应用程序** 使用编码在 `topo_repeater.json` 中的网络拓扑信息。对于其他控制应用程序，需要在类似文件中提供相关的网络拓扑信息。
|
||||
|
||||
#### Generating Traffic Between End-Points
|
||||
|
||||
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.
|
||||
|
||||
如果 `PC1` 和 `PC2` 能够通过 `ping` 互相通信，则说明 repeater 应用程序部署成功。
|
||||
|
||||
#### 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`**.
|
||||
|
||||
一个高级控制应用程序 **`arpcache.py`** 与前面的示例一起提供在 `router4` 上。其对应的 P4 源文件为 **`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.
|
||||
|
||||
更多有用的示例可以在 **MNM-GitHub 仓库** [MNM-GitHub](https://github.com/mnm-team/p4-sdn.git) 中找到。这些示例应按照仓库主页面 (`README.md`) 中指定的顺序进行练习，以便更好地理解和顺利过渡。从 **simple_demo 应用程序** 开始，然后依次进行 **simple_switch** 等其他示例。
|
||||
|
||||
Other P4 sources and control applications can also be found in:
|
||||
|
||||
其他 P4 源文件和控制应用程序也可以在以下链接找到：
|
||||
|
||||
- The **P4 language tutorials** [P4 Tutorials](https://github.com/p4lang/tutorials/tree/master/exercises).
|
||||
- The **p4-learning** repository [P4 Learning](https://github.com/nsg-ethz/p4-learning/tree/master/exercises).
|
||||
|
||||
### 4.5 Assignment
|
||||
|
||||
Students will "program" the provided infrastructure using P4-based SDN to meet specific requirements based on a practical scenario.
|
||||
|
||||
学生将使用基于 P4 的 SDN 对提供的基础设施进行编程，以满足基于实际场景的特定需求。
|
||||
|
||||
#### 4.5.1 Scenario
|
||||
|
||||
The Academic Affairs Office (AAO) of University A has:
|
||||
|
||||
1. A **web server** hosting the AAO-Website, publishing important student information.
|
||||
2. An **E-learning Server** providing experimental e-learning services, such as lectures, exercises, and evaluations.
|
||||
|
||||
大学 A 的教务办公室 (AAO) 拥有以下资源：
|
||||
|
||||
1. 一个 **Web 服务器**，托管 AAO 网站，用于发布重要的学生信息。
|
||||
2. 一个 **E-learning 服务器**，提供实验性的在线学习服务，如讲座、练习和评估。
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
为了演示目的，将场景简化为 **图 4.16**：
|
||||
|
||||
- **PC1** 代表外部实体。
|
||||
- **交换机 S1** 作为网关。
|
||||
- **交换机 S2, S3** 和 **PC2, PC3** 构成内部网络。
|
||||
|
||||
|
||||
|
||||
**Requirements:**
|
||||
|
||||
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.
|
||||
|
||||
**需求：**
|
||||
|
||||
1. 如果从 **PC1 到 PC2** 的流量达到或超过 **512 Kbps**：
|
||||
- 在网关执行 **负载均衡**，流量交替转发到 **PC3** 和 **PC2**，因为 PC3 也提供与 PC2 相同的服务。
|
||||
- 从 **PC3 到 PC1** 的响应流量必须在网关处修改，将其 **源 IP 地址** 和 **源 MAC 地址** 更改为 **PC2** 的地址。
|
||||
2. **可选**：如果从 **PC1 到 PC2** 或 **PC3** 的流量达到或超过 **768 Kbps**，丢弃负载最高的流量。
|
||||
|
||||
**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.
|
||||
|
||||
**注意：** 以上提到的流量仅指从 **PC1 到 PC2** 的方向。来自 **PC2 到 PC1** 的流量以及其他流量可以忽略。
|
||||
|
||||
####
|
||||
|
||||
#### Implementation
|
||||
|
||||
Student groups will:
|
||||
|
||||
- Develop appropriate SDN applications and P4 programs.
|
||||
- Deploy these on the provided infrastructure to meet the above requirements.
|
||||
|
||||
学生小组需要：
|
||||
|
||||
- 开发适当的 SDN 应用程序和 P4 程序。
|
||||
- 将其部署到提供的基础设施中，以满足上述需求。
|
||||
|
||||
### 4.5.3 Submission
|
||||
|
||||
- Submit the source code and a manual detailing how to deploy and run the applications. 提交源代码以及详细说明如何部署和运行应用程序的手册。
|
||||
- The submission should be compressed into a **zip file**. 提交内容需压缩为 **zip 文件**。
|
||||
|
||||
### 4.5.4 Assessment
|
||||
|
||||
The assignment will be assessed based on: 作业的评估基于以下两点：
|
||||
|
||||
1. The **final demo** presented in class (at the "Baracke"). 在课堂上进行的 **最终演示**（地点："Baracke"）。
|
||||
2. The **manual** submitted with the source code. 提交的 **手册**。
|
||||
|
||||
### 4.5.5 Important Dates
|
||||
|
||||
- **14.01.2025 23:59**:
|
||||
Submission of the source code that measures the traffic volume from **PC1 to PC2**.
|
||||
|
||||
- Refer to the example on Counters available at https://github.com/mnmteam/p4-sdn/tree/main/counters.
|
||||
|
||||
提交用于测量从 **PC1 到 PC2** 流量的源代码。
|
||||
|
||||
- 参考 https://github.com/mnmteam/p4-sdn/tree/main/counters 中关于计数器的示例。
|
||||
|
||||
- **21.01.2025 13:59**:
|
||||
Submission of the **final source code** and the **manual**.
|
||||
提交 **最终源代码** 和 **手册**。
|
||||
|
||||
- **21.01.2025 14:00**:
|
||||
**Demo** presentation
|
||||
BIN
Blatt04/Notes04.pdf
Normal file
BIN
Blatt04/Notes04.pdf
Normal file
Binary file not shown.
831
OralNotes.md
Normal file
831
OralNotes.md
Normal file
@@ -0,0 +1,831 @@
|
||||
还差什么？
|
||||
|
||||
1-3 Theoretical Problems
|
||||
|
||||
4 ask yourself questions
|
||||
|
||||
3 RIP OSPF BGP?
|
||||
|
||||
3 讲述一下RA RS NA NS的过程
|
||||
|
||||
[toc]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 什么是一个自治系统？(Autonome Systeme)
|
||||
|
||||
自治系统（Autonomous System，AS）指的是在互联网中由单一管理实体（如网络运营商、企业、大学等）控制的一组IP网络和路由器集合。每个自治系统都有一个唯一的自治系统号码（ASN），用于在边界网关协议（BGP）中标识和交换路由信息。自治系统内部使用统一的路由策略管理数据流，而各AS之间则通过BGP互联，从而构成全球互联网的基础架构。
|
||||
|
||||
## 自治系统语境下的对等关系和传输关系各是什么意思？
|
||||
|
||||
**Peering relationship（对等互联关系）：**
|
||||
在这种关系中，两家或多家网络通常规模相近且流量互补，它们直接互联并交换彼此的流量，而不收取费用或仅象征性收取费用。这种方式旨在优化数据传输路径和提高网络效率，同时降低运营成本。
|
||||
|
||||
**Transit relationship（传递关系）：**
|
||||
这种关系通常涉及付费，指的是一个网络（客户网络）向一个规模更大、覆盖范围更广的网络（提供商网络）支付费用，以获得对整个互联网或更大部分网络的连接。通过 Transit 关系，客户网络可以访问那些没有与之直接对等互联的其他网络。
|
||||
|
||||
## 网络层和数据链路层的作用各是什么？
|
||||
|
||||
- **网络层（Network Layer）：**
|
||||
- **主要作用：** 负责在不同网络之间传输数据包，确定数据从源到目的地的最佳路径。
|
||||
- 关键功能：
|
||||
- **逻辑寻址：** 使用IP地址标识各个网络设备。
|
||||
- **路由选择：** 通过路由协议（如OSPF、BGP等）决定数据包的转发路径。
|
||||
- **数据包转发：** 在各个网络间将数据包从一跳转发到下一跳。
|
||||
- **分片与重组：** 当数据包在传输中需要跨越不同MTU的网络时进行分片，并在目的地重组数据包。
|
||||
- **数据链路层（Data Link Layer）：**
|
||||
- **主要作用：** 负责在相邻网络节点之间进行可靠的数据传输，确保物理传输过程中数据的完整性。
|
||||
- 关键功能：
|
||||
- **帧封装：** 将网络层传来的数据封装成帧，并在接收端进行解封装。
|
||||
- **物理地址：** 使用MAC地址来唯一标识局域网中的设备。
|
||||
- **错误检测与纠正：** 通过校验和等机制检测传输错误，并在必要时进行纠正。
|
||||
- **流量控制：** 管理数据传输速率，避免网络拥塞。
|
||||
|
||||
## 不同子网的不同的第二层实现指的是什么？
|
||||
|
||||
以太网，WiFi
|
||||
|
||||
## CIDR出现前是怎么划分子网的？
|
||||
|
||||
IPv4 地址被划分为五类，每类的网络部分和主机部分的长度不同：
|
||||
|
||||
| **类别** | **地址范围** | **网络部分长度** | **主机部分长度** | **用途** |
|
||||
| :------- | :-------------------------- | :--------------- | :--------------- | :------------------- |
|
||||
| A | 0.0.0.0 - 127.255.255.255 | 8 位 | 24 位 | 大型网络 |
|
||||
| B | 128.0.0.0 - 191.255.255.255 | 16 位 | 16 位 | 中型网络 |
|
||||
| C | 192.0.0.0 - 223.255.255.255 | 24 位 | 8 位 | 小型网络 |
|
||||
| D | 224.0.0.0 - 239.255.255.255 | N/A | N/A | 多播地址 |
|
||||
| E | 240.0.0.0 - 255.255.255.255 | N/A | N/A | 保留地址（实验用途） |
|
||||
|
||||
RFC 1918 定义了以下私有地址范围，这些地址用于本地网络（如企业内部网络），不会在公共互联网上路由：
|
||||
|
||||
| **类别** | **私有地址范围** | **默认子网掩码** |
|
||||
| :------- | :---------------------------- | :---------------- |
|
||||
| A | 10.0.0.0 - 10.255.255.255 | 255.0.0.0 (/8) |
|
||||
| B | 172.16.0.0 - 172.31.255.255 | 255.240.0.0 (/12) |
|
||||
| C | 192.168.0.0 - 192.168.255.255 | 255.255.0.0 (/16) |
|
||||
|
||||
6. IPv6协议有多长？
|
||||
128位
|
||||
| **字段** | **长度（比特）** | **描述** |
|
||||
| :-------------------------------- | :--------------- | :--------------------------------------------------------- |
|
||||
| **FP（Format Prefix）** | 3 | 格式前缀，用于标识地址类型（如全局单播地址、本地地址等）。 |
|
||||
| **TLA（Top-Level Aggregation）** | 13 | 顶级聚合标识符，用于标识顶级 ISP 或大型组织。 |
|
||||
| **RES（Reserved）** | 8 | 保留字段，用于未来扩展。 |
|
||||
| **NLA（Next-Level Aggregation）** | 24 | 下一级聚合标识符，用于标识下级 ISP 或组织。 |
|
||||
| **SLA（Site-Level Aggregation）** | 16 | 站点级聚合标识符，用于标识组织内部的子网。 |
|
||||
| **Interface ID** | 64 | 接口标识符，用于标识网络接口。 |
|
||||
|
||||
## IPv6地址的构成？（子网和主机ID各有多少位？）
|
||||
|
||||
各64位
|
||||
|
||||
## IPv6的头部是固定的还是变长的？如果是固定的，如何添加额外的信息？
|
||||
|
||||
固定的，存在header-extension
|
||||
IPv6 头部固定为 **40 字节**，包含以下字段：
|
||||
|
||||
| **字段** | **长度（比特）** | **描述** |
|
||||
| :---------------------- | :--------------- | :----------------------------------------------------------- |
|
||||
| **Version** | 4 | 版本号，IPv6 的值为 `6`。 |
|
||||
| **Traffic Class** | 8 | 流量类别，用于区分不同类型的流量（类似于 IPv4 的 TOS 字段）。 |
|
||||
| **Flow Label** | 20 | 流标签，用于标识属于同一流的数据包（用于 QoS 和实时应用）。 |
|
||||
| **Payload Length** | 16 | 有效载荷长度，表示 IPv6 头部之后的数据长度（不包括头部本身）。 |
|
||||
| **Next Header** | 8 | 下一个头部类型，标识紧接在 IPv6 头部之后的扩展头部或上层协议（如 TCP/UDP）。 |
|
||||
| **Hop Limit** | 8 | 跳数限制，类似于 IPv4 的 TTL，每经过一个路由器减 1，减到 0 时丢弃数据包。 |
|
||||
| **Source Address** | 128 | 源 IPv6 地址。 |
|
||||
| **Destination Address** | 128 | 目的 IPv6 地址。 |
|
||||
|
||||
在next header处添加扩展信息
|
||||
|
||||
每个扩展头部都包含以下两个关键字段：
|
||||
|
||||
1. **Next Header**（8 位）：指示下一个扩展头部或上层协议的类型。
|
||||
|
||||
2. **Header Extension Length**（8 位）：指示当前扩展头部的长度（以 8 字节为单位，不包括前 8 字节）。
|
||||
|
||||
## 什么是IPsec?
|
||||
|
||||
**IPsec（Internet Protocol Security）** 是一种用于保护 IP 通信的安全协议套件。它通过在 IP 层提供加密、认证和完整性保护，确保数据在传输过程中的机密性、完整性和真实性。IPsec 广泛应用于虚拟专用网络（VPN）、远程访问、站点到站点连接等场景。
|
||||
|
||||
传输模式（Transport Mode）
|
||||
|
||||
- 仅保护 IP 数据包的有效载荷（Payload），不修改原始 IP 头部。
|
||||
- 适用于端到端通信（如主机到主机）。
|
||||
- 示例：
|
||||
- 原始数据包：`[IP Header][TCP/UDP Header][Data]`
|
||||
- IPsec 保护后：`[IP Header][AH/ESP Header][TCP/UDP Header][Data][ESP Trailer][ICV]`
|
||||
|
||||
**隧道模式（Tunnel Mode）**
|
||||
|
||||
- 保护整个 IP 数据包（包括 IP 头部和有效载荷），并封装在新的 IP 数据包中。
|
||||
- 适用于站点到站点 VPN 或远程访问 VPN。
|
||||
- 示例：
|
||||
- 原始数据包：`[IP Header][TCP/UDP Header][Data]`
|
||||
- IPsec 保护后：`[New IP Header][AH/ESP Header][Original IP Header][TCP/UDP Header][Data][ESP Trailer][ICV]`
|
||||
|
||||
## IPv6是怎么区分本地和全局地址的？
|
||||
|
||||
1. script里主要写分为两类：**全局地址**和**链路本地地址**
|
||||
2. 需要注意的是**链路本地地址不能跨路由器**
|
||||
3. IPv6 地址主要分为以下几类：
|
||||
1. **全局单播地址（Global Unicast Address）**：
|
||||
1. 用于公共互联网，全球唯一。
|
||||
2. 前缀通常为 `2000::/3`（即 `2000::` 到 `3FFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF`）。
|
||||
2. **唯一本地地址（Unique Local Address, ULA）**：
|
||||
1. 用于本地网络，类似于 IPv4 的私有地址。
|
||||
2. 前缀为 `FC00::/7`（即 `FC00::` 到 `FDFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF`）。
|
||||
3. **链路本地地址（Link-Local Address）**：
|
||||
1. 用于同一链路上的设备通信，不能跨路由器。
|
||||
2. 前缀为 `FE80::/10`（即 `FE80::` 到 `FEBF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF`）。
|
||||
4. **多播地址（Multicast Address）**：
|
||||
1. 用于一对多通信。
|
||||
2. 前缀为 `FF00::/8`（即 `FF00::` 到 `FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF`）。
|
||||
5. **回环地址（Loopback Address）**：
|
||||
1. 用于本地回环测试。
|
||||
2. 地址为 `::1`。
|
||||
6. **未指定地址（Unspecified Address）**：
|
||||
1. 用于表示地址未指定。
|
||||
2. 地址为 `::`。
|
||||
|
||||
## 实现IPv4和IPv6两个协议版本共存的方法：
|
||||
|
||||
1. 双栈
|
||||
2. 隧道技术
|
||||
|
||||
## 讲一讲ICMPv6
|
||||
|
||||
ICMPv6 的主要功能包括：
|
||||
|
||||
1. **错误报告**：
|
||||
|
||||
- 当数据包传输过程中发生错误时，ICMPv6 会生成错误消息并发送给源节点。
|
||||
- 例如，目标不可达、数据包过大、超时等。
|
||||
|
||||
2. **诊断功能**：
|
||||
|
||||
- 提供网络诊断工具，如 **Ping** 和 **Traceroute**。
|
||||
- 用于测试网络连通性和路径。
|
||||
|
||||
3. **邻居发现协议（NDP）**：
|
||||
|
||||
- 用于 IPv6 中的地址解析、邻居状态跟踪和路由器发现。
|
||||
- 替代了 IPv4 中的 **ARP（Address Resolution Protocol）**。
|
||||
|
||||
4. **多播监听发现协议（MLD）**：
|
||||
|
||||
- 用于管理多播组成员关系。
|
||||
- 替代了 IPv4 中的 **IGMP（Internet Group Management Protocol）**。
|
||||
|
||||
|
||||
**2. ICMPv6 的消息类型**
|
||||
|
||||
ICMPv6 消息分为两大类：**错误消息** 和 **信息消息**。每种消息类型由一个唯一的类型值标识。
|
||||
|
||||
**2.1 错误消息**
|
||||
|
||||
错误消息用于报告数据包传输过程中的问题。常见的错误消息类型包括：
|
||||
|
||||
| **类型值** | **消息类型** | **描述** |
|
||||
| :--------- | :------------------------------------ | :------------------------------------------- |
|
||||
| 1 | 目标不可达（Destination Unreachable） | 数据包无法到达目标节点。 |
|
||||
| 2 | 数据包过大（Packet Too Big） | 数据包超过链路的 MTU，无法传输。 |
|
||||
| 3 | 超时（Time Exceeded） | 数据包的 TTL（跳数限制）减到 0，或重组超时。 |
|
||||
| 4 | 参数问题（Parameter Problem） | 数据包头部字段有错误。 |
|
||||
|
||||
**2.2 信息消息**
|
||||
|
||||
信息消息用于网络诊断和管理。常见的信息消息类型包括：
|
||||
|
||||
| **类型值** | **消息类型** | **描述** |
|
||||
| :--------- | :---------------------------------------- | :--------------------------------------- |
|
||||
| 128 | 回显请求（Echo Request） | 用于 Ping 测试，请求目标节点回复。 |
|
||||
| 129 | 回显应答（Echo Reply） | 目标节点对回显请求的响应。 |
|
||||
| 133 | 路由器请求（Router Solicitation） | 主机请求路由器发送路由器通告。 |
|
||||
| 134 | 路由器通告（Router Advertisement） | 路由器发送的通告消息，包含网络配置信息。 |
|
||||
| 135 | 邻居请求（Neighbor Solicitation） | 用于地址解析和邻居状态跟踪。 |
|
||||
| 136 | 邻居通告（Neighbor Advertisement） | 对邻居请求的响应，包含链路层地址。 |
|
||||
| 130 | 多播监听查询（Multicast Listener Query） | 用于查询多播组成员。 |
|
||||
| 131 | 多播监听报告（Multicast Listener Report） | 主机报告其多播组成员关系。 |
|
||||
| 132 | 多播监听完成（Multicast Listener Done） | 主机离开多播组时发送的消息。 |
|
||||
|
||||
------
|
||||
|
||||
**3. ICMPv6 的消息格式**
|
||||
|
||||
ICMPv6 消息的通用格式如下：
|
||||
|
||||
| **字段** | **长度（字节）** | **描述** |
|
||||
| :------------------------- | :--------------- | :-------------------------------------------------- |
|
||||
| **类型（Type）** | 1 | 消息类型（如 1 表示目标不可达，128 表示回显请求）。 |
|
||||
| **代码（Code）** | 1 | 消息子类型，提供更详细的错误分类。 |
|
||||
| **校验和（Checksum）** | 2 | 用于检测消息在传输过程中是否损坏。 |
|
||||
| **消息体（Message Body）** | 可变 | 包含具体的消息数据，如错误信息、诊断数据等。 |
|
||||
|
||||
------
|
||||
|
||||
**4. ICMPv6 的关键功能**
|
||||
|
||||
**4.1 邻居发现协议（NDP）**
|
||||
|
||||
NDP 是 ICMPv6 的核心功能之一，用于替代 IPv4 中的 ARP。它通过以下消息实现：
|
||||
|
||||
- **路由器请求（Router Solicitation, RS）**：
|
||||
- 主机发送 RS 消息，请求路由器发送路由器通告。
|
||||
- **路由器通告（Router Advertisement, RA）**：
|
||||
- 路由器发送 RA 消息，包含网络配置信息（如前缀、MTU 等）。
|
||||
- **邻居请求（Neighbor Solicitation, NS）**：
|
||||
- 用于地址解析（将 IPv6 地址解析为链路层地址）。
|
||||
- **邻居通告（Neighbor Advertisement, NA）**：
|
||||
- 对 NS 消息的响应，包含链路层地址。
|
||||
|
||||
**4.2 多播监听发现协议（MLD）**
|
||||
|
||||
MLD 用于管理多播组成员关系，替代了 IPv4 中的 IGMP。它通过以下消息实现：
|
||||
|
||||
- **多播监听查询（Multicast Listener Query）**：
|
||||
- 路由器发送查询消息，询问哪些主机加入了多播组。
|
||||
- **多播监听报告（Multicast Listener Report）**：
|
||||
- 主机发送报告消息，声明其加入的多播组。
|
||||
- **多播监听完成（Multicast Listener Done）**：
|
||||
- 主机发送完成消息，声明其离开多播组。
|
||||
|
||||
## 描述一下NDP的过程？
|
||||
|
||||
**NDP（Neighbor Discovery Protocol，邻居发现协议）** 是 IPv6 中的一个关键协议，用于替代 IPv4 中的 **ARP（Address Resolution Protocol）**。NDP 不仅支持地址解析，还提供了路由器发现、邻居状态跟踪、重复地址检测等功能。以下是 NDP 的工作过程及其主要功能的详细说明：
|
||||
|
||||
**2. NDP 的工作过程**
|
||||
|
||||
**2.1 路由器发现（Router Discovery）**
|
||||
|
||||
当主机加入网络时，它需要发现本地网络中的路由器并获取网络配置信息（如前缀、MTU 等）。这个过程通过 **RS** 和 **RA** 消息实现。
|
||||
|
||||
1. **主机发送 RS 消息**：
|
||||
- 主机发送 **Router Solicitation（RS）** 消息，请求路由器发送路由器通告。
|
||||
- RS 消息的目标地址为 **所有路由器多播地址（FF02::2）**。
|
||||
|
||||
2. **路由器发送 RA 消息**：
|
||||
- 路由器收到 RS 消息后，发送 **Router Advertisement（RA）** 消息。
|
||||
- RA 消息包含以下信息：
|
||||
- 网络前缀（用于地址自动配置）。
|
||||
- 默认路由器的链路层地址。
|
||||
- MTU（最大传输单元）。
|
||||
- RA 消息可以定期发送，也可以响应 RS 消息发送。
|
||||
|
||||
---
|
||||
|
||||
**2.2 地址解析（Address Resolution）**
|
||||
|
||||
当主机需要将 IPv6 地址解析为链路层地址时，使用 **NS** 和 **NA** 消息。
|
||||
|
||||
1. **主机发送 NS 消息**：
|
||||
- 主机发送 **Neighbor Solicitation（NS）** 消息，请求目标 IPv6 地址对应的链路层地址。
|
||||
- NS 消息的目标地址为 **请求节点多播地址（Solicited-Node Multicast Address）**，格式为 `FF02::1:FFXX:XXXX`，其中 `XX:XXXX` 是目标 IPv6 地址的最后 24 位。
|
||||
|
||||
2. **目标主机发送 NA 消息**：
|
||||
- 目标主机收到 NS 消息后，发送 **Neighbor Advertisement（NA）** 消息，包含其链路层地址。
|
||||
- NA 消息的目标地址为请求主机的单播地址。
|
||||
|
||||
---
|
||||
|
||||
**2.3 邻居状态跟踪（Neighbor State Tracking）**
|
||||
|
||||
NDP 维护一个 **邻居缓存表（Neighbor Cache）**，用于跟踪邻居的状态。邻居状态包括：
|
||||
- **INCOMPLETE**：正在解析地址。
|
||||
- **REACHABLE**：邻居可达。
|
||||
- **STALE**：邻居状态未知，需要验证。
|
||||
- **DELAY**：延迟验证。
|
||||
- **PROBE**：正在验证邻居的可达性。
|
||||
|
||||
---
|
||||
|
||||
**2.4 重复地址检测（Duplicate Address Detection, DAD）**
|
||||
|
||||
在主机配置 IPv6 地址之前，需要确保该地址在本地链路上是唯一的。这个过程通过 **NS** 和 **NA** 消息实现。
|
||||
|
||||
1. **主机发送 NS 消息**：
|
||||
- 主机发送 **Neighbor Solicitation（NS）** 消息，目标地址为待检测的 IPv6 地址。
|
||||
- 如果收到 **Neighbor Advertisement（NA）** 消息，说明地址已被占用。
|
||||
|
||||
2. **地址可用**：
|
||||
- 如果没有收到 NA 消息，主机可以安全地使用该地址。
|
||||
|
||||
---
|
||||
|
||||
**2.5 重定向（Redirect）**
|
||||
|
||||
当路由器发现主机选择的下一跳不是最优路径时，会发送 **Redirect** 消息，通知主机有更好的下一跳地址。
|
||||
|
||||
1. **路由器发送 Redirect 消息**：
|
||||
- 路由器发送 **Redirect** 消息，包含更好的下一跳地址。
|
||||
- 主机更新其路由表，使用新的下一跳地址。
|
||||
|
||||
|
||||
|
||||
## 路由协议的主要功能是什么？最优路径用在哪里？
|
||||
|
||||
路由协议的主要功能是让每个路由器将其已知的子网信息传递给其他路由器。
|
||||
最优路径用在计算两个设备之间的最优距离
|
||||
|
||||
## 如何计算最优路径？
|
||||
|
||||
1. 网络可以看成是在生成的加权边图上(generated weighted graph)，规划算法为路由器寻找一条最优路径(plan algorithm finds an optimal path for the router.)
|
||||
2. 一般存在一个成本函数，成本函数会计算包离开网络的代价。离开网络既可以指送到指定设备，也可以是送到对应的运营商（自治系统 ）
|
||||
|
||||
## 自适应路由方法的分类？
|
||||
|
||||
1. 集中式
|
||||
2. 分布式
|
||||
|
||||
## 路由协议一般使用哪两种方法
|
||||
|
||||
1. 自适应距离向量方法
|
||||
1. **距离向量（Distance Vector）**：每个路由器维护一个路由表，表中包含到每个目标网络的距离（通常以跳数或成本度量）和下一跳路由器。
|
||||
2. **自适应（Adaptive）**：路由器根据网络拓扑的变化动态更新路由表。
|
||||
2. 自适应链路状态方法
|
||||
1. **链路状态（Link State）**：每个路由器维护整个网络的拓扑图，包含所有路由器和链路的状态。
|
||||
2. **自适应（Adaptive）**：路由器根据网络拓扑的变化动态更新链路状态数据库。
|
||||
|
||||
## 讲一下RIP？
|
||||
|
||||
## 什么是OSPF？
|
||||
|
||||
## 什么是BGP？
|
||||
|
||||
**OSPF**、**RIP** 和 **BGP** 是三种常见的路由协议，分别适用于不同的网络环境和需求。以下是它们的详细说明：
|
||||
|
||||
---
|
||||
|
||||
## **1. OSPF（Open Shortest Path First）**
|
||||
|
||||
### **1.1 概述**
|
||||
- **类型**：链路状态路由协议（Link-State Routing Protocol）。
|
||||
- **适用范围**：中大型企业网络、ISP 网络。
|
||||
- **标准**：RFC 2328。
|
||||
|
||||
### **1.2 工作原理**
|
||||
1. **链路状态信息收集**：
|
||||
- 每个路由器通过 **Hello 协议** 发现邻居路由器，并收集链路状态信息（如链路成本、带宽等）。
|
||||
|
||||
2. **链路状态广播**：
|
||||
- 每个路由器将收集到的链路状态信息封装成 **链路状态通告（LSA, Link State Advertisement）**，并广播给整个网络。
|
||||
- 使用 **泛洪（Flooding）** 机制确保所有路由器收到 LSA。
|
||||
|
||||
3. **链路状态数据库同步**：
|
||||
- 每个路由器维护一个 **链路状态数据库（LSDB, Link State Database）**，存储整个网络的拓扑信息。
|
||||
- 通过交换 LSA，所有路由器的 LSDB 最终同步。
|
||||
|
||||
4. **最短路径计算**：
|
||||
- 每个路由器使用 **Dijkstra 算法** 计算到所有目标网络的最短路径。
|
||||
- 根据计算结果更新路由表。
|
||||
|
||||
5. **区域划分**：
|
||||
- OSPF 支持将网络划分为多个 **区域（Area）**，以减少路由信息的传播范围。
|
||||
- **Area 0** 是骨干区域，其他区域必须与 Area 0 直接或间接连接。
|
||||
|
||||
### **1.3 特点**
|
||||
- **快速收敛**：在网络拓扑变化时，路由信息传播较快，收敛速度快。
|
||||
- **支持分层设计**：通过区域划分减少路由信息的传播范围。
|
||||
- **计算复杂度高**：需要更多的计算资源和存储空间。
|
||||
|
||||
### **1.4 适用场景**
|
||||
- 中大型企业网络。
|
||||
- ISP 网络。
|
||||
|
||||
---
|
||||
|
||||
## **2. RIP（Routing Information Protocol）**
|
||||
|
||||
### **2.1 概述**
|
||||
- **类型**：距离向量路由协议（Distance-Vector Routing Protocol）。
|
||||
- **适用范围**：小型网络。
|
||||
- **版本**：RIP v1（RFC 1058）、RIP v2（RFC 2453）。
|
||||
|
||||
### **2.2 工作原理**
|
||||
1. **路由表初始化**：
|
||||
- 每个路由器初始化自己的路由表，记录到直连网络的距离（通常为 0）和下一跳路由器。
|
||||
|
||||
2. **定期广播路由信息**：
|
||||
- 每个路由器定期（默认 30 秒）向邻居路由器广播自己的路由表。
|
||||
- 广播的内容包括目标网络和到该网络的距离（跳数）。
|
||||
|
||||
3. **更新路由表**：
|
||||
- 路由器收到邻居的路由表后，根据以下规则更新自己的路由表：
|
||||
- 如果通过邻居到达目标网络的距离更短，则更新路由表。
|
||||
- 如果邻居的路由表中包含新的目标网络，则添加到自己的路由表中。
|
||||
|
||||
4. **路由收敛**：
|
||||
- 通过多次广播和更新，路由表最终收敛到稳定的状态。
|
||||
|
||||
### **2.3 特点**
|
||||
- **简单易实现**：算法简单，适合小型网络。
|
||||
- **慢收敛问题**：在网络拓扑变化时，路由信息传播较慢，可能导致路由环路。
|
||||
- **最大跳数限制**：RIP 的最大跳数为 15，超过 15 跳的网络被视为不可达。
|
||||
|
||||
### **2.4 适用场景**
|
||||
- 小型网络。
|
||||
- 对路由计算复杂度要求较低的场景。
|
||||
|
||||
---
|
||||
|
||||
## **3. BGP（Border Gateway Protocol）**
|
||||
|
||||
### **3.1 概述**
|
||||
- **类型**：路径向量路由协议（Path-Vector Routing Protocol）。
|
||||
- **适用范围**：互联网骨干网、ISP 之间的路由。
|
||||
- **版本**：BGP-4（RFC 4271）。
|
||||
|
||||
### **3.2 工作原理**
|
||||
1. **建立邻居关系**：
|
||||
- BGP 路由器通过 **TCP 连接（端口 179）** 建立邻居关系（Peer）。
|
||||
- 邻居关系可以是 **内部 BGP（iBGP）** 或 **外部 BGP（eBGP）**。
|
||||
|
||||
2. **交换路由信息**：
|
||||
- 邻居之间交换 **BGP 更新消息（Update Message）**，包含目标网络和路径属性（如 AS 路径、下一跳等）。
|
||||
|
||||
3. **路径选择**：
|
||||
- 每个 BGP 路由器根据路径属性（如 AS 路径长度、本地优先级等）选择最佳路径。
|
||||
- 最佳路径被添加到路由表中，并广播给其他邻居。
|
||||
|
||||
4. **路由策略**：
|
||||
- BGP 支持灵活的路由策略配置，如路由过滤、路径偏好设置等。
|
||||
|
||||
### **3.3 特点**
|
||||
- **支持大规模网络**：BGP 是互联网的核心路由协议，支持大规模路由表。
|
||||
- **路径向量协议**：通过 AS 路径属性避免路由环路。
|
||||
- **路由策略灵活**：支持复杂的路由策略配置。
|
||||
|
||||
### **3.4 适用场景**
|
||||
- 互联网骨干网。
|
||||
- ISP 之间的路由。
|
||||
- 大型企业网络的多宿主连接。
|
||||
|
||||
---
|
||||
|
||||
## **4. 三种协议的对比**
|
||||
|
||||
| **特性** | **OSPF** | **RIP** | **BGP** |
|
||||
| -------------- | ------------------------ | ---------- | ---------------------------- |
|
||||
| **类型** | 链路状态 | 距离向量 | 路径向量 |
|
||||
| **适用范围** | 中大型企业网络、ISP 网络 | 小型网络 | 互联网骨干网、ISP 之间的路由 |
|
||||
| **收敛速度** | 快 | 慢 | 中等 |
|
||||
| **计算复杂度** | 高 | 低 | 高 |
|
||||
| **路由策略** | 有限 | 无 | 灵活 |
|
||||
| **典型应用** | 企业内网、ISP 网络 | 小型局域网 | 互联网骨干网 |
|
||||
|
||||
---
|
||||
|
||||
## **5. 总结**
|
||||
- **OSPF**：适用于中大型网络，支持分层设计和快速收敛，计算复杂度较高。
|
||||
- **RIP**：适用于小型网络，简单易实现，但存在慢收敛问题。
|
||||
- **BGP**：适用于互联网骨干网和 ISP 之间的路由，支持复杂的路由策略，但配置和管理较为复杂。
|
||||
|
||||
根据网络规模和需求，可以选择合适的路由协议。
|
||||
|
||||
## A200 Address Resolution and Neighbor Discovery (Theorie)
|
||||
|
||||
Das RFC 826 definiert das Address Resolution Protocol (ARP). In RFC 4861 wird das Neighbor Discovery Protocol (NDP) spezifiziert. RFC 826 定义了地址解析协议（ARP）。RFC 4861 规定了邻居发现协议（NDP）。
|
||||
|
||||
1. **Wozu wird ARP eingesetzt? Was ist der Unterschied zu NDP?** **ARP 的用途是什么？它与 NDP 的区别是什么？**
|
||||
My answer: ARP is used to convert the IPv4 Address to Hardware address, i.e. MAC address.
|
||||
NDP is used in IPv6 protocol
|
||||
While ARP works by broadcasting requests, NDP uses ICMPv6 messages and **multicast** addresses to achieve more efficient neighbor discovery.
|
||||
|
||||
2. **Beschreiben Sie den Aufbau einer ARP-PDU und erläutern Sie die Bedeutung der einzelnen Felder!** **描述 ARP-PDU 的结构并解释各个字段的含义！**
|
||||
Hardware type 2
|
||||
protocol type 2
|
||||
hardware size 1
|
||||
protocol size 1
|
||||
|
||||
op code 2
|
||||
src_ip: 4
|
||||
src_hw: 6
|
||||
dst_ip: 4
|
||||
dst_hw: 6(ff)
|
||||
|
||||
3. **Welche unterschiedlichen ARP-PDUs gibt es? Welche NDP-PDUs gibt es?** **有哪些不同的 ARP-PDU？NDP-PDU 又有哪些？**
|
||||
reply and request
|
||||
NA NS RS rA
|
||||
|
||||
|
||||
|
||||
4. **Wie lang (in Bytes) ist eine ARP-PDU in einem Netz in dem IPv4 und Ethernet eingesetzt werden?** **在 IPv4 和以太网网络中，ARP-PDU 的长度是多少字节？** 28
|
||||
|
||||
5. **Wie lang (in Bytes) ist eine Neighbor Solicitation Nachricht?** **Neighbor Solicitation 消息的长度是多少字节？**
|
||||
|
||||
|
||||
6. **Das RFC 826 spricht von einer Tabelle (table), deren Implementierung meist als ARP-Cache bezeichnet wird. Was soll laut RFC mit einer Ethernet-SDU passieren, wenn kein Eintrag zur Ziel-IP-Adresse in der Tabelle gefunden wird?** **RFC 826 提到了一张表（table），其实现通常称为 ARP 缓存。RFC 规定如果表中没有找到目标 IP 地址的条目，对以太网 SDU 应该怎么处理？**
|
||||
First, the host broadcast the ARP request packet to every neighbor in the network.
|
||||
If the host receives the ARP reply packet, add the entry to both sides.
|
||||
else drop the packet.
|
||||
|
||||
### A300 Fragmentierung und IP-Tunneling (Theorie)
|
||||
|
||||
i) In wie viele Fragmente wird ein IP-Paket mit Größe 9000 Byte zerlegt, um über ein Ethernet mit MTU = 1500 Byte übertragen zu werden? Geben Sie eine vollständige Rechnung an! 一个大小为 9000 字节的 IP 包在 Ethernet 的 MTU 为 1500 字节的情况下会被分成多少个片段？请提供完整的计算过程！
|
||||
|
||||
ii) Nennen Sie drei Gründe dafür, dass Netzbetreiber IP-Fragmentierung in ihren Netzen verbieten. Erläutern Sie diese Gründe! 请列举网络运营商在其网络中禁止 IP 分片的三个原因，并对这些原因进行解释！**Three Reasons Why Network Operators Prohibit IP Fragmentation and Their Explanations**
|
||||
|
||||
IP fragmentation occurs when a packet exceeds the Maximum Transmission Unit (MTU) of a network link and must be broken into smaller fragments. Many **network operators prohibit IP fragmentation** due to the following reasons:
|
||||
|
||||
**1. Performance Degradation & Increased Overhead**
|
||||
|
||||
- Fragmentation increases the number of packets that must be processed, leading to **higher CPU and memory usage** in routers and firewalls.
|
||||
- Each fragment requires additional headers, increasing **network overhead** and reducing effective data transmission efficiency.
|
||||
- Reassembly at the destination requires buffer space, which can cause delays and resource exhaustion in high-throughput environments.
|
||||
|
||||
**2. Security Risks & Susceptibility to Attacks**
|
||||
|
||||
- Fragmentation makes networks vulnerable to **fragmentation-based attacks**, such as **overlapping fragments (Teardrop attack)** and **tiny fragment attacks** used to evade security filters.
|
||||
- Intrusion Detection Systems (IDS) and firewalls may struggle to inspect fragmented packets, allowing attackers to **bypass security policies** and smuggle malicious payloads.
|
||||
- Attackers can send fragmented packets with missing fragments, causing **DoS (Denial of Service)** by exhausting resources on the target system waiting for reassembly.
|
||||
|
||||
**3. Complications in Path MTU Discovery (PMTUD) & Packet Loss Issues**
|
||||
|
||||
- Many modern networks use **Path MTU Discovery (PMTUD)** to dynamically determine the optimal packet size. If fragmentation is allowed, incorrect PMTUD settings can result in persistent retransmissions.
|
||||
- If a single fragment of a fragmented packet is lost, the entire packet must be retransmitted, leading to **higher packet loss rates** and inefficiencies.
|
||||
- Some middleboxes (e.g., NAT devices, firewalls) drop fragmented packets, causing unpredictable failures in communication.
|
||||
|
||||
### **Conclusion:**
|
||||
|
||||
Because of these issues, **network operators often prohibit IP fragmentation and instead rely on techniques like MSS (Maximum Segment Size) adjustment and PMTUD** to ensure efficient packet transmission without fragmentation.
|
||||
|
||||
------
|
||||
|
||||
**网络运营商在其网络中禁止 IP 分片的三个原因及其解释**
|
||||
|
||||
IP 分片（IP Fragmentation）发生在数据包超过网络链路的 **最大传输单元（MTU）** 时，需要拆分成多个小片进行传输。许多**网络运营商禁止 IP 分片**的原因如下：
|
||||
|
||||
**1. 性能下降 & 额外开销增加**
|
||||
|
||||
- 分片会导致 **路由器和防火墙的 CPU 及内存负载增加**，因为它们需要处理更多的小数据包。
|
||||
- 每个分片都需要附加额外的头部信息，增加了**协议开销**，降低了有效数据传输效率。
|
||||
- 目标端的 **数据重组** 需要缓冲区（buffer），在高吞吐量环境下容易造成**延迟**或**资源耗尽**。
|
||||
|
||||
**2. 安全风险增加 & 易受攻击**
|
||||
|
||||
- 分片容易受到 **基于分片的攻击**，例如**重叠分片攻击（Teardrop attack）\**和\**微小分片攻击（Tiny Fragment Attack）**，这些攻击可用于绕过安全检查。
|
||||
- **入侵检测系统（IDS）和防火墙** 可能无法正确分析分片数据包，导致攻击者可以绕过安全策略，传输恶意负载。
|
||||
- 攻击者可以发送 **丢失部分片段的数据包**，导致目标设备的**资源耗尽（DoS 攻击）**，因为系统需要长时间等待完整数据包。
|
||||
|
||||
**3. PMTUD（路径 MTU 发现）问题 & 数据丢失风险**
|
||||
|
||||
- 现代网络通常使用 **路径 MTU 发现（PMTUD）** 机制来动态确定最佳数据包大小，如果允许分片，错误的 PMTUD 配置可能导致**持续的重传**问题。
|
||||
- 如果 **一个分片丢失**，整个数据包必须重新传输，导致**更高的数据丢失率**和**不必要的网络流量**。
|
||||
- 一些中间设备（如 **NAT 设备、防火墙**）可能会**直接丢弃**分片数据包，导致通信失败。
|
||||
|
||||
iii) Wie wird in modernen TCP/IP-Implementierungen dafür gesorgt, dass Fragmentierung in der Regel nicht erforderlich ist? 在现代的 TCP/IP 实现中，是如何确保通常情况下不需要分片的？
|
||||
|
||||
### **How Do Modern TCP/IP Implementations Avoid the Need for Fragmentation?**
|
||||
|
||||
Modern TCP/IP implementations use several techniques to **minimize or eliminate IP fragmentation**, ensuring efficient packet transmission. The key mechanisms include:
|
||||
|
||||
#### **1. Path MTU Discovery (PMTUD)**
|
||||
|
||||
- **PMTUD dynamically determines the maximum packet size** that can be transmitted without fragmentation.
|
||||
- It works by sending packets with the **Don't Fragment (DF) flag** set. If a router cannot forward the packet due to MTU limitations, it drops the packet and sends an **ICMP "Fragmentation Needed" message** back to the sender.
|
||||
- The sender then **reduces the packet size** accordingly until it finds a suitable MTU.
|
||||
- **Drawback:** Some networks block ICMP messages, causing PMTUD to fail.
|
||||
|
||||
#### **2. TCP Maximum Segment Size (MSS) Adjustment**
|
||||
|
||||
- During the **TCP handshake**, both communicating hosts negotiate the **Maximum Segment Size (MSS)**, which defines the largest payload a TCP segment can carry.
|
||||
- The MSS is set to ensure that the TCP segment, when combined with headers, does not exceed the MTU.
|
||||
- This prevents the need for IP fragmentation at the transport layer.
|
||||
|
||||
#### **3. IPv6 Enforces No Fragmentation by Routers**
|
||||
|
||||
- Unlike IPv4, **IPv6 does not allow routers to fragment packets**. Instead, **only the sender can fragment** based on the discovered MTU.
|
||||
- IPv6 requires **end-to-end PMTUD**, ensuring that packets fit within the smallest MTU along the path.
|
||||
- This shifts the responsibility of fragmentation from routers to the sender, improving network efficiency.
|
||||
|
||||
#### **4. Datagram Packetization Layer Path MTU Discovery (DPLPMTUD)**
|
||||
|
||||
- To address ICMP blocking issues in traditional PMTUD, **DPLPMTUD** uses **probe packets** of increasing sizes to discover the optimal MTU.
|
||||
- This method is more reliable since it does not rely on ICMP messages.
|
||||
- Supported in protocols like **QUIC and modern TCP implementations**.
|
||||
|
||||
### **Conclusion:**
|
||||
|
||||
Modern TCP/IP implementations avoid fragmentation by:
|
||||
|
||||
1. **Using PMTUD** to dynamically adjust packet sizes.
|
||||
2. **Negotiating MSS** in TCP to prevent oversized packets.
|
||||
3. **Relying on IPv6's no-fragmentation rule** and sender-side control.
|
||||
4. **Using DPLPMTUD** as an advanced method for MTU discovery.
|
||||
|
||||
------
|
||||
|
||||
### **在现代的 TCP/IP 实现中，是如何确保通常情况下不需要分片的？**
|
||||
|
||||
现代 TCP/IP 实现采用多个技术来**减少或避免 IP 分片**，从而提高数据传输效率。主要方法包括：
|
||||
|
||||
#### **1. 路径 MTU 发现（PMTUD）**
|
||||
|
||||
- **PMTUD 负责动态确定数据包的最大可传输大小**，以避免分片。
|
||||
- 它通过发送 **“不分片（DF）”标志** 的数据包来测试路径 MTU。
|
||||
- 如果路由器无法转发该数据包（因为 MTU 限制），它会丢弃数据包并返回 **ICMP “需要分片”** 消息。
|
||||
- 发送方根据反馈**调整数据包大小**，直到找到合适的 MTU。
|
||||
- **缺点：**某些网络会屏蔽 ICMP 消息，导致 PMTUD 失败。
|
||||
|
||||
#### **2. TCP 最大段大小（MSS）调整**
|
||||
|
||||
- 在 **TCP 握手** 过程中，双方会协商 **最大段大小（MSS）**，决定 TCP 段的最大有效负载。
|
||||
- MSS 设定时会确保 TCP 段加上 **IP 和 TCP 头部** 不会超过 MTU。
|
||||
- 这样可以在 **传输层避免 IP 分片**，确保数据包大小适应网络环境。
|
||||
|
||||
#### **3. IPv6 取消路由器分片**
|
||||
|
||||
- IPv6 **不允许路由器对数据包进行分片**，只有**发送端**可以执行分片。
|
||||
- IPv6 依赖 **端到端的 PMTUD**，确保数据包适应最小 MTU。
|
||||
- 这使得分片的控制权交给发送方，**提升了网络效率**。
|
||||
|
||||
#### **4. 数据报分组层路径 MTU 发现（DPLPMTUD）**
|
||||
|
||||
- 传统 PMTUD 依赖 ICMP 消息，但某些网络会**屏蔽 ICMP**，导致失败。
|
||||
- **DPLPMTUD** 通过发送不同大小的**探测数据包**来测试路径 MTU，而不依赖 ICMP。
|
||||
- 这种方法更可靠，并已在 **QUIC 和现代 TCP 实现** 中得到支持。
|
||||
|
||||
### **总结：**
|
||||
|
||||
现代 TCP/IP 通过以下方式避免分片：
|
||||
|
||||
1. **使用 PMTUD** 动态调整数据包大小。
|
||||
2. **TCP 通过 MSS 协商**，确保 TCP 段不会超出 MTU 限制。
|
||||
3. **IPv6 取消路由器分片**，让发送方控制数据包大小。
|
||||
4. **DPLPMTUD 提供更先进的 MTU 发现机制**，解决 ICMP 屏蔽问题。
|
||||
|
||||
### A301 IPv6 (Theorie)
|
||||
|
||||
i) Erklären Sie anhand eines Beispiels auf einer Ihrer VMs wie link-local Adressen aus der MAC-Adresse abgeleitet werden! 请结合您虚拟机中的一个示例，解释链路本地地址是如何从 MAC 地址派生的！
|
||||
|
||||
1. Split the MAC address into two halves:
|
||||
|
||||
- `08:00:27:53:8a:e0` → `08:00:27` and `53:8a:e0`
|
||||
|
||||
2. Insert `FF:FE` in the middle:
|
||||
|
||||
- `08:00:27:FF:FE:53:8a:e0`
|
||||
|
||||
3. Invert the 7th bit (Universal/Local bit) of the first byte (08):
|
||||
|
||||
- Convert `08` to binary: `00001000`
|
||||
- Flip the **7th bit**: `00001010` (which is `0A` in hex)
|
||||
- New identifier: **0A:00:27:FF:FE:53:8A:E0**
|
||||
|
||||
4.
|
||||
|
||||
5. ```
|
||||
FE80::0A00:27FF:FE53:8AE0
|
||||
```
|
||||
|
||||
ii) Wie implementiert IPv6 „Broadcasts”? IPv6 是如何实现“广播”的？
|
||||
|
||||
iii) Welches sind die privaten Adressbereiche in IPv6, analog zu 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16 in IPv4? IPv6 中的私有地址范围与 IPv4 中的 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16 对应的是什么？**What Are the Private Address Ranges in IPv6, Equivalent to IPv4's 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16?**
|
||||
|
||||
In **IPv6**, the equivalent of IPv4’s private address ranges includes **Unique Local Addresses (ULA)** and **Link-Local Addresses**.
|
||||
|
||||
#### **1. Unique Local Addresses (ULA) – Equivalent to IPv4 Private Addresses**
|
||||
|
||||
- **Address Range:** `FC00::/7` (commonly used as `FD00::/8`)
|
||||
|
||||
- **Similar to:** IPv4 **10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16**
|
||||
|
||||
- **Purpose:** Used for private networks **without global Internet access**.
|
||||
|
||||
- Structure:
|
||||
|
||||
```
|
||||
FC00::/7
|
||||
```
|
||||
|
||||
is divided as:
|
||||
|
||||
- `FC00::/8` (reserved, not widely used)
|
||||
- `FD00::/8` (widely used for private networks)
|
||||
- The next **40 bits** are a randomly generated "Global ID" to ensure uniqueness.
|
||||
- The remaining **16 bits** are for subnetting.
|
||||
|
||||
Example ULA address:
|
||||
|
||||
```
|
||||
FD12:3456:789A::/48
|
||||
```
|
||||
|
||||
- These addresses are **not routable on the global Internet** but can be used across a large organization.
|
||||
|
||||
------
|
||||
|
||||
#### **2. Link-Local Addresses – Equivalent to IPv4 APIPA (169.254.0.0/16)**
|
||||
|
||||
- **Address Range:** `FE80::/10`
|
||||
- **Similar to:** IPv4 **169.254.0.0/16** (Automatic Private IP Addressing, APIPA)
|
||||
- **Purpose:** Used for communication **within the same link (network segment)**.
|
||||
- **Mandatory:** Every IPv6-enabled device **must** have a link-local address.
|
||||
- **Not Routable:** Cannot be forwarded beyond the local network interface.
|
||||
- **Automatically Assigned:** The address is generated based on the interface MAC address (Modified EUI-64) or a random value.
|
||||
|
||||
Example link-local address:
|
||||
|
||||
```
|
||||
FE80::1a2b:3c4d:5e6f:7g8h/64
|
||||
```
|
||||
|
||||
- Always used in local communication, like **Neighbor Discovery Protocol (NDP) and Router Advertisements (RA)**.
|
||||
|
||||
------
|
||||
|
||||
### **Comparison: IPv4 Private vs. IPv6 Private**
|
||||
|
||||
| **IPv4 Private Address** | **Equivalent IPv6 Address** | **Usage** |
|
||||
| ------------------------ | --------------------------- | -------------------------------------------- |
|
||||
| 10.0.0.0/8 | FD00::/8 (ULA) | Private networks |
|
||||
| 172.16.0.0/12 | FD00::/8 (ULA) | Private networks |
|
||||
| 192.168.0.0/16 | FD00::/8 (ULA) | Private home/enterprise networks |
|
||||
| 169.254.0.0/16 (APIPA) | FE80::/10 (Link-Local) | Automatic addressing within the same network |
|
||||
|
||||
### **Conclusion**
|
||||
|
||||
- **`FD00::/8` (ULA) replaces IPv4 private addresses** (10.x.x.x, 172.16.x.x, 192.168.x.x).
|
||||
- **`FE80::/10` (Link-Local) replaces IPv4 APIPA** (169.254.x.x) and is used for local communication.
|
||||
|
||||
Thus, **IPv6 provides private networking similar to IPv4 but with better uniqueness and flexibility**.
|
||||
|
||||
------
|
||||
|
||||
### **IPv6 中的私有地址范围，与 IPv4 中的 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16 对应的是什么？**
|
||||
|
||||
在 **IPv6** 中，与 **IPv4 私有地址** 对应的主要是 **唯一本地地址（ULA）** 和 **链路本地地址（Link-Local Address）**。
|
||||
|
||||
------
|
||||
|
||||
#### **1. 唯一本地地址（ULA）—— 对应 IPv4 私有地址**
|
||||
|
||||
- **地址范围：** `FC00::/7`（通常使用 `FD00::/8`）
|
||||
|
||||
- **类似于：** IPv4 **10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16**
|
||||
|
||||
- **用途：** 供**私有网络使用，不能访问互联网**。
|
||||
|
||||
- 结构：
|
||||
|
||||
```
|
||||
FC00::/7
|
||||
```
|
||||
|
||||
进一步划分为：
|
||||
|
||||
- `FC00::/8`（保留地址，通常不使用）。
|
||||
- `FD00::/8`（广泛用于私有网络）。
|
||||
- 接下来的 **40 位** 是随机生成的 “Global ID”，以确保不同网络中的 ULA 地址唯一。
|
||||
- 其余 **16 位** 用于子网划分。
|
||||
|
||||
示例 ULA 地址：
|
||||
|
||||
```
|
||||
FD12:3456:789A::/48
|
||||
```
|
||||
|
||||
- **不会在全球互联网路由**，但可以用于大规模企业网络或 VPN 连接。
|
||||
|
||||
------
|
||||
|
||||
#### **2. 链路本地地址（Link-Local Address）—— 对应 IPv4 APIPA (169.254.0.0/16)**
|
||||
|
||||
- **地址范围：** `FE80::/10`
|
||||
- **类似于：** IPv4 **169.254.0.0/16**（自动私有 IP 地址，APIPA）
|
||||
- **用途：** 仅用于**同一链路（网络段）内的通信**。
|
||||
- **强制要求：** 每个 IPv6 设备都**必须**拥有一个链路本地地址。
|
||||
- **不可路由：** 不能跨网络转发，仅用于本地通信。
|
||||
- **自动分配：** 设备启动时，会根据**接口 MAC 地址（EUI-64）或随机数**自动生成地址。
|
||||
|
||||
示例链路本地地址：
|
||||
|
||||
```
|
||||
FE80::1a2b:3c4d:5e6f:7g8h/64
|
||||
```
|
||||
|
||||
- 常用于**本地通信**，如 **邻居发现协议（NDP）和路由器通告（RA）**。
|
||||
|
||||
------
|
||||
|
||||
### **IPv4 私有地址 vs. IPv6 私有地址**
|
||||
|
||||
| **IPv4 私有地址** | **对应 IPv6 地址** | **用途** |
|
||||
| ---------------------- | -------------------- | ------------------ |
|
||||
| 10.0.0.0/8 | FD00::/8 (ULA) | 私有网络 |
|
||||
| 172.16.0.0/12 | FD00::/8 (ULA) | 私有网络 |
|
||||
| 192.168.0.0/16 | FD00::/8 (ULA) | 私有家庭或企业网络 |
|
||||
| 169.254.0.0/16 (APIPA) | FE80::/10 (链路本地) | 同一局域网自动通信 |
|
||||
|
||||
------
|
||||
|
||||
### **总结**
|
||||
|
||||
- **`FD00::/8`（ULA）取代 IPv4 私有地址**（10.x.x.x, 172.16.x.x, 192.168.x.x）。
|
||||
- **`FE80::/10`（链路本地地址）取代 IPv4 APIPA 地址**（169.254.x.x），用于本地通信。
|
||||
|
||||
IPv6 提供了与 IPv4 类似的私有网络方案，但**解决了 IPv4 私有地址冲突的问题，提供更好的唯一性和灵活性**。
|
||||
|
||||
iv) Für besondere Zwecke, außer für den privaten Gebrauch, sind noch weitere Bereiche reserviert. Wie teilt sich der IPv6 Addressraum auf? Hinweis: IANA, ignorieren Sie die vom IETF reservierten Bereiche 除了私人用途外，还有其他特殊用途的地址范围被保留。IPv6 地址空间如何划分？提示：请参考 IANA，并忽略由 IETF 保留的范围。
|
||||
290
RESTful-APIs.md
Normal file
290
RESTful-APIs.md
Normal file
@@ -0,0 +1,290 @@
|
||||
# RESTful APIs Documentation
|
||||
|
||||
These APIs are designed to control **TCP** traffic.
|
||||
|
||||
---
|
||||
|
||||
## Policy Endpoints
|
||||
|
||||
Policy rules determine whether to **allow** or **deny** connections between two IP addresses and a specific destination port.
|
||||
|
||||
---
|
||||
|
||||
### **1. Add a Policy Rule**
|
||||
Add a new policy rule to allow or deny traffic.
|
||||
|
||||
- **HTTP Method**: `POST`
|
||||
- **URL Path**: `/policies`
|
||||
- **Request Body**:
|
||||
- `src_ip` (string): Source IP address.
|
||||
- `dst_ip` (string): Destination IP address.
|
||||
- `dst_port` (string): Destination port.
|
||||
- `action` (string): Must be either `allow` or `deny`.
|
||||
|
||||
#### **Example**
|
||||
- **Request**:
|
||||
```bash
|
||||
curl -X POST -H "Content-Type: application/json" -d '{"src_ip": "172.16.1.1", "dst_ip": "172.16.1.2", "dst_port": "5201", "action": "allow"}' http://localhost:8080/policies
|
||||
```
|
||||
|
||||
- **Response**:
|
||||
```json
|
||||
{
|
||||
"action": "allow",
|
||||
"dst_ip": "172.16.1.2",
|
||||
"dst_port": "5201",
|
||||
"id": 0,
|
||||
"src_ip": "172.16.1.1"
|
||||
}
|
||||
```
|
||||
|
||||
- **Status Codes**:
|
||||
- `201 Created`: Policy rule added successfully.
|
||||
- `400 Bad Request`: Invalid input data.
|
||||
- `409 Conflict`: Rule already exists.
|
||||
|
||||
---
|
||||
|
||||
### **2. Retrieve Policy Rules**
|
||||
Fetch all existing policy rules.
|
||||
|
||||
- **HTTP Method**: `GET`
|
||||
- **URL Path**: `/policies`
|
||||
|
||||
#### **Example**
|
||||
- **Request**:
|
||||
```bash
|
||||
curl -X GET http://localhost:8080/policies
|
||||
```
|
||||
|
||||
- **Response**:
|
||||
```json
|
||||
[
|
||||
{
|
||||
"action": "allow",
|
||||
"dst_ip": "172.16.1.2",
|
||||
"dst_port": "5201",
|
||||
"id": 0,
|
||||
"src_ip": "172.16.1.1"
|
||||
},
|
||||
{
|
||||
"action": "allow",
|
||||
"dst_ip": "172.16.1.2",
|
||||
"dst_port": "5202",
|
||||
"id": 1,
|
||||
"src_ip": "172.16.1.1"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
- **Status Codes**:
|
||||
- `200 OK`: Returns the list of policy rules.
|
||||
|
||||
---
|
||||
|
||||
### **3. Update a Policy Rule**
|
||||
Modify an existing policy rule.
|
||||
|
||||
- **HTTP Method**: `PUT`
|
||||
- **URL Path**: `/policies`
|
||||
- **Request Body**:
|
||||
- `src_ip` (string): Source IP address.
|
||||
- `dst_ip` (string): Destination IP address.
|
||||
- `dst_port` (string): Destination port.
|
||||
- `action` (string): Must be either `allow` or `deny`.
|
||||
|
||||
#### **Example**
|
||||
- **Request**:
|
||||
```bash
|
||||
curl -X PUT -H "Content-Type: application/json" -d '{"src_ip": "172.16.1.1", "dst_ip": "172.16.1.2", "dst_port": "5201", "action": "allow"}' http://localhost:8080/policies
|
||||
```
|
||||
|
||||
- **Response**:
|
||||
```json
|
||||
{
|
||||
"action": "allow",
|
||||
"dst_ip": "172.16.1.2",
|
||||
"dst_port": "5201",
|
||||
"id": 0,
|
||||
"src_ip": "172.16.1.1"
|
||||
}
|
||||
```
|
||||
|
||||
- **Status Codes**:
|
||||
- `201 Updated`: Policy rule updated successfully.
|
||||
- `400 Bad Request`: Invalid input data.
|
||||
|
||||
---
|
||||
|
||||
### **4. Delete a Policy Rule**
|
||||
Remove a policy rule by its ID.
|
||||
|
||||
- **HTTP Method**: `DELETE`
|
||||
- **URL Path**: `/policies/{id}`
|
||||
|
||||
#### **Example**
|
||||
- **Request**:
|
||||
```bash
|
||||
curl -X DELETE http://localhost:8080/policies/1
|
||||
```
|
||||
|
||||
- **Response**:
|
||||
```json
|
||||
{
|
||||
"message": "Policy deleted"
|
||||
}
|
||||
```
|
||||
|
||||
- **Status Codes**:
|
||||
- `201 Deleted`: Policy rule deleted successfully.
|
||||
- `404 Not Found`: Rule does not exist.
|
||||
|
||||
---
|
||||
|
||||
## Bandwidth Control Endpoints
|
||||
|
||||
These endpoints manage bandwidth control rules using **P4 meter**. They regulate traffic bandwidth between two IP addresses and a specific destination port.
|
||||
|
||||
Bandwidth is controlled using four parameters:
|
||||
- **CIR (Committed Information Rate)**: Guaranteed minimum bandwidth.
|
||||
- **Cburst (Committed Burst Size)**: Maximum allowed burst above CIR.
|
||||
- **PIR (Peak Information Rate)**: Maximum allowed bandwidth.
|
||||
- **Pburst (Peak Burst Size)**: Maximum allowed burst above PIR.
|
||||
|
||||
**Note**: During testing with `iperf3`, the actual bandwidth was observed to be approximately half of the configured value.
|
||||
|
||||
---
|
||||
|
||||
### **1. Add a Bandwidth Control Rule**
|
||||
Add a new bandwidth control rule.
|
||||
|
||||
- **HTTP Method**: `POST`
|
||||
- **URL Path**: `/bandwidth`
|
||||
- **Request Body**:
|
||||
- `src_ip` (string): Source IP address.
|
||||
- `dst_ip` (string): Destination IP address.
|
||||
- `rates` (list): A list containing two lists:
|
||||
- `[[CIR (bytes), Cburst (bytes)], [PIR (bytes), Pburst (bytes)]]`
|
||||
- `dst_port` (string): Destination port.
|
||||
|
||||
#### **Example**
|
||||
- **Request**:
|
||||
```bash
|
||||
curl -X POST -H "Content-Type: application/json" -d '{"src_ip": "172.16.1.1", "dst_ip": "172.16.1.2", "rates": [[100000, 10000], [100000, 10000]], "dst_port": "5201"}' http://localhost:8080/bandwidth
|
||||
```
|
||||
|
||||
- **Response**:
|
||||
```json
|
||||
{
|
||||
"dst_ip": "172.16.1.2",
|
||||
"dst_port": "5201",
|
||||
"path": ["s1", "s2"],
|
||||
"rates": [[100000, 10000], [100000, 10000]],
|
||||
"src_ip": "172.16.1.1"
|
||||
}
|
||||
```
|
||||
|
||||
- **Status Codes**:
|
||||
- `201 Created`: Bandwidth control rule added successfully.
|
||||
- `400 Bad Request`: Invalid input data.
|
||||
- `409 Conflict`: Rule already exists.
|
||||
|
||||
---
|
||||
|
||||
### **2. Retrieve Bandwidth Control Rules**
|
||||
Fetch all existing bandwidth control rules.
|
||||
|
||||
- **HTTP Method**: `GET`
|
||||
- **URL Path**: `/bandwidth`
|
||||
|
||||
#### **Example**
|
||||
- **Request**:
|
||||
```bash
|
||||
curl -X GET http://localhost:8080/bandwidth
|
||||
```
|
||||
|
||||
- **Response**:
|
||||
```json
|
||||
[
|
||||
{
|
||||
"dst_ip": "172.16.1.2",
|
||||
"dst_port": "5201",
|
||||
"id": 0,
|
||||
"path": ["s1", "s2"],
|
||||
"rates": [[100000, 10000], [100000, 10000]],
|
||||
"src_ip": "172.16.1.1"
|
||||
},
|
||||
{
|
||||
"dst_ip": "172.16.1.2",
|
||||
"dst_port": "5202",
|
||||
"id": 1,
|
||||
"path": ["s1", "s2"],
|
||||
"rates": [[100000, 10000], [100000, 10000]],
|
||||
"src_ip": "172.16.1.1"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
- **Status Codes**:
|
||||
- `200 OK`: Returns the list of bandwidth control rules.
|
||||
|
||||
---
|
||||
|
||||
### **3. Update a Bandwidth Control Rule**
|
||||
Modify an existing bandwidth control rule. If the rule does not exist, it will be created.
|
||||
|
||||
- **HTTP Method**: `PUT`
|
||||
- **URL Path**: `/bandwidth`
|
||||
- **Request Body**:
|
||||
- `src_ip` (string): Source IP address.
|
||||
- `dst_ip` (string): Destination IP address.
|
||||
- `rates` (list): A list containing two lists:
|
||||
- `[[CIR (bytes), Cburst (bytes)], [PIR (bytes), Pburst (bytes)]]`
|
||||
- `dst_port` (string): Destination port.
|
||||
|
||||
#### **Example**
|
||||
- **Request**:
|
||||
```bash
|
||||
curl -X PUT -H "Content-Type: application/json" -d '{"src_ip": "172.16.1.1", "dst_ip": "172.16.1.2", "rates": [[150000, 10000], [150000, 10000]], "dst_port": "5201"}' http://localhost:8080/bandwidth
|
||||
```
|
||||
|
||||
- **Response**:
|
||||
```json
|
||||
{
|
||||
"dst_ip": "172.16.1.2",
|
||||
"dst_port": "5201",
|
||||
"path": ["s1", "s2"],
|
||||
"rates": [[150000, 10000], [150000, 10000]],
|
||||
"src_ip": "172.16.1.1"
|
||||
}
|
||||
```
|
||||
|
||||
- **Status Codes**:
|
||||
- `201 Updated`: Bandwidth control rule updated successfully.
|
||||
- `400 Bad Request`: Invalid input data.
|
||||
|
||||
---
|
||||
|
||||
### **4. Delete a Bandwidth Control Rule**
|
||||
Remove a bandwidth control rule by its ID.
|
||||
|
||||
- **HTTP Method**: `DELETE`
|
||||
- **URL Path**: `/bandwidth/{id}`
|
||||
|
||||
#### **Example**
|
||||
- **Request**:
|
||||
```bash
|
||||
curl -X DELETE http://localhost:8080/bandwidth/1
|
||||
```
|
||||
|
||||
- **Response**:
|
||||
```json
|
||||
{
|
||||
"message": "Bandwidth rule deleted"
|
||||
}
|
||||
```
|
||||
|
||||
- **Status Codes**:
|
||||
- `201 Deleted`: Bandwidth control rule deleted successfully.
|
||||
- `404 Not Found`: Rule does not exist.
|
||||
|
||||
Reference in New Issue
Block a user