phrock

Ich glaube fast weniger, daß es hilft, aber versuche mal folgendes: Mache den Router mal komplett nackig, will heißen, außer der Konfig: ! isdn switch-type basic-net3 ! interface BRI0 no ip address isdn switch-type basic-net3 ! und dem normalen default-Kram (wr erase + reload) sollte nichts weiter drauf sein. Und dann probiers nochmal mit dem Debugging: debug isdn q921 debug isdn q931 (ggf. ergänzt durch die bereits angesprochenen: "deb isdn l2" und "deb isdn events") und dem hier: isdn test call interface bri0 <Telefonnummer> Statt <Telefonnummer> nimmst du einfach deine eigene Nummer, also die des ISDN-Anschlusses, an dem du gerade mit deinem Router steckst. Die Ausgabe des Debuggings kannst du ja mal posten. Hintergrund des Ganzen: Eventuell hinderliche Konfig-Teile als Fehlerursache auszuschließen. Obwohl auch andere das schon vor mir getan haben, muß ich trotzdem auch nochmal dämlich nachfragen: Das Kabel ist wirklich in Ordnung?

Hallo michael01, hast du das Problem mittlerweile gelöst? Oder hat vielleicht sonst jemand eine Lösung bzw. helfende Hinweise? Wäre echt klasse!

Hallöle, ich bin eher QoS-unerfahren, habe da Thema aber demnächst auch umpfangreicher auf dem Tisch. Was aber auf jeden Fall zu klären ist: Soll bestimmter Verkehr künstlich eingeschränkt werden, egal wie hoch die Auslastung der Leitung insgesamt ist, oder soll bei hohem Datenaufkommen bestimmter Verkehr bevorzugt und anderer benachteiligt werden? Was mir noch aufgefallen ist: Warum markierst du die Pakete mit den DSCP-Werten: ef und af21? Das macht doch eigentlich nur Sinn, wenn dein Gegenüber diese auswertet und für diese Pakete und deren weitere Verarbeitung ein kleines Regelwerk konfiguriert hat!? bis denn dann erstmal

Hallöchen, ich bin ja ein Freund des Debuggen. gibt denn ein: "debug ip nat" oder "debug ip nat detailed" oder eben "debug ip nat ?" usw. etwas her? Ein "term mon" zuvor bei Telnet-Verbindung auf den Router nicht vergessen! Na denn viel Erfolg, der robert

Hallöchen, sehr schön - Problem scheinbar gelöst. Nur für private Zwecke noch der Tipp: Mit "no ip unreachables" auf den Interfaces "sicherst" du das Teil nochmal ein Stückchen besser ab! Ohne diesen Eintrag sendet der Router dieses "administratively prohibited unreachable" an die pingende Gegenstelle: *Mar 1 00:51:21.551: ICMP: dst (192.168.10.174) administratively prohibited unreachable sent to 192.168.10.163 - und somit weiß der Pingende ja dann eigentlich, daß da was ist, was nicht angepingt werden will! Mit dem Eintrag "no ip unreachables" unterläßt er das Senden der unreachable-Meldungen. Somit ist er dann bei einfachen Ping-"Scans" unsichtbar. die Lösung einmal komplett: ! interface ethernet0 ip access-group 101 in no ip unreachables ! interface serial0 ip access-group 101 in no ip unreachables ! access-list 101 deny icmp any any echo access-list 101 permit ip any any !

Hallo, ich glaube du übersiehst da was ganz Entscheidendes: ICMP ist nicht nur Ping!! Du blockst jeden ICMP-Traffic, der über das S0-Interface an den Router gerichtet wird. Sailer hat es schon kurz angesprochen: Schau dir in dem Zusammenhang "echo request" und "echo reply" an! Dies ist nur ein Denkanstoß.

Hallo, probier mal: "ppp authentication chap callin" unterm dialer1. Ansonsten: Wenn ihr Lust habt, dann laßt uns mal ein wenig dran bleiben an dem "Projekt". Ich hatte nämlich auch vor, die Tage mal eine vernünftige AOL-ISDN-Einwahl für nen Bekannten zu kreieren und dabei sinnvolle access-listen und andere Sicherheits-Features etc. zu nutzen. Im Moment bin ich arbeitstechnisch nur arg eingebunden und hab nach den-ganzen-Tag-Konfigs-schreiben Abends keinen rechten Antrieb mehr, da weiter zu machen. Aber ich steig in den nächsten Tagen ein wenig intensiver ein. Bis denn erstmal

Ahja, das ist interessant. Ich weiß es aber auch net! - hätte es nur so vermutet. Es gibt natürlich die Möglichkeit, daß sich unterschiedliche IOS-Versionen unterschiedlich verhalten. Ich glaub, ich hol' mir morgen mal so ne Kiste hier rüber auf die Couch und mach mir selber ne Konfig fertig - erstens reichen mir diese Spekulationen und zweitens wollte ich mir für den Fall, daß mir meine andere Kiste mal abraucht, schon immer ne vernünftige Konfig erstellen. Hat mal jemand den Config-Maker bemüht? Die damit erstellten Konfigs sind zwar ähnlich gut, wie mit MS Frontpage erstellte Web-Seiten ;) , aber ich gehe davon aus, daß der CM diese doch eigentlich recht einfache Kür fehlerfei meistern sollte. Vielleicht werden ja aber auch noch mal die Ergebnisse der Fehlersuche vom Initiator hier gepostet!?!?! ;) Dann bis denn

Hi, nur kurz: versuch mal, vorher das "dialer in-band" unterm Dialer wegzunehmen. -> conf t int di1 no dialer in-band Und dann probier ma' nochmal "dialer pool 1" und "~member...". Ein fröhliches Fest ich wünsch'! Bis denn

Hallo, was Hr_Rossi sagt, ist auf jeden Fall korrekt! + das "ip nat outside" unterm BRI0 weg. Vielleicht einfach mal probieren - denke aber trotzdem an ein IOS-Problem. Gibts denn im Flash ein Crash-Info? Bis denn

Hallo scooby, ! interface FastEthernet0 description LAN 4Competence GmbH Koblenz ip address 192.168.137.253 255.255.255.0 secondary ip address 192.168.153.254 255.255.255.0 no ip redirects no ip proxy-arp ip nat inside <---- speed auto ! Das meinte ich. Auf dem Ethernet 0 sollte meiner Meinung nach kein "ip nat outside" konfiguriert sein, da ja der Dialer als logisches Interface über dem Ethernet0 (-> die "Physik") steht. Der Dialer1 ist die mit der Außenwelt kommunizierende (sozusagen Layer3-)Schnittstelle. Deshalb wird auch die AddressTranslation zwischen dem WAN- (Dialer1) und der LAN-Schnittstelle (FastEthernet0) durchgeführt. Joa, dann wünsch ich uns Allen ein fröhliches Fest im Kreise unserer Lieben! Dann bis denn, phrock

Hallo, probier' die Konfig: version 12.2 no service pad service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname Router ! logging queue-limit 100 no logging console ! ip subnet-zero ip dhcp excluded-address 10.10.10.1 ! ip dhcp pool CLIENT import all network 10.10.10.0 255.255.255.0 default-router 10.10.10.1 dns-server 217.237.149.225 lease 0 2 ! ! ip audit notify log ip audit po max-events 100 vpdn enable ! vpdn-group pppoe request-dialin protocol pppoe ! no ftp-server write-enable isdn switch-type basic-net3 ! ! ! ! ! ! ! interface Ethernet0 ip address 10.10.10.1 255.255.255.0 ip nat inside ip tcp adjust-mss 1452 no cdp enable ! interface BRI0 no ip address encapsulation ppp shutdown dialer pool-member 2 isdn switch-type basic-net3 ! interface ATM0 no ip address no atm ilmi-keepalive pvc 1/32 pppoe-client dial-pool-number 1 dial-on-demand ! dsl operating-mode annexb-ur2 ! interface Dialer1 description T-online Zugang ueber DSL mtu 1492 ip address negotiated ip nat outside encapsulation ppp dialer pool 1 dialer idle-timeout 180 dialer hold-queue 10 dialer-group 1 no cdp enable ppp authentication chap callin ppp chap hostname xxxxxxxxxxxxxxxxxxxxxx#0002@t-online.de ppp chap password 7 xxxxxxxxxxxxxxxxxxxxx ppp ipcp dns request ! ! ip nat inside source list 23 interface Dialer1 overload ip classless ip route 0.0.0.0 0.0.0.0 Dialer1 no ip http server no ip http secure-server ! access-list 23 permit 10.10.10.0 0.0.0.255 access-list 199 permit tcp 10.10.10.0 0.0.0.255 any eq www access-list 199 permit tcp 10.10.10.0 0.0.0.255 any eq pop3 access-list 199 permit tcp 10.10.10.0 0.0.0.255 any eq smtp access-list 199 permit tcp 10.10.10.0 0.0.0.255 any eq 443 access-list 199 permit tcp 10.10.10.0 0.0.0.255 any eq ftp access-list 199 permit tcp 10.10.10.0 0.0.0.255 any eq ftp-data access-list 199 permit tcp 10.10.10.0 0.0.0.255 any eq domain access-list 199 permit udp 10.10.10.0 0.0.0.255 any eq domain access-list 199 permit udp 10.10.10.0 0.0.0.255 any eq 20 access-list 199 permit udp 10.10.10.0 0.0.0.255 any eq 21 access-list 199 permit udp 10.10.10.0 0.0.0.255 any eq 443 access-list 199 permit udp 10.10.10.0 0.0.0.255 any eq 25 access-list 199 permit udp 10.10.10.0 0.0.0.255 any eq 110 access-list 199 permit udp 10.10.10.0 0.0.0.255 any eq 80 access-list 199 deny tcp any any access-list 199 deny udp any any access-list 199 deny ip any any log dialer-list 1 protocol ip list 199 no cdp run ! ! line con 0 exec-timeout 120 0 stopbits 1 line vty 0 4 access-class 23 in exec-timeout 120 0 login local length 0 ! scheduler max-task-time 5000 no rcapi server ! ! ! end Die Verbindung steht für 300 Sek. nach dem letzten interested traffic. Interested und uninterested traffic ist z.B. mit: "debug dialer packet" zu ermitteln. Der interested traffic ist ausgehender Verkehr mit den Zielports 20, 21, 25, 53, 80, 110, 443 ; Zieladresse uninteressant; Quellport uninteressant; Quelladresse im Netz: 10.10.10.0 /24 interessante Abfragen: show caller timeout show dialer show dialer interface dialer1 show caller user show caller user <username> detail -> show user Na probier's mal. Vielleicht auch mal auf Cisco-HP mit den Schlagworten: "Understanding and Troubleshooting Idle Timeouts" "PPPoE Client DDR Idle-Timer" suchen. Bis denn, phrock

Ich denke, das ist nicht notwendig!? In der Konfig ist das FastEthernet0 als NAT-Inside und der Dialer als NAT-Outside gekennzeichnet. Dadurch setzt er bei die Adressen der ACL 1 (192.168.153.0 /24) in die des Dialer1 um - und umgedreht. Was sagt das Debugging?

Hallo, ich hab leider nicht viel Zeit - deshalb nur kurz: zur CHAP-Prozedur: Suche auf der Cisco-Seite mit den Schlagworten: "PPP Authentication ppp chap hostname and ppp authentication" - das solltest du auf jeden Fall fündig werden. zu dem Callin: nimm's "callin" beidseitig raus, dann authentifizieren sie sich gegenseitig - ist doch ok. IP-Negotiation: Ja, das stimmt. Load-threshold: Ja, so ähnlich würde ich's auch denken. Habe den Algortihmus aber noch nie hinterfragt. Zu der Zeit (5 Minuten etc.): wahrscheinlich kann man diese Zeit mit "load-intervall ~" runtersetzen. Statt des "~" kannst du Werte ab 30 aufwärts einsetzen. 30 steht dann für 30 sek. Da bin ich mir aber nicht sicher, ob dieser Eintrag auch mit dem load-threshold "korrespondiert". Aber vielleicht kommen ja noch qualifiziertere Aussagen als die meinigen... Bis denn

Hallo, ich versuch mich mal an einem Erklärungsversuch deiner Fragen: >username user2 password XXXXXX <-- Warum werden hier sowohl Username und Passwort für beide Router angegeben??? Schau dir Unterlagen zur Chap-Prozedur an. -> Der eine authentifiziert sich beim anderen. >ppp authentication chap pap callin <-- ist das Callin an dieser Stelle richtig? Der Router soll schliesslich nur wählen und nicht angewählt werden, ausser beim RAS. "callin" bedeutet, daß nur er sich beim Gegenüber ausweisen muß - dies macht Sinn bei Einwahlen bei einem Provider (z.B. T-Online), da sich T-Online nicht bei mir, dem sich einwählenden, authentisieren muß/soll, sondern ich mich gegenüber T-Online "callin" macht in deinem Fall nicht wirklich Sinn! >ip address negotiated <-- Sollte hier nicht die WAN IP stehen? Damit läßt er sich die IP-Adresse dynamisch zuweisen! >dialer load-threshold 10 either <-- Reicht der Wert 10? Ab wann würde sich der zweite Kanal dazu schalten? Ich glaube, daß dieser Wert in einem Bereich zw. 1 und 255 liegen muß. 0 bedeutet - keine Auslastung, 255 bedeutet Vollauslastung 10 Wäre somit ein rel. niedriger Wert, sodaß er u.U. recht schnell den zweiten Kanal aufbauen würde. Der Zeitraum, den er für diese Berechnung zu Rate nimmt, ist natürlich nich interessant. Mir schwirrt da "load-intervall 30" im Hinterkopf rum - default ist, glaub ich, 5 Minuten. - Also wenn über 5 Minuten im Mittel der Threshold erreicht ist, baut er den zweiten Kanal auf. -> Cisco: Interface load used to determine whether to initiate another call or to drop a link to the destination. This argument represents a utilization percentage; it is a number between 1 and 255, where 255 is 100 percent. >ip route 0.0.0.0 0.0.0.0 Dialer1 <-- Wenn ich mich nicht täusche sollte dies die kriegsentscheidene Route sein, die sämtliche Pakete über die ISDN Leitung zum Router 2 schickt?? Ja, das ist korrekt. >logging buffered 8192 debugging <-- Was hat dieser Eintrag hier zu suchen, was macht er für "böse" Sachen?? Damit stellst du dem Router 8192 bytes Speicher für Logging-Zwecke zur Verfügung. Du kannst dir den Inhalt per "show log" anschauen. Darin werden z.B. solche Dinge wie Dialer-Aufbauten etc. aufgezeichnet. Vielleicht ist's ne kleine Hilfe. Bis denn, Phrock

Hallöchen, mangels Erfahrungen auf dem Gebiet DSL-Einwahl und Tunneling kann ich nur meine spekulativen Überlegungen zu der Konfig kundtun: Zuerst sollte geklärt werden, ob du überhaupt online kommst - hast du ein wenig mit dem debugging rumgespielt? "debug dialer events" "debug dialer packet" "debug dialer ?" "debug ppp authentication" "debug ppp negotiation" ... Vielleicht kannst du ja dabei aufschlußreiche Informationen erhalten. -> Bei einer Telnet-IP-Connection auf den Router das "term mon" nicht vergessen! Zu deiner Konfig: Ich weiß nicht, ob der Eintrag "pppoe-client dial-pool-number 1" unter dem Interface Ethernet0 richtig ist. Sollte der nicht unter dem Dialer stehen? - Wie schon gesagt, ich habe noch keine Erfahrungen im (privaten) DSL-Einwahl-Bereich. Weiterhin vermisse ich unter dem Ethernet0-Interface die Zuordnung zum Dialer-Pool 1. Zum Tunneling sage ich lieber nicht so viel, da dies ein Thema ist, welches ich mir zwar schon immer zu Gemüte führen wollte, aber nie dazu kam... :( Nur eins: Per "ip unnumbered dialer1" unter dem Tunnel10 "borgst" du dir die Adresse des Dialer1, welcher sich seine wiederum dynamisch holt. - Dies ist korrekt so? Naja, vielleicht hilfts ja ein klein wenig!? Poste bitte auf jeden Fall mal deine im Endeffekt funktionierende Konfig, wenn du's denn dann soweit hast. Bis denn dann, phrock

Hallöle, ich denke nicht, daß es an irgendeiner Stelle der Konfig hapert! Ich vermute ein IOS-Bug. Ich rate dir, unbedingt mal ein anderes IOS zu probieren! Bis denn, phrock

Hallöchen, ich hab hier eventuell noch eine Lösung, die weiterhelfen könnte. Meine Lösung, die noch eingehend von mir zu testen sein wird, sieht wie folgend aus: siehe Bild (Anhang) und Text unten (Bitte die "Professionalität" der Zeichnung nicht beachten. Ich hab' kein Visio hier und Zeit und Muße, eine ansehnlichere Darstellung anzufertigen hatte ich auch nicht. Man möge es mir verzeihen.) Einige Einträge könnten eventuell redundant sein. So zum Beispiel die doppelte Angabe des Name-Servers einmal global und noch einmal unter dem DHCP-Server. Was noch zu testen wäre. ;) Na dann viel Spaß damit. Sollte es Fragen geben - einfach melden. ! version 12.2 no service pad service timestamps debug datetime msec localtime service timestamps log datetime msec localtime service password-encryption service compress-config ! hostname c1603R ! logging queue-limit 100 logging buffered 32000 debugging enable secret 5 <removed> ! username c1603R privilege 15 password 7 <removed> username tdata password 7 <removed> ip subnet-zero ip name-server 192.168.10.161 ip dhcp excluded-address 10.199.199.129 ! ip dhcp pool Pool1 import all network 10.199.199.128 255.255.255.252 default-router 10.199.199.129 dns-server 192.168.10.161 lease 0 2 ! isdn switch-type basic-net3 ! ! ! interface Loopback0 ip address 10.101.101.3 255.255.255.255 ! interface Ethernet0 ip address 192.168.10.174 255.255.255.240 ip mtu 1492 ip nat outside no ip route-cache no cdp enable ! interface BRI0 no ip address encapsulation ppp dialer pool-member 1 isdn switch-type basic-net3 isdn answer1 123456789 no fair-queue no cdp enable ppp multilink ! interface Dialer1 ip address 10.199.199.129 255.255.255.252 ip nat inside encapsulation ppp dialer pool 1 dialer remote-name tdata dialer-group 1 peer default ip address dhcp no cdp enable ppp multilink ! ip nat inside source list 23 interface Ethernet0 overload ip classless ip route 0.0.0.0 0.0.0.0 192.168.10.161 ip route 10.101.125.240 255.255.255.248 10.199.199.130 no ip http server ! ! access-list 23 permit 10.101.101.3 access-list 23 permit 10.101.125.240 0.0.0.3 access-list 23 permit 10.199.199.128 0.0.0.2 access-list 100 permit ip any any dialer-list 1 protocol ip list 100 no cdp run ! line con 0 exec-timeout 0 0 logging synchronous login local line vty 0 4 session-timeout 20 exec-timeout 20 0 logging synchronous login local ! sntp server 130.149.17.21 version 3 end !

Hallöchen, nur als Tip im nachhinein: vielleicht solltest du temporär deine(n) gefundenen Fehler rückgängig machen und ein wenig mit den Debuggen fortzusetzen. -> ich weiß nicht, ob's was bringt, aber du könntest noch folgende debugging-Möglichkeiten ausschöpfen: "debug dialer events" "debug dialer packet" "debug dialer ?" (- ich kann nicht eindeutig sagen, ob es noch mehr Möglichkeiten gibt und ob die vorher Genannten etwas Aufschlussreiches bringen) Vielleicht ist sind die Erkenntnisse ja interessant für spätere Zwecke. (arbeitstechnisch, privat...) - und vielleicht hätte dich dies früher auf die Lösung des Fehlers gebracht - man lernt nie aus! :) bis denn, rob

Hallo xyCruiseryx, die vier Zeilen: *Mar 1 00:03:29.979: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down *Mar 1 00:03:29.995: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down [...] *Mar 1 00:03:30.979: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to down *Mar 1 00:03:30.995: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, changed state to down sagen dir, daß die beiden B-Kanäle down sind. Ich denke, das ist in deinem Sinne. ;) Über den ISDN-Staus kannst du dich mit folgendem Befehl informieren: "show isdn status" Da kannst du dann den Status der Layer 1, 2 und 3 erfahren. Weiterhin kannst du dann auch mal mit dem Debugging rumspielen: "term mon" (falls Connection zum Router per telnet) "debug isdn q921" (Layer 2 - z.B. TEI-Zuweisung) "debug isdn q931" (Layer 3 - z.B. Verbindungsaufbau) "debug isdn ?" (für weiteres Zeugs) Hilfreich? Viel Spaß damit.

Nachtrag: bitte das CDP ausschalten! conf t no cdp run int di1 no cdp ena int bri0 no cdp ena end

Hallo zimbo123, Problem schon gelöst? Falls nicht: Du hast in der Config 2x "ip nat outside"! interface Ethernet0 description T-DSL ip nat outside ! interface Dialer1 ip nat outside Ich bilde mir ein, mich zu erinnern, bei einem Cisco-ISDN-Workshop als Info mal mitgenommen zu haben, daß bei einer "ISDN-Connection" zwei Mal "encap ppp" (auf BRI UND auf Dialer) auch nicht funktioniert. Ich könnte mir vorstellen, daß das der Fehler ist! Auf dem Eth0 sollte kein "ip nat outside" konfiguriert sein. Bitte einfach mal probieren und Ergebnis hier posten. Viel Erfolg!

Hallo firescout, also ich bin jetzt nicht der Cisco-Guru, aber mich wundert fast, daß du überhaupt online kommst. In der Config ist steht folgendes: dialer-list 1 protocol ip list 1 Dieser Eintrag "korrespondiert" mit dem Eintrag dialer-group 1 unter dem Dialer1 und bezieht sich auf auf eine access-list 1 (~ list 1). Mit dieser dialer-list wird angegeben, welches der "interested traffic" ist, also der Verkehr, der den Dialer aktivieren und aufrecht erhalten soll/darf. Dadurch, daß du keine access-list 1 angegen hast, wundert es mich, daß überhaupt eine Verbindung zustande kommt. Aber ich muß zugeben, ich habe diesen Fall noch nie ausprobiert. Der interested traffic muß also eingeschränkt werden! Du mußt dir also überlegen, welcher Verkehr den Dialer aufbauen UND aufrecht erhalten darf! Beispiel: Surf-Verkehr (Port 80, 443) , dein ICQ (5190) und Mail (Port 110). Tja, und daraus ne access-list erstellt dürfte dann in etwa so ausschauen: access-list 199 permit tcp any any eq 80 access-list 199 permit tcp any any eq 110 access-list 199 permit tcp any any eq 443 access-list 199 permit tcp any any eq 5190 access-list 199 deny tcp any any log Du mußt natürlich dann den Eintrag: dialer-list 1 protocol ip list 1 auf dialer-list 1 protocol ip list 199 abändern: folgende zwei Zeilen im global configuration mode (conf t) reinkopieren: no dialer-list 1 protocol ip list 1 dialer-list 1 protocol ip list 199 Weiterhin habe ich grad überlegt, ob es zusätzlich noch sinnvoll wäre, den idle-timeout nur auf den ausgehenden Verkehr triggern zu lassen: "dialer idle-timeout 30 outbound" statt "dialer idle-timeout 30" unterm Dialer1. -> Vielleicht einfach zusätzlich probieren. Eine kurze Erklärung: Ich habe gerade keinen Cisco vor mir. Deshalb ist alles hier gesagte recht theoretisch! -> Bitte einfach ausprobieren! Das "log" am Ende des letzten Eintrags der acces-list gibt den Traffic aus, der den Dialer NICHT aufbauen oder aufrecht erhalten darf! Vielleicht kannst du damit ja herausfinden, welcher traffic noch interessant für dich ist. Rumspielen solltest du vielleicht auch mit dem Debugging: debug dialer packet und debug dialer events beides im enable-mode (sog. privileged exec mode). Solltest du dich per telnet auf den Router connected haben, dann vorher noch "term mon" ausführen! Wichtig auf jeden Fall: Die access-list an die dialer-list gebunden schränkt KEINEN Verkehr ein! Sie dient lediglich der Definition, welcher Verkehr den Dialer aufbauen und aufrecht erhalten darf oder soll!!! Stöber vielleicht noch ein wenig auf den Cisco-Seiten rum. Mit ein wenig Muße und Suchgeschick kannst du da alle Infos finden. Nun gut, ich hoffe, es hat geholfen und daß meine Tipps korrekt waren. ;o) Viel Erfolg und schreib mal bitte, ob es geklappt hat. Grüße aus Potsdam