OpenStack网络指南（1）网络基础

OpenStack网络服务提供了一个API，允许用户在云中设置和定义网络连接和寻址。网络服务的项目代码名称是neutron。 OpenStack网络处理虚拟网络基础设施的创建和管理，包括OpenStack计算服务（nova）管理的设备的网络，交换机，子网和路由器。还可以使用诸如防火墙或虚拟专用网（VPN）之类的高级服务。
OpenStack网络由neutron-server，持久存储数据库和任意数量的插件代理组成，它们提供其他服务，例如与本地Linux网络机制，外部设备或SDN控制器连接。
OpenStack Networking是完全独立的，可以部署到专用主机。如果部署使用控制器主机来运行集中式计算组件，则可以将网络服务器部署到该特定主机。
OpenStack Networking集成了各种OpenStack组件：
OpenStack身份服务（keystone）用于API请求的身份验证和授权。
OpenStack计算服务（nova）用于将VM上的每个虚拟NIC插入特定网络。
OpenStack仪表板（地平线）由管理员和项目用户使用，通过基于Web的图形界面创建和管理网络服务。

以太网

以太网是由IEEE 802.3标准指定的网络协议。大多数有线网络接口卡（NIC）使用以太网进行通信。
在网络协议的OSI模型中，以太网占用第二层，称为数据链路层。在讨论以太网时，您经常会听到本地网络，第2层，L2，链路层和数据链路层等术语。
在以太网中，连接到网络的主机通过交换帧进行通信。以太网上的每个主机由称为媒体访问控制（MAC）地址的地址唯一地标识。特别地，OpenStack环境中的每个虚拟机实例都有唯一的MAC地址，这与计算主机的MAC地址不同。 MAC地址具有48位，通常表示为十六进制字符串，例如08：00：27：b9：88：74。 MAC地址由制造商硬编码到NIC中，虽然现代NIC允许您以编程方式更改MAC地址。在Linux中，可以使用ip命令检索NIC的MAC地址：

$ ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
     link/ether 08:00:27:b9:88:74 brd ff:ff:ff:ff:ff:ff

从概念上讲，您可以将以太网视为每个网络主机连接的单个总线。在早期实现中，以太网网络由主机将接入以连接到网络的单个同轴电缆组成。但是，现代以太网中的网络主机直接连接到称为交换机的网络设备。尽管如此，这个概念模型是有用的，在网络图（包括OpenStack仪表板生成的那些）中，以太网通常被描述为单个总线。有时您会听到一个以太网网络，称为第2层网段。
在以太网中，网络上的每个主机都可以直接向每个其他主机发送帧。以太网网络还支持广播，以便一个主机可以通过发送到特殊MAC地址ff：ff：ff：ff：ff：ff向网络上的每个主机发送帧。 ARP和DHCP是使用以太网广播的两个值得注意的协议。由于以太网网络支持广播，因此有时会听到称为广播域的以太网网络。
当NIC接收到以太网帧时，默认情况下，NIC检查目标MAC地址是否与NIC（或广播地址）的地址匹配，如果MAC地址不匹配，则丢弃以太网帧。对于计算主机，这种行为是不期望的，因为该帧可能用于一个实例。 NIC可以配置为混杂模式，即将所有以太网帧传递到操作系统，即使MAC地址不匹配。计算主机应始终具有为混杂模式配置的相应NIC。
如前所述，现代以太网网络使用交换机互连网络主机。交换机是一个具有大量端口的网络硬件盒，用于将以太网帧从一个连接的主机转发到另一个主机。当主机首先通过交换机发送帧时，交换机不知道哪个MAC地址与哪个端口相关联。如果以太网帧目的地是未知的MAC地址，交换机将广播该帧到所有端口。交换机通过观察流量来了解哪些MAC地址在哪些端口。一旦它知道哪个MAC地址与端口相关联，它可以发送以太网帧到正确的端口，而不是广播。交换机维护称为转发表或转发信息库（FIB）的表中的MAC地址到交换机端口的映射。交换机可以串接在一起，并且交换机和主机的最终连接行为像单个网络。

VLAN

VLAN是一种网络技术，使单个交换机能够像多个独立交换机一样工作。具体来说，连接到同一交换机但在不同VLAN上的两台主机不会看到对方的流量。 OpenStack能够利用VLAN来隔离不同项目的流量，即使项目碰巧在同一计算主机上运行实例也是如此。每个VLAN都有一个相关的数字ID，在1和4095之间。我们说“VLAN 15”指的是数字ID为15的VLAN。
要了解VLAN的工作原理，让我们考虑传统IT环境中的VLAN应用程序，其中物理主机连接到物理交换机，并且不涉及虚拟化。想象一下，你想要三个孤立的网络，但你只有一个物理交换机的场景。网络管理员将选择三个VLAN ID，例如10,11和12，并将配置交换机将交换机端口与VLAN ID相关联。例如，交换机端口2可以与VLAN 10相关联，交换机端口3可以与VLAN 11相关联，等等。当为特定VLAN配置交换机端口时，将其称为访问端口。交换机负责确保跨VLAN的网络流量隔离。
现在考虑第一交换机中的所有交换机端口被占用的情况，并且因此组织购买第二交换机并将其连接到第一交换机以扩展可用交换机端口数量。第二交换机还被配置为支持VLAN ID 10,11和12.现在假设在为VLAN ID 10配置的端口上连接到交换机1的主机A发送用于连接到交换机2的主机B的以太网帧在配置为VLAN ID 10.当交换机1将以太网帧转发到交换机2时，它必须传达该帧与VLAN ID 10相关联。
如果两个交换机要连接在一起，并且交换机配置为VLAN，则用于交叉连接的交换机端口必须配置为允许来自任何VLAN的以太网帧转发到另一个交换机。此外，发送交换机必须使用VLAN ID对每个以太网帧进行标记，以便接收交换机能够确保只有匹配VLAN上的主机才有资格接收该帧。
配置为从所有VLAN传递帧并使用VLAN ID对其标记的交换机端口称为中继端口。 IEEE 802.1Q是描述在使用中继时如何在以太网帧中编码VLAN标记的网络标准。
请注意，如果您在物理交换机上使用VLAN在OpenStack云中实现项目隔离，则必须确保所有交换端口都配置为中继端口。
请务必选择当前网络基础结构未使用的VLAN范围。例如，如果您估计云必须最多支持100个项目，请选择该值以外的VLAN范围，例如VLAN 200-299。 OpenStack和处理项目网络的所有物理网络基础设施必须支持此VLAN范围。
中继用于在不同交换机之间连接。每个中继使用标签来标识正在使用的VLAN。这确保同一VLAN上的交换机可以通信。

subnet和arp

虽然NIC使用MAC地址寻址网络主机，但TCP / IP应用程序使用IP地址。地址解析协议（ARP）通过将IP地址转换为MAC地址来桥接以太网和IP之间的差距。
IP地址分为两部分：网络号和主机标识符。如果两台主机具有相同的网络号，则它们位于同一子网上。回想一下，如果两个主机在同一个本地网络上，它们只能通过以太网直接通信。 ARP假定在同一子网中的所有计算机都在同一个本地网络上。网络管理员在为主机分配IP地址和网络掩码时必须小心，以使处于同一子网中的任何两台主机位于同一个本地网络上，否则ARP无法正常工作。
要计算IP地址的网络编号，您必须知道与该地址相关联的网络掩码。网络掩码指示32位IP地址中的多少位组成网络号。
有两种语法用于表达网络掩码：
- 点分表示法
- 无类域间路由（CIDR）
考虑IP地址为192.168.1.5，其中地址的前24位是网络号。在虚线四边形符号中，网络掩码将被写为255.255.255.0。 CIDR表示法包括IP地址和网络掩码，并且此示例将写为192.168.1.5/24。

创建包括多播地址或环回地址的CIDR子网不能在OpenStack环境中使用。 例如，不支持使用224.0.0.0/16或127.0.1.0/24创建子网。

有时我们要引用子网，但不是子网上的任何特定IP地址。一个常见的约定是将主机标识符设置为全零以引用子网。例如，如果主机的IP地址是10.10.53.24/16，那么我们会说子网是10.10.0.0/16。
要了解ARP如何将IP地址转换为MAC地址，请考虑以下示例。假设主机A具有IP地址192.168.1.5/24和MAC地址fc：99：47：49：d4：a0，并且想要向IP地址为192.168.1.7的主机B发送分组。注意，网络号对于两个主机是相同的，因此主机A能够直接发送帧到主机B.
第一次主机A尝试与主机B通信时，目标MAC地址未知。主机A向本地网络发出ARP请求。请求是一个广播，带有这样的消息：
收件人：大家（ff：ff：ff：ff：ff：ff）。我正在寻找有IP地址192.168.1.7的计算机。签名：MAC地址fc：99：47：49：d4：a0。
主机B以这样的响应进行响应：
To：fc：99：47：49：d4：a0。我有IP地址192.168.1.7。签名：MAC地址54：78：1a：86：00：a5。
然后主机A向主机B发送以太网帧。
您可以使用arping命令手动启动ARP请求。例如，要向IP地址10.30.0.132发送ARP请求：

$ arping -I eth0 10.30.0.132
ARPING 10.30.0.132 from 10.30.0.131 eth0
Unicast reply from 10.30.0.132 [54:78:1A:86:1C:0B]  0.670ms
Unicast reply from 10.30.0.132 [54:78:1A:86:1C:0B]  0.722ms
Unicast reply from 10.30.0.132 [54:78:1A:86:1C:0B]  0.723ms
Sent 3 probes (1 broadcast(s))
Received 3 response(s)

为了减少ARP请求的数量，操作系统维护一个ARP缓存，其中包含IP地址到MAC地址的映射。 在Linux机器上，可以使用arp命令查看ARP高速缓存的内容：

$ arp -n
Address   HWtype  HWaddress           Flags Mask  Iface
10.0.2.3  ether   52:54:00:12:35:03   C           eth0
10.0.2.2  ether   52:54:00:12:35:02   C           eth0

DHCP

连接到网络的主机使用动态主机配置协议（DHCP）动态获取IP地址。 DHCP服务器向网络主机（即DHCP客户端）分配IP地址。
DHCP客户端通过从端口68发送UDP数据包到端口67上的地址255.255.255.255来定位DHCP服务器。地址255.255.255.255是本地网络广播地址：本地网络上的所有主机都会看到发送到此地址的UDP数据包。然而，这样的分组不被转发到其他网络。因此，DHCP服务器必须位于与客户端相同的本地网络上，否则服务器将不会接收广播。 DHCP服务器通过从客户端上的端口67到端口68发送UDP数据包进行响应。交换看起来像这样：
客户端发送一个发现（“我是MAC地址为08：00：27：b9：88：74的客户端，我需要一个IP地址”）
服务器发送报价（“OK 08：00：27：b9：88：74，我提供IP地址10.10.0.112”）
客户端发送请求（“服务器10.10.0.131，我想有IP 10.10.0.112”）
服务器发送确认（“OK 08：00：27：b9：88：74，IP 10.10.0.112是您的”）
OpenStack使用第三方程序dnsmasq实现DHCP服务器。 Dnsmasq写入syslog，您可以在其中观察DHCP请求和回复：

Apr 23 15:53:46 c100-1 dhcpd: DHCPDISCOVER from 08:00:27:b9:88:74 via eth2
Apr 23 15:53:46 c100-1 dhcpd: DHCPOFFER on 10.10.0.112 to 08:00:27:b9:88:74 via eth2
Apr 23 15:53:48 c100-1 dhcpd: DHCPREQUEST for 10.10.0.112 (10.10.0.131) from 08:00:27:b9:88:74 via eth2
Apr 23 15:53:48 c100-1 dhcpd: DHCPACK on 10.10.0.112 to 08:00:27:b9:88:74 via eth2

当对通过网络无法访问的实例进行故障排除时，检查此日志以验证是否对所讨论的实例执行了DHCP协议的所有四个步骤会很有帮助。

IP

Internet协议（IP）指定如何在连接到不同本地网络的主机之间路由数据包。 IP依赖于称为路由器或网关的特殊网络主机。 路由器是连接到至少两个本地网络并且可以将IP分组从一个本地网络转发到另一个本地网络的主机。 路由器有多个IP地址：每个网络连接一个IP地址。
在网络协议的OSI模型中，IP占用第三层，称为网络层。 在讨论IP时，您经常会听到诸如第3层，L3和网络层之类的术语。
向IP地址发送分组的主机参考其路由表以确定该分组应该发送到的本地网络上的哪台机器。 路由表维护与主机直接连接到的每个本地网络相关联的子网的列表，以及在这些本地网络上的路由器的列表。
在Linux机器上，以下任何命令都显示路由表：

$ ip route show
$ route -n
$ netstat -rn

这里是ip route show的输出示例：

$ ip route show
default via 10.0.2.2 dev eth0
10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.15
192.168.27.0/24 dev eth1  proto kernel  scope link  src 192.168.27.100
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1

输出的第1行指定默认路由的位置，如果没有其他规则匹配，这是有效的路由规则。 与默认路由（10.0.2.2在上例中）相关联的路由器有时被称为默认网关。 DHCP服务器通常将默认网关的IP地址与客户端的IP地址和网络掩码一起发送到DHCP客户端。
输出的第2行指定10.0.2.0/24子网中的IP位于与网络接口eth0关联的本地网络上。
输出的第3行指定192.168.27.0/24子网中的IP位于与网络接口eth1关联的本地网络上。
输出的第4行指定192.168.122.0/24子网中的IP位于与网络接口virbr0关联的本地网络上。
路由的输出-n和netstat -rn命令以略有不同的方式格式化。 此示例显示如何使用这些命令格式化相同的路由：

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.0.2.2        0.0.0.0         UG        0 0          0 eth0
10.0.2.0        0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.27.0    0.0.0.0         255.255.255.0   U         0 0          0 eth1
192.168.122.0   0.0.0.0         255.255.255.0   U         0 0          0 virbr0

ip route get命令输出目的IP地址的路由。 从以下示例，目标IP地址10.0.2.14位于eth0的本地网络上，将直接发送：

$ ip route get 10.0.2.14
10.0.2.14 dev eth0  src 10.0.2.15

目标IP地址93.184.216.34不在任何连接的本地网络上，并将转发到默认网关10.0.2.2：

$ ip route get 93.184.216.34
93.184.216.34 via 10.0.2.2 dev eth0  src 10.0.2.15

通常，分组跨越多个路由器跳跃到达其最终目的地。 在Linux机器上，traceroute和更新的mtr程序打印出IP数据包沿着其路径到达其目的地所经过的每个路由器的IP地址。

TCP/UDP/ICMP

对于网络软件应用程序通过IP网络进行通信，它们必须使用在IP上层分层的协议。 这些协议占据被称为传输层或层4的OSI模型的第四层。参见由因特网号码分配机构（IANA）维护的协议编号网页，用于在IP及其相关联的数字上层的协议的列表。
传输控制协议（TCP）是网络应用中最常用的第4层协议。 TCP是面向连接的协议：它使用客户端 - 服务器模型，其中客户端连接到服务器，其中服务器引用接收连接的应用程序。 在基于TCP的应用中的典型交互进行如下：
1. 客户端连接到服务器。
2. 客户端和服务器交换数据。
3. 客户端或服务器断开连接。
因为网络主机可能运行多个基于TCP的应用程序，所以TCP使用称为端口的寻址方案来唯一地识别基于TCP的应用程序。 TCP端口与1-65535范围内的数字相关联，并且主机上只有一个应用程序可以与TCP端口一次关联，这是操作系统强制执行的限制。
TCP服务器被称为在端口上侦听。例如，SSH服务器通常侦听端口22.对于客户端使用TCP连接到服务器，客户端必须知道服务器主机的IP地址和服务器的TCP端口。
TCP客户端应用程序的操作系统自动为客户端分配端口号。客户端拥有此端口号，直到TCP连接终止，之后操作系统回收端口号。这些类型的端口被称为临时端口。
IANA维护许多基于TCP的服务的端口号的注册表，以及使用其他使用端口的第4层协议的服务。不需要注册TCP端口号，但注册端口号有助于避免与其他服务的冲突。
用于编写基于TCP的应用程序的最常见的应用程序编程接口（API）称为Berkeley套接字，也称为BSD套接字或简称为套接字。套接字API公开了面向流的接口，用于编写TCP应用程序。从程序员的角度来看，通过TCP连接发送数据类似于将字节流写入文件。操作系统的TCP / IP实现的责任是将数据流分解成IP分组。操作系统还负责自动重传丢弃的分组，并负责处理流控制，以确保传输的数据不会超越发送方的数据缓冲区，接收方的数据缓冲区和网络容量。最后，操作系统负责以正确的顺序将分组重组成接收方侧的数据流。因为TCP检测和重传丢失的数据包，所以它被认为是一个可靠的协议。
用户数据报协议（UDP）是另一个第4层协议，它是几种众所周知的网络协议的基础。 UDP是无连接协议：通过UDP通信的两个应用程序在交换数据之前不需要建立连接。 UDP也是一个不可靠的协议。操作系统不尝试重新传输或甚至检测丢失的UDP数据包。操作系统也不提供任何保证接收应用程序以与它们发送相同的顺序看到UDP分组。
UDP像TCP一样，使用端口的概念来区分在同一系统上运行的不同应用程序。 但请注意，操作系统将UDP端口与TCP端口分开处理。 例如，一个应用程序可能与TCP端口16543相关联，并且单独的应用程序可能与UDP端口16543相关联。
像TCP一样，套接字API是编写基于UDP的应用程序最常用的API。 套接字API提供了面向消息的接口，用于编写UDP应用程序：程序员通过传输固定大小的消息在UDP上发送数据。 如果应用程序需要丢失分组的重传或接收分组的明确排序，则程序员负责在应用代码中实现该功能。
DHCP，域名系统（DNS），网络时间协议（NTP）和虚拟可扩展局域网（VXLAN）是OpenStack部署中使用的基于UDP的协议的示例。
UDP支持一对多通信：向多个主机发送单个数据包。应用程序可以通过将接收方IP地址设置为特殊IP广播地址255.255.255.255，向本地网络上的所有网络主机广播UDP数据包。应用程序还可以使用IP多播将UDP数据包发送到一组接收器。预期的接收器应用程序通过将UDP套接字绑定到作为有效多播组地址之一的特殊IP地址来加入多播组。接收主机不必与发送方位于同一本地网络，但是干预路由器必须配置为支持IP组播路由。 VXLAN是使用IP组播的基于UDP协议的示例。
因特网控制消息协议（ICMP）是用于在IP网络上发送控制消息的协议。例如，如果在路由器的路由表中没有与目的地地址对应的路由，或者IP包对于路由器处理来说太大了，则接收IP分组的路由器可以将ICMP分组发送回源。ping和mtr Linux命令行工具是使用ICMP的网络实用程序的两个示例。