Spanning Tree verursacht Paketverlust zwischen einem Cisco-Switch C3560 und einem Linux-Server, der auf CentOs läuft

Spanning Tree verursacht Paketverlust zwischen einem Cisco-Switch C3560 und einem Linux-Server, der auf CentOs läuft

Ich arbeite in einer Netzwerkumgebung, in der ich einige Cisco Switch WS-C3560X-48 und Linux-Server mit CentOS 7.7 habe.

Die Linux-Server sind dreimal mit meinen Switches verbunden: eine Admin-Verbindung, eine Produktionsverbindung und eine ILO-Verbindung, da sie auf HP-Hardware laufen.

Wenn ich versuche, von meinem Cisco-Switch aus die Server im Admin-LAN anzupingen, erhalte ich das folgende Ergebnis:

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

Wie Sie sehen, habe ich ein Muster, ich verliere immer beim 7. Ping ein Paket. Auf der Serverseite kann ich mit tcpdump sehen, dass die ICMP-Anforderung empfangen wird, aber die ICMP-Antwort nicht gesendet wird. Im Beispiel unten habe ich den Server 8 Mal angepingt und wir können 2 Anfragen hintereinander sehen.

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 ist die Adresse des VLAN auf meinem Cisco-Switch.
10.123.213.152 ist die Adresse von eno1 auf dem Linux-Server.
10.123.213.144 ist die ILO-Adresse eines anderen Servers, der eine ARP-Anfrage stellte, während mein TCPdump ausgeführt wurde.

Nach erneuter Untersuchung habe ich festgestellt, dass das Problem mit Spanning Tree zusammenhängt. Ich habe ein PCAP meiner Ergebnisse gehostet. https://filebin.net/9x9ech3uude93sda

Im PCAP können wir sehen, dass sich zwischen den beiden ICMP-Anfragen ein STP-Paket befindet. Ich habe es mehrere Male versucht und jedes Mal hätte ich meine Antwort in einem STP-Paket finden sollen.

Für mich ist es nur eine BPDU-Nachricht und sollte keine Auswirkungen auf meine Schnittstelle GigabitEthernet0/27 haben.

In der Spanning Tree-Konfiguration auf dem Cisco ist nichts (für mich) besonders Beunruhigendes zu erkennen:

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)

Ich habe meine Schnittstelle Gi0/27 beobachtet, während der Ping aktiv war und die Schnittstelle im FWD-Status blieb.

Hat jemand eine Idee, warum ich ein Paket verliere, während der Switch einen BDPU-Frame sendet? Ich habe einige Probleme, einige erweiterte STP-Funktionen zu verstehen, daher übersehe ich hier möglicherweise etwas.

verwandte Informationen