Документирование сети

[ALEX_SE]

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

Как бы лучше документировать сеть? До уровня коммутаторов и выше.

 

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

 

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

 

Или таки у моей проблемы нет решения и единственный вариант это вести 2 паралельные схемы (логическую и физическую)? но в таком случае и число потенциальных ошибок возрастает в 2 раза. А всплывают они как правило в самый неподходящий момент - например при аврале когда идет поиск неисправности.

Специализированного ПО у меня нет.

 

Есть мнения как лучше сделать или примеры?

[lugoblin]

В такой общей формулировке на пальцах не объяснить.

Читайте обзоры, например https://habr.com/ru/post/134892/

 

Конкретно относительно "невозможно работать", это так, надо вести N паралельных схем. Очень распостранённая ошибка пытаться на одной схеме уместить все нужные детали. По моему опыту, требуется по меньщей мере 3 типа схем:

- На уровне 3 модели OSI. В ней узлами будут маршрутизаторы и коммутаторы Л3, а коммутаторы Л2 будут выглядеть просто как хосты. Делать отдельно отдельно для каждой локации.

- На уровне 2 модели OSI. В ней будут указанны физические линки Л1 между устройствами и их природа на Л2. Делать отдельно отдельно для каждой локации.

- Схема WAN, гибрид между Л2 и Л3, но рисуется сеть только между географически разнесёнными площадками.

 

[ALEX_SE]

Да я в общем-то то же к этому пришел.

Схема подключения девайсов графическая не нужна - это все есть в табличке.

Тут именно вопрос в топологии и логической схеме. 

По логической вполне можно тестировать сеть, смотреть связи, проверять и настраивать STP, ERPS, VLAN и т.д. 

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

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

Отдельно для каждой локации в моем случае наверное не имеет смысла так как в каждой локации девайсов не более 5-6. Самих локаций полтора десятка.

 

[Saab95]

В табличке ведете учет оборудования и настроек.

В графической схеме типа визио рисуете графическую схему сети с привязкой к адресам, то есть квадратик это некий дом, внутри него рисуете оборудование и связи с подписью портов и IP адресов на них.

В гуглмапс рисуете схему связей на местности.

 

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

[frol13]

Вставлю свои 3 коп. На уровне проектирования тоже часто нельзя разобраться во всех этих связях и совместить логическую топологию с физической. Придумана для этих целей схема организации связи, которую доблестные проектанты часто игнорят в своих проектах. Она опирается на логическую, но все основные узлы (или вообще все, если их там не так много) идут с привязкой к физическому адресу и каждая свзяь, подразумевающая кабельную линию, расписывается с указанием, что это - например, нарисован значок оптики, стандарт ОВ, скажем, G.652,емкость кабеля, протяженность и затухание, способ прокладки. На интерфейсах указан тип, длина волны, количество портов. Таким образом, видна работоспособна ли система и легко проверить, обеспечивает ли она те характеристики, которые заявлены. Для систем с TDMA расписывается количество тайм-слотов и ведется их таблица (поскольку там можно попасть в засаду их нехватки при пробросе их).       

[ALEX_SE]

Quote

В табличке ведете учет оборудования и настроек.

Так и происходит потом вывалю все в БД. Только еще не решил как лучше организовать. Таблички совсем неудобная штука. Но в общем да - подключения конечных клиентов, их описания, настройки - все есть.

 

2 hours ago, Saab95 said:

В графической схеме типа визио рисуете графическую схему сети с привязкой к адресам, то есть квадратик это некий дом, внутри него рисуете оборудование и связи с подписью портов и IP адресов на них.

Я в автокаде но не суть принципиально. Тут и проблема кстати сразу. Если дома располагать хаотично без привязки к взаимному расположению то в принципе можно однако работать со схемой неудобно. Если же грубо гаворя всзять за основу генплан объекта (ну или гуглмапс) и рисовать уже на нем с привязкой что и где находится и что и как идет - получается тихий ужас. Сеть никто не продумывал заранее делалось в 5 или 6 этапов по мере необходимости часто короткими отрезками между случайными строениями. Представляете что там получится на этой схеме если её делать с привязкой к строениям и трассами кабелей :))

 

Юзерсайды и прочее можно конечно рассмотреть, человеков несколько если рассматривать все сети на предприятии (они разделены физически но кабели часто используются общие). Более умные системы типа того же мобайлкросс или тем более такие монстры как аргус все это умеют, там еще и мониторинг, там и подсветка трасс (трассировка) там и учет кроссов. Но пока я так понял планов на приобретение нет.

 

2 hours ago, frol13 said:

На уровне проектирования тоже часто нельзя разобраться во всех этих связях и совместить логическую топологию с физической.

Тут уже много что сделано вот и надо во-первых понимать куда двигаться при расширении а главное понимать на сколько оптимально сделать отказоустойчивость.

 

2 hours ago, frol13 said:

каждая свзяь, подразумевающая кабельную линию, расписывается с указанием, что это - например, нарисован значок оптики, стандарт ОВ, скажем, G.652,емкость кабеля, протяженность и затухание, способ прокладки.

Так и делаем но это касается только кабелей до кросса и между ними без привязки к оборудованию.

[frol13]

42 минуты назад, ALEX_SE сказал:

Так и делаем но это касается только кабелей до кросса и между ними без привязки к оборудованию.

Без привязки к оборудованию-бестолковый номер

[ALEX_SE]

45 minutes ago, frol13 said:

Без привязки к оборудованию-бестолковый номер

А с привязкой ничего понять невозможно :) Я имею в виду привязку на схеме а не в таблицах разварки кроссов.

[frol13]

3 часа назад, ALEX_SE сказал:

А с привязкой ничего понять невозможно :) Я имею в виду привязку на схеме а не в таблицах разварки кроссов.

Насчет привязки кабелей к оборудованию. Вся суть в этом и есть (по крайней мере, при проектировании и проверке функционионирования). Часто может выясниться, что волокон там не хватает, какие там конверторы или SFP применены на какую длину волны и сколько дБ, хрен его знает. Применение всякого мультиплексирования вообще чревато затыками без подробного расписывания потоков. Имеется ввиду логическая схема. Также может оказаться, что кроссовые устройства не предназначены для ввода такого количества кабелей, поэтому их желательно укрупненным квадратиком указывать с местом их расположения. Сколько раз при ремонтах у энергетиков сталкивались, что по наличествующим схемам соединений очень сложно понять, схему прохождения сигналов с учетом всяких штанов, перекроссировок и проч, и где это территориально расположено и сколько там будет нормой затухание, а сколько - нет. Глядишь в эти "портянки" и не понимаешь, а где эти чертовы кроссы расположены, в каких именно помещениях, какова протяженность кабелей между ними и их типы.:( 

Ну и стандартная беда при реализации проектов - все время выпадают соединительные шнуры и кабели внутренние. Начинают соединять все при запуске - а их нет:) А они по стыку идут между станционной и линейной частью - никто у себя не предусмотрел в проектах.:)      

[ALEX_SE]

Я имел в виду активное оборудованию :) Что нужна схема с ЛКС привязанная к местности всецело согласен. И делаю такие :) 

[frol13]

1 минуту назад, ALEX_SE сказал:

Я имел в виду активное оборудованию

По активному оборудованию. Схема организации связи предполагает указания по соединению интерфейсов и через что они соединяются. Иначе понять невозможно работоспособность. Был эпический случай - всю систему связи опробовали, стали присоединять к АСУ, а там массовая нестыковка интерфейсов RS232 и RS485. Пришлось кучу конверторов срочно приобретать. Один раз тайм-слотов не хватило - не учли, что в транзитном узле их недостаточно. Ну и т.п.    

[ALEX_SE]

Ну это понятно. Просто тут уже все есть. :) Делалось в разное время разными людьми с разным подходом или как это правильнее "видением", по хрен знает какой документации... такую же кстати и после себя оставили.... Сейчас все это более-менее знает 2 человека. И то конечно забывается и в случае срочных работ время на пару кроссировок исчасляется уже часами... 

[frol13]

1 минуту назад, ALEX_SE сказал:

Просто тут уже все есть. :) Делалось в разное время разными людьми с разным подходом или как это правильнее "видением", по хрен знает какой документации...

Вот когда "клюнет", то начинаются разборы: а какое направление у нас основное, а какое резервное? А как они там хотя бы укрупненно (через какие адреса проброшены? ). Ну и вскрываются там всякие интересные "изустно переданные" подробности, а время идет...

[ALEX_SE]

А так оно и есть. И прибавьте сюда еще идиотские звонки и наезды. Мне проще я в не ИТ и у меня хоть резервы есть и некоторые сети поновее. Но с документацией все-равно не все идеально :(