12
Cisco Pix hinter Cisco Router
Hi,
warum kann man die Pix am outside Interface nicht an einen 1700er Router hängen?
Habe diese Beispielkonfiguration in meinem Lab verwendet, aber habe wie gesagt das Problem,
dass ich die Verbindung zwischen dem 1700 und der Pix nicht zustande bekomme.
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configur ...
Der 1700er hat ein FastEthernet interface das ich entsprechend konfiguriert habe. Bei der Pix
das outside interface ebenso. Jedoch bekomme ich keine Statusmeldung bei der Anzeige an
der Pix. Das interface bleibt down. Wenn ich jedoch die Pix mit einem Switch verbinde, zeigt mir das outside interface
sofort connection an.
Muss das nicht auch mit dem 1700er funktionieren? Habe auch schon Patch/Crossover Kabel ausgetauscht, da dran
liegt es nicht.
Geht mir nicht um die config sondern nur um die "rein physische" Verbindung.
Jemand eine Idee?
Gruß
Mireux
warum kann man die Pix am outside Interface nicht an einen 1700er Router hängen?
Habe diese Beispielkonfiguration in meinem Lab verwendet, aber habe wie gesagt das Problem,
dass ich die Verbindung zwischen dem 1700 und der Pix nicht zustande bekomme.
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configur ...
Der 1700er hat ein FastEthernet interface das ich entsprechend konfiguriert habe. Bei der Pix
das outside interface ebenso. Jedoch bekomme ich keine Statusmeldung bei der Anzeige an
der Pix. Das interface bleibt down. Wenn ich jedoch die Pix mit einem Switch verbinde, zeigt mir das outside interface
sofort connection an.
Muss das nicht auch mit dem 1700er funktionieren? Habe auch schon Patch/Crossover Kabel ausgetauscht, da dran
liegt es nicht.
Geht mir nicht um die config sondern nur um die "rein physische" Verbindung.
Jemand eine Idee?
Gruß
Mireux
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 110755
Url: https://administrator.de/contentid/110755
Printed on: April 19, 2024 at 19:04 o'clock
12 Comments
Latest comment
Eventuell ist ja der Port am 1700 auf shutdown gesetzt.
conf t
interface FastEthernet0/1
no shutdown
conf t
interface FastEthernet0/1
no shutdown
nein, kein shutdown, wie gesagt funktioniert wunderbar am catalyst.
Router (FastEthernet) --> Catalyst (Ok)
Router (FastEthernet) --> Pix (outside) (keine Verbindung)
Pix (outside) --> Catalyst (Ok)
Nur vom Router zur Pix will das outside interface der Pix keine Verbindung
herstellen.
Router (FastEthernet) --> Catalyst (Ok)
Router (FastEthernet) --> Pix (outside) (keine Verbindung)
Pix (outside) --> Catalyst (Ok)
Nur vom Router zur Pix will das outside interface der Pix keine Verbindung
herstellen.
Was meinst du genau mit keine Verbindung ???
Das ist eine Wischi Waschi Aussage ohne tiefere Bedeutung
Was denn nun ???
Ein Konfig Auszug hätte uns hier sehr weitergeholfen, aber so weit hast du vermutlich nicht gedacht...
Wenn der physische Link auf down bleibt hast du vermutlich kein Crossover Kabel verwendet.
Wenn der Ping nicht geht sind beide Interfaces vermutlich im falschen IP Netzwerk und/oder du hast vergessen auf dem PIX Interface eine ACL zu konfigurieren die ICMP Traffic bzw. inbound Traffic erlaubt ???
Vermutlich ists schlicht und einfach nur das Crossover Kabel... oder die Konfig der Interfaces auf statische Duplex oder Speed Werte ?!
Diese Konstellation mit PIX und 1700er Router ist absoluter Standard und natürlich funktioniert so ein Szenario wunderbar !!
Das ist eine Wischi Waschi Aussage ohne tiefere Bedeutung
- Keinen physischen Link auf dem Ethernet ??? Interface bleibt auf Down..
- Ping funktioniert nicht ?
- usw.
Was denn nun ???
Ein Konfig Auszug hätte uns hier sehr weitergeholfen, aber so weit hast du vermutlich nicht gedacht...
Wenn der physische Link auf down bleibt hast du vermutlich kein Crossover Kabel verwendet.
Wenn der Ping nicht geht sind beide Interfaces vermutlich im falschen IP Netzwerk und/oder du hast vergessen auf dem PIX Interface eine ACL zu konfigurieren die ICMP Traffic bzw. inbound Traffic erlaubt ???
Vermutlich ists schlicht und einfach nur das Crossover Kabel... oder die Konfig der Interfaces auf statische Duplex oder Speed Werte ?!
Diese Konstellation mit PIX und 1700er Router ist absoluter Standard und natürlich funktioniert so ein Szenario wunderbar !!
Wischi Waschi ist die Art wie du hier mit mir sprichst. Was soll denn dieser Ton? Wenn du lesen würdest, hättest du gesehen was ich oben geschrieben habe. Gleich frech werden ist leider die falsche Lösung.
Ich habe bereits oben geschrieben dass die config egal ist weil ich alles konfiguriert habe. IP´s sowie das Subnetz sind korrekt gesetzt.
Ein Crossover Kabel habe ich verwendet, dieses war vorher zwischen Modem und 1700er, dieses Kabel funktioniert. Ich habe es zum Testen in den FastEthernet Port des 1700er und in den outside Port der Pix gesteckt. Kein physischer Link! Dann habe ich vom outside Interface der Pix ein Patchkabel in den Catalyst gesteckt. Verbindung!
Ein normales Patchkabel vom 1700er in die Pix (outside) funktioniert nicht. (muss ja Crossover sein!)
http://www.cisco.com/en/US/docs/security/pix/pix62/quick/guide/501quick ... habe ich gelesen, sowie das oben gepostete Fallbeispiel von Cisco.
ein show int zeigt:
Pix# show int
interface ethernet0 "outside" is up, line protocol is down
Hat es evtl. was mit dem line protocol zu tun?
Und bitte in einem normalen Ton, spreche hier auch normal ;)
Gruß
Mireux
Ich habe bereits oben geschrieben dass die config egal ist weil ich alles konfiguriert habe. IP´s sowie das Subnetz sind korrekt gesetzt.
Ein Crossover Kabel habe ich verwendet, dieses war vorher zwischen Modem und 1700er, dieses Kabel funktioniert. Ich habe es zum Testen in den FastEthernet Port des 1700er und in den outside Port der Pix gesteckt. Kein physischer Link! Dann habe ich vom outside Interface der Pix ein Patchkabel in den Catalyst gesteckt. Verbindung!
Ein normales Patchkabel vom 1700er in die Pix (outside) funktioniert nicht. (muss ja Crossover sein!)
http://www.cisco.com/en/US/docs/security/pix/pix62/quick/guide/501quick ... habe ich gelesen, sowie das oben gepostete Fallbeispiel von Cisco.
ein show int zeigt:
Pix# show int
interface ethernet0 "outside" is up, line protocol is down
Hat es evtl. was mit dem line protocol zu tun?
Und bitte in einem normalen Ton, spreche hier auch normal ;)
Gruß
Mireux
Hi,
Zur Zeit spielen alle mit Ciscorouter, weil jeder meint: "Achja, machen wir kurz vor dem Feierabend." Man sollte schon mal eine Schulung o.ä. besucht haben, denn dann weiß man auch welche DEBUG - Möglichkeiten es gibt und welche Statusübersichten - damit lassen sich die Fehler eingrenzen. Wilde Ratespiele führen selten zum Ziel...
Grüße,
Dani
Wischi Waschi ist die Art wie du hier mit mir sprichst. Was soll denn dieser Ton? Wenn du lesen würdest, hättest du gesehen was ich oben geschrieben habe. Gleich frech werden
ist leider die falsche Lösung.
ich kann aqui verstehen....wie soll man da bitte das Problem erkennen. Was fehlen ist einfach z.B. eine Ausgabe von "sh ip int brief" auf dem Cisco Router. Somit sieht man schon mal ob es einen Link überhaupt gibt - Fehler bei der Hardware. Auszüge von der PIX bzw. Routerkonfiguration über das entsprechende Interface (Speed und Duplexeinstellungen, Protokolle, etc...) - alles ist wichtig!ist leider die falsche Lösung.
Zur Zeit spielen alle mit Ciscorouter, weil jeder meint: "Achja, machen wir kurz vor dem Feierabend." Man sollte schon mal eine Schulung o.ä. besucht haben, denn dann weiß man auch welche DEBUG - Möglichkeiten es gibt und welche Statusübersichten - damit lassen sich die Fehler eingrenzen. Wilde Ratespiele führen selten zum Ziel...
Grüße,
Dani
Hi,
Zur Zeit spielen alle mit Ciscorouter, weil jeder meint: "Achja,
machen wir kurz vor dem Feierabend." Man sollte schon mal eine
Schulung o.ä. besucht haben, denn dann weiß man auch welche
DEBUG - Möglichkeiten es gibt und welche Statusübersichten -
damit lassen sich die Fehler eingrenzen. Wilde Ratespiele führen
selten zum Ziel...
Grüße,
Dani
machen wir kurz vor dem Feierabend." Man sollte schon mal eine
Schulung o.ä. besucht haben, denn dann weiß man auch welche
DEBUG - Möglichkeiten es gibt und welche Statusübersichten -
damit lassen sich die Fehler eingrenzen. Wilde Ratespiele führen
selten zum Ziel...
Grüße,
Dani
Das ist ja das Thema "Lab" ;) Durch praktische Erfahrung kann ich in der Schulung mehr machen, wenn ich nur die Sachen von der Schulung auswendig lerne bringt das nicht wirklich viel. Lieber aktiv im Lab, dann lernt man hardwarenah und nicht nur Packet Tracer und andere Spielereien. Aber das ist ein anderes Thema.
Hier die Auszüge:
PIX
show int:
interface ethernet0 "outside" is up, line protocol is down
Hardware is i82559 ethernet, address is XXXXXXXXXXX
IP address 192.168.1.2, subnet mask 255.255.255.252
MTU 1500 bytes, BW 10000 Kbit half duplex
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
1 packets output, 60 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collisions, 0 deferred
1 lost carrier, 0 no carrier
input queue (curr/max blocks): hardware (128/128) software (0/0)
output queue (curr/max blocks): hardware (0/1) software (0/1)
interface ethernet1 "inside" is up, line protocol is up
Hardware is i82559 ethernet, address is XXXXXXXX
IP address 192.168.2.1, subnet mask 255.255.255.240
MTU 1500 bytes, BW 100000 Kbit full duplex
39 packets input, 24720 bytes, 0 no buffer
Received 40 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
1 packets output, 60 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collisions, 0 deferred
0 lost carrier, 0 no carrier
input queue (curr/max blocks): hardware (128/128) software (0/1)
output queue (curr/max blocks): hardware (0/1) software (0/1)
1700er - show int:
FastEthernet0 is up, line protocol is down
Hardware is PQUICC_FEC, address is XXXXXXXX
Internet address is 192.168.1.1/30
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 219/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Unknown duplex, Unknown Speed, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog
0 input packets with dribble condition detected
17 packets output, 1020 bytes, 0 underruns
17 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collision, 0 deferred
17 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped outshow ip int brief
Interface IP-Address OK? Method Status Protocol
BRI0 unassigned YES NVRAM administratively down down
BRI0:1 unassigned YES unset administratively down down
BRI0:2 unassigned YES unset administratively down down
Dialer1 XXXXXXXXXX YES IPCP up up
Ethernet0 unassigned YES NVRAM up up
FastEthernet0 192.168.1.1 YES NVRAM up down
Virtual-Access1 unassigned YES unset up up
Virtual-Access2 unassigned YES unset down down
Virtual-Access3 unassigned YES unset up up
Virtual-Template1 unassigned YES NVRAM down dow
Warum wird kein Link Status an der Pix (outside0) angezeigt? Ich benutze das Crossover Kabel das bei der Pix dabei war.
Ich finde es gut sich damit zu beschäftigen wenns einen interessiert - Netzwerkkenntnisse zu haben ist im Adminberuf stets von Vorteil.
Und der Weg ins Lab und Aufbau einer Testumgebung und Troubleshooting spricht für dich.
Der Port an sich ist "up", bzw. "bereit", doch das Lineprotokoll ist down bzw. passt nicht zum verbundenen Partner.
Unterschiedliche Encapsulation Typen?
Eventuell ist der Port am 1700 auch einfach kabutt. Kommt vor!
Jedenfalls - bevor ich irgendwas weitermachen würde würd ich mir erstmal das mögl. aktuellste IOS und PIX OS runterladen und draufklatschen.
Zum einen ne gute Übung mti TFTP usw, zum anderen schliesst man dann so manche "Merkwürdigkeit" aus aufgrund zu alter OS Version.
Kannst du mal die config von beiden geräten posten?
Und der Weg ins Lab und Aufbau einer Testumgebung und Troubleshooting spricht für dich.
Der Port an sich ist "up", bzw. "bereit", doch das Lineprotokoll ist down bzw. passt nicht zum verbundenen Partner.
Unterschiedliche Encapsulation Typen?
Eventuell ist der Port am 1700 auch einfach kabutt. Kommt vor!
Jedenfalls - bevor ich irgendwas weitermachen würde würd ich mir erstmal das mögl. aktuellste IOS und PIX OS runterladen und draufklatschen.
Zum einen ne gute Übung mti TFTP usw, zum anderen schliesst man dann so manche "Merkwürdigkeit" aus aufgrund zu alter OS Version.
Kannst du mal die config von beiden geräten posten?
Zitat von @spacyfreak:
Ich finde es gut sich damit zu beschäftigen wenns einen
interessiert - Netzwerkkenntnisse zu haben ist im Adminberuf stets von
Vorteil.
Und der Weg ins Lab und Aufbau einer Testumgebung und Troubleshooting
spricht für dich.
Der Port an sich ist "up", bzw. "bereit", doch
das Lineprotokoll ist down bzw. passt nicht zum verbundenen Partner.
Unterschiedliche Encapsulation Typen?
Eventuell ist der Port am 1700 auch einfach kabutt. Kommt vor!
Jedenfalls - bevor ich irgendwas weitermachen würde würd
ich mir erstmal das mögl. aktuellste IOS und PIX OS runterladen
und draufklatschen.
Zum einen ne gute Übung mti TFTP usw, zum anderen schliesst man
dann so manche "Merkwürdigkeit" aus aufgrund zu alter
OS Version.
Kannst du mal die config von beiden geräten posten?
Ich finde es gut sich damit zu beschäftigen wenns einen
interessiert - Netzwerkkenntnisse zu haben ist im Adminberuf stets von
Vorteil.
Und der Weg ins Lab und Aufbau einer Testumgebung und Troubleshooting
spricht für dich.
Der Port an sich ist "up", bzw. "bereit", doch
das Lineprotokoll ist down bzw. passt nicht zum verbundenen Partner.
Unterschiedliche Encapsulation Typen?
Eventuell ist der Port am 1700 auch einfach kabutt. Kommt vor!
Jedenfalls - bevor ich irgendwas weitermachen würde würd
ich mir erstmal das mögl. aktuellste IOS und PIX OS runterladen
und draufklatschen.
Zum einen ne gute Übung mti TFTP usw, zum anderen schliesst man
dann so manche "Merkwürdigkeit" aus aufgrund zu alter
OS Version.
Kannst du mal die config von beiden geräten posten?
Danke dass du mir hier zustimmst. Lieber mehr als zu wenig wissen.
Hier die config´s:
Router config:
Current configuration : 1830 bytes
!
! Last configuration change at 00:43:17 UTC Fri Mar 1 2002
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
enable secret 5 $1$CiW7$ohwD/IZK2LFdshfDzbumy0
!
no aaa new-model
ip subnet-zero
!
!
!
!
ip name-server 217.237.148.70
ip name-server 217.237.149.142
ip cef
ip audit notify log
ip audit po max-events 100
ip ssh break-string
vpdn enable
!
no ftp-server write-enable
no scripting tcl init
no scripting tcl encdir
!
!
!
!
no crypto isakmp enable
!
!
!
bba-group pppoe global
virtual-template 1
!
!
interface BRI0
no ip address
shutdown
!
interface Ethernet0
no ip address
half-duplex
pppoe enable
pppoe-client dial-pool-number 1
!
interface FastEthernet0
ip address 10.10.10.1 255.255.255.0
ip nat inside
speed 10
half-duplex
!
interface Virtual-Template1
mtu 1492
no ip address
peer default ip address dhcp-pool PPPoE
ppp authentication pap
!
interface Dialer1
ip address negotiated
ip mtu 1492
ip nat outside
encapsulation ppp
ip tcp adjust-mss 1452
no ip mroute-cache
dialer pool 1
dialer-group 1
ppp authentication chap callin
ppp chap hostname xxxxxxxxxxxxxxxx
ppp chap password xxxxxxxxxxxxxxxx
ppp ipcp dns request
!
ip nat inside source list 101 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
!
ip dns server
!
!
access-list 101 permit ip host 10.10.10.2 any
access-list 101 permit ip host 10.10.10.7 any
dialer-list 1 protocol ip permit
!
!
control-plane
!
line con 0
password xxxxxxxxxxxxxx
login
line aux 0
password xxxxxxxxxxxxxx
login
line vty 0 4
password xxxxxxxxxxxxx
login
!
no scheduler allocate
!
end
PIX config:
PIX Version 6.3(5)
interface ethernet0 10baset
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password Z.Qty1IMTjiVaDx/ encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
hostname Pix
domain-name ciscopix.com
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
names
pager lines 24
mtu outside 1500
mtu inside 1500
ip address outside 10.10.10.2 255.255.255.0
ip address inside 10.10.1.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
pdm location 10.10.10.0 255.255.255.0 inside
pdm logging informational 100
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
timeout xlate 0:05:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout sip-disconnect 0:02:00 sip-invite 0:03:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
telnet timeout 5
ssh timeout 5
console timeout 0
dhcpd auto_config outside
terminal width 80
Cryptochecksum:14b998741a6cdbd5b9b9dfe0e79d3375
: endSchau mal die configs an, vielleicht liegt das an den Encapsulations-Typen.
danke spacyfreak
Gruß
Mireux
Hmmm. sieht für mich im Schnelldurchlauf alles schickifricki aus..
Ne Config aus wie aus dem Lehrbuch quasi.
Vielleicht mal probieren auf dem router die duplex einstellungen zu ändern, auf auto
conf t
interface FastEthernet0
speed auto
duplex auto
no shut
end
show interface FastEthernet0
Anderes Kabel hast du bestimmt auch schon brobiert..
Ne Config aus wie aus dem Lehrbuch quasi.
Vielleicht mal probieren auf dem router die duplex einstellungen zu ändern, auf auto
conf t
interface FastEthernet0
speed auto
duplex auto
no shut
end
show interface FastEthernet0
Anderes Kabel hast du bestimmt auch schon brobiert..
Ich habe leider nur ein Crossover Kabel. Jedoch habe ich das an zwei 2600er Router angeschlossen, habe mich auf diesen Routern zwar nicht eingeloggt, jedoch haben beide alle 5 sek geblinkt, denke mal dass dann das Kabel nicht defekt ist. War wie gesagt auch bei der Pix dabei als ich mir diese gekauft habe. Orange für Crossover und Gelb für normales Patchkabel.
Hatte ich vorher auf auto, dann geändert und 1:1 der Pix angepasst. 10baset, half-duplex. No shutdown auch eingestellt.
Wenn man die Pix konfiguriert und das interface definiert ist standardmäßig no shutdown aktiviert. Bei Auslieferungszustand sind jedoch die interfaces standardmäßig auf shutdown laut Pix Handbuch.
Das FastEthernet interface des 1700er ist auch auf no shutdown.
Ich bin echt am verzweifeln, verstehe das nicht wieso da nix über die Leitung kommt (an physischer Kommunikation)
Habe das orange Kabel der Pix mal zwischen zwei Catalyst gehängt. Kein Signal der LED´s. Ich glaube wirklich dass das Kabel defekt ist. Mehr kann es ja nicht sein. Konfiguration ist einwandfrei.
Oder liege ich falsch?
Nach einem Test des Kabels bin ich mir jetzt 100%ig sicher dass dieses defekt ist.
Auch nach einem Versuch zwischen zwei Switches habe ich keine Connection bekommen.
Trotzdem danke für die Hilfe.
Viele Grüße
Mireux
Hatte ich vorher auf auto, dann geändert und 1:1 der Pix angepasst. 10baset, half-duplex. No shutdown auch eingestellt.
Wenn man die Pix konfiguriert und das interface definiert ist standardmäßig no shutdown aktiviert. Bei Auslieferungszustand sind jedoch die interfaces standardmäßig auf shutdown laut Pix Handbuch.
Das FastEthernet interface des 1700er ist auch auf no shutdown.
Ich bin echt am verzweifeln, verstehe das nicht wieso da nix über die Leitung kommt (an physischer Kommunikation)
Habe das orange Kabel der Pix mal zwischen zwei Catalyst gehängt. Kein Signal der LED´s. Ich glaube wirklich dass das Kabel defekt ist. Mehr kann es ja nicht sein. Konfiguration ist einwandfrei.
Oder liege ich falsch?
Nach einem Test des Kabels bin ich mir jetzt 100%ig sicher dass dieses defekt ist.
Auch nach einem Versuch zwischen zwei Switches habe ich keine Connection bekommen.
Trotzdem danke für die Hilfe.
Viele Grüße
Mireux
Hi,
da spricht auch nichts dagegen - im Gegeteil. Aber wenn ich hier die Ausgaben poste, kann ich sie doch im identischen Thread hier im Forum auch posten, oder? Das hätte den Vorteil, dass einige Fragen übersprungen werden können.
In Zukunft bitte auch die Formiertungsrichtlinien benutzen. Bestes Beispiel sind die Codeboxen! Alles zu findest du im FAQ. Bitte in Zukunft dran denken...sieht einfach - bei größeren Sachen - besser aus. Beitrag gelöst, sehr gut -> geschlossen.
Grüße,
Dani
da spricht auch nichts dagegen - im Gegeteil. Aber wenn ich hier die Ausgaben poste, kann ich sie doch im identischen Thread hier im Forum auch posten, oder? Das hätte den Vorteil, dass einige Fragen übersprungen werden können.
In Zukunft bitte auch die Formiertungsrichtlinien benutzen. Bestes Beispiel sind die Codeboxen! Alles zu findest du im FAQ. Bitte in Zukunft dran denken...sieht einfach - bei größeren Sachen - besser aus. Beitrag gelöst, sehr gut -> geschlossen.
Grüße,
Dani
