Moepi

Es zählt in jedem Fall die höchste IP - wenn also ein Loopback Interface ne höhere hat, dann zählt die. Ob jedoch die Loopback Adresse auch dann ausschlaggebend ist, wenn sie nicht die höchste IP insgesamt ist, weiß ich nicht. Auf jeden Fall ist es gängige Praxis, die OSPF Router ID mithilfe von Loopback Interfaces anzugeben, da Loopback Interfaces inhärent stabil sind. Das heißt, es kann nicht down gehen (was im Falle eines phys. Interfaces die Router ID ändern und eine Neuaushandlung von DR und BDR notwendig machen würde).

Also, nachdem ja offenbar noch niemand Erfahrungen mit dieser Prüfung hat, hier meine Eindrücke: Vergleichsweise leicht, nicht von den Simulationen schocken lassen. Bedauerlicherweise sind in den Routersimulationen sowohl die Tab-Kommandoergänzung als auch die Hilfe via '?' unterbunden worden. Darin besteht auch die Schwierigkeit. Hab mich leider davon ziemlich verunsichern lassen - daher hab ich die eigentlich leichte ISDN DDR Simulation vollends vergeigt. Für 887 Punkte hats dann aber doch noch gereicht - 790 waren notwendig, 1000 gabs wie immer.

Ja aber da werden neue Einträge immer unten angefügt oder? Indiskutabel... ;) Außerdem kann man Extended oder Named ACLs nicht immer gebrauchen.

Ich plane für kommenden Freitag die BCRAN Prüfung fürn CCNP zu machen. Hat sie kürzlich jemand gemacht? Wird tatsächlich so ein Sch*** wie PRI Linecoding und Framing für Europa und Kanada gefragt? *bibber* Die CD, die dem Buch von Cisco Press beiliegt, kann man ja wie üblich wieder in der Pfeife rauchen...

Normales Verhalten. Speicher Dir die ACL via "show run" in ne Textdatei, editier sie dort, lösch sie komplett vom Router und jag ihm die veränderte ACL via Copy&Paste wieder rein.

UDP kannst schon mal rausnehmen, da FTP nur TCP verwendet. Der 21er is der Control Port, auf den sich ein Client verbindet. Vom 20er geht dann eine Datenverbindung vom Server zurück zum Client. Im Prinzip müsste als der TCP21 ausreichen. Check bitte die IP und Firewalls am entsprechenden Client bzw. Server. Wenn das nichts hilft, rück dem Problem mti Sniffern am Server und am Client zu leibe bzw. verwende die "debug ip nat translation" und "debug ip packet" Kommandos, um zu sehen, was Sache ist.

Die Frage ist im Prinzip kurz: Beherrschen die deutschen Exchange 2003 Versionen (auch SBS Server) das Versenden von Mails mit japanischen Schriftzeichen oder habe ich da mit Schwierigkeiten zu rechnen? Hab mich mit Internationalisierungen bisher nicht auseinandergesetzt... Danke schonmal!

Wie verbindet man zwei Ciscorouter via VPN, wenn beide dynamische IPs haben? Garnicht? Dachte ich auch einige Zeit... Nachdem ich sehr lange gesucht und im Netz nicht viel drüber gefunden habe und schlussendlich selber auf ne Lösung kam, will ich Euch diese nicht vorenthalten. Am einfachsten scheint es über Scripts zu gehen, die via Cronjobs ausgeführt werden. Auf meiner Homepage (http://home.in.tum.de/~guenther/network/cisco_dynvpn.html) hab ich ein kleines Howto geschrieben.

Also das IOS ist ein 12.4(7) Advanced IP Services. Bisher ist mit allen IOS Versionen dasselbe Problem aufgetreten. Dass ihm der Speicher ausgeht (selbst wenn Teile nicht mehr korrekt freigegeben werden), kann nicht sein, da die Kiste bereits nach wenigen KB IPSec Verkehr crasht - zu wenig, als dass ihm seine 128MB nicht reichen könnten... Bin langsam echt ratlos mit der Kiste... /EDIT: Haltet Euch jetzt bitte fest worans lag. Aber davor verleihe ich den Titel des Dümmsten Anzunehmenden Administrators (kurz DAA) noch an mich: Ich hatte die IPSec Crypto Map auf das Tunnel 0 Interface gebunden. Ergo hat er mir erst nach der IPSec Verschlüsselung die GRE Encapsulation gemacht - und ich hab mich schong ewundert warum meine Crypto Map "permit gre host ..." net fruchtet. Das war auch der Grund warum die IPSec Verbindung insgesamt eher selten und wenn nur instabil zustande kam. Seitdem ich die Crypto Maps jetzt angepasst und auf die Dialer Interfaces gelegt habe, läuft alles bestens - das Crypto Modul des 1841 eingeschlossen. Der Gute hat sich wohl an meiner himmelschreienden Falschkonfiguration verschluckt... Neue Signatur: "Jeder is mal DAA :D" Danke Euch für Euere Tips!!

Also das ist ein Teil dessen, was man via Terminal Monitor (SSH) auffangen kann. Das komplette Output der Konsole hab ich leider noch net einfangen können. Die Crashinfos, die der Router im Flash ablegt, sind zwar sehr ausführlich (inkl. Memory Dump) aber nicht besonders vielsagend... Mar 28 18:10:16.007: %SYS-2-MALLOCFAIL: Memory allocation of 18188 bytes failed from 0x602CBB20, alignment 32 Pool: I/O Free: 8295696 Cause: Mempool corrupt Alternate Pool: None Free: 0 Cause: No Alternate pool -Process= "IP Input", ipl= 0, pid= 59 -Traceback= 0x60E4C294 0x601EC628 0x601F0AC0 0x602CBB28 0x602CC0B8 0x602CC904 0x613186D0 0x61318394 0x61315478 0x6131566C 0x61315728 0x613158CC ahg-border# Mar 28 18:10:24.443: %SYS-3-OVERRUN: Block overrun at E7400050 (red zone 628BD2E8) -Traceback= 0x60E4C294 0x60202F58 0x60203CF8 0x60205F00 0x60206190 Mar 28 18:10:24.443: %SYS-6-MTRACE: mallocfree: addr, pc 64987E30,600000F0 64987AB4,602CBCC0 0,602CBB20 64987AB4,602CBAD4 64987AB4,400001A6 656C39E4,60000044 656C3668,602CBCC0 0,602CBB20 Mar 28 18:10:24.443: %SYS-6-MTRACE: mallocfree: addr, pc 656C3668,602CBAD4 656C3668,400001A6 64987E30,600000F0 64987AB4,602CBCC0 0,602CBB20 64987AB4,602CBAD4 64987AB4,400001A6 656C39E4,60000044 Mar 28 18:10:24.443: %SYS-6-BLKINFO: Corrupted redzone blk E7400050, words 144, alloc 602CBB20, InUse, dealloc 4500008C, rfcnt 1A41659A -Traceback= 0x60E4C294 0x601EC7D8 0x60202F6C 0x60203CF8 0x60205F00 0x60206190 Mar 28 18:10:24.443: %SYS-6-MEMDUMP: 0xE7400050: 0xAB1234CD 0xFFFE0000 0x0 0x628BD2E8 Mar 28 18:10:24.443: %SYS-6-MEMDUMP: 0xE7400060: 0x602CBB20 0xE7400190 0xE7400014 0x80000090 Mar 28 18:10:24.443: %SYS-6-MEMDUMP: 0xE7400070: 0x1A41659A 0x13C4EF 0x425D8864 0x110003DD /edit: Habs grad durch den Interpreter von Cisco gelassen. Nachdem er sich erstmal seitenlang drüber beschwert hatte, dass ich kein AAA New Model verwende kam er zum Memory Dump. Das einzig leserliche was er brachte war "Crash caused by a software defect" und eine Liste mit IOS Versionen, seit denen potentielle Fehler für mein Problem gefixt sein sollen - allesamt älter als das aktuelle IOS. Falls es also kein Hardwaredefekt ist und die Speicheranforderungen auf der Cisco HP fürs IOS korrekt sind muss es ein Bug im IOS sein, um den Cisco sich bislang nicht gekümmert hat. Schade, denn so wies momentan ist scheint das onboard Cryptomudel des 1841 schlicht unbenutzbar zu sein... :(

So jetzt würde mein VPN Tunnel stehen - dummerweise stürzt einer der beiden Router (ein Cisco 1841) ab, sobald Traffic übers VPN geht. Unter Traffic versteh ich das, was ein DSL6000 im Upstream hergibt. Der Router verabschiedet sich mit einigen Fehlermeldungen bzgl. Speicherzuweisungen und Reservierungen auf der Konsole und startet neu. Interessant ist, dass das Problem nur dann auftritt, wenn das onboard VPN Modul aktiviert ist. Schalte ich es mit "no crypto engine onboard 0" und "crypto engine software ipsec" ab, läuft der Router stabil. Ich hab bereits zwei verschiedene IOS getestet (12.3 und 12.4) - mit beiden dasselbe Problem. Die Speicherbestückung ist aber für die IOSes ausreichend (32MB Flash, 128MB RAM). Der Router belegt auch grade mal ~16MB RAM laut "sh version". Dass es ihm ausgeht kann ka wohl kaum sein... Hat jemand schon mal ähnliche Probleme gehabt oder ne Idee woran es liegen könnte? Hardware defekt?

Was bringt mir ne Route zum Loopback der Gegenstelle? Die is für gewöhnlich mit ner privaten IP konfiguriert. Und selbst wenn das Loopback mit der WAN Ip konfiguriert wäre, wüsste das der Router auf der anderen Seite nicht! Und einfach übers Dialer 0 raus bringst ja auch nicht. Woher weiß mein ISP wohin er routen soll wenn ich ein Paket an ne private IP schicke? Der weiß doch vom Loopback auch nichts...

Und wie kontaktiert er bei Deiner Lösung die Gegenseite? Einzige Chance ist die dynamische WAN IP - das is ja eben der Knackpunkt. Hab gestern Nacht ne abenteuerliche Lösung gefunden, die so sicher in keinem Lehrbuch steht - klappt aber prächtig: event manager session cli username moepi event manager applet update_tr-muc_ip event timer cron cron-entry "0-59 * * * *" action command1 cli command "enable" action command2 cli command "configure terminal" action command3 cli command "interface tunnel 0" action command4 cli command "tunnel destination xxx.dyndns.org" Das ganze ist ein CLI Script für Ciscos Event Manager, ausgeführt via Cronjob einmal pro Minute und aktualisiert die Interfaceconfig für den Tunnel. Da das IOS anstatt der IP auch nen FQDN als tunnel destination annimmt, klappt das wunderbar. (Der FQDN wird beim Bestätigen aufgelöst und durch die IP ersetzt, daher wird überhaupt erst der Affengriff nötig) Jetzt leg ich heute noch IPSec übern Tunnel und fertig is das DynToDyn VPN ;) *schweinischgutfühl* *michvonmeinemprofheutwiederdeprimierenlass*

Geh ins LAN Interface vom AP und versuch mit "pppoe-enable" PPPoE zu aktivieren - wenn das klappt, schauts gut aus ;). Das WLAN Interface müsste dann als Radio Interface konfigurierbar sein. Hatte leider noch nie lange meine Finger an nem Aironet... *lottospiel* :D

Ich bin grade mal wieder dabei zu versuchen, was bestimmt 1000 Leute vor mir versucht haben - hoffentlich hatten einige von Ihnen mehr Erfolg... Also kurzes Umfeld: 2 Router (Cisco 1721 und 1841) an T-DSL Anschlüssen (also dynamische IPs). Ziehl ist es, mit den beiden Routern einen geschützten VPN Tunnel aufzubauen, der mir auch Routingprotokolle (OSPF) ermöglicht. Schritt 1 ist demnach ein Tunnel Interface für GRE, Schritt 2 ein IPSec Protection. Auf den beiden Routern sieht die Tunnel Config derzeit etwa so aus: interface tunnel 0 tunnel source dialer 0 tunnel destination xxx.xxx.xxx.xxx tunnel mode gre ipv4 [/Code] Das funktioniert prächtig, solang keiner der Router sich neu ins Netz einwählt :( Es muss doch ne Möglichkeit für so nen Tunnel zwischen 2 Geräten mit jeweils dynamischen IPs geben. Hatte schon an NHRP gedacht aber auch da haben die Hub Router feste IPs. Hat jemand Vorschläge oder ein absolut sicheres "Das geht nicht" ? Danke!