Sailer

Werde ein batch bauen und diese ausführen lassen per GPO.

Warum willst du dafür einen Batch schreiben? Du kannst doch per GPO einstellen wann die Clients den Statusbericht senden und nach neuen Updates suchen sollen

Gibts da irgendeine Gesetzmäßigkeit was per WSUS kommt und was nicht?

Hallo lefg,

führe am Client in der Comandline "wuauclt.exe /updatenow" aus. Der Statusbericht wird dann innerhalb von ein paar Minuten erstellt und an den WSUS Server gesandt (ist ein variabler Bereich 5-10Minuten, soviel ich weiß)

Wie hast du festgestellt, dass STP über diesen Switch läuft?

STP blockt einen Link nur auf einer Seite d.h. es kann sein, dass am roten Switch beide Ports auf "forwarding" sind und dafür einer seiner Nachbarn den Link zum roten Switch auf "blocking" gesetzt hat.

Vielleicht erweiterst du dein Bild um Switchname und Interfacebezeichnungen und postest hier mal ein "sh spanning-tree" von jedem Gerät.

Da ist schon klar. Wir befinden uns bei der Problematik schon in einem VLAN.

 

Problem ist halt das ein Switch mit der Prio 50000 zwei Switche mit der Prio 5000 verbindet, anstatt diese über die höchste Hierarchie Ebene, den beiden Layer 3 Switchen mit den Prios 1000 und 2500 verbunden sind.

Vielleicht kannst du uns das mal mit einer Grafik verdeutlichen.

Da Cisco ein PVST macht, muss die STP-Priorität pro VLAN angegeben werden.

Dadurch ist es durchaus möglich, dass Switch-A STP-Root von VLAN1 ist und Switch-B STP-Root von VLAN2.

Mit "show spanning-tree" bekommst du die STP-Einstellungen pro VLAN angezeigt. Da siehst du auch welche MAC-Adresse der Root hat, welcher Port "root-port" ist und mit welchen Kosten er vom momentanen Switch aus erreicht werden kann.

Wenn du dir sicher bist, dass die Prioritäten alle richtig vergeben wurden, kann es vielleicht sein, dass du einfach beim falschen VLAN nachgesehen hast? -> VLAN1 gibts immer, wird aber normalerweise aus Sicherheitsgründen nicht verwendet

hab gerade auch gehört das es von "phion"(Tochterfirma von Cisco?) einen Router mit integriertem SIM Einschub gibt aber nichts konkretes und auch keinen Preis.

Phion eine Tochter von Cisco? Na die werden sich freuen wenn sie das lesen :D Phion ist eine eigenständige Firma und klare Konkurenz (verzeihung, "Mitbewerber") von Cisco.

Das ist eigentlich eine Firma die Firewall Software entwickelt und dann teilweise auch mit Hardware bundled.

Hab von denen mal so ein UMTS-Teil gesehen, kostet aber (weil inkl. professioneller Firewall Software) sicher €500,- aufwärts, denke das ist nicht das wonach du suchst, oder?

Nu hab ich hier son unschönen Foundry-HSRP Cluster der mir bei traceroute die virtuelle IP anzeigt....das ist doch nicht regelkonform oder ???:)

Dein "Problem" hat seine Vor- und Nachteile. Natürlich bekommt man bei Cisco schnell heraus welches GW gerade aktiv ist aber andererseits kann so auch jeder gleich die Interface Adressen eines HSRP-Routers erkennen... Sicherheitstechnisch vielleicht eher von Nachteil ;)

Na na na... wer wird denn wegen einer verkonfigurierten Firewall gleich den ganzen Server neu aufsetzen? :D

In einem der ersten Postings schreibst du:

Apropos Firewall: wo sehe ich denn beim SBS, welche Ports/Verbindungen zugelassen werden? Ich habe letztens mit einer Gruppenrichtlinie ein paar Firewallregeln definiert - kann's daran liegen?

das widerspricht sich doch mit deinem letzten Posting:

Na ja, ich hab's garantiert nie in einer GR festgelegt, trotzdem kann ich nicht auf die FW zugreifen

:suspect:

Naja, sonst mal über Security Center versuchen... ehrlichgesagt hab ich noch nie auf einem Windows Server eine Software-Firewall aktiviert (und würde es auch niemandem empfehlen), kann also nicht gerade aus Erfahrung sprechen :wink2:

Systemsteuerung -> Windows Firewall -> dort unter "General" gibt es die zwei Punkte "on" und "off"

Wenn du das allerdings per Policy konfiguriert hast wirst du u.U. keinen direkten Zugriff darauf haben sondern musst den Eintrag in der Policy umkehren.

Habs mal geuppt

Danke, werds mir bei Gelegenheit mal ansehen

Ich kann den Server NICHT anpingen (...)

Umgekehrt kann ich jedoch vom Server aus die Clients anpingen

Das klingt eindeutig nach Firewall, du hast dir bestimmt (versehentlich) die Firewall am Server dicht gemacht!

Deaktiviere mal die Firewall am Server und schau ob dann wieder alles so funktioniert wie es soll -> so kannst du das Problem schon mal recht flott eingrenzen

Könnte mir vorstellen du hast jetzt irgendwelche Firewall-Setings von wegen "sämtlichen Zugriff von aussen blocken"

stimmt doch nicht, die MAC von sft bleibt immer gleich und er aendert die MAC's von den NIC's ... noch besser! ;)

Na wunderbar, dann gibts auch keine Probleme bzgl. ARP

Was ist "iANS"? Eine Software von Intel für Intel oder hast du da ein Tool gefunden das mit den verschiedensten NICs klar kommt?

Leider ist deine Skizze noch ncith freigeschalten aber so wie du die Topologie beschreibst sollte das mit dem Stack klappen und mach Sinn (sofern wir von C3750ern sprechen???)

Ein echter Stack ist genaugenommen ein Zusammenschließen der Backplanes aller beteiligten Switches. Dadurch entsteht ein logisches Gerät d.h. ja du kannst dann auf zwei der vier Uplinks verzichten. Den Stack solltest du natürlich redundant ausführen also zwei Stackingkabel zwischen den Switches anstecken!

Mit "echter Stack" meine ich übrigens das was die Cisco 3750er Serie bietet. Für die C35xx Serie gibts nämlich auch "Stacking Module" -> ist allerdings nichts anderes als ein GigaPort mit STP und meiner Meinung nach nicht ratsam!

Bedeutet das jetzt wenn ich "deutsch" angebe falle ich auf jedenfall als Beta - Tester raus oder überlegen die dann, doch eine Version in deutsch anzubieten?

Tja, die gleiche Frage habe ich mir eben auch gestellt...

Bin dann doch kein Risiko eingegangen und hab "English" gewählt :D

Hallo,

 

die Lösung heisst "fault tolerance" wie Sailer schon vermutet hat, habe einen Speziallisten bei mir in der Firma gefragt. Es gibt Tools, damit kann man sowas einrichten.

d.H. Wenn ein Link ausfällt greift die andere NIC ein.

 

Danke nochmal für die Unterstützung

 

Laubi

Oh, diesen Eintrag von dir hab ich überlesen... na dann ist ja alles klar.

Viel Glück noch!:wink2:

Unter Netzwerkbrücke meinte ich, im Windows unter Netzwerkverbindungen --> beide LAN Verbindungen markieren -->Rechte Maustaste -->Netzwerkbrücke

Genau was ich meinte -> damit schickst du alles was bei der einen NIC reinkommt bei der anderen wieder raus und produzierst in weiterer Folge einen Loop.

Aber ich denke das sollte die Lösung sein

 

Zitat von Sailer:

Normalerweise sollte eine Karte aktiv sein und die andere standby bis sie gebraucht wird

Eine aktiviren, einde deaktivieren und dann manuell umschalten ist keine echte Lösung. Hilft zwar einen Fehler schnell zu beheben aber bietet null Automatismus -> wer macht die Umschaltung für dich bei einem Ausfall um 2Uhr in der Früh :D

Server-NICs unterstützen i.d.R. schon genau was du vor hast (zwei Karten auf zwei Switches und bei Bedarf automatisch umschalten) Das solltest du dann aber mit einem Tool vom NIC-/Server-Hersteller konfigurieren können.

Kann nicht ausschließen, dass dein NIC-Hersteller dieses Feature "Netzwerkbrücke" nennt aber unter "Bridging" hätte ich eher das weiterleiten von einer Karte auf die andere verstanden -> normales Windows Feature, hat aber nichts mit Redundanzbildung zu tun!!!

Das würde nämlich auch erklären warum deine Switches verrückt spielen (Loop durch den Server) und warum die MAC-Adresse auf zwei Ports auftaucht.

Normalerweise sollte eine Karte aktiv sein und die andere standby bis sie gebraucht wird

hallo laubi,

nun, ein switch speichert immer eine MAC-Port-VLAN Beziehung ab (VLAN nicht jeder Hersteller). Somit kann ein Switch mit einer MAC-Adresse, die zwischen zwei normalen Ports hin und her springt, einfach nicht klar kommen.

Was du hier ansprichst ist ein "EtherChannel" -> mehrere Ports zu einem logischen Port zusammenfassen um die Bandbreite zu erhöhen und Redundanzen zu schaffen. Eine solche Konfiguration ist allerdings nur auf einem Switch möglich (also nicht ein Link auf SwitchA und der andere auf SwitchB) Eine Ausnahme wären zwei gestackte Cisco 3750er (wobei Stacking wieder ein logisches Gerät hervorbringt)

Was du aber vermutlich machen kannst wäre die beiden Karten am Server zu einer logischen Karte zusammen zu fassen, die eine ist aktiv und wenn diese ausfällt wird die andere aktiviert-> könnte z.B. unter dem Begriff Adapter-Teaming laufen (aber das nennt auch wieder jeder Hersteller anders)

Willst du beide gleichzeitig aktiv haben (um die Bandbreite zu erhöhen) dann müsstest du den besagten EtherChannel am Switch und am Server konfigurieren, hast aber die Einschränkung, dass du dich nur zu einem Switch verbinden kannst.

Die Beschreibung deines Problems klingt daher für mich so als wolltest du "Adapter-Teaming" haben, hast aber einen "EtherChannel" konfiguriert und diesen auf zwei Switches gepatcht :suspect:

Mit 802.1x Authentifizierung kannst du effektiv alle fremdartigen Clients aus deinem internen Netz aussperren und damit die User von ihren Windows Clients keinen unfug machen bietet Windows ja genügend Möglichkeiten. Falls deine aktiven Komponenten kein 802.1x unterstützen wäre evtl. eine Möglichkeit die Kommunikation mit den Servern ausschliesslich über IPSEC zu erlauben.

802.1x schützt zwar vor fremden Geräten, gewährt den eigenen aber weiterhin uneingeschränkten Zugriff auf das LAN.

Das grundsätzliche Problem bleibt also bestehen -> da diverse Würmer/Viren/Trojaner Sicherheitslücken ausnutzen, kann man nicht mal den eigenen Workstations/Laptops trauen

Da nützt auch eine IPSEC-Verbindung zum Server nichts wenn damit dann halt verschlüsselte Attacken gefahren werden :D

Ein interessanter Ansatz wäre Cisco NAC (unter Zuhilfenahme von 802.1x). Dabei kommt jeder Client erst in ein Quarantäe-VLAN, wird dort mit allen neuen Updates, Hotfixes und Patterns versorgt und wird danach automatisch ins "normale" LAN verschoben.

Bietet aber natürlich auch keinen Schutz der Server vor bislang unbekannten Viren und dergleichen :(

Hallo Freshi, willkommen im Board!

Also gleich vorweg, innerhalb eines LANs (100MBit Client-Access und 1GBit Uplinks) brauchst du dir um die QoS für VoIP eigentlich keine Sorgen machen -> man bekommt die Links eigentlich kaum dicht, wie die Praxis ganz klar zeigt.

Aber zu deinen konkreten Fragen:

Ja, ein Strict Priority Queuing gibt dem Voice-Verkehr wirklich alles was er verlangt d.h. sämtlicher anderer Traffik könnte u.U. verhungern. Nun ist das im LAN eigentlich kein Thema, wenn du auf den Giga-Links z.B. 10MBit für Voice bräuchtest dann stehen dem restlichen Verkehr ja immer noch theoretische 990MBit zur Verfügung, da kommt jeder mal dran.

Bei deinem 2MBit-Scenario sieht das natürlich anders aus, Strict Priority gibt Voice alles und hat vermutlich keine Reserven mehr für den anderen Traffic.

Aber aus diesem Grund wird Queuing auch ständig weiterentwickelt und es entstehen neue Strategien wie z.B. LLQ (Low Latency Queuing) -> eine PQ für Voice und dann noch verschiedene Queues mit unerschiedlichen Prioritäten für anderen Verkehr. Die PQ kann hier allerdings mit einer Obergrenze versehen werden.

D.h. bei einem 2MBit Link könnte man der PQ bei Bedarf bis zu 1,5MBit geben aber auch 500KBit für den Rest übrig lassen.

Beim designen von VoIP-Lösungen sollte man sich ohnehin vorher überlegen wieviele Verbindungen gleichzeitig übers WAN gehen werden (wo sonst hat man 2MBit) und dann die Anlage entsprechend konfigurieren.

Beim Cisco Callmanger ist es z.B. so, dass man die maximalen (Voice-)Bandbreiten zwischen verschiedenen Standorten konfiguriert und der Callmanager dann auch nur eine gewisse Anzahl von gleichzeitigen Gesprächen zwischen den Standorten zulässt -> macht absolut Sinn denn ein Gespräch zu viel würde natürlich alle anderen Gespräche stören!

Der sternförmige Netzwerkaufbau bei mir, könnte mir das zum Problem werden mit Spanning-Tree?

Spanning-Tree fühlt sich mit Dreieckskonstellationen am wohlsten (darauf wurden einige Features ausgelegt). Prinzipiell kommt STP aber mit allen möglichen (und unmöglichen) Topologien klar, brauchst dir also keine Sorgen machen ;)

Wenn du schon dabei bist STP einzuführen dann würde ich dir empfehlen gleich RSTP zu verwenden. Bei STP Konvergiert das Netzwerk nach Ausfall des primären Links in ca. 40 Sekunden, bei RSTP kann man locker auf 2-4 Sekunden runter kommen!

Übrigens haben HP-Switches defaultmäßig STP DEAKTIVERT (zumindest bei den Serien die ich bisher gesehen habe 25xx, 26xx, 410x und 530x).

Weil hier schon der von Cisco bekannte Begriff "Portfast" gefallen ist:

Wenn du RSTP verwendest ist das (soweit mir bei HP bekannt) schon die Default Einstellung.

Du aktivierst RSTP mit "spanning-tree" und musst dann nur noch auf allen Uplink-/Downlink-Ports "no spanning-tree Portnummer edge-port" sagen damit die Switches wissen, dass dies keine Client-Ports sind.

Würde ich so machen:

access-list 100 deny icmp host A host B echo

access-list 100 permit icmp host A host B echo-reply

access-list 100 permit icmp host B host A echo

access-list 100 permit icmp host B host A echo-reply

access-list 100 deny ip any any (ist am Ende ohnehin default)

Das wäre doch was für ein ServerHowTo...

Was konkret? :wink2:

Damian hat das meiste ja schon gesagt aber was ich noch ergänzen möchte:

Ich glaube nicht, dass der DHCP-Server eine VLAN-fähige NIC hat bzw. nicht so konfiguriert ist.

Das Problem ist in größeren Netzen ja immer das selbe:

• DHCP-Anfragen erfolgen als Broadcast (eine andere Möglichkeit hätte der PC in dem Moment nicht, er hat noch keine IP-Adresse)
  
• Broadcasts können sich nur in einem VLAN/Subnet ausbreiten, Router lassen Broadcasts nicht durch
  
• Das bedeutet aber auch, dass jedes Subnet irgendwie bis zum DHCP-Server gezogen werden müsste da dieser sonst diese DHCP-Broadcasts nicht bekommt.
  

Da es ab einer gewissen Größe einfach undenkbar wäre jedes Subnet bis zum DHCP-Server zu ziehen, kann man den Routern beibringen gewisse Broadcasts doch weiterzuleiten.

Bei Cisco nennt sich das dann IP-Helper -> Man sagt dem Router die IP-Adresse(n) der(des) DHCP-Server und wenn er einen DHCP-Broadcast "hört" wandelt er diesen in einen Unicast um und sendet die Anfrage weiter an den DHCP-Server.

Das ist eine gängige Technik und kann für mehrere Protokolle konfiguriert werden (z.B. Time-Services usw.)

Der DHCP-Server kann dann irgendwo stehen (idealerweise im Rechenzentrum :D ) und man kann Subnetze anlegen soviel man will, man muss einfach nur dem Router wieder beibringen was er mit DHCP-Anfragen zu tun hat. Am DHCP-Server selbst muss man somit an der NIC-Konfiguration nichts weiter machen.

Und genau das könnte auch bei der IP-Telefon Lösung der Fall sein die du gesehen hast. Die tatsächliche Topologie könnte auch so aussehen:

PC----Telefon===Switch===Switch===VLANfähigerRouter---CoreRouter---ServerRouter---ServerSwitch---DHCP-Server

oder der Server könnte auch an einem ganz anderen Standort stehen und die Anfragen übers WAN beantworten. Alles kein Problem!

Bei Cisco IP-Telefon Lösungen spielt übrigens der Callmanager oft auch gleich DHCP-Server, also alles aus einer Box -> sind im Grunde "nur" Win2k Server ;)

Natürlich hat Damian mit seiner Beschreibung (VLAN-NIC im DHCP Server) recht, das ginge auch.

Aber ich hoffe mal, dass sich eine Firma die sich Cisco IP-Telefone leistet auch gleich für eine modularen Netzwerk-Topologie entschieden hat :p