Как в NetBox проследить конкретную ветку MPO-breakout через оптическую кассету

Если трассировка кабеля в NetBox упирается в кассету и дальше показывает «конец пути», хотя физически волокно идёт дальше на LC-порт свитча, — первым делом проверьте карту соответствий FrontPort/RearPort на самой кассете, а если транк заканчивается веером, то и профиль кабеля. Ниже — как это устроено в модели данных NetBox 4.5+ и как я развожу такую схему на практике.

Симптом: трассировка обрывается на кассете

Типичная жалоба проектировщика ЛКС, который только начал заносить оптику в NetBox: транковый MPO-кабель от коммутационной панели в серверной до кассеты в другой стойке заведён, кассета заведена, LC-патчкорды от кассеты до портов свитчей — тоже. Но кнопка «Trace» на порту свитча доходит до кассеты и останавливается, хотя физически волокно тянется через весь транк до порта на другом конце. В интерфейсе это выглядит как разрыв пути там, где разрыва нет.

Причина почти всегда одна: кабели заведены как простые point-to-point связи без разметки того, как конкретные волокна внутри MPO-транка соответствуют друг другу на двух концах, а сама кассета заведена как чёрный ящик — рэковый порт есть, а того, какая позиция транка соответствует какому LC-порту на лицевой панели, в модели нет. NetBox в такой ситуации ведёт себя ожидаемо: раз он не знает внутреннюю структуру транка и кассеты, он не может продолжить трассировку дальше уровня «кабель существует, оба конца подключены». Это ровно тот пробел, который я закрываю на этапе внедрения NetBox для клиентов с плотной оптикой — без карты портов кассеты вся остальная разметка теряет смысл.

У меня был почти такой же запрос от клиента — юридической фирмы «ПравоГрад» (30 рабочих мест, разберу кейс ниже). Инженер занёс всю физику в NetBox за два дня, обрадовался, что документация наконец есть, а на третий день попытался найти по интерфейсу свитча, через какую именно жилу транка и какой порт кассеты идёт связь — и трассировка молчала после кассеты. Решение не в дополнительных кабелях, а в двух полях, которые часто пропускают при первом заведении оптики: Cable.profile у транка и карта портов у кассеты.

Физика связки: транк → кассета → LC-патчкорд

Стандартная топология для density-плотной оптики выглядит так: MPO/MTP-транк на 12 волокон приходит с одного конца в MPO-адаптер на задней стороне кассеты, а на лицевой панели той же кассеты — 12 (или 6, если кассета дуплексная) LC-адаптеров, разведённых внутри кассеты по отдельным жилам. От LC-адаптеров уже идут обычные дуплексные LC-патчкорды до портов свитчей. Кассета физически разбивает один 12-волоконный транк на 6 дуплексных LC-соединений или на 12 симплексных — в зависимости от конструкции.

В модели данных NetBox это описывается тремя разными объектами с разной ролью. Сам MPO-транк — это Cable между двумя RearPort (задний, «магистральный» порт панели и задний порт кассеты). Кассета описывается как отдельное устройство (обычно device type с ролью «patch panel» или «fiber cassette»), у которого есть RearPort с несколькими позициями (тот самый разъём под транк) и несколько FrontPort — по одному на каждый LC-адаптер на лицевой панели. И наконец LC-патчкорд от кассеты до свитча — снова обычный Cable, но уже между FrontPort кассеты и Interface свитча.

Официальная документация по модели RearPort прямо приводит этот сценарий как хрестоматийный пример: «MPO fiber termination cassette might have a single 12-strand rear port mapped to 12 discrete front ports, each terminating a single fiber strand» — то есть кассета с одним 12-волоконным задним портом, размеченным на 12 отдельных передних портов, каждый из которых терминирует одну жилу. Это ровно та схема, которую нужно занести, чтобы трассировка не обрывалась. В общем разборе документации инфраструктуры в NetBox я уже писал, что порядок в стойках без порядка в кабельной системе — половина дела; оптика с кассетами обычно и есть та часть, которую заводят последней и хуже всего.

Cable Profile: когда он нужен MPO-транку, а когда нет

Поле profile у объекта Cable появилось в NetBox 4.5.0 (issue #20788). По формулировке release notes, профиль задаёт число дискретных параллельных каналов («lanes»), которые кабель несёт между концами: например, у breakout-кабеля 1-к-4 четыре канала, общие на одном конце и разведённые на четыре отдельные терминации на другом. Поле необязательное: если профиль не назначен, «legacy tracing behavior will be preserved». И тут важная для практики вещь, которую часто упускают: классическая связка «MPO RearPort панели — кабель — MPO RearPort кассеты» с одинаковым числом позиций трассировалась по позициям и до 4.5 — именно так в NetBox годами моделировали патч-панели. Поэтому если Trace обрывается на прямом транке между двумя кассетами, виноват почти всегда не отсутствующий профиль, а карта портов (о ней — в следующем разделе).

Без профиля не обойтись там, где у кабеля на одном конце один многопозиционный разъём, а на другом — несколько отдельных терминаций: MPO-«гидра» с веером LC, breakout 40G→4×10G и т. п. В обсуждении #21104 пользователь с кассетой «1 MPO сзади, 6 LC спереди» и breakout-кабелем описывает ровно этот эффект: без профиля трассировка показывает все шесть устройств подключёнными к каждому порту сразу. Честное предупреждение про документацию: страница модели Cable до сих пор перечисляет профили как «Straight (single position), Straight (multi-position), Shuffle (2x2 MPO8), Shuffle (4x4 MPO8)», но в коде (dcim/choices.py) и в выпадающем списке интерфейса их давно зовут иначе — по формуле «число коннекторов C × число позиций P»: группа Single (1C1P … 1C16P), группа Trunk (2C1P … 8C4P, плюс варианты 2C4P и 4C4P с пометкой shuffle) и группа Breakout (1C4P:4C1P, 1C6P:6C1P, 2C4P:8C1P shuffle). Для прямого 12-волоконного MPO-транка «разъём в разъём» это 1C12P, для «гидры» MPO → 6 дуплексных LC — 1C6P:6C1P.

Каталог профилей пополняется точечно: в 4.5.7 добавлен breakout «1C2P:2C1P» (issue #21760), в 4.6.0 — «1C8P:8C1P» (issue #22279). Формат имени описан и в блоге NetBox Labs про Cable Profiles: «1C4P:4C1P» означает один 4-позиционный коннектор на одной стороне, разведённый в четыре одиночных коннектора на другой. Готового профиля «1C12P:12C1P» для веера из 12 симплексных волокон в списке нет — такую разводку проще моделировать через кассету с картой портов, а не одним кабелем. Shuffle-варианты нужны, когда пары волокон физически переставлены под схему полярности. В REST API профиль передаётся не подписью, а значением вида single-1c12p или breakout-1c6p-6c1p — сверяйте список в своей версии NetBox перед тем, как проектировать схему под конкретный код.

PortMapping: как кассета делит транк на отдельные LC-порты

Профиль размечает сам провод, но не объясняет, как разведены порты внутри кассеты. За это отвечает второй механизм, тоже добавленный в NetBox 4.5 (issue #20564, «Advanced Port Mappings»): поля rear_port и rear_port_position, которые раньше жили прямо на модели FrontPort и жёстко привязывали один передний порт к одной позиции одного заднего порта, убраны. Вместо них — промежуточная модель PortMapping, которая поддерживает произвольное число связей между парой «FrontPort + позиция» и парой «RearPort + позиция». По формулировке из release notes, это «unlocks the ability to model complex inline devices that swap individual fiber pairs between cables» — то есть именно устройства вроде оптических кассет, которые внутри себя переставляют жилы.

На практике это выражается в двух полях при создании FrontPort: Positions — сколько позиций заднего порта этот передний порт покрывает (для простого симплексного LC-адаптера кассеты — 1, для дуплексного — 2), и Rear Ports — собственно список пар «задний порт + позиция», к которым передний порт подключён. При массовом создании портов с шаблонным именем (LC[1-12]) NetBox ожидает по одной записи маппинга на каждую позицию каждого создаваемого порта — то есть для 12 симплексных LC-портов, покрывающих 12-волоконный транк один-к-одному, нужно 12 записей маппинга, а не одна на весь диапазон.

У модели RearPort симметричное поле Positions — число позиций, доступных для маппинга на передние порты; в примере с 12-волоконной MPO-кассетой это 12. Мой практический совет: заводите кассету как отдельный device type с явно заданными шаблонами RearPort (positions=12) и FrontPort (по одному на LC-адаптер, positions=1, с explicit rear-port-position mapping) один раз, а не руками на каждом физическом экземпляре — тогда при добавлении второй, третьей кассеты того же типа вся разводка проставляется автоматически при создании устройства из шаблона.

Пошагово: заводим транк и кассету так, чтобы трассировка не обрывалась

Порядок, который у меня работает стабильно. Сначала — device type кассеты: один RearPort с типом MPO (в списке типов портов NetBox он один, без деления на MPO-8/MPO-12) и Positions = 12 (или сколько волокон у вашего транка), и 6 или 12 FrontPort с типом LC (симплекс или дуплекс, по конструкции кассеты). У каждого FrontPort в поле Rear Ports — привязка к нужной позиции того самого RearPort; при дуплексных LC-портах на один FrontPort приходится Positions = 2 и две записи маппинга (например, позиции 1 и 2 транка — на первый дуплексный LC-порт).

Дальше — сам транк. Заводите Cable между RearPort стоечной MPO-панели и RearPort кассеты. В поле profile я ставлю 1C12P для прямого 12-волоконного транка — не потому, что без него трассировка не пойдёт, а чтобы связь была описана явно и одинаково на всех транках; shuffle-вариант — только если волокна физически переставлены, breakout — если на одном из концов веер вместо второго MPO. Это не отдельная сущность, а поле на уже привычной форме создания кабеля.

Патчкорды от FrontPort кассеты до интерфейсов свитчей заводятся как обычные Cable без профиля — здесь никакой внутренней структуры нет, это уже прямой дуплексный линк. После того как все три звена — стоечная панель, транк с профилем, кассета с картой FrontPort/RearPort, патчкорды — на месте, «Trace» с интерфейса свитча проходит через кассету и транк насквозь и показывает конечную точку на удалённой панели, а не обрывается на кассете, как было в исходной жалобе клиента.

Проверка через REST API устроена так же, как через UI — поле profile доступно на /api/dcim/cables/ как обычное choice-поле со значениями-слагами (токен в формате v2, который рекомендован с 4.5):

curl -s -H "Authorization: Bearer $NB_TOKEN" \
  "https://netbox.example.com/api/dcim/cables/?profile=single-1c12p"

Это удобно, чтобы одним запросом получить все размеченные транки и сравнить их со списком MPO-кабелей: разница — это то, что ещё не размечено. Обычно после первичного переноса инфраструктуры в NetBox таких кабелей остаётся немало, и я прохожусь по ним отдельным списком уже после базового заведения топологии.

Что проверить перед тем, как полагаться на трассировку

Функциональность Cable Profile и PortMapping относительно новая — появилась в 4.5, и в патч-релизах на неё продолжают закрывать баги. В release notes зафиксированы как минимум два случая, которые стоит держать в голове: issue #21653 — трассировка по профилю работала некорректно, когда одна точка происхождения несёт сразу несколько позиций (частый случай именно для MPO-транков), и issue #21917 — неверные peer-порты для задних портов, соединённых через trunk-профиль кабеля. Оба исправлены в линейке 4.5.x (в 4.5.5 и 4.5.9 соответственно), а в 4.6 закрыт ещё и ошибочный повторный пересчёт пути при использовании профиля (#22187) — это повод не считать первую же попытку трассировки эталоном истины без визуальной проверки — сверьте результат хотя бы на одной ветке руками, физически прозвонив волокно.

Второй практический момент — сообщество прямо отмечает, что документация по Cable Profile на момент выхода функции была неполной, и часть пользователей в обсуждениях советовала повременить с массовым использованием профилей до появления более подробных примеров. Я не разделяю этот совет буквально: для простого случая «прямой multi-position транк + кассета с явной картой портов», который нужен в 90 % малых и средних инфраструктур, схема работает предсказуемо. Но если у вас нестандартная полярность, каскад из нескольких кассет подряд или смешение shuffle- и straight-профилей на одном пути — закладывайте время на тестовую трассировку и проверку граничных случаев перед тем, как строить на этом автоматизацию (например, генерацию конфигов по данным NetBox).

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

Кейс: правовое консультирование «ПравоГрад», 30 рабочих мест

У клиента — одна серверная с MPO-транками до двух коммутационных стоек на разных этажах, шесть 12-волоконных транков суммарно, каждый заходит в кассету и дальше расходится дуплексными LC-патчкордами на порты access-свитчей. До обращения к нам инфраструктура была занесена в NetBox частично: панели и свитчи как устройства были, кабели между ними — тоже, но без профилей и без карты портов на кассетах, потому что инженер клиента заводил оптику по той же схеме, что и обычные медные патчкорды, не зная про Cable Profile и PortMapping.

Мы завели корректный device type для используемой модели кассеты (RearPort MPO-12 с positions=12, 6 дуплексных LC FrontPort с явной картой на пары позиций транка), переразметили шесть транков профилем 1C12P — физическая полярность у клиента была прямой, без перестановки волокон, — и перезавели патчкорды от кассет до свитчей как отдельные кабели без профиля. Заодно актуализировали общую сегментацию сети по VLAN в этих двух стойках — оптика и VLAN у клиента заводились в NetBox разными сотрудниками в разное время, и часть подписей портов на схеме уже разошлась с реальным подключением. На перезаведение шести транков с кассетами ушло около четырёх часов, включая сверку с реальной физической разводкой по паре волокон на каждом транке.

Результат клиент оценил не в момент внедрения, а через три недели, когда один из LC-патчкордов от кассеты до свитча в серверной физически перетёрся и связь пропала. NetBox, конечно, не видит обрыв — он знает только документированный путь. Но Trace от порта свитча до панели в другой стойке за минуту показал всю цепочку: какой патчкорд, какой LC-порт кассеты, какие позиции транка и какой порт удалённой панели. Инженер проверил оптическим тестером две точки — выход кассеты и порт свитча, — нашёл неисправный патчкорд и заменил его, а не начал прозванивать весь транк заново, как делал бы без размеченной топологии.

Частые вопросы