ISDN-Einwahl - Layer2-Problem

[niedax 10]

Guten Morgen zusammen,

 

ich versuche mich auf einem CISCO 1812 in einer Aussenstelle per ISDN einzuwählen. Der Router hängt per Patchkabel direkt an einem neuen NTBA, keine Telefonanlage dazwischen. Wir nutzen ISDN zur Fernadministration und als Backup für die DSL-Leitung. Dies funktioniert in mehreren Aussenstellen auch schon ohne Probleme.

Doch in besagter Aussenstelle klappt die Einwahl/das Backup nicht. Folgendes schon getestet:

 

- Telekom hat Leitung überprüft --> OK

- Kabel getauscht --> keine Veränderung

- Per Fritz!Card über den Anschluss rausgewählt auf Handy --> OK

- mehrfach:

--> clear interface bri0

--> shut/no shut

--> reload

 

Ich habe schon sämtliche ISDN-Troubleshoot-Dokumente von CISCO durch. Es scheint so, als hätte ich das selbe Problem, wie der User in DIESEM THREAD

 

HINWEIS: Die Einwahl hat ein einziges Mal funktioniert, nachdem ich das ISDN-Kabel an die anderen Anschluss am NTBA geklemmt habe. Ein paar Stunden später (keine Änderung zwischendurch) gings dann wieder nicht. Seitdem kein Erfolg mehr.

 

Hier mal die relevanten Configauszüge und einige Statiangaben:

 

sh run

!

isdn switch-type basic-net3

!

interface BRI0

no ip address

encapsulation ppp

load-interval 30

dialer pool-member 2

isdn switch-type basic-net3

isdn tei-negotiation first-call --> eingefügt laut CISCO-Tutorial

isdn point-to-point-setup

ppp authentication ms-chap chap

ppp multilink

ppp timeout idle 120

 

sh isdn status

 

Global ISDN Switchtype = basic-net3

ISDN BRI0 interface

dsl 0, interface ISDN Switchtype = basic-net3

Layer 1 Status:

DEACTIVATED

Layer 2 Status:

TEI = 255, Ces = 1, SAPI = 0, State = ESTABLISH_AWAITING_TEI

Layer 3 Status:

0 Active Layer 3 Call(s)

CCB:callid=800B, sapi=0, ces=1, B-chan=1, calltype=DATA, hdlctype=HDLC-TRUNK

Active dsl 0 CCBs = 1

The Free Channel Mask: 0x80000002

Total Allocated ISDN CCBs = 1

 

sobald ich mich einwähle und dabei das Kommando "sh isdn status" auslöse, ändert sich der Status:

 

sh isdn status

Global ISDN Switchtype = basic-net3

ISDN BRI0 interface

dsl 0, interface ISDN Switchtype = basic-net3

Layer 1 Status:

ACTIVE

Layer 2 Status:

TEI = 255, Ces = 1, SAPI = 0, State = ESTABLISH_AWAITING_TEI

Layer 3 Status:

0 Active Layer 3 Call(s)

CCB:callid=C, sapi=0, ces=1, B-chan=1, calltype=DATA, hdlctype=HDLC-TRUNK

Active dsl 0 CCBs = 1

The Free Channel Mask: 0x80000002

Total Allocated ISDN CCBs = 1

 

Danach legt er einfach auf, weil er anscheinend keine TEI zugewiesen bekommt. Folgend noch die Debug-Ausgaben:

 

sh debugging

 

The following ISDN debugs are enabled on all DSLs:

 

debug isdn error is ON.

debug isdn q921 detail is ON.

debug isdn q921 frame is ON. (filter is OFF)

debug isdn mgmnt detail is ON.

debug isdn silent errors is ON.

 

Logmeldungen --> siehe beigefügte Textdatei debug-isdn.txt

 

Ein "isdn test call interface brI 0 MeineTelefonnummer" liefert:

 

Logmeldungen --> siehe beigefügte Textdatei debug-isdn.txt

 

 

Hat jemand ne Idee, was ich noch versuchen könnte. So wie's ausschaut, bekommt die BRI keine TEI zugewiesen? Merkwürdig ist, dass ich die RX vom NTBA, jedoch nicht die TX vom Router im Log sehe.

 

Danke für eure Hilfe.

 

Gruß,

 

Stefan

debug-isdn.txt

[Wordo 11]

Hast du schon mal die Cisco an nen anderen NTBA gehaengt (bzw andere Leitung), um das BRI mal auszuschliessen? Der ISDN Status sollte eigentlich immer Active sein sofern die Verbindung vom BRI zum NTBA passt.

[niedax 10]

Ja, ich hab's mal an einem anderen NTBA versucht, aber da hängt noch eine Telefonanlage mit dran, die wir nicht betreuen und da bin ich mir nicht sicher, ob er den Call richtig durchstellt. Hat jedenfalls auch nicht geklappt. An diesem Standort habe ich leider keine andere Möglichkeit.

Der ISDN Status sollte eigentlich immer Active sein sofern die Verbindung vom BRI zum NTBA passt

Note: In certain parts of the world (notably in Europe), Telco ISDN switches can deactivate Layer 1 or 2

when there are no active calls. Hence, when there are no active calls, show isdn status indicates that Layer 1

and 2 are down. But when a call occurs, Layers 1 and 2 are brought up. Make a test BRI call to verify whether

the BRI functions. If the call succeeds, no further ISDN troubleshooting is necessary.

Quelle: "Cisco − Using the show isdn status Command for BRI Troubleshooting"

 

Beim Anwählen springt er ja auch auf Active. Wir haben dieses Phänomen auch schon in einer anderen Aussenstelle beobachtet. DEACTIVATED scheint kein festes Indiz dafür zu sein, dass es nicht klappen wird.

[Wordo 11]

Ich hatte sowas aehnliches mal, da waren die Kupferdraehte im NTBA (oder Splitter?) vertauscht. Da hatte die Telekom die einfach ueberbrueckt anstatt das ordentlich zu machen. Ein Test an nem 2ten NTBA waere echt nicht schlecht. Oder wenigstens 2 Outgoing Calls hintereinander. Dann sollte bei der Telanlage nicht der Fehler kommen wie im Log.

[Ja_mei 10]

Bei deiner konfig ist mir was aufgefallen:

 

Wenn es ein normaler ISDN Mehrgeräteanschluß ist sollte als point-to-multipoint anstatt point-to-point-setup eingestellt sein. Das könnte deien L2-Fehler verursachen.

[niedax 10]

Danke für eure Antworten:

 

@ Wordo: Wenn die Drähte vertauscht wären, würden dann die ausgehenden Anrufe mit der Fritz!Card funzen? Vielleicht teste ich es doch nochmal an der Telefonanlage

 

@Ja_mei: point-to-multipoint kann ich auf dem BRI-Interface gar nicht konfigurieren

[rob_67 10]

Hi,

 

 

und wenn du no point-to-point-setup sagst?

 

 

gruss

 

 

rob

[niedax 10]

Das hab ich natürlich auch schon probiert :cool:

[niedax 10]

Noch jemand ne Idee??

[rob_67 10]

Hi,

 

 

nimm mal den Befehl isdn tei-negotiation first-call wieder runter, der router kriegt beim ersten connect einen TEI zugewiesen, es sollte auch so funzen, damit er beim Initialisieren einen TEI zugewiesen bekommt.

 

 

dann post mal debug isdn error, isdn event, isdn standard und isdn q921.

 

 

Bist du sicher, daß es ein EURO ISDN ANschluß ist oder kann es auch ein 1TR6 Anschluß sein?

 

 

Gruss

 

rob

[niedax 10]

Hallo Rob,

 

danke für deine Hilfe. Anbei die Debug-Meldungen. Habe das "isdn tei-negotiation first-call" wieder vom BRI entfernt.

 

Bist du sicher, daß es ein EURO ISDN ANschluß ist oder kann es auch ein 1TR6 Anschluß sein?

 

Die aktive Vermarktung von Anschlüssen des Nationalen ISDN wurde bereits Mitte der 1990er Jahre eingestellt; der Betrieb wurde nach mehreren Verlängerungen zum Jahresende 2006 endgültig eingestellt. Kunden der Telekom AG, die noch Anschlüsse des Nationalen ISDN hatten, wurde im September 2006 die Nutzung zum Jahresende gekündigt. Die gekündigten Anschlüsse wurden spätestens in der Nacht vom 28. auf den 29. Dezember 2006 zwangsweise auf DSS1 umgestellt. Dieser Wechsel zu DSS1 ist für die Kunden kostenlos, jedoch werden sich die betroffenen Teilnehmer in der Regel neue Endgeräte anschaffen müssen.

 

Ich gehe daher einfach mal davon aus.

 

Gruß,

 

Stefan

isdn-debug.txt

[rob_67 10]

Hi,

 

 

Jun 25 12:58:43.170: ISDN BR0 SERROR: L2_Go: at bailout DLCB is NULL

L2: sapi 63 tei 255 ces 0 ev 0x650

 

-->weiß nicht ob das ein Fehler ist, finde leider auch bei cisco so gut wie nichts.... error klingt nicht gut.

 

 

Jun 25 12:58:47.170: ISDN BR0 Q931: Ux_DLRelInd: DL_REL_IND received from L2

 

Er sieht den D-Kanal Layer 3 den bekommt er vom Layer 2 diese Meldung und wirft den call ab, dein dialer war schon connected.

 

 

nimm mal noch debug dialer events dazu, da auch der dialer 5 sec connect hatte.

 

den debug würde ich mal noch abwarten, welche ios version hattest du gleich drauf?

 

was ist das für ein bri? ein wic? es muss ein bri s/t sein, vielleicht hast du ein bri-ll? deshalb auch kein multipoint setup?

 

gruss

 

rob

[niedax 10]

Moin.

 

Danke für deine Bemühungen.

 

welche ios version hattest du gleich drauf?

Cisco IOS Software, C181X Software (C181X-ADVIPSERVICESK9-M), Version 12.4(9)T1, RELEASE SOFTWARE (fc2)

 

Ich habe gerade mal auf den anderen 1812ern nachgeschaut, bei zwei anderen ist die selbe Version drauf und bei denen geht's. Also vielleicht doch ein defekter NTBA/defektes BRI??

 

was ist das für ein bri? ein wic? es muss ein bri s/t sein, vielleicht hast du ein bri-ll?

Ist ein BRI S/T.

 

nimm mal noch debug dialer events dazu, da auch der dialer 5 sec connect hatte

Jun 28 06:32:28.744: BR0:1 DDR: Caller id XXXXXXX matched to profile XXXXXX

Jun 28 06:32:28.744: BR0:1: interface must be fifo queue, force fifo

Jun 28 08:32:28.744: %DIALER-6-BIND: Interface BR0:1 bound to profile Di99

Jun 28 08:32:28.744: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up

Jun 28 08:32:28.744: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to XXXXXXX N/A

Jun 28 08:32:34.624: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected from XXXXXXX , call lasted 5 seconds

Jun 28 08:32:34.624: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

Jun 28 06:32:34.624: BR0 DDR: has total 0 call(s), dial_out 0, dial_in 0

Jun 28 08:32:34.624: %DIALER-6-UNBIND: Interface BR0:1 unbound from profile Di99

 

Danke und Gruß,

 

Stefan

[Wordo 11]

Bekommst du beim debug von ppp neg und ppp auth nen Timeout? Vielleicht sind da 2 Geraete am NTBA und das andere schnappt sich den Call?

[rob_67 10]

Hi,

 

das was wordo sagt, kann zwar auch passieren, glaube ich aber nicht, da der connect da ist und sogar der dialer schon gebunden ist.

 

 

mich wundert eher, das du es nicht auf multipoint setup umsetzen kannst, zwei möglichkeiten,

 

 

no point-to-point-setup auf dem bri configurieren und schauen, was er sagt oder den befehl lassen und einen static tei festlegen isdn static tei 64 (0..64) und dann schauen, was passiert. ich kenne den 1812er nicht, vielleicht hat der irgendwelche abweichenden sw defaults... falls du einen statischen tei setzt, interface clearen... grund für die probleme ist auf jeden fall der layer2

 

gruss

 

rob