NIC ene keer eth0 andere keer eth1

[Sir Isaac]

Van mijn PC (ubuntu 9.10) heb ik network manager verwijderd, omdat hij toch altijd onder mijn bureau staat met een touwtje naar de switch en maar een NIC heeft.
Network is netjes in /etc/network/interfaces geconfigureerd. Maar ik merk dat mijn NIC soms verandert van eth0 naar eth1. Omdat de boel hard geconfigureerd is werkt het netwerk dan niet totdat ik mijn configuratie heb aangepast en ifup doe.
Nogal irritant. Kan je ergens forceren dat de NIC altijd eth0 is? Ik neem aan dat dat bij het laden van de betreffende kernel module wordt gedaan, maar dat gaat automatisch. Het gaat om een realtek NIC, en ik heb een 2.6.31 kernel.

[!null]

Als ie eth1 is geworden, zit er dan nog iets anders op eth0?

[MisterE]

in de udev rules (/etc/udev/...rules.d/ oid) kan je bepalen aan de hand van specs welke naam ie krijgt. Normaal gesproken wordt alleen de naam verhoogd wanneer je hem in een ander pci slot douwt.

[FireAge]

Ik had op mijn server eenzelfde probleem.
NIC0 was voor internet.
NIC1 was voor intranet.
NIC2 hing een draadloze router aan.

Helaas kon na een reboot zomaar NIC0 niet meer eth0 zijn, waardoor mijn firewall en qos over de zeik gingen.
Met udev was dit inderdaad mooi op te lossen.
Ik heb nu geen eth0/1/2 meer, maar de interfaces heten gewoon NIC0/1/2 en met die namen werk ik in mijn scripts.

EDIT:
Ik heb nog even opgezocht wat ik doe in mijn local udev rules
KERNEL=="eth*", ATTR{address}=="00:02:a5:a8:05:21", NAME="NIC0"
KERNEL=="eth*", ATTR{address}=="00:50:bf:b6:79:6a", NAME="NIC1"

Ik weet eigenlijk niet of je daar ook eth0 aan toe kan wijzen ipv NIC0.

[ Voor 25% gewijzigd door FireAge op 01-12-2009 18:04 ]

[Sir Isaac]

Eth0 bestaat niet als'ie eth1 is. Ik zal eens in udev kijken, maar een configuratiefile verandert ook niet zo maar.

[moto-moi]

http://wiki.debian.org/udev#persistent-name zou dat op moeten lossen lijkt me Ik had een soortgelijk probleem op mijn desktop, maar daar is het 'opeens' gestopt. Geen idee waarom, maar daar werkt eth8 al maanden goed

[Sir Isaac]

Ik had al zo'n vermoeden dat het in de udev rules zat. De oplossing van de debian wiki vind ik alleen een beetje lomp. Deze oplossing zorgt alleen dat een specifiek device altijd dezelfde device naam krijgt. Handig als je 3 NICs hebt, maar ik zou liever hebben dat mijn eerste/enige netwerkkaart gewoon eth0 heeft. In ieder geval kan ik dit proberen als het probleem zich weer voordoet.

[burne]

Sir Isaac schreef op dinsdag 01 december 2009 @ 14:13:
mijn eerste/enige netwerkkaart gewoon eth0 heeft

Wat zegt

code:

ifconfig -a

?

[moto-moi]

Sir Isaac schreef op dinsdag 01 december 2009 @ 14:13:
Handig als je 3 NICs hebt, maar ik zou liever hebben dat mijn eerste/enige netwerkkaart gewoon eth0 heeft.

ach, je kan er ook ethexternal van maken, of de naam van je vriendin, dat boeit verder niet, zolang 'ie maar hetzelfde is na een reboot zodat ubuntu de juiste interface up gooit.

[DeKaerften]

Gewoon de device een andere naam geven, is natuurlijk een work-around en niet een oplossing. Als er geen andere devices bestaan, die als nic fungeren, móet eth0 gebruikt worden voor de eerste (enige) nic.

Ik zou het in ieder geval als bug aanmelden bij de beheerder van de package/upstream. Daarvoor is het echter wel nodig, dat meer informatie bekend is, zoals de situaties waarin het probleem zich voordoet.

[d1ng]

De namen eth0, eth1, eth2 enz. worden aan je device gegeven aan de hand van de volgorde waarin ze 'gevonden' worden.
Echter, als er geen interface gegeven kan worden aan je eerste netwerkkaart, dan is de naam eth0 al bezet en dan zou de device de naam eth1 kunnen krijgen. (Althans, als ik het goed begrepen heb, is dit geen bug maar 'normaal' gedrag)

Maar, met maar 1 netwerkkaart is dat natuurlijk wel erg vreemd.
In ieder geval, een andere naam geven is een oplossing.

Als je wat leesvoer wilt hebben, even googlen op 'Persistent Interface Name' o.a.

[MisterE]

GuitarWeed schreef op dinsdag 01 december 2009 @ 15:01:
Gewoon de device een andere naam geven, is natuurlijk een work-around en niet een oplossing. Als er geen andere devices bestaan, die als nic fungeren, móet eth0 gebruikt worden voor de eerste (enige) nic.

Namen worden niet hergebruikt. Bij onthoud waar de teller gebleven is. Op zich logisch. als je bijv. 2 kaarten erin hebt eth0 en eth1, en je zou 0 eruit halen dan zou 1 in jouw geval 0 worden.
De topicstarter heeft ergens een probleem gehad dat de teller bij herstarten deed verhogen, en dat is natuurlijk niet de bedoeling

[MartinMeijerink]

Check /var/log/messages eens op het moment dat je netwerkkaart weer eth1 is. Misschien dat daar aanwijzingen in wat er dan eth0 is geworden? Misschien de onboard netwerkkaart die je in het bios hebt uitgeschakeld, en die dan toch gevonden wordt?

[e_var]

Wanneer je een eth1 krijgt, lijkt het me dat er ook nog een eth0 rondzweefd.

Wat geeft lspci aan?

Stel, je hebt twee nics, gebruiken ze dezelfde modules?

[Sir Isaac]

Mijn computer draait al weer een poosje stabiel op eth1. Hij heeft geen on-board nic en er zit maar 1 kaart in. Heel vreemd.

dmesg | grep eth
[   51.785676] eth0: VIA Rhine III at 0xdffffe00, 00:17:9a:bc:bc:dc, IRQ 11.
[   51.786395] eth0: MII PHY found at address 1, status 0x786d advertising 05e1 Link 45e1.
[   74.687793] udev: renamed network interface eth0 to eth1
[   75.982960] eth1: link up, 100Mbps, full-duplex, lpa 0x45E1
[   86.040073] eth1: no IPv6 routers present

lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333]
00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333 AGP]
00:08.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 62)
00:08.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 62)
00:08.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 65)
00:09.0 Ethernet controller: VIA Technologies, Inc. VT6105/VT6106S [Rhine-III] (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8233 PCI to ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:11.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 18)
00:11.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 18)
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 10)
01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 MX 440] (rev a3)

Hij ziet dus maar een ethernet controller, de VIA Rhine III kaart, maar wordt die tijdens het boot proces door udev hernoemd naar eth1. Waarom zou dat gebeuren?
De lspci -vv kun je hier bekijken.

[ Voor 5% gewijzigd door Sir Isaac op 05-12-2009 22:46 ]

[MartinMeijerink]

Wat staat er in /etc/udev/rules.d/70-persistent-net.rules?
Eigenlijk is dit de oplossing al, er staat hier volgens mij nog een andere netwerkkaart, die hier eth0 wordt genoemd.
Verder staat er in ieder geval de regel:
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:17:9a:bc:bc:dc", NAME="eth1"
hier krijgt dus jouw netwerkkaart de naam eth1

[a casema user]

Kan je de interface niet koppelen aan je MAC adres ?

pre-up /path/to/check-mac-address.sh eth0 11:22:33:44:55:66

http://www.cyberciti.biz/...-network-interfaces-file/

[lintweaker]

Is het niet makkelijk om ouderwets de ifcgh-ethX file aan te passen? Kun je de udev rules e.d. met rust laten. Bij fedora staan deze files in /etc/sysconfig/network-scripts/. In ifcfg-ethX kun je met HWADDR= vast zetten op een MAC adres. E.e.a. kan ook grafisch geconfigureerd worden.

[Sir Isaac]

Martin Meijerink had gelijk. In mijn /etc/udev/rules.d/70-persistent-net.rules staat (stond):

code:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:17:9a:bc:bc:dc", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

Die regel heb ik maar even uitgecommentarieerd.
@lintweaker: dat is denk ik een redhat configuratie.

Edit:
Het commentaarteken in de udev rules file wordt weer verwijders! Welk lollig programma denkt dat 'ie dat mag doen? /etc/udev/rules.d is toch juist voor lokale configuratie door de gebruiker.

[ Voor 22% gewijzigd door Sir Isaac op 08-12-2009 00:45 ]

[FireAge]

Sir Isaac schreef op dinsdag 08 december 2009 @ 00:29:
Martin Meijerink had gelijk. In mijn /etc/udev/rules.d/70-persistent-net.rules staat (stond):

Edit:
Het commentaarteken in de udev rules file wordt weer verwijders! Welk lollig programma denkt dat 'ie dat mag doen? /etc/udev/rules.d is toch juist voor lokale configuratie door de gebruiker.

Nee, dat is 10-local.rules, althans die heb ik gekozen.
Persistent lijkt me iets wat aangepast wordt door een ander programma.

Als je nu die persistent aanpast om er eth0 van te maken?

[ Voor 5% gewijzigd door FireAge op 08-12-2009 07:34 ]

[BCC]

Debian genereert die persistancy configuratie autmatisch on boot als deze mist. Daar gebeuren soms nog wel eens onverwachte dingen. By default zorgt hij ervoor dat als er geen configuratie is, er een stabiele configuratie komt. Tijdens het booten heb jij een eth0 en geen configuratie (is uitgecommentaard). Hij detect dan een "nieuwe" netwerkkaart, want er zijn nog geen persistancy rules voor en zet die op de eerste vrije eth, namelijk eth1. Vervolgens persist hij dit netjes in de configuratie.

[Sir Isaac]

Afgelopen weekend heb ik mijn moederbord vervangen. Mijn nieuwe heeft een onboard lan, dus heb ik mijn oude nic weggelaten. Raad eens: mijn netwerk interface heet eth2 terwijl hij toch echt de enige is. Blijkbaar onthoudt udev ergens dat er in het verleden twee andere nics zijn geweest en reserveert hij de aanduidingen eth0 en eth1 voor hen.
Persistentie is ideaal als je meerdere nics hebt die steeds dezelfde naam moeten hebben, maar dit is een beetje te persistent voor mij: zo moet je de configuratie aanpassen als je een nic vervangt. Weet iemand waar udev die informatie opslaat? Ik heb in /var/ naar udev gerelateerde zaken gezocht, maar niet gevonden dat met ethernet devices te maken heeft.

[Verwijderd]

De hele udev configuratie van je netwerk kaarten staat in: /etc/udev/rules.d/70-persistent-net.rules

Je kunt dit bestand naar wens aanpassen bijv. door de mac adressen van de verschillende devices om te draaien. Je kunt dit bestand ook weggooien, als je dit laatste doet zal je zien dat dit bestand weer na een reboot netjes wordt aangemaakt.

[Sir Isaac]

edit:
te snel geschreven

[ Voor 94% gewijzigd door Sir Isaac op 22-12-2009 22:35 ]

[Raven]

Sorry voor de kick, maar om nou een nieuw topic te openen voor onderstaande vraag is ook zoiets.

Bestaat dit "gedrag" in de huidige versies van Ubuntu (Server) nog steeds? Ik weet wel van udev (een stukje naar boven staat dat deze automatisch aangemaakt wordt?, dacht dat dat handmatig moest), maar dat zie ik als workaround, niet als een fix.

[ Voor 16% gewijzigd door Raven op 30-08-2011 20:40 ]

[Snow_King]

Geen idee of het nog bestaat, want udev doet het al tijden hartstikke goed!

udev geeft een NIC op basis van zijn MAC-Adres een ethX naam en die is persistent. Onder Debian en Ubuntu werkt dit al een tijd zo, maar ik meen (correct me if wrong) onder CentOS/RHEL ook al een tijdje.

De onderliggende reden van het flappen van de NIC's weet ik niet, maar udev neemt al die problemen nu weg en zorgt voor consistentie

[Raven]

Okee

Dat kwam door de volgorde van herkennen tijdens het opstarten, die is/was niet altijd hetzelfde.