Discussion:
Mielenkiintoinen ongelma linuxissa lisätessä verkkokortteja
(too old to reply)
Elias
2017-12-21 18:12:34 UTC
Permalink
Terve
Lisäilimpä tuossa palvelimeen joka pyörittää proxmoxia muutaman
verkkokortin lisää. Ennen siis käyttänyt emolevyn integroitua
ensisiaisena verkkokorttina ja tottakai oletin että se pysyisi
oletuksena kun serveri käynnistetään uudelleen. Käynnistin palvelimen ja
ihmettelin miksi masiinaan ei saa ssh yhteyttä. Päätimpä heittää
kaapelin toiseen verkkokorttiin ja ssh kirjautumiskehote tuli näytölle
ja homma toimi. Menimpä katsomaan seuraavaksi /etc/network/interfaces
tiedostosta mitä nyt on oikein sekoiltu. Tuo integroitu verkkokortti oli
siis järjestelmässä aikaisemmin nimellä enp3s. Nyt ensisiaiseksi
verkkokortiksi täsmälleen samalla nimellä oli vaihtunut tuo intelin
verkkokortti. Ip link show komennon jälkeen sain selville että
integroidun nimi jonka kautta hallintayhteys pitäisi muodostaa oli
vaihtunut enp4s:ksi. Miten tuo ylipäätään voi olla mahdollista. Että
verkkokortit vaihtuvat itsekseen. Sekä niiden nimet muuttuvat.
Järjestelmänä proxmox5.0 joka perustuu debian stretchiin. Itsellä tunne
että saattaisi systemd jotain sekoilla. Tarkoituksena hyödyntää
lisättyjä verkkokortteja lacp:llä leikkimiseen. Sekä rakentaessa lisää
verkkoja joihin voin pistää eri virtuaalikoneita. Masiinan
hallintayhteys kulkee nyt konfiguraatiomuutosten jälkeen integroidun
verkkokortin kautta.
Mikko Saukkoriipi
2017-12-22 12:16:19 UTC
Permalink
Post by Elias
Terve
Lisäilimpä tuossa palvelimeen joka pyörittää proxmoxia muutaman
verkkokortin lisää. Ennen siis käyttänyt emolevyn integroitua
ensisiaisena verkkokorttina ja tottakai oletin että se pysyisi
oletuksena kun serveri käynnistetään uudelleen. Käynnistin palvelimen ja
ihmettelin miksi masiinaan ei saa ssh yhteyttä. Päätimpä heittää
kaapelin toiseen verkkokorttiin ja ssh kirjautumiskehote tuli näytölle
ja homma toimi. Menimpä katsomaan seuraavaksi /etc/network/interfaces
tiedostosta mitä nyt on oikein sekoiltu. Tuo integroitu verkkokortti oli
siis järjestelmässä aikaisemmin nimellä enp3s. Nyt ensisiaiseksi
verkkokortiksi täsmälleen samalla nimellä oli vaihtunut tuo intelin
verkkokortti. Ip link show komennon jälkeen sain selville että
integroidun nimi jonka kautta hallintayhteys pitäisi  muodostaa oli
vaihtunut enp4s:ksi. Miten tuo ylipäätään voi olla mahdollista. Että
verkkokortit vaihtuvat itsekseen. Sekä niiden nimet muuttuvat.
Järjestelmänä proxmox5.0 joka perustuu debian stretchiin. Itsellä tunne
että saattaisi systemd jotain sekoilla. Tarkoituksena hyödyntää
lisättyjä verkkokortteja lacp:llä leikkimiseen. Sekä rakentaessa lisää
verkkoja joihin voin pistää eri virtuaalikoneita. Masiinan
hallintayhteys kulkee nyt konfiguraatiomuutosten jälkeen integroidun
verkkokortin kautta.
Tämä artikkeli selittää mikä näissä nimissä on kyseessä.

Predictable Network Interface Names
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
Ari Saastamoinen
2017-12-22 12:56:46 UTC
Permalink
Post by Mikko Saukkoriipi
on oikein sekoiltu. Tuo integroitu verkkokortti oli siis
järjestelmässä aikaisemmin nimellä enp3s. Nyt ensisiaiseksi
verkkokortiksi täsmälleen samalla nimellä oli vaihtunut tuo
intelin verkkokortti. Ip link show komennon jälkeen sain selville
että integroidun nimi jonka kautta hallintayhteys pitäisi 
muodostaa oli vaihtunut enp4s:ksi. Miten tuo ylipäätään voi olla
Tämä artikkeli selittää mikä näissä nimissä on kyseessä.
Predictable Network Interface Names
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
Paitsi, että tuon artikkelin perusteella, laitenimen nimenomaan EI
olisi pitänyt muuttua, joten sinänsä tuo artikkeli vastaa kysyjän
ongelmaan huonosti.

Itse olen käyttänyt sitä, että udev:n ruleihin olen aina kertonut,
että minkä llaitteen haluan millekin nimelle, mutta saattaa olla, että
tuota käytäntöä pitää muuttaa nyt systemd on alkanut assimiloimaan
muuta maailmaa rikkoen toimivat järjestelmät. (En edelleenkään
ymmärrä, että mitä hienoa on binaariformaatissa olevissa logeissa,
miksi login pitäisi muka olla systeemin käynnistyspalikan hommia,
miksi ntpd on pitänyt tehdä itse uudestaan, mutta huonommin jne...)

PS. Follarit laitettu s.a.linux:iin, kun tää nyyssiserveri (tai sitten
nyytistinohjelma, en jaksanut tutkia kumpi) kieltäytyy postaamasta
näin moneen ryhmään ilman follarimäärittelyä.
--
Arzka oh3mqu+***@hyper.fi - En halua follareita mailina
1. Valitse sopiva paikka, ei ihmisten tai rakennusten lahella, jossa
paukku voi aiheuttaa hairiota. - Iso-Kiinalaisen kayttoohje
Anssi Saari
2017-12-22 14:18:18 UTC
Permalink
Post by Ari Saastamoinen
Paitsi, että tuon artikkelin perusteella, laitenimen nimenomaan EI
olisi pitänyt muuttua, joten sinänsä tuo artikkeli vastaa kysyjän
ongelmaan huonosti.
No toisaalta, siellähän sanotaan "Stable interface names even when
hardware is added or removed, i.e. no re-enumeration takes place (to the
level the firmware permits this)". Eli siis, vakaat nimet jos
firmikselle sopii. Aika erikoista kyllä jos tuo tarkoittaa että
verkkokorttien lisääminen on jotenkin saanut koneen järjestämään
PCI-väylät uuteen uskoon. Mielenkiintoista olisi tietää näkyisikö
lspci:n tulostuksessa ennen ja jälkeen verkkokorttien lisäämistä jotain
mikä tuon selittäisi.
Elias
2017-12-23 10:44:14 UTC
Permalink
Post by Anssi Saari
Post by Ari Saastamoinen
Paitsi, että tuon artikkelin perusteella, laitenimen nimenomaan EI
olisi pitänyt muuttua, joten sinänsä tuo artikkeli vastaa kysyjän
ongelmaan huonosti.
No toisaalta, siellähän sanotaan "Stable interface names even when
hardware is added or removed, i.e. no re-enumeration takes place (to the
level the firmware permits this)". Eli siis, vakaat nimet jos
firmikselle sopii. Aika erikoista kyllä jos tuo tarkoittaa että
verkkokorttien lisääminen on jotenkin saanut koneen järjestämään
PCI-väylät uuteen uskoon. Mielenkiintoista olisi tietää näkyisikö
lspci:n tulostuksessa ennen ja jälkeen verkkokorttien lisäämistä jotain
mikä tuon selittäisi.
lspci:n tuloste tässä. EN nopealla tsekkauksella huomannut ainakaan
mitään erikoista
lspci

00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3 Processor DRAM
Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core
Processor PCI Express x16 Control
ler (rev 06)

00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3
Processor Integrated Graphics C
ontroller (rev 06)

00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core
Processor HD Audio Controller (
rev 06)

00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
Family USB xHCI (rev 05)
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series
Chipset Family MEI Controll
er #1 (rev 04)

00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
Family USB EHCI #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset
High Definition Audio Controlle
r (rev 05)

00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset
Family PCI Express Root Port #1 (
rev d5)

00:1c.1 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset
Family PCI Express Root Port #2 (
rev d5)

00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset
Family PCI Express Root Port #3 (
rev d5)

00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
Family USB EHCI #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation B85 Express LPC Controller (rev
05)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset
Family 6-port SATA Controlle
r 1 [AHCI mode] (rev 05)

00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family
SMBus Controller (rev 05)
01:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic
SAS2008 PCI-Express Fusion-MPT SA
S-2 [Falcon] (rev 03)

02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network
Connection
03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network
Connection
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit E
thernet Controller (rev 0c)
Mikko Tuumanen
2017-12-23 11:55:10 UTC
Permalink
Post by Anssi Saari
firmikselle sopii. Aika erikoista kyllä jos tuo tarkoittaa että
verkkokorttien lisääminen on jotenkin saanut koneen järjestämään
PCI-väylät uuteen uskoon. Mielenkiintoista olisi tietää näkyisikö
Minulla on käytössä eräs Asrock-emolevy, jossa sata-laitteen
ottaminen biosista käyttöön/pois käytöstä, numeroi pci-väylät uudestaan.
Mm. näytönohjainten numerointi vaihtuu sen seurauksena ja xorg.confin
"BusID PCI:X:Y"-rivit menevät pieleen.

Sama voi siis aivan hyvin tapahtua myös verkkokorttien kanssa. Oliskin
mielenkiintoista tietää, miksi tällaista tapahtuu. Onko esim. muuttuva
numerointi jotenkin helpompi toteuttaa kuin kiinteä?
Anssi Saari
2017-12-28 13:12:47 UTC
Permalink
Post by Mikko Tuumanen
Post by Anssi Saari
firmikselle sopii. Aika erikoista kyllä jos tuo tarkoittaa että
verkkokorttien lisääminen on jotenkin saanut koneen järjestämään
PCI-väylät uuteen uskoon. Mielenkiintoista olisi tietää näkyisikö
Minulla on käytössä eräs Asrock-emolevy, jossa sata-laitteen
ottaminen biosista käyttöön/pois käytöstä, numeroi pci-väylät uudestaan.
Mm. näytönohjainten numerointi vaihtuu sen seurauksena ja xorg.confin
"BusID PCI:X:Y"-rivit menevät pieleen.
Kaipa sitä voi sitten olettaa että tuosta on kyse Eliaksenkin
tapauksessa vaikkei hän sitä "ennen" lspci:n tulostusta postannutkaan.
Teemu Likonen
2017-12-23 06:56:36 UTC
Permalink
Post by Ari Saastamoinen
Itse olen käyttänyt sitä, että udev:n ruleihin olen aina kertonut,
että minkä llaitteen haluan millekin nimelle, mutta saattaa olla, että
tuota käytäntöä pitää muuttaa nyt systemd on alkanut
Näin: /etc/systemd/network/omanetti.link:

[Match]
# Verkkolaitteen MAC-osoite
MACAddress=00:a0:de:63:7a:e6

[Link]
# verkkolaitteen nimi
Name=omanetti0

Lisätietoa: "man systemd.link".
--
/// Teemu Likonen - .-.. <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///
Nospam
2017-12-23 09:14:54 UTC
Permalink
Post by Teemu Likonen
Post by Ari Saastamoinen
Itse olen käyttänyt sitä, että udev:n ruleihin olen aina kertonut,
että minkä llaitteen haluan millekin nimelle, mutta saattaa olla, että
tuota käytäntöä pitää muuttaa nyt systemd on alkanut
[Match]
# Verkkolaitteen MAC-osoite
MACAddress=00:a0:de:63:7a:e6
[Link]
# verkkolaitteen nimi
Name=omanetti0
Lisätietoa: "man systemd.link".
Täytyykö olla systemd-networkd käytössä että tuo toimisi?

BR, Nospam
Teemu Likonen
2017-12-24 06:56:10 UTC
Permalink
Post by Nospam
Post by Teemu Likonen
[Match]
# Verkkolaitteen MAC-osoite
MACAddress=00:a0:de:63:7a:e6
[Link]
# verkkolaitteen nimi
Name=omanetti0
Lisätietoa: "man systemd.link".
Täytyykö olla systemd-networkd käytössä että tuo toimisi?
Ei tarvitse, mutta ainakin Debianissa täytyy suorittaa

update-initramfs -u -k all

ennen kuin asetus tulee voimaan tietokoneen käynnistyksen yhteydessä.

Alkuperäisessä esimerkissäni annoin huonon nimen tiedostolle
(omanetti.link). Oletusasetukset ovat tiedostossa
/lib/systemd/network/99-default.link, ja koska asetustiedostot
käsitellään aakkosjärjestyksessä, pitäisi omat asetukset sijoittaa
aakkosissa aiemmaksi, esimerkiksi:

/etc/systemd/network/10-oma.link
--
/// Teemu Likonen - .-.. <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///
Nospam
2017-12-26 15:50:07 UTC
Permalink
Post by Teemu Likonen
Post by Nospam
Post by Teemu Likonen
[Match]
# Verkkolaitteen MAC-osoite
MACAddress=00:a0:de:63:7a:e6
[Link]
# verkkolaitteen nimi
Name=omanetti0
Lisätietoa: "man systemd.link".
Täytyykö olla systemd-networkd käytössä että tuo toimisi?
Ei tarvitse, mutta ainakin Debianissa täytyy suorittaa
update-initramfs -u -k all
ennen kuin asetus tulee voimaan tietokoneen käynnistyksen yhteydessä.
Alkuperäisessä esimerkissäni annoin huonon nimen tiedostolle
(omanetti.link). Oletusasetukset ovat tiedostossa
/lib/systemd/network/99-default.link, ja koska asetustiedostot
käsitellään aakkosjärjestyksessä, pitäisi omat asetukset sijoittaa
/etc/systemd/network/10-oma.link
Hmm... minulla ei ole systemd-networkd asenettuna, eikä löydy
(oletuksena) myöskään /etc/systemd/network tai /lib/systemd/network
hakemistoja. Olisiko tuo kuitenkin systemd-networkd riippuvainen juttu?

Mulla Centos 7.x.

BR, Nospam
Kai Tujula
2017-12-26 18:54:32 UTC
Permalink
Post by Nospam
Hmm... minulla ei ole systemd-networkd asenettuna, eikä löydy
(oletuksena) myöskään /etc/systemd/network tai /lib/systemd/network
hakemistoja. Olisiko tuo kuitenkin systemd-networkd riippuvainen juttu?
Homman voi hoitaa myös ehkä udev:n avulla. Miulla on tiedostossa
"/etc/udev/rules.d/10-network.rules" rivit:
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:e0:4c:80:06:66" , NAME="maailma"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1b:0d:66:06:66" , NAME="koti"

Tässä systeemissä ei verkkokortin nimet muutu buuttausten välillä.

kt
Jouko Holopainen
2018-01-16 03:42:23 UTC
Permalink
Post by Ari Saastamoinen
Itse olen käyttänyt sitä, että udev:n ruleihin olen aina kertonut,
että minkä llaitteen haluan millekin nimelle, mutta saattaa olla, että
tuota käytäntöä pitää muuttaa nyt systemd on alkanut assimiloimaan
muuta maailmaa rikkoen toimivat järjestelmät. (En edelleenkään
ymmärrä, että mitä hienoa on binaariformaatissa olevissa logeissa,
miksi login pitäisi muka olla systeemin käynnistyspalikan hommia,
miksi ntpd on pitänyt tehdä itse uudestaan, mutta huonommin jne...)
Tämähän kuulostaa ihan pulseaudiolta. Eli kuinka lip-sync tuhotaan
kymmeneksi vuodeksi. Ehkä 2020 lip-sync toimii?
--
@jhol

www.iki.fi/jhol
Loading...