[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Probleme mit udev & xen



"Dominique H. Schramm" <info@schramm.by> wrote:

>>> Die RTL Karte wird beim Reboot nicht richtig vom Kernel
>>> resettet bzw. wird wohl beim Resett die Adresse der peth0 auf
>>> die eth0 geschrieben. Bei einer INTEL Karte kommt das nicht
>>> vor, da wird beim Reboot alles so gelassen wie es ist.

>> Was wird wann wohin geschrieben? Bitte mit entsprechenden Ausgaben
>> belegen.

> Hier die Ausgabe von ifconfig -a

> eth0      Link encap:Ethernet  HWaddr 00:19:DB:F9:72:EE
> peth0     Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF

> Das mit den Dummy Adressen FE:FF:FF:FF:FF habe ich bereits verstanden.
> Nun ist es aber doch so, dass irgendwie auf die eth0 dieses FE:FF...
> gelangen muss, das kann ja nicht von ungefähr kommen. 

Bisher sieht das doch gut aus, so wie es aussehen soll.

> Daher meine Vermutung dass beim Reboot und dem Auflösen des Bridging
> irgendwo der Fehler entsteht und deswegen dann die eth0 plötzlich
> FE:FF...  hat.

_Das_ ist in der Tat ungewöhnlich. Kannst du einmal in ein
Rettungssystem wie GRML oder Knoppix rebooten und schauen, ob dort dann
die Dummy-MAC in der Karte vorhanden ist? Wenn ja: Wegwerfen und zwar
möglichst weit.

>> Man beachte, dass peth0, obwohl es das eigentliche physical interface
>> ist, eine Dummy-MAC hat, während eth0, welche ja mit vif0.0 gekoppelt
>> ist, die eigentliche MAC der Netzhardware hält.

> Den Satz muss ich nen paar Mal lesen damit ich den richtig
> verstehe:

> eth0 -> peth0 << physikalische

> dabei hat peth0 -> dummy

> eth0 -> vif0.0 --> MAC der Hardware.
> Nun meine vif0.0 hat aber:

> FE:FF:FF.....

Alles ok.

Bei Xen ist alles ein wenig "anders", da ja auch die Dom0 als
virtualisierte Umgebung unterhalb (oder oberhalb, wie man will) des
Hypervisors läuft.

_Vor_ Xen3.0 war es so, dass man in der Dom0 eth0 hatte, welches das
wirkliche Interface war, dieses wurde dann in die xenbr0 geführt und die
IP dann auf das Bridge-Interface gelegt, welchem dann wiederum die vifs
angefügt wurden.

Das wurde in Xen3.0 dann vereinheitlicht, so dass *auch* die Dom0 ein
virtualisiertes Ethernet-Interface bekommen hat.

Ich zitiere einmal die xen-config.sxp:

,----
|  dom0: fake eth0 -> vif0.0 -+
|                             |
|                           bridge -> real eth0 (peth0) -> the network
|                             |
|  domU: fake eth0 -> vifN.0 -+
`----

Um jetzt zu meinem Satz von oben zu kommen: Es überrascht einen jetzt
(mich zumindest), dass peth0 eine Dummy-MAC hat, obwohl sich dahinter
eigentlich der echte Netz-Treiber befindet. eth0 dagegen, welches jetzt
über den xen-netfront-Treiber geführt wird, hat die MAC, die die echte
Karte hatte (bzw. hat).

Wenn *wirklich* die Dummy-MAC von peth0 sich in der RealTek-Karte
befindet, auch nach dem du z.B. in GRML rebootet hast, dann ist die
Hardware noch schlechter, als ich schon immer dachte.

Im Zweifelsfalle nicht herumdoktoren, sondern entsorgen.

S°

-- 
Sven Hartge -- professioneller Unix-Geek
Meine Gedanken im Netz: http://www.svenhartge.de/


Reply to: