Drucker über VPN/WAN langsam

[Nastert 0]

Hallo zusammen ich habe eine Frage bezüglich unserem Drucker in unserer Niederlassung

 

Daten:

 

Hauptstandort: Company Connect SDSL 10mbit Synchron; Securepoint RC 300 -> IPsec

 

Niederlassung: Company Connect SDSL 5Mbit Synchron; Securepoint Black Dwarf -> IPsec

 

Eingesetzt wird eine RDP Verbindung zu unserem Terminal/Citrix Server.

 

Drucker: Kyocera FS 2100

 

1 Telefon wird auch über VOIP/VPN eingesetzt

 

 

 

Nun zum Thema:

 

Der Drucker ist über den Terminalserver via Druckverwaltung eingerichtet über seine IP Adresse. Die Niederlassung arbeitet remote auf dem Server. Wenn nun aus unserem ERP System ein Druckauftrag generiert wird, wird dieser ja über Internet/VPN an den Drucker in die NL übertragen.

 

Bis dieser Auftrag "bearbeitet" wird vergehen nach dem "klick" etwa 10-15 Sekunden. Der Drucker ist dabei nicht im Sleepmodus. Das dauert uns schon zu lange!

 

Wenn mehrere Seiten gedruckt werden, macht der Drucker ca. nach 4-5 Seiten eine Pause von erneut 15 Sekunden.

 

 

Worann kann das liegen? die RAM-Disk mussten wir im Druckertreiber deaktivieren, da sonst keine Mehrfachkopie möglich war (Anzahl 2, 3 etc.)

 

Es wird über den Spooler des Servers gedruckt, hier ist "Sofort Drucken" eingestellt sowie Druckaufträge im Spooler zuerst Drucken

[zahni 521]

Ram-Disk im Druckertreiber? Was ist das denn?

Versuche mal PCL6 als Treiber zu verwenden. Postscript produziert manchmal sehr viel Datenvolumen.

PCL6 wird  im Drucker i.d.R. auch schneller berechnet.

[Nastert 0]

Anscheinend dient dieser dazu, dass Jobs zwischen gecached werden.

 

PCL6 ist bereits im Drucker im Commandcenter eingestellt, ob man das extra im Treiber einstellen kann, weiß ich nicht

Ich benutze den KX driver von Kyocera

[NeMiX 76]

Wie sind die Leitungen den ausgelastet, evtl. mal mit der freien PRTG Version mitmessen.

 

Und mal mit "Druckaufträge im Spooler zuerst Drucken" ausgeschaltet testen, das hat bei einem KM Drucker mal geholfen (die sind aber entsprechend ausgestattet und können auch große Aufträge ab.)

[lefg 276]

Moin,

 

meine bevorzugte Hauptverdächtige(Lieblingshypothese) ist die Namensauflösung per DNS?

 

Wird der Drucker vom Sender mit dem NetBIOS-Namen angesteuert oder mit der IP-Adresse?

 

Hat sich der Drucker, wurde er in den Zonen des DNS eingetragen?

bearbeitet 13. Januar 2016 von lefg

[Nastert 0]

Hallo Nemix und lefg,

 

Also ich denke dass die Leitungen eher weniger ausgelastet sind, ich habe nicht mal QoS über VPN für VOIP konfiguriert, trotzdem gibts keine Störungen bzw Jitter :) Dennoch würde ich gerne mehr darüber erfahren wie ich das am besten messen kann.

 

@lefg: Der Drucker ist über die IP-Adresse angebunden nicht über den Hostname. Die IP Adresse ist natürlich in einem anderen Netz, aber das sollte ja schnell geroutet werden

[lefg 276]

Wie ist das Verhalten bei einem Druck von der GUI des Servers aus?

 

Wie ist das Verhalten bei einem Druck von einem Rechner der Zentrale aus?

 

Was für Terminals stehen denn in der Niederlassung, Thinclients oder Windows Clients?

 

Wie ist das Verhalten bei einem direkten Druck von einem Windows-Rechner der Niederlassung aus?

 

Falls ein Windows-Client den Drucker mit in die Sitzung nimmt, wie ist das Verhalten dann?

 

Edit: Welche Adresse hat der Terminalserver denn als Standardgateway eingetragen, die des Routers zur Niederlassung? Wie sieht das in der Niederlassung am Drucker aus für den Rückweg? Und wenn am TS Ping an den Drucker abgesetzt wird, wie ist die Antwort?

bearbeitet 13. Januar 2016 von lefg

[Nastert 0]

Hallo lefg,

 

1. Vom Server aus ist das Drucken genauso wie beschrieben

 

2. Teste ich heute und gebe Anwort ;)

 

3. Normale Windows PCs (Wir haben dort nur 1 PC)

 

4. Wenn der Rechner direkt von lokal aus druckt, gibt es keine Zeitverzögerung oder Pausen zwischen den Drucks. Lokal funktioniert allerdings unser ERP nicht, daher ist RDP nötig.

 

5. Es ist immer ein Windows Client

 

6. Unser Terminalserver (Steht im Hauptstandort) hat als Gateway unsere Firewall in dem Hauptstandort eingetragen. Im Drucker selber ist als Gateway die Firewall in der Niederlassung eingetragen.

 

Ping:

 

Ping wird ausgeführt für 192.168.68.70 mit 32 Bytes Daten:
Antwort von 192.168.68.70: Bytes=32 Zeit=16ms TTL=62
Antwort von 192.168.68.70: Bytes=32 Zeit=17ms TTL=62
Antwort von 192.168.68.70: Bytes=32 Zeit=16ms TTL=62
Antwort von 192.168.68.70: Bytes=32 Zeit=15ms TTL=62

 

Tracert:

 

Routenverfolgung zu 192.168.68.70 über maximal 30 Abschnitte

  1    <1 ms    <1 ms    <1 ms  fw01-1.Domainname.local [192.168.60.254]
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3    17 ms    16 ms    16 ms  192.168.68.70

bearbeitet 14. Januar 2016 von Nastert

[lefg 276]

Moin,

 

die Zeitüberschreitung bei der Routenverfolgung gefällt mir nicht. Was mag dafür die Ursache sein?

 

Wird eigentlich der Druckertreiber am Client mit in die Terminalsitzung genommen?

 

Ist der Druckertreiber eigentlich für Terminalserver/RDP-Sitzungen geeignet/freigegeben? Ich meine mich so dunkel zu erinnern, eine ähnliche Problemstellung hatten wir schon einmal oder mehrmals.

 

Ich gestehe, etwas mit Substanz fällt mir nicht ein, ich stochere im Nebel.

 

Edit: wie ist denn mit Ping und Routenverfolgung in der Niederlassung? Wie gut funktioniert ein RDP-Zugriff von der Haupstelle aus auf den PC dder Niederlassung? Wie gut funktioniert ein Wartungszugriff auf den Drucker?

bearbeitet 14. Januar 2016 von lefg

[Nastert 0]

Moin,

 

das bei der Routenverfolgung Sternchen kommen ist ganz normal, da es über VPN übermittelt wird, da sieht man keine zwsichen Hops ;)

 

Der Druckertreiber wird nicht über RDP mitübernommen bzw durchgeschleift, das hat zu starken Problemen geführt.

 

Laut Kyocera ist der Treiber dafür freigegeben.

 

Antwort auf dein Edit: Ping und Routenverfolgung sind identisch als würde ich den Drucker anpingen. RDP zugriffe funktionieren in beide Richtungen super! Der Wartungszugriff funktioniert auch bestens vom eigenen Netz oder vom Netz aus der Zentrale.

 

Ich bin auch wirklich überfragt :(

[DocData 85]

Ping wird ausgeführt für 192.168.68.70 mit 32 Bytes Daten:

Antwort von 192.168.68.70: Bytes=32 Zeit=16ms TTL=62

Antwort von 192.168.68.70: Bytes=32 Zeit=17ms TTL=62

Antwort von 192.168.68.70: Bytes=32 Zeit=16ms TTL=62

Antwort von 192.168.68.70: Bytes=32 Zeit=15ms TTL=62

 

Schau mal. Du hast eine Latenz von ca. 15 bis 20ms auf der Leitung. TCP/IP funktioniert leider nicht nach dem Prinzip "Hier, nimm das", sondern da wird immer mal wieder was bestätigt. Das kann dazu führen, dass es die Latenz ist, welche den gesamten Prozess in die länge zieht. Das erkennt man vor allem daran, wenn die Auslastung der Leitung (Bandbreite) eher gering ist.

[lefg 276]

Ich hab jetzt mal durch einen Tunnel pnged zu meiner Zentrale: Antwort von 192.168.y.y: Bytes=32 Zeit=7ms TTL=125

 

Und die Routenverfolgung sieht so aus:

 

1    <1 ms    <1 ms    <1 ms  internetrouter.x.local [192.168.x.x]
  2     7 ms    35 ms     7 ms  10.0.x.x
  3     5 ms     7 ms     7 ms  10.0.y.y
  4     6 ms     7 ms     7 ms  x.local [192.168.y.y]

 

Also, keine Zeitüberschreitung in meinem Bereich.

 

Ich hab jemanden gebeten, nachher von einer anderen Aussenstelle mal zur Zentrale Ping und Routenverfolgung durchzuführen. Diese Aussenstelle arbeitet seit einiger zeit mit Thinclients auf Citrix in der Zentrale und klagt ebenfalls über das Drucken wie der TO. Nächste Woche wird die Niederlassung hier auf Thinclients umgestellt. Ich bin mal gespannt.

bearbeitet 14. Januar 2016 von lefg

[DocData 85]

Ein Tracert arbeitet mit ICMP Echo Requests. Es ist nicht unüblich, dass z.B. Firewalls nicht auf diese Anfragen antworten. Dabei zeigt sich das vom TE gezeigte Bild bei der Routenverfolgung. Das wird nicht der Root Cause für das Problem sein.

[Nastert 0]

Danke Doc,

 

zudem wird es daran liegen, dass die Anschlüsse Company Connect sind und die Telekom diese anders Routet und halt nicht möchte dass die HOPS angezeigt werden.

 

 

Ich kann mir aber auch gut vorstellen dass unsere Securepoint ICMP Echo Requests ablehnen, unsere Firewall lässt sich z.b. auch nicht von extern anpingen ;)

könnte ich mit QoS arbeiten um die Druckaufträge priorisiert behandeln zu lassen?

 

Wenn dem so ist, müsste ich natürlich wissen welches Protokoll zur übermittlung eingesetzt wird.

 

Ich glaube zwar nicht, dass es daran liegt, aber jeder versuch macht Klug

[DocData 85]

Also ICMP zu blocken ist keine gute Idee. Man gewinnt nichts und man handelt sich oft nur Probleme ein. Mit IPv6 ist das zum Glück eh vorbei, da ist ICMPv6 überlebenswichtig...

 

Du hast kein Bandbreitenproblem, du hast ein Latenzproblem. Da hilft kein QoS.