Jump to content

Schahn

Members
  • Gesamte Inhalte

    8
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Schahn

  1. Ach, ich liebe HP :mad: Habe jetzt am WE alle Treiber erneuert und auch ThinPrint auf 7.6 gebracht. ThinPrint machte keine Probleme, aber die HP-Treiber... Nach dem Ändern der Treiber waren in allen Druckeinstellungs-Fenstern die Druckverknüpfungen weg (also diese Schnelleinstellungs-Vorlagen). Achja, und drucken konnt man nur vom Druckserver direkt aus, nicht aus den Terminal-Sessions. Habe dann jeden Drucker einzeln (wir haben ja "nur" über 200 Drucker) kurz auf einen völlig anderen Treiber geschalten (Apple LaserWriter irgendwas) und direkt wieder zurück auf den richtigen Treiber. Dann ging es... So ein Quark aber auch... Bisher läßt sich alles ganz ordentlich an, ich hoffe mal, die Probleme sind damit behoben. Ich möchte nur wissen, was HP hier wieder gemacht hat, dass man nicht mal ein simples Treiberupdate (über Eigenschaften -> Erweitert -> Neuer Treiber) machen kann, ohne das was schiefgeht. Ich war kurz davor, alle Drucker zu löschen und neu anzulegen. Zum Glück ist mir der Trick noch eingefallen. @Golle: Diese "Plastik-Drucker" hatte ich schon verdrängt :) mfg, Schahn
  2. Danke für den Link... Die P2055 stehen aber drin, das sind keine GDI-Drucker (hat HP überhaupt welche?). Genau den angegebenen Treiber verwenden wir ja auch, es gibt ja keinen anderen. Allerdings habe ich das Problem jetzt etwas einkreisen können. Möglicherweise ist auch ThinPrint schuld. Wir verwenden noch Version 7.0, vielleicht hat diese doch recht alte Version Probleme mit den neueren HP-Treibern. Ich werde mal auf ThinPrint 7.6 updaten, vielleicht wird es dann ja besser. mfg, Schahn
  3. Das Thema ist zwar schon etwas älter, allerdings habe ich jetzt bei unserer Citrix-Farm dasselbe Problem. Wir haben seit 2 Wochen HP P2055dn im Einsatz, seitdem häufen sich die Probleme: - sporadische Neustarts der Citrix-Server - ***isches Verhalten des Druckservers (Druckaufträge werden "verschluckt") Wir haben den bisher einzigen verfügbaren Treiber installiert, dieser hat z.B. die Eigenart, den verfügbaren Druckerspeicher nicht korrekt einstellen zu können (wir haben alle P2055 mit 384MB ausgestattet, einstellbar sind aber nur 320MB). Der HP-Support verweist auf allgemeine Treiberseiten und, ich zitiere WÖRTLICH: "Auserdem wir als Solutio Center unetrtuetzen nicht Web Jetadmin und Terminalserver" Ahja... Der Universal-Druckertreiber ist für uns nicht verwendbar, da wir über ThinPrint-Gateways drucken (d.h. die Drucker sind nicht direkt am Printserver verbunden), sodass der Universal-Treiber nicht erkennen kann, was da nun genau für ein Drucker hängt. Alles in allem sehr unbefriedigend. HP wird immer schlimmer bei jedem neuen Modell... mfg, Schahn
  4. Na ich denke ja schon, sonst würde ich ja einen Log-Eintrag bekommen. Habe ja auch noch andere Trackobjekte, die auch reagieren, wenn z.B. eine Leitung komplett stirbt. Das Trackobjekt pingt also von der ASA aus eine externe Adresse im Internet an, also quasi durch den 871 durch. Wenn es da klemmen würde, käme der Ping ja nicht durch. Hm... Alles sehr verworren. Ich könnte ja mal nen Call bei CISCO aufmachen, aber was soll ich denen erzählen? mfg, Schahn
  5. Den 871 habe ich nicht pingen lassen, aber ich habe ein Trackobjekt mit SLA-Monitor auf eine externe Adresse laufen über dieses Interface mit sehr geringer Toleranz, der müsste sich also im Log melden, wenn Unterbrechungen von mehr als 1 sec auftreten. Tut er aber nicht, mit anderen Worten, pingen nach draussen scheint zu gehen, auch während der "Hänger" mfg, Schahn
  6. Das Failover ist Active/Standby... Das NAT im 871 ist nach innen und aussen aktiviert (ip nat inside am VLAN1, ip nat outside am DI10). Der 871 nat-tet also in seine DMZ 192.168.20.0. Auf dem 871 ist alles offen, die ASA macht dann den VPN-Tunnel zu den Aussenstellen. Grundsätzlich funktioniert ja alles, auch manchmal viele Stunden lang. Bis es dann wieder "kracht". Das sieht im Interface-Log dann so aus: Cisco ASDM 6.0 for ASA - 10.10.10.2 - Graph (1) Interface outside3, Bit Rates ASA Time (CEST) Input Bit Rate (Kbps) Output Bit Rate (Kbps) 22.02.2008 11:49 473 456 22.02.2008 11:49 540 686 22.02.2008 11:49 489 627 22.02.2008 11:49 296 10 22.02.2008 11:49 53 1 22.02.2008 11:49 74 1 22.02.2008 11:50 52 1 22.02.2008 11:50 38 1 22.02.2008 11:50 133 489 22.02.2008 11:50 506 912 22.02.2008 11:50 339 493 22.02.2008 11:50 261 407 Wie man sieht, fällt die Output-Bitrate faktisch auf 0. Das führt dann zur Trennung der VPNs, entweder von ASA-Seite oder von Aussenstellen-Seite, je nachdem, wo zuerst das Timeout greift. mfg, Schahn
  7. Bitteschön... Ich habe mal alles unwichtige ausgeblendet. Der dargestellte Zweig macht den Ärger. Der angesprochene HP-Switch ist hier nicht zu sehen. Der verbindet die jeweiligen Outside3 der beiden ASAs mit dem 871. http://www.schahn.de/ASA.jpg mfg, Schahn
  8. Hallo, ich habe ein eigenartiges Problem. Zunächst in Kurzfassung unsere Konfiguration hier: - 2x CISCO ASA 5510 (Failover-Verbund) - 1x SDSL-Leitung Versatel mit festem IP-Bereich permanenter Verbindung (VPN direkt) - 1x SDSL-Leitung T-Com mit Einwahl und fester IP (VPN über NAT-T) - Aussenstellen: CISCO 876 bzw. 871 Es geht um die T-SDSL-Leitung. Die Einwahl wird von einem CISCO 871 bewerkstelligt, der in einer DMZ steht und über einen HP ProCurve Switch 1700-8G an einem der Outside-Interface der ASA hängt. Es passiert nun folgendes: Die Aussenstellen bauen das VPN auf über die Leitung. Die Verbindung ist funktional. Sporadisch fällt jedoch der Datentransfer auf dem Outside-Interface für 10-20 sec auf nahezu 0, aber OHNE dass die PPP-Verbindung unterbrochen wird. Das führt dann, je nach Länge des "Aussetzers" zum Zusammenbruch der VPN-Tunnel. Diese bauen sich i.d.R. relativ schnell wieder auf, da wir aber draussen Citrix-Sessions fahren, bleibt jedesmal alles dort stehen. Wir haben schon folgendes gemacht: - T-Com angemault... mehrtägige Leitungsüberwachung brachte keine Fehler - VPN-Timeouts verändert... keine Besserung - Mittels SLA-Monitor mit sehr kurzer Wartezeit versucht, den Aussetzer irg.wie zu loggen... kein Erfolg Wie es ausschaut, ist die Leitung für die ASA immer ok, im Debug-Log werden nur die VPN-Abbrüche dokumentiert, entweder mit "Lost Service" oder mit "Keepalive DPD". Ich bin gelinde gesagt vollkommen ratlos mittlerweile, woran das liegen könnte. Hat hier vielleicht jemand ein paar Tipps parat? Vielen Dank schonmal :) mfg, Schahn
×
×
  • Neu erstellen...