☰

Intel NIC E810-C 불안정한 연결 - 문제 해결 방법

tag-icon • tag-icon debian network-interface
Intel NIC E810-C 불안정한 연결 - 문제 해결 방법

이것은 이전 질문에 이어집니다.네트워크 카드가 불안정합니다. 문제를 해결하는 방법은 무엇입니까?. 네트워크 카드는 다음과 같습니다.

# networkctl -a status
...
● 4: ens6f0                                                                                             
                     Link File: /usr/lib/systemd/network/99-default.link
                  Network File: n/a
                          Type: ether
                         State: n/a (unmanaged)
             Alternative Names: enp24s0f0
                          Path: pci-0000:18:00.0
                        Driver: ice
                        Vendor: Intel Corporation
                         Model: Ethernet Controller E810-C for QSFP (Ethernet Network Adapter E810-C-Q2)
                    HW Address: 64:9d:99:ff:fe:c0 (FS COM INC)
                           MTU: 1500 (min: 68, max: 9702)
                         QDisc: mq
  IPv6 Address Generation Mode: eui64
          Queue Length (Tx/Rx): 320/320
              Auto negotiation: no
                         Speed: 100Gbps
                        Duplex: full
                          Port: fibre
                       Address: 192.168.50.7
                                fe80::669d:99ff:feff:fec0
                       Gateway: 192.168.50.1 (TP-LINK TECHNOLOGIES CO.,LTD.)
Failed to query link DHCP leases: Unit dbus-org.freedesktop.network1.service not found.

운영 체제는 다음과 같습니다.

# cat /etc/*release*
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

마더보드는 다음과 같습니다.

# dmidecode -t baseboard
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
        Manufacturer: Supermicro
        Product Name: X12SPL-F
        Version: 2.00
        Serial Number: ZM224S007191
        Asset Tag: Base Board Asset Tag
        Features:
                Board is a hosting board
                Board is replaceable
        Location In Chassis: Part Component
        Chassis Handle: 0x0003
        Type: Motherboard
        Contained Object Handles: 0

NIC는 유일한 16레인 슬롯에 있습니다.

Handle 0x000F, DMI type 9, 17 bytes
System Slot Information
        Designation: CPU SLOT6 PCI-E 4.0 X16
        Type: x16 PCI Express 4 x16
        Current Usage: In Use
        Length: Long
        ID: 6
        Characteristics:
                3.3 V is provided
                Opening is shared
                PME signal is supported
        Bus Address: 0000:18:00.0

제가 겪고 있는 문제는 뚜렷한 이유 없이 네트워크 카드가 계속 떨어지고 어떻게 해결해야 할지 모른다는 것입니다. 지금까지 내가 가진 것은 다음과 같습니다 dmesg.

# dmesg | grep 0000:18:00.0

[    0.754043] pci 0000:18:00.0: [8086:1592] type 00 class 0x020000
[    0.754056] pci 0000:18:00.0: reg 0x10: [mem 0x201ffa000000-0x201ffbffffff 64bit pref]
[    0.754070] pci 0000:18:00.0: reg 0x1c: [mem 0x201ffe010000-0x201ffe01ffff 64bit pref]
[    0.754080] pci 0000:18:00.0: reg 0x30: [mem 0xbb600000-0xbb6fffff pref]
[    0.754166] pci 0000:18:00.0: reg 0x184: [mem 0x201ffd000000-0x201ffd01ffff 64bit pref]
[    0.754168] pci 0000:18:00.0: VF(n) BAR0 space: [mem 0x201ffd000000-0x201ffdffffff 64bit pref] (contains BAR0 for 128 VFs)
[    0.754179] pci 0000:18:00.0: reg 0x190: [mem 0x201ffe220000-0x201ffe223fff 64bit pref]
[    0.754180] pci 0000:18:00.0: VF(n) BAR3 space: [mem 0x201ffe220000-0x201ffe41ffff 64bit pref] (contains BAR3 for 128 VFs)
[    0.754429] pci 0000:18:00.0: 126.016 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x16 link at 0000:17:02.0 (capable of 252.048 Gb/s with 16.0 GT/s PCIe x16 link)
[    0.800984] pci 0000:18:00.0: CLS mismatch (64 != 32), using 64 bytes
[    1.369098] pci 0000:18:00.0: Adding to iommu group 31
[    1.819150] ice 0000:18:00.0: firmware: failed to load intel/ice/ddp/ice-e20070ffffd99fd0.pkg (-2)
[    1.819589] ice 0000:18:00.0: firmware: direct-loading firmware intel/ice/ddp/ice.pkg
[    2.140744] ice 0000:18:00.0: The DDP package was successfully loaded: ICE OS Default Package version 1.3.30.0
[    2.211858] ice 0000:18:00.0: PTP init successful
[    2.616387] ice 0000:18:00.0: DCB is enabled in the hardware, max number of TCs supported on this port are 8
[    2.616387] ice 0000:18:00.0: FW LLDP is disabled, DCBx/LLDP in SW mode.
[    2.616492] ice 0000:18:00.0: Commit DCB Configuration to the hardware
[    2.618380] ice 0000:18:00.0: 126.016 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x16 link at 0000:17:02.0 (capable of 252.048 Gb/s with 16.0 GT/s PCIe x16 link)
[    2.621272] ice 0000:18:00.0 eth0: A parallel fault was detected.
[    2.621365] ice 0000:18:00.0 eth0: Possible Solution: Check link partner connection and configuration.
[    2.621513] ice 0000:18:00.0 eth0: Port Number: 1.
[    3.331319] ice 0000:18:00.0 ens6f0: renamed from eth0
[ 1052.057728] ice 0000:18:00.0 ens6f0: NIC Link is up 100 Gbps Full Duplex, Requested FEC: RS-FEC, Negotiated FEC: RS-FEC, Autoneg Advertised: Off, Autoneg Negotiated: False, Flow Control: None
[2304065.370537] ice 0000:18:00.0 ens6f0: NIC Link is Down
[2304065.470757] ice 0000:18:00.0 ens6f0: NIC Link is up 100 Gbps Full Duplex, Requested FEC: RS-FEC, Negotiated FEC: RS-FEC, Autoneg Advertised: Off, Autoneg Negotiated: False, Flow Control: None
[6567288.755539] ice 0000:18:00.0 ens6f0: Changing Rx descriptor count from 2048 to 8160
[10043828.294404] ice 0000:18:00.0 ens6f0: NIC Link is Down
[10043828.394033] ice 0000:18:00.0 ens6f0: NIC Link is up 100 Gbps Full Duplex, Requested FEC: RS-FEC, Negotiated FEC: RS-FEC, Autoneg Advertised: Off, Autoneg Negotiated: False, Flow Control: None
[10198013.280727] ice 0000:18:00.0 ens6f0: NIC Link is Down
[10198013.381243] ice 0000:18:00.0 ens6f0: NIC Link is up 100 Gbps Full Duplex, Requested FEC: RS-FEC, Negotiated FEC: RS-FEC, Autoneg Advertised: Off, Autoneg Negotiated: False, Flow Control: None

그러나 나는 그것이 진짜 문제라고 확신하지 않습니다. 내가 보고 있는 문제를 설명할 만큼 자주 발생하지 않는 것 같고, 1초도 안 되어 다시 발생합니다. 이러한 문제는 다음과 같은 네트워크 연결과 관련된 것으로 보입니다.

root@pluto:/home/comind# ping knox
PING knox.comind.io (192.168.50.7) 56(84) bytes of data.
64 bytes from knox.comind.io (192.168.50.7): icmp_seq=1 ttl=64 time=0.476 ms
64 bytes from knox.comind.io (192.168.50.7): icmp_seq=2 ttl=64 time=0.542 ms
64 bytes from knox.comind.io (192.168.50.7): icmp_seq=3 ttl=64 time=0.521 ms
...
64 bytes from knox.comind.io (192.168.50.7): icmp_seq=26 ttl=64 time=0.544 ms
64 bytes from knox.comind.io (192.168.50.7): icmp_seq=27 ttl=64 time=0.554 ms
64 bytes from knox.comind.io (192.168.50.7): icmp_seq=34 ttl=64 time=0.539 ms
64 bytes from knox.comind.io (192.168.50.7): icmp_seq=35 ttl=64 time=0.402 ms
64 bytes from knox.comind.io (192.168.50.7): icmp_seq=36 ttl=64 time=0.539 ms
...

중단(각각의 길이는 약 7초인 icmp_sec=27것으로 보이며 icmp_sec=34매우 자주 발생합니다. 터미널 세션에서도 비슷한 현상이 나타납니다. 키보드 입력이 터미널에 표시되기 전에 몇 초 동안 멈추는 것 같습니다. 때로는 문자가 마지막에 있는 경우도 있습니다. 서버의 NFS 공유는 동일한 대기 시간의 영향을 받습니다.

NFS 서비스는 Ganesha V3.4에서 제공되며 로그에는 다음과 같은 여러 줄이 포함됩니다.

13/01/2023 01:09:46 : epoch 63a6c5e3 : knox : ganesha.nfsd-3365103[svc_946] rpc :TIRPC :EVENT :svc_ioq_flushv: 0x7fc37422f1b0 fd 10798 msg_iov 0x7fc2da2e0f60 sendmsg remaining 112 result -1 error Broken pipe (32)
13/01/2023 06:26:54 : epoch 63a6c5e3 : knox : ganesha.nfsd-3365103[svc_887] rpc :TIRPC :EVENT :svc_ioq_flushv: 0x7fc2190609f0 fd 10386 msg_iov 0x7fc447406f60 sendmsg remaining 112 result -1 error Broken pipe (32)
13/01/2023 08:06:33 : epoch 63a6c5e3 : knox : ganesha.nfsd-3365103[svc_967] rpc :TIRPC :EVENT :svc_ioq_flushv: 0x7fc1f42aec90 fd 10387 msg_iov 0x7fc2d8ac8f60 sendmsg remaining 112 result -1 error Broken pipe (32)
13/01/2023 08:36:01 : epoch 63a6c5e3 : knox : ganesha.nfsd-3365103[svc_967] rpc :TIRPC :EVENT :svc_ioq_flushv: 0x7fc11c5ee4c0 fd 10388 msg_iov 0x7fc2d8ac8f60 sendmsg remaining 112 result -1 error Broken pipe (32)
13/01/2023 08:38:04 : epoch 63a6c5e3 : knox : ganesha.nfsd-3365103[svc_1032] rpc :TIRPC :EVENT :svc_ioq_flushv: 0x7fc134b4f480 fd 10394 msg_iov 0x7fc38cde1f60 sendmsg remaining 112 result -1 error Broken pipe (32)
13/01/2023 10:55:53 : epoch 63a6c5e3 : knox : ganesha.nfsd-3365103[svc_1032] rpc :TIRPC :EVENT :svc_vc_wait: 0x7fc1e8074320 fd 10603 recv errno 104 (will set dead)

다시 말하지만, 빈번한 지연을 설명하기에는 로그에 오류가 충분하지 않습니다.

나에게는 이것이 네트워크 문제인 것이 분명합니다. 서버가 FS:에서 스위치에 연결되어 있지만 N5860-48SC불행히도 스위치 문제 해결에 대해 충분히 알지 못합니다. 이 문제를 해결하는 방법에 대한 도움, 통찰력 또는 제안을 보내주시면 감사하겠습니다.

답변1

특히 광섬유에서 링크가 불안정한 경우 로컬 오류가 발생했는지 아니면 원격 오류가 발생했는지 여부를 확인하면 매우 좋습니다.

다음 명령으로 카운터를 확인하세요.

ethtool -S ens6f0

다음과 같은 내용을 확인하세요.

$ ethtool -S ens259f0 |grep fault
     mac_local_faults.nic: 0
     mac_remote_faults.nic: 0

거기에 아무것도 없으면 출력을 가져옵니다.

ethtool -m ens6f0
ethtool -S ens6f0
ethtool -i ens6f0
devlink dev info

그리고 사용 가능한 최신 펌웨어/NVM 이미지를 실행하고 있는지 다시 확인하세요.

문제 해결 시 마지막으로 확인해야 할 부분은 스위치 로그 자체로 로컬(스위치 측) 오류가 발생했는지 아니면 원격(E810 측) 오류가 발생했는지 확인하는 것입니다.

E810에 로컬 오류가 표시되는 경우 문제 해결을 통해 지원팀에 문의하고 위에서 수집한 일부 정보를 제공해야 합니다. 잘못될 수 있는 부분이 많지만 위의 몇 가지 기본 단계를 따르면 일부 문제를 해결하는 데 도움이 됩니다.

답변2

이 작업을 수행하는 동안 ethtool -m경보가 있는지 확인하고 RX/TX 전력 수준이 범위 내에 있는지 확인하십시오. 범위에 대한 경보 임계값을 볼 수 있습니다.

임계값은 SFP 모듈마다 다를 수 있습니다.

답변3

마침내 문제를 발견했습니다. 광학 장치에 먼지가 있다는 것입니다. 어떻게든 누군가(이름은 언급되지 않았지만 나와 매우 가까운 사람입니다!) 광학 장치를 청소하지 않고 광 케이블을 뽑았다가 다시 연결했습니다. 정말 바보입니다. 세심한 청소 후에 모든 것이 완벽했습니다. 우리는 살고 배웁니다.

관련 정보