Привет, Хабр!

Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги.

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

Однако есть в сетевой архитектуре место, где рождается большинство проблем, и при этом ему уделяют меньше всего внимания на этапе проектирования.

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

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

А потом мы получаем STP‑штормы в час пик, лавины неизвестного юникаста, всевозможные split‑brain в vPC.

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

Сегодня мы будем говорить не о проблемах конкретного вендора и не про «правильную» топологию. Мы рассмотрим типовые ошибки, которые часто встречаются в реальных проектах, и про то, как их избежать.

Где вообще проходит граница L2/L3 и почему это так важно

Прежде чем говорить об ошибках, нам для начала нужно договориться о терминах.

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

Это скорее логическая демаркация, где сеть перестаёт быть набором broadcast‑доменов и становится набором маршрутизируемых префиксов.

Классическая иерархическая модель предполагает три уровня (access, distribution, core) и исторически граница L2/L3 чаще всего проходила на уровне распределения.

• Так access‑коммутаторы строили L2-домены, а distribution‑коммутаторы (или пара коммутаторов) выполняли роль шлюза по умолчанию и маршрутизировали трафик между VLAN'ами.

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

• На уровне ядра также можно встретить разделение L2/L3, но обычно это встречается в старых сетях и означает, что L2 растянут слишком далеко.

• Разделение может вообще отсутствовать в привычном виде. Так, в современных фабриках (EVPN/VXLAN, ACI) граница L2/L3 размывается из‑за использования anycast gateway на каждом участке L2 поверх L3.

На самом деле выбор границ домена L2 зависит, во‑первых, от его размеров, так как чем он больше, тем больше устройств пострадает от одной проблемы.

• Во‑вторых, он зависит от скорости сходимости, ведь STP сходится за секунды, в то время как маршрутизация за миллисекундами.

• Также, в L3 путь пакета детерминирован, а в L2 он зависит от топологии STP, которую мало кто помнит наизусть.

• И последнее по списку, но не по значимости это безопасность. L2-атаки (ARP-spoofing, VLAN hopping, MAC-flooding) возможны только внутри L2-домена.

Здесь основное — это то, что ошибка проектирования не является «неправильной» точкой выбора границы.

Ошибка — это когда точка выбрана без осознания этих последствий.

А теперь давайте поговорим об этих ошибках подробнее.

Слишком большой broadcast‑домен

Самая распространённая и при этом, самая недооценённая ошибка проектирования.

«У нас один VLAN на весь этаж, потому что так проще администрировать» или «Зачем дробить, если это одна организация?».

И здесь проблема заключается в том, что broadcast‑домен — это, по сути, единый домен отказов.

Внутри него находится STP‑топология, которая определяет пути фреймов, и ошибка в конфигурации или отказ линка автоматически приводит к перестройке (то есть простою сети), которая затрагивает всех.

Аналогично broadcast‑трафик (ARP, DHCP, NetBIOS, mDNS) достигает каждого устройства, и в большом домене это уже не «фон», а заметная нагрузка.

Здесь стоит усвоить простое практическое правило: если вы не можете назвать точное число устройств в VLAN и объяснить, почему их должно быть именно столько, то вы не контролируете свой broadcast‑домен.

Можно предложить следующие разумные ориентиры:

• До 200–250 хостов на VLAN — комфортно для большинства сценариев.

• До 500 — терпимо, но требует мониторинга и дисциплины.

• Больше 1000 — почти всегда признак того, что границу L2/L3 пора двигать ближе к доступу.

Важно понимать, что микросегментация — это не дань моде, а инженерная необходимость.

Так VLAN на порт (или на небольшую группу портов) в сочетании с routed access даёт предсказуемость, которую невозможно получить в плоской L2-сети.

Размытая ответственность между L2 и L3

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

Здесь типичный сценарий представляет собой использование access‑коммутаторов для построения L2, уровень распределения, соответственно, маршрутизирует, но между ними — «серая зона», где STP и маршрутизация работают одновременно и конфликтуют, FHRP настроен на одних устройствах, а фильтрация — на других, в свою очередь, часть VLAN’ов терминируется на одном устройстве, часть — на другом, и никто не может ответить на вопрос «где именно теряется пакет».

Признаками размытой ответственности является:

• Двойной контроль, когда один и тот же трафик проходит и через STP‑домен, и через маршрутизацию, причём пути не согласованы.

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

• Траблшутинг по цепочке, когда инженер идёт от устройства к устройству, потому что нет единой точки, где видно весь путь.

Лечится это не какой‑то «правильной» настройкой, а явной демаркацией, то есть документированным решением о том, где проходит граница, какие функции на какой стороне, и кто за что отвечает.

И если это решение не зафиксировано на бумаге, то считайте, что его нет.

Использование STP там, где нужно L3

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

Маршрутизация на L3 выигрывает у STP по большинству пунктов.

Так, мы уже говорили про время сходимости, которое у маршрутизации намного меньше. Также STP менее предсказуем, чем L3, и это может привести к сюрпризам.

В свою очередь, архитектура IP исключает зацикливание трафика благодаря использованию поля Time To Live (TTL) в пакетах.

Помимо этого, на сетевом уровне у нас прозрачнее диагностика и лучше масштабирование, по сравнению с STP.

Но почему же тогда STP всё ещё живёт в сетях доступа?

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

Также сюда можно добавить использование правила /24 маска на один VLAN, когда дробить было особо нечем.

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

При этом, иногда использование STP всё же будет оправдано. Например, в сценариях, где нужна связность L2 между устройствами (кластеры, live migration без overlay).

Также связующее дерево пригодится в сетях с большим количеством устаревшего оборудования или в маленьких сетях, где переход на L3 просто не окупается.

Но если вы проектируете новую сеть доступа и по умолчанию ставите STP, то вы, скорее всего, делаете это по инерции, а не по расчёту.

Суровый итог

Граница L2/L3 не должна строиться по принципу «так исторически сложилось». Это архитектурное решение, которое определяет, как сеть будет вести себя при отказах, как она будет масштабироваться и насколько легко будет её эксплуатировать.

И здесь важно понимать, что цена ошибки растёт с масштабом самой сети.

В сети на 50 узлов большие broadcast‑домены и размытая демаркация могут годами не проявляться, в то время как в сети на 5000 узлов ошибки станут ежедневной болью, а иногда и причиной крупных инцидентов.

Хороший дизайн границы L2/L3 это не история о «правильном выборе вендор» и не про «модную технологию».

Это про ясное понимание того, где проходит граница и почему именно там, а также, что происходит при отказе, и кто за это отвечает.

Если на эти вопросы есть ответы, то вы действительно спроектировали сеть, но если нет, то вы просто подобрали набор устройств, который однажды перестанет работать предсказуемо.

Где проходит граница между L2 и L3, как устроена маршрутизация и что помогает сделать сетевую инфраструктуру предсказуемее?

Продолжить разбираться в этих вопросах можно на бесплатных открытых уроках OTUS:

• 11 ноября — «Статическая и динамическая маршрутизация». Записаться

• 19 ноября — «OSPF Deep Dive: Практикум по построению карты сети из базы данных маршрутизаторов». Записаться

Больше вебинаров по сетевым технологиям и другим направлениям IT собраны в октябрьском дайджесте.