LINUX.ORG.RU
ФорумAdmin

OIF, IIF. Может ли измениться числовой индекс сетевого интерфейса?

 , ,


0

1

Решил заменить строковые значения в конфиге nftables на числовые идентификаторы.
Так вот, если сетевой интерфейс хардварный, типа lo или enp1s0, то там уверенность есть, что их значения будут по порядку

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 2f:54:6z:87:0e:42 brd ff:ff:ff:ff:ff:ff
    altname enp0s18
    inet 1.2.3.4/5 brd 1.2.3.6 scope global enp1s0
       valid_lft forever preferred_lft forever

Если у меня добавлена PCI-сетевая с 4-мя портами. На первых 2-х портах VLAN’ы + поднят OpenVPN, который поднимается systemctl’ем и т. п., ну то есть, условно, на данный момент есть 10 числовых идентификаторов сетевых интерфейсов, что хардварных, что софтварных.
По моим наблюдениям lo всегда первый, enp1s0 (в моём случае) всегда второй, а вот допустим enp1s0.vlan04 - пятый, а tun0 шестой.
Есть ли вероятность того, что при перезагрузке последовательность софтварных интерфейсов изменится?


Есть ли вероятность

Нет вероятности, есть уверенность. Ты же в курсе, что интерфейсы могут удаляться и появляться?

no-dashi-v2 ★★★★
()
Ответ на: комментарий от Dodik

Ты ничего не написал о том, чем управляются и создаются интерфейсы, какой дистрибутив, а точнее какая система инициализации и какой framewark управляет сетью.

Если это чисто systemd, даже без systemd-networking - тут всё может запуститься плюс - минус в произвольном порядке, допустим через отдельный Unit.

Если это systemd-netoworking, тут всё зависит от того, как systemd интерпретирует его конфиг, возможно так же для каждой описанной конфигурации сетевого интерфейса создаёт отдельный systemd unit, читай документацию по systemd.

Если это debian network-interfaces - тут плюс минус всё запускается по очереди.

Но во всех этих случая - есть но, если какой-то интерфейс не поднялся, то следующий поднявшийся изменит свой индекс.

По поводу netplan - плюс минус так же, если что-то не поднялось - индекс может измениться.

В случае systemd-networking - не подскажу, но думаю тоже, что создаются отдельные unit`ы.

В случае отдельных systemd unit`ов - точно произвольно может запуститься, если ты не прописал директивы after и / или requierd.

Так же ты сказал, что есть pci-e плата.

Прочитай документацию по systemd udevd, если кратко, systemd создаёт предсказуемые имена устройств, чтобы при каждом запуске они были одинаковые, а не зависели от очерёдности инициализации устройства, т.е. загрузки драйвера (модуля). Есть одно «но», для именования systemd использует порядковые номера устройство на pci/pci-e шине. Это значит, что если ты, допустим, подключишь новый nvme накопитель или отключишь один из существующих, добавишь ещё одну pci-e карту в слот, или переставишь в другой слот или заменишь видео карту или другую плату расширения в pci-e, которая в себе содержит большее число pci-e устройств - нумерация устройства сетевого контроллера на pci-e шине изменится - изменится имя сетевого устройства, вместо enps0 - станет что-то другое. И в случае, если есть ещё другие сетевые контроллеры - они могут поменяться местами.

Поэтому, советую делать grep по именам устройств и / или mac адресов в выводе

ip a

И проверять всё, при изменении аппаратной части ПК.

kostik87 ★★★★★
()

Номера в этом списке - исключительно для удобства чтения вывода юзером. Никакие алгоритмы на них завязывать нельзя. Даже если оно у тебя будет работать, когда-нить неожиданно что-то пойдёт не так и ты уже забуешь в чём было дело.

А зачем вообще тебе эти номера понадобились?

firkax ★★★★★
()
Ответ на: комментарий от kostik87

Дистрибутив - Debian 13
Интерфейсы управляются systemd-networkd. По пути /etc/systemd/network/ создаются файлы вланов .netdev и .network, ну как создаются? Созданы 1 раз и всё. В принципе конфигурация не меняется.
Пока ждал ответов, нагуглил, что да. Присвоение идентификаторов интерфейсам непредсказуемо, в отличии от их именования. Единственное, в чём можно быть уверенным, что lo будет всегда первым

Dodik
() автор топика
Ответ на: комментарий от firkax

А зачем вообще тебе эти номера понадобились?

Выиграть микроскопическую производительность при обработке пакетов, описывая правила в конфигурации файервола =)

Dodik
() автор топика
Последнее исправление: Dodik (всего исправлений: 2)
Ответ на: комментарий от Dodik

в отличии от их именования.

Нет, имена тоже могут меняться и я выше написал почему. Systemd тебе это гарантирует только в случае, если ты ничего не меняешь в аппаратной части ПК, читай выше.

Выиграть микроскопическую производительность при обработке пакетов

Никакого выигрыша при использовании индексов сетевых устройств ты не получишь. При загрузке правил nftables в ядро правила преобразуются в ebpf код и работаю напрямую с сетевыми устройствами, как их видит само ядро. Поэтому используй имена сетевых интерфейсов в правилах и всё.

Это тебе, видимо, ИИ такую чушь посоветовал. Слушай их больше.

kostik87 ★★★★★
()
Ответ на: комментарий от kostik87

Это тебе, видимо, ИИ такую чушь посоветовал.

Я к этому калу не обращаюсь.

Спасибо за разъяснения!

Dodik
() автор топика
Ответ на: комментарий от kostik87

используй имена сетевых интерфейсов в правилах и всё

Хороший совет. Только надо имена интерфейсов зафиксировать через правила udev например и тогда вообще красота.

no-dashi-v2 ★★★★
()
Ответ на: комментарий от no-dashi-v2

Чтобы зафиксировать имена физических интерфейсов в начале нужно отключить предсказуемые имена в systemd.

И фраза, что ты вырвал из предложения относилась в целом ко всем интерфейсам, в том числе tun, vlan и прочему. И автору это всё не нужно, если не будет менять конфигурацию оборудования - у него и так будут постоянные имена.

И он хотел он использовать индексы, вместо имён сетевых интерфейсов, в том числе для tun и прочего.

И тут твой совет никак не поможет.

kostik87 ★★★★★
()

Решил заменить строковые значения в конфиге nftables на числовые идентификаторы.

Не надо так делать.

Есть ли вероятность того, что при перезагрузке последовательность софтварных интерфейсов изменится?

На уровне 99.9%.

anc ★★★★★
()
Ответ на: комментарий от Dodik

Единственное, в чём можно быть уверенным, что lo будет всегда первым

Это тоже можно «уронить».

anc ★★★★★
()
Ответ на: комментарий от no-dashi-v2

используй имена сетевых интерфейсов в правилах и всё

Хороший совет. Только надо имена интерфейсов зафиксировать через правила udev например и тогда вообще красота.

И да и нет. «Нет» это я про массовую смену сетевок, а так конечно да!

anc ★★★★★
()
Ответ на: комментарий от kostik87

в том числе tun, vlan и прочему. И автору это всё не нужно, если не будет менять конфигурацию оборудования - у него и так будут постоянные имена.

«tun, vlan и прочему» можно гвоздями прибить и не париться на тему смены сетевки и даже самого сервера от слова совсем.

anc ★★★★★
()
Ответ на: комментарий от anc

Анк, ну ты то мне зачем пишешь? Ты прочитал весь тред?

Я не понимаю суть твоего сообщения. Если ы прочитал весь тред и понял логику - незачем писать сообщение.

Если не прочитал, а отвечаешь на выдернутое из контекста предложение - ок.

Если не прочитал - прочитай, пожалуйста весь тред.

kostik87 ★★★★★
()
Последнее исправление: kostik87 (всего исправлений: 1)
Ответ на: комментарий от kostik87

Зачем?

Затем, что «если не будет менять конфигурацию оборудования - у него и так будут постоянные имена.» коренное здесь «если не будет менять конфигурацию оборудования»

anc ★★★★★
()
Ответ на: комментарий от anc

Отлично. Спасибо за подтверждение моих слов.

Но право не стоило. Я и так в них уверен.

kostik87 ★★★★★
()
Последнее исправление: kostik87 (всего исправлений: 1)
Ответ на: комментарий от kostik87

Чтобы зафиксировать имена физических интерфейсов в начале нужно отключить предсказуемые имена в systemd.

По барабану. Если правила для udev есть, будет как там написано (если, конечно, эти правила не привязаны к системшэшным именам :-) )

AS ★★★★★
()
Ответ на: комментарий от anc

Затем, что «если не будет менять конфигурацию оборудования - у него и так будут постоянные имена.»

Хохма в том, что они и так могут неожиданно поменяться:
https://bugzilla.altlinux.org/show_bug.cgi?id=28955#c33

AS ★★★★★
()
Ответ на: комментарий от Dodik

Выиграть микроскопическую производительность при обработке пакетов, описывая правила в конфигурации файервола =)

Разверни мысль. В каком месте ты что-то собрался выигрывать, используя эти индексы вместо имён интерфейсов?

CrX ★★★★★
()
Ответ на: комментарий от CrX

Сравнение строк vs сравнение двух чисел. Не знаю как в nftables, в iptables когда-то для сравнения имени интерфейса (15 байт) было как 4 сравнения int32, плюс, ещё какие-то операции, так как имя могло содержать плюсик. А два числа за 1 такт сравниваются.

преобразуются в ebpf код

Но никто не привёл, в какой, и сколько операций будет в iff и iffname сравнениях.

mky ★★★★★
()
Ответ на: комментарий от Dodik

А ты серьезно думаешь что на каждый приходящий пакет делается lookup с поиском id интерфейса, если он задан в правилах firewall по имени?

Pinkbyte ★★★★★
()
Ответ на: комментарий от mky

ИМХО если система загружена НАСТОЛЬКО, что ищется ускорение на уровне такой мелочи - то надо не такие оптимизации проводить(выигрыш от которых если не сомнителен, то микроскопически мал), а систему расширять(новое более мощное железо и т.д.).

А если система не загружена - то это всё попахивает преждевременной оптимизацией как раз из-за того что выигрыш скорее всего будет статистически не значим.

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от mky

Сравнение строк vs сравнение двух чисел. Не знаю как в nftables, в iptables когда-то для сравнения имени интерфейса (15 байт) было как 4 сравнения int32, плюс, ещё какие-то операции, так как имя могло содержать плюсик. А два числа за 1 такт сравниваются.

Это шутка, или он серьёзно вот об этом?

Это не микроскопическая и даже не наноскопическая, это я даже не знаю, что. Экономить 15 байт и несколько тактов, имея гигабайты и гигагерцы — это уже не экономия на спичках, а не знаю, пересчёт крупинок в пакете с сахаром. Он на создание этой темы больше вычислительных ресурсов потратил, чем сумеет на этом сэкономить за всю жизнь.

CrX ★★★★★
()
Ответ на: комментарий от Pinkbyte

попахивает преждевременной оптимизацией

Дак оптимизации же в тренде, иначе как бы Dirty Pipe, Copy Fail и Dirty Frag в ядре появились :)

mky ★★★★★
()
Ответ на: комментарий от CrX

Экономить 15 байт и несколько тактов, имея гигабайты и гигагерцы

В принципе, да. Но может у него 100500 правил с именами интерфейсов. Или какой-нибудь дохлый одноплатник. Хотя пишет, что Debian 13 и PCI-сетёвка (видимо PCIe сетевая плата).

Он на создание этой темы больше вычислительных ресурсов потратил

На кол его! И пусть педали генератора крутит, пока всю потраченную энергию не возвратит :)

mky ★★★★★
()
Ответ на: комментарий от AS

Хохма в том, что они и так могут неожиданно поменяться:

Есть такая хохма, во всяком случае у русских дистров. До столкновения с астрой/альтом «я такого номера не видел».

anc ★★★★★
()
Ответ на: комментарий от anc

Есть такая хохма, во всяком случае у русских дистров. До столкновения с астрой/альтом «я такого номера не видел».

При чём тут конкретный дистрибутив, если дело в изменениях в ядре? Это не какие-то отдельные дистрибутивоспецифичные патчи, это везде есть. А что не нарвался - случайность. В принципе-то событие редкое само по себе.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

Это не какие-то отдельные дистрибутивоспецифичные патчи, это везде есть.

За «везде» не говорите, вот у меня как-то пока всё норм. :)

anc ★★★★★
()

Зависит от того, как их UEFI перечисляет. У меня был прикол, когда в M.2 заменил SATA-SSD на NVMe-SSD, и у сетевой поменялся номер.

В systemd-networkd можно и по MAC соответствие искать. В Match вообще куча параметров для поиска.

https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html

Radjah ★★★★★
()
Ответ на: комментарий от anc

За «везде» не говорите, вот у меня как-то пока всё норм. :)

Просто не было именно этого перехода между ядрами. Подозреваю, ещё и от платформы там была зависимость, вероятно на десктопной материнке и не случилось бы.

AS ★★★★★
()
Ответ на: комментарий от Radjah

Зависит от того, как их UEFI перечисляет. У меня был прикол, когда в M.2 заменил SATA-SSD на NVMe-SSD, и у сетевой поменялся номер.

Я изменение «постоянного» имени видел и из-за установки видеокарты. В общем любое изменение количества устройств PCI на это может влиять. Вероятно тоже зависимость от аппаратной платформы может быть.

AS ★★★★★
()
Ответ на: комментарий от AS

За «везде» не говорите, вот у меня как-то пока всё норм. :)

Просто не было именно этого перехода между ядрами.

Ну у меня сейчас чуть менее чем годовалый 5.15.161. Полет нормальный.

вероятно на десктопной материнке и не случилось бы.

Как раз на десктопах это и происходило «с этими вашими ненужно» именованиями интерфейсов. :)

anc ★★★★★
()
Ответ на: комментарий от AS

любое изменение количества устройств PCI на это может влиять

Сталкивался с подобным. При воткнутой PCI-видюхе были имена интерфейсов enp6s0 и enp7s0, а после того, как видюху убрал с материнки, имена интерфейсов стали enp5s0 и enp6s0

Dodik
() автор топика
  • Markdown
Пустая строка (два раза Enter) начинает новый абзац. Знак '>' в начале абзаца выделяет абзац курсивом цитирования.
Внимание: прочитайте описание разметки Markdown.
Используйте Ctrl-Enter для размещения комментария