DocData

Kennen die Systeme, die du anpingen möchtest das Netz, aus dem du heraus die Systeme anpingst? Haben die Systeme für das Netz eine Route oder kennt das Default-Gateway den Weg zu dem Netz, aus dem du versuchst die Systeme anzupingen?

Ansonsten möchte ich dir dringen raten eine systematische Methode, wie z.B. Problemanalyse nach Kepner-Tregoe, anzuwenden. Gerade hinsichtlich der Problembeschreibung dürfte das Klarheit schaffen. Zur Zeit, und aufgrund der Datenlage (die durchaus schlecht ist), gehe ich von einem total trivialen Problem aus.

Warum hast du VRRP konfiguriert, ohne einen zweiten Switch, der auch VRRP kann? Wenn du eine Client an Port 1 vom Testswitch anschließt und diesem die IP 10.115.15.3, sowie als Gateway die 10.115.15.1 gibst, was kannst du dann erreiche und was nicht?

Du solltest dir die NetApp Netzconfig der VIF anschauen in welchem Modus die ist und danach den Cisco konfigurieren.  

Genau.

Hat der NetApp Engineer nicht mit dir gesprochen?

 

Das frage ich mich auch. Es ist normalerweise Sache des Dienstleisters das von mir oben erklärte Wissen zu vermitteln. Es hat offenbar seinen Grund, warum ich so viel zu tun habe...

Na ja, wenn du weißt, nach welchem Prinzip der Verkehr auf die Mitglieder der LAG verteilt wird, dann weißt du auch welcher Hash bei euch der Beste ist. Du kannst ja mal überlegen was passiert, wenn die src-mac für das Hashing verwendet wird. Der gesamte Verkehr von deinem Filer kommt von einer Mac-Adresse, die Ifgrp hat ja nur eine Mac-Adresse. Ergo wird das Hashing immer den gleichen Link in der LAG verwenden. Wenn du dst-mac verwendest, dann ist alles cool, solange Clients und Filer im gleichen VLAN sind. Sobald ein SVI dazwischen ist, ist es auch damit vorbei. Das hat nur eine Mac-Adresse, ergo wird immer der gleiche Link verwendet. In diesem Fall bringt dir auch src-dst-mac nicht viel... Src-ip wäre auch dumm, der Filer wird ja nicht so viele Adressen haben. Versuch es mal mit Dst-ip oder src-dst-ip. Und denk daran, dass der ausgehende Verkehr der Ifgrp auch verteilt werden sollte (-b rr|mac|ip|port)

 

Warum bleibt er nicht physikalisch ? Nur weil er virtuell betrieben wird, ist er nicht weniger anfällig für Viren.

Weil man dann das hässliche Problem der Hardware hat. Und bevor man so eine Kiste versucht auf aktuelle Hardware umzuziehen, dann doch lieber als VM betreiben - sofern supported.

Veeam gibt immer noch NFR Lizenzen raus:

VMware VCP, VCI, and vExpert designations as well as Microsoft MCP, MCTS, and MVP holders to get up to two CPU sockets of Veeam Backup & Replication

Hallo Setzt ihr in eurem Unternehmen VLAN als Sicherheitswerkzeug ein, z.B. für Drucker? Quelle "Drucker sollten eh in ein separates VLAN" http://www.mcseboard.de/topic/197928-2008-r2-nps-und-procurve-8021x-mac-auth/?do=findComment&comment=1229155 Tschüß

Ja. Und der Verkehr wird mittels Datacenter Firewall getrennt.

Es ist common practice, dass man VLANs immer tagged übeträgt. Es ist auch eine gute Idee, dass VLAN 1 (auch wenn man es nicht nutzt), über alle Switches zu ziehen.

Poste mal die Ausgabe von show ip route vom Core Switch und bitte poste ein show running von allen Switches die du da zu verbinden versuchst.

Was erwartest du? Gerade für einen MCSE 2003... Für "Tech VIPs" wird gerne mal was rausgehauen, dazu gehören:

Microsoft MVP,

VMware vExpert,

Citrix CTP,

Salesforce MVP,

ASPInsiders,

Friends of Red Gate,

JavaOne Rock Star,

Sind aber alles Dinge, die man nicht für ein paar Zertifizierungen verliehen bekommt.

Also in meiner Testumgebung läuft alles auf Hyper-V, ich merke schon, das Problem ist das Routing von Subnetz zu Subnetz..

Natürlich, was sonst?

In der Realität sind die DCs zwar alle in einem anderen Subnetz, aber in dem gleichen VLAN, wie kann ich das am realitätsnahsten umsetzen?

Ja und? Das VLAN hat damit wenig zu tun. Wenn die beiden Maschinen in unterschiedlichen Subnetzen stehen, dann brauchst du einen Router, VLAN hin oder her.

Klar, kann man nicht genug Scheine haben, aber die Kosten ......

Was, nur mal so nebenbei, totaler Quatsch ist. Das sind mir immer die liebsten: Haufenweise Scheine aber keine dazu passenden Projekte realisiert.

(M/R)STP und LAGs schließen sich nicht aus. Das hat auch nichts mit KISS zu tun.

Wichtig ist aber die beiden Copperkabel in einen Trunk zu schalten, sonst gibts Loops und nichts geht ;).

Nicht wenn man (M/R)STP aktiviert...

Zumal hier bereits etliche Links zu hilfreichen Seiten gepostet und Lösungsansätzen aufgezeigt wurden.

Ihr habt ein ERP System, dessen Hersteller nicht erreichbar ist, der euch nicht helfen kann und ihr habt auch niemanden der euch Support gibt? Mutig... Was macht ihr, wenn gesetzliche Änderungen eine Anpassung notwendig machen? Oder euch das Ding echt um die Ohren fliegt? Ihr seid euch der Relevanz der im System gespeicherten Daren bewusst?

Statt Troubleshooting würde ich die Zeit in die Evaluation eines neuen Produktes stecken...

SATA II hat eine Bandbreite von 300 MB/s pro Link, also con jeder Platte zum Controller. Bei U320 teilen sich alle Platten die Bandbreite, da es ein paralleles Protokoll ist.

Wie viele Dateien sichert ihr und wie groß ist die durchschnittliche Dateigröße? Die Sicherung von 1 TB bei 4 Mio. Dateien wird sehr viel länger dauern als die Sicherung von 1 TB aus einer Datenbank oder von 200 50 GB Dateien. Zudem wird das ständige Stoppen und Starten des Laufwerkes mit zur schlechten Performance beitragen. Ihr müsst das LTO Laufwerk konstant mit Daten füttern.

Docdata,

Ich bitte dich nicht zu urteilen wenn du nicht die ganze Geschichte weißt. Sie ist ein wenig breiter als nur "ich kenne mich mit LANCOM nicht aus". Aber in jeden thread alle umstände zu beschreiben ist nur mühsam.

Das ist der Nachteil dieses Mediums. Dann moniere aber nicht, dass jemand sich aufgrund deiner dargelegten Faktenlage ein eigenes Urteil bildet. Und es ist sehr unhöflich jemandem seine Meinung zu verbieten. Dann lege alle Fakten auf den Tisch und erlaube mir die Neubewertung. Anderfalls bleibe ich bei meinem Urteil.

Die Tatsache ist, wenn es geht, werde ich mit der LANCOM auseinander setzen. Brauche aber dafür Hilfe. Wie oben gesagt, müssten wir Richtung fremde Firmen gehen, da der Typ der es bei uns eingerichtet hat die Einstellung hat "ich mache es, aber sage nicht wie". Die Info habe mir nicht ausgedacht sondern vom GF persönlich bekommen.

Vom Fortigate habe ich einen Nachbar der sich damit auskennt und seine ganze Firma auf FG setzt.

Und einen neuen Router brauchen wir sowieso, da wir vermutlich 3 WAN Ports brauchen.

Mal sehen wie es hier weiter geht.

Du hast also einen Dienstleister, der sich mit LANCOM auskennt, aber sein Knowhow nicht weitergibt und einen Dienstleister der sich mit Fortigate auskennt und scharf auf einen Neukunden ist. Das nenne ich mal Auswahlmöglichkeiten...

Es sind also offenbar weniger technische Fakten die deine Entscheidung lenken, als viel mehr das Bauchgefühl, dass die dein Nachbar mit seinem Arbeitgeber schon helfen werden, wenn es notwendig ist.

Wenn du aber unbedingt ne Fortigate willst, deinen Nachbar mit ins Boot holen willst und die Firma unbedingt Geld ausgeben möchte, dann tut es doch einfach..

Genau das denke ich mir auch.

Was ist denn das Kernproblem? Dir Bandbreite zwischen den Standorten? Was wird denn so an Bandbreite genutzt? Eine andere Möglichkeit wären WAN scaler auf beiden Seiten, die den Datenstrom transparent komprimieren. Oder halt sowas wie BranchCache, was vor allem beim Arbeiten mit Office Dateien gute Dienste leisten dürfte.

DFS wäre okay, aber nur bei zwei Standorten, also auch zwei unterschiedlichen Subnetzen. Innerhalb eines Standortes gibt das nur Ärger, da DFS keine File Locking Informationen pflegt und "Last write wins".

Möglicherweise ein Szenario für BranchCache.

Ehrlich gesagt verstehe ich das Problem nicht. Wenn ich die Basics verstanden habe, dann ist der Rest Syntax, den ich im Zweifel im Handbuch nachschlage. Dann ist es mir egal ob ich da Cisco, LANCOM, Fortigate oder Systeme von Juniper habe.

Wenn dem TO LANCOM nicht gefällt und er lieber Fortigates verwenden möchte, dann soll er das bitte tun. Ich behaupte, ohne es geprüft zu haben, dass LANCOM, auch in Österreich, weiter verbreitet sind als Fortigate Produkte.

Für mich lesen sich die letzten Beiträge eher wie eine krampfhafte Suche nach Argumenten gegen LANCOM und für Fortigate oder ein anderes Produkt. Das Kernproblem ist aber wohl viel eher, dass der TO wenig Erfahrung hat und seitens der Geschäftsführung ein Argumentationsproblem hat.

Hallo. Normalerweise brauchst du dann für einen Exchange intern andere Zertifikate. Ich würde das gleiche Zertifikat nicht intern UND extern nutzen. Intern tut es wohl auch ein über die eigene, interne CA ausgestelltes Zertifikat.

Ein IRF Verbund ist logisch wie ein Switch zu behandeln. Wenn du also zwischen deinem Distribution-IRF und Access-IRF zwei Leitungen hast, dann brauchst du (R/M)STP. Sind die beiden Leitungen eine LAG/ Trunk, dann brauchst du kein (R/M)STP. Grundsätzlich ist es aber eine gute Idee (R/M)STP zu aktivieren, aber bitte wirklich nur RSTP oder MSTP und dann auch darauf achten, dass nur die Uplinks mit eingezogen werden, keine Edge-Ports.

Soweit mir bekannt ist, ist NAT offiziel von Microsoft nicht unterstützt.

Na ja, sie haben es nicht getestet, sie empfehlen es nicht und es wird nur eingeschränkt supported. Siehe KB978772.

Zwei Möglichkeiten:

1. IP Subnetz auf einer Seite ändern. Ist, je nach Größe, aufwendig und fehleranfällig. Aber langfristig werdet ihr da nicht herumkommen.

2. NAT. Funktioniert auch mit überlappenden Netzwerken. Wäre zum Beispiel schnell und einfach implementiert, wenn ihr die Netze per VPN verbindet.

Es ist die Frage was du daraus machst. Als SE in einem Systemhaus wärst du evtl. aufgeschmissen, als Administrator bei einem Schulungsanbieter nicht. Interessant wäre möglichweise ein zweiter Weg: Trainer. Über den Weg gibt es oft den brückenschlag ins Consulting, da das eine oder andere Beratungshaus auch Training/ Workshops anbietet und mache Trainingsanbieter auch Consulting machen. Über diesen Weg wären dir nach einigen Jahren sicherlich unterschiedliche Wege offen. Bis dahin heißt es: Berufs- und Projekterfahrung sammeln. Um den Einstieg zu finden ist es oft besser sich auf das zu besinnen, was man hat. Führe die Zertifikate im Lebenslauf auf, lege sie der Bewerbung bei. Klasse statt Masse. Und suche nach Junior-Stellen. Vermeide Personaldienstleister.