Хотел вчера я iperf’ом померить полосу. Хосты дома у меня прибиты и в прямой, и в обратной dns зонах, так что я ввёл адрес и… оно мне написало, что до хоста достучатся не может. А он работает. Но с другим адресом! Сначала подумал, что это сбой в udhcpd (да, я использую его и unbound, вместо dnsmasq), но оказалось, что просто изменился MAC-адрес моей машины. Удивительное рядом…
Компьютер подключается к сети медью, через intel’овскую десктопную карту. Она включена в мостовой интерфейс, соответственно мостовой интерфейс использует её MAC-адрес для общения с сетью. Но просмотр вывода ‘ip link’ показал, что интерфейс br0 имеет отличный от интерфейса vlan2 (да, дома я использую vlan’ы) MAC-адрес. Тут я, конечно, выпал в осадок. Так как 10 лет linux bridge копировал MAC включённого в него интерфейса, а теперь, внезапно, нет!
И ведь я даже догадываюсь, почему оно так теперь нынче выглядит: мост копировал на себя адрес интерфейса, и если интерфейсов более одного, то выбирал он адрес с наименьшим значением. И он таки мог применить на себя, например, адрес интерфейса виртуальной машины (начинающийся с ’52:54:00:’), вместо адреса реального сетевого интерфейса (начинающегося с ‘f8:’). То есть на время смены MAC’а, в момент включения/выключения виртуальной машины, хост мог сидеть без сети. Этого можно было избежать, принудительно добавив интерфейс-заглушку в бридж… Но это же что-то делать надо! А теперь нате — вот вам фикс, который меняет стандартное поведение. Пожалуйста. Без предупреждения. «Благо для всех и для каждого», ога-ога…
И теперь, чтобы парировать изменение поведения linux bridge, приходится совсем отказаться от использования helper’а из состава bridge-utils (да, у меня Debian):
aliech@arcturus:~$ cat /etc/network/interfaces.d/br0
auto br0
iface br0 inet dhcp
#bridge_ports vlan2 # параметр helper'а из bridge-utils, более не нужно
#bridge_stp off # параметр helper'а из bridge-utils, более не нужно
#bridge_fd 0 # параметр helper'а из bridge-utils, более не нужно
#bridge_maxwait 0 # параметр helper'а из bridge-utils, более не нужно
pre-up ip link show enp1s0 | grep -q DOWN && ip link set enp1s0 up || true # поднимаем физический интерфейс, если не поднят
pre-up ip link add link enp1s0 name vlan2 type vlan id 2 gvrp off # добавляем vlan (только если нужен)
pre-up ip link set vlan2 up # поднимаем vlan (только если нужен)
pre-up ip link add name br0 type bridge # добавляем мост
pre-up ip link set vlan2 master br0 # добавляем в мост сетевой интерфейс
pre-up ip link set dev br0 address xx:xx:xx:xx:xx:xx # ставим на мост MAC-адрес сетевого интерфейса
post-down ip link set vlan2 nomaster # удаляем сетевой интерфейс из моста
post-down ip link delete br0 type bridge # удаляем мост
post-down ip link set vlan2 down # гасим vlan (если создавали vlan)
post-down ip link del vlan2 # удаляем vlan (если создавали vlan)
Вот смотрите: vlan я уже давно добавляю руками, так как у helper’а из состава пакета vlan нет параметров, касающихся gvrp. Теперь руками и мостом управляю. И, в итоге, получается портянка в лучших традициях Slackware. Может пора мигрировать? Меня разве скрипты и массовый make config/install/uninstall может смутить? Ну да, uninstall не у всех программ в Makefile прописан. Ну так скрипт напишу, который мне на базе inortify, например, отследит действия make install и откатит их. Делов то…