私は、Cisco スイッチ WS-C3560X-48 と CentOS 7.7 を実行している Linux サーバーがいくつかあるネットワーク環境で作業しています。
Linux サーバーは、HP ハードウェア上で実行されているため、スイッチ上で 3 回接続されています。1 つは管理リンク、1 つは運用リンク、もう 1 つは ILO リンクです。
Cisco スイッチから管理 LAN 上のサーバーに ping を実行しようとすると、次の結果が得られます。
SWTCisco#ping 10.123.213.152 source 10.123.213.158 repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 10.123.213.152, timeout is 2 seconds:
Packet sent with a source address of 10.123.213.158
!!!!!!.!!!!!!.!!!!!!.!!!!!!.!!!!!!.!!!!!!.!!!!!!.!!!!!!.!!!!!!.!!!!!!.
!!!!!!.!!!!!!.!!!!!!.!!!!!!.!!
Success rate is 86 percent (86/100), round-trip min/avg/max = 1/3/17 ms
ご覧のとおり、パターンがあります。7 回目の ping で常にパケットが失われます。サーバー側では、tcpdump を使用して、icmp 要求は受信されているが、icmp 応答は送信されていないことを確認できます。以下の例では、サーバーに 8 回 ping を実行しましたが、2 つの要求が連続していることがわかります。
root@CentOSserver:/etc/sysconfig/network-scripts# tcpdump -i eno1 host 10.123.213.158 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
11:37:04.770292 IP 10.123.213.158 > 10.123.213.152: ICMP echo request, id 134, seq 0, length 80
11:37:04.770354 IP 10.123.213.152 > 10.123.213.158: ICMP echo reply, id 134, seq 0, length 80
11:37:04.772624 IP 10.123.213.158 > 10.123.213.152: ICMP echo request, id 134, seq 1, length 80
11:37:04.772644 IP 10.123.213.152 > 10.123.213.158: ICMP echo reply, id 134, seq 1, length 80
11:37:04.774394 IP 10.123.213.158 > 10.123.213.152: ICMP echo request, id 134, seq 2, length 80
11:37:04.774411 IP 10.123.213.152 > 10.123.213.158: ICMP echo reply, id 134, seq 2, length 80
11:37:04.776592 IP 10.123.213.158 > 10.123.213.152: ICMP echo request, id 134, seq 3, length 80
11:37:04.776606 IP 10.123.213.152 > 10.123.213.158: ICMP echo reply, id 134, seq 3, length 80
11:37:04.789083 IP 10.123.213.158 > 10.123.213.152: ICMP echo request, id 134, seq 4, length 80
11:37:04.789099 IP 10.123.213.152 > 10.123.213.158: ICMP echo reply, id 134, seq 4, length 80
11:37:04.791466 IP 10.123.213.158 > 10.123.213.152: ICMP echo request, id 134, seq 5, length 80
11:37:04.791483 IP 10.123.213.152 > 10.123.213.158: ICMP echo reply, id 134, seq 5, length 80
11:37:04.793669 IP 10.123.213.158 > 10.123.213.152: ICMP echo request, id 134, seq 6, length 80
11:37:04.822159 ARP, Request who-has 10.123.213.158 tell 10.123.213.144, length 46
11:37:06.793024 IP 10.123.213.158 > 10.123.213.152: ICMP echo request, id 134, seq 7, length 80
11:37:06.793068 IP 10.123.213.152 > 10.123.213.158: ICMP echo reply, id 134, seq 7, length 80
10.123.213.158 は Cisco スイッチ上の VLAN のアドレス、
10.123.213.152 は Linux サーバー上の eno1 のアドレス、
10.123.213.144 は tcpdump の実行中に ARP 要求を実行している別のサーバーの ILO アドレスです。
新たな調査の結果、問題はスパニングツリーに関連していることがわかりました。私が発見した内容の pcap をホストしました。 https://filebin.net/9x9ech3uude93sda
pcap では、2 つの icmp 要求の間に STP パケットがあることがわかります。何度か試してみましたが、そのたびに、応答が見つかるはずの場所に STP パケットがありました。
私にとっては、これは単なる bpdu メッセージであり、インターフェイス GigabitEthernet0/27 には何の影響も与えないはずです。
シスコのスパニング ツリー構成には、特に警告するようなことは (私にとって) 見当たりません。
SWTCisco#sh spanning-tree vlan 28
VLAN0028
Spanning tree enabled protocol ieee
Root ID Priority 32796
Address 501c.bf45.1c00
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32796 (priority 32768 sys-id-ext 28)
Address 501c.bf45.1c00
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/11 Desg FWD 4 128.11 P2p
Gi0/18 Desg FWD 4 128.18 P2p
Gi0/19 Desg FWD 4 128.19 P2p
Gi0/20 Desg FWD 4 128.20 P2p
Gi0/21 Desg FWD 19 128.21 P2p
Gi0/22 Desg FWD 4 128.22 P2p
Gi0/23 Desg FWD 4 128.23 P2p
Gi0/24 Desg FWD 4 128.24 P2p
Gi0/25 Desg FWD 4 128.25 P2p
Gi0/26 Desg FWD 4 128.26 P2p
Gi0/27 Desg FWD 4 128.27 P2p
Gi0/31 Desg FWD 4 128.31 P2p
Gi0/32 Desg FWD 19 128.32 P2p
Gi0/33 Desg FWD 4 128.33 P2p
Gi0/34 Desg FWD 4 128.34 P2p
Gi0/35 Desg FWD 4 128.35 P2p
Gi0/36 Desg FWD 4 128.36 P2p
Gi0/37 Desg FWD 4 128.37 P2p
Gi0/38 Desg FWD 4 128.38 P2p
Gi0/39 Desg FWD 4 128.39 P2p
Gi0/40 Desg FWD 4 128.40 P2p
Gi0/47 Desg FWD 19 128.47 P2p
Gi1/3 Desg FWD 4 128.51 P2p
SWTCisco#sh run int gigabitEthernet 0/27
Building configuration...
Current configuration : 113 bytes
!
interface GigabitEthernet0/27
switchport access vlan 28
switchport mode access
end
SWTCisco#sh spanning-tree blockedports
Name Blocked Interfaces List
-------------------- ------------------------------------
Number of blocked ports (segments) in the system : 0
SWTCisco#sh spanning-tree summary
Switch is in pvst mode
Root bridge for: VLAN0028, VLAN0031, VLAN3715
EtherChannel misconfig guard is enabled
Extended system ID is enabled
Portfast Default is disabled
PortFast BPDU Guard Default is disabled
Portfast BPDU Filter Default is disabled
Loopguard Default is disabled
UplinkFast is disabled
BackboneFast is disabled
Configured Pathcost method used is short
Name Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ----------
VLAN0028 0 0 0 23 23
VLAN0031 0 0 0 12 12
VLAN0157 0 0 0 1 1
VLAN3715 0 0 0 1 1
---------------------- -------- --------- -------- ---------- ----------
4 vlans 0 0 0 37 37
SWTCisco#sh version | in RELEASE
Cisco IOS Software, C3560E Software (C3560E-UNIVERSALK9-M), Version 12.2(55)SE5, RELEASE SOFTWARE (fc1)
BOOTLDR: C3560E Boot Loader (C3560X-HBOOT-M) Version 12.2(53r)SE1, RELEASE SOFTWARE (fc1)
ping がアクティブで、インターフェースが FWD 状態のままである間に、インターフェース Gi0/27 を監視しました。
スイッチが BDPU フレームを送信している間にパケットが失われる理由がわかる人はいますか? 高度な STP 機能を理解するのに苦労しているので、何か見逃していることがあるかもしれません。