Das Upgrade von Parallels Desktop 5 auf 6 verursachte eine "Langsamkeit" der DNS-Abfrageauflösung auf Mac OS X-Ebene

Fühlt sich das noch jemand anders an / hat eine Idee, wie man es beheben kann, ohne Snow Leopard neu zu installieren? Dies scheint den Problemen sehr ähnlich zu sein, die PD im Jahr 2008 hatte ( Forenlink ).

FWIW, meine aktuellen Netzwerkschnittstellen sind:

$ ifconfig -l
lo0 gif0 stf0 en0 en1 fw0 vnic0 vnic1 vmnet1 vmnet8

(Und ja, wie Sie den NICs entnehmen können, führe ich auch VMWare Fusion 3.1.1 aus, aber das Problem trat beim Upgrade auf PD6 auf.)

$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
 inet6 ::1 prefixlen 128
 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
 inet 127.0.0.1 netmask 0xff000000
 inet6 fd18:d7ce:18ee:1e60:223:32ff:fea0:fade prefixlen 128
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 ether HH:II:DD:DD:EE:NN
 media: autoselect
 status: inactive
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 ether HH:II:DD:DD:EE:NN
 inet6 HH:II:DD:DD:EE:NN%en1 prefixlen 64 scopeid 0x5
 inet 192.168.0.198 netmask 0xffffff00 broadcast 192.168.0.255
 media: <unknown subtype>
 status: active
fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078
 lladdr 90:84:0d:ff:fe:ba:6d:2a
 media: autoselect <full-duplex>
 status: inactive
vnic0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 ether 00:1c:42:00:00:08
 inet 10.211.55.2 netmask 0xffffff00 broadcast 10.211.55.255
 inet6 fe80::21c:42ff:fe00:8%vnic0 prefixlen 64 scopeid 0x7
 inet6 ::1 prefixlen 64
 media: autoselect
 status: active
vnic1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 ether 00:1c:42:00:00:09
 inet 10.37.129.2 netmask 0xffffff00 broadcast 10.37.129.255
 inet6 fe80::21c:42ff:fe00:9%vnic1 prefixlen 64 scopeid 0x8
 inet6 ::1 prefixlen 64
 media: autoselect
 status: active
vmnet1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 ether 00:50:56:c0:00:01
 inet 172.16.155.1 netmask 0xffffff00 broadcast 172.16.155.255
vmnet8: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 ether 00:50:56:c0:00:08
 inet 192.168.102.1 netmask 0xffffff00 broadcast 192.168.102.255

$ cat /etc/resolv.conf
nameserver 208.67.220.220
nameserver 208.67.222.222
Können Sie die Ausgabe Ihrer ifconfig und die Ausgabe von: cat /etc/resolv.conf (in Terminal.App natürlich) posten?

Antworten (1)

Beginnen Sie mit einigen Tests in Ihrem Terminal:

  1. Verwenden Sie nslookup und versuchen Sie, bestimmte Dinge nachzuschlagen (www.google.com, www.ibm.com usw.). Sehen Sie, wie es von dort aus funktioniert.

  2. Verwenden Sie 'dig' (einen anderen Befehl), um dasselbe zu tun. Dig wird viel ausführlicher sein und Ihnen mehr Informationen über die Suche an sich anzeigen.

  3. Stellen Sie sicher, dass Ihre DNSs in /etc/resolv.conf korrekt sind (versuchen Sie Googles 8.8.8.8, wenn Sie sich nicht sicher sind).

  4. Überprüfen Sie Ihre Konsole auf mögliche Meldungen im Zusammenhang mit Netzwerkadaptern oder aktiven Schleifen.

Edit: Scheint alles "normal" zu sein. Verwenden Sie Shared Networking? Können Sie versuchen, vnic0 und vnic1 zu deaktivieren (das sind die parallelen). Ich erinnere mich an Langsamkeitsprobleme (damals in Parallels 3.x), die ich behoben habe, indem ich Bridged Networking anstelle von Shared verwendet habe. Ich dachte nicht, dass das Problem ein paar Jahre später immer noch ein Problem war!

1 und 2) Manchmal löst es sich sofort auf, manchmal ist es höllisch ätzend. Das ist das Verwirrende. Ich habe tatsächlich die Befehle "time nslookup" und "time dig" ausgeführt und bekomme ein seltsames Verhalten. 3) Meine DNS-Server sind definitiv korrekt. Ich verwende OpenDNS, weil ich möchte, dass Google zumindest nicht alle meine Pornogewohnheiten kennt. 4) Ich sehe einige seltsame Kernel.log-Meldungen mit VMWare-Informationen ... (vmnet: VMNET_SO_BINDTOHUB: port: paddr vmnet: bridge-en1: media 80 dev 0x89f2404 family 2vmnet: Invalidating peer info for hub: 0, port: 0vmnet: VNetUserIfFree: Befreit userIf bei 0x9e8df00.) Ich muss mir das genauer ansehen. Danke!
Ich verwende auch OpenDNS, also versuche, alle virtuellen Adapter zu deaktivieren, die sowohl von Parallels als auch von VMWare bereitgestellt werden, und starte einen nach dem anderen. Bridged Networking funktioniert normalerweise (für mich) am besten, da es einen „echten“ Adapter (jedenfalls virtuell) erstellt und sich nicht mit der Erstellung eines „privaten Netzwerks“ zwischen Ihrem Mac und Ihren VMs herumschlägt.