Lizenzen über Router holen / CATIA V5 Infrastruktur
ProcyonTheDragon 24. Okt. 2008, 14:54

Hallo,

ich habe hier ein kleines lokales Netzwerk mit einem Dateiserver und drei bis 10 Catia-Workstations. Da dieses Netzwerk keine direkte Verbindung zu dem Lizenzserver hat, mussten wir bisher über ein VPN die Verbindung zum Lizenzserver herstellen. Da wir dann aber nicht mehr auf den Dateiserver zugreifen konnten, möchte ich das jetzt so ändern, dass sich der Dateiserver als Router eingesetzt wird und auch gleichzeitig die VPN-Verbindung aufbaut.

Das VPN funktioniert perfekt, der Lizenzserver ist anpingbar (vom Server und von den Workstations aus), aber weder das Basic License Tool noch Catia finden die Lizenzen. Wenn ich von der Workstation aus eine VPN-Verbindung aufbaue (über den Dateiserver=Router) funktioniert alles perfekt.

Am Router wird im Moment auch *nichts* geblockt, es ist keine Firewall installiert (alle iptables-Policen stehen auf accept...).

Die Firewall sagt mir nur, dass es regen Verkehr über UDP gibt zwischen dem Lizenzserver und der Workstation (Quellport Workstation 1363, Zielport Lizenzserver 1515 und halt wieder zurück).

Gibt es da einen goldenen Trick, den man beachten muss? Ich habe nämlich keine Ahnung, warum das ganze nicht funktioniert ...

Bei Bedarf kann ich noch mehr Infos über den Router und die Pakete, die da durchgehen, bereitstellen.

Danke schonmal,
Procyon

RSchulz 27. Okt. 2008, 08:50

Hallo,
ist vielleicht auf den Workstation selbst eine Firewall aktiv, welche den Port 1515 für den Lum-Server blockt?

cwillmann 27. Okt. 2008, 09:52

Gab/gibt es nicht die Ports 1515 und 1516? Bin mir nicht mehr sicher, war auch ein Unterschied bei TCP und UDP.

RSchulz 27. Okt. 2008, 09:57

Zitat:
Original erstellt von cwillmann:
Gab/gibt es nicht die Ports 1515 und 1516? Bin mir nicht mehr sicher, war auch ein Unterschied bei TCP und UDP.


Über TCP/IP wird normaler Weise eine Verbindung aufgebaut und unter UDP wird lediglich etwas losgeschickt, ohne dass über eine Verbindung geprüft wird, ob es angekommen ist. UDP ist daher ein relativ riskantes Protokoll, da nie sichergestellt ist/werden kann, dass die losgeschickten Information angekommen sind bzw. verabeitet wurden. Zu den Ports kann ich nichts genaues sagen, aber im Normalfall ist es nie nur ein Port, sondern eine Range an Ports, die von einem Programm verwendet werden.

nullplan 29. Okt. 2008, 21:49

So ein Problem mit LUM hatten wir auch. Wir haben daraufhin den Client/Server Netzwerkverkehr mit
einem Sniffer (Wireshark) mitgeschnitten und die UDP-Pakete analysiert. Bei uns scheiterte LUM
an blockierten Ports (Firmensecurity...). IBM hat übrigens für dieses Szenario den IPAuth Parameter in der
i4ls.ini des Servers vorgesehen (z.B. 9900). Also mal die Netzwerker gucken lassen was schief läuft.

Gruß
Thomas

ProcyonTheDragon 29. Okt. 2008, 22:28

Tach erstmal

Vielen Dank nullplan,

das heißt also es könnte doch gehen? Ich hab zwar keine Netzwerker, die mir das machen könnten (werd ich wohl selber probieren müssen), aber wenn ich Zeit und Lust habe (ich habe wahrscheinlich beides nicht) werde ich mich mal dahinterklemmen.

Wie habt ihr das Problem denn gelöst? Andere Servereinstellungen (-> anderer Port?) oder Änderungen in der Firewall?

Und was bewirkt diese IPAuth-Direktive?

Danke schonmal,

Procyon

nullplan 30. Okt. 2008, 12:22

Das mit dem IPAuth wurde hier schon öfter erwähnt. Benutze mal die Suchfunktion im LUM 4.6.8 Handbuch. Dort wirst Du unter Firewalling mit LUM fündig. Der Parameter IPAuth=9900 wird in die i4ls.ini des Servers eingetragen und dann kommunizieren Client und Server nur noch über 1515 und 9900 (ansonsten nämlich über 1515 und random Port#). Für diese dann festen Port# kann man die Firewall/Router dann so konfigurieren, daß diese dann alle UPD-Pakete durchläßt.

In unserem Fall hat die Firmensecurity aber njet gesagt :-/ Wir können das Problem nur mit Hilfe von IBM lösen. Die müßten uns eine Gateway-Lösung zur Verfügung stellen. Das steht aber noch in den Sternen. Solange müssen wir mit einem Haufen Lizenzservern leben...

Gruß
Thomas

Sven Schloegl 17. Nov. 2008, 15:13

Hallo,
wir haben fast das gleiche Problem. Nur funktioniert es mal und dann wieder nicht. Unser LUM-Server steht in einem 192er Netz. Ein Teil der CATIA-Maschinen(V4/AIX-V5/XP64)im selben Netz und der andere Teil in einem 150er Netz. Beide Netze sind über ein Gateway verbunden. Die Broadcasts werden geblockt(macht ja auch Sinn). Aus dem 192er Netz funktioniert alles wunderbar. Aus dem 150er Netz gibt es hin und wieder extreme Problem eine Lizenz zu bekommen. Es wird einfach kein Lizenzserver gefunden, obwohl dieser anpingbar ist.
Beim Durchsuchen der LUM-DOKU bin ich auf die glb_site.txt gestoßen. Die soll erforderlich sein, wenn der Server in einem anderen Netz steht. Leider ist der Speicherort für diese Datei nur für UNIX angegeben. Unter Windows gibt es ja mehrere Möglichkeiten. Hat jemand einen Tipp? Ich probiere jetzt einfach mal aus. Vielleicht hilft Euch das auch weiter?

Gruß Sven


Procyon 17. Nov. 2008, 18:59

Tach erstmal

das hilft mir aber nicht unbedingt weiter ...

Bei mir sind die Lizenzserver mit dem Domainnamen im LUM eingetragen, d.h. der LUM muss gar nicht broadcasten.

Das Problem ist, dass die Lizenz nur erteilt wird, wenn Pakete von zufälligen Ports des Servers den Clienten erreichen, ohne dass vorher eine Verbindung vom Client aus an diesen Port aufgebaut wurde. Da bei uns dazwischen ein NAT-Router sitzt, können die Pakete gar nicht ankommen, denn im NAT steht ja nicht an welchen PC sie weitergeleitet werden.

Wenn euer Gateway nichts blockt außer Broadcasts und auch kein NAT betreibt, müsstet ihr das Problem doch lösen können indem ihr die IPs/Hostnamen der Lizenzserver in der LUM-Config an den Client-PCs eintragt ...

Tschau
Procyon

Sven Schloegl 18. Nov. 2008, 12:21

Das dachte ich auch. Aber leider funktioniert das nicht. So wie ich die Doku vom LUM verstehe, ist es egal  was in der i4ls.ini steht. Erst mit der "glb_site.txt" versucht er direkt mit dem Server zu kommunizieren. Zumindest ist es unter Windows so. Die AIX-Maschinen bekommen ihre Lizenzen problemlos.

Gruß Sven

Procyon 18. Nov. 2008, 15:44

Tach erstmal

hmm ok. Und wenn du was rausgefunden hast, benachrichtigst du uns dann? Ich hab im Moment nicht die Zeit da noch ewig dran rumzubasteln...

Tschau
Procyon

ijne 24. Nov. 2008, 11:20

Hallo !
Die Einträge in der i4ls.ini sind relevant.
Die glb_site.txt wird bei uns überhaupt nicht unter
windows eingetragen. Muss auch nicht.
Im Zweifelsfall über das config-tool den Server eintragen,
dieses editiert ebenfalls die i4ls.ini.
Dann funktioniert die Lizenzvergabe auch netzübergreifend.

Gruß Jens


ProcyonTheDragon 27. Nov. 2008, 18:11

Tach erstmal

ja, die Lizenzserver können eingetragen werden, aber das ganze funktioniert nicht wenn man hinter einem NAT sitzt. Das ist das Problem, zumindest bei mir.

ijne 01. Dez. 2008, 15:19

Hallo !
Ja, NAT muss natürlich auch geroutet sein.
Wir haben das Spiel auch mal gespielt, als
wir unsere Mitarbeiter extern mit einer Lizenz
versorgen mussten. Damals konnte man mit V4 unter
Unix nur den Weg gehen. D.h. auf dem Client haben wir die
NAT-Adresse des Servers eingetragen. Für den Server muss das
NATTING explizit editiert werden.

Gruss Jens