红帽全球峰会第 6 章 对供应商网络进行故障排除
在开始看来，使用虚拟路由器和交换机（也被称为软件定义的网络，简称 SDN）会使网络系统变得复杂。实际上，对 OpenStack Networking 中的连接进行故障排除的过程和对物理网络进行故障排除的方法非常相似。虚拟基础架构可以看做为物理网络的一个主干扩展，而不是一个完全独立的环境。
6.1. 故障排除的方法
- 基本的 ping 测试
- 对 VLAN 网络进行故障排除
- 从租户网络内进行故障排除
6.2. 基本的 ping 测试
ping 命令是一个非常有用的分析网络连接问题的工具。使用它可以获得基本的网络连接状态，但无法排除所有的连接问题，如防火墙阻止的特定应用程序的连接。ping 命令的工作流程是，向指定的地址发送数据，然后输出这个操作是否成功作为结果。
ping 命令需要 ICMP 网络流量可以通过所有相关的防火墙。
从有网络连接问题的系统上运行 ping 命令进行测试非常有必要。因此，当一个系统看起来已完全没有网络连接时，需要可以通过 VNC 管理控制台连接到系统的命令行以便运行 ping 命令。
例如，下面的 ping 测试命令验证了网络可以正常工作所需的多个网络层的功能（域名解析功能、IP 路由功能和网络交换功能）：
$ ping www.redhat.com PING e1890.b.akamaiedge.net (125.56.247.214) 56(84) bytes of data. 64 bytes from a125-56.247-214.deploy.akamaitechnologies.com (125.56.247.214): icmp_seq=1 ttl=54 time=13.4 ms 64 bytes from a125-56.247-214.deploy.akamaitechnologies.com (125.56.247.214): icmp_seq=2 ttl=54 time=13.5 ms 64 bytes from a125-56.247-214.deploy.akamaitechnologies.com (125.56.247.214): icmp_seq=3 ttl=54 time=13.4 ms ^C
在获得了所需的结果后，您可以使用 Ctrl-c 中断 ping 命令。如果命令输出中的数据包丢失（packet loss）值是 0，则说明网络连接处于正常状态：
--- e1890.b.akamaiedge.net ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 13.461/13.498/13.541/0.100 ms
另外，根据测试的目标，从 ping 测试的结果中可以发现造成网络问题的原因。例如，在以下的图例中，VM1 有一些网络连接问题。其中以红色数字标识的位置是 ping 测试的目的地址：
1. internet - 一个常见的做法是首先 ping 一个 internet 地址，如 www.redhat.com。
- Success：这意味着，所有中间的网络端点都可以正常工作，包括虚拟网络和物理网络系统。
- Failure：多种原因都可以造成 ping 一个 internet 地址失败。如果网络中的其它系统可以成功 ping 到 internet，则说明 internet 本身的连接是正常的，您需要进一步对本地网络系统进行检查。
2. Physical（物理）路由器 - 被网络管理员设置为处理向外部地址发送数据的路由器。
- Success：ping 默认网关可以显示本地网络以及所依赖的底层网络交换是否可以正常工作。因为它们中的数据包还没有到达路由器，所以无法说明默认网关是否有路由问题。
- Failure：这说明 VM1 和默认网关之间的连接有问题。路由器/交换机可能出现问题，或您使用了一个错误的网关。您可以把有问题的系统的设置和其它可以正常工作的系统上的配置进行比较。尝试 ping 本地网络中的其它服务器。
3. Neutron 路由 - 这是一个 RHEL OpenStack 用来处理虚拟机网络数据的虚拟 SDN（软件定义的网络）.
- Success：防火墙允许 ICMP 数据，Networking 节点在线。
- Failure：确认实例的安全组是否允许 ICMP 数据。检查 Networking 节点是否在线，所有需要的服务是否都在运行。
4. 物理交换机 - 物理交换机被用来管理相同物理网络中的节点间的通讯。
- Success：虚拟机发送到物理交换机的数据需要通过虚拟网络系统。如果 ping 命令成功，则意味着这一段的网络在正常工作。
- Failure：物理交换机端口是否被配置为处理相关的 VLAN？
5. VM2 - 尝试 ping 同一个子网中的同一个 Compute 节点上的虚拟机。
- Success：VM1 上的 NIC 驱动和基本的 IP 配置可以正常工作。
- Failure：检查 VM1 上的网络配置。也可能是 VM2 上的防火墙配置阻塞了 ping 的数据。
6.3. 对 VLAN 网络进行故障排除
OpenStack Networking 可以通过 SDN 交换机进行 VLAN 网络的端口汇聚（trunk）。对 VLAN-tagged 供应商网络的支持意味着虚拟实例可以在物理网络中和服务器子网进行集成。
为了对一个 VLAN 供应商网络的连接性进行故障排除，尝试 ping 在创建网络时指定的网关 IP。例如，您使用以下命令创建了网络：
# neutron net-create provider --provider:network_type=vlan --provider:physical_network=phy-eno1 --provider:segmentation_id=120 --router:external=True # neutron subnet-create "provider" --allocation-pool start=192.168.120.1,end=192.168.120.253 --disable-dhcp --gateway 192.168.120.254 192.168.120.0/24
您可以尝试 ping 其中的网关 IP - 192.168.120.254
如果失败，请确认您是否正确配置了与 VLAN 相关的网络设置（在创建网络时定义）。在上面的例子中，OpenStack Networking 被定义为把 VLAN 120 端口汇聚（trunk）到供应商网络。这个选项通过 --provider:segmentation_id=120 参数设置。
检查网桥接口（在这里，它的名称是 br-ex） 上的 VLAN 网络流设置：
# ovs-ofctl dump-flows br-ex NXST_FLOW reply (xid=0x4): cookie=0x0, duration=987.521s, table=0, n_packets=67897, n_bytes=14065247, idle_age=0, priority=1 actions=NORMAL cookie=0x0, duration=986.979s, table=0, n_packets=8, n_bytes=648, idle_age=977, priority=2,in_port=12 actions=drop
6.3.1. 查看 VLAN 配置和日志文件
- OpenStack Networking（neutron）agent - 使用 neutron 命令验证所有 agent 都在运行，并以正确的名称注册：
# neutron agent-list +--------------------------------------+--------------------+-----------------------+-------+----------------+ | id | agent_type | host | alive | admin_state_up | +--------------------------------------+--------------------+-----------------------+-------+----------------+ | a08397a8-6600-437d-9013-b2c5b3730c0c | Metadata agent | rhelosp.example.com | :-) | True | | a5153cd2-5881-4fc8-b0ad-be0c97734e6a | L3 agent | rhelosp.example.com | :-) | True | | b54f0be7-c555-43da-ad19-5593a075ddf0 | DHCP agent | rhelosp.example.com | :-) | True | | d2be3cb0-4010-4458-b459-c5eb0d4d354b | Open vSwitch agent | rhelosp.example.com | :-) | True | +--------------------------------------+--------------------+-----------------------+-------+----------------+
- 检查 /var/log/neutron/openvswitch-agent.log - 这个日志应该显示，创建的过程使用 ovs-ofctl 命令来配置 VLAN 端口汇聚功能（VLAN trunking）。
- 检查 /etc/neutron/l3_agent.ini 文件中的 external_network_bridge 设置。如果它是一个“硬代码”值，则无法通过 L3-agent 使用供应商网络，也无法创建所需的网络流程。
- 检查 /etc/neutron/plugin.ini 文件中 network_vlan_ranges 的值。如果它是一个供应商网络，则不需要指定 VLAN ID。只有在您使用 VLAN 隔离租户网络时才需要指定 ID。
6.4. 从租户网络内进行故障排除
在 OpenStack Networking 中，所有网络流量都会被限制在网络命名空间内。这样，租户就可以在不相互影响的情况下进行网络配置。例如，网络命名空间允许不同租户都使用192.168.1.1/24 作为子网范围，而不会相互影响。
为了对租户网络进行故障排除，首先需要决定网络包括在哪个命名空间中：
1. 使用 neutron 命令列出所有租户网络：
# neutron net-list +--------------------------------------+-------------+-------------------------------------------------------+ | id | name | subnets | +--------------------------------------+-------------+-------------------------------------------------------+ | 9cb32fe0-d7fb-432c-b116-f483c6497b08 | web-servers | 453d6769-fcde-4796-a205-66ee01680bba 192.168.212.0/24 | | a0cc8cdd-575f-4788-a3e3-5df8c6d0dd81 | private | c1e58160-707f-44a7-bf94-8694f29e74d3 10.0.0.0/24 | | baadd774-87e9-4e97-a055-326bb422b29b | private | 340c58e1-7fe7-4cf2-96a7-96a0a4ff3231 192.168.200.0/24 | | 24ba3a36-5645-4f46-be47-f6af2a7d8af2 | public | 35f3d2cb-6e4b-4527-a932-952a395c4bb3 172.24.4.224/28 | +--------------------------------------+-------------+-------------------------------------------------------+
在这个例子中，我们将检查 web-servers 网络。记录下 web-server 行中 id 值（这里是 9cb32fe0-d7fb-432c-b116-f483c6497b08）。在下一步的输出中，可以看到这个值被附加到一个网络命名空间名的后面。
2. 使用 ip 命令列出所有网络命名空间：
# ip netns list qdhcp-9cb32fe0-d7fb-432c-b116-f483c6497b08 qrouter-31680a1c-9b3e-4906-bd69-cb39ed5faa01 qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b qdhcp-a0cc8cdd-575f-4788-a3e3-5df8c6d0dd81 qrouter-e9281608-52a6-4576-86a6-92955df46f56
在结果中，一个命名空间与 web-server 网络 id 匹配。它由 qdhcp-9cb32fe0-d7fb-432c-b116-f483c6497b08 代表。
3. 在命名空间中运行命令来检查 web-servers 网络的配置。您需要在故障排除命令前加上 ip netns exec (namespace)。例如：
a) 查看 web-servers 网络的路由表：
# ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 172.24.4.225 0.0.0.0 UG 0 0 0 qg-8d128f89-87 172.24.4.224 0.0.0.0 255.255.255.240 U 0 0 0 qg-8d128f89-87 192.168.200.0 0.0.0.0 255.255.255.0 U 0 0 0 qr-8efd6357-96
b) 查看 web-servers 网络的路由表：
# ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 172.24.4.225 0.0.0.0 UG 0 0 0 qg-8d128f89-87 172.24.4.224 0.0.0.0 255.255.255.240 U 0 0 0 qg-8d128f89-87 192.168.200.0 0.0.0.0 255.255.255.0 U 0 0 0 qr-8efd6357-96
6.4.1. 在命名空间内执行高级的 ICMP 测试
1. 使用 tcpdump 命令获取 ICMP 网络流量。
# ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b tcpdump -qnntpi any icmp
在执行下一步前，可能没有输出：
2. 在一个独立的命令行窗口中运行一个到外部网络的 ping 测试命令：
# ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b ping www.redhat.com
3. 在运行 tcpdump 的终端中检查 ping 测试的结果详情。
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
IP (tos 0xc0, ttl 64, id 55447, offset 0, flags [none], proto ICMP (1), length 88)
172.24.4.228 > 172.24.4.228: ICMP host 192.168.200.20 unreachable, length 68
IP (tos 0x0, ttl 64, id 22976, offset 0, flags [DF], proto UDP (17), length 60)
172.24.4.228.40278 > 192.168.200.21: [bad udp cksum 0xfa7b -> 0xe235!] UDP, length 32在对网络数据进行 tcpdump 分析时，您可能会发现返回的数据包会发送到路由器接口，而不是实例。这是一个正常的行为，因为 qrouter 会在返回的数据包上执行 DNAT。
