对LACP端口通道/接口组进行故障排除
适用场景
网络交换机
问题解答
什么是端口通道组?
端口通道组是一组聚合在一起的多个物理以太网端口、用于提高聚合吞吐量和/或提高网络故障恢复能力。它也称为EtherChannel、中继、端口捆绑包或LACP。电气和电子工程师协会(IEEE)为命名为802.3ad和802.3ad的端口通道组定义了标准、而端口通道组通常指交换机端配置、而NetApp则使用术语"interface groups / ifgrp
"或虚拟接口(VIF)的原有名称。NetApp端的接口组有三种形式。
-
SystemID:滞后中的每个成员将在其LACPDU中发送一个系统ID。存储器的所有成员端口都应发送相同的系统ID、以指示只有一个逻辑设备连接到交换机。同样、交换机的每个成员端口都应发送相同的系统ID。但是、交换机和存储器之间的系统ID应不同。
-
如果成员端口不发送相同的系统ID、则一方尝试聚合两个不同的逻辑设备、而LACP不支持这两个逻辑设备。例如、如果交换机上未配置虚拟端口通道(VPC)、Cisco Nexus跨交换机链路聚合组可能会发送两个不同的系统ID。使用VPC配置链路聚合组会指示每个交换机发送相同的系统ID。
-
注意:请参见下面的ifconfig -a示例、其中显示了不匹配的系统ID
-
-
- 单模式:无交换机端配置、仅主动/被动、不是端口通道组
- 多模式:一个"静态"端口通道组。存储控制器和交换机使用一定数量的端口进行硬编码、这些端口始终是端口通道组的成员。它不如Multimode_LACP最佳、因为存储控制器和交换机无法阻止单个端口加入端口通道组、除非端口脱机(例如:未插入缆线)。
如果配置了此类型端口通道组的设备布线不正确、则"静态"多模式端口通道组也不会意识到布线错误、并会使用所有端口进行传输。然后、您应看到交换机报告的CAM表摆动("AC摆动")。此外、如果建立网络连接、则会出现非常不一致的情况。
注意:交换机管理员可能会将静态端口通道组称为LACP、但"静态"多模式ifgrp或端口通道组不使用LACP协议、并且这两个术语不能互换使用。
Multimode_LACP
:一种端口通道组模式、允许两个网络设备(例如交换机和NetApp存储控制器)进行通信并比较端口状态和参数。由于LACP是指两个端口之间的通信(例如、服务器或客户端上的NIC端口及其所插入的交换机端口)、因此LACP能够确认这两个设备之间的通信成功。它允许任何参与者决定是否应使用端口通道组中的每个物理端口。这一点优于"静态"多模式端口通道组、因为它只能检测到某些与已拔出端口或完全出现故障的端口无关的情况。ONTAP 要求每个端口通道只能有一个系统ID、并且不能跨多个交换机。
LACP端口中有两个"节点"操作: - 活动LACP端口始终参与LACP协商。如果未将相邻设备(缆线的另一端)中的接口配置为使用LACP (主动或被动)、则此端口将被禁用。
- 如果缆线另一端的设备通过发送LACP控制数据包启动、则允许被动LACP端口参与LACP协商。
- 所有NetApp存储控制器始终在"活动LACP"模式下运行。这是不可配置的。
LACP将在任意给定时间按以下两个"时间"之一运行: - "低计时器"每30秒交换一次LACP控制数据包。
- "快速计时器"每1秒交换一次LACP控制数据包。
- 在端口最初启动时、大多数设备都会使用"快速计时器"。此外、在正确协商LACP并启动端口以供使用后、LACP预计很快就会移至"低计时器"。
在多种情况下、LACP可以禁用端口通道的成员。 - 如果网络设备停止从另一设备接收更新、则此端口最终将被禁用。此操作最多需要90秒(可能更短)。
- 如果网络设备从相邻设备接收更新、但该更新包含不正确的信息、则网络设备可以禁用此端口。这将检测到布线不当的系统、并且可能会在90秒内发生。
- 如果网络设备收到指示相邻端口不可用的更新、则应在收到LACP控制数据包后立即禁用此端口。
- 在某些情况下、设置为"被动"的交换机将无法与存储控制器正确协商、即使存储控制器默认设置为"主动"也是如此。
- 在某些情况下、当存储控制器移动时、交换机可能不会移动到"低计时器"。这可能会阻止LACP将端口投入使用。
注意:LACP只能确认两个相邻设备(例如:NIC和交换机)之间直接通信。LACP不会检测到任何其他故障、例如路由故障或交换机中断、这些故障不会影响此端口。
谁创建端口通道组?
存储架构师和网络管理员必须协同工作、以确保其端口通道组配置正确。如果未执行此集体验证、则网络基础架构可能会面临风险。
为什么要了解端口通道组并对其进行故障排除?
端口通道组配置不当的常见症状包括:间歇性连接、数据包丢失、意外丢失冗余和"不稳定"网络连接。最好确保为稳定可靠的存储基础架构100%配置端口通道组。
以下是端口通道组配置不当的常见原因:
- 网络交换机配置不正确。
- 存储控制器NIC的缆线连接到错误的网络交换机端口。
- 在存储控制器上的ifgrp配置中指定的端口不正确。
- 布线或硬件问题描述 和/或以太网缆线或交换机端口/模块损坏。
- 在某些环境中、可能需要将交换机配置为仅使用"计时器"和"活动LACP"
如何对LACP端口通道组进行故障排除?
本节介绍在对存储架构师的LACP端口通道组进行故障排除时应遵循的操作步骤 :查看接口组状态输出或ifgrp status
。如果ifgrp status
输出不正确、则需要进行一些更正。
对于ONTAP 9.2及更高版本、请考虑利用以下知识库获取故障排除帮助:
How to Troubleshoot LACP issues with "ifconfig -v" in ONTAP 9.2+
请考虑以下情形:
场景1—端口关闭
-------- IFGRP-STATUS --------
default: transmit 'IP Load balancing', Ifgrp Type 'multi_mode', fail 'log'
corp_lag1: 1 link, transmit 'IP Load balancing', Ifgrp Type 'lacp' fail 'default'
Ifgrp Status Up Addr_set
trunked: corp_ifgrp
up:
e13a: state up, since 26Feb2013 05:18:14 (4+19:01:01)
mediatype: auto-10g_sr-fd-up
flags: enabled
active aggr, aggr port: e13a
input packets 2965338456, input bytes 11151446739454
input lacp packets 13811, output lacp packets 414063
output packets 2518851712, output bytes 22373630536977
up indications 3, broken indications 0
drops (if) 0, drops (link) 0
indication: up at 26Feb2013 05:18:14
consecutive 0, transitions 3
broken:
e7a: state broken, since 26Feb2013 15:23:49 (4+08:55:26)
mediatype: auto-10g_sr-fd-down
flags: lacp enabled
input packets 0, input bytes 0
input lacp packets 1218, output lacp packets 36343
output packets 0, output bytes 0
up indications 4, broken indications 2
drops (if) 0, drops (link) 67
indication: broken at 26Feb2013 15:23:49
consecutive 0, transitions 6
以下示例显示了一个端口通道组、其中一个端口工作正常、一个端口实际关闭。此时将显示正在工作的端口active aggr
、这意味着它正在成功参与链路聚合。在 e7a
本示例中、端口上的"断开状态"指示表示端口中未插入任何缆线。
场景2—端口布线错误
corp_lag1: 1 link, transmit 'IP Load balancing', Ifgrp Type 'lacp' fail 'default'
Ifgrp Status Up Addr_set
trunked: corp_ifgrp
up:
e13a: state up, since 22Jan2013 15:07:01 (18+09:17:13)
mediatype: auto-10g_sr-fd-up
flags: enabled
active aggr, aggr port: e13a
input packets 18140836964, input bytes 52796851685561
input lacp packets 211121, output lacp packets 6332475
output packets 15346936943, output bytes 168979152263131
up indications 21, broken indications 9
drops (if) 0, drops (link) 0
indication: up at 22Jan2013 15:07:01
consecutive 0, transitions 30
lag_inactive:
e7a: state lag_inactive, since 22Jan2013 15:06:39 (18+09:17:35)
mediatype: auto-10g_sr-fd-up
flags: lacp enabled
input packets 582405, input bytes 1193956618
input lacp packets 211095, output lacp packets 6355756
output packets 19089029, output bytes 13102456660
up indications 15, broken indications 7
drops (if) 0, drops (link) 0
indication: lag_inactive at 22Jan2013 15:06:39
consecutive 0, transitions 22
此处的配置相同;但是e7a
、显示LAG_INACTIVE
的不是"已断开"。这表示存储控制器和交换机尚未就与LACP相关的内容达成一致。存储控制器确定LACP不支持使用此端口后、此链路将标记为lag_inactive、表示此链路在"滞后"(链路聚合组)中不是"活动"。这种情况的最终结果是e7a
、Data ONTAP 不会使用端口来传输流量、从而强制所有流量使用端口e13a
。因此、不再存在冗余、故障恢复能力和潜在的吞吐量提升。如果端口e13a
也变为lag_inactive
(对于前面提到的任何触发ifgrp
条件)、则此端口将移至非活动或脱机状态、并且任何方向都不允许任何流量。
在这种情况下、可以通过监控"输入LACP数据包"和"输出LACP数据包"计数器来收集有关发生原因 的线索:
"输入LACP数据包"计数器可监控从交换机收到的LACP控制/协商数据包数量。如果不增加、则意味着交换机可能不发送LACP数据包、或者硬件丢弃收到的所有数据包。如果为交换机配置了"静态"多模式ifgrp
、则不会看到此计数器递增。
"输出LACP数据包"计数器可监控存储控制器发送的LACP控制/协商数据包的数量。如果端口处于"已断开"以外的任何状态、则此值应始终递增
场景3—已正确配置LACP ifgrp
这两个端口都具有active aggr
(忽略aggr端口部分)。不应提及lag_inactive
。
此配置类似于以下内容:
corp_lag2: 2 links, transmit 'IP Load balancing', Ifgrp Type 'lacp' fail 'default'
Ifgrp Status Up Addr_set
trunked: corp_ifgrp
up:
e7b: state up, since 26Feb2013 04:58:05 (4+19:12:27)
mediatype: auto-10g_sr-fd-up
flags: enabled
active aggr, aggr port: e13b
input packets 9493, input bytes 1177132
input lacp packets 13831, output lacp packets 415997
output packets 617618727, output bytes 2908794789546
up indications 3, broken indications 0
drops (if) 0, drops (link) 0
indication: up at 26Feb2013 04:58:05
consecutive 0, transitions 3
e13b: state up, since 26Feb2013 04:58:04 (4+19:12:28)
mediatype: auto-10g_sr-fd-up
flags: enabled
active aggr, aggr port: e13b
input packets 9494, input bytes 1177256
input lacp packets 13830, output lacp packets 414747
output packets 505651519, output bytes 4117402075645
up indications 3, broken indications 0
drops (if) 0, drops (link) 0
indication: up at 26Feb2013 04:58:04
consecutive 0, transitions 3
在这种状态下、两个端口均列为"已启用"、并且"输入LACP数据包"和"输出LACP数据包"计数器应每30秒至少增加一个。
有关LACP端口通道组配置的最佳实践、请参见技术报告TR-3802;例如、Cisco Nexus交换机上的语法。确保了解NetApp存储控制器所连接的端口、以验证第1层是否符合预期。使用Data ONTAP 的Cisco发现协议(CDP)功能有助于进行此验证。
node1> options cdpd.enabled on
最多等待60分钟、LLDP轮询间隔才能成功完成。
node1> CDPD show-neighbors
对于集群模式Data ONTAP :
Cluster01::> node run -node Node1 options cdpd.enable on
Cluster01::> node run -node Node1 cdpd show-neighbors
注意:对于当前的Cisco实施方案、请考虑在vpc peer-gateway’
端口通道配置上添加‘设置、以确保与NetApp FastPath配置的最大兼容性(在7-模式和CDOT中默认为ON)。此VPC对等网关声明适用于7000系列交换机的NX-OS 4.2.1和5500系列交换机的NX-OS 5.0 (3) N1 (1)版。有关详细信息、请参见无法 通过启用了ip.fastpath 的 Cisco Nexus vPC发送网络流量 知识库。
追加信息
ifconfig -V中的"bad"和"good "系统ID信息示例:(ONTAP 9.2+)
请注意"滞后ID"相对于 3C-13-CC-6F-D8-08...在"lagport"下的每个分段上、此值应相同。 例如、当查看e0f (关闭端口)时、它会显示80-2D-BF-3A-A4-7F...此值应与"滞后ID"下列出的值相同- 3C-13-CC-6F-D8-08。 "lagport:e0e"显示正确的系统ID - 3C-13-CC-6F-D8-08
a0a: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000
options=6407bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
ether d2:39:ea:21:e8:f4
laggproto lacp lagghash l3
lagg options:
flags=1<USE_FLOWID>
flowid_shift: 16
lagg statistics:
active ports: 3
flapping: 0
lag id: [(8000,D2-39-EA-21-E8-F4,0032,0000,0000),
~~> (8000,3C-13-CC-6F-D8-08,0001,0000,0000)]
laggport: e0f flags=18<COLLECTING,DISTRIBUTING> state=3d<ACTIVITY,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
[(8000,D2-39-EA-21-E8-F4,0032,8000,0003),
~~> (8000,80-2D-BF-3A-A4-7F,0001,8000,0108)]
input/output LACPDUs: 13743 / 80819
laggport: e0e flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> state=3d<ACTIVITY,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
[(8000,D2-39-EA-21-E8-F4,0032,8000,0004),
~~> (8000,3C-13-CC-6F-D8-08,0001,8000,0108)]
input/output LACPDUs: 13743 / 80789
客户更正了vPC设置后、这些系统ID将匹配
注意:下面的命令也可用于获取LACP的状态(ONTAP 9.2+)
::> node run -node <node> -command ifconfig -v