Fedora 15 mudará a nomenclatura de placas de rede
Enviado por Nícolas Wildner[Ironmaniaco] (nicolasgauchoΘgmail·com):
O esquema de nomes ethX funciona de forma satisfatória para sistemas que possuem apenas uma porta Ethernet. Contudo, se mais de uma porta Ethernet é instalada, uma série de “race conditions” podem acontecer durante o processo de inicialização, e os nomes podem ser trocados. Não há uma forma “consistente” de que se mantenha eth0 e eth1 nomeadas corretamente até o próximo reboot. Os nomes são alocados de forma arbitrária, e não é um comum em computadores pessoais, visto que eles só possuem uma interface. Entretanto, este tipo de problema, pode ser uma dor de cabeça em servidores com mais de 1 porta Ethernet.
Para garantir que os dispositivos manterão o mesmo nome, independente de reboot ou não, a Dell desenvolveu uma ferramenta chamada biosdevname. O biosdevname renomeia as interfaces Ethernet de acordo com a informação presente na BIOS. Isto, contudo, impede a utilização do esquema de nomeação antigo.
De acordo com Matt Domsch, o novo esquema será representado da seguinte forma:
* em[1-N] para placas onboard
* pci[slot] para placas PCI
* Dispositivos NPAR & SR-IOV adicionam o sufixo _[vf], de 0..N dependendo do numero de funções ou partições virtuais expostas em cada dispositivo.
* Outras convenções do linux como por exemplo vlan e :alias, continuam sendo aplicadas.
O novo esquema de nomenclatura é um pouco mais complicado que o esquema ethX, porém não fará muita diferença em computadores pessoais que possuem apenas uma porta Ethernet. E mais, estas mudanças não afetarão os dispositivos Wireless e USB. Mais informações no Link de referência.” [referência: digitizor.com]
@brlinuxblog
Feed RSS
10 anos configurando servidores linux com várias interfaces e NUNCA tive problema… talvez seja pq eu nunca usei o Fedora =)
Também trabalho com servidores a mais de 10 anos e nunca tive problemas com a nomenclatura das eth e também sempre utilizei várias interfaces, para mim isto é desculpa de joão sem braço. Não sabem como resolver um problema que é deles, então é melhor inventar outra coisa.
Lamentável
sempre utilizei ethXX e nunca deu nada. sempre “amarro” a eth com o mac da placa. nunca deu de inverter as placas em um reboot.
já vi esse caso acontecer, mas não tinha o mac configurado para a interface.
Já vi acontecer de algumas máquinas trocar a orden da nomenclatura das placas de rede.
Mas já tem algum tempo que existe uma maneira de fixar os nomes do tipo ethX no /etc/udev/rules.d/70-persistent-net.rules para quem usa Debian/Ubuntu. E isso sem precisar aplicar nenhuma nomenclatura nova do jeto que os desenvolvedores do Fedora estão querendo fazer.
@ Adilson
Foi exatamente o que eu iria escrever. Em 29 de setembro de 2009 fiz um relato baseado em uma experiência quando atualizei para o Xubuntu 9.04 (partindo do 8.10) e tive o desprazer de notar que eth0 e eth1 tinham sido invertidas. Não lembro agora se foi na migração do devfs para udev ou se foi outra “chupada de bala”.
Trabalho com servidores há 8 anos e nunca tive problemas com placas de rede no reboot. Acontece de eth0 se tornar eth1 e vice-versa na reinstalação do sistema, mas no reboot NUNCA aconteceu comigo. Eu também nunca usei Fedora. Pra mim esta mudança parece desnecessária.
O udev já não resolveu esse problema a anos?
Faço minhas as palavras do Alexandre… Mas se a mudança vir para melhor, tranquilo…
Bom… Como todo mundo aí disse acima, também trabalho com redes há mais de 10 anos, e do contrario da maioria JÁ nos aconteceu várias vezes de se inverterem os nomes das placas. Claro que nao falo de 2 placas somente, mas experimente colocar 3 placas de 5 canais cada em um servidor com linux… experimente ainda uma queda de energia sem nobreak… Pior ainda se a bios “resolver” mudar uma tal de tabela de ESCD (digo resolver pq isso é beeem aleatório) Aí meu caro é um pandemônio de interfaces! Coisas de IRQs com TPM e endereços de memória que esquecem onde moram. Esse cenário já faz uns 09-11 anos em época de pentium II e placa ISA. Como resolvi? Usei Netbsd. Esse tipo de abordagem já é usado faz séculos por lá. Não com o mesmo conceito, mas pelo menos pra mim resolveu!
Em sistemas Solaris, a nomenclatura da placa de rede varia conforme o fabricante. Assim, uma placa com chipset Sis900, por exemplo, é nomeada como sis1 ou similar. Seria interessante se o Linux fosse por esse caminho: ia padronizar mais as coisas.
Para quem usa BSD, onde o nome varia de acordo com o fabricante (e modelo) pode não fazer muita diferença.
Agora pense em quem for atualizar o Fedora desavisado e as regras do iptables deixarem de funcionar.
Vamos ver o que vai dar…
Lamentável é ter que aturar reclamações por causa de uma simples padronização de nomes. Isso lá é coisa pra se fazer um cavalo de batalha? Se tiver que mudar, que mude. Aliás, se vc não usa Fedora ou não se sentiu confortável com a notícia, guarde suas críticas para si. Aliás², se fosse a Canonical que decidisse isso, vcs estariam soltando fogos, né?
@André Machado @Zhu Sha Zang
Por padrão as interfaces nos sistemas Unix/Unix-like que vocês citaram têm nomes relacionados com o Driver que elas estão usando, porém isso é o Default, mas desde a época do “sco hanbook” (coisa velha) que a recomendação é alterar o nome da interface para o que for mais adequado (lan0,wan0,dmz0,gig0). Assim seu script de firewall não sofre quando você troca de interface ou de máquina.
Já tive problemas com interface de redes e conversores USB-ethernet, Mas como foi dito, o udev resolveu o problema. A solução automática do udev no Ubuntu, foi atrelar a interface ao MAC address. Como eu tinha 2 conversores em duas portas USB e nunca altero de porta, fiz uma regra para associar o dispositivo eth à porta USB.
Acho que o udev soluciona bem esse tipo de problema, e caso haja uma necessidade mais avançada do que associar o dispositivo eth ao MAC, o udev tem mecanismos para resolver.
Comecei com servidores frebsd e não tinha problemas. Depois passeia a usar servidores Linux e tive este tipo de problema em um servidor com várias placas de rede. Mas, depois de algumas atualizações, amarração MAC, udev e outras coisas, não sei mais o que é isso. Eu sempre mudo os nomes das placas de rede para facilitar minha vida e fica tudo como deixei. Mas, ultimamente são apenas duas placas de rede, um bom switch, alguns roteadores e pronto.
Os sistemas derivados pelo Red Hat, pelo que sei, usam um arquivo chamado /etc/iftab que possui um conteúdo do tipo
eth0 mac 00:1e:c9:1d:82:1d
…
onde é amarrado o nome de cada ethX ao respectivo MAC. Qual é o problema com essa abordagem ?!
Bom, taí mais um motivo pra eu continuar longe, bem longe do fedora.
No FreeBSD o esquema é parecido, mas lá isso é padrão há muito tempo. É usado o fragmento do nome do módulo da placa de rede para nomeá-la.
Legal é ler comentários de alguns: Tem que ser o Fedora mesmo pra dar esse problema.
quando não tem nada haver com o fedora. lamentável essa turminha do u…..
Talvez o Ubuntu, Opensuse/Suse e Red Hat adotem: http://www.networkworld.com/community/fedora-15-changes-network-device-naming
Bom, vamos supor que esse problema aconteça mesmo quando existem mais placas.
Que impacto teria na compatiblidade entre as outras distribuições Linux? Algum programa vai precisar gerar pacote específico? Algum script não seria mais portável entre Fedora e outra distro?
Se ajudar, *e* que isso vire um padrão entre as distros, não vejo problema…
@ Marcos
Só se seus scripts referenciem eth0, eth1, etc. Quem faz assim terá que rescreve-los.
O FreeBSD faz algo parecido.. :D
ln -s /dev/$MINHA_PLACA_DE_REDE_COM_NOME_ESQUISITO /dev/eth0
Vai ser assim que serão resolvidos os casos de incompatibilidade com o Fedora. BTW, a grande maioria citou que trabalha com servidores há X anos, mas quem em sã consciência colocaria o Fedora em um servidor? O Fedora é conhecido como plataforma de testes para novas tecnologias, estabilidade não é e nunca vai ser o foco da distribuição. Como está no artigo, quem usa Fedora são as pessoas que só tem uma placa de rede no sistema mesmo.
Vai ser legal daqui a uns meses quando o Ubuntu usar o mesmo padrão, todo mundo aqui dizendo que isso é a oitava maravilha do mundo.
Pera aí, Fedora = Desktop.
Quem tá usando Fedora ou Ubuntu pra SERVER que me perdoe !!!
Uso o Fedora no Desktop e posso afirmar que logo logo a Canonical vai seguir a mesma ideia.
persistent-net.rules rola no Fedora também …
Coisa mais comum é ver script com “eth0″, “eth1″.
Seria legal se a nomeclatura funcionar como em outros *nix, em que a nomeclatura da placa varia com o fabricante.
Da uma facilitada mostro na hora de editar scripts.
Já to vendo mimimi do povão que faz script com “eth0″, “eth1″.
Eu até tinha um script assim, mas era para fazer uma clonagem do mac.
Nada que uma alteração simples nos arquivos de cfg não faça.
“Não há uma forma “consistente” de que se mantenha eth0 e eth1 nomeadas corretamente até o próximo reboot.”
Como não? udev.
É cada idéia viu… uma é insistir no yum, outra agora é mudar o que está bom.
Uso o Fedora e não gostei nada dessa mudança. Se o foco do Fedora é desktop porque fazer isso, só vai complicar mais, até porque é raro ver um desktop com mais de uma interface de rede ativa.
O que falei em outro comentário, repito aqui, este tipo de atitude que toma uma distribuição enfraquece o Linux, fica mais difícil dar suporte, as coisas mudam muito de uma distribuição para a outra.
Agora se isso fosse feito em comum acordo entre as grandes distribuições ai até concordaria. Mesmo assim traria grandes transtornos.
* Pega o meu script la no meu site.
* E ai funcionou?
& Não, ta dando um erro.
* Mas o teu desktop é Fedora né.
& sim, Fedora 15.
* A esquece vou alterar o script porque no 15 mudou a nomenclatura.
-Se versão for < 15 faz isso se não faz aquilo.
Quando o benefício é grande até vale o trabalho, mas neste caso, como falou os colegas acima não.
Eu também sempre tomo cuidado de atrelar o MAC ao dispositivo, e no Debian, e utilizo os “alias” com o parametro “realdev” de /etc/network/interfaces.
Assim, minha placa externa sempre se chamará ext, a interna int e a de dmz, dmz.
Basta alterar o realdev caso o Linux “zoe com a sua vida” e altere as ethX.
Acho que esta nomenclatura nova ajudaria da seguinte forma:
Peguei um server da IBM(3200 Series), que possuia 2 placas Broadcom Nextreme II(onboards), e 1 da Dlink(slot PCI express).
O CentOS nomeia como eth0 e eth1 as da Broadcom, e eth2 a Dlink PCI Express. O Debian, pede a firmware do pendrive durante a instalação, e nomeia como eth0 a da Dlink, e eth1 e eth2 as da Broadcom(por ordem de instalação).
Talvez este biosdevname me ajude para que as da Broadcom sejam sempre em0 e em1, e a da Dlink, pci0 se todas as distros adotarem. Eu acho isto bacana ;)
Vai ser legal daqui a uns meses quando o Ubuntu usar o mesmo padrão, todo mundo aqui dizendo que isso é a oitava maravilha do mundo.
Pera aí, Fedora = Desktop.
Quem tá usando Fedora ou Ubuntu pra SERVER que me perdoe !!!
Uso o Fedora no Desktop e posso afirmar que logo logo a Canonical vai seguir a mesma ideia.
persistent-net.rules rola no Fedora também …
Diego, qual o problema em usar Ubuntu em servidor ? Ubuntu é uma mistura da árvore Testing e Unstable do Debian. O Ubuntu tem a versão LTS que é a mais apropriada para server.
Ironmaniaco,
é só amarrar o MAC a interface de rede, você está criando bonding ?
>>> Se o foco do Fedora é desktop porque fazer isso, só vai complicar mais
Se você ler a matéria toda, verá que pra desktop não fará a menooooooor diferença. Pura tempestade em copo d´água sua.
>>>> este tipo de atitude que toma uma distribuição enfraquece o Linux
Falaram a mesma coisa do PulseAudio, que funciona redondinho nos dias de hoje. Falarão sobre o upstart e o systemd, e depois que tiver redondinho, vai todo mundo esquecer este tipo de discussão
Porque?
Porque o Linux evoluiu ;)
>>> é só amarrar o MAC a interface de rede, você está criando bonding ?
Sim. Eu deixo amarrado o MAC para o eth0, eth1 e eth2 mas não faço bonding. Apenas crio nomenclaturas “amigaveis” para as interfaces, pra que nos meus scripts de firewall, eu não tenha que ficar criando coisas do tipo…
IFEXT=”eth0″
IFINT=”eth1″
IFDMZ=”eth2″
…eu simplesmente faço:
iptables -A FORWARD -i int
e não:
iptables -A FORWARD -i $IFINT
Ou ainda, pra comandos ficarem mais “dinâmicos” e não ter que decorar os ethX de meus clientes(que são vários firewalls administrados) na hora de usar ferramentas de rede:
# iftop -i int -P
Acho mais “limpo”. Só isso