48 www.linuxmagazine.com.br

REDES | Dispositivos de rede

Dispositivos de rede

A descoberta dos nomes de dispositivos

Dispositivos Ethernet no Linux sempre foram chamados de eth0 e nada mais. De repente, essa verdade universal perdeu a validade e os administradores Linux precisam entender o porquê disso ter acontecido.por Thorsten Scherf

Recentemente, um cliente me perguntou o que estava acon-tecendo com seu sistema. De

repente, ele não tinha mais uma co-nexão eth0; em vez disso, ele estava vendo nomes estranhos como em1 ou p3p1 no console. Ele queria saber exa-tamente o que estava acontecendo. A explicação é bastante simples. A re-gra do subsistema udev é responsável pela nomeação. Se todos os critérios para uma regra corresponderem a um dispositivo de rede encontrado no momento de boot, o dispositivo geralmente adota o nome definido, como eth<X>. Um exemplo seria:

# grep eth0 /etc/udev/rules.d/ 70‑persistent‑net.rules SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="f0:de:f1:d5 :c1:25",

ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

A regra diz que um dispositivo de rede com o endereço MAC declarado deve nomear um dispositivo como eth0 e, assim, ser o primeiro dispositivo visível no sistema. O nome do arquivo é arbi-trário. Se quisermos, podemos chamar esta conexão de pública ou privada. Este princípio funciona em determinadas situações. A desvantagem é que não sabemos exatamente qual conexão de rede será esta no sistema. A única coisa que fica clara é que se trata da conexão com o endereço MAC declarado; se

este também é o primeiro dispositivo de rede no sistema ainda não está cla-ro. Para administradores de sistema, esta situação sempre foi uma grande preocupação. Se o usuário já ficou na frente de um servidor com uma dúzia de portas de rede procurando por eth0, saberá exatamente o que queremos dizer.

Perigo de confusãoA situação é agravada em instalações de rede onde a solicitação de boot TFTP é enviada em eth0, mas o instalador depois envia a mensagem DHCPDISCO‑VER através de uma conexão de rede diferente identificada como eth0. Esta situação é muito propícia para a reso-lução de problemas. Queremos que o nome visto no sistema seja idêntico ao nome da conexão para que possa-mos visualizar diretamente se trata-se de uma porta de rede onboard ou de uma porta na placa PCI externa. No início de 2011, alguns desenvolvedores da Dell publicaram uma nova ferra-menta chamada biosdevname, sob a GPL. O biosdevname garante que o sis-tema do BIOS detecte o arranjo dos dispositivos de rede e passa esta infor-mação para o sistema operacional. O sistema operacional sabe, portanto, se esta é uma placa onboard ou um adap-tador PCI externo, e detecta a porta exata na placa-mãe ou na placa PCI. A nomenclatura, também conheci-da como Consistent Network Device Naming (Nomenclatura Consistente

de Dispositivo de Rede), então, segue esse padrão, cujos nomes onboard são:

emPort‑number_instance_of_ virtualFunction

(por exemplo, em1 para a primeira placa onboard). A situação para pla-cas PCI externas é:

pSlot‑NumberpPort‑number_instance_

of_virtual_function

(por exemplo, p2p1 para a primeira porta do NIC externo no slot 2).

Recursos virtuais são usados quando a placa de rede suporta Single Root I/O Virtualization (SR-IOV). Este recurso

RE

DE

S

Listagem 1: Interfaces virtuais de rede

# lspci | grep ‑i ether 07:00.0 Ethernet controller: Intel Corporation 82576

Gigabit Network Connection (rev 01)

# modprobe ‑r igb # modprobe igb max_vfs=2 # lspci | grep ‑i ether 07:00.0 Ethernet controller: Intel Corporation 82576

Gigabit Network Connection (rev 01)

07:10.0 Ethernet controller: Intel Corporation 82576

Virtual Function (rev 01) 07:10.1 Ethernet controller: Intel Corporation 82576

Virtual Function (rev 01)

49

| REDESDispositivos de rede

Linux Magazine #104 | Julho de 2013

permite dividir um único dispositivo PCI em vários sistemas virtuais sem sacrifi-car o desempenho. É então atribuída uma função virtual do dispositivo a um sistema virtual. Por exemplo, uma placa de rede com uma porta única aparece com múltiplas entradas na saída lspci no hypervisor (listagem 1).

A primeira entrada refere-se à fun-ção física da placa, e as outras duas referem-se às funções virtuais, cada uma das quais podendo ser passada para um sistema virtual com uma simples atribuição de PCI. Em um sistema com biosdevname habilitado, os

seguintes nomes de dispositivo existirão para a placa de rede já mencionada no slot do PCI 3: p3p1, p3p1_0, p3p1_1. A designação para a tecnologia de rede, tais como VLAN ou aliases, é mantida. Por exemplo, p3p1:0 designa um alias para o dispositivo de rede p3p1 com mais de um endereço IPv4.

Informações do BIOSO que informa ao sistema operacional em qual slot uma placa está conectada ou quais portas uma placa oferece? A resposta é bastante simples: o BIOS (nos sistemas atuais Dell e HP) armazena essas informações em duas tabelas: 9 (para placas PCI externas) e 41 (para placas onboard). O biosdevname sim-plesmente acessa as tabelas e grava as entradas correspondentes a uma nova regra udev. A regra é, então, responsável pelos novos nomes das placas de rede. Se o sistema não possuir uma versão atual do SMBIOS, ou se a informação estiver ausente das tabelas correspondentes, o biosdevname também pode acessar os da-dos da tabela de roteamento PCI IRQ.

As ferramentas dmidecode e bios‑decode fornecem esta informação na requisição. Alternativamente, o script da listagem 2 pode ajudar.

Novas regrasA figura 1 mostra o caminho de infor-mações do hardware para o aplicativo, que, em seguida, visualiza os nomes dos dispositivos definidos por biosdev‑name. A regra udev que implementa os nomes de dispositivo se parece com:# grep PROGRAM /lib/udev/ rules.d/71‑biosdevname.rules PROGRAM="/sbin/biosdevname ‑‑smbios 2.6

‑‑policy physical ‑i %k", NAME="%c",

OPTIONS+="string_escape=replace"

Podemos ver que o biosdevname atribui um novo nome ao dispositi-vo (%c) logo após o driver do kernel detectá-lo (%k). Se quisermos usar a nova nomenclatura no sistema, devemos primeiro executar o script acima para ver se o hardware for-nece a informação desejada. Em seguida, exclua o arquivo /etc/udev/rules.d/70‑persistent‑net.rules. Queremos que os nomes dos dispositivos venham de bios‑devname e não que sejam definidos estaticamente pela udev.

Finalmente, devemos renomear os arquivos de configuração para as placas de rede abaixo do diretório /etc/sysconfig/network‑scripts/ e alterar a entrada DEVICE para um novo nome. O Red Hat Enterpri-se Linux, a partir da versão 6.1, e o Fedora, a partir da versão 15, e as versões atuais do openSUSE, SUSE Linux Enterprise Server e Ubuntu já usam o novo critério de nomea-ção, e o instalador usa esses novos nomes durante a instalação. Se o usuário não puder ou não quiser mudar os scripts que apontam para eth<X>, poderá reverter para o modo antigo usando o parâmetro biosde‑vname=0 no momento do boot. n

Listagem 2: Verificação de hardware

# curl ‑s https:// fedoraproject.org/w/ uploads/3/38/

Biosdevname‑support‑check. sh | bash

Checking hardware requirements [ OK ]

Checking for SMBIOS type 41 support [ OK ]

Checking for SMBIOS type 9 support [ OK ]

Checking for PCI Interrupt Routing support [ OK ][

anaconda

Espaço do usuário

Firmware do sistema

ACPI SMBIOS

Kernel

sysfs

udev

biosdevname

dmidecode

em0, em1, p2p1...

gerenciador de rede seu aplicativo

Figura 2 Do hardware, via udev, para o aplicativo.

Gostou do artigo?Queremos ouvir sua opinião. Fale conosco em: cartas@linuxmagazine.com.brEste artigo no nosso site: http://lnm.com.br/article/8693