eth0 verschwindet in Debian VMware

[rs80]

Hallo zusammen

Kennt jemand das Problem bei Debian-40r0 in VMWARE.
Manchmal wenn man die VMware virtuell ausschaltet,
(Also shutdown -h now und erneutes einschalten)
verschwindet einfach eth0, obwohl der Netzweradapter in VMware
noch immer auf Connected und Bridged steht.

Man kann ihn irgendwie auch nicht mehr aktivieren,
denn bei der Eingabe von: ifconfig eth0 dynamic up
erscheint:
eth0: ERROR while getting interface flags: Kein passendes Gerät gefunden

Wenn man allerdings den Bootschirm mit folgendem Kommando absucht:

dmesg | grep eth

erscheint:

eth0: registered as PCnet/PCI II 79C970A

Seltsam, denn auch ein neustarten mit
/etc/init.d/networking restart
hilft nichts.

Mit ifconfig -a findet man jedoch heraus, dass jetzt eth1
vorhanden ist. Warum auch immer!

Aber okay, dann versuchte ich eben diesen mit
ifconfig eth1 dynamic up
zu aktivieren.

Aber dieser holt sich nie eine DHCP Adresse und beim Neustart
verschwindet er auch immer wieder,
obwohl ich dann auch die /etc/network/interfaces
auf eth1 angepasst habe

Dieses Problem habe ich nun schon bereits auf 3 verschiedenen
Debian Versionen auf VMware festgestellt.

Bei richtigen pysikalischen PCs mit Debians kommt dies nie vor.

Kann mir jemand weiterhelfen?

Wäre sehr dankbar.

Viele Grüsse

Ralph

[rs80]

Hallo zusammen

Hab nun folgende Änderungen in der Datei /etc/network/interfaces
vorgenommen und das Netzwerk neu gestartet:

VORHER:

Code: Alles auswählen

[...]

auto lo
iface lo inet loopback

# The primary network interface

allow-hotplug eth0

iface eth0 inet dhcp

NACHHER:

Code: Alles auswählen

[...]

auto lo
iface lo inet loopback

# The primary network interface

#allow-hotplug eth0
 auto eth1
iface eth1 inet dhcp

Nun funktionierts. Wieso genau eth0 plötzlich einfach so rausfliegt,
was der Unterschied zwischen allow-hotplug eth1 und auto eth1
genau ist und wieso im dmesg trotzdem eth0 als Netzwerkadapter
gefunden wird, weiss ich noch nicht.

Wenn ich es rausfinde, werde ich mal noch was schreiben.
Ansonsten lege ich es zur Akte X.

Viele Grüsse

Ralph

[MSueper]

seltsam,
danke Für den Update!
Grüße, Martin

[okx]

Ahoi,

wenn der Thread noch lebt, kann ich noch einen drauf setzen...

Ich habe ein sehr ähnliches Problem wie rs80:
Ein mit dem Server aufgesetzes Debian (etch) wird auf verschiedenen Windoof Rechnern mit dem Player abgespielt und bekommt dann keine Netzwerkkarte. Als Randbedingung wäre noch zu sagen, daß die VM mit Host-only konfiguriert wurde, was auch auf dem Server hervorragend funktioniert. Sobald die Maschine im Player auf einem fremden Rechner läuft, meldet Debian beim Aktivieren der eth0 "no such device". Witziger Weise passiert es nicht wenn der Host ein Linux ist - also nur bei Windows Hosts besteht diese Problem.

Aus Spaß habe ich mal den Tip von rs80 umgesetzt und es mit der Konfiguration von eth1 ausprobiert - NIX GUT!
Mehr oder weniger aus Blödellei habe ich es dann mal mit eth2 probiert... - siehe da, eth2 war ein Volltreffer!
Ich bin ein wenig verwirrt, ich hatte gedacht, daß der Adapter vmnet1 (Host-Only) als einziger Adapter in die VM reingereicht wird und dieser dann auch vom Debian als eth0 erkannt wird?
Bin ich da auf dem Holzweg, oder erkennt da vielleicht jemand ein logisches System?

Gruß,
okx

[okx]

Ok, selbst ist der Mann :

Auch wenn ich nicht verstanden habe warum Debian sich so merkwürdig mit dem vergeben der eth Nummern verhält, kann man simpel mit

Code: Alles auswählen

grep eth /proc/net/dev

sich die vom System erkannten eths anschauen und dann gezielt diese hochfahren bzw. sie in der /etc/network/interfaces verdrahten.

Da ich die VMs auf verschiedenen Rechnern laufen lassen will/muß ist also in der VM jeweils ein einmaliger (hoffentlich) Eingriff nötig - hmm

[MSueper]

Hi,
dies sind alle meine Einträge zu ethernet0 und einer VM mit Linux:

ethernet0.present = "TRUE"
ethernet0.addressType = "generated"
ethernet0.generatedAddress = "00:0c:29:69:75:67"
ethernet0.generatedAddressOffset = "0"

bei einigen kommt noch

ethernet0.virtualdev = "e1000"
ethernet0.connectionType = "bridged"

hinzu.
Hast Du weitere Einstellungen? Trag mal >> ethernet0.connectionType = "bridged" << explizit bei Dir in die vmx-Datei ein und poste auch mal die ganze vmx-Datei. Da sind ggf. noch irgendwelche Reste drin...
Martin

[okx]

So, hier kommt meine vmx:

Code: Alles auswählen

config.version = "8"
virtualHW.version = "4"
scsi0.present = "TRUE"
scsi0.virtualDev = "lsilogic"
memsize = "256"
scsi0:0.present = "TRUE"
scsi0:0.fileName = "Other Linux 2.6.x kernel.vmdk"
ide1:0.present = "FALSE"
ide1:0.fileName = "auto detect"
ide1:0.deviceType = "cdrom-raw"
floppy0.fileName = "A:"
Ethernet0.present = "TRUE"
displayName = "bomvers"
guestOS = "other26xlinux"
priority.grabbed = "normal"
priority.ungrabbed = "normal"

ide1:0.autodetect = "TRUE"
floppy0.startConnected = "FALSE"

scsi0:0.redo = ""
ethernet0.addressType = "generated"
uuid.location = "56 4d a2 a6 4c ce c3 53-6b 31 ae a0 a7 52 01 3d"
uuid.bios = "56 4d a2 a6 4c ce c3 53-6b 31 ae a0 a7 52 01 3d"
ethernet0.generatedAddress = "00:0c:29:52:01:3d"
ethernet0.generatedAddressOffset = "0"

ide1:0.startConnected = "FALSE"

ethernet0.connectionType = "hostonly"

floppy0.present = "FALSE"
workingDir = "."


Der Connection-Type steht übrigens auf hostonly, was auch in meinem Fall korrekt und gewünscht ist. Der Zugriff soll nur über ein privates Netzwerksegment "sichtbar" sein.
Am ethernet0.virtualdev habe ich auch schon mal erfolglos rumgeschraubt. Der Eintrag hat für meine Problematik vermutlich keine Auswirkungen
Was mich an der vmx-Datei ein wenig wundert ist die bunte Reihenfolge der Einträge und die unterschiedliche Groß/Kleinschreibung von Ethernet. Ich habe dies jedenfalls nicht verursacht.

Gruß,
okx

[the13th]

Da ich das Thema auch gerade durch habe hier mal als "Einstand" die Lösung

Nach dem Kopieren eines VM Ware Images und dem importieren des selbigen wird die MAC Adresse der Netzwerkkarte geändert.

Da Linux eine Liste der MAC IDs pro IF vorhält und somit eth0 für die Netzwerkverwaltung "nicht mehr vorhanden ist", die neue MAC ID aber auch nicht bekannt ist, wird daraus dann eth1.

Die Lösung ist eigentlich ganz Simpel:

1. In der neu erstellen .vmx Datei die MAC Adresse der Netzwerkkarten auslesen (ethernet0.generatedAddress)
2. Die Virtuelle Maschine anschmeissen und dann mit dem Texteditor der Wahl die durch das kopieren neuerstellte MAC ID in der Datei /etc/iftab an entsprechender Stelle einfügen
3. Die virtuelle Maschine neustarten.

[okx]

Hallo nochmal,

Da ich mit Deiner (the13th) und meiner Lösung nicht so ganz zufrieden war, habe ich noch ein wenig weiter geforscht. Auf alle Fälle ist das Verrutschen der eths auf die sich ändernde MAC-Adresse zurückzuführen, wie Du sehr richtig herausgefunden hast - vielen Dank für den Schubs in die richtige Richtung!

Im Thread des Ubuntu-Forums http://ubuntuforums.org/showthread.php?p=3196271 (ganz unten) wird geschrieben, wie man udev austricksen kann um immer eth0 zu vergeben, unabhängig von der MAC-Adresse.

Code: Alles auswählen

GOTO="persistent_net_generator_end"

an den Anfang von /etc/udev/persistent-net-generator.rules stellen
und den Inhalt von Datei /etc/udev/rules.d/z25_persistent-net.rules löschen und einmal durchstarten (ein frischer Boot tut immer gut ).

Der Vorteil von dieser Methode ist, daß man dies nur einmal machen muß und die VM dann auf jedem Host-System sich die eth0 schnappt - Ein rumpuzzeln in Config-Dateien für jede Player-Instanz bzw. jeden neuen Host entfällt somit
Genau das ist für mich wichtig, wenn die VM auf vielen unterschiedlichen Hosts laufen soll!

Gruß,
okx

[emil82]

Hallo okx,

dein letzter Beitrag verwirrt mich etwas. Wenn ich deine Anweisungen befolge schnappt sich mein Debian Etch überhaut keine eth mehr, ich muss diese immer erst mit "ifup eth0" per Hand starten.

Hab ich da etwas falsch verstanden? Kannst du mir bitte exakt beschreiben wo die besagte Zeil rein muss.

Code: Alles auswählen

# These rules generate rules to keep network interface names unchanged
# across reboots write them to /etc/udev/rules.d/z25_persistent-net.rules.
#
# The default name for this file is z45_persistent-net-generator.rules.

# hier die von dir beschriebene Zeile.....
GOTO="presistent_net_generator_end"

ACTION!="add",                          GOTO="persistent_net_generator_end"
SUBSYSTEM!="net",                       GOTO="persistent_net_generator_end"

# ignore the interface if a name has already been set
NAME=="?*",                             GOTO="persistent_net_generator_end"

# ignore "secondary" raw interfaces of the madwifi driver
KERNEL=="ath*", ATTRS{type}=="802",     GOTO="persistent_net_generator_end"

# provide nice comments for the generated rules
SUBSYSTEMS=="pci", \
 ENV{COMMENT}="PCI device $attr{vendor}:$attr{device}"
SUBSYSTEMS=="usb", \
 ENV{COMMENT}="USB device $attr{idVendor}:$attr{idProduct}"
SUBSYSTEMS=="ieee1394", \
 ENV{COMMENT}="Firewire device $attr{host_id}"
SUBSYSTEMS=="xen", \
 ENV{COMMENT}="Xen virtual device"
ENV{COMMENT}=="", \
 ENV{COMMENT}="Unknown $env{SUBSYSTEM} device ($env{DEVPATH})"
ATTRS{driver}=="?*", \
 ENV{COMMENT}="$env{COMMENT} ($attr{driver})"

# ignore interfaces without a driver link like bridges and VLANs
KERNEL=="eth*|ath*|wlan*|ra*|sta*", DRIVERS=="?*",\
        IMPORT{program}="write_net_rules $attr{address}"

ENV{INTERFACE_NEW}=="?*", NAME="$env{INTERFACE_NEW}"

LABEL="persistent_net_generator_end"


MfG Emil

[skammann]

Wollte mal kurz ein Danke in den Raum schmeissen

Hatte das gleiche Problem und konnte das , dank dieses Threads , sofort lösen.

Gruss

Stefan

[RogerG781]

Hi Leute,
ich hole den Thread nochmal hervor. Vor einigen Tagen habe ich meinem ESXi mehr RAM gegönnt. Beim Herunterfahren des ESXi wurde anscheinend meine Debian-VM nicht sauber beendet
Nach einschalten des ESXi erscheint beim Versuch die Debian-VM zu starten immer die Fehlermeldung:
Could not power on VM: No Swap File
Failed to Power on VM
Da es sich bei meinem ESXi um ein Standalone-Gerät handelt, konnte ich einen noch laufenden Prozess durch eine Migration ausschliessen. Ein Reboot änderte das Verhalten nicht. Speicherplatz ist ebenfalls genug auf dem Storage vorhanden.
Da ich nicht weiterkam, erstellte ich eine weitere VM und übergab ihr die Festplatte der alten VM.
Nun startet die VM auch wieder, erkennt aber keine Netzwerkkarten. Mit einem ifconfig, wird mir nur der Loopback-Adapter angezeigt.
Nun wollte ich zunächst die MAC-Adresse der alten VM auf die neue übertragen. Aber anscheinend hat sich durch ein ESXi Update die MAC-Range bei VMware geändert?
VM-Alt MAC-Adresse: 00:0C:29
VM-Neu MAC-Adresse: 00:50:56
Also konnte ich die MAC-Adressen nicht übertragen, da sich der VI-Client beschwert, dass es nicht innerhalb der Range liegen würde.
So versuchte ich zunächst mit dem Befehl grep eth /proc/net/dev die Nummer des neuen Interfaces zu ermitteln und es wurde mir eth5 angezeigt. Wenn ich nun allerdings versuche mit ifup eth5 das Interface zu starten, bekomme ich die Fehlermeldung: Ignoring unknown interface eth5=eth5
Wie bekomme ich es am besten wieder hin, die Debian-VM mit eth0 und eth1 und den bereits konfigurierten IP-Adressen ans Rennen zu bekommen?
Danke.

[chris72]

Wie bekomme ich es am besten wieder hin, die Debian-VM mit eth0 und eth1 und den bereits konfigurierten IP-Adressen ans Rennen zu bekommen?

öffne mal /etc/udev/rules/70-persistent-net.rules
und lösch alle Einträge raus.
Nach dem nächsten reboot werden die Netzwerkkarten
neu erkannt und aufsteigend beginnend bei eth0
wieder in die Datei eingetragen.


Kämpfe gerade selbst mit dem Anfangs beschriebenen Problem
das die Netzwerkkarte erst nach einem zusätzlichen "ifconfig eth0 up"
funktioniert. Verwende vmware-server mit Host Win2003 und Guest
CentOS5.3. Wobei ich bereits verschiedene Linux Distries durchprobiert
habe und auch unter vmware-server 1.09 dasselbe Problem hab.
Beim CentOS hab ich dann zufällig die Krücke mit dem ifconfig entdeckt.

eth0 hat statisch eine IP zugewiesen und wird über bridged mode mit
dem Lan verbunden. Nach /etc/init.d/network start ist das Interface up
aber ich kann weder raus noch rein pingen.
Wenn ich dann nochmal "ifconfig eth0 up" in der Shell starte, dann
funktioniert das Netzwerk. ifconfig eth0 liefert genau die gleiche
Ausgabe wie vor dem "up".
In den diversen Logfiles finde ich auch nichts.

Hab bereits einige Zeit gegoogelt und auch einige Postings von Leuten
mit dem gleichen Problem gefunden. War aber keine saubere Lösung dabei.

Hab jetzt einfach "ifconfig eth0 up" am Ende vom "start" case in
/etc/init.d/network ergänzt. Damit kann ich vorerst leben.

Hatte bisher noch nie Probleme mit vmware Netzwerkverbindungen.

[Locke85]

Hallo nochmal,

Da ich mit Deiner (the13th) und meiner Lösung nicht so ganz zufrieden war, habe ich noch ein wenig weiter geforscht. Auf alle Fälle ist das Verrutschen der eths auf die sich ändernde MAC-Adresse zurückzuführen, wie Du sehr richtig herausgefunden hast - vielen Dank für den Schubs in die richtige Richtung!

Im Thread des Ubuntu-Forums http://ubuntuforums.org/showthread.php?p=3196271 (ganz unten) wird geschrieben, wie man udev austricksen kann um immer eth0 zu vergeben, unabhängig von der MAC-Adresse.

Code: Alles auswählen

GOTO="persistent_net_generator_end"

an den Anfang von /etc/udev/persistent-net-generator.rules stellen
und den Inhalt von Datei /etc/udev/rules.d/z25_persistent-net.rules löschen und einmal durchstarten (ein frischer Boot tut immer gut ).

Der Vorteil von dieser Methode ist, daß man dies nur einmal machen muß und die VM dann auf jedem Host-System sich die eth0 schnappt - Ein rumpuzzeln in Config-Dateien für jede Player-Instanz bzw. jeden neuen Host entfällt somit
Genau das ist für mich wichtig, wenn die VM auf vielen unterschiedlichen Hosts laufen soll!

Gruß,
okx

gibt es auch eine Variante für Suse???

[Dayworker]

Versuch mal den VMTN-Eintrag SUSE 10 and changing MAC addresses, ob das auch noch mit deiner Suse-Version funktioniert.

[Locke85]

Versuch mal den VMTN-Eintrag SUSE 10 and changing MAC addresses, ob das auch noch mit deiner Suse-Version funktioniert.

vielen dank aber jetzt fangen die Proleme erst an

1. rename the ifcfg-eth-id-&lt;MAC-ADDRESS&gt; to ifcfg-eth0 (in /etc/sysconfig/network)



soll ich ifcg-eth-id-00:50:56:XX:YY:ZZ >> ifcg-eht0
oder
ifcg-eth-id-00:50:56:XX:YY:ZZ >> ifcg-eth0-id-00:50:56:XX:YY:ZZ??

2. remove the rules file (/etc/udev/rules.d/30-&lt;rest of name here&gt;



diese Datei ist nicht vorhanden oder soll ich komplett rules.d löschen?

3. edit /etc/sysconfig/network/config and change FORCE_PERSISTENT_NAMES to "no".

Code: Alles auswählen

## Path:   Network/Hardware/Config
## Description:   Set some general network configuration
## Type:   string("","-","+")
## Default:   "+"
## ServiceRestart: network
#
# DEFAULT_BROADCAST is used when no individual BROADCAST is set. It can get one
# of the following values:
# ""  : don't set a broadcast address
# "-" : use IPADDR with all host bits deleted
# "+" : use IPADDR with all host bits set
DEFAULT_BROADCAST="+"

## Type:   yesno
## Default:   yes
# sometimes we want some script to be executed after an interface has been
# brought up, or before an interface is taken down.
# default dir is /etc/sysconfig/network/if-up.d for POST_UP and
# /etc/sysconfig/network/if-down.d for PRE_DOWN
GLOBAL_POST_UP_EXEC="yes"
GLOBAL_PRE_DOWN_EXEC="yes"

## Type:        yesno
## Default:     no
# If ifup should check if an ip address is already in use, set this to yes.
# Make sure that packet sockets (CONFIG_PACKET) are supported in the kernel,
# since this feature uses arping, which depends on that.
# Also be aware that this takes one second per interface; consider that when
# setting up a lot of interfaces.
CHECK_DUPLICATE_IP="no"

## Type:        yesno
## Default:     no
# Switch on/off debug messages for all network configuration stuff. If set to no
# most scripts can enable it locally with "-o debug".
DEBUG="no"

## Type:        yesno
## Default:     yes
# Should error messages from network configuration scripts go to syslog, or do
# you like them on stderr?
USE_SYSLOG="yes"

## Type:        yesno
## Default:     yes
# There are some services (ppp, ippp, dhcp-client, pcmcia, hotplug) that have to
# change the /etc/resolv.conf dynamically at certain times.  E.g. if ppp/ippp
# establishes a connection and is supplied by the peer with a list of
# nameservers. Or pcmcia needs to set the correct nameserver for the choosen
# configuration scheme. If you don't like these services to change
# /etc/resolv.conf at all, then set this variable to "no".
# If unsure, leave it at the default (which is "yes").
#
MODIFY_RESOLV_CONF_DYNAMICALLY="yes"

## Type:        yesno
## Default:     no
# Like MODIFY_RESOLV_CONF_DYNAMICALLY, except it modifies /etc/named.conf.
# If unsure, leave it at the default (which is "no").
#
MODIFY_NAMED_CONF_DYNAMICALLY="no"

# Handling of network connections
# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# These features are designed for the convenience of the experienced
# user. If you encounter problems you don't understand then switch
# them off. That is the default.
# Please do not complain if you get troubles. But if you want help to
# make them smarter write to <http://www.suse.de/feedback>.

## Type:   yesno
## Default:   no
#
# If you are interested in the connections and nfs mounts that use a
# network interface, you can set CONNECTION_SHOW_WHEN_IFSTATUS="yes".
# Then you will see them with 'ifstatus <interface>' (or 'ifstatus
# <config>')
# This one _should_ never harm ;)
#
CONNECTION_SHOW_WHEN_IFSTATUS="no"

## Type:   yesno
## Default:   no
#
# If an interface should be set down only if there are no active
# connections, then use CONNECTION_CHECK_BEFORE_IFDOWN="yes"
#
CONNECTION_CHECK_BEFORE_IFDOWN="no"

## Type:   yesno
## Default:   no
#
# If these connetions (without the nfs mounts) should be closed when
# shutting down an interface, set CONNECTION_CLOSE_BEFORE_IFDOWN="yes".
# WARNING: Be aware that this may terminate applications which need
# one of these connections!
#
CONNECTION_CLOSE_BEFORE_IFDOWN="no"

## Type:   yesno
## Default:   no
#
# If you are a mobile laptop user and like even nfs mounts to be
# closed when you leave your current workplace, then set
# CONNECTION_UMOUNT_NFS_BEFORE_IFDOWN="yes". This does only work
# if CONNECTION_CLOSE_BEFORE_IFDOWN="yes", too.
# WARNING: Be aware that this may terminate applications which use
# these nfs mounts as working directory. Be very carefull if your home
# is mounted via nfs!!!
# WARNING: This may even lead to hanging ifdown processes if there are
# processes that could not be terminated. If you are using
# hotpluggable devices (pcmcia, usb, firewire), first shut them down
# before unplugging!
#
CONNECTION_UMOUNT_NFS_BEFORE_IFDOWN="no"

## Type:   yesno
## Default:   no
#
# If terminating processes that use a connection or nfs mount is not
# enough, then they can be killed after an unsuccesfull termination.
# If you want that set CONNECTION_SEND_KILL_SIGNAL="yes"
#
CONNECTION_SEND_KILL_SIGNAL="no"

## Type:        string
## Default:     ""
#
# Here you may specify which interfaces have to be up and configured properly
# after 'rcnetwork start'. rcconfig will return 'failed' if any of these
# interfaces is not up. You may use interface names as well but better use
# hardware descriptions of the devices (eth-id-<macaddress> or eth-bus-...  See
# man ifup for 'hardware description'). The network start script will wait for
# these interfaces, but not longer as set in WAIT_FOR_INTERFACES.
# You need not to add dialup or tunnel interfaces here, only physical devices.
# The interface 'lo' is always considered to be mandatory and can be omitted.
#
# If this variable is empty, rcnetwork tries to derive the list of mandatory
# devices automatically from the list of existing configurations. Configurations
# with names bus-pcmcia or bus-usb or with STARTMODE=hotplug are skipped. (try
# '/etc/init.d/rc5.d/S*network start -o debug fake | grep MANDAT')
MANDATORY_DEVICES=""

## Type:   integer
## Default:   20
#
# Some interfaces need some time to come up or come asynchronously via hotplug.
# WAIT_FOR_INTERFACES is a global wait for all mandatory interfaces in
# seconds. If empty no wait occurs.
#
WAIT_FOR_INTERFACES="20"

## Type:   yesno
## Default:   yes
#
# With this variable you can determine if the SuSEfirewall when enabled
# should get started when network interfaces are started.
FIREWALL="yes"

## Type:        string("off","guess","auto-off","auto-manual","manual")
## Default:     "off"
#
# !!!This feature is still not implemented. Leave it to 'off'!!!
# What shall we do if there is no valid configuration?
# off:         do nothing, just fail
# guess:       try to guess the needed info (zeroconf)
# auto-off:    trigger automatic creation of a config file; if that fails, do
#              nothing, just fail
# auto-manual: trigger automatic creation of a config file; if that fails, ask
#              user to provide configuration (via yast)
# manual:      ask user to provide configuration (via yast)
# !!!This feature is still not implemented. Leave it to 'off'!!!
FAILURE_ACTION=off

## Type:        string
## Default:     "eth*[0-9]|tr*[0-9]|wlan[0-9]|ath[0-9]"
#
# Automatically add a linklocal route to the matching interfaces.
# This string is used in a bash "case" statement, so it may contain
# '*', '[', ']'  and '|' meta-characters.
#
LINKLOCAL_INTERFACES="eth*[0-9]|tr*[0-9]|wlan[0-9]|ath[0-9]"

## Type:        string
## Default:     "-a -f -I -u 0 -d 10"
#
# Set default options for ifplugd. You may also set them in an ifcfg-* file
# individually. Have a look at 'man ifplug' for details. We let ifplugd set the
# interface UP when starting, because there are many interfaces where link beat
# cannot be detected otherwise. If you want the interface to stay down then add
# the option '-a'.
#
IFPLUGD_OPTIONS="-f -I -u 0 -d 10"

## Type:        yesno
## Default      yes
#
# If you don't want to use ipv6 at all, set this to 'no'. Then ifup will always
# flush all ipv6 adresses. This might be usefull together with ifplugd, if link
# beat detection is only possible with interface UP.
#
USE_IPV6=no


FORCE_PERSISTENT_NAMES sowas finde ich leider nicht

Benutze 9.3 suse

MfG

Locke85

[Dayworker]

Für Suse 9.3 gehts im Thread Neue MAC alte IP weiter.