Cisco 800 ungewollte Verbindungstrennung

[Pusi 10]

Hallo,

 

ich muss mich um folgendes Problem kümmern:

 

Cisco 800 mit "Standleitung" zur Gegenstelle. Verbindung besteht seit mindestens einem Jahr, angeblich ohne Konfiguratiosnänderung. Seit ein paar Wochen wird die Verbindung in regelmäßigen Abständen nach ca. 5 Minuten getrennt (bei Leerlauf), das soll aber nicht sein.

 

Ich soll nun herausfinden, ob das auf unserer Seite oder an der Gegenstelle liegt. Da ich mit meinen wenigen Cisco-Kenntnissen nur die Konfiguration auslesen kann, wäre mir sehr geholfen, wenn mir jemand die Konfigzeilen nennt für eine automatische Trennung nach x Minuten Idle-Time bzw. "niemals trennen".

 

Vielen Dank

[n@ppo 10]

hi,

 

um welchen cisco der 800er serie handelt es sich denn (801, 803..).

es wäre auch hilfreich den leitungstyp und die ios-version nebst konfig zu erfahren bzw. besondere gegebenheiten (multilink, usw)

[Pusi 10]

Hm, da kann ich frühestens Montag drauf antworten. Hab nur flüchtig draufgeschaut und die 800 gesehen. Hängt direkt am NTBA und nutzt schätze ich nur einen B-Kanal.

[Pusi 10]

Hallo, es ist ein 801 und darum geht es mir:

 

Original geschrieben von Pusi

 

...Da ich mit meinen wenigen Cisco-Kenntnissen nur die Konfiguration auslesen kann, wäre mir sehr geholfen, wenn mir jemand die Konfigzeilen nennt für eine automatische Trennung nach x Minuten Idle-Time bzw. "niemals trennen".

 

Vielen Dank

[n@ppo 10]

hi,

 

bei einer festverbindung zieht der idle-timer nicht. der ist nur bei wählverbindungen relevant.

 

deshalb auch meine fragen bezüglich der releasestände konfiguration usw.

[Frank04 10]

Ja, wenn es eine 64 SFV ist, dürfte da nix abgebaut werden.

 

Vielleicht hat die T, da heimlich ein ISDNer rausgemacht...aber Spass beiseite: Wenn wirklich keine Änderungen beidseitig gemacht wurden, dann ist entweder die Ltg. defekt oder die Cisco-HW spinnt.

[n@ppo 10]

hi,

 

da ab und an auch die vermittlungsstellen ein softwareupdate bekommen kann der fehler auch dort begraben sein.

 

gerade die 801 haben ab und an mit der eingesetzten hardware und software probleme.

 

ein beliebter bug ist das der d-kanal bei einer leased-line konfig nicht automatisch von 801er serie shutdown genommen wird und irgendwann wenn sich keiner mehr daran erinnert fehler auftauchen.

ein workaround ist den d-kanal (int bri0) shutdown zu setzen.

 

wie gesagt das kann muß aber nicht der fehler sein. wie Frank04 schon schrieb kann es auch ein genereller fehler der leitung oder die hardware des routers sein.

[laurasan 10]

Hallo,

 

Mit was für ein Kabel verbindet sich der Router mit dem NTBA, wenn es normale ISDN-Kabel sein sollte würde ich es mal mit ein CAT5 kabel probieren, denn ich habe auch schon son Prob gehabt nach dem Austausch ging es wieder.

 

MfG

[Pusi 10]

Kabel ist Cat5, die Software der Vermittlungsstelle wurde am 15.2. umgestellt. Es ist aber leider nicht genau nachvollziehbar ob die Probleme seit dem Termin auftreten oder erst später.

 

Ich lese mal die konfig aus und poste sie, möchte ja nur wissen, ob es an unserer Seite der Verbindung liegt.

[Pusi 10]

So, da bin ich wieder :-)

 

hier die config des Routers und die Frage, warum nach 5 Minuten die Verbindung getrennt wird.

 

xxx-xxx#show conf

Using 1782 out of 8065 bytes

!

version 12.0

no service pad

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname xxx-xxx

!

!

ip subnet-zero

!

isdn leased-line BRI0 128

!

!

!

interface Ethernet0

ip address x.x.x.x 255.255.0.0

no ip directed-broadcast

!

interface BRI0

description >> WAN ISDN 128K nach xx Standleitung ueber NetCologne <<

bandwidth 128

ip address xx.xx.xx.xx 255.255.255.252

no ip directed-broadcast

!

no ip http server

ip classless

ip route xx.xx.xx.xx 255.255.255.255 xx.xx.xx.xx

ip route xx.xx.xx.xx 255.255.255.255 xx.xx.xx.xx

ip route xx.xx.xx.xx 255.255.255.255 xx.xx.xx.xx

ip route xx.xx.xx.xx 255.255.255.255 xx.xx.xx.xx

ip route xx.xx.xx.xx 255.255.255.255 xx.xx.xx.xx

ip route xx.xx.xx.xx 255.255.255.255 xx.xx.xx.xx

ip route xx.xx.xx.xx 255.255.255.255 xx.xx.xx.xx

ip route xx.xx.xx.xx 255.255.255.255 xx.xx.xx.xx

ip route xx.xx.xx.xx 255.255.255.255 xx.xx.xx.xx

ip route xx.xx.xx.xx 255.255.255.255 xx.xx.xx.xx

ip route xx.xx.xx.xx 255.255.255.255 xx.xx.xx.xx

ip route xx.xx.xx.xx 255.255.255.255 xx.xx.xx.xx

ip route xx.xx.xx.xx 255.255.255.255 xx.xx.xx.xx

ip route xx.xx.xx.xx 255.255.255.255 xx.xx.xx.xx

ip route xx.xx.xx.xx 255.255.255.255 xx.xx.xx.xx

ip route xx.xx.xx.xx 255.255.255.255 xx.xx.xx.xx

ip route xx.xx.xx.xx 255.255.255.255 xx.xx.xx.xx

ip route xx.xx.xx.xx 255.255.255.252 BRI0

!

access-list 100 permit ip any any

snmp-server engineID local xxxxxxxxxxxxxxxxxxxxxxxx

snmp-server community public RO

snmp-server community private RW

snmp-server enable traps snmp

snmp-server enable traps isdn call-information

!

line con 0

password xxxxxxxxxxxxxxxxxx

login

transport input none

stopbits 1

line vty 0 4

password xxxxxxxxxxxxxxxxxx

login

!

end

 

 

Ist die so ok bezüglich Standleitung ?

 

Vielen Dank für Eure Hilfe

[n@ppo 10]

hi,

 

rein theoretisch funktioniert die konfiguration so.

das ganze setzt aber voraus das beiden pakete die der router die beiden b-kanäle schickt ohne großen zeitversatz auf der anderen seite ankommen müssen. da kann der cisco bei einer "leased-line 128" konfig maximal 2 hoch 4 oktets ausgleichen. dann ist schicht im schacht.

eine konfig in der art funktioniert in den meisten fällen nicht oder nicht dauerhaft. cisco hat dazu auch ein dok. veröffentlicht. ich finde es nur im moment nicht.

 

wenn dein provider kanale über unterschiedliche systeme in die fernebene führt oder ein b-kanal fehler aufweist kann das unter umständen schon das problem sein.

 

günstiger ist da eine konfig mit "ppp multilink". die multilink pakete werden mit einer sequence-nummer versehen und können so auf der anderen seite wieder "zusammengebaut" werden.

bei einer multilink-konfig kann theoretisch sogar ein b-kanal ausfallen und die verbindung funktioniert trotzdem noch.

dies ist bei einer "leased-line 128" nicht unbedingt gegeben.

ev. hat ja einer der kanäle ein problem. das wäre auch eine

erklärung, alldieweil dann die "leased-line bri128" konfig nicht zuverlässig nicht funktioniert.

 

 

ich würde bei deinem provider mal erfragen ob bezüglich der leitungsführung etwas geändert wurde und gegebenenfalls die konfig ändern. dies muß auf beiden seiten erfolgen und danach muß ein reload erfolgen.

 

 

genaueres kann ich dir erst sagen wenn du mir mal folgende debugger und ausgaben schickst. "deb interface brI0", sho int bri0.

 

mach mal einen "extended ping" mit 1000 byte und 500 paketen und schau ob die pings alle durchlaufen.

 

ändere die konfig und schau dann wie sich das ganze verhält.

 

hier die konfig:

 

#

no isdn leased-line BRI0 128

isdn leased-line BRI0

!

int multilink1

ip address xx.xx.xx.xx 255.255.255.252

multilink-group 1

!

int bri0

no ip address

shut

!

int bri0:1

encapsulation ppp

ppp multilink

multilink-group 1

!

int bri0:2

encapsulation ppp

ppp multilink

multilink-group 1

#

 

 

 

das routing bleibt dabei unverändert. die ip-adressen mußt du anpassen.

[Pusi 10]

Super! Da werd ich mal mit dem Kollegen drüber sprechen.

 

Herzlichen Dank für die Mühe, werde berichten sobald wir was probiert haben.

[steffen3379 10]

hi

 

habe da auchmal eine frage mein cisco 803 funzt jetzt endlich eigentlich richtig gut , auser im chat da trennt er immer nach der im idle-timer eingestellten zeit ab. geht ein chat über einen anderen port raus? der den timer nicht zurück setzt oder ist der datenstrom zu gering???

 

wer kann helfen

danke

mfg