Ошибки конфигураций L2 (Перевод)

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

Неправильная конфигурация Layer 2 иногда может вызывать труднообнаружимые ошибки в сети, случайные снижения производительности, недоступность отдельных сегментов сети, неисправность определенных сетевых служб или полный сбой сети. На этой странице будут представлены некоторые общие и не очень распространенные конфигурации, которые могут вызвать проблемы в вашей сети.

Bridge-ы на одном чипе коммутатора

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

Конфигурация

/interface bridge
add name=bridge1
add name=bridge2
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2
add bridge=bridge2 interface=ether3
add bridge=bridge2 interface=ether4

Проблема После простого тестирования производительности вы можете заметить, что один bridge способен пересылать трафик со скоростью передачи по проводу, в то время как второй, третий и так далее bridge не способен передавать столько данных, сколько первый bridge. Другим симптомом может быть наличие большой задержки для пакетов, которые должны быть маршрутизированы. После быстрого осмотра вы можете заметить, что ЦП всегда находится под полной нагрузкой, потому что аппаратное ускорение не доступно на всех bridge-ах, а доступно только на одном bridge. Проверив статус аппаратного ускорения, вы заметите, что только один bridge его активировал:

[admin@MikroTik] > /interface bridge port print
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload 
 #     INTERFACE                                 BRIDGE                                 HW
 0   H ether1                                    bridge1                                yes
 1   H ether2                                    bridge1                                yes
 2     ether3                                    bridge2                                yes
 3     ether4                                    bridge2                                yes

Причина того, что только один bridge имеет доступный флаг аппаратного ускорения, заключается в том, что устройство не поддерживает изоляцию портов. Если изоляция портов не поддерживается, то только один bridge сможет ускорять передачу трафика на коммутаторе.

Симптомы Ниже приведен список возможных симптомов, которые могут быть следствием такой конфигурации:

Решение Не все устройства поддерживают изоляцию портов, в настоящее время поддерживают только устройства серии CRS1xx/CRS2xx, и только 7 изолированных и аппаратно ускоренных bridge поддерживаются одновременно. Другие устройства должны использовать ЦП для пересылки пакетов по другим bridge. Это обычно ограничение аппаратного обеспечения, и может потребоваться использование другого устройства. Параметр split-horizon bridge - это программная функция, которая отключает аппаратное ускорение, и при использовании правил фильтрации bridge вам нужно включить пересылку всех пакетов на ЦП, что требует отключения аппаратного ускорения. Вы можете контролировать, какой bridge будет аппаратно ускорен, установив флаг hw=yes, и устанавливая hw=no для других мостов, например:

/interface bridge port set [find where bridge=bridge1] hw=no
/interface bridge port set [find where bridge=bridge2] hw=yes

Иногда возможно перестроить топологию сети для использования VLAN, что является правильным способом изоляции сетей Layer2.

Поток пакетов с аппаратным ускорением и обучением MAC

Рассмотрим следующий сценарий: вы настраиваете мост и включаете аппаратное ускорение, чтобы максимизировать пропускную способность вашего устройства. В результате ваше устройство работает как коммутатор, но вы хотите использовать инструменты Sniffer или Torch для отладки, или, возможно, вы хотите реализовать журналирование пакетов.

Конфигурация

/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 hw=yes interface=ether1 learn=yes
add bridge=bridge1 hw=yes interface=ether2 learn=yes

Проблема При выполнении инструментов Sniffer или Torch для захвата пакетов вы можете заметить, что видны едва ли не все пакеты, только некоторые одиночные пакеты, но в основном захватываются широковещательные/многоадресные пакеты. При этом интерфейсы сообщают о том, что через определенные интерфейсы проходит гораздо больший трафик, чем тот, который был захвачен. С версии RouterOS v6.41, если вы добавляете два или более интерфейса Ethernet в bridge и включаете аппаратное ускорение, то коммутатор будет использоваться для пересылки пакетов между портами. Чтобы понять, почему захватываются только некоторые пакеты, нам сначала нужно рассмотреть, как коммутатор соединен с ЦПУ. В данном примере можно использовать блок-схему от общего 5-портового Ethernet-роутера:

Alt text

Для этого устройства каждый порт Ethernet подключен к коммутатору, а коммутатор подключен к ЦПУ через порт ЦПУ (иногда называемый портом switch-cpu). Чтобы пакеты были видны в инструментах Sniffer или Torch, пакет должен быть отправлен с порта Ethernet на порт ЦПУ. Это означает, что пакет должен быть предназначен для порта ЦПУ (MAC-адрес назначения пакета совпадает с MAC-адресом моста) или MAC-адрес пакета не должен быть известен (пакет рассылается на все порты), это происходит из-за обучения MAC.

Коммутатор хранит список MAC-адресов и портов, называемый таблицей хостов. Когда требуется переслать пакет, коммутатор проверяет MAC-адрес назначения пакета по таблице хостов, чтобы найти порт, который следует использовать для пересылки пакета. Если коммутатор не может найти MAC-адрес назначения, то пакет рассылается на все порты (включая порт ЦПУ). В ситуациях, когда пакет должен быть переслан, например, с ether1 на ether2, и MAC-адрес устройства за ether2 есть в таблице хостов, то пакет никогда не отправляется на ЦПУ и, следовательно, не виден инструментам Sniffer или Torch.

Симптомы Ниже приведен список возможных симптомов, которые могут быть результатом такой конфигурационной ошибки:

Решение Пакеты с MAC-адресом назначения, который известен, не будут отправлены на ЦПУ, так как они не рассылаются на все порты. Если вам действительно нужно отправлять определенные пакеты на ЦПУ для анализатора пакетов или брандмауэра, то можно скопировать или перенаправить пакет на ЦПУ, используя правила ACL. Вот пример того, как отправить копию пакетов, предназначенных для 4C:5E:0C:4D:12:4B:

/interface ethernet switch rule
add copy-to-cpu=yes dst-mac-address=4C:5E:0C:4D:12:4B/FF:FF:FF:FF:FF:FF ports=ether1 switch=switch1

Если пакет отправляется на ЦПУ, то он должен быть обработан ЦПУ, что увеличит загрузку ЦПУ.

Интерфейсы LAG и балансировка нагрузки

Рассмотрим следующий сценарий: вы создали интерфейс LAG для увеличения общей пропускной способности между двумя сетевыми узлами, как правило, это коммутаторы. В целях тестирования правильной работы интерфейса LAG вы подключили два сервера для передачи данных. Обычно для таких настроек используется известный инструмент измерения производительности сети Iperf. Например, вы могли создать интерфейс LAG из двух портов Gigabit Ethernet, что дает виртуальный интерфейс, способный балансировать трафик по обоим интерфейсам и теоретически достигать пропускной способности 2 Гбит/с, в то время как серверы подключены через интерфейс 10 Гбит/с, например, SFP+.

Alt text

Конфигурация

Следующая конфигурация актуальна для SW1 и SW2:

/interface bonding
add mode=802.3ad name=bond1 slaves=ether1,ether2
/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 interface=bond1
add bridge=bridge1 interface=sfp-sfpplus1

Проблема

После начальных тестов вы сразу замечаете, что пропускная способность вашей сети никогда не превышает 1 Гбит/с, даже если нагрузка процессора на серверах и на сетевых узлах (в данном случае, коммутаторах) низкая. Тем не менее, пропускная способность ограничивается только 1 Гбит/с. Причина в том, что LACP (802.3ad) использует политику хеширования передачи, чтобы определить, можно ли балансировать трафик по нескольким членам LAG. В данном случае интерфейс LAG не создает интерфейс 2 Гбит/с, а скорее интерфейс, способный балансировать трафик по нескольким интерфейсам-членам LAG, когда это возможно. Для каждого пакета генерируется хеш передачи, который определяет, по какому члену LAG будет отправлен пакет. Это необходимо для предотвращения упорядочения пакетов. Есть возможность выбрать политику хеширования передачи, обычно предоставляется выбор между Layer2 (MAC), Layer3 (IP) и Layer4 (Port). В RouterOS это можно выбрать, используя параметр transmit-hash-policy. В данном случае хеш передачи одинаков, так как вы отправляете пакеты на одинаковый MAC-адрес назначения, а также на одинаковый IP-адрес, и Iperf использует тот же порт. Это генерирует одинаковый хеш передачи для всех пакетов, и балансировка нагрузки между членами LAG невозможна. Следует отметить, что не всегда пакеты будут балансироваться между членами LAG, даже если назначение разное, потому что стандартизированная политика хеша передачи может генерировать одинаковый хеш передачи для разных адресов назначения, например, 192.168.0.1/192.168.0.2 будет балансироваться, но 192.168.0.2/192.168.0.4 НЕ будет балансироваться в случае использования политики хеша передачи Layer2-and-3 и одинакового MAC-адреса назначения.

Симптомы

Ниже приведен список возможных симптомов, которые могут быть результатом такой конфигурационной ошибки:

Решение

Выберите подходящую политику хеша передачи и правильно протестируйте пропускную способность вашей сети. Простейший способ протестировать такие настройки - использовать несколько адресатов. Например, вместо отправки данных только на один сервер, лучше отправить данные на несколько серверов. Это сгенерирует разный хеш передачи для каждого пакета и сделает возможной балансировку нагрузки между членами LAG. Для некоторых настроек может потребоваться изменить режим интерфейса bonding для увеличения общей пропускной способности. Например, для трафика UDP режим balance-rr может быть достаточным, но может вызвать проблемы для трафика TCP.

Интерфейс VLAN на slave интерфейсе

Рассмотрим следующий сценарий: вы создали bridge, и хотите, чтобы DHCP-сервер выдавал IP-адреса только для определенного тегированного трафика VLAN. Для этого вы создали интерфейс VLAN, указали VLAN ID и создали DHCP-сервер на нем, но по какой-то причине это не работает должным образом.

Конфигурация

/interface bridge
add name=bridge1
/interface bridge port
add interface=ether1 bridge=bridge1
add interface=ether2 bridge=bridge1
/interface vlan
add name=VLAN99 interface=ether1 vlan-id=99
/ip pool
add name=VLAN99_POOL range=192.168.99.100-192.168.99.200
/ip address add address=192.168.99.1/24 interface=VLAN99
/ip dhcp-server
add interface=VLAN99 address-pool=VLAN99_POOL disabled=no
/ip dhcp-server network
add address=192.168.99.0/24 gateway=192.168.99.1 dns-server=192.168.99.1

Проблема При добавлении интерфейса в bridge, bridge становится главным интерфейсом, и все порты bridge-a становятся второстепенными портами. Это означает, что весь трафик, полученный на порту bridge, захватывается интерфейсом bridge-a, и весь трафик пересылается на CPU с использованием интерфейса bridge вместо физического интерфейса. В результате интерфейс VLAN, созданный на второстепенном интерфейсе, никогда не захватит никакого трафика, поскольку он сразу пересылается на главный интерфейс до любой обработки пакетов. Обычным побочным эффектом является то, что некоторые DHCP-клиенты получают IP-адреса, а некоторые — нет.

Симптомы Ниже приведен список возможных симптомов, которые могут быть результатом такой неправильной конфигурации:

Решение Измените интерфейс, на котором интерфейс VLAN будет слушать трафик, и измените его на главный интерфейс:

/interface vlan set VLAN99 interface=bridge1

Bridged VLAN на физических интерфейсах

Рассмотрим следующий сценарий: у вас есть несколько коммутаторов в вашей сети, и вы используете VLAN для изоляции определенных доменов уровня 2 и подключения этих коммутаторов к маршрутизатору, который назначает адреса и маршрутизирует трафик в мир. Для обеспечения отказоустойчивости вы подключаете все коммутаторы напрямую к маршрутизатору и включаете RSTP, но чтобы настроить DHCP-сервер, вы решаете создать интерфейс VLAN для каждого VLAN на каждом физическом интерфейсе, подключенном к коммутатору, и добавить эти интерфейсы VLAN в мост. Диаграмма сети может быть найдена ниже:

Alt text

Конфигурация Значима только часть с настройкой маршрутизатора, конфигурация коммутатора не имеет значения, главное, чтобы порты были коммутированы. Конфигурация маршрутизатора может быть найдена ниже:

/interface bridge
add name=bridge10
add name=bridge20
/interface vlan
add interface=ether1 name=ether1_v10 vlan-id=10
add interface=ether1 name=ether1_v20 vlan-id=20
add interface=ether2 name=ether2_v10 vlan-id=10
add interface=ether2 name=ether2_v20 vlan-id=20
/interface bridge port
add bridge=bridge10 interface=ether1_v10
add bridge=bridge10 interface=ether2_v10
add bridge=bridge20 interface=ether1_v20
add bridge=bridge20 interface=ether2_v20

Проблема Может возникнуть задержка в сети или даже отсутствие ответа сети; возможно, обнаружено наличие петли (пакет, полученный с собственным MAC-адресом), и генерируется какой-то трафик из ниоткуда. Проблема заключается в том, что широковещательный пакет, исходящий из одного из интерфейсов VLAN, созданных на маршрутизаторе, будет отправлен через физический интерфейс, коммутатор и получен обратно на другом физическом интерфейсе. В этом случае широковещательные пакеты, отправленные из ether1_v10, будут получены на ether2, пакет попадет в ether2_v10, который объединен с ether1_v10, и снова будет перенаправлен тем же путем (петля). (R)STP не всегда обнаруживает эту петлю, поскольку (R)STP не знает о VLAN, петля не существует с untagged трафиком, но она существует с tagged трафиком. В этом сценарии довольно легко выявить петлю, но в более сложных настройках не всегда легко обнаружить дефект сетевого дизайна. Иногда этот дефект сетевого дизайна может остаться незамеченным очень долгое время, если ваша сеть не использует широковещательный трафик, обычно протокол обнаружения соседей транслирует пакеты с интерфейса VLAN и обычно вызывает обнаружение петли в такой настройке. Иногда полезно захватить пакет, который вызвал обнаружение петли, это можно сделать с помощью сниффера и анализа файла захвата пакетов:

/tool sniffer
set filter-mac-address=4C:5E:0C:4D:12:44/FF:FF:FF:FF:FF:FF \
filter-interface=ether1 filter-direction=rx file-name=loop_packet.pcap

Или более удобным способом с использованием журналирования:

/interface bridge filter
add action=log chain=forward src-mac-address=4C:5E:0C:4D:12:44/FF:FF:FF:FF:FF:FF
add action=log chain=input src-mac-address=4C:5E:0C:4D:12:44/FF:FF:FF:FF:FF:FF

Симптомы Вот список возможных симптомов, которые могут быть результатом такой неправильной конфигурации:

Решение Решением является использование фильтрации VLAN на bridge для совместимости всех мостов с IEEE 802.1W и IEEE 802.1Q.

/interface bridge
add name=bridge vlan-filtering=yes
/interface bridge port
add bridge=bridge interface=ether1
add bridge=bridge interface=ether2
/interface bridge vlan
add bridge=bridge tagged=ether1,ether2,bridge vlan-ids=10
add bridge=bridge tagged=ether1,ether2,bridge vlan-ids=20
/interface vlan
add name=vlan10 interface=bridge vlan-id=10
add name=vlan20 interface=bridge vlan-id=20

Включив vlan-filtering, вы будете фильтровать трафик, предназначенный для ЦП, перед включением фильтрации VLAN убедитесь, что вы настроили порт управления.

Bridged VLAN

Более упрощенный сценарий Bridged VLAN на физических интерфейсах, но в этом случае вы просто хотите объединить два или более VLAN, созданных на разных физических интерфейсах. Это очень распространенный тип настройки, который заслуживает отдельной статьи, поскольку неправильная конфигурация этого типа настройки приводила к нескольким сбоям в сети. Этот тип настройки также используется для трансляции VLAN.

Конфигурация

/interface vlan
add interface=ether1 name=ether1_v10 vlan-id=10
add interface=ether2 name=ether2_v10 vlan-id=10
/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 interface=ether1_v10
add bridge=bridge1 interface=ether2_v10

Проблема

Вы можете заметить, что определенные части сети недоступны и/или определенные соединения постоянно колеблются. Это происходит из-за (R)STP: этот тип конфигурации заставляет устройство отправлять тегированные BPDUs, которые могут не поддерживаться другими устройствами, включая RouterOS. Поскольку устройство получает искаженный пакет (тегированные BPDUs не должны существовать в вашей сети при использовании (R)STP, что нарушает IEEE 802.1W и IEEE 802.1Q), устройство не сможет правильно интерпретировать пакет и может проявить непредсказуемое поведение.

Симптомы Ниже приведен список возможных симптомов, которые могут быть результатом такой неправильной конфигурации:

Решение

Самое простое решение - просто отключить (R)STP на Bridge:

/interface bridge
set bridge1 protocol-mode=none

Тем не менее, рекомендуется переписать конфигурацию для использования фильтрации VLAN на Bridge:

/interface bridge
add name=bridge1 vlan-filtering=yes
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2
/interface bridge vlan
add bridge=bridge1 tagged=ether1,ether2 vlan-ids=10

Включив vlan-filtering, вы будете фильтровать трафик, предназначенный для ЦПУ. Прежде чем включить фильтрацию VLAN, убедитесь, что вы настроили порт управления.

Bridge фильтрация VLAN на устройствах не относящихся к CRS3xx

Рассмотрим следующий сценарий: вы узнали о новой функции фильтрации VLAN для мостовой и решили изменить конфигурацию на своем устройстве. У вас очень простая настройка транкового/доступного порта, и вам нравится идея фильтрации VLAN на мостовой.

Конфигурация

/interface bridge
add name=bridge1 vlan-filtering=yes
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2 pvid=20
add bridge=bridge1 interface=ether3 pvid=30
add bridge=bridge1 interface=ether4 pvid=40
/interface bridge vlan
add bridge=bridge1 tagged=ether1 untagged=ether2 vlan-ids=20
add bridge=bridge1 tagged=ether1 untagged=ether3 vlan-ids=30
add bridge=bridge1 tagged=ether1 untagged=ether4 vlan-ids=40

Проблема Например, вы используете эту конфигурацию на устройстве серии CRS1xx/CRS2xx, и заметили, что использование процессора (CPU) очень высоко. При выполнении теста производительности для проверки пропускной способности сети вы обнаруживаете, что общая пропускная способность составляет лишь долю от производительности, которую она легко должна достигнуть. Причиной проблемы является то, что не все устройства поддерживают фильтрацию VLAN на аппаратном уровне. Все устройства могут быть настроены с использованием фильтрации VLAN на bridge, но только некоторые из них смогут выгрузить трафик на микросхему коммутатора. Если используется неправильный метод конфигурации на устройстве с встроенной микросхемой коммутатора, то процессор будет использоваться для пересылки трафика.

Симптомы Вот список возможных симптомов, которые могут быть результатом такой неправильной конфигурации:

Решение Перед использованием фильтрации VLAN на bridge проверьте, поддерживает ли ваше устройство эту функцию на аппаратном уровне. Таблицу совместимости можно найти в разделе “Аппаратное ускорение моста”. Каждый тип устройства в настоящее время требует различного метода конфигурации. Вот список конфигураций, которые следует использовать на устройстве для использования преимуществ аппаратного ускорения:

Фильтрация VLAN с использованием нескольких чипов коммутации

Рассмотрим следующий сценарий: у вас есть устройство с двумя или более чипами коммутации, и вы решили использовать один мост и настроить фильтрацию VLAN (с использованием меню /interface ethernet switch) на аппаратном уровне, чтобы достичь производительности сети на уровне передачи скуорости соединения. Это особенно актуально для устройств серии RB2011 и RB3011. В этом примере предположим, что вы хотите иметь один trunk порт, а все остальные порты - порты доступа. Например, ether10 является нашим trunk портом, а ether1-ether9 - портами доступа.

Конфигурация

/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether4
add bridge=bridge1 interface=ether5
add bridge=bridge1 interface=ether6
add bridge=bridge1 interface=ether7
add bridge=bridge1 interface=ether8
add bridge=bridge1 interface=ether9
add bridge=bridge1 interface=ether10
/interface vlan
add interface=bridge1 name=VLAN10 vlan-id=10
/interface ethernet switch port
set ether1,ether2,ether3,ether4,ether5,ether6,ether7,ether8,ether9 default-vlan-id=10 vlan-header=always-strip vlan-mode=secure
set ether10 vlan-header=add-if-missing vlan-mode=secure
set switch1-cpu,switch2-cpu vlan-mode=secure
/interface ethernet switch vlan
add ports=ether1,ether2,ether3,ether4,ether5,switch1-cpu switch=switch1 vlan-id=10
add ports=ether6,ether7,ether8,ether9,ether10,switch2-cpu switch=switch2 vlan-id=10

Проблема

После выполнения нескольких тестов вы можете заметить, что пакеты с ether6-ether10 пересылаются, как ожидается, но пакеты с ether1-ether5 не всегда пересылаются правильно (особенно через trunk порт). Наиболее заметной проблемой будет то, что пакеты с ether1-ether5 через ether10 просто отбрасываются, потому что эти порты расположены на разных чипах коммутации, что означает, что фильтрация VLAN на аппаратном уровне невозможна, так как чип коммутатора не знает содержание таблицы VLAN на другом чипе коммутации. Пакеты, которые пересылаются между портами, расположенными на разных чипах коммутации, также обрабатываются ЦП, что означает, что вы не сможете достичь производительности на уровне передачи по проводу.

Симптомы

Ниже приведен список возможных симптомов, которые могут быть результатом такой некорректной конфигурации:

Решение

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

Есть способ настроить устройство так, чтобы все порты коммутировались вместе и при этом использовали фильтрацию VLAN на аппаратном уровне, хотя у этого решения есть некоторые ограничения. Идея заключается в том, чтобы пожертвовать одним портом Ethernet на каждом чипе коммутатора, который будет действовать как trunk порт для пересылки пакетов между чипами коммутации. Это можно сделать, подключив Ethernet-кабель между обоими чипами коммутации, например, подключим Ethernet-кабель между ether5 и ether6, затем переконфигурируем устройство, предполагая, что эти порты - trunk порты:

/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether4
add bridge=bridge1 interface=ether5
add bridge=bridge2 interface=ether6
add bridge=bridge2 interface=ether7
add bridge=bridge2 interface=ether8
add bridge=bridge2 interface=ether9
add bridge=bridge2 interface=ether10
/interface ethernet switch port
set ether1,ether2,ether3,ether4,ether7,ether8,ether9 default-vlan-id=10 vlan-header=always-strip vlan-mode=secure
set ether5,ether6,ether10 vlan-header=add-if-missing vlan-mode=secure default-vlan-id=auto
set switch1-cpu,switch2-cpu vlan-mode=secure
/interface ethernet switch vlan
add ports=ether1,ether2,ether3,ether4,ether5,switch1-cpu switch=switch1 vlan-id=10
add ports=ether6,ether7,ether8,ether9,ether10,switch2-cpu switch=switch2 vlan-id=10

Для коммутаторов с пропускной способностью 100 Мбит/с используйте default-vlan-id=0 вместо default-vlan-id=auto

Фильтрация VLAN с упрощенной таблицей VLAN bridge

Необходимо создать сетевую конфигурацию, в которой несколько клиентов подключены к отдельным портам доступа и изолированы различными VLAN. Этот трафик должен быть tagged и отправлен на соответствующий trunk порт. Порты доступа настроены с использованием свойства pvid. Поскольку trunk порт используется для обоих VLAN, вы решили упростить конфигурацию, добавив одну запись в таблицу VLAN bridge и разделив VLAN запятой. Это особенно полезно, когда используются tagged trunk порты через большое количество VLAN или даже определенные диапазоны VLAN (например, vlan-id=100-200). См. диаграмму сети и конфигурацию ниже.

Alt text

Конфигурация

/interface bridge
add name=bridge1 vlan-filtering=yes
/interface bridge port
add bridge=bridge1 interface=ether2
add bridge=bridge1 interface=ether3 pvid=10
add bridge=bridge1 interface=ether4 pvid=20
/interface bridge vlan
add bridge=bridge1 tagged=ether2 vlan-ids=10,20

Проблема Трафик правильно пересылается и помечается с портов доступа на trunk порт, но вы можете заметить, что некоторые широковещательные или многоадресные пакеты фактически передаются между обоими untagged портами доступа, хотя они должны быть на разных VLAN. Кроме того, широковещательный и многоадресный трафик с tagged порта также передается на оба порта доступа. Это может вызвать опасения с точки зрения безопасности, так как трафик из разных сетей может быть перехвачен. Когда вы смотрите на таблицу VLAN моста, вы замечаете, что создана единая запись для VLAN 10 и 20, и оба untagged порта принадлежат той же группе VLAN.

[admin@SW1] /interface bridge vlan print where tagged=ether2
Columns: BRIDGE, VLAN-IDS, CURRENT-TAGGED, CURRENT-UNTAGGED
# BRIDGE   VLAN-IDS  CURRENT-TAGGED  CURRENT-UNTAGGED
;;; port with pvid added to untagged group which might cause problems, consider adding a separate VLAN entry
0 bridge1        10  ether2          ether3          
                 20                  ether4    

Симптомы Трафик передается между разными VLAN. Красное предупреждение: порт с pvid добавлен к группе untagged, что может вызвать проблемы, рассмотрите добавление отдельной записи VLAN.

Решение Когда порты доступа настроены с использованием свойства pvid, они динамически добавляются в соответствующую запись VLAN. После создания статической записи VLAN с несколькими VLAN или диапазоном VLAN, untagged порт доступа с соответствующим pvid также включается в ту же группу VLAN или диапазон. Может быть полезным определить большое количество VLAN с использованием одной строки конфигурации, но следует проявлять осторожность при настройке портов доступа. В данном примере следует создать отдельные записи VLAN:

/interface bridge vlan
add bridge=bridge1 tagged=ether2 untagged=ether3 vlan-ids=10
add bridge=bridge1 tagged=ether2 untagged=ether4 vlan-ids=20

MTU на основном интерфейсе

Представьте себе следующий сценарий: вы создали bridge, добавили несколько интерфейсов и создали VLAN-интерфейс поверх интерфейса bridge, но вам нужно увеличить размер MTU на интерфейсе VLAN, чтобы принимать большие пакеты.

Конфигурация

/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2
/interface vlan
add interface=bridge1 name=VLAN99 vlan-id=99

Проблема Как только вы пытаетесь увеличить размер MTU на интерфейсе VLAN, вы получаете ошибку, что RouterOS не может установить MTU. Это может произойти, когда вы пытаетесь установить MTU больше, чем L2MTU. В этом случае вам нужно увеличить размер L2MTU на всех ведомых интерфейсах, что обновит размер L2MTU на интерфейсе моста. После этого вы сможете установить больший MTU на интерфейсе VLAN. Тот же принцип применяется к интерфейсам Bonding. Вы можете увеличивать MTU на интерфейсах, таких как VLAN, MPLS, VPLS, Bonding и других интерфейсах, только когда все физические ведомые интерфейсы имеют правильно установленный L2MTU.

Симптомы Ниже приведен список возможных симптомов, которые могут быть результатом такой неправильной конфигурации:

Решение Увеличьте L2MTU на ведомых интерфейсах перед изменением MTU на основном интерфейсе.

/interface ethernet
set ether1,ether2 l2mtu=9018
/interface vlan
set VLAN99 mtu=9000

Несоответствие MTU

Рассмотрим следующий сценарий: у вас есть несколько устройств в вашей сети, большинство из них используются в качестве коммутатора/bridge, и есть определенные конечные точки, предназначенные для приема и обработки трафика. Чтобы уменьшить нагрузку в сети, вы решаете увеличить размер MTU, устанавливая более крупный размер MTU на обеих конечных точках. Однако вы замечаете, что некоторые пакеты отбрасываются.

Alt text

Конфигурация

В данном случае обе конечные точки могут быть любым типом устройства, предположим, что это два сервера Linux, предназначенные для передачи большого объема данных. В таком сценарии вы, вероятно, установили размер MTU интерфейса в 9000 на ServerA и ServerB, а на вашем коммутаторе, возможно, установили что-то подобное следующему:

/interface bridge
add name=bridge1
/interface bridge port
add interface=ether1 bridge=bridge1
add interface=ether2 bridge=bridge1

Проблема

Это очень упрощенная проблема, но в больших сетях ее может быть не так легко обнаружить. Например, ping может работать, так как обычный пакет ping будет иметь длину 70 байт (14 байт для заголовка Ethernet, 20 байт для заголовка IPv4, 8 байт для заголовка ICMP, 28 байт для полезной нагрузки ICMP). Однако передача данных может не работать должным образом. Некоторые пакеты могут не пересылаться, потому что устройства MikroTik с RouterOS по умолчанию имеют MTU, установленный в 1500, и L2MTU, установленный примерно в 1580 байт (зависит от устройства), и интерфейс Ethernet молча отбросит все, что не умещается в размер L2MTU. Обратите внимание, что параметр L2MTU не имеет отношения к устройствам x86 или CHR. Для устройства, предназначенного только для пересылки пакетов, нет необходимости увеличивать размер MTU, достаточно увеличить размер L2MTU; RouterOS не позволит вам увеличить размер MTU больше размера L2MTU. Если требуется, чтобы пакет был получен на интерфейсе и устройство должно обработать этот пакет, а не просто пересылать его (например, в случае маршрутизации), тогда необходимо увеличить размер и L2MTU, и MTU, но вы можете оставить размер MTU на интерфейсе значением по умолчанию, если вы используете только IP-трафик (который поддерживает фрагментацию пакетов) и вас не беспокоит фрагментация пакетов. Можно использовать утилиту ping, чтобы убедиться, что все устройства могут пересылать jumbo-фреймы:

/ping 192.168.88.1 size=9000 do-not-fragment

Помните, что размеры L2MTU и MTU должны быть больше или равны размеру пакета ping на устройстве, с которого и на которое вы отправляете пакет ping, так как ping (ICMP) - это IP-трафик, отправляемый из интерфейса через уровень 3.

Симптомы

Ниже приведен список возможных симптомов, которые могут быть результатом такой конфигурационной ошибки:

Решение

Увеличьте размер L2MTU на вашем коммутаторе:

/interface ethernet
set ether1,ether2 l2mtu=9000

В случае, если ваш трафик инкапсулирован (VLAN, VPN, MPLS, VPLS или другие), вам, возможно, придется рассмотреть установку еще большего размера L2MTU. В этом сценарии нет необходимости увеличивать размер MTU по вышеописанным причинам.

Полный размер MTU фрейма не совпадает с размером L2MTU. Размер L2MTU не включает в себя заголовок Ethernet (14 байт) и поле CRC-контрольной суммы (FCS). Поле FCS удаляется драйвером Ethernet, и RouterOS никогда не покажет дополнительные 4 байта в любом пакете. Например, если вы установили размер MTU и L2MTU равными 9000, то полный размер MTU фрейма составит 9014 байт, что также можно наблюдать при перехвате пакетов с помощью команды /tool sniffer quick.

Bridge и зарезервированные MAC-адреса

Рассмотрим следующий сценарий: вы хотите прозрачно объединить два сегмента сети, будь то интерфейсы туннеля, такие как EoIP, беспроводные интерфейсы, интерфейсы Ethernet или любые другие типы интерфейсов, которые можно добавить в bridge. Такая настройка позволяет вам бесшовно соединять два устройства, как если бы между ними был только физический кабель. Это иногда называется прозрачным мостом от УстройстваA к УстройствуB.

Конфигурация Для обоих устройств, УстройстваA и УстройстваB, должна быть очень похожая конфигурация.

/interface bridge
add name=bridge1 protocol-mode=rstp
/interface bridge port
add interface=ether1 bridge=bridge1
add interface=eoip1 bridge=bridge1

Проблема Оба устройства могут обмениваться данными, но некоторые протоколы работают неправильно. Причина в том, что при использовании любого варианта STP (STP, RSTP, MSTP) bridge становится совместимым с IEEE 802.1D и IEEE 802.1Q. Эти стандарты рекомендуют не пересылать пакеты, предназначенные для 01:80:C2:00:00:0X. В случае, когда в bridge добавлено всего 2 порта (R/M)STP не следует использовать, поскольку петля не может возникнуть с 2 интерфейсов, и если петля все же возникнет, причина кроется в другом месте и ее следует устранить в друг bridge-е. Поскольку (R/M)STP не нужен в настройках bridge, его можно отключить. Как только (R/M)STP отключен, bridge RouterOS не соблюдает стандарты IEEE 802.1D и IEEE 802.1Q, и, следовательно, будет пересылать пакеты, предназначенные для 01:80:C2:00:00:0X.

Симптомы Ниже приведен список возможных симптомов, которые могут быть следствием такой неправильной конфигурации:

Решение Начиная с RouterOS v6.43, можно частично отключить соответствие стандартам IEEE 802.1D и IEEE 802.1Q, изменив режим протокола bridge.

/interface bridge
set bridge1 protocol-mode=none

Стандарт IEEE 802.1x предназначен для использования между коммутатором и клиентом напрямую. Если возможно подключить устройство между коммутатором и клиентом, это создает угрозу безопасности. По этой причине не рекомендуется отключать соответствие стандартам IEEE 802.1D и IEEE 802.1Q, а лучше разработать правильную топологию сети.

Объединение Wireless интерфейсов

Рассмотрим следующий сценарий: вы настроили несколько Wireless интерфейсов и решили объединить интерфейсы Ethernet для достижения максимальной пропускной способности и обеспечения избыточности. В зависимости от передаваемого трафика вы выбрали определенный режим объединения. Этот сценарий может быть применен в любом случае, где создается bonding интерфейс между интерфейсами, которые не являются прямо подключенными друг к другу.

Alt text

/interface bonding
add mode=802.3ad name=bond1 slaves=ether1,ether2 transmit-hash-policy=layer-2-and-3
/ip address
add address=192.168.1.X/24 interface=bond1

Данная конфигурация относится к устройствам R1 и R2. Следующая конфигурация применяется к устройствам AP1, AP2, ST1 и ST2, где X соответствует IP-адресу каждого устройства.

/interface bridge
add name=bridge1 protocol-mode=none
/interface bridge port
add interface=ether1 bridge=bridge1
add interface=wlan1 bridge=bridge1
/ip address
add address=192.168.1.X/24 interface=bridge1

Проблема Во время правильной пересылки трафика между R1 и R2, балансировки нагрузки и переключения на резервный канал работают правильно, но устройства между R1 и R2 не всегда доступны, и некоторые из них совершенно недоступны (в большинстве случаев AP2 и ST2 недоступны). При рассмотрении проблемы можно заметить, что пакеты не всегда пересылаются через необходимый интерфейс, и, следовательно, они никогда не достигают устройства, к которому вы пытаетесь получить доступ. Это ограничение сетевого дизайна и протокола bonding. Как только пакет должен быть отправлен через bonding интерфейс (в данном случае, возможно, вы пытаетесь отправить ICMP-пакеты к AP2 или ST2), интерфейс bonding создаст хеш на основе выбранного режима bonding и политики передачи хеша, и выберет интерфейс, через который отправить пакет, независимо от того, что назначение доступно только через определенный интерфейс. Некоторые устройства будут доступны, потому что созданный хеш соответствует интерфейсу, на котором расположено устройство, но он может также не выбрать нужный интерфейс, что приведет к недоступности устройства. Только режим объединения “broadcast” не имеет такого ограничения протокола, но у этого режима есть очень ограниченное применение.

Симптомы Ниже приведен список возможных симптомов, которые могут быть результатом такой неправильной конфигурации:

Решение Интерфейсы bonding не должны быть подключены с использованием непрямых связей, но всегда можно создать обходное решение. Идея этого обходного решения заключается в том, чтобы найти способ обойти отправку пакетов через интерфейс bonding. Есть несколько способов заставить пакет не отправляться через интерфейс bonding, но, по сути, решение заключается в создании новых интерфейсов поверх физических интерфейсов и добавлении этих вновь созданных интерфейсов в bonding вместо физических интерфейсов. Один из способов добиться этого - создать туннели EoIP на каждом физическом интерфейсе, но это создаст значительный оверхед и снизит общую пропускную способность. Более эффективным способом является создание VLAN-интерфейса поверх каждого физического интерфейса; это создает гораздо меньший оверхед и практически не влияет на общую производительность. Вот пример того, как нужно изменить конфигурацию R1 и R2:

/interface vlan
add interface=ether1 name=VLAN_ether1 vlan-id=999
add interface=ether2 name=VLAN_ether2 vlan-id=999
/interface bonding
add mode=balance-xor name=bond1 slaves=VLAN_ether1,VLAN_ether2 transmit-hash-policy=layer-2-and-3
/ip address
add address=192.168.1.X/24 interface=bond1
add address=192.168.11.X/24 interface=ether1
add address=192.168.22.X/24 interface=ether2

AP1 и ST1 нуждаются только в обновленных IP-адресах в соответствующем подсети:

/ip address
add address=192.168.11.X/24 interface=bridge1

Те же изменения следует внести для AP2 и ST2 (обязательно используйте правильную подсеть):

/ip address
add address=192.168.22.X/24 interface=bridge1

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

Примечание: LACP (802.3ad) не предназначен для использования в ситуациях, где устройства, объединяющие рабочие каналы, не подключены напрямую. В этом случае не рекомендуется использовать LACP, если между обоими маршрутизаторами есть беспроводные связи. LACP требует, чтобы оба рабочих канала имели одинаковую скорость, а беспроводные связи могут изменять свою скорость в любое время, что приведет к уменьшению общей производительности и стабильности. Вместо этого следует использовать другие режимы bonding.

Тестирование пропускной способности

Рассмотрим следующий сценарий: вы настроили соединение между двумя устройствами, это может быть любое соединение, Ethernet-кабель, беспроводное соединение, туннель или любое другое. Вы решаете протестировать пропускную способность соединения, но из-за удобства решаете начать тестирование соединения на тех же устройствах, которые выполняют соединение.

Alt text

Проблема

Как только вы начинаете тестирование пропускной способности или генерацию трафика, вы замечаете, что пропускная способность значительно меньше ожидаемой. Даже для очень мощных маршрутизаторов, которые должны способны передавать много гигабит в секунду (Gbps), вы замечаете, что передается всего несколько гигабит в секунду. Причина этого заключается в методе тестирования, который вы используете. Никогда не следует тестировать пропускную способность маршрутизатора, используя тот же самый маршрутизатор для генерации трафика, потому что вы добавляете дополнительную нагрузку на ЦП, что уменьшает общую пропускную способность.

Симптомы

Ниже приведен список возможных симптомов, которые могут быть результатом такого рода некорректной настройки:

Решение

Используйте правильный метод тестирования. Не используйте Bandwidth-test для тестирования соединений с большой пропускной способностью, и не запускайте инструменты, генерирующие трафик, на том же устройстве, которое вы тестируете. Проектируйте вашу сеть правильно, чтобы можно было подключить устройства, которые будут генерировать и принимать трафик с обоих концов. Если вы знакомы с Iperf, то это понятие должно быть вам понятно. Помните, что в реальном мире маршрутизатор или коммутатор не генерирует большие объемы трафика (по крайней мере, не должен, иначе это может указывать на существующую проблему безопасности), сервер/клиент генерирует трафик, в то время как маршрутизатор/коммутатор пересылает трафик (и выполняет некоторые манипуляции с трафиком в соответствующих случаях).

Alt text

Использование Bridge split-horizon

Рассмотрим следующий сценарий: у вас есть bridge, и вам необходимо изолировать определенные порты bridge-a друг от друга. Есть опции использования встроенного чипа коммутации для изоляции определенных портов на определенных микросхемах коммутаторов, вы можете использовать правила bridge firewall для предотвращения передачи трафика с определенных портов на другие, вы можете изолировать порты в настройках типа PVLAN с использованием изоляции портов, но также есть программное решение - использование механизма bridge split-horizon (который отключает аппаратное ускорение на всех микросхемах коммутаторов).

Конфигурация

/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 horizon=1 hw=no interface=ether1
add bridge=bridge1 horizon=2 hw=no interface=ether2
add bridge=bridge1 horizon=3 hw=no interface=ether3
add bridge=bridge1 horizon=4 hw=no interface=ether4

Проблема

После установки bridge split-horizon на каждом порту, вы начинаете замечать, что каждый порт все равно способен передавать данные между собой. Причина этого заключается в неправильном использовании bridge split-horizon. Порт bridge-a не может общаться только с портами в том же horizon, например, horizon=1 не может общаться с horizon=1, но может общаться с horizon=2, horizon=3 и так далее.

Симптомы

Ниже приведен список возможных симптомов, которые могут быть результатом такого неправильной конфигурации:

Решение

Установите правильное значение для bridge split-horizon. В случае, если вы хотите изолировать каждый порт друг от друга (обычный сценарий для настроек PPPoE) и каждый порт может общаться только с самим bridge, то все порты должны быть в одном и том же bridge split-horizon.

/interface bridge port
set [f] horizon=1

Установка всех портов моста в один и тот же bridge split-horizon приведет к тому, что трафик сможет достигать только самого интерфейса моста, а затем пакеты могут быть только маршрутизированы. Это полезно, когда вы хотите, чтобы другие устройства фильтровали определенный трафик. Аналогичное поведение можно достичь с использованием правил filter bridge.

Неподдерживаемые модули SFP

Рассмотрим следующий сценарий: вы решили использовать оптоволоконные кабели для соединения ваших устройств с использованием оптических модулей SFP или SFP+, но для удобства выбрали оптические модули SFP, которые были доступны.

Проблема: Как только вы настроите ваши устройства для обеспечения подключения на портах, использующих эти оптические модули SFP, вы можете заметить, что либо связь работает нормально, либо возникают случайные проблемы с подключением. Существует множество производителей оптических модулей SFP, но не все из них строго следуют стандартам SFP MSA, SFF и IEEE 802.3, что может привести к непредсказуемым проблемам совместимости. Это очень распространенная проблема при использовании малоизвестных или неподдерживаемых оптических модулей SFP в устройствах MikroTik.

Симптомы: Ниже приведен список возможных симптомов, которые могут быть результатом такого рода неправильной конфигурации:

Решение: Вы должны использовать только поддерживаемые модули SFP. Всегда проверяйте таблицу совместимости SFP, если вы планируете использовать модули SFP, произведенные MikroTik. Есть и другие модули SFP, которые также работают с устройствами MikroTik, проверьте таблицу поддерживаемых периферийных устройств, чтобы найти другие модули SFP, подтвержденные для работы с устройствами MikroTik. Некоторые неподдерживаемые модули могут работать неправильно при определенных скоростях и с автосогласованием. Вам, возможно, захочется отключить его и вручную установить скорость соединения.

Поделиться

Обсуждение