🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: dnet.inet
Article #320

Re: CISCO <==> IBM 3745

#320
From: Toerless Eckert
Date: Sat, 06 Jul 1991 13:28
82 lines
4878 bytes
Auch Hallo

[...]
> (d) was fuer Schnittstellen sind beteiligt: V.35 oder RS-449?
> 
> (e) falls RS-449: hast Du auf der Cisco-Seite ein DTE- oder ein DCE-Applique?

Falls V.35 - DCE/DTE Applique oder DTE Applique ?

> (f) Jumper fuer Clock-Selection auf der entsprechenden Cisco-Interface-Karte
>     (und ggf. auch noch auf dem Applique)?

Vielleicht zum Verstaendnis der Jumpersituation:
Die Jumper auf dem MCI oder SCI board der Cisco bestimmen, welcher Takt
vom Line Controller auf selbigen board verwendet wird. Es gibt die
Moeglichkeit, den internen Taktgenerator zu verwenden, oder den Takt
zu nehmen, der vom Applique kommt. Die Taktfrequenz des internen Taktgenerator
kann man ueber das Kommando "clockrate" veraendern. 
Bei diesen Jumpern auf dem MCI board ist es weiterhin moeglich, "inverse
clock" zu verwenden oder "normal clock". Dies ist gedacht um
Phasenverschiebungen bei laengeren Kabel auszugleichen, es lohnt sich
auf jeden Fall, dies auszuprobieren, wenn es mit "normal clock" nicht
funktioniert. Im Endeffekt ist das nichts anderes, als das bei
"inverted clock" die A und B Taktsignalleitungen vertauscht sind, was einem
Phasenshift von 180 Grad enspricht.

Weiterhin gibt es dann die Appliques, naemlich DTE und DCE Appliqes. Diese
legen im Grunde genommen fuer Layer 1 das DTE/DCE Verhalten fest, das nicht
identisch sein muss mit dem lapb und X.25 DCE/DTE Verhalten.

Bei den RS449 Appques (oder besser bei der RS449 Signalisierung) geht
das Taktsignal vom DCE (Layer 1) aus. Dafuer gibt es die beiden Signalleitungen
ST fuer Send Timing (Sendedaten vom DTE) und RT fuer Receive Timing
(Sendedaten vom DCE). Dann gibt es noch die TT Taktleitung (Terminaltiming),
die tatsaechlich das ueber das DTE zurueckgeschleifte ST Timing ist. Da das
ST Timing vom vom DCE kommt, aber die eigentlichen Sendedaten (SD) vom DTE
sind SD und ST im DCE nicht phasensynchron, insbesondere bei laengeren
Kabeln zwischen DTE und DCE. Deshalb das TT Signal.

Bezogen auf Ihre Probleme gibt es zwei Knackpunkte:

1. Wenn Sie ein Interface physikalisch als DCE fahren wollen, muessen
   Sie auf jeden Fall die MCI Board Jumper auf "internal clock" legen.

2. Es gibt keine Garantie dafuer, das bei Verwendung des DTE Appliques
   ueberhaupt das interne Clocksignal irgendwo auf dem Applique
   auftaucht, es ist also fraglich, ob Sie ueberhaupt ein DTE
   Applique als physikalisches DCE fahren koennen. Ich bin mir nicht sicher,
   aber ich wuerde schaetzen, dass Sie doch eher ein DCE Applique
   verwenden sollten.

3. Wenn Sie dann ein DCE Applique haben, und das ueber ein Telemation
   uebliches RS449/X.21 Kabel an die IBM verbinden, muessen sie auf
   jeden Fall den Jumper auf dem DCE Applique umsetzen, dieser regelt naemlich
   ob das DCE die SD (Sendedaten) mit TT oder ST sampled, default TT.
   Da ueber die ueblichen RS449/X.21 Kabel aber TT nicht zurueckgefuehrt
   wird, haengt der Takt dann einfach in der Luft.
   Viel Spass dabei, dafuer duerfen Sie naemlich den Deckel des Cisco
   aufschrauben (14 Schrauben spaeter und Tags dadrauf ;-)).

> Bei Problemen lohnt sich im uebrigen haeufig einmal nachzusehen welchen
> Debug-Output die Cisco dazu liefern kann; die Debug-Traces sind haeufig
> sehr informativ sind (bei X.25 sollte man sich die CCITT-Empfehlung
> dazulegen, da z.B. die Zustandsnamen aus der X.25 mitangezeigt werden).
> Wenn man die Konsolfunktion ueber das Netz angewaehlt hat,
> "terminal monitor" nicht vergessen!

- Nie Debuggingoutput uber die Console gehen lassen, die Console hat
  naemlich hoechste prioritaet,d.h. wenn sie auf die Console ausgibt
  macht die Box nichts anderes mehr.

- Bei Ihrem Problem sollte "debug serial" und "debug lapb" ausreichen.

>   > Vielleicht hat schon einmal jemand ein aehnlich verwegenes Unterfangen
>   > erfolgreich abgeschlossen und kann mir einen Tip geben.
> nein, die praezise gleiche Aufgabenstellung noch nicht; aber man kennt ja
> so gewisse, uebliche Probleme:-)

Genau, dieselben Probleme hat man auch, wenn man einfach 2 Ciscos zusammen
schliessen will. Was immer irgendwie fehlt ist in den Handbuechern eine
Beschreibung von so elementaren Dingen wie RS449 oder X.21 funktionieren.
Technical Details
Message-ID: <9107061328.AA02979@faui43.informatik.uni-erlangen.de>
Path: arc1-ca.pugleaf.net!gmdzi!unido!fauern!Informatik.Uni-Erlangen.de!Toerless.Eckert
References: <9107052139.AA16500@deins.informatik.uni-dortmund.de>

Show Full Headers
Complete Article Headers
X-Google-Language: GERMAN,ASCII-7-bit
X-Google-Thread: 13322c,3a6bfcceabacf3c1
X-Google-Attributes: gid13322c,public
X-Google-ArrivalTime: 1991-07-06 10:48:31 PST
Path: arc1-ca.pugleaf.net!gmdzi!unido!fauern!Informatik.Uni-Erlangen.de!Toerless.Eckert
From: Toerless.Eckert@Informatik.Uni-Erlangen.de (Toerless Eckert)
Newsgroups: dnet.inet
Subject: Re: CISCO <==> IBM 3745
Message-ID: <9107061328.AA02979@faui43.informatik.uni-erlangen.de>
Date: 6 Jul 91 13:28:58 GMT
References: <9107052139.AA16500@deins.informatik.uni-dortmund.de>
Sender: Toerless.Eckert@Informatik.Uni-Erlangen.de
Organization: The Internet
Lines: 82