Sailer

Deine Anforderung ist ganz klar ein Fall für 802.1x -> das können auch HP Switches ab der 25xx Serie (der 2650er sowieso)

Kann mich dippas nur voll und ganz anschließen, was du vor hast ist nicht wirklich managebar und die Sicherheit bei MAC-Adressen anzusetzen ist IMHO vergeudete Zeit.

Natürlich kann man es so machen aber dann sollte das schon eine sehr kleine Installation sein (max. 20-30 Geräte) und die Sicherheit als nice-to-have angesehen werden. :rolleyes:

Aber um noch mal deine ursprüngliche Frage zu beantworten:

Ein MAC-Filter filtert (wie der Name schon sagt :D ) anhand der (Source-)MAC-Adressen und lässt somit auch nur die durch die angegeben wurden.

In deinem Beispiel würde überhaupt nichts mehr funktionieren weil du erstens keine Client-Adressen angibst und zweitens müsstest du die Base-MAC der beiden Switches angeben. Management-Traffic wird nur mit dieser Adresse verschickt und ist nicht davon abhängig welche MAC-Adresse der Outgoing-Switchport hat.

@sailer, sigma

wohin wollt ihr jemanden schicken, wenn die Maschine unbekannt ist?

 

cu

blub

Wenn du mir die IP-Adresse eines Gerätes sagst, finde ich in einem gemanagten Netz jedes Gerät... :p

Anhand der IP weiß man auch wer das Default-Gateway sein muss (also der Router).

Auf diesem Router kann man die ARP-Table auslesen und bekommt die passende MAC-Adresse zur IP.

Mit der MAC-Adresse kann man sich dann den Switches entlang arbeiten bis man schließlich am letzten Switchport angekommen ist.

In einem Netzen mit 1000ten Anschlüssen findet man so in wenigen Minuten heraus in welchem Raum ein Gerät steht also sollte das doch in einem Netz mit 100 Geräten auch schaffbar sein?! :suspect:

@StefanK: Wie groß ist denn dein "Revier"? Sprechen wir hier von einem Gebäude oder von einem Netz mit 30 Aussenstellen? Alleine anhand des IP-Ranges müsstest du den Standort doch schon eingrenzen können?

Was spricht dagegen vorort hin zu gehen bzw. jemanden hin zu schicken :suspect:

Wie hier schon mal erwähnt sollte man das Cisco Passwort Recovery Prozedere mal bei den Tips aufnehmen, die Frage kommt doch ziemlich oft. (http://www.mcseboard.de/cisco-forum-allgemein-38/login-daten-2-115063.html)

@spache: die ports sollten doch beschriftet sein? Also mit dem ISDN (oder BRI) zur ISDN-Analage und mit den Ethernet-Ports zum Switch -> oder habe ich deine Frage falsch verstanden? :suspect:

Wie meine Vorredner schon geschrieben haben, die Portbezeichnung ist bei der C3750er Serie so (weil stackingfähig)

Solltest du einen Switch aus dem Stack nehmen und er hat danach z.B. die Portbezeichnung "Gi 3/0/1" kannst du das mit "C3750(config)#switch 3 renumber 1" wieder auf "Gi 1/0/1" ändern

Dass beide Switches die selben VLANs haben sagt ja nichts darüber aus ob diese auf einem Trunk auch vorhanden/zugelassen sind ;)

Macht in der Praxis durchaus Sinn alle VLANs auf den Switches gleich zu konfigurieren aber auf den Trunks dann nur bei Bedarf zuzulassen...

da warte ich bis heute auf mein Muster :)

Und wie lange wartest du schon? :D

mit jeder CCNP Prüfung verlängert sich dein CCNA um weitere 3 Jahre d.h. theoretisch hätte man 12 Jahre lang Zeit den CCNP zu machen :D

Wie gesagt, "theoretisch", denn wenn Cisco das Schulungs und Zertifizierungsprogramm umstellt, gibt es meist auch neue Fristen wie lange abgelegte Prüfungen noch gültig sind bzw. mit neuen Prüfungen kombiniert werden können.

So was gibts z.B. von PatchSee (http://www.patchsee.com).

Aber es geht halt doch nichts über eine gut gewartete Doku ;)

Damit du einen von den beiden Pfaden wählen kannst, must du für den Pfad den du wählen willst eine Administrativedistanz wählen der kleine ist als der von den anderen Pfad.

Bloß nicht! Die AD hilft dir in diesem Fall überhaupt nicht also Finger weg davon!

Mit der AD beeinflusst man welchem Routing-Protokoll mehr "geglaubt" wird d.h. soll der Router die Routen die ihm RIP erzählt in die Routing-Table schreiben oder die, die ihm OSPF erzählt (gleiches Subnet vorausgesetzt).

Wenn man an der AD herumdreht könnte die Routingtable also plötzlich ganz anders aussehen und eventuell das Routing nicht mehr wie geplant funktionieren!!!

@hkahmann:

OSPF macht eigentlich per default Equal-Cost-Loadbalancing. Eine 100% 1:1 Verteilung wirst du aber selten sehen weil die Verteilung nicht pro Paket sondern pro Session/Flow gemacht wird.

Die Verteilung die du schilderst ist aber natürlich auch sehr ungewöhnlich 99:1

Wie überprüfst du denn das Loadbalancing? Traceroutes? Interface-Statistiken?

Hallo Gulk,

willkommen im Board!

zu 1)

Die Metrik hängt defaultmäßig von der Bandbreite des Links ab -> 100.000.000 / Bandwidth

ergibt dann:

Metrik 1 für 1GBit

Metrik 1 für 100MBit (kein Schreibfehler :D )

Metrik 10 für 10MBit

usw.

zu 2)

man kann auf jedem Interface auch manuell eine "cost" setzen

zu 3)

area area-id virtual-link router-id

(wobei area-id = transit area)

Hallo (nochmal) zappi, :D

den SDM habe ich für den ONT auch gebraucht. Mir gings wie dir, hab das Ding noch nie benützt.

Bei Cisco kann man sich allerdings den SDM gratis herunterladen und es gibt sogar einen Demo-Mode -> dazu benötigt man ein .zip welches ebenfalls auf der Cisco-Seite zu finden ist.

Damit bekommt man zumindest ein bisschen ein Gefühl für die Oberfläche.

Kann vom ONT allerdings sagen, dass sich die Mühe nicht gelohnt hat. Es kam eine SDM-Simulation in der man ganze zwei Buttons drücken konnte um sich Einstellungen anzusehen. Der Rest war "gesperrt" ;)

Naja, wenn ein vorhandener Router CEF unterstützt soll man es natürlich unbedingt aufgedreht lassen (ist default ein).

Bei einem 4MBit Link hat aber bestimmt keine CPU groß Arbeit damit das Processing zu machen. Daher ist CEF ja/nein imho in diesem Fall kein Kriterium für die Auswahl des Routers. Sieht anders aus wenn es um einen Core-Router mit mehreren GBit Interfaces ginge...

ich habe den stecker rausgezogen und wieder rein gesteckt und siehe da es geht alles wieder.

Ja, das funktioniert solange du die Config nicht gespeichert hast. Sämtliche Änderungen an einem Cisco Gerät werden in die sog. Running-Config geschrieben (die ist weg wenn man den Strom weg nimmt). Beim booten wird dann wieder die "Startup-Config" geladen.

Mit "copy run start" kopiert man die running- in die startup-config -> was du (zum Glück) noch nicht gemacht hattest ;)

Btw, auf der Cisco Seite wäre genauestens dokumentiert wie man ein Passwort wieder zurücksetzen kann.

War gerade mal wieder Thema hier: http://www.mcseboard.de/cisco-forum-allgemein-38/login-daten-115063.html

Kann mich #9370 und sebastian.f nur anschließen.

Password Recovery ist ein von Cisco genauestens dokumentiertes und öffentlich zugänglich gemachtes Verfahren. Könnte mir mein tägliches Leben als Netzwerk-Admin ohne dieses Verfahren auch kaum vorstellen. :suspect:

Früher musste man in diesem Fall das Gerät an Cisco schicken damit sie das Passwort zurücksetzten. Nicht umsonst hat Cisco also dieses Verfahren öffentlich zugänglich gemacht!!! :rolleyes:

Da diese Frage hier immer wieder mal auftaucht und lt. Dr. Melzer ohnehin nichts schlimm daran ist...

Nichts, hat auch niue jemand behauptet!

...würde ich sogar vorschlagen das Verfahren bei den "Tipps & Links" aufzunehmen! Was meint ihr?

Was man vielleicht noch anmerken sollte:

Es ist natürlich auch durchaus möglich komplett auf Area 0 zu verzichten und die verschiedenen Areas dann mittels BGP miteinander zu verbinden.

Hängt natürlich vom Anwendungsgebiet ab, prinzipiell wurde natürlich Area 0 dafür geschaffen alle anderen Areas miteinander zu verbinden.

Hallo glady,

verstehe ich dich richtig, du willst wissen was der Unterschied zwischen CEF und Process-Switching ist?

Der Unterschied liegt in der Geschindigkeit mit der ein Router Pakete von einem Interface auf ein anderes geben kann. Bei Process-Switching erledigt alles die CPU (daher etwas langsamer) bei CEF (Cisco Express Forwarding) werden relevante Infos aus den verschiedensten Tables an die Hardware-Logic übertragen und die Forwardingentscheidung kann großteils ohne CPU-Belastung erfolgen -> ist somit wesentlich schneller.

Wirklich interessant ist das nur bei schnellen Bandbreiten. Du schreibst hier von max. 4MBit -> da wirst du keinen Unterschied zwischen PS und CEF feststellen ;)

Wenn man jetzt einige Patches/Updates zurückhalten will, wie z.B. die Installation vom IE7, hat mein bei den Reports immer ein falsches Bild, da diese auch als erforderlich angesehen werden.

Nachdem ich nun auch seit ein paar Wochen den neuen WSUS administriere, muss ich sagen, dass mich das auch extrem nervt :rolleyes:

Hat jemand eine praktikable Lösung für unser beider "Problem". Es ist wirklich ungut, dass man nicht schon auf den ersten Blick sagen kann, ob neue Updates anstehen oder ob nur eines, für ein späteres Rollout, bewußt zurückgehalten wurde

Hi hekmek und danke für deine Antwort,

dass ab 3.0 jedes Update den Clients zur Überprüfung "gezeigt" wird find ich gar nicht mal so schlecht aber wie du schon sagst, die Reports werden verfälscht wenn man was zurückhalten will :mad:

Früher reichte es den Bericht auf der Startseite anzusehen und wußte, dass was neues ansteht. Jetzt muss man sich reinklicken und die Liste durchsehen ob was neues dabei ist. Hoffentlich wird das in WSUS 3.1 verbessert ;)

Gruß

Sailer

Hallo Leute,

nachdem ich von WSUS 2 auf WSUS 3.0 upgedatet habe bin ich nun schon eine Weile auf der Suche nach der "nur ermitteln" Option für neue Updates.

In WSUS 2.0 hatte man damit doch die Möglichkeit, neue Updates nur mal zur Überprüfung frei zu geben ohne sie runter laden zu müssen d.h. die Clients wurden gefragt ob sie überhaupt Bedarf für den Patch/Hotfix haben und nur wenn einer Bedarf angemeldet hat wurde der Patch tatsächlich freigeben und heruntergeladen.

Bin ich blind oder gibt es diese Option im WSUS 3.0 nicht mehr

Gruß

Sailer

Habe gerade das Update von WSUS 2.0 auf 3.0 durchgeführt! Ausser dass ich den ReportViewer 5.0 und MMC 3.0 nachinstallieren musste, klappte alles wunderbar.

 

Grüße, Pretender

Na dann haben wir ja bisher 100% Erfolgsmeldungen :D

Wie ist das zu verstehen? Ausgeführt wird das doch am WSUS-Server, nicht an den Clients.

ähm... ja, stimmt... denkfehler meinerseits, sorry :rolleyes:

Hallo!

Hat schon jeman Erfahrungen mit einem Update von WSUS 2 auf WSUS 3.0?

Soll/kann man das überhaupt machen oder empfiehlt sich eine komplette Neuinstallation?

Bei 100Clients vielleicht ein bisschen aufwendig aber wie siehts bei kleineren Setups mit 10-20 Clients aus? Was wäre da eure Empfehlung?

Mir fällt auf die schnelle auch keine sinnvolle Alternative zu VLANs ein. Aber ich vermute du hast irgend einen Hintergedanken, dass du diese Frage stellst? Erzähl uns doch mal genauer was du vor hast bzw. was gegen VLANs spricht?

Bezüglich der maximalen Anzahl von VLANs auf einem 35xx:

Was kibo schreibt stimmt soweit, als dass man 4096 verschiedene VLAN-IDs zur Verfügung hat. Ein 35xx würde das aber vom Memory her nicht schaffen ;) Ich glaube gehört zu haben, dass es eine eingebaute Grenze bei 256 (gleichzeitigen) VLANs gibt aber selbst diese Zahl übersteigt die Anzahl der vorhandenen Ports um das 5fache!

Man kann dies Frage also mit "mehr als genug" beantworten :D

Wie kann das dennoch funktionieren???? Ist das dot1q irgendwie auf dem Port versteckt? Bei einem show int steht immer alles auf access...

Nein, versteckt ist hier gar nichts... sagen wir einfach es ist "anders" als man es vielleicht gewohnt ist :D

Wenn du an einen solchen Port einen PC anschließt dann bleibt der Port ein normaler Access-Port (keine outgoing VLAN-Tags)

Schließt man an einem solchen Port aber ein IP-Phone an, so unterhalten sich Phone und Switch mittels CDP und initialisieren dynamisch einen 802.1Q Trunk. Normale Daten kommen dann in das VLAN das als "switchport access vlan xx" definiert wurde und Voice kommt in das VLAN das mittels "switchport voice vlan yy" definiert wurde.

Ist eine feine Sache, als Admin braucht man so nur eine Standard Config ausrollen und die Switches erstellen dynamisch Access- oder Trunk-Ports je nach dem welches Device angestöpselt wird. (Cisco Switches + Phones natürlich vorausgesetzt!!!)