Blacky_24

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

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

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

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

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

Ü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

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

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

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

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

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

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

Hm, bei unserer Ankage funktioniert das über PPTP (auf PIX 506). Gruss Markus

:suspect: Kommt jetzt der lustige Teil des frühen Samstagmorgens oder willst Du da wirklich eine Antwort drauf? Gruss Markus

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

Der QoS-Dienst bzw. der QoS-Paketplaner bewirkt eigentlich gar nix ausser dass er Ressourcen frisst. "Brauchen" kann man das Gerödel erst wenn das gesamte Netzwerk QoS-fähig gemacht hat, d.h. wenn da irgend was im Netz ist was mit 802.1p und DSCP umgehen kann. Auf der anderen Seite brauchst Du auf XP dafür Apllikationen die in der Lage sind, dem OS über die QoS-API mitzuteilen dass diese bitte soundsoviel Bandbreite reservieren möchte. Ich kenne keine Applikation die das macht. Wie ich schon schrub: DEN Schalter gibt es da nicht. Wenn das Problem ungefähr da liegt wo ich es vermute wird die Lösung wahrscheinlich nicht ganz billig. Gruss Markus

Ich fürchte, DEN Schalter gibt es da nicht. Ihr habt mit einer gewissen Wahrscheinlichkeit ein Bandbreiten- und Geschwindigkeitsproblem. Ggf. kann man das lösen, ggf. nicht oder nur mit enem grösseren Aufwand, hängt von der Gesamt-Infrastruktur ab. Ansetzen kann man z.B. bei den Codecs und bei der Priorisierung des Voice-Traffics. Ferndiagnostisch mit den gegebenen Informationen konkrete Aussagen zu machen wäre irgendwas zwischen sinnfrei und unseriös. Aufgrund gemachter Erfahrungen in diversen Kundenprojekten empfehle ich Euch eher, für zwei oder drei Manntage einen Fachmann ranzuholen der sowas schonmal gemacht hat, der kann Euch dann fundiert sagen woran es hakt und wie man das beheben kann. Gruss Markus

Infos zur Zertifizierung gibt es z.B. bei Cisco CCNA-Career Certifications & Paths - Cisco Systems Die Prüfungen kann man z.B. bei VUE Pearson VUE: Computer-based testing solutions for high stakes certification and licensure test delivery machen - "Test Taker Services" -> "Locate Test Centers" - kann man sich länderweise anzeigen lassen welche Testcenter es gibt. Altersbeschränkung gibt es AFAIK keine, AFAIR ist der jüngste CCNA 13 oder 14 Jahre alt. Kann sein dass man unter 18 irgendeinen Schrieb von den Eltern braucht, soweit ich weiss geht die Anmeldung nur mit Kreditkarte, die kriegt man i.d.R. auch erst mit der Volljährigkeit - oder die Eltern rücken ihre raus. Gruss Markus

Damit kannst Du zwischend den VLANS bzw. den VLANs und anderen Netzen routen. Gar nicht. IPSec funktioniert ausschliesslich auf OSI Layer 3 (und ggf. höher) während VLANs eine Funktion auf Ethernet und somit auf OSI Layer 2 sind. Wenn Du Layer 2-Funktionalitäten durch ein WAN transportieren willst brauchst Du dafür zwangsläufig einen Transportmechanismus der mit Layer 2 umgehen kann, z.B. L2TP (wie der Name schon sagt ...). Es gibt nur sehr wenige Argumente für eine solche Konstruktion. Oftmals wiegen die Nachteile deutlich schwerer als der Nutzen. Warum müssen die VLANs (100?) nativ miteinander kommunizieren? Reicht es nicht aus, IP-Netz mit IP-Netz miteinander kommunizieren zu lassen? Gruss Markus

Brauchbare deutsche Cisco-Bücher sind mir noch nicht untergekommen. Meine Cisco-Bibliothek dürfte bald 4 Meter im Regal einnehmen, wenn da 10 deutsche Bücher dabei sind ... Die deutschen Übersetzungen der Cisco-Press-Bücher erscheinen bei Markt & Technik. Ganz vorsichtig gesagt halte ich die Übersetzungen für nicht wirklich gelungen. Die Fachsprache der IT ist und bleibt nun mal Englisch, wer in der Branche was werden will sollte sich damit anfreunden, die Lektüre englischer Fachbücher ist da sicher nicht das Schlechteste. Für den Erwerb englischer Bücher sollte man um den deutschen Buchhandel einen grossen Bogen machen. Ich habe es mehrfach erlebt dass dort Preise aufgerufen werden die umgerechnet beim Doppelten des aufgedruckten Preises liegen. Frechheit in Potenz. Zumindest VOR dem Bestellen fragen was das Buch am Ende kosten wird, wenn die dann rumeiern wegen Wechselkurs und Gezeitenhub besser nicht bestellen. Eine gute Quelle ist ebay.com, dort kann man englische Cisco-Bücher billigst kaufen und die Versandkosten liegen teilweise bei einem Bruchteil von dem was man bei Amazon.com bezahlen müsste. Gruss Markus

Habe keine Eumex, habe Elmeg. Ich denke, es reicht, beiden ISDN-Ports jeweils eine Rufnummer (Durchwahl) zuzuweisen. Testweise ist es immer nützlich, ein oder zwei alte, billige ISDN-Telefone zu haben. Wenn man vom einen Telefon das andere anrufen kann sollte es auch mit Cisco klappen. Gruss Markus

:jau:

Kannst Du mal die ganze Konfig posten so dass man sich da mal einen Reim drauf machen kann? "sh tech" im Terminal und den Config-Part rauskopieren, da sind dann alle Kennwörter schon unleserlich gemacht. Gruss Markus

Besserwisser findet man überall, Bessermacher leider nur selten. Wie sagt ihr den Avayas denn wie sie den Traffic auf welchem Port taggen sollen? Die Besserwisserkonfig läuft darauf hinaus, mit der Hand am Arm einen Trunk zu konfigurieren - allerdings muss man dem Switch dann immer noch irgendwo sagen welches VLAN denn bitte das Voice-VLAN sein soll - oder man geht eben hin und bastelt sich was Schönes mit QoS, das ist aber eine ganz andere Baustelle und die hat ein paar böse Stolperfallen. Normalerweise - ich sage das nur ganz leise - reicht es in einem gut gebauten Netz (LAN!) vollkommen aus, den Traffic einfach nur in ein eigenes VLAN zu packen - wenn man überhaupt den Aufwand betreiben will. Gruss Markus

Aaaarg. CDP ist proprietät, deswegen fängt das ja auch mit "C" an. CDP gibt es schon seitdem ich mit Cisco arbeite, also seit über 10 Jahren. Abgesehen hat Cisco CDP auch an andere Firmen lizenziert, z.B. an HP (in einigen besseren ProCurve-Switches implementiert). CDP ist aber ganz sicher keine Untermenge von LLDP - kann es allein vom Zeitablauf her nicht sein. Cisco hat mit CDP schon das VLAN-Autoassignment gemacht als das Reisekomitee für LLDP noch mit der Trommel um den Christbaum gerannt ist. LLDP heisst neudeutsch auch 802.1AB und wurde 2005 standardisiert (von der IEEE wie an der Nomenklatur unschwer erkennbar ist). Der neueste Gag heisst LLDP-MED und wurde erst 2006 standardisiert - diesmal von der TIA. Ohne die Glaskugel zu polieren prophezeie ich mal dass es da bald die schönste Konfusion geben wird. Cisco hält sich da im Moment vornehm zurück. Einerseits hat Cisco mit CDP ein funktionierendes Protokoll und andererseits ist die ganze LLDP-Geschichte derzeit noch ziemlich konfus. Lieber abwarten bis sich das stabilisiert hat und dann einbauen als sich eine Dauerbaustelle zu kaufen. Gruss Markus