🚀 go-pugleaf

Hallo Udo,

  > ich versuche seit einigen Tagen, unseren CISCO AGS+ Router ueber ein
  > serielles Interface mit einer IBM 3745 bekannt zu machen. Ziel ist es,
  > die X.25-Switching-Funktion der CISCO-Buechse auszunutzen und X.25-
  > Verkehr aus dem WIN ueber die entsprechende Subadresse unserem MVS
  > zukommen zu lassen ( und umgekehrt).
ja, und so erhaelt man als einen positiven Seiteneffekt auch noch eine
X.25-Untervermittlung, die mit einem Standard-Netzwerk-Management-Protokoll
ueberwacht werden kann (de facto-Standard reicht ja meist fuer praktische
Zwecke...)

  > Leider verstehen sich die beiden Maschinen bisher nicht, un das aeussert
  > sich so:
ich tippe darauf, dass die beiden Systeme sich gegenseitig ueberhaupt nicht
verstehen, wegen Verwirrung bzgl. Taktgenerierung. Wie hast Du denn die
Takt-Versorgung geregelt. Fragen dazu:

(a) hast Du Modems (oder einen "Modem-Eliminator) in der Strecke, die den 
    Takt liefern sollen?

(b) oder hast Du einfach ein Kabel mit passender Kreuzung der Signale?

(c) falls ja zu (b): soll die 3745 oder die Cisco den Takt liefern?
    (oder auch noch wechselweise, da mindestens RS-449 getrennte Signale
    fuer beide Richtungen unterstuetzt!)

(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?

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

(Das ansonsten natuerlich im Kabel noch beliebig viele Wuermer sein koennen,
will ich garnicht erwaehnen).

  > Die Generierung der DCE-Schnittstelle an der CISCO sieht so aus:
  > !
  > interface Serial 2
  > no ip address
  > encapsulation X25-DCE
                      ^^^
dies legt im wesentlichen nur die Stationsadressen im LAPB und die Verwendung
der Kanalnummern auf Ebene 3 fest.
Was die Schnittstellen-Signale bzgl. DTE/DCE angeht, sagt das nichts.

  > lapb n1 1712
  > clockrate 64000
  > !
  > Den lapb-Parameter habe ich von einem anderen seriellen Interface
  > uebernommen, ohne mir weitere Gedanken darueber zu machen. Es ist mir
  > bisher aber noch nicht gelungen, ihn wieder zu loeschen (no lapb...).
solange Du keine Paketgroessen >128 Byte verwenden willst, ist der Parameter
kein Problem.

Ich vermute, dass sich die clockrate mal wieder als tueckisch erweist:
dieser Parameter schaltet tatsaechlich einen Clock-Generator auf der
Interface-Karte an und irgendwie wird dann **DIESES** Signal auch **AUF** 
der Karte benutzt - NUR muss zusaetzlich ein (oder mehrere?) Jumper auf
der Karte zusaetzlich passend gesetzt werden, damit auch die richtige
Clock mit dem Applique ausgetauscht wird UND bei RS-449 muss auch noch
die richtige Applique-Type verwendet werden.  
Ein gaengiger Fehler ist es die clockrate zu konfigurieren, obwohl man
sich eigentlich an den extern gegebenen Takt anhaengen will, und dann
interne Verwirrung durch nicht abgestimmten Takt zu haben. Moeglicherweise
ist hier mal der umgekehrte Fall gegeben.

Speziell wenn RS-449 verwendet wird (was ich annehme - da ja gegenueber 
der Post benoetigt) und die Verwendung des Interface in der Konfiguration
nicht ausdruecklich mit Telemation abgesprochen ist, waere es keine
Ueberraschung dass es nicht passt (es ist allerdings auch bei genauer
Spezifikation noch vergleichsweise leicht ein Detail zu uebersehen).

  > Die Firma TELEMATION war bisher leider nicht in der Lage, das Problem
  > zu loesen. Die Kenntnisse im X.25-Bereich sind nach unseren bisherigen
  > Erfahrungen dort wohl eher rudimentaer, 
schade, wo das Unternehmen schon viele Jahre X.25-PADs, -Untervermittler
und andere Geraete im Programm hat...

zur Diagnose waeren natuerlich einige Sachen interessant, wie etwa
- Protokoll-Analysator in die Leitung

- LAPB-Debug-Trace (evt. auch den HDLC) auf der Cisco beobachten,
  und vor allem pruefen, ob und welche Frames der 3745 von der Cisco
  ueberhaupt erkannt werden (wenn keine ==> low level Problem wie von mir
  vermutet oder sogar auf Ebene 0)

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!

  > 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:-)

Viel Erfolg,
  Ruediger Volk


Ruediger Volk
Universitaet Dortmund, Informatik IRB
Postfach 500 500
D-W-4600 Dortmund 50
Germany

E-Mail: rv@Informatik.Uni-Dortmund.DE    (or rv@unido.uucp, rv@unido.bitnet)
Phone:  +49 231 755 4760                 Fax:  +49 231 755 2386