Wurstbläser

jo poste mal - bin ich mal gespannt wie es jetzt läuft. Die über die Access-Listen definierte dialer-list sollte man wenn irgend möglich weiter einschränken (z.B. nur Http, Email etc.) das senkt die Kosten erfahrungsgemäß. ... die Radprofis aus Deutschland ziehen ja auch zuerst in den Schwarzwald, und wenns ihnen da zu flach wird in die Schweiz (dort darf man dann sein Steuersätze noch zusätzlich selbst aushandeln). Hab die ganze letzte Woche die Tour de Suisse verfolgt - nette Ecke da unten ... Gruss Robert

Hallo Tom also auf der 3Com Website steht ziemlich klar dass er 802.1q beherscht. Wenns euch also erstmal nur auf die VLANs ankommt dürfte das wohl funktionieren. Würds aber vorher mal ausprobieren. Was steht denn im Handbuch wie man die Switche Konfiguriert - Konsole? Am Handbuch lesen kommt Ihr da wohl nicht vorbei ... Gruss Robert

.. dann bin ich auch mal gespannt wann darktemplar wieder auftaucht dieses "callin" hab das mal in diesem Cisco Field Manual für Router nachgeschlagen - so richtig ausführlich ist das dort wohl auch nicht beschrieben. Bei Amazon.com hab ich mal billige gedruckte Exemplare der offiziellen IOS-Doku gesehen - muss ich nochmal schauen ob die sich lohnen ... @rob: ne bin nur Hobbyrenner (D-Lizenz :) ) - fürs Fahrrad ist mir im Frühjahr zu lange zu kalt. Laufe mehr .. Gruss Robert

Du köntest Dialer 1 zunächst ohne die Authentifizierung zu konfigurieren. Dann kann man die Routing/Map und andere zuordnungsprobleme zuerst lösen. Die access-list 2 ist aber irgendwie sehr unschön - also nach so ziemlich jedem Lehrbuch empfielt sich da "access-list 2 permit <source net>" - also zweimal any any - ne ne wundert mich echt das das geht? da hätte ich jetzt mal eben 100 € verwettet! Wenn eine ACL eine Nr. von 1-99 verwendet handelt es sich um eine Standard-Access-Liste die nur die Quell IP (Netz, Subnetz oder Host). Deshalb macht access-list 1 permit any keinen Sinn - Sie schränkt ja auch nichts ein ... Gruss, bis Morgen - Robert

nochwas: NAT auf dem Dialer 1 zur Zweigstelle braucht man doch auch nicht - auf dem Dialer fehlte dazu eh das statement "ip nat outside" also die Zeile "ip nat inside source list 1 interface dialer 1" kann auch weg. Außerdem referenziert "ip nat inside source list 2 ..." doch eine ACL Nr. 2 - die seh ich auch nicht. Also flugs hinzaubern: "access-list 2 permit 172.16.8.0 0.0.0.255" Gruss Robert @rob 67: ein CANYON FACT 2 mit Shimano Ultegra

OK machen wir einfach hier weiter (muss aber gleich mal kurz weg :) ) Also dann würde ich vorschlagen zuerst einen Dialer - den fürs Internet ordentlich einzuricheten. Danach machen wir den zweiten zusätzlich. Versuche dabei folgendes zu berücksichtigen: 1. die Zeile "no ip split-horizon" wird da erstmal nicht gebraucht - weg damit. 2. weise die Tel. Nr zuerst mit dem "dialer string 123456" zu - keine maps 3. benutze wenn möglich 2 verschiedene ACLs - die wirst Du später sicher dringend brauchen um den Verkehr einzuschränken. Also besser dialer-group 2 -> dialer-list 2 protocol list 102 -> access-list 102 permit ip any 0.0.0.0 0.0.0.0 dialer-group 1 -> dialer-list 1 protocol list 101 -> access-list 101 permit ip any 172.16.13.0 0.0.0.255 (für später) 4. bitte die Authentifizierung zum ISP mal aussortieren, besser kein PAP benutzen. Das keyword "callin" finde ich da komisch, soll eigentlich bedeuten das die authentifizierung nur für eingehende Anrufe benutzt werden soll. Alosnur : "ppp authentication chap" keine "ppp pap sent-username ..." Kann mir nicht vorstellen dass der Provider kein CAP kann. 5. vielleicht die Routing-Tabelle in diese Richtung: ip route 0.0.0.0 0.0.0.0 dialer 2 ip route 172.16.13.0 255.255.255.0 dialer 1 (für später) danch sollte man erst mal den Ping zum ISP ans laufen kriegen. Mein Vorschlag. So muss aber gez erstmal 2h Radfahren Gruss Robert

@darktemplar: ich hab den Eindruck das da irgenwie immer mit textfiles hantiert wird. Die Ausrufezeichen sind wirklich an komischen Stellen - Wer hat denn Dialer Control List 1 da rein geschrieben - die kämen doch erst 4 Zeilen später. Ist da irgend so ein komischer automatischer Konfig-Maker zugange?? Gruss Robert PS: ist das echt die "show running-config" die wir da sehen?

Wenn Du eh in deinen ACL 101 + 102 permit ip any any benutzt könntest Du die dialer-list auch einfacher schreiben und stattdessen "dialer-list 1 protocol ip permit" schreiben. eigentlich würde ich als nächstes "debug ppp negotiation" ausprobieren. Mit der Fehlermeldung beim Abspeichern kann ich garnichts anfangen. Die dialer pool konfiguration ist eigentlich tadellos ??? Ohne dialer-group X Befehl wird die Verbindung nie aufgebaut werden. Das ist allenfalls für einen Dialer denkbar der nur eingehende Anrufe annimmt ... "Mischen" kann man die schon - was auch immer das heißen soll - die Befehle haben eben nichts miteinander zu tun. Also ich sehe jetzt wenig Ansatzpunkte - soll die Fehlermeldung bedeuten dass die Konfiguration garnicht anzuspeichern ist?? Das hieße nichts weiter als das die KOnfiguration die die debug-meldungen nicht die ist die wir zu sehen kriegen oder? Ich habe jetzt echt Schwierigkeiten den Änderungen zu folgen. Wir bräuchten mal eine Konfig, die wenigstens halb geht - und von da aus müssen wir weiter. Dann muss man entscheiden z.B. "no ip split-horizon" ist ein nutzloser Befehl - wie kommt der da rein? Und wenn man sich über so ein Problem klar ist, nächster punkt ... Der debug zeigt ja cdp-Packete an obwohl die auf dem dialer eigentlich disabled sind? vielleicht kann man das auchmal mit "no cdp run" im globalen-config abschalten. Gruss Robert

... ein reload musst Du nicht jedesmal machen - die Änderungen werden eigentlich sofort wirksam. Mach das Debugging lieber über Telnet - ist weniger CPU intensiv (einloggen per telnet: terminal monitor)

Hi Felix - DNS ist optional - Du mußt routen: Dein XP-PC muss Anfragen an das LAN2 an die NIC2 richten. Du würdest also eine Route auf deiem Windows PC einrichten. Angenommen LAN 1 = 192.168.1.0/24 (NIC 1 dein bisheriges Netz) LAN 2 = 192.168.2.0/24 (NIC 2 IP 192.168.2.1, deine IP Kamera ) route -p add 192.168.2.0 mask 255.255.255.0 192.168.2.1 Falls jetzt noch andere aus deinem Netz auf die IP Kamera zugreifen wollen brauchen Die natürlich auch eine entsprechende Route die auf deine IP der NIC1 zeigt ... Hier stößt das statische Routen aber an seine Leistungsgrenze. Eine Route auf einem zentralen Router ginge natürlich auch. Routingprotokoll gehen in dem Fall wohl nicht, da XP meines Wissens nach keins kann (kann XP RIP oder OSPF ??? die Server können das soweit ich weiß) XP Pro ist aber auch kein besonders praktikabler Router.. Gruss Robert

@rob: stimmt - hat mich auch gewundert. Sind wir mal gespannt was uns darktempla gleich berichten wird ... @darktemplar: Also ich denke sinnvoll wäre eine aktuelle konfig und die Fehlermeldung aus dem debug die sich reproduzieren läßt. Damit die konfig nicht so lang wird, es reichen ja Routingtabelle, BRI, Dialer und die dialer-lists und ACL - kann man ja ein bisschen zusammenstreichen. Irgendwie kriegen wir ja nichtmal raus woran ungefähr es liegen könnte - Authentifizierung käme ja auch noch in Frage. Die Konfiguration der Gegenstelle wäre dafür ja auch wichtig - und genau dieses Router zu Router wählen klappt ja nicht ... Bisher haben wir ja nur auf Deine erste Konfig geguckt und so vermutet, und geschaut was etwas ungewöhnlich aussieht ...

moin show flash | zeigt den Inhalt Deines Flash Speichers - hier liegt Dein IOS copy flash tftp | initiiert einen Dialog der dich nach den Parametern abfragt, um dein IOS-Image als file aus Deinem flash-speicher auf einen tftp-Server zu kopieren - den Du vorher auf deinem PC eingerichetet hast. Gruss Robert

@rob67 also "dialer in-band" - benutzt man das nicht nur wenn man analoge Gegenstellen von einem ISDN BRI oder PRI aus anwählt? Was hat der "dialer pool" damit zu tun? Also Rotary-Group und Dialer-Pool sollte man alternativ benutzen ...

@tom12: warum muss der Provider ein Routing-Protokoll konfigurieren? Wenn ein GRE-Tunnel aufgbaut ist, ist das doch die Privatangelegenheit des LAN-Betreibers ob oder was für ein Routingprotokol er benutzt. Dann würde doch auch ein "dialer watch" super funktionieren - dieser würde einspringen sobal die Route in der Routingtabelle verschwindet .... Gruss Robert

Also die Troubleshooting Reihenfolge sollte jetzt so aussehen: 1) wird der richtige Dialer ausgewählt (ping + debug ppp dialer) 2) wählt der B-Kanal die Gegenstelle korrekt an (Layer 2/3 -> debug isdn q933) 3) schafft PPP den Verbindungsaufbau über die ISDN Leitung

1. mit "dialer pool-member 1" mit BRI0 dem Pool 1 zugeordnet - fertig. 2. mit "dialer pool 1" wird Dialer X gesagt: benutze ein BRI/B-Kanal aus dem Pool 1 - fertig. dialer-list und dialer-group haben mit dem BRI nichts mehr zu tun. dialer-group X sagt: benutze dialer-list X (dort steht dann weiteres) Gruss Robert PS: dein Beitrag 14: heißt das der Dialer wird nun angesprochen - anders als im Beitrag 1 Ist das ne Verbesserung?

tja, das übliche wäre ja statisches NAT - bin da etwas am rätseln welchen Sinn es machen würde.. Wie soll der andere Ethernet-Port je mit dem Internet kommunizieren wenn ALLE Ports des IP-Verkehrs auf eine interne IP umgeleitet werden? Was währe dann noch der Unterschied zur konfiguration von PPPoE direct auf der NIC deines Servers? Das Übliche wäre doch das man sich ein Anzahl von Ports aussucht, und zusätzlich zum dynamischen NAT ein paar statische Einträge mit den entsprechenden Ports zusätzlich statisch 'mapt'. (mit dem keyword "range" kann man doch Bereiche zusammenfassen ... spart doch jede Menge Tipperei) Gruss Robert

kleiner Nachtrag/Frage: gibt es nicht noch ein drittes Subnetz? Dein LAN am Fa0 hat 172.16.8.0/24, dein Dialer zwischen den CISCO Routern hat 172.16.4.0/24 - dann sollte es doch ein drittes IP Subnetz geben, an der LAN Schnittstelle dieses anderen Routers ... ist das 172.16.13.0/24? .. dann müsste meine ACL 101 die ich vorhin gepostet habe natürlich entsprechend korrigiert werden - sorry - (also dann .13 statt .4) Gruss Robert

also CCIEs finden doch eigentlich immer Jobs - oder meinst Du mit CCIE-Skills Leute die denken Sie wäre super Netzwerk-Hechte lediglich das Geld für Zertifikate hat bisher gefehlt? Sucht euch Doch ein paar CCxP's - die müssen sich in drei Jahren doch eh mit der 350-001 Klausur - so gewünscht rezertifizieren ... Gruss Robert

@rob ja, mmhh, könnte sein - bin mir selbst da nicht sicher. darktemplar schreibt aber das die Dialer einzeln gehen wenn er den jeweils anderen auskommentiert. Deshalb vermute ich den Fehler in der Auswahl der Dialer. In Beitrag 5 schreibt er "no dialer-group defined" ... Die Dialer selbst laufen ja erstmal ... @darktemplar Bitte "debug ppp dialer" benutzen etc. Gruss Robert

Moin also für mich nicht einfach da ich den Kurs 2000 nicht kenne. Wenn Du Dich am Exam-Certification Guide (Cisco Press) orientierst dürftest Du aber keine Überraschungen erleben. Die CatOS Befehle interessieren kaum noch, und die Fast-Switching Techniken sind etwas weiterentwickelt. AAA QoS und Multicasting (ist ja eher was zum routen) sind vielleicht Themen, bei denen ich mir vorstellen könnte das die dazugekommen sind ... Gruss Robert

@darktemplar: folgende drei Befehle müssen bei Dir mal "sortiert" werden dialer-group 1 dialer-list 1 protocol ip ... access-list ... Du hast beide Dialer über dieselbe dialer-list angesprochen. Der im Befehl dialer-list definierte traffic bestimmt welcher traffic den Dialer auslösen soll. Du musst also schon mal mind. 2 verschiedene dialer-lists referenzieren. Also unter Dialer 1 kommt > dialer-group 1 Dialer 2 kommt > dialer-group 2 jetzt werden 2 verschiedene dialer-list erstellt dialer-list 1 protocol ip list 101 dialer-list 2 protocol ip list 102 in einer entsprechenden ACL definiert man jetzt den genauen traffic access-list 101 permit ip 172.16.8.0 0.0.0.255 172.16.4.0 0.0.0.255 (oder access-list 102 permit ip any 172.16.4.0 0.0.0.255) eure Zweigstelle access-list 102 permit ip 172.16.8.0 0.0.0.255 0.0.0.0 0.0.0.0 ISP (besser über die einzelnen Ports ausarbeiten) Also mach die die Regeln klar "dialer-group 1" bezieht sich auf "dialer-list 1 protocol ip list 101". Diese bezieht sich auf die ACL 101 ... Etwas anderes: Du brauchst nicht mit mehreren Dialer-Pools zu arbeiten, Du hast ja nur eine BRI Schnittstelle. Beide Dialer können mit Dialer Pool 1 denselben Pool benutzen. unter BRI0 reicht dann dialer pool-member 1. Gruss Robert

@KFN3000 ... bin heute morgen beim surfen zufällig auf einen neuen Router von Linksys (bisher nur auf den US Seiten) gestoßen: ich meine den RT042, der hat 2 WAN ports und QOS features [so 90$ Strassenpreis in USA] -> http://www.linksys.com/products/product.asp?grid=34&scid=29&prid=684 Bliebe in den Handbücher zu recherchieren, ob Dir das was nützt. Die Fragen nach der Verwaltung von zwei DSL/WAN Anschlüssen scheint zuzunehmen ... Gruss Robert

Moin Moin Statt sich einen ISA zu keufen könnte man auch das policy-based routig auf einem (hoffentlich vorhandenen) Cisco Router (z.B. 17xx, 26xx etc) konfigurieren. Bitte doch euren Cisco-Fachmann den Skype-Verkehr über eine Access-Liste (->Layer 4) zu filtern und mit einer Route-Map statt der Standard-Routing-Tabelle zu routen. Ist im Prinzip eine Variante des Layer 4 Routings wie oben von Gruzzly999 beschrieben. Falls ihr keine Literatur habt -> Cisco Website nach "policy based routing" oder "route-maps" suchen. Gruss Robert

@ xcooldj hab gerade diesen Thread 'studiert' - wie wärs mit diesen Ideen: 1. Fest IPs bei 2-4 Rechnern 2. So ne kleine Routerbüchse (z.B. was ordentliches von Linksys) - diesen könntet Ihr geradezu Ideal als Printserver, DHCP-Server, Switch, und Backup-Router nutzen. Zusätzlich - als Paranoia-Bonus sozusagen - bestünde die Möglichkeit eure Standleitung zusätzlich per VPN/IPSec zu veschlüsseln falls man seinem Provider oder dem lokalen Hausmeister nicht traut. Das alles mit der 50-100€ Kiste die eure jetzige Lösung nur erweitert und keine zusätzlichen SPF "Single Points of Failure" einführen würde. Um die Lösung zu bewerten müßte man das in euer Budget einordnen oder die technischen Anforderungen eurer 'Außenposten' kennen .. Gruss Robert