sebaaaat

Ich habe einen 2801 als DSL Router, den möchte ich als DNS Proxy für die Clients im LAN laufen lassen. Er lernt über sein Dialer Interface automatisch die DNS Server des Providers. Die Konfiguration für DNS Proxy ist: ciscorouter(config)# ip domain lookup ciscorouter(config)# ip dns server ciscorouter(config)# ip name-server [i]ip-address[/i] Das heißt, ich muss den ip name-server statisch eintragen. Gibt es irgendeinen Weg, stattdessen die dynamisch per Dialer Interface gelernten DNS Server zu nutzen? Danke & Gruß

Danke schonmal! Ich überlege mir noch, ob ich so viel Geld ausgebe, oder mir mit ein paar Cisco PDF's behelfe ;)

Hallo zusammen, ich suche ein gutes Buch, was folgende Themen aus Cisco-Sicht erklärt: -IPSec -DMVPN -mGRE Es sollten die Grundlagen und die Konfiguration erklärt werden. Danke für eure Tips! Grüße

Aber: Mein promiscuous mode hilft mir auch nicht viel, wenn ich trotzdem nur Broadcasts sehe, weil ich an einem Switch stecke? Was soll ich mit ARP machen? -->Wie gesagt: Gibt es keine bessere Möglichkeit?

:rolleyes: auf solche Antworten habe ich gewartet... :) Also gut: Die Frage basiert auf der Annahme, dass dem "Angreifer" nichts außer dem Laptop und dem eine Switchport zur Verfügung steht.

Hallo zusammen, ich hoffe, ich habe die richtige Kategorie für diese Frage erwischt. Hinweis: Hinter dieser Frage steckt keine "bösartige Energie", es geht um eine Art Security-Check. Frage: Wie kann ich in einem geswitchten Netzwerk die Gateway-IP-Adresse und die Netzmaske herausfinden, vorrausgesetzt ich habe physikalischen Zugang? Bisher gehe ich wie folgt vor: - Laptop an einen Switchport gesteckt - mit Wireshark gesniffert, welche IP-Adressen im Netz sind - mir selbst eine entsprechende IP-Adresse gegeben --> Problem1: Welche Netzmaske nehme ich? --> Problem2: Wie komme ich auf die Gateway IP? Mein bisheriger (theoretischer) Ansatz: Dauersniffern und auf ARP-Requests warten, die IP-Adressen, die am häufigsten nachgefragt werden, haben höhere Wahrscheinlichkeit, das Gateway zu sein. Nachteil: sehr zeitintensiv Habt ihr irgendwelche Ideen oder Tips?

Hallo zusammen, Zunächst die Fakten: beim Cisco VSS (Virtual Switching System) mit zwei 6500ern gibt es ein so genanntes In-Service Software Upgrade, bei dem das IOS aktualisiert werden kann, ohne eine Netzwerk-Downtime zu haben. Während des gesamten Vorgangs steht mindestens 50 % der Bandbreite zur Verfügung (z.B. wenn einer der beiden Switche rebootet) und es findet kein Paketverlust statt. Jetzt meine Frage: Gibt es so etwas auch bei anderen Herstellern (HP, 3Com ...)?

Auf der (übrigends auch sonst sehr empfehlenswerten) Seite PacketLife.net habe ich folgendes gefunden Hört sich meines Erachtens sehr logisch an, und entspricht auch meinen Erfahrungen in der Praxis. Warum das in sonstigen Unterlagen (Cisco CCNP-BSCI) nicht erwähnt wird, weiß ich nicht.

Hallo zusammen, wahrscheinlich ist die Lösung recht einfach, aber ich komme nicht drauf. In sämtlichen Unterlagen und Webseiten ist bei einer OSPF Stub Area nur die Rede davon, dass (ausschließlich) Type 5 LSAs durch eine default-route ersetzt werden. Alle anderen LSAs - also auch Type 4 - müssten also weiterhin in die Stub Area gelangen. Der einzige Fall. wo Type 4 (und zudem auch Type 3 und 5) LSAs durch eine default-route ersetzt werden ist die Totally Stubby Area. Meine Praxiserfahrung im Lab sieht aber so aus, dass in einer Stub Area auch Type 4 LSAs durch eine default-route ersetzt werden. Hab ich einen Denkfehler? Sind die Unterlagen falsch? :confused: Gruß

Danke für die Antworten. Das die trust boundary in den Accessbereich gehört ist klar. Es ging wie gesagt nur um die am Core angeschlossenen Server. Ist es denn jetzt klüger, die Werte der Server mit ! policy-map in_untrusted class class-default set dscp default set cos 0 ! interface x/y service-policy input in_untrusted ! auf 0 zu setzen, oder sollte ich auf gut Glück alles auf trusted lassen..? Ersteres hätte zur Folge, das "wichtige" Serverdienste eventuell genauso behandelt würde, wie aller Clienttraffic. Letzteres hätte zur Folge, dass ein "unwichtiger" Serverdienst möglicherweise im Netz höchste Priorität hat. Die 20 Server einzeln zu betrachten und passende QoS-Markings zu setzen ist mir ehrlich gesagt zu viel Aufwand ;) Was würdet ihr tun?

Hallo zusammen, ich nutze im LAN eines Kunden das AutoQoS-feature. Auf den Access-Switchen (3560, 2960) mache ich es so, dass alle uplink-port ein "auto qos voip trust" und alle Access-Ports ein "auto qos voip cisco-phone" bekommen. Ports für Drucker und andere Geräte lasse ich einfach wie sie sind, und somit auf untrusted (default). Beim 4506 im Core ist die Konfiguration aber ein bißchen anders: Alle Ports, die ich bei ihren default-Werten lasse, sind auf "trust": Core_01#sh auto qos GigabitEthernet2/1 auto qos voip trust GigabitEthernet2/2 auto qos voip trust (...) Wie kriege ich die Dinger auf untrusted? Ich will doch nicht allen Non-Cisco Servern einfach blind vertrauen, oder?

Anfangs hatte ich eine 3.x drauf. Jetzt habe die 4.0.155.5 ED drauf bekommen, da diese noch kleiner als 32 MB ist. Ich hätte gern die aktuellste 5er drauf. Es scheint aber am Controller zu liegen, da dieser (wenn ich ich das richtig verstehe) die maximale Blocksize durch seinen Read-Request vorgibt. Kann man trotzdem Abhilfe schaffen?

Tag zusammen, Ich versuche seit Stunden verzweifelt, meinen 4402 WLC auf den aktuellsten Softwarestand zu heben. Ich hänge direkt über Crossover am Controller. Es scheitert offenbar daran, dass ich meinen TFTP-Server nicht dazu bekomme, eine blocksize größer als 512 zu schieben. Die Softwarefiles der neueren Versionen sind allerdings größer als 32 MB. Ich habe folgende Server versucht: - SolarWinds TFTP Server - 3cDaemon (3Com TFTP Server) - tftpd32 Alles ohne Erfolg. Wenn ich den Verkehr mitsniffer sehe ich immer eine Blockgröße von 512 Bytes. Somit bleibt der erfolgreiche Transfer von Dateien, die größer sind als 32 MB ausgeschlossen, denn im TFTP-Protokoll sind nur 16 Bits für die Block-Nummerierung vorgesehen. Wenn man also rechnet: 32MB = 33554432 Bytes 33554432 Bytes / 512 = 65536 2^16 = 65536 So sind irgendwann die Block-nummern der ACK-Pakete aufgebraucht und er fängt wieder von vorne an, was jeden der o.g. TFTP-Server zum Abbruch der Übertragung führt. Daraus folgt: Ich muss irgendwie die Blocksize höher schrauben. Aber wie? beim tftpd32 kann man ja die negotiation ausstellen und das "anticipation window" höher stellen, hilft aber nichts. Wenn ich das richtig verstehe, kann der Server bei einem Read-Request auch nur eine Blocksize, die entweder gleichgroß oder kleiner als die im Read-Request angegebene wählen. Wenn also der Controller einen Read-Request mit 512 blocksize schickt, kann der Server nicht mit 1024 antworten. So verstehe ich zumindest das Zitat aus dem RFC: (RFC 2348) Verstehe ich das alles richtig, oder hab ich irgendwie einen Denkfehler? Wie krieg ich die Block-size höher?

Die Lösung des Problems war so denkbar einfach, dass ich mich im Nachhinein für jeden Buchstaben meiner vorigen Postings schäme ;) Gerätemanager -> Treiber aktualisieren -> Windows Update -> Reboot -> funktioniert. Schuldig im Sinne der Anklage, aber wenigstens läufts jetzt. Die feste IP hat er nach dem Neustart sogar immer noch gewusst... Danke :D

Danke für deine Tips! Ich finde für den Ethernetadapter ( Intel® PRO/1000 PL Network Connection PCI\VEN_8086&DEV_109A&SUBSYS_FF001179 ) leider keinen Treiber im Netz, auch nicht auf der Intel Support Page (Network Connectivity - Intel® Network Adapters support). Das Zurücksetzen des TCP/IP-Stacks half auch nichts, es hatte nur zufolge, dass die Karte nun bei jedem Reboot ihre feste IP verliert... :( Wie oben erwähnt, haben Pings mit größeren Paketen normale Antwortzeiten. Durch Rumprobieren bin ich auf die scheinbare Grenze gestoßen: ping -l 210 (oder kleiner) bringt Zeiten >500ms ping -l 211 (oder größer) bringt Zeiten <1ms Ein Hardwareproblem ist aufgrund verschiedener durchgeführter Tests auszuschließen. Hat noch jemand eine Idee / einen Tip?