phrock
-
Gesamte Inhalte
23 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von phrock
-
-
Hallo michael01,
hast du das Problem mittlerweile gelöst?
Oder hat vielleicht sonst jemand eine Lösung bzw. helfende Hinweise?
Wäre echt klasse!
-
Hallöle,
ich bin eher QoS-unerfahren, habe da Thema aber demnächst auch umpfangreicher auf dem Tisch.
Was aber auf jeden Fall zu klären ist:
Soll bestimmter Verkehr künstlich eingeschränkt werden, egal wie hoch die Auslastung der Leitung insgesamt ist, oder soll bei hohem Datenaufkommen bestimmter Verkehr bevorzugt und anderer benachteiligt werden?
Was mir noch aufgefallen ist:
Warum markierst du die Pakete mit den DSCP-Werten: ef und af21? Das macht doch eigentlich nur Sinn, wenn dein Gegenüber diese auswertet und für diese Pakete und deren weitere Verarbeitung ein kleines Regelwerk konfiguriert hat!?
bis denn dann erstmal
-
Hallöchen,
ich bin ja ein Freund des Debuggen.
gibt denn ein: "debug ip nat" oder "debug ip nat detailed" oder eben "debug ip nat ?" usw. etwas her?
Ein "term mon" zuvor bei Telnet-Verbindung auf den Router nicht vergessen!
Na denn viel Erfolg,
der robert
-
Hallöchen,
sehr schön - Problem scheinbar gelöst.
Nur für private Zwecke noch der Tipp:
Mit "no ip unreachables" auf den Interfaces "sicherst" du das Teil nochmal ein Stückchen besser ab!
Ohne diesen Eintrag sendet der Router dieses "administratively prohibited unreachable" an die pingende Gegenstelle:
*Mar 1 00:51:21.551: ICMP: dst (192.168.10.174) administratively prohibited unreachable sent to 192.168.10.163
- und somit weiß der Pingende ja dann eigentlich, daß da was ist, was nicht angepingt werden will!
Mit dem Eintrag "no ip unreachables" unterläßt er das Senden der unreachable-Meldungen. Somit ist er dann bei einfachen Ping-"Scans" unsichtbar.
die Lösung einmal komplett:
!
interface ethernet0
ip access-group 101 in
no ip unreachables
!
interface serial0
ip access-group 101 in
no ip unreachables
!
access-list 101 deny icmp any any echo
access-list 101 permit ip any any
!
-
Hallo,
ich glaube du übersiehst da was ganz Entscheidendes:
ICMP ist nicht nur Ping!!
Du blockst jeden ICMP-Traffic, der über das S0-Interface an den Router gerichtet wird.
Sailer hat es schon kurz angesprochen:
Schau dir in dem Zusammenhang "echo request" und "echo reply" an!
Dies ist nur ein Denkanstoß.
-
Hallo,
probier mal:
"ppp authentication chap callin"
unterm dialer1.
Ansonsten:
Wenn ihr Lust habt, dann laßt uns mal ein wenig dran bleiben an dem "Projekt".
Ich hatte nämlich auch vor, die Tage mal eine vernünftige AOL-ISDN-Einwahl für nen Bekannten zu kreieren und dabei sinnvolle access-listen und andere Sicherheits-Features etc. zu nutzen.
Im Moment bin ich arbeitstechnisch nur arg eingebunden und hab nach den-ganzen-Tag-Konfigs-schreiben Abends keinen rechten Antrieb mehr, da weiter zu machen. Aber ich steig in den nächsten Tagen ein wenig intensiver ein.
Bis denn erstmal
-
Ahja, das ist interessant.
Ich weiß es aber auch net! - hätte es nur so vermutet.
Es gibt natürlich die Möglichkeit, daß sich unterschiedliche IOS-Versionen unterschiedlich verhalten.
Ich glaub, ich hol' mir morgen mal so ne Kiste hier rüber auf die Couch und mach mir selber ne Konfig fertig - erstens reichen mir diese Spekulationen und zweitens wollte ich mir für den Fall, daß mir meine andere Kiste mal abraucht, schon immer ne vernünftige Konfig erstellen.
Hat mal jemand den Config-Maker bemüht?
Die damit erstellten Konfigs sind zwar ähnlich gut, wie mit MS Frontpage erstellte Web-Seiten ;) , aber ich gehe davon aus, daß der CM diese doch eigentlich recht einfache Kür fehlerfei meistern sollte.
Vielleicht werden ja aber auch noch mal die Ergebnisse der Fehlersuche vom Initiator hier gepostet!?!?!
;)
Dann bis denn
-
Hi,
nur kurz: versuch mal, vorher das "dialer in-band" unterm Dialer wegzunehmen.
->
conf t
int di1
no dialer in-band
Und dann probier ma' nochmal "dialer pool 1" und "~member...".
Ein fröhliches Fest ich wünsch'!
Bis denn
-
Hallo,
was Hr_Rossi sagt, ist auf jeden Fall korrekt!
+ das "ip nat outside" unterm BRI0 weg.
Vielleicht einfach mal probieren - denke aber trotzdem an ein IOS-Problem.
Gibts denn im Flash ein Crash-Info?
Bis denn
-
Hallo scooby,
!
interface FastEthernet0
description LAN 4Competence GmbH Koblenz
ip address 192.168.137.253 255.255.255.0 secondary
ip address 192.168.153.254 255.255.255.0
no ip redirects
no ip proxy-arp
ip nat inside <----
speed auto
!
Das meinte ich.
Auf dem Ethernet 0 sollte meiner Meinung nach kein "ip nat outside" konfiguriert sein, da ja der Dialer als logisches Interface über dem Ethernet0 (-> die "Physik") steht.
Der Dialer1 ist die mit der Außenwelt kommunizierende (sozusagen Layer3-)Schnittstelle.
Deshalb wird auch die AddressTranslation zwischen dem WAN- (Dialer1) und der LAN-Schnittstelle (FastEthernet0) durchgeführt.
Joa, dann wünsch ich uns Allen ein fröhliches Fest im Kreise unserer Lieben!
Dann bis denn,
phrock
-
Hallo,
probier' die Konfig:
version 12.2
no service pad
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname Router
!
logging queue-limit 100
no logging console
!
ip subnet-zero
ip dhcp excluded-address 10.10.10.1
!
ip dhcp pool CLIENT
import all
network 10.10.10.0 255.255.255.0
default-router 10.10.10.1
dns-server 217.237.149.225
lease 0 2
!
!
ip audit notify log
ip audit po max-events 100
vpdn enable
!
vpdn-group pppoe
request-dialin
protocol pppoe
!
no ftp-server write-enable
isdn switch-type basic-net3
!
!
!
!
!
!
!
interface Ethernet0
ip address 10.10.10.1 255.255.255.0
ip nat inside
ip tcp adjust-mss 1452
no cdp enable
!
interface BRI0
no ip address
encapsulation ppp
shutdown
dialer pool-member 2
isdn switch-type basic-net3
!
interface ATM0
no ip address
no atm ilmi-keepalive
pvc 1/32
pppoe-client dial-pool-number 1 dial-on-demand
!
dsl operating-mode annexb-ur2
!
interface Dialer1
description T-online Zugang ueber DSL
mtu 1492
ip address negotiated
ip nat outside
encapsulation ppp
dialer pool 1
dialer idle-timeout 180
dialer hold-queue 10
dialer-group 1
no cdp enable
ppp authentication chap callin
ppp chap hostname xxxxxxxxxxxxxxxxxxxxxx#0002@t-online.de
ppp chap password 7 xxxxxxxxxxxxxxxxxxxxx
ppp ipcp dns request
!
!
ip nat inside source list 23 interface Dialer1 overload
ip classless
ip route 0.0.0.0 0.0.0.0 Dialer1
no ip http server
no ip http secure-server
!
access-list 23 permit 10.10.10.0 0.0.0.255
access-list 199 permit tcp 10.10.10.0 0.0.0.255 any eq www
access-list 199 permit tcp 10.10.10.0 0.0.0.255 any eq pop3
access-list 199 permit tcp 10.10.10.0 0.0.0.255 any eq smtp
access-list 199 permit tcp 10.10.10.0 0.0.0.255 any eq 443
access-list 199 permit tcp 10.10.10.0 0.0.0.255 any eq ftp
access-list 199 permit tcp 10.10.10.0 0.0.0.255 any eq ftp-data
access-list 199 permit tcp 10.10.10.0 0.0.0.255 any eq domain
access-list 199 permit udp 10.10.10.0 0.0.0.255 any eq domain
access-list 199 permit udp 10.10.10.0 0.0.0.255 any eq 20
access-list 199 permit udp 10.10.10.0 0.0.0.255 any eq 21
access-list 199 permit udp 10.10.10.0 0.0.0.255 any eq 443
access-list 199 permit udp 10.10.10.0 0.0.0.255 any eq 25
access-list 199 permit udp 10.10.10.0 0.0.0.255 any eq 110
access-list 199 permit udp 10.10.10.0 0.0.0.255 any eq 80
access-list 199 deny tcp any any
access-list 199 deny udp any any
access-list 199 deny ip any any log
dialer-list 1 protocol ip list 199
no cdp run
!
!
line con 0
exec-timeout 120 0
stopbits 1
line vty 0 4
access-class 23 in
exec-timeout 120 0
login local
length 0
!
scheduler max-task-time 5000
no rcapi server
!
!
!
end
Die Verbindung steht für 300 Sek. nach dem letzten interested traffic.
Interested und uninterested traffic ist z.B. mit:
"debug dialer packet"
zu ermitteln.
Der interested traffic ist ausgehender Verkehr mit den Zielports 20, 21, 25, 53, 80, 110, 443 ; Zieladresse uninteressant; Quellport uninteressant; Quelladresse im Netz: 10.10.10.0 /24
interessante Abfragen:
show caller timeout
show dialer
show dialer interface dialer1
show caller user
show caller user <username> detail -> show user
Na probier's mal.
Vielleicht auch mal auf Cisco-HP mit den Schlagworten:
"Understanding and Troubleshooting Idle Timeouts"
"PPPoE Client DDR Idle-Timer"
suchen.
Bis denn,
phrock
-
Original geschrieben von scooby
[...] Das heißt weiter du mußt auf dem Ethernet 0/0 auch ip nat inside einstellen.
Ich denke, das ist nicht notwendig!?
In der Konfig ist das FastEthernet0 als NAT-Inside und der Dialer als NAT-Outside gekennzeichnet.
Dadurch setzt er bei die Adressen der ACL 1 (192.168.153.0 /24) in die des Dialer1 um - und umgedreht.
Was sagt das Debugging?
-
Hallo,
ich hab leider nicht viel Zeit - deshalb nur kurz:
zur CHAP-Prozedur: Suche auf der Cisco-Seite mit den Schlagworten: "PPP Authentication ppp chap hostname and ppp authentication" - das solltest du auf jeden Fall fündig werden.
zu dem Callin: nimm's "callin" beidseitig raus, dann authentifizieren sie sich gegenseitig - ist doch ok.
IP-Negotiation: Ja, das stimmt.
Load-threshold: Ja, so ähnlich würde ich's auch denken. Habe den Algortihmus aber noch nie hinterfragt.
Zu der Zeit (5 Minuten etc.): wahrscheinlich kann man diese Zeit mit "load-intervall ~" runtersetzen. Statt des "~" kannst du Werte ab 30 aufwärts einsetzen. 30 steht dann für 30 sek. Da bin ich mir aber nicht sicher, ob dieser Eintrag auch mit dem load-threshold "korrespondiert".
Aber vielleicht kommen ja noch qualifiziertere Aussagen als die meinigen...
Bis denn
-
Hallo,
ich versuch mich mal an einem Erklärungsversuch deiner Fragen:
>username user2 password XXXXXX <-- Warum werden hier sowohl Username und Passwort für beide Router angegeben???
Schau dir Unterlagen zur Chap-Prozedur an. -> Der eine authentifiziert sich beim anderen.
>ppp authentication chap pap callin <-- ist das Callin an dieser Stelle richtig? Der Router soll schliesslich nur wählen und nicht angewählt werden, ausser beim RAS.
"callin" bedeutet, daß nur er sich beim Gegenüber ausweisen muß - dies macht Sinn bei Einwahlen bei einem Provider (z.B. T-Online), da sich T-Online nicht bei mir, dem sich einwählenden, authentisieren muß/soll, sondern ich mich gegenüber T-Online
"callin" macht in deinem Fall nicht wirklich Sinn!
>ip address negotiated <-- Sollte hier nicht die WAN IP stehen?
Damit läßt er sich die IP-Adresse dynamisch zuweisen!
>dialer load-threshold 10 either <-- Reicht der Wert 10? Ab wann würde sich der zweite Kanal dazu schalten?
Ich glaube, daß dieser Wert in einem Bereich zw. 1 und 255 liegen muß. 0 bedeutet - keine Auslastung, 255 bedeutet Vollauslastung
10 Wäre somit ein rel. niedriger Wert, sodaß er u.U. recht schnell den zweiten Kanal aufbauen würde. Der Zeitraum, den er für diese Berechnung zu Rate nimmt, ist natürlich nich interessant.
Mir schwirrt da "load-intervall 30" im Hinterkopf rum - default ist, glaub ich, 5 Minuten. - Also wenn über 5 Minuten im Mittel der Threshold erreicht ist, baut er den zweiten Kanal auf.
-> Cisco: Interface load used to determine whether to initiate another call or to drop a link to the destination. This argument represents a utilization percentage; it is a number between 1 and 255, where 255 is 100 percent.
>ip route 0.0.0.0 0.0.0.0 Dialer1 <-- Wenn ich mich nicht täusche sollte dies die kriegsentscheidene Route sein, die sämtliche Pakete über die ISDN Leitung zum Router 2 schickt??
Ja, das ist korrekt.
>logging buffered 8192 debugging <-- Was hat dieser Eintrag hier zu suchen, was macht er für "böse" Sachen??
Damit stellst du dem Router 8192 bytes Speicher für Logging-Zwecke zur Verfügung. Du kannst dir den Inhalt per "show log" anschauen.
Darin werden z.B. solche Dinge wie Dialer-Aufbauten etc. aufgezeichnet.
Vielleicht ist's ne kleine Hilfe.
Bis denn,
Phrock
-
Hallöchen,
mangels Erfahrungen auf dem Gebiet DSL-Einwahl und Tunneling kann ich nur meine spekulativen Überlegungen zu der Konfig kundtun:
Zuerst sollte geklärt werden, ob du überhaupt online kommst - hast du ein wenig mit dem debugging rumgespielt?
"debug dialer events"
"debug dialer packet"
"debug dialer ?"
"debug ppp authentication"
"debug ppp negotiation"
...
Vielleicht kannst du ja dabei aufschlußreiche Informationen erhalten.
-> Bei einer Telnet-IP-Connection auf den Router das "term mon" nicht vergessen!
Zu deiner Konfig: Ich weiß nicht, ob der Eintrag "pppoe-client dial-pool-number 1" unter dem Interface Ethernet0 richtig ist.
Sollte der nicht unter dem Dialer stehen? - Wie schon gesagt, ich habe noch keine Erfahrungen im (privaten) DSL-Einwahl-Bereich.
Weiterhin vermisse ich unter dem Ethernet0-Interface die Zuordnung zum Dialer-Pool 1.
Zum Tunneling sage ich lieber nicht so viel, da dies ein Thema ist, welches ich mir zwar schon immer zu Gemüte führen wollte, aber nie dazu kam... :(
Nur eins:
Per "ip unnumbered dialer1" unter dem Tunnel10 "borgst" du dir die Adresse des Dialer1, welcher sich seine wiederum dynamisch holt. - Dies ist korrekt so?
Naja, vielleicht hilfts ja ein klein wenig!?
Poste bitte auf jeden Fall mal deine im Endeffekt funktionierende Konfig, wenn du's denn dann soweit hast.
Bis denn dann,
phrock
-
Hallöle,
ich denke nicht, daß es an irgendeiner Stelle der Konfig hapert!
Ich vermute ein IOS-Bug.
Ich rate dir, unbedingt mal ein anderes IOS zu probieren!
Bis denn,
phrock
-
Hallöchen,
ich hab hier eventuell noch eine Lösung, die weiterhelfen könnte.
Meine Lösung, die noch eingehend von mir zu testen sein wird, sieht wie folgend aus: siehe Bild (Anhang) und Text unten
(Bitte die "Professionalität" der Zeichnung nicht beachten. Ich hab' kein Visio hier und Zeit und Muße, eine ansehnlichere Darstellung anzufertigen hatte ich auch nicht. Man möge es mir verzeihen.)
Einige Einträge könnten eventuell redundant sein. So zum Beispiel die doppelte Angabe des Name-Servers einmal global und noch einmal unter dem DHCP-Server. Was noch zu testen wäre. ;)
Na dann viel Spaß damit. Sollte es Fragen geben - einfach melden.
!
version 12.2
no service pad
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
service password-encryption
service compress-config
!
hostname c1603R
!
logging queue-limit 100
logging buffered 32000 debugging
enable secret 5 <removed>
!
username c1603R privilege 15 password 7 <removed>
username tdata password 7 <removed>
ip subnet-zero
ip name-server 192.168.10.161
ip dhcp excluded-address 10.199.199.129
!
ip dhcp pool Pool1
import all
network 10.199.199.128 255.255.255.252
default-router 10.199.199.129
dns-server 192.168.10.161
lease 0 2
!
isdn switch-type basic-net3
!
!
!
interface Loopback0
ip address 10.101.101.3 255.255.255.255
!
interface Ethernet0
ip address 192.168.10.174 255.255.255.240
ip mtu 1492
ip nat outside
no ip route-cache
no cdp enable
!
interface BRI0
no ip address
encapsulation ppp
dialer pool-member 1
isdn switch-type basic-net3
isdn answer1 123456789
no fair-queue
no cdp enable
ppp multilink
!
interface Dialer1
ip address 10.199.199.129 255.255.255.252
ip nat inside
encapsulation ppp
dialer pool 1
dialer remote-name tdata
dialer-group 1
peer default ip address dhcp
no cdp enable
ppp multilink
!
ip nat inside source list 23 interface Ethernet0 overload
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.10.161
ip route 10.101.125.240 255.255.255.248 10.199.199.130
no ip http server
!
!
access-list 23 permit 10.101.101.3
access-list 23 permit 10.101.125.240 0.0.0.3
access-list 23 permit 10.199.199.128 0.0.0.2
access-list 100 permit ip any any
dialer-list 1 protocol ip list 100
no cdp run
!
line con 0
exec-timeout 0 0
logging synchronous
login local
line vty 0 4
session-timeout 20
exec-timeout 20 0
logging synchronous
login local
!
sntp server 130.149.17.21 version 3
end
!
-
Hallöchen,
nur als Tip im nachhinein:
vielleicht solltest du temporär deine(n) gefundenen Fehler rückgängig machen und ein wenig mit den Debuggen fortzusetzen.
-> ich weiß nicht, ob's was bringt, aber du könntest noch folgende debugging-Möglichkeiten ausschöpfen:
"debug dialer events"
"debug dialer packet"
"debug dialer ?" (- ich kann nicht eindeutig sagen, ob es noch mehr Möglichkeiten gibt und ob die vorher Genannten etwas Aufschlussreiches bringen)
Vielleicht ist sind die Erkenntnisse ja interessant für spätere Zwecke. (arbeitstechnisch, privat...)
- und vielleicht hätte dich dies früher auf die Lösung des Fehlers gebracht - man lernt nie aus! :)
bis denn,
rob
-
Hallo xyCruiseryx,
die vier Zeilen:
*Mar 1 00:03:29.979: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 1 00:03:29.995: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
[...]
*Mar 1 00:03:30.979: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to down
*Mar 1 00:03:30.995: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, changed state to down
sagen dir, daß die beiden B-Kanäle down sind. Ich denke, das ist in deinem Sinne. ;)
Über den ISDN-Staus kannst du dich mit folgendem Befehl informieren:
"show isdn status"
Da kannst du dann den Status der Layer 1, 2 und 3 erfahren.
Weiterhin kannst du dann auch mal mit dem Debugging rumspielen:
"term mon" (falls Connection zum Router per telnet)
"debug isdn q921" (Layer 2 - z.B. TEI-Zuweisung)
"debug isdn q931" (Layer 3 - z.B. Verbindungsaufbau)
"debug isdn ?" (für weiteres Zeugs)
Hilfreich?
Viel Spaß damit.
-
Nachtrag:
bitte das CDP ausschalten!
conf t
no cdp run
int di1
no cdp ena
int bri0
no cdp ena
end
-
Hallo zimbo123,
Problem schon gelöst?
Falls nicht:
Du hast in der Config 2x "ip nat outside"!
interface Ethernet0
description T-DSL
ip nat outside
!
interface Dialer1
ip nat outside
Ich bilde mir ein, mich zu erinnern, bei einem Cisco-ISDN-Workshop als Info mal mitgenommen zu haben, daß bei einer "ISDN-Connection" zwei Mal "encap ppp" (auf BRI UND auf Dialer) auch nicht funktioniert.
Ich könnte mir vorstellen, daß das der Fehler ist!
Auf dem Eth0 sollte kein "ip nat outside" konfiguriert sein.
Bitte einfach mal probieren und Ergebnis hier posten.
Viel Erfolg!
-
Hallo firescout,
also ich bin jetzt nicht der Cisco-Guru, aber mich wundert fast, daß du überhaupt online kommst. In der Config ist steht folgendes:
dialer-list 1 protocol ip list 1
Dieser Eintrag "korrespondiert" mit dem Eintrag
dialer-group 1
unter dem Dialer1 und bezieht sich auf auf eine access-list 1 (~ list 1).
Mit dieser dialer-list wird angegeben, welches der "interested traffic" ist, also der Verkehr, der den Dialer aktivieren und aufrecht erhalten soll/darf.
Dadurch, daß du keine access-list 1 angegen hast, wundert es mich, daß überhaupt eine Verbindung zustande kommt. Aber ich muß zugeben, ich habe diesen Fall noch nie ausprobiert.
Der interested traffic muß also eingeschränkt werden!
Du mußt dir also überlegen, welcher Verkehr den Dialer aufbauen UND aufrecht erhalten darf!
Beispiel: Surf-Verkehr (Port 80, 443) , dein ICQ (5190) und Mail (Port 110).
Tja, und daraus ne access-list erstellt dürfte dann in etwa so ausschauen:
access-list 199 permit tcp any any eq 80
access-list 199 permit tcp any any eq 110
access-list 199 permit tcp any any eq 443
access-list 199 permit tcp any any eq 5190
access-list 199 deny tcp any any log
Du mußt natürlich dann den Eintrag:
dialer-list 1 protocol ip list 1
auf
dialer-list 1 protocol ip list 199
abändern:
folgende zwei Zeilen im global configuration mode (conf t) reinkopieren:
no dialer-list 1 protocol ip list 1
dialer-list 1 protocol ip list 199
Weiterhin habe ich grad überlegt, ob es zusätzlich noch sinnvoll wäre, den idle-timeout nur auf den ausgehenden Verkehr triggern zu lassen:
"dialer idle-timeout 30 outbound" statt "dialer idle-timeout 30" unterm Dialer1. -> Vielleicht einfach zusätzlich probieren.
Eine kurze Erklärung: Ich habe gerade keinen Cisco vor mir. Deshalb ist alles hier gesagte recht theoretisch! -> Bitte einfach ausprobieren!
Das "log" am Ende des letzten Eintrags der acces-list gibt den Traffic aus, der den Dialer NICHT aufbauen oder aufrecht erhalten darf!
Vielleicht kannst du damit ja herausfinden, welcher traffic noch interessant für dich ist.
Rumspielen solltest du vielleicht auch mit dem Debugging:
debug dialer packet
und
debug dialer events
beides im enable-mode (sog. privileged exec mode).
Solltest du dich per telnet auf den Router connected haben, dann vorher noch "term mon" ausführen!
Wichtig auf jeden Fall: Die access-list an die dialer-list gebunden schränkt KEINEN Verkehr ein! Sie dient lediglich der Definition, welcher Verkehr den Dialer aufbauen und aufrecht erhalten darf oder soll!!!
Stöber vielleicht noch ein wenig auf den Cisco-Seiten rum. Mit ein wenig Muße und Suchgeschick kannst du da alle Infos finden.
Nun gut, ich hoffe, es hat geholfen und daß meine Tipps korrekt waren. ;o)
Viel Erfolg und schreib mal bitte, ob es geklappt hat.
Grüße aus Potsdam
Probleme mit Cisco 1721 und BRI-Interface
in Cisco Forum — Allgemein
Geschrieben
Ich glaube fast weniger, daß es hilft, aber versuche mal folgendes:
Mache den Router mal komplett nackig, will heißen, außer der Konfig:
!
isdn switch-type basic-net3
!
interface BRI0
no ip address
isdn switch-type basic-net3
!
und dem normalen default-Kram (wr erase + reload) sollte nichts weiter drauf sein.
Und dann probiers nochmal mit dem Debugging:
debug isdn q921
debug isdn q931
(ggf. ergänzt durch die bereits angesprochenen: "deb isdn l2" und "deb isdn events")
und dem hier:
isdn test call interface bri0 <Telefonnummer>
Statt <Telefonnummer> nimmst du einfach deine eigene Nummer, also die des ISDN-Anschlusses, an dem du gerade mit deinem Router steckst.
Die Ausgabe des Debuggings kannst du ja mal posten.
Hintergrund des Ganzen: Eventuell hinderliche Konfig-Teile als Fehlerursache auszuschließen.
Obwohl auch andere das schon vor mir getan haben, muß ich trotzdem auch nochmal dämlich nachfragen: Das Kabel ist wirklich in Ordnung?