Jump to content

Blacky_24

Board Veteran
  • Content Count

    587
  • Joined

  • Last visited

Community Reputation

10 Neutral

2 Followers

About Blacky_24

  • Rank
    Board Veteran
  1. High level spam protection for Microsoft Windows 2000 SMTP Service and Microsoft Exchange 2000 Server platforms from Vamsoft - ein wirklich traumhaft gutes Produkt zu einem Spitzenpreis. Schlägt bei Spam GFI & Konsorten um Längen (wenn man es richtig konfiguriert). Gruss Markus
  2. Die Lancoms sind sehr ordentlich, allerdings ist der Preis wirklich Businessklasse und die Konfigurationssoftware teilweise sehr undurchsichtig. In der Preisklasse von Lancom gibt es problemlos auch gute Geräte z.B. von Cisco, z.B. die Router aus der 87x-Serie. Bei den VPN-Ciscos sind i.d.R. 10 VPN-Verbindungen und die Hardwarebeschleunigung für VPN bereits freigeschaltet, ausserdem auch das SSL-VPN mit 2 Connections. Ausserdem können die Ciscos schon IPv6 (wers braucht) - steht bei Lancom noch sehr weit weg in den Sternen - und die Performance i.S.v. Rechenleistung der Ciscos scheint mir besser als bei den Lancoms. Dafür liefert Lancom bei einigen Routern eine rudimentäre VoIP-PBX mit (wers braucht). Bei Cisco kosten Updates (jährliche Wartungspauschale inkl. Telefonsupport und Hardwaeaustausch next Business Day um die EUR 40,--), bei Lancom gibts die Software für Umme, dafür ist der Hardwareaustausch auch kostenpflichtig und kostet AFAIR einen Tick mehr als bei Cisco. Der (kostenlose) Support bei Lancom ist sehr durchwachsen, der (kostenpflichtige, s.o.) Support bei Cisco ist sehr gut und 24x7 erreichbar, allerdings sollte man brauchbar Englisch sprechen. Über Draytek kann ich nichts Schlechtes sagen, haben wir selber auch (neben Lancom und Cisco) im Einsatz und die Drayteks tun das was sie sollen - bei einem ansprechenden Preis-Leistungs-Verhältnis. Netgear und D-Link würde ich mir eher nicht kaufen. Gruss Markus
  3. Theoretisch könnten wir Dich beliefern, allerdings sitzen wir in DE (in Sichtweite der schweizer Grenze). Für einen "preisgünstigen" Test reicht Dir vielleicht eine Eicon/Dialogic Diva BRI oder Diva V-BRI (hat man vielleicht rumliegen, ansonsten billig gebraucht bei eBay & Konsorten). Dialogic bietet für diese Karten eine Software "Diva SIPcontrol" an welche ISDN via CAPI auf den Exchange 2007 bzw. OCS 2007-SIP-Dialekt umsetzt und an den Server schickt. In der kostenlosen Version unterstützt SIPcontrol bis zu 8 gleichzeitige Sprachkanäle, für ein Testsystem - und eine kleine Produktivumgebung - wahrscheinlich genug. Wenn man für SIPcontrol Geld ausgeben will skaliert das bis 120 Sprachkanäle (4x E1). Dialogic Diva SIPcontrol Software Gruss Markus
  4. Die erste Frage wäre doch ob X-TAPI überhaupt auf Citrix läuft / funktioniert - Auskunft dazu sollte Global IP geben können. Auf Citrix bzw. MSTS gibt es einige Besonderheiten die den Betrieb "üblicher" TAPIs auf diesen Systemen schlicht unmöglich machen - was man da mit einem "Skript" hinbiegen kann entzieht sich meiner Kenntnis, aufgrund meiner Kenntnis der Probleme glaube ich aber nicht dass sich da alleine mit einem "Skript" allzuviel retten lässt. Gruss Markus
  5. Wir haben hier Netgear, HP und Cisco-Switches im Einsatz. Den Netgear finde ich ziemlich ätzend was die Konfiguration angeht. Das Webinterface ist nahe dran an "unbrauchbar" und die Syntax auf der Kommandozeile ist ziemlich gewöhnungsbedürftig. Die VLAN-Geschichte - speziell die VLAN-Port-Zuweisungen auf den Trunk-Interfaces hat mich etliche böse Flüche gekostet. Ein "Save"-Kommando hat Netgear tatsächlich mittlerweile auch eingebaut, früher konnte man die Konfig nur speichern wenn man sich explizit vom Terminal abgemeldet hat (dann fragt die Kiste ob man speichern will) - dumm wenn das Terminal in den Timeout läuft und man nicht mehr dran denkt, dann war die Konfig beim Reboot weg. HP sind einfach gut, sehr standardtreu und robust, die Syntax ist sehr an Cisco angelehnt. Cisco ist meiner Meinung nach zu teuer für die gebotene Leistung - und im Vergleich z.B. zu HP. D-Link finde ich etwas durchwachsen. Früher hatten die mal brauchbare modulare Switches, mittlerweile machen die eigentlich nur noch im SMB- und SoHo-Segment rum, haben wohl die Kurve nicht gekriegt zumal denen im Business-Umfeld das "drumherum" gefehlt hat. Ein brauchbarer Kompromiss ist IMHO Linksys. Geht halt nur übers Webinterface zu konfigurieren und man kann die im Vergleich zu HP und Cisco nicht bis ins Letzte konfigurieren aber für durchschnittliche Anforderungen bis zu einer mittleren zweistelligen Hostzahl dürften die ausreichend sein. Einen durchaus brauchbaren Eindruck macht SMC. Die haben wohl Ambitionen auf das gehobene Business-Segment und können mit 10 GBE-Ports und modularen Chassis mittlerweile auch die "besseren" Sachen. Ich habe mich auf der Cebit länger und öfters mit denen unterhalten (deren Stand war neben unserem) und die machten durchaus den Eindruck dass die wissen was sie tun. Gruss Markus
  6. Über 3Com sage ich hier nix - ausser dass wir deren Kram bei allen Kunden rausgeschmissen und durch HP bzw. Cisco ersetzt haben. Habe gerade nochmal etwas Literatur studiert (leider hier nur in Papierform, deswegen kein Link): Der HP Teaming NIC erkennt ob der Switch gegenüber LACP spricht oder nicht. Wenn der Switch kein LACP spricht mach der Teaming NIC ein "transmit load-balancing team", d.h. der Teaming NIC verteilt den Traffic in Senderichtung möglichst gleichmässig über alle physikalischen Interfaces. Wenn der SWITCH LACP spricht verteilt der Teaming NIC den Traffic in Sende- und in Empfangsrichtung gleichmässig ("aggregated link that supports both transmit and receive load balancing"). Soweit zumindest aus Sicht vom Teaming NIC. Wie weiter oben bereits geschrieben kann es sein dass Switch-seitig Loadbalancing erst ab 4 physikalischen Interfaces geht, ggf. ist das auch eine Default-Einstellung die abgeschaltet werden kann. Das "stp edge-port" interpretiere ich so dass das den Switch anweist, über diesen Port keine BPDUs rausgeschickt werden - und die wären beim Teaming NIC ja wirklich für die Füsse. Was man sich ansehen sollte ist die VLAN-Konfiguration. Oft taggen Switches im Default alle Pakete die über einen Trunk gehen, ein Server kann mit getaggten Paketen aber nicht unbedingt was anfangen ... Gruss Markus
  7. Man müsste etwas mehr über die Netze auf beiden Seiten wissen, Grösse, Architektur ... Der "Ethernet Connect" von der DTAG funktioniert AFAIK als reiner OSI2-Link, d.h. - und das sagt der Name schon - als Ethernet. Daher verstehe ich nicht warum man dafür einen "L3-Switch", AKA "Router", dafür brauchen soll, der spielt auf OSI3. Die Telekom wirbt doch selbst damit dass man keinen Route braucht "Aufwändige Konfiguration von Routern entfällt"?!? Auch wenn es angeblich "einfacher" ist sollte man eine Standortkopplung auf L2 gut planen, man kann sich da eine Menge Probleme kaufen die man auf L3 schlicht nicht hat. Gruss Markus
  8. Du musst die Ports trunken da ansonsten der Spanning-Tree ein Switch-Interface deaktiviert - der sieht nämlich eine MAC-Adresse an zwei Ports was heisst dass das ein redundanter Pfad sein müsste. Ob der 3Com über den Stack weg trunken kann weiss ich nicht. Ob ein 2er Trunk performancetechnisch was bringt weiss ich nicht, es kann - je nach Implementierung - sein dass ein Trunk erst ab vier Interfaces ein Load-Balancing übe alle Pfade macht, alles unter vier Interfaces ist dann reines Fail-Over. Gruss Markus
  9. Unternehmen denken sehr wohl nach wenn sie Cat. 7 verlegen lassen. Bezogen auf 10 GBASE-T hat Cat. 7 den Vorteil dass man damit über 100 Meter kommt während Cat. 6 nur 55 Meter schafft. Ausserdem ist Cat. 7 bis 600 MHz spezifiziert, Cat. 6 nur bis 250 MHz. Da der Trend dahin geht, möglichst viele Dienste auf einem Kabeltypen laufen zu lassen werden heute sogar oft Kabel verlegt die die Anforderungen von Cat. 7 deutlich übersteigen, z.B. Kabel die Frequenzen bis 1400 MHz abkönnen (z.B. Kerpen ELIne 1200 EC7) - oder sogar bis 1500 MHz (Kerpen Megaline G12). Braucht man z.B. wenn man CATV mit auf dem Kabel fahren will - mittlerweile sind wir da bei 860 MHz angekommen. Im Objektbau werden heute in der Regel die besten verfügbaren Kabel verlegt. Im Hinblick auf die durchschnittliche Nutzungsdauer von ca. 20 Jahren die einzig sinnvolle Entscheidung. Der Aufpreis für Cat. 7+ im Vergleich zu Cat. 6 hält sich beim Kabel in Grenzen, das sind ein paar Cent pro Meter (wenn man hochwertige Markenkabel vergleicht) - und man spart eine parallele Verkabelung z.B. für TV. Im Neubau ist der Verlegeaufwand vergleichbar weil es da eine Fachplanung gibt die auch die baulichen Rahmenbedingungen berücksichtigt bzw. von Anfang an beeinflusst und eben dafür sorgt, dass der bauliche Rahmen z.B. bezüglich der Leitungsführung "passt". Teurer ist bei Cat. 7 hauptsächlich das Leitungsende, sprich Patchpanels und Dosen. Bei GG-45 hat man den Vorteil dass auch RJ-45 passt (und den Nachteil dass dann "nur" 600 MHz geht) während man bei Siemon/TERA bis 1200 MHz kann - und dafür dann Patchkabel mit TERA-Stecker braucht. Richtig teuer wird es eigentlich erst wenn man nach ein paar Jahren merkt dass man seinerzeit an der falschen Stelle gespart hat weil jetzt ein Dienst erforderlich wird der über die "billige" Verkabelung nicht gefahren werden kann. Ich kenne einige Unternehmen die in den 90er Jahren die damals "modischen" Splitverkabelungen verlegt haben - damals konnte sich ja keiner vorstellen dass man im Netz jemals mehr als 100 MBit fahren würde - und dafür reichen bekanntlich vier Adern. Also hat man die Cat. 5-Leitungen gesplittet auf 2x4 Adern und da zwei Datendosen hingebastelt für zwei Arbeitsplätze oder für LAN und Telefon an einem Arbeitsplatz. Heute ****en die weil sie über den Murks nicht mal GBit fahren können - und weil es vergleichsweise unendlich teuer ist, in einer laufenden Firma die Kabel zu tauschen - man kann die Leute ja nicht für vier Wochen komplett in Urlaub schicken. Dass man die Kabel bei Cat. 7 nicht "bündeln" darf hat noch andere Hintergründe: Einerseits sind gebündelte Kabel immer mies wenn man aus irgendwelchen Gründen ein einzelnes Kabel nachziehen bzw. ersetzen muss. Andererseits hat man bei Cat. 7 ekelhafte Probleme mit Alien Crosstalk (Fremdnebensprechen) zwischen zwei oder mehreren parallel laufenden / gebündelten Kabeln. Grob gesagt sind die Werte von schön sauber gebündelten und parallel verlegten Cat. 7-Kabeln bei 10 GBASE-T deutlich schlechter als wenn man die Kabel nach dem Spaghetti-Prinzip einfach in die Pritsche schmeisst. Das Prinzip gibt es ja schon seit Jahren in allen Twisted Pair-Kabeln (bzw. deswegen heissen die ja "Twisted") - die Adernpaare sind mit unterschiedlichen Schlaglängen miteinander verseilt um die parallel laufenden Anteile möglichst gering zu halten um dadurch das Nahnebensprechen möglichst zu minimieren. Gruss Markus
  10. Soso. Da wo steht "ip des hostes" steht in der Realität die ÖFFENTLICHE IP des internen Hostes der von aussen erreichbar sein soll? Dumme Frage: Wo sitzt Du eigentlich? Will meinen: Sitzt Du HINTER (INSIDE) der PIX und versuchst dann mit "telnet ÖFFENTLICHEIP 9157" auf den Host zuzugreifen? Falls ja kannst Du heimgehen - und von da aus noch mal testen. Was ich jetzt auch noch nicht verstehe ist wohin Du mit "ftp 21" kommst - da ist doch nirgendwo FTP freigegeben? Liegt die "ip des hostes" im gleichen Netz wie die "ip pix"? Das VPN-Zeugs in der Konfig dürfte übrigens auch nicht funktionieren und die Software ist so alt dass ich sie bis hier her nach einem Update schreien höre. Gruss Markus
  11. Das Einzige was Du musst ist das Handbuch lesen um die Grundlagen zu verstehen. Cryptomaps haben mit dem was Du hier fragst nichts zu tun, aber auch garnix. Static für den internen Host einrichten der von aussen erreichbar sein soll: static (inside,outside) ÖFFENTLICHEIP INTERNEIP netmask 255.255.255.255 0 0 Diese ÖFFENTLICHEIP ist NICHT die IP vom Outside-Interface!!! entweder access-list OUTSIDE-IN permit tcp any host ÖFFENTLICHEIP eq 9157 oder für udp access-list OUTSIDE-IN permit tcp any host ÖFFENTLICHEIP eq 9157 oder für tcp und udp access-list OUTSIDE-IN permit ip any host ÖFFENTLICHEIP eq 9157 Wichtig ist das die ACL auf die ÖFFENTLICHE IP geht, nicht auf die interne, dein IF OUTSIDE weiss nämlich nix von internen IPs. Dann den Schamott aufs Interface binden und freuen: access-group OUTSIDE-IN in interface outside Wenn das nicht geht Konfig posten, bald ist Weihnachten, da wollen wir alle was anderes machen. Gruss Markus
  12. Lass die Finger vom Conduit. Das Ding ist Geschichte und im Prinzip nur noch aus Kompatibilitätsgründen drin. Ganz besonders übel wird das wenn man ACLs und Conduits mischt. Abgesehen davon haben Conduits den Nachteil dass sie Global sind und auf jeglichen Traffic wirken der von einem IF mit niedrigem Security Level kommt, d.h. wenn Du Port 4711 per Conduit erlaubst geht dieser Port sowohl in Richtung Inside als auch in Richtung DMZ auf. Last but not Least: Der Conduit (und sein Gegenstück rauswärts, der Outbound), sind mehr oder weniger mausetot, alle PIX-Releases nach R6.3 kennen diese Befehle nicht mehr - das verkündet Cisco schon seit einigen Jahren und wer R7 kennt weiss dass Cisco da Wort gehalten hat. Die ACLs können alles was man mit Conduit und OUtbound machen konnte - und noch viel mehr - so dass es wirklich absolut keinen Grund mehr gibt, noch Conduits einzubauen. Gruss Markus
  13. Hm, bei unserer Ankage funktioniert das über PPTP (auf PIX 506). Gruss Markus
  14. :suspect: Kommt jetzt der lustige Teil des frühen Samstagmorgens oder willst Du da wirklich eine Antwort drauf? Gruss Markus
  15. Einschränkend möchte ich vorausschicken dass ich seit Jahren mit 3COM-Switches nicht mehr "gearbeitet" habe - wenn ich die in letzten Jahren in der Hand hatte ging es eigentlich nur darum, diese Dinger in die Mülltonne zu befördern. Für den Effekt gibt es möglicherweise eine einfache Erklärung: Viele Switches - unabhängig vom Hersteller - machen bei 2-3 aggregierten Links nur Failover, d.h. eine Verbindung ist produktiv, die andere Verbindung "wartet" nur darauf dass die erste Verbindung kaputt geht und springt dann ein. Der Hintergedanke ist n+1 - und das ist soweit auch sinnvoll. Bei den HP-ProCurves bekommst Du ein Load-Balancing erst mit VIER aggregierten Links, alles was darunter ist läuft im Failover - und das ist hart reinprogrammiert, lässt sich durch Konfigurationsanpassung nicht umgehen. Mag auch sein dass das so im Standard steht, so sattelfest bin ich in LACP nicht. Deine Aussage "Man erhört doch durch LACP die Performance und Ausfallsicherheit." stimmt nur eingeschränkt bzw. basiert im gegebenen Setup auf einem Denkfehler: Wenn Du beide Links saturierst hast Du nur noch eine grössere Bandbreite aber keine Ausfallsicherheit mehr - wenn nämlich ein Link wegbricht passt der Traffic nicht mehr durch den verbleibenden Link- setzen, sechs. Load-Balancing in Verbindung mit einfacher Redundanz kann nur funktionieren wenn der gesamte Load nicht grösser ist als die Kapazität des verbleibenden Links. Wenn wir also annehmen dass Deine Konfig in Ordnung ist kannst Du wohl beruhigt Feierabend machen - mehr gibt die Kiste nicht her. Wenn Du mehr willst musst Du wahrscheinlich noch mehr Links dazu aggregieren. Gruss Markus
×
×
  • Create New...