15
Bedeutung Packet Drops am Switch Port
Hallo,
wir haben einen 10G Netzwerk Backbone / Core Switch. An diesem hängen:
- die ESX Server mit 10G
- die Etagen Switche mit 1G
- die zentrale FW mit 1G
Die ESX Server hängen zudem noch per 1G zur Redundanz an den Etagenswitchen.
An dem Port der FW werden Packet Drops angezeigt.
Dies scheint dann zu passieren, wenn eine VM mit einer anderen VM aus einem anderen Netz/VLAN kommuniziert und per 10G über die 1G FW muss.
Kommunizieren Clients über den 1G Switch über die 1G FW, so sehen ich weder auf den Etagenswitchen noch auf dem Backbone Drops an den ganzen Ports.
Gleiches auch, wenn ich die VMs nur über die 1G Verbindung kommunizieren lasse. Keine Packet Drops.
Die Frage:
Sind die Packet Drops in dieser Konstellation an der FW erwartbar und das gehört so (weil Flaschenhals)?
Oder deutet dies auf ein Problem hin?
Danke und Gruß
wir haben einen 10G Netzwerk Backbone / Core Switch. An diesem hängen:
- die ESX Server mit 10G
- die Etagen Switche mit 1G
- die zentrale FW mit 1G
Die ESX Server hängen zudem noch per 1G zur Redundanz an den Etagenswitchen.
An dem Port der FW werden Packet Drops angezeigt.
Dies scheint dann zu passieren, wenn eine VM mit einer anderen VM aus einem anderen Netz/VLAN kommuniziert und per 10G über die 1G FW muss.
Kommunizieren Clients über den 1G Switch über die 1G FW, so sehen ich weder auf den Etagenswitchen noch auf dem Backbone Drops an den ganzen Ports.
Gleiches auch, wenn ich die VMs nur über die 1G Verbindung kommunizieren lasse. Keine Packet Drops.
Die Frage:
Sind die Packet Drops in dieser Konstellation an der FW erwartbar und das gehört so (weil Flaschenhals)?
Oder deutet dies auf ein Problem hin?
Danke und Gruß
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 44096249940
Url: https://administrator.de/en/bedeutung-packet-drops-am-switch-port-44096249940.html
Ausgedruckt am: 22.12.2024 um 06:12 Uhr
15 Kommentare
Neuester Kommentar
Du meinst den Port am Switch wo die Firewall dran hängt oder meinst du den Port an der Firewall wo der Uplink zum Switch eingesteckt ist ?
Hallo,
der Port auf dem 10G Switch zeigt die Drops an.
Gruß
der Port auf dem 10G Switch zeigt die Drops an.
Gruß
Hallo,
warum müssen die VMs denn überhaupt über 1G kommunizieren?
Das verstehe ich nicht.
Redundanz ja, aber dann stelle ich die 1G Ports unter VMware als Standby ein, dann sind die im Normalfall ruhig.
Oder verstehe ich da was nicht?
warum müssen die VMs denn überhaupt über 1G kommunizieren?
Das verstehe ich nicht.
Redundanz ja, aber dann stelle ich die 1G Ports unter VMware als Standby ein, dann sind die im Normalfall ruhig.
Oder verstehe ich da was nicht?
1
Solche Drops können vielfältige Ursachen haben. Treten sie vermehrt an Trunks auf ist das oftmals ein Tagging Mismatch. Sprich Frames werden auf einer Seite mit einem Tag rausgesendet und die andere Seite kann mit dem Tag nichts anfangen (fehlendes VLAN etc.) und dropt den Frame dann. Passiert auch an einem (untagged) Access Port der Tagged Frames von der anderen Seite bekommt.
Congestion wäre auch möglich z.B. ein 10G Port der eingehende Daten mit 1G oder auch 1G LAGs weiterreicht. Aber dazu musste man wissen wie deine Auslastung an dem Port ist und ob die Switches Store and Forward oder Passthrough Teile sind wozu du ja leider nichts sagst.
Frame CRC Errors, Runt oder Giants, Collisions usw. zählen dazu auch. Bei 10G Base T oftmals durch schlechte Kabel und Verbindungen weshalb man dort für den Anschluß von Server HW ausschliesslich DAC/Twinax, AOC oder SFP+ Optiken verwenden sollte aber niemals RJ-45. Man kann aber ohne weitere Troubleshootingdaten auch nur Kristallkugeln.
Congestion wäre auch möglich z.B. ein 10G Port der eingehende Daten mit 1G oder auch 1G LAGs weiterreicht. Aber dazu musste man wissen wie deine Auslastung an dem Port ist und ob die Switches Store and Forward oder Passthrough Teile sind wozu du ja leider nichts sagst.
Frame CRC Errors, Runt oder Giants, Collisions usw. zählen dazu auch. Bei 10G Base T oftmals durch schlechte Kabel und Verbindungen weshalb man dort für den Anschluß von Server HW ausschliesslich DAC/Twinax, AOC oder SFP+ Optiken verwenden sollte aber niemals RJ-45. Man kann aber ohne weitere Troubleshootingdaten auch nur Kristallkugeln.
Hallo,
1G ist an den ESX als Standby. Nur zum Gegentest habe ich das am ESX gedreht.
Die VMs im VLAN A und VLAN B könnten per 10G kommunizieren, wenn die nicht über die 1G Firewall gehen müssten. Und dann entstehen die Drops.
Nehme ich die 1G Standby Adapter Aktiv, können die VMs ja max 1G. Und dann entstehen auch keine Drops.
Gruß und Danke
Quote from @Deepsys:
warum müssen die VMs denn überhaupt über 1G kommunizieren?
Das verstehe ich nicht.
Redundanz ja, aber dann stelle ich die 1G Ports unter VMware als Standby ein, dann sind die im Normalfall ruhig.
Oder verstehe ich da was nicht?
ja, Missverstanden.warum müssen die VMs denn überhaupt über 1G kommunizieren?
Das verstehe ich nicht.
Redundanz ja, aber dann stelle ich die 1G Ports unter VMware als Standby ein, dann sind die im Normalfall ruhig.
Oder verstehe ich da was nicht?
1G ist an den ESX als Standby. Nur zum Gegentest habe ich das am ESX gedreht.
Die VMs im VLAN A und VLAN B könnten per 10G kommunizieren, wenn die nicht über die 1G Firewall gehen müssten. Und dann entstehen die Drops.
Nehme ich die 1G Standby Adapter Aktiv, können die VMs ja max 1G. Und dann entstehen auch keine Drops.
Gruß und Danke
Hallo,
@aqui
Hier mal ein Screenshot von der Interface Statistic:
Ist ein Juniper EX4600.
Die ESX hängen per 10g DAC ohne LAG am Backbone
Aber die FW hängt per 2x Kupfer-SFP und LAG dran.
VLAN Tagging Probleme dürfte man ausschließen können, da keinerlei Paket Drops per 1G zu finden sind!?
Gruß und Danke
@aqui
Hier mal ein Screenshot von der Interface Statistic:
Die ESX hängen per 10g DAC ohne LAG am Backbone
Aber die FW hängt per 2x Kupfer-SFP und LAG dran.
VLAN Tagging Probleme dürfte man ausschließen können, da keinerlei Paket Drops per 1G zu finden sind!?
Gruß und Danke
VLAN Tagging Probleme dürfte man ausschließen können, da keinerlei Paket Drops per 1G zu finden sind!?
Du redest hier ja aber vom 10G Port zum ESXi, oder? Dort spielt ja dann die "Dropping" Musik und ggf. dann auch der Tagging Mismatch zum ESXi Host. Der 1G Port ist ja ganz andere Baustelle...In der Juniper Knowledgebase gibts bestimmt einen Guide der dir sagt WAS alles Paket Drops triggert. Cisco u. Co. hat das auch.
Hallo,
Die Frage habe ich nicht verstanden...
Die Drops sind ausschließlich auf dem Port, wo die Firewall per 1G hängt, zu sehen.
Die Anzahl steigt, wenn VMs per 10G über den ESX kommunizieren und der Traffic über die 1G FW muss (weil anderes Netz und VLAN).
Nutze ich anstelle des 10G Interface das 1G Interface des ESX, dann geht es über den Etagen Switch, der per 1G am Backbone hängt. Also alles max 1G. Dann steigen die Drops nicht am FW Port und an den anderen Ports ist auch nichts zu sehen.
Gruß
Quote from @aqui:
VLAN Tagging Probleme dürfte man ausschließen können, da keinerlei Paket Drops per 1G zu finden sind!?
Du redest hier ja aber vom 10G Port zum ESXi, oder? Dort spielt ja dann die "Dropping" Musik und ggf. dann auch der Tagging Mismatch zum ESXi Host. Der 1G Port ist ja ganz andere Baustelle...Die Frage habe ich nicht verstanden...
Die Drops sind ausschließlich auf dem Port, wo die Firewall per 1G hängt, zu sehen.
Die Anzahl steigt, wenn VMs per 10G über den ESX kommunizieren und der Traffic über die 1G FW muss (weil anderes Netz und VLAN).
Nutze ich anstelle des 10G Interface das 1G Interface des ESX, dann geht es über den Etagen Switch, der per 1G am Backbone hängt. Also alles max 1G. Dann steigen die Drops nicht am FW Port und an den anderen Ports ist auch nichts zu sehen.
Gruß
Die Drops sind ausschließlich auf dem Port, wo die Firewall per 1G hängt, zu sehen.
Aaaahhsooo, sorry das war dann missverstanden. 🙈Kann das eine Überlast Situation (Congestion) sein??
https://www.juniper.net/documentation/us/en/software/junos/junos-overvie ...
1
Moin,
Die VMs könnten 10G und quetschen sich durch die 1G Firewall.
Sind die Drops dann zu erwarten?
Kennt das jemand und kann das Verhalten bestätigen?
Oder deutete es eher auf ein Problem hin und wir müssen die Ports noch "besser" konfigurieren?
Danke und Gruß
Quote from @aqui:
Kann das eine Überlast Situation (Congestion) sein??
https://www.juniper.net/documentation/us/en/software/junos/junos-overvie ...
So meine Vermutung.Kann das eine Überlast Situation (Congestion) sein??
https://www.juniper.net/documentation/us/en/software/junos/junos-overvie ...
Die VMs könnten 10G und quetschen sich durch die 1G Firewall.
Sind die Drops dann zu erwarten?
Kennt das jemand und kann das Verhalten bestätigen?
Oder deutete es eher auf ein Problem hin und wir müssen die Ports noch "besser" konfigurieren?
Danke und Gruß
Sind die Drops dann zu erwarten?
Bei TCP basiertem Traffic durch die Sliding Windows Flusskontrolle eher wenig aber alles was keinen Session Level hat schon wenn so eine Leitung 10:1 überbucht ist.An den Port Buffern des Switches zu tunen bringt nichts, denn das Problem besteht ja schon vorher und liegt an einem falschen Backbone Design.
Hallo,
Meinst du den 10G Switch?
Oder, dass die FW nur mit max 1G angebunden ist?
Danke
Quote from @aqui:
Bei TCP basiertem Traffic durch die Sliding Windows Flusskontrolle eher wenig aber alles was keinen Session Level hat schon wenn so eine Leitung 10:1 überbucht ist.
Das kann ich in der Tat testen, da es zwei verschiedene Arten der Kommunikation zwischen diesen beiden VMs gibt. Jedoch erst Ende nächster Woche...Bei TCP basiertem Traffic durch die Sliding Windows Flusskontrolle eher wenig aber alles was keinen Session Level hat schon wenn so eine Leitung 10:1 überbucht ist.
... liegt an einem falschen Backbone Design.
Kannst du darauf näher eingehen?Meinst du den 10G Switch?
Oder, dass die FW nur mit max 1G angebunden ist?
Danke
Kannst du darauf näher eingehen?
Na ja einen 10G Link im Backend durch einen 1Gig Link mit 10zu1 Überbuchung zu zwängen endet immer so. Wenn der 10G Link mehr als 1 Gig Traffic hat muss es ja zum Dropping von Frames kommen, denn ein Interface Queue kann nicht mehrere Mbit an Daten zwischenpuffern. Bei Passthrough Switches ist sogar gar kein Zwischenpuffern möglich.Oder, dass die FW nur mit max 1G angebunden ist?
Wenn die nicht routen muss zw. den 10G Hosts und ins Internet nicht mehr als 1Gig weggehen dann ist die FW nicht die Ursache.
Moin @ElmerAcmeee,
das riecht meiner Ansicht nach zu > 99% danach, dass bei dir die Überlaststeuerung nicht korrekt greift.
Als erstes solltest du prüfen, ob auf der gesamten Strecke (vmNIC, vSwitch, NIC, Switch, FW) Flow Control aktiviert ist, wenn nicht dann bitte aktivieren. By the way, bei VMware sollte FC eigentlich per default an sein.
Wenn das nicht fruchtet, dann könnte auch das von @aqui angesprochene "TCP Congestion Control" zwischen Client/Server, respektive Sender/Empfänger nicht kompatibel zueinander konfiguriert sein.
Welche Betriebssysteme sind den auf den Clients/Server den überhaupt installiert?
Gruss Alex
Nehme ich die 1G Standby Adapter Aktiv, können die VMs ja max 1G. Und dann entstehen auch keine Drops.
das riecht meiner Ansicht nach zu > 99% danach, dass bei dir die Überlaststeuerung nicht korrekt greift.
Als erstes solltest du prüfen, ob auf der gesamten Strecke (vmNIC, vSwitch, NIC, Switch, FW) Flow Control aktiviert ist, wenn nicht dann bitte aktivieren. By the way, bei VMware sollte FC eigentlich per default an sein.
Wenn das nicht fruchtet, dann könnte auch das von @aqui angesprochene "TCP Congestion Control" zwischen Client/Server, respektive Sender/Empfänger nicht kompatibel zueinander konfiguriert sein.
Welche Betriebssysteme sind den auf den Clients/Server den überhaupt installiert?
Gruss Alex
1
Wenn es das denn war bitte nicht vergessen deinen Thread als erledigt zu schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
