Sailer

@rblasey Werde das bei Gelegenheit gerne noch mal nach recherchieren. Auf die Schnelle frage ich mich dann aber wie das bei einem vollbestückten 65xx oder 45xx funktionieren soll, die haben je nach Modul weit über 255 Ports! Ich hab mir mal sagen lassen, dass STP immer eine eindeutige Entscheidung treffen kann, ganz egal was der User auch konfiguriert. Die Erklärung mit der MAC-Adresse wäre wohl naheliegend -> die letzte Entscheidungsinstanz Aber wie gesagt, werds noch mal genau recherchieren ;)

Doch, ein gemanagter Switch hat definitiv auf jedem einzelnen Port eine eigene MAC-Adresse ;) Die Frage von sgabriel ist also durchaus berechtigt und gut mitgedacht! Ein Switch braucht zum switchen keine MAC-Adressen, auch nicht um irgendetwas zu filtern oder sich zu merken. Auch VLANs usw. könnten gebildet werden ohne, dass der Switch selbst auf jedem Port eine MAC-Adresse besitzt ABER MAC-Adressen am Switch-Port werden benötigt: 1) Wenn es ein L3 Switch ist und ein Port mit "no switchport" zu einem L3-Interface konfiguriert wird (also im Grunde ein Routerinterface wird) 2) Der Switch an einem STP teilnimmt. Bei gleichen Pfadkosten zum Root-Switch entscheidet die MAC-Adresse der Ports in letzter Instanz. Gruß Sailer P.S.: Noch eine kleine Unrichtigkeit: Switches suchen nicht per Broadcast oder Trial & Error nach MAC-Adressen (wär ja ein unglaublicher Aufwand und Overhead). Die Adressen lernen sie rein passiv indem sie die Source-MAC eines ankommenden Frames auslesen. Somit weiß man an welchem Port welche MAC-Adresse hängt. Diese Info wird dann in die sog. CAM-Table geschrieben und für ein paar Minuten gespeichert

ein 45xx oder 65xx z.B. hat bestimmt kein Problem mit so vielen VLANs, der STP vielleicht schon eher aber da kann man immer noch auf MSTP umsteigen... aber ist ja eher eine hypothetische Diskussion weil so viele VLANs ohnehin kaum jemand braucht. Nein, ISL ist kein Protokoll wie dot1Q, auch wenn sie den selben Zweck erfüllen ISL ENKAPSULIERT d.h. packt den ursprünglichen Frame in ein neues Paket ein und am Ende des Trunks wieder aus dot1Q TAGGT d.h. dem ursprünglichen Frame wird die VLAN-Information dazwischengeschoben (getagged) VLAN-Hopping wird wohl von keinem seriösen Hersteller "unterstützt", Microsoft unterstützt ja auch keine Bluescreens ;-) VLAN-Hopping ist nur aus einem native VLAN (dot1q untagged) möglich, da es bei ISL aber etwas vergleichbares nicht gibt, besteht auch keine Gefahr auf ISL-Trunks. (will dot1q hier aber nicht in ein falsches Licht rücken, auf einem sauber konfigurierten dot1q-Trunk besteht diese Gefahr natürlich auch nicht)

das stimmt so auch nicht ganz: ISL unterstützt eine größere Anzahl an VLANs als dot1Q (wers braucht) ISL ist außerdem eine Encapsulation, daher gibt es so etwas wie ein "untagged VLAN" per Design nicht, was wiederum VLAN-Hopping von vornherein ausschließt. Trotzdem möchte auch ich dir empfehlen bei dot1Q zu bleiben. ISL ist Cisco proprietär und wird meines Wissens auch von Cisco früher oder später nicht mehr supportet werden.

Hallo, ich habe genau das gleiche Problem (auch SBS2003, auch die selbe Meldung) Gibts dafür inzwischen eine Lösung? Gruß Sailer

aaaaaha, wieder alles klar :D

Versteh ich jetzt nicht ganz :suspect:

Collisions spielen sich auf Layer 1 ab, daher ist bei einem Switch (Layer2 Gerät) jeder Port eine eigene Collisiondomain. Ein Hub hingegen ist ein Layer1 Gerät, somit ist jeder Port eines Hubs Mitglied der selben Collisiondomain. Auf einem Switch spielt es keine Rolle wieviele logische IP-Subnets man anschließt, solange diese nicht durch unterschiedliche VLANs von einander getrennt sind, breiten sie dich Broadcasts in alle Subnetze aus -> für den Switch macht das keinen Unterschied, seine Welt besteht ja nur aus Layer 1 & 2 ;) Man kann sich VLANs auch ganz einfach als mehrere physikalische Switches vorstellen, die keine Verbindung miteinander haben.

Hast du da auch einen Link dazu?

such mal auf http://www.cisco.com oder bei google nach "password recovery", ist ganz gut beschrieben wie man vorgehn muss. hier im forum wird diese frage nicht gern gesehen ;) und bezüglich "wie programmiert man den dann" müsste man schon ein bisschen mehr Info von dir bekommen... :rolleyes:

Ja, ein Ping sollte genügen. Der PC antwortet mit einem ICMP-Reply und der Switch lernt dabei seine MAC-Addresse.

Das gilt für das IOS das geladen werden soll, nicht die Konfiguration!

KOPIEREN -> Ja aber alex möchte die Konfig auf der Karte auch als "Backup-Config" beim BOOTEN verwenden, ich glaub das geht nicht

Ich wüßte nicht, wie man den Speicherort der Config ändert und hab auch noch nie gehört, dass das gehn würde... also sag ich jetzt mal "Nein" Den tieferen Sinn der Speicherkarten habe ich auch noch nicht herausgefunden, es ist halt ein Speicher den man wechseln kann ohne den Router ausschalten und zerlegen zu müssen und man kann diese Karten auch mal ganz bequem in einem PC stecken und schnell ein IOS rüber spielen -> das spart Zeit wenn das IOS gelöscht oder defekt ist und der Router nicht mal mehr eine IP-Verbindung zum tftp aufbauen kann. Zur Not muss man dann ein neues IOS über die superschnelle xmodem Verbindung mit 9600k rein spielen, das kann dauern. Eine Flashkarte in den PC gesteckt, spart dann schon viel Zeit :wink2: Trotzdem könnte ich auch ohne diese Karten ganz gut leben :D

hi alex, Die Config liegt im NVRAM und heißt startup-config -> dir nvram: Du kannst dir diese z.B. per tftp wegsichern (am besten in regelmäßigen Abständen bzw. nach jeder Änderung) Die "Firmware", also das IOS, kann überall liegen wo du sie hinbekommst, es muss nur ein Booteintrag darauf verweisen -> mach "mal boot system ?", dann siehst was alles möglich wäre. Mit diesem Befehl setzt du auch den Booteintrag. Bei "sh version" siehst du irgendwo "System image file is flash:xxxxxxxxx.bin", das IOS an dieser Stelle wird beim Boot geladen.

http://sourceforge.net/ ist immer ein guter Tip finde ich, hab da mal einige interessante Projekte zum Thema Netflow gesehen.

Ich gehe dabei aber auf die Frage nach der maximalen Geschwindigkeit auf einem Netzwerkpfad ein und wollte verdeutlichen, dass der schwächste Link maßgeblich ist -> man hat ja auch selten einen durchgehenden Channel vom Server bis zur Workstation ;)

Die Gigabit Verbindung zum Server bringt dir insofern was, als dass die Konkurrenz um das Medium verringert wird (um es so auszudrücken wie du vorhin geschrieben hast ;) ) Auf einen Gigabit-Link können halt mal bis zu zehn PCs (mit 100 MBit-Karten) ohne Performance Einbußen gleichzeitig zugreifen -> das ist natürlich reine Theorie und in der Praxis von Faktoren wie Kabelqualität, Backplain-Durchsatz auf den Netzwerkgeräten, Serverleistung usw. abhängig Und zu deinem letzten Satz: Ja, die maxiamale Geschwindigkeit auf einem Netzwerkpfad ist immer die der langsamsten Verbindung -> stell dir einfach mal das Extrem vor: Server/GBIT----GBIT/Switch/10MBit----10MBit/Router/ISDN----------ISDN/Router/10MBit----PC Der PC wird den Server malximal mit 64-128kBit erreichen können, auch wenn sonst noch so eine performante Infrastruktur aufgebaut ist... :( Den Spruch mit dem schwächsten Glied der Kette kennst du ja ;)

Ja, aber Pings die von Seiten der Ethernet-Schnittstelle kommen werden nicht geblockt nur weil eine ACL auf s0 konfguriert ist. Aber vielleicht reden wir auch nicht vom selben, unter "außen" verstehe ich jetzt alles außerhalb des Routers also von allen Seiten. Wenn man als "außen" nur die s0 Seite sieht würde deine Konfiguration schon passen. Ich weiß nicht wie pingelig diese Frage gestellt wird aber ein Statement für PC1 musst du einbauen wenn auch vom Router aus der PC1 gepingt werden soll -> eines seiner Interfaces wäre dann nämlich Source-Address d.h. der Reply würde auf diese gesendet werden

Hallo Jabao, natürlich musst du die acl auf jedes Interface binden auf dem sie wirken soll, s0 ist ein interface wie jedes andere auch! Und was noch fehlt ist die konfiguration, dass die ICMP-Reply's von PC1 duch können (zumindest entnehme ich das deiner Aufgabenstellung so)

Ja, geht auch Area5---Area0---Area3---Area2 damit Area2 nun auch mit den anderen Areas kommunizieren kann, kann man es durch Area3 durchtunneln damit es Area0 erreicht und somit wieder mit allen Areas verbunden werden kann.

Meinst du jetzt wenn du mit > interface ethernet 1/0.1 > ip address 10.0.0.1 255.255.255.0 ein Subinterface anlegst? Hab ich nie ausprobiert aber nach meiner Auffassung zählt ein Subinterface gleich viel wie ein "normales" Interface, somit wird auch die höchste IP eines Subinterfaces RID.

Bei OSPF müssen beide Router im selben Area sein, die Process-ID ist hingegebn nur lokal von Bedeutung. Also: router> router ospf "Process-ID" router> network 10.0.0.0 0.0.0.255 area "Area" Um Router aus verschiedenen Areas miteinander zu verbinden, müssen diese über Area 0 verbunden sein => OSPF zwingt einem ein sehr flaches Schema auf d.h. alle Areas müssen an Area 0 angeschlossen sein (sofern man ausschließlich OSPF einsetzen will und die Areas nicht über anderer Routingprotokolle verbindet)

die hierarchie bei den RID's läuft folgendermaßen ab 1) die fix konfigurierte RID >router ospf 1 >router-id 10.0.0.1 2)wenn keine ID fix konfiguriert ist, zieht die höchste Loopback-Adresse 3)wenn keine Loopbacks definiert sind, zieht die höchste Interface-Adresse 4)wenn auch keine Interface-Adresse konfiguriert ist dann... handelt es sich eher um eine teure Heizung als um einen Router :D

hallo angel, das kannst du auf cisco routern mit "netflow" machen, es gibt dazu auch jede menge freeware mit der du dir diese daten grafisch aufbereiten lassen kannst. willst du dieses feature allerdings auf einem 6500er nutzen brauchst du ein eigenes (wie immer nicht gerade billiges) modul in dem gerät , die meisten "kleinen" router unterstützen das einfach so :rolleyes: