Я попытался выяснить, как настроить RSTP в Linux с задействованными VLAN и мостами, и теперь совершенно запутался.
Я пытаюсь соединить три интерфейса, два из которых должны действовать как магистраль (hdlc0 и hdlc1), а один должен действовать как порт доступа (eth0). Мне также нужно включить RSTP на каждом интерфейсе, включенном в мост, но с конфигурацией, указанной ниже, пакеты RSTP отправляются через hdlc0 и hdlc1 с тегами (!), Поэтому другие устройства их отклоняют. Поскольку в Linux нет понятия «собственный vlan», я не знаю, как это исправить.
Вот моя конфигурация:
ifconfig eth0 up
ifconfig hdlc0 up
ifconfig hdlc1 up
vconfig add hdlc0 42
vconfig add hdlc1 42
ifconfig hdlc0.42 up
ifconfig hdlc1.42 up
brctl addbr br1
brctl addif br1 eth0
brctl addif br1 hdlc0.42
brctl addif br1 hdlc1.42
ifconfig br1 up
brctl stp br1 on
Другой вопрос: мне также интересно, как настроить RSTP в сценариях, где у меня есть несколько мостов: скажем, eth0 - это магистраль с разрешенным vlan 42-42, vlan 42 должен проходить через hdlc0, а vlan 43 должен проходить через hdlc1, поэтому у меня два моста. Если я включу RSTP на обоих мостах, он (вероятно) будет работать независимо на каждом мосту, поэтому у меня скоро возникнут проблемы?
В Linux VLAN и мосты являются полностью отдельными конструкциями, а мосты Linux не поддерживают VLAN.
Когда вы создаете интерфейс VLAN, Linux помечает / отменяет теги пакеты на этом интерфейсе перед их передачей в / из базового физического («магистрального») интерфейса. Однако вы по-прежнему можете использовать базовый физический интерфейс для отправки немаркированных пакетов («собственная VLAN»).
Когда вы создаете мост, Linux переключает пакеты между связанными интерфейсами, не заботясь о тегах VLAN (или их отсутствии) в пакетах. Если вы подключите магистральный интерфейс к мосту, мост будет успешно переключать пакеты с тегами VLAN без учета тегов. Когда вы включаете STP на мосту, Linux генерирует немаркированные пакеты STP и отбрасывает их на мост.
Когда мост подключен к физическому интерфейсу, который также имеет связанные интерфейсы VLAN, эти интерфейсы VLAN перестанут видеть любой трафик, не предназначенный для MAC-адреса физического интерфейса. Такое поведение связано с порядком, в котором обрабатываются мосты и теги VLAN, и может быть изменено с помощью ebtables, как описано в http://blog.rackspace.com/vms-vlans-and-bridges-oh-my-part-2 . Однако, что касается связующего дерева, подключение мостов как к физическому интерфейсу, так и к связанным интерфейсам VLAN будет работать должным образом только в том случае, если вы все равно используете PVST + (поскольку блокировка портов STP управляется независимо для каждого моста), поэтому на самом деле это не так. актуально здесь.
Но вы также можете создать интерфейсы VLAN поверх моста, который передает пакеты с тегами VLAN, а затем добавить эти интерфейсы VLAN к другим мостам.
Итак, чтобы добиться желаемого, попробуйте:
ip link set dev hdlc0 up
ip link set dev hdlc1 up
brctl addbr br_native
brctl addif br_native hdlc0
brctl addif br_native hdlc1
brctl stp br_native on
ip link set dev br_native up
ip link add link br_native name br_native.42 type vlan id 42
ip link set dev br_native.42 up
ip link set dev eth0 up
brctl addbr br_42
brctl addif br_42 br_native.42
brctl addif br_42 eth0
ip link set dev br_42 up
Обратите внимание, что код моста ядра Linux изначально поддерживает только традиционный 802.1D STP. Чтобы добавить поддержку RSTP и PVST +, используйте https://github.com/mstpd/mstpd (Некоторую соответствующую документацию для mstpd также можно найти по адресу: https://docs.cumulusnetworks.com/display/DOCS/Spanning+Tree+and+Rapid+Spanning+Tree ). mstpd также может говорить MSTP, но из-за того, как Linux реализует свои FIB, в настоящее время невозможно отобразить топологии MSTP на мосты Linux, поэтому MSTP фактически не работает.
Чтобы ответить на ваш второй вопрос, я не верю, что возможно (на любом коммутаторе, а не только при использовании Linux) использовать STP или RSTP для направления каждой из двух разных VLAN на одной магистрали через две другие магистрали. Это можно сделать только с помощью PVST + или MSTP, хотя, как упоминалось выше, MSTP не поддерживается в Linux.
Начиная с ядра Linux 3.0 или около того, уже неверно, что мосты Linux «не поддерживают VLAN». https://linux-blog.anracom.com/2017/10/30/fun-with-veth-devices-in-un named-linux-network-namespaces-i/ и последующие статьи дают довольно хорошее объяснение, но в итоге:
Вы можете использовать bridge(8) инструмент для управления взаимодействиями bridge-vlan таким же образом, как у большинства управляемых коммутаторов.
В вашей ситуации вы можете попробовать что-то вроде:
# ip link set br0 type bridge vlan_filtering 1 vlan_default_pvid 1 stp_state 1 priority 32768 nf_call_iptables 1 nf_call_arptables 1
# bridge vlan add vid 1 pvid untagged dev eth0
bridge vlan add vid 19 dev eth0
ip link set up dev eth0
ip link set up dev hdlc0
ip link set up dev hdlc1
# if you only want to bridge VLAN42, you don't need these, but here's how you'd create them:
# ip link add link hdlc0 name hdlc0.42 type vlan protocol 802.1q id 1 reorder_hdr on gvrp on mvrp on loose_binding off
# ip link add link hdlc1 name hdlc1.42 type vlan protocol 802.1q id 1 reorder_hdr on gvrp on mvrp on loose_binding off
# ip link set up dev hdlc0.42
# ip link set up dev hdlc1.42
# now for the actual bridging:
brctl addbr br1
brctl addif br1 eth0
brctl addif br1 hdlc0
brctl addif br1 hdlc1
# port eth0 is an untagged port; assuming it should be in VLAN42:
bridge vlan add vid 42 dev eth0 pvid untagged
# hdlc0 is a trunk interface that forwards vlan42 in a tagged manner:
bridge vlan add vid 42 dev hdlc0
# hdlc1 carries vlan42 and vlan43, both with tagging:
bridge vlan add vid 42 dev hdlc1
bridge vlan add vid 43 dev hdlc1
brctl stp br1 on
ip link set up dev br1
Вы также можете добавить интерфейс vlan к мосту, который будет делать то, что логично, если вы думаете об этом: мост генерирует кадр Ethernet и передает его в порт, который отправляет его. Поскольку рассматриваемый порт является интерфейсом vlan, он добавляет тег vlan перед отправкой кадра. Я уверен, что для этого есть допустимые применения, но на данный момент я не могу ничего придумать. :)