12
TCP Paket zwischen zwei Servern wird verworfen, RST
Hallo,
Die Performance auf einem unserer Terminalserver ist schlecht, wenn er ein Programm benutzt, welches auf dem Datenbankserver läuft.
Beide Server sind im selben Netz. Das Standardgateway beider ist die Firewall.
Ich habe mit Wireshark einen Mitschnitt angelegt und kann erkennen, dass die RST Pakete von Quelle Terminalserver zu Ziel Datenbankserver unterwegs sind mit einer TTL von 128.
Wenn die TTL 128 ist, dann wurde das Paket ja nicht geroutet.
Meine Frage an der Stelle:
Wenn die Firewall das Paket resetten sollte, reduziert sich dann die TTL um 1 oder nur dann, wenn das Paket erfolgreich die Firewall passiert?
Ich würde gern wissen wollen, ob die Firewall als Ursache in Betracht kommt oder ob ich die Ursache woanders suchen muss.
Vielen Dank schon mal.
Die Performance auf einem unserer Terminalserver ist schlecht, wenn er ein Programm benutzt, welches auf dem Datenbankserver läuft.
Beide Server sind im selben Netz. Das Standardgateway beider ist die Firewall.
Ich habe mit Wireshark einen Mitschnitt angelegt und kann erkennen, dass die RST Pakete von Quelle Terminalserver zu Ziel Datenbankserver unterwegs sind mit einer TTL von 128.
Wenn die TTL 128 ist, dann wurde das Paket ja nicht geroutet.
Meine Frage an der Stelle:
Wenn die Firewall das Paket resetten sollte, reduziert sich dann die TTL um 1 oder nur dann, wenn das Paket erfolgreich die Firewall passiert?
Ich würde gern wissen wollen, ob die Firewall als Ursache in Betracht kommt oder ob ich die Ursache woanders suchen muss.
Vielen Dank schon mal.
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: 1219100907
Url: https://administrator.de/contentid/1219100907
Ausgedruckt am: 12.11.2024 um 19:11 Uhr
12 Kommentare
Neuester Kommentar
Moin,
Wenn beide Server im gleichem Netz stehen, gehen keine Datenpakete über die Firewall bzw. das Gateway.
Gruß
C.C.
Wenn beide Server im gleichem Netz stehen, gehen keine Datenpakete über die Firewall bzw. das Gateway.
Gruß
C.C.
Zitat von @148656:
Moin,
Wenn beide Server im gleichem Netz stehen, gehen keine Datenpakete über die Firewall bzw. das Gateway.
Moin,
Wenn beide Server im gleichem Netz stehen, gehen keine Datenpakete über die Firewall bzw. das Gateway.
Deswegen bleibt die TTL bei 128, weil das Paket weder Firewall noch Router durchlaufen hat.
Das RST kommt also direkt vom TS.
lks
PS: schau auf die MAC-Adresse des Absenders. Die gibt Auskunft, von welchem Interface das Paket kommt, solange keiner spooft.
Vielen Dank für den Hinweis. Nun kann ich an der richtigen Stelle ansetzen.
Und welche Stelle nimmst du jetzt als Ansatz?
Ich würde das vmware Interface des Terminalservers in die nähere Auswahl ziehen. Die Absender-MAC ist das VMWare Interface.
Ist dir zufällig eine Einstellung im ESXi 6.5 bekannt, die z.B: maximale Anzahl der Verbindungen regelt? Irgendwas muss ja dazu führen, dass die Pakete verworfen werden. Interessant ist auch die vergangene Zeit zum vorangegangenen Paket - die liegt z.T: bei ca. 10 Sekunden.
Ist dir zufällig eine Einstellung im ESXi 6.5 bekannt, die z.B: maximale Anzahl der Verbindungen regelt? Irgendwas muss ja dazu führen, dass die Pakete verworfen werden. Interessant ist auch die vergangene Zeit zum vorangegangenen Paket - die liegt z.T: bei ca. 10 Sekunden.
Zitat von @joh316:
Ich würde das vmware Interface des Terminalservers in die nähere Auswahl ziehen. Die Absender-MAC ist das VMWare Interface.
Ist dir zufällig eine Einstellung im ESXi 6.5 bekannt, die z.B: maximale Anzahl der Verbindungen regelt? Irgendwas muss ja dazu führen, dass die Pakete verworfen werden. Interessant ist auch die vergangene Zeit zum vorangegangenen Paket - die liegt z.T: bei ca. 10 Sekunden.
Ich würde das vmware Interface des Terminalservers in die nähere Auswahl ziehen. Die Absender-MAC ist das VMWare Interface.
Ist dir zufällig eine Einstellung im ESXi 6.5 bekannt, die z.B: maximale Anzahl der Verbindungen regelt? Irgendwas muss ja dazu führen, dass die Pakete verworfen werden. Interessant ist auch die vergangene Zeit zum vorangegangenen Paket - die liegt z.T: bei ca. 10 Sekunden.
Wie sieht denn die Gesamt-kommunikation vom ersten SYN bis zum RST aus? Insbesodnere die letzen Pakete vor dem RST?
lks
Das erste SYN ist offenbar nicht mit aufgezeichnet - ich schick einfach mal das, was ich habe.
Vielleicht lässt sich ja trotzdem was erkennen.
... die gelöst Markierung habe ich an dem Beitrag hier mal wieder entfernt, da wir dem Fehler offenbar gleich gemeinsam nachgehen - vielen Dank!!
Vielleicht lässt sich ja trotzdem was erkennen.
... die gelöst Markierung habe ich an dem Beitrag hier mal wieder entfernt, da wir dem Fehler offenbar gleich gemeinsam nachgehen - vielen Dank!!
Zitat von @joh316:
Das erste SYN ist offenbar nicht mit aufgezeichnet - ich schick einfach mal das, was ich habe.
Vielleicht lässt sich ja trotzdem was erkennen.
Sieht so aus als würde die *.63 nach dem vorletzten Paket nicht mehr antworten so dass es dann zu einem Timeout kommt und die *.213 die Verbindung dann nach einem Timeout versucht zu kappen/erneuern. Sind ja immerhin 23 Sekunden zwischen den letzten beiden PaketenDas erste SYN ist offenbar nicht mit aufgezeichnet - ich schick einfach mal das, was ich habe.
Vielleicht lässt sich ja trotzdem was erkennen.
Min,
Nichr ganz. Die Frage wäre, ob die DCERPC-Verbindungen mit Deine Anwendung und der TCp-verbindugn zusammenhängen oder ob die unabhängig davon von andern Anwendungen laufen.
Außerdem wäre die gesamte Kommunikation wichtig, um zu schauen, ob da nur einige Wenige Pakete durchgehen oder ob das ganz normale eine Weil e hin und her geht.
Und wie schon evoplus sagte. Da kommt es anscheinend zu einem Timeout. Da ist über 20 Sekunden lang keine Paketaustausch zwischen den beiden Kisten.
lks
Zitat von @joh316:
Das erste SYN ist offenbar nicht mit aufgezeichnet - ich schick einfach mal das, was ich habe.
Vielleicht lässt sich ja trotzdem was erkennen.
Das erste SYN ist offenbar nicht mit aufgezeichnet - ich schick einfach mal das, was ich habe.
Vielleicht lässt sich ja trotzdem was erkennen.
Nichr ganz. Die Frage wäre, ob die DCERPC-Verbindungen mit Deine Anwendung und der TCp-verbindugn zusammenhängen oder ob die unabhängig davon von andern Anwendungen laufen.
Außerdem wäre die gesamte Kommunikation wichtig, um zu schauen, ob da nur einige Wenige Pakete durchgehen oder ob das ganz normale eine Weil e hin und her geht.
Und wie schon evoplus sagte. Da kommt es anscheinend zu einem Timeout. Da ist über 20 Sekunden lang keine Paketaustausch zwischen den beiden Kisten.
lks
ich habe eben auf dem Host nachgesehen und die angehangene Einstellung gefunden.
Standard-Einstellung ist, dass nur 4 Verbindungen von derselben IP Adresse gleichzeitig zugelassen werden. Diese Einstellung haben wir noch nie angepasst.
Da alle Nutzer an der 213 gleichzeitig arbeiten und auf die 63 zugreifen, würde ich sagen ist 4 deutlich zu wenig.
Was denkt ihr? Irre ich mich?
Standard-Einstellung ist, dass nur 4 Verbindungen von derselben IP Adresse gleichzeitig zugelassen werden. Diese Einstellung haben wir noch nie angepasst.
Da alle Nutzer an der 213 gleichzeitig arbeiten und auf die 63 zugreifen, würde ich sagen ist 4 deutlich zu wenig.
Was denkt ihr? Irre ich mich?
Zitat von @joh316:
ich habe eben auf dem Host nachgesehen und die angehangene Einstellung gefunden.
Standard-Einstellung ist, dass nur 4 Verbindungen von derselben IP Adresse gleichzeitig zugelassen werden. Diese Einstellung haben wir noch nie angepasst.
Da alle Nutzer an der 213 gleichzeitig arbeiten und auf die 63 zugreifen, würde ich sagen ist 4 deutlich zu wenig.
Was denkt ihr? Irre ich mich?
ich habe eben auf dem Host nachgesehen und die angehangene Einstellung gefunden.
Standard-Einstellung ist, dass nur 4 Verbindungen von derselben IP Adresse gleichzeitig zugelassen werden. Diese Einstellung haben wir noch nie angepasst.
Da alle Nutzer an der 213 gleichzeitig arbeiten und auf die 63 zugreifen, würde ich sagen ist 4 deutlich zu wenig.
Was denkt ihr? Irre ich mich?
Die Frage ist doch, was der Hersteller der Software dazu sagt. je nachdem wie die Software arbeitet, können 4 verbindugne mehr als genug sein oder deutlich unterdimensioniert.
lks
Die Anfrage an den Hersteller ist raus - ich melde mich bald zurück.
Bis hier hin auf jeden Fall: Danke!
Bis hier hin auf jeden Fall: Danke!
