《NX-OS与Cisco Nexus交换技术：下一代数据中心架构（第2版）》2.5 端口通道

2.5　端口通道

NX-OS与Cisco Nexus交换技术：下一代数据中心架构（第2版）

    从生成树的角度来看，两台交换机之间存在多条链路时，通常都倾向于将这些链路视为一条链路。这类逻辑绑定的好处是这些冗余的物理连接不会被生成树阻塞，因而能够为数据流量提供更大的可用带宽。端口通道（Port-Channel）也能创造一定程度的冗余性，因为端口通道中的某条物理链路出现故障后不会导致生成树的重新收敛。Nexus 7000最多可以将8条链路聚合成一个端口通道。为了实现性能优化，建议链路数量为2的整数次幂（如2条、4条或8条链路）。端口通道的成员可以位于同一块线卡上，也可以出于线卡故障保护的目的而分布到系统中的多个模块上。端口通道通过不同的算法对到达的数据帧进行哈希计算，并通过多个物理接口进行流量的负载均衡。其中，同一个流的数据帧会始终被哈希到同一个物理接口。有关端口通道的一个常见错误概念就是误以为逻辑接口是20/40/80-Gbit/s链路，但是，对于10Gbit/s的成员链路来说，没有单个流能够超过成员物理链路的传输速率。打个比方，虽然端口通道为高速公路增加了一条车道，但并没有增加该高速公路的速度限制。在实际应用中，可以根据需求将端口通道配置为二层链路或三层链路。

用户可以对通过多条链路实现流量负载均衡的哈希方法进行配置，Nexus 7000提供了以下配置选项：

• 源IP；
• 目的IP；
• 源MAC；
• 目的MAC；
• 源端口；
• 目的端口；
• 源和目的IP；
• 源和目的MAC；
• 源和目的端口。

可以采取全局模式配置上述选项参数，当然，考虑到Nexus 7000的分布式特性，也能以每块线卡为基础进行逐一配置。如果部署了VDC，那么就要在默认VDC中定义这些参数。

例2-62显示了配置和验证负载均衡算法的方式。

例2-62 端口通道负载均衡算法

2.5.1 为端口通道分配物理端口

可以采取以下两种方式将成员端口分配到逻辑接口中。

配置成员链路以运行行业标准的802.3ad LACP（Link Aggregation Control Protocol，链路聚合控制协议）。

    将端口静态配置为端口通道的成员。如果使用了该模式，那么设备之间就不再交换聚合协议信息。

    具体使用哪种模式没有对错之分，完全取决于个人喜好。有些管理员可能希望网络环境是确定性的，因而喜欢使用静态配置模式，而其他管理员则可能希望使用LACP提供的一些增强型功能。LACP的一个好处是能够实现一定程度的安全防护，可以防止端口因偶然配置错误而成为端口通道的成员，从而形成二层环路或数据流量黑洞。这种保护能力在虚拟端口通道配置中非常有用。有关虚拟通道配置的详细信息将在本章后面讨论。

命令channel-group负责关联成员接口与端口通道。如果应用于接口的现有配置与端口通道不兼容，那么端口通道可能会经常拒绝channel-group命令，此时可以通过添加force命令来确保端口通道的兼容性。

如果希望在不使用LACP的情况下将物理端口分配给端口通道，那么就可以使用以下命令：

由于LACP是NX-OS中的模块化进程，因而必须在配置之前显式启用LACP特性。该操作可以通过feature命令来完成。

启用了LACP之后，就可以通过以下两种模式将端口协商进端口通道。

主动（Active）模式：该模式通过发送LACP包主动协商通道的成员关系。

    被动（Passive）模式：**该模式侦听LACP包并加以响应，但是不会发送LACP协商包。

    对于两台设备之间的绑定链路来说，必须将端口配置为主动/主动模式或主动/被动模式。如果将链路两侧都配置为被动模式，那么将无法绑定该链路。

例2-63显示了使用LACP将物理端口分配给端口通道的配置方式。

例2-63 LACP配置

为了确保该成员端口与端口通道的兼容性，必须在协商阶段验证许多兼容性参数。

例2-64显示了端口绑定时必须匹配的兼容性参数。

例2-64 端口通道兼容性

例2-65使用命令show port-channel summary快速验证了端口通道的配置情况。

例2-65 验证LACP

由于逻辑接口参数会应用于所有成员链路，因而这种方式为管理员控制多个端口提供了一种非常简便的配置方法。

注意：对于IOS设备来说，端口通道接口最初会被管理性地置于不可用状态，而对于最新的NX-OS来说，端口通道在创建之初就处于活动状态。

2.5.2 端口通道的流控制

端口通道上的接口也支持流控制功能。为了保证流控制操作的正确性，必须在端口通道的双端进行必要的配置。端口通道默认是优先启用流控制功能。也可以通过静态配置方式开启或关闭每个方向的流控制功能。

例2-66显示了配置和验证端口通道流控制功能的方式。

例2-66 端口通道流控制

2.5.3 验证端口通道的负载分发

很多原因都可能会导致多个物理端口之间出现非等价流量分发，如配置了次优负载均衡算法或者链路条数不是2的整数次幂（如3条）。因而一种好的处理方式是，经常验证流量是否在所有可用成员上实现了负载均衡。此时，可以利用命令show port-channel traffic。该命令能够快速获取这些统计信息的快照。该命令的输出结果如例2-67所示。

例2-67 验证负载分发

从例2-67的输出结果可以看出，第一条命令显示了每条成员链路所分配的哈希桶（hash buckets）数量，第二条命令显示了每条链路转发的流量占比。在进行端口通道的故障排查时，一个额外任务就是要确定特定流将会被哈希到哪条链路上，利用命令show portchannel loadbalance forwarding-path即可收集这方面的信息（如例2-68所示）。

例2-68 确定特定流将要使用哪条链路

根据所使用的哈希算法，通过指定所需的输入值即可发现，来自172.16.30.25且去往192.168.10.236的流量将由Ethernet1/17进行转发，而去往172.168.10.235的流量则选择由Ethernet2/17进行转发。

免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删