richidd

Nein, den Standardgateway-Eintrag unter Windows hätt ich auch weglassen können. Die beiden Rechner sind allein an einem Switch. Da gibt es keine weiteren Netzwerkendgeräte bzw. -knoten. Die Windows und MAC Firewall ist down. Sonst hätte die einiges dicht gemacht und mich bei der Analyse nur behindert.

Windows PC: Windows-IP-Konfiguration Hostname . . . . . . . . . . . . : Mobile Prim‰res DNS-Suffix . . . . . . . : Knotentyp . . . . . . . . . . . . : Hybrid IP-Routing aktiviert . . . . . . : Nein WINS-Proxy aktiviert . . . . . . : Nein DNS-Suffixsuchliste . . . . . . . : Ethernet-Adapter LAN-Verbindung: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Marvell Yukon 88E8039 PCI-E Fast Ethernet Controller Physikalische Adresse . . . . . . : ##-##-##-##-##-## DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja IPv4-Adresse . . . . . . . . . . : 192.168.0.2(Bevorzugt) Subnetzmaske . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 192.168.0.1 NetBIOS ¸ber TCP/IP . . . . . . . : Aktiviert Ping wird ausgef¸hrt f¸r 169.254.90.3 mit 32 Bytes Daten: Antwort von 169.254.90.3: Bytes=32 Zeit<1ms TTL=255 Antwort von 169.254.90.3: Bytes=32 Zeit<1ms TTL=255 Antwort von 169.254.90.3: Bytes=32 Zeit<1ms TTL=255 Antwort von 169.254.90.3: Bytes=32 Zeit<1ms TTL=255 Ping-Statistik f¸r 169.254.90.3: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms IPv4-Routentabelle =========================================================================== Aktive Routen: Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik 0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.2 276 127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 306 127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 306 127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306 192.168.0.0 255.255.255.0 Auf Verbindung 192.168.0.2 276 192.168.0.2 255.255.255.255 Auf Verbindung 192.168.0.2 276 192.168.0.255 255.255.255.255 Auf Verbindung 192.168.0.2 276 224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 306 224.0.0.0 240.0.0.0 Auf Verbindung 192.168.0.2 276 255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306 255.255.255.255 255.255.255.255 Auf Verbindung 192.168.0.2 276 =========================================================================== St‰ndige Routen: Netzwerkadresse Netzmaske Gatewayadresse Metrik 0.0.0.0 0.0.0.0 192.168.0.1 Standard =========================================================================== +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ MAC - Rechner en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 169.254.90.3 netmask 0xffff0000 broadcast 169.254.255.255 ether ##:##:##:##:##:## media: autoselect (1000baseT <full-duplex,flow-control>) status: active supported media: none autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,flow-control> 10baseT/UTP <full-duplex,hw-loopback> 100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX <full-duplex,flow-control> 100baseTX <full-duplex,hw-loopback> 1000baseT <full-duplex> 1000baseT <full-duplex,flow-control> 1000baseT <full-duplex,hw-loopback> PING 192.168.0.2 (192.168.0.2): 56 data bytes 64 bytes from 192.168.0.2: icmp_seq=0 ttl=128 time=0.895 ms 64 bytes from 192.168.0.2: icmp_seq=1 ttl=128 time=0.703 ms 64 bytes from 192.168.0.2: icmp_seq=2 ttl=128 time=0.556 ms 64 bytes from 192.168.0.2: icmp_seq=3 ttl=128 time=0.623 ms ^C --- 192.168.0.2 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.556/0.694/0.895/0.127 ms #route -nv get 192.168.0.2 u: inet 192.168.0.2; u: link ; RTM_GET: Report Metrics: len 128, pid: 0, seq 1, errno 0, flags:<UP,GATEWAY,HOST,STATIC> locks: inits: sockaddrs: <DST,IFP> 192.168.0.2 route to: 192.168.0.2 destination: 192.168.0.2 interface: en0 flags: <UP,HOST,DONE,LLINFO,WASCLONED> recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 1200 locks: inits: sockaddrs: <DST,GATEWAY,IFP,IFA> 192.168.0.2 ##.##.##.##.##.## en0:##.##.##.##.##.## 169.254.90.3

Ich habe mir eine Testumgebung aufgebaut um den Problem auf die Spur zu kommen. Ein Mac OS X Rechner und ein Windows Vista Rechner an einem ISO/OSI Layer2 Switch. Auf beiden Rechnern ist ausschließlich IPv4 aktiviert. Mac OS X mit zeroconf Adresse (169.254.62.209/16) Windows Vista Rechner mit irgendeiner IP in einem anderen Subnet. Der MAC Rechner kann weiterhin auf den Windows Rechner zugreifen, egal in welchem Subnet und mit welcher IP der Windows Rechner adressiert ist. Ebenso kann der Windows Rechner auf den MAC Rechner mit der zeroconf-Adresse zugreifen. Drehe ich den Spieß um, d.h. der Windows Rechner bekommt eine zeroconf(APIPA) und der MAC Rechner z.b. eine Class C Adresse können sich beide Rechner nicht mehr sehen, wie es auch sein sollte. Da kein Routing zwischen den Subnets stattfindet, darf der Zugriff nur jeweils im eigenen Subnet funktionieren und nicht Subnet-übergreifend. Der Zugriff erfolgt stets per IP-Adresse und nicht per NetBios-Name/ Netzwerkumgebung. Auf beiden Rechnern ist jeweils nur eine IP-Adresse an der NIC aktiv. (abgesehen von den Multicast Adressen) @flashpixx Es wäre interessant ob du ohne Router ebenfalls aus dem zeroconf subnet auf die anderen Mac's und den Linux Rechner zugreifen kannst, solang diese in einem anderen Subnet, in Bezug auf das zeroconf Subnet, stehen. Subnetze: zeroconf: Netzwerkbasisadr.: 169.254.0.0 Subentmaske: 255.255.0.0 Broadcast: 169.254.255.255 Class C: Netzwerkbasisadr.: 192.168.0.0 Subnetmaske: 255.255.255.0 Broadcast: 192.168.0.255

Hi@flashpixx zugreifen heisst, der Zugriff auf jegliche offenen Ports/Dienste der Hosts. z.B. ICMP, SMB usw.. Ich habe zudem den ARP-Cache geleert und den traffic auf dem "zeroconf-MAC" mitgeschnitten während ich einen icmp-request (ping) geschickt habe. Es gibt ein paar Multicasts aus dem ClassC Netz und der "zeroconf-MAC" löst, als gäbe es keine Subnetze, die Class C IP mittels ARP auf, schickt das icmp-request Paket und erhält als Antwort ein icmp-reply. Ich hab zudem zuvor den bonhour-browsing Dienst (mDNSresponder) deaktiviert, weil ich dem Ding einfach nicht traue.

Hi@all Ich habe bei uns ein Problem mit dem zeroconf entdeckt, das ich aber absolut nicht kapiere. Ich hab ein paar MAC-Rechner in einem Klasse-C Subnetz (192.168.0.0/24) Wenn ich jetzt einen von diesen MAC-Rechnern eine zeroconf Adresse zuweisen lasse (z.B. 169.254.62.209/16), dann kann dieser auf die MAC-Rechner im Klasse-C Subnet zugreifen und umgedreht. Das dürfte eigentlich garnicht sein, weil das zwei verschiedene Subnetze sind und auch nicht geroutet werden. Ich hab zum Test auch einemal einen Win Vista PC eine APIPA Adresse zuweisen lassen. Dieser kann wie erwartet nicht auf das Klasse-C Subnet zugreifen. Hat irgendjmd eine Idee oder hab ich irgendwo einen Denkfehler? :confused:

Da hast du recht, garnicht dran gedacht....aber das ergebnis wird davon nicht beeinflusst. Da egal, welche Webseite man ansteuert das eine Ewigkeit dauert. Zumindest ist es inzwischen besser geworden..die hohe Latenzzeit tritt zwar immer noch fast regelmäßig auf, aber ich verlier keine Pakete mehr. Zuvor waren es z.T. 25% Verlust !!!

Hi, also ich habe ein absolut kurioses DSL-Problemchen. Bin gespannt ob da jmd Rat weiss. Also ich habe fast täglich gegen 20 Uhr einen extrem hohen Ping von ca. 200-300ms zu z.B. google.de Normal sind ca. 55ms Der Versatel-Support hat natürlich erstmal die Schuld auf meine Hardware geschoben. Ich setze einen Linksys WAG200G mit aktuellster Firmware ein. Nun wurde mir vom Support ans Herz gelegt doch erst den Original-Router von der Telekom einzusetzen (Speedstream 4100), habe ich also gemacht und nun wird es kurios. Mit dem Telekom "Router" war der Ping nach Login fast sofort wieder i.o. Also schliess ich meinen Linksys wieder an um zu prüfen ob es an diesem liegt und auf einmal habe ich auch beim Linksys wieder vernünftigen Ping. Das Phänomen ist im übrigen fast jedesmal reproduzierbar. Also kann mir das einer mal erklären? Ich bin zwar Fachinformatiker, aber dummerweise weiss ich nicht welche Software/Server ISPs einsetzen um weitere Vermutungen anstellen zu können, was das Problem sein könnte. Das Problem kann eigentlich nur am PPPOE-Server liegen. Wären es irgendwelche ATM-Switche zwischen dem Hausanschluss und dem ISP-PPPOE-Server wäre der hohe Ping höchstwahrscheinlich auch noch mit dem Telekom-"Router" vorhanden. PS: Keine Ahnung ob es damit was zu tun haben könnte, aber bei uns wurde vor ca. einem halben Jahr VDSL 50 ausgebaut.

Danke für die Antworten, ich werd wohl nicht drum rum kommen einen Router für das Load-Balancing zu benutzen. @flashpixx gegen die Lizenzbestimmungen würde dieses vorgehen nicht verstoßen, aber es dürfte nicht funktionieren.

Hi@all, ich hoffe Ihr könnt mir helfen. ch habe auch schon die SUFU benutzt aber keinen Lösungsansatz finden können der mir helfen könnte Wir haben eine ASA5510 und ich möchte 2 Internetleitungen mit der ASA benutzen. Da wir keine Fail-Over Lizenz besitzen muss die Lösung ein wenig tricky sein. Leider weiss ich auch nicht ob und wie man mit der ASA Load-Balancing einsetzen kann. Inet 1 - Standleitung für alle wichtigen Dienste ausser HTTP/S (TCP/80-443) Inet 2 - ADSL-Leitung für HTTP/S (TCP/80-443) Verbindungen Inet 1 wird über das Outside Interface angesprochen. Für dieses Interface ist eine Static Route eingerichtet: IP-Adress und Mask 0.0.0.0 DF-Gateway: 192.168.0.1 Metric 1 Da alle anderen physischen Interfaces belegt sind wird der ADSL-Router für die Inet 2 mit einem VLAN-Interface an die ASA angebunden. Dieses Interface soll ebenfalls eine static Route erhalten: IP-Adress und Mask 0.0.0.0 DF-Gateway: 192.168.1.1 Metric 2 Damit ausschließlich Inet2 für HTTP/S benutzt wird möchte ich den TCP/80-443 Port mit den Access Rules für Inet1 (Outside Interface) sperren. Kann das funktionieren? Ich habe bedenken, dass bei ausgehenden HTTP/S-Traffic die Access Rule mit deny reagiert und danach nicht automatisch versucht wird über das VLAN-Interface mit der Metric 2, für die HTTP/S erlaubt ist, die Verbindung zu routen. Über alternative Vorschläge/Lösungen wäre ich auch sehr dankbar.