Blacky_24

Nunja. Wenn Du keine / wenig Ahnung von Servern hast würde ich Dir empfehlen, bis auf Weiteres die Finger davon zu lassen oder Dir jemanden zu suchen der davon Ahnung hat. Wenn das mit der roten LED die Bootplatte ist und die Platten über Software gespiegelt sind hast Du gute Chancen dass die Kiste nicht mehr hochfährt. Blinder Aktionismus ohne eingehende Analyse / Verständnis des Problems und seiner Ursache richtet im Zweifelsfall mehr Flurschaden an als dass er nützt. Wenn sich die Kiste um 12:35 Uhr mit einem freundlichen "inaccessible boot device" hinstellt hast Du mit Deinem Kenntnisstand ein echtes Problem (und Deinen Chef) am Hals. Such Dir für den Anfang mal eine leere 3,5"-Floppy und fahr RDISK auf dem Server, dann wirf einen Blick aufs Backup ob das aktuell und vollständig ist, ein kleiner Test ob auf den Bändern tatsächlich verwertbare Informationen sind schadet auch nicht. Gruss Markus

Grübel, murmel, kopfkratz ..... Logging auf Syslog, z.B. Kiwi: Wo sagst Du dem Router denn wohin er protokollieren soll? logging 10.100.1.100 logging 10.100.1.101 steht bei mir in der Konfig (ein Eintrag reicht natürlich). Wenn Dir die Zeitstempel im Syslog etwas verschoben erscheinen in Bezug auf Deine Ortszeit mag das hier noch eine gewisse Anpassung bringen: service timestamps log datetime localtime Wenn Du XP verwendest denke bitte daran, ggf. in den Netzwerkeinstellungen die Firewalleinstellungen entsprechend anzupassen dass XP die Syslog-Pakete durchlässt, da habe ich mich in den Anfangszeiten von XP mal zu Tode gesucht. Weiterhin mit DHCP und Serverdiensten aufpassen, ggf. für den Rechner mit dem Syslogd eine Reservation im DHCP anlegen dass der vom Router immer dieselbe IP kriegt. Das hier: dialer-list 1 protocol ip list 100 dünkt mir in Kombination mit Deiner Access-list 100 access-list 100 permit udp any any eq domain access-list 100 permit tcp any any eq pop3 access-list 100 permit tcp any any eq www access-list 100 permit tcp any any eq ftp access-list 100 permit icmp any any pfiffig! Würde trotzdem auch noch eine Beschränkung auf die zugelassenen Netze einbauen. Wegen dem hold timer debug dialer schreibt die Dialer-Ereignisse auf den Syslog bzw. auf die Konsole, u.a. steht darin wenn der Router "interesting traffic" i.S.v. Deiner Access-List 100 erkannt hat und woher der Traffic kam. Du kannst noch an die internen Access-Listen jeweils ein deny ip any any log anhängen. Im Prinzip steht das sowieso schon drin - allerdings ohne das "log". Mit dem "log" protokolliert der Router die verworfenen Pakete, das kann bei einer ev. Fehlersuche sehr hilfreich sein. In dem Fall bei weiteren Ergänzungen der Access-Lists bedenken, dass neue Statements immer am Ende angehängt werden! Gruss Markus

Egal. 1 Konfig die sich jeder Router beim ersten Einschalten per TFTP holt und für jeden Router ein spezielles Konfig-File mit den paar Parametern die vom Standard abweichen. - Router holt sich die Default-Konfig - Spezial-Konfig per Kommandozeile vom FTP nachladen - Abspeichern - Nächster Router Die Spezial-Konfigs mit einem Editor zu generieren sollte kein Problem sein - und auf jeden Fall schneller gehen als mit dem ConfigMaker ein paar hundert bunte Netze zu zeichen oder ein Netz ein paar hundert Mal zu editieren und die Konfigs per Crossover- und Konsolenkabel in die Router zu laden. Gruss Markus

Hi, ein unkonfigurierter / neuer 801 defaultet auf TFTP und versucht, von da eine Konfig zu kriegen. DHCP mit TFTP-Option aufsetzen, TFTP-Server aufsetzen, Konfig-File(s) auf TFTP hinterlegen, Router einschalten, warten, Konfig per Telnet / Konsole speichern, fertig. Schneller geht nimmer. Gruss Markus

Achso, spar Dir die redundanten Einträge. Wenn Du CDP mit no cdp run schon Global abschaltest ist das no cdp enable auf den Interfaces / Dialern obsolet. Analog das ganze PPP-Geraffel auf dem BRI - fackel das nach Möglichkeit auf dem Dialer ab. Hat was mit Lesbarkeit zu tun und hilft bei der Fehlersuche :D - der redundante Kram führt da gerne in die Irre wenn man denkt man hat was rausgeschmissen und an anderer Stelle stehts doch noch drin. Gruss Markus

Hi, Dein Dialer-Problem liegt auf den ersten Blick in den Debug nicht am ISDN. Gib mir mal einen debug ppp auth Zeitsynchronisation: clock timezone met 1 clock summer-time mest recurring last Sun Mar 2:00 last Sun Oct 3:00 ntp server 10.100.1.101 version 1 service timestamps log datetime localtime Frag mal die Hilfe mit "ntp server ?" wegen den Optionen, irgendwo kann man da Synchronisationsintervalle setzen. (ich habe intern einen NTP stehen als Zeitreferenz, reicht wenn der sich mit einem öffentlichen NTP abgleicht, muss nicht jedes Netzwerkdevice selber machen, ausserdem ist es "guter Stil", die öffentlichen NTP nicht mit vermeidbaren Anfragen zu belasten). Öffentliche NTP z.B. ntp1.ptb.de und ntp2.ptb.de, weitere google. Auf das Ethernet vielleicht noch: ntp broadcast client (muss nicht sein) Access-Liste auf Dialer: (ist ein Auszug von meiner Konfig, möglicherweise funktioniert bei Dir das nicht alles weil ich erstens einen 3620er verwende und zweitens ein ziemlich aktuelles IOS Plus mit 3DES/FW habe): interface Dialer0 description Backup zu ISP wenn DSL futsch ip address negotiated ip access-group 100 in no ip directed-broadcast ip nat outside ip inspect 3620firewall out encapsulation ppp dialer remote-name blafasel dialer string 4711 dialer pool 1 dialer-group 1 priority-group 1 no cdp enable ppp authentication pap ppp pap sent-username nixiss password xxxxx access-list 100 deny ip 192.168.0.0 0.0.255.255 any log access-list 100 deny ip 172.16.0.0 0.15.255.255 any log access-list 100 deny ip 10.0.0.0 0.255.255.255 any log access-list 100 deny ip 127.0.0.0 0.255.255.255 any log access-list 100 deny ip 224.0.0.0 31.255.255.255 any log (Damit blocke ich alle Pakete von Absendern die nach der höheren Lehre der reinen und wahren IP-Wissenschaften an einem externen Interface eigentlich nie auftauchen sollten, interessanterweise filtert fast kein ISP diese Netze auf seinen Routern so dass man permanent Hits auf diese Einträge hat. Das "log" am Ende weist den Router an, entsprechende Matches auf den Syslog zu schreiben. Und wenn wir schon gerade dabei sind, den Laden zuzumachen: access-list 100 permit tcp any any established access-list 100 permit tcp any any ack access-list 100 deny tcp any any log access-list 100 deny udp any eq netbios-dgm any access-list 100 deny udp any eq netbios-ns any access-list 100 deny udp any eq netbios-ss any access-list 100 deny tcp any eq 137 any access-list 100 deny tcp any eq 138 any access-list 100 deny tcp any eq 139 any access-list 100 deny udp any any eq snmp log access-list 100 deny udp any any eq 79 log access-list 100 deny udp any any eq rip log access-list 100 deny udp any any eq bootpc log access-list 100 deny udp any any eq bootps log access-list 100 deny udp any any eq snmptrap log access-list 100 deny udp any any eq sunrpc log access-list 100 deny udp any any eq syslog log access-list 100 deny udp any any eq ntp log access-list 100 permit udp any any access-list 100 deny icmp any any information-request log access-list 100 deny icmp any any mask-request log access-list 100 deny icmp any any router-advertisement log Das mit dem interesting Traffic habe ich auch etwas enger gefasst: access-list 1 permit 10.100.1.0 0.0.0.255 access-list 1 deny any ip nat inside source list 1 interface Dialer0 overload Im Gegensatz zum gängigen "dialer-list 1 protocol ip permit" macht mein Dialer nur auf wenn ein IP-Paket aus meinem internen Netz nach draussen will, könnt ja jeder kommen. Wenn Du den HTTP-Server unbedingt laufen lassen willst: ip http server ip http access-class 1 (access-list 1 siehe oben) Damit ist der Zugriff auf das interne Netz beschränkt. Analog Telnet: line vty 0 4 access-class 1 in access-class 6 out Access-List 1 siehe oben. Fehlende Access-List nachreich: access-list 6 deny any Etwas Routing gefällig? router ospf 1 redistribute connected network 10.100.1.0 0.0.0.255 area 0 ip route 0.0.0.0 0.0.0.0 10.100.1.254 10 1 ip route 0.0.0.0 0.0.0.0 Dialer0 50 2 Routing ist bei Dir wahrscheinlich nicht sinnvoll - oder hast Du weitere - direkte oder indirekte - Pfade ins Internet? Gruss Markus

Hi, das mit dem "no shutdown" auf dem BRI0 ist sicher schonmal ein Schritt in die richtige Richtung :D Konfig weiter absichern: - HTTP-Server abschalten - in der Access-List 121 die Netze 10/8, 172.16/12 und 192.168/16 blocken - VTY und Konsole: exec-timeout setzen - VTY und Konsole: Banner setzen - VTY access-list setzen - weiteren externen DNS im DHCP eintragen - Domain-Namen auf dem Router und im DHCP setzen - NetBIOS und 137-139 auch outbound blocken - Zeitserver eintragen, entsprechend konfigurieren dass der nicht permanent die Leitung aufmacht! - Protokollierung aktivieren (Syslog), zumindest mal die Access-Listen damit überwachen Gruss Markus