Sailer

Oh, selber Gedanke zur selben Zeit :D

Naja, beim Small Business Server packen sie ja auch alles auf einen Server. Das hängt halt immer von der Anzahl der User ab die man mit den Servern zu bedienen hat und natürlich von der Hardware-Performance. Beim SBS sind imho 75 User möglich.

Hallo Leute, ich hab da mal eine Verständnisfrage bezüglich "Microsoft Connector für POP3-Postfächer" Sehe ich das richtig, dass man damit nur bestehende pop3-Accounts abrufen, nicht aber damit senden kann? Hab ursprünglich angenommen man könnte damit quasi einen Exchange-Server einführen ohne alle Postfächer umstellen zu müssen bzw. sich mit seinem Internet/Email-Provider kurzschließen zu müsen. Beim Testen musste ich aber feststellen, dass ich so zwar pop3-Accounts abrufen, nicht aber Mails nach extern senden kann... (könnt natürlich auch ein Konfig-Fehler meinerseits sein, hab aber auf die Schnelle nichts gefunden)

Wizzard für Standorte hab ich beim SBS keinen entdeckt -> wird bei einem SB wohl nicht angenommen :wink2: Die Settings kann man aber bestimmt händisch auch machen, werd mir das noch ansehen und dann hier Bescheid geben.

Habe das jetzt noch mal auf einem frisch aufgesetzten SBS ausprobiert (also vorher nix manuell verstellt) Bevor ich den Zugriff vom Internet auf alle Websites zugelassen habe, war bei allen Pages eine Beschränkung aufs Server-Subnet. Nach dem Wizzard waren alle Beschränkungen weg, außer beim ConnectComputer :rolleyes: Naja, das ist ja auch gleich umgestellt. @Mike Danke jedenfalls für den Tip -> sollte es keine weiteren automatischen Beschränkungen geben, war das bestimmt des Rätsels Lösung! :)

Hi Mike, ja, bei dem Punkt haben meine Augen auch zu funkeln begonnen :D Nachdem der Wizzard durch war musste ich aber mit Bedauern feststellen, dass im ISS die Beschränkung wieder auf das Server-Subnet gesetzt wurde (ich hatte sie vorher manuell um die anderen Subnetze erweitert) Ich denke die Konfig im Wizzard bezieht sich wohl auf die Webmail und VPN-Settings?!?! Das ist beruhigend! Ich halte den SBS zwar immer noch für suspect (hab eine Automatismus-Paranoia :D ) aber deine Aussage lässt mich doch etwas ruhiger schlafen ;)

-> Ein über drei Gebäude verteiltes LAN -> Jedes Gebäude hat ein eigenes Subnet für die Clients -> Der Server befindet sich in Gebäude 1 hat aber ein eigenes Server-Subnet -> Geroutet werden die Subnetze über einen Cisco C3560 auf dem "ip routing" aktiviert wurde Ja, können sie. Wie gesagt, es gibt keine Netzwerkprobleme. Servergespeicherte Profile, AD-Authentication, Shares... funktioniert alles wunderbar. ABER: Mir ist aufgefallen, dass der Link http:\\server\connetcomputer nicht funktioniert. Das liegt daran, dass in den IIS-Settings automatisch eine IP-Beschränkung gesetzt wurde die es nur dem Server-Subnet ermöglichen würde diesen Link zu erreichen. Meine Befürchtung und Frage zugleich ist daher: Setzt der SBS auch noch in anderen Konfigurationen solche Beschränkungen automatisch? Wenn ja, wo? Und gibt es eine Möglichkeit dem SBS irgendwo zentral zu sagen, dass es die andere Subnetze auch noch gibt und er diese bitte bitte bitte in sämtlichen Konfigurationen nachtragen soll? Schlussfolgerung: Die Beschränkug der Website war offensichtlich und kann relativ einfach erweitert werden. Andere Probleme habe ich z.Z. nicht, nur eine Befürchtung, dass es durch weitere automatische Beschränkungen, noch zu weniger offensichtlichen Problemem kommen könnte.

Wenn meine Frage missverständlich formuliert ist tut es mir leid? Trotzdem bin ich davon überzeugt, dass die Umbenennung von 10.1.x.x, 10.2.x.x usw in 10.0.0.0, 20.0.0.0 nichts verkompliziert sondern vereinfacht (dein Vergleich mit Auto und Frau ist also eher peinlich :rolleyes: )

Danke für den Tip! Hab den Assistenten gerade noch mal durchgeklickt aber da gibts leider keine Abfrage nach zugelassenen Subnets :( Hast du auch schon mal einen SBS mit mehreren Subnets aufgesetzt? Sind dir außer beim IIS keine Beschränkungen aufgefallen bzw. Probleme die auf unterschiedliche Subnets zurückzuführen sind?

Hmm, gute Idee... das werd ich mir mal ansehen. Danke für den Tip!

Dieser Thread verkommt langsam zu einen Netzwerk-HowTo :) Nein, ich verwende z.B. 10.1.1.x, 10.1.2.x, 10.1.3.x aber der Einfachheit halber nenne ich sie hier 10, 20, 30... Bitte glaubt mir einfach, dass ich weiß wie man ein Netzwerk aufzieht ;)

*seufz* Also noch mal bezüglich L3 Device, damit du mir endlich glaubst, dass im Netzwerk alles ok ist: +Cisco 3560 +mehreren "interface vlan xxx" +die Ports sind auf die jeweiligen VLANs verteilt +ip routing" ist enabled. +alle Clients/Server haben korrekte Subnetmasks und Gateways eingestellt. (soviel zur Konfiguration) Nein, ein SBS ist defaultmässig eben nicht so wie jeder andere Server auch. MS hat jede Menge Wizards und Vorkonfigurationen dazugepackt und genau darum gehts -> Voreinstellungen die mir nicht ganz passen Wie im ersten Thread schon erwähnt funktioniert z.B. der Link http://server/connectcomputer'>http://server/connectcomputer nur im Subnet des SBS. Der Grund dafür ist mir klar und wie man das ändert weiss ich auch (Internetinformationsdienst -> Eigenschaften der Website -> IP-Beschränkung anpassen) Damit habe ich aber nur ein Feature für andere Subnetze ermöglicht. Meine Frage ist daher nach wie vor: 1) Gibt es eine Möglichkeit dem SBS einmal zu sagen, dass es Subnet 1, 2, 3... auch noch gibt und er sämtliche voreingestellten Beschränkungen die es sonst noch irgendwo geben könnte für die Netze aufhebt? 2) Dass die Website http://server/connectcomputer nicht funktioniert fällt relativ schnell auf, ich befürchte aber, dass auch andere, weniger offensichtliche Probleme auftreten können wenn Clients in anderen Subnetzen sind. Kann mir dazu jemand was sagen, gibts vielleicht eine komplette Auflistung? @MikeKellner: Danke, dass du versuchst hier zu helfen aber bitte verbohr dich nicht weiter ins Netzwerk, darum gehts wirklich nicht. :wink2:

@MikeKellner Schon mal was von genau lesen gehört? ;) @all: Also es handelt sich hier um kein Routing-Problem -> Routing zwischen den Subnets funktioniert wunderbar. Auch die meisten anderen Features des SBS sind im gesamten Netz verfügbar. Es geht mir also nur darum ob man dem SBS auf einfache Weise beibringen kann, dass mehr als nur sein eigenes Subnet dazugehört und somit für manche Features freigeschalten sein soll. Hoffe da kann mir jemand weiterhelfen :(

Hallo! Ich habe ein bestehendes Peer2Peer Netzwerk mit einem SBS2003 versehen. Vereinfacht sieht das jetzt so aus: Server-Subnet: 10.0.0.0 Client-Subnet#1: 20.0.0.0 Client-Subnet#2: 30.0.0.0 Also wie ihr seht befinden sich der Server und die Clients in verschiedenen Subnets und kommunizieren über ein L3 Device. Nun zum "Problem": Ich musste feststellen, dass SBS wohl standardmässig davon ausgeht, dass sich Server und Clients im selben Subnet befinden. Folglich sind einige Funktionen nur im Server-Subnet möglich z.B. Clients über http://server/connectcomputer in die Domäne hängen. Kann mir vielleicht jemand sagen ob man dem SBS auf einfache Weise beibringen kann, dass es mehrere "befreundete" Subnetze gibt und er sämtliche Beschränkungen dahingehend ändern soll. Vielleicht hat auch jemand einen Übersicht, welche Features noch nur im eigenen Subnet funktionieren... hab dazu nichts vollständiges gefunden Besten Dank! Sailer

hi, wie siehts auf den clients aus. habt ihr überprüft ob auf allen Subnetmask und Gateway richtig konfiguriert sind? Habt ihr in jedem Subnet schon versucht ob ein "ping" auf das eigene Gateway und auf die anderen Gateway-IPs am Cisco funktionieren? Bzw. noch wichtiger, funktionieren Pings zu anderen Geräten im eigenen Subnet? Gruß Sailer

Na dann lass uns doch auch wissen wies funktioniert bzw. wo der Fehler lag :wink2:

na bestens ;) Gruß Sailer

Hallo Vircon, willkommen im/an Board! :) *Ist Port 1 ein L3 Port -> also "no switchport"? *Falls es ein L3 Port ist, hast du den DHCP-Server als IP-Helper angegeben? *Funktioniert das ganze ohne ACL? Gruß Sailer

stimmt, zum reinen switchen braucht sie der Switch nicht da er für die Netzwerkclients vollkommen transparent arbeitet.

NBMA ist z.B. ein FrameRelay Netzwerk Da in einem solchen Netz keine Broad- und Multicasts möglich sind, muss OSFP dort die Hellos usw. die es mit den Neighbors austauscht als Unicast senden (anstatt als Multicast)

In welchem Club? "Club der konservativen Dynamik Verweigerer"? :D Bezgl ISL: Eingeplant muss es wohl irgendwo gewesen sein sonst hätten sie wohl nicht 15 Bit reserviert. Aber vielleicht sind sie nach ein paar Monaten drauf gekommen, dass niemand jemals 32000 VLANs brauchen wird bzw. aus Performancegründen nicht supportet werden kann :p

Gratuliere zur bestandenen Prüfung! :)

Hallo! Hmm, da steht aber auch nicht drin wofür die restlichen 5Bit vom VLAN-Feld sind Eines der letzten Rätsel der Menschheit :) --> konfigurierst du auf jedem trunk oder access port switchport nonegotiate? Ja natürlich. Klingt vielleicht ein bisschen konservativ aber ich mag Dynamische Protokolle nicht besonders (außer beim Routing :p )-> ein Trunk soll ein Trunk sein, ein Access-Port ein Acces-Port, ein Channel ein Channel... Und wenn sich daran was ändert dann weils der Admin so wollte. Auf Links zwischen Switches drehe ich daher immer alle dynamischen Protokolle ab (DTP, LACP,...) Auf Access-Ports beginne ich die Konfiguration mit "switchport host" dann wird sowieso schon mal alles abgedreht was ein Host nicht braucht und STP-Portfast enabled. Das verkürzt übrigens die Zeit bis ein Host einen Link bekommt noch mal um ein paar Sekunden (also ich meine zusätzlich zum "STP-Portfast")

hallo daking, danke für den ausführlichen Bericht. Jetzt weiß ich auch endlich was der Unterschied zwischen PVST und PVST+ ist. Das konnte mir bisher noch niemand so recht beantworten :-) Was die Anzahl der möglichen VLANs angeht hab ich mich wohl geirrt -> Sorry für die Fehlinformation!!! Zu meiner Verteidigung muss ich aber sagen, dass ISL ein 15Bit Feld für die VLAN ID vorsieht (also über 32000 Werte). Hab aber auch noch mal in den BCMSN-Unterlagen nachgelesen und dort heißt es, dass davon nur die ersten 10 Bit verwendet werden. Begründung gibts dafür keine :-( Bezüglich Encapsulation: Auch wenn in dem Text beide Protokolle als Encapsulation bezeichnet werden stimmt das für dot1q schlichtweg nicht. Eine Encapsulation setzt einen neuen Header vorraus, dot1q fügt aber nur ein zusätzliches Feld in den bestehenden Header ein. Zum VLAN-Hopping noch mal: Das beschriebene Verfahren (DTP ausnutzen) funktioniert natürlich für dot1q und ISL. Wer Hackern VLAN-Hopping auf diese Art ermöglicht ist aber selber schuld und hats verdient :-) Wirklich gehoppt wird bei dieser Variante auch nicht weil der Angreifer dann von vorn herein schon in dem VLAN sitzt das er angreifen will. "Echtes" VLAN-Hopping ist allerdings nur auf einem dot1q Trunk möglich da dabei die Eigenheit von dot1q ausgenutzt wird, dass das native VLAN unveränderte (untagged) Frames überträgt. Diese Eigenheit gibts bei ISL halt einfach nicht! Gruß Sailer

@rblasey Hab's mir zu Herzen genommen und noch mal recherchiert ;) Auf der Cisco Seite habe ich folgendes gefunden: Understanding Spanning-Tree Protocol Bridge Protocol Data Units (BPDU) The stable active topology of a switched network is determined by the following: *The unique switch identifier (MAC address) associated with each switch. *The path cost to the root associated with each switch port. *The port identifier (MAC address) associated with each switch port. (Quelle: http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/sw_ntman/cwsimain/cwsi2/cwsiug2/vlan2/stpapp.htm) Die Port MAC-Adresse spielt also auch bei STP eine Rolle. @sgabriel Hab beim Suchen auch noch was bezüglich deiner ursprünglichen Frage gefunden: Die Port-MACs werden auch für sämtliche andere Kontroll-Pakete (CDP, LACP, ...) verwendet. Gruß Sailer