Валентин

Сеть 10.0.0.0 используют из-за того, что удобно делать сети > /24, а во втором октете можно зашифровать географию (№ офиса, код региона, зону ответственности и т.д., например, 10.77.X.X - адресный диапазон для Москвы).
Конечно, нужно кучу вланов, вы удивитесь, но у вас их будет гораздо больше, чем вы написали. Например, сходу будет влан управления (где будет управление сетевым оборудованием), влан управления серверами (iLo, IPMI, iDRAC или что там у вас), влан с "публичными" IP-адресами (в офисе же будет интернет?), влан серверов для пользователей (файловые шары), влан технологических серверов (всякие сислоги, заббиксы), рано или поздно два влана на вай-фай (гостевой и внутренний), вланы для стыковочных сетей (от L3-коммутатора до маршрутизатора, между L3-коммутаторами и т.д.).

Основная экономическая характеристика коммутатора - цена за порт. Как правило, для телефонии используются порты с PoE, они стоят в 2.5 раза дороже портов без PoE. На сэкономленные деньги лучше купить ЗИП на телефоны.
Когда-то потом вы придете к настройке QoS для телефонии по крайней мере на линках от агрегации. Это проще всего делать, когда телефоны выделены в отдельный влан.

Под видеонаблюдение опять же как правило используются порты с PoE. Камеры, конечно лучше в отдельный влан, который пустить в отдельный порт. Трафик с камер емкий, но в то же время не вызывающий сильного пользовательского негатива, легко забьет 1GE.

Это так не решается. Есть набор практик, описанный в ITIL, можете почитать. Начинать надо с создания каталога сервисов. Примеры легко гуглятся, например вот. Дальше планируется, какая нужна под это инфраструктура (помещения, сеть связи, электричество, АРМы, периферийное оборудование, серверы, софт). Дальше на это накручивается ITSM (сервис деск), потом учёт типа CMDB, требования к типовому АРМ, а дальше непрерывный процесс оптимизации.

iproute2, зачем изобретать что-то еще?

Если провода норм и компьютеры норм, то глючит коммутатор.
В коммутаторах доступа порты на плате сгруппированы по восемь штук. Один ASIC обрабатывает восьмерку портов. Вполне возможно, что дохнет конкретный asic. Попробуйте проблемные ПК переткнуть в другую восьмерку.
В коммутаторах есть такая проблема, как коллизия мак адресов. Коммутатор ищет порт, куда отправить пакет, по хешу от мак-адресу и влану. Во-первых, пара хешей может совпасть. Во-вторых, память для хранения этих хешей (таблицы мак-адресов) дорогая, и производители дешевых коммутаторов на ней экономят так, что в неё умещается не весь хеш, а только первые его байты. Эта особенность тоже может привести к коллизии. Можно попробовать перекинуть порты в другой влан. Или найти мак-адрес, из-за которого происходит коллизия.
Ну и конечно никто не отменял случая, когда в сети появилось несколько устройств с одинаковым мак-адресом (или петля), а порты коммутатора флапают из-за loop-detect.

Следите за логикой:
1) отдельный домен как правило отдельная ИТ-инфраструктура, отдельный web-сервер например
2) за домены второго уровня надо платить. В масштабах организации может быть они стоят и дёшево, но нужно следить за их статусом просрочки. Регистрацию домена третьего уровня не надо согласовывать с закупками.
3) подходящее имя домена второго уровня может быть уже занято, в то время как все пространство имён 3-го уровня у вас под рукой.
4) на все домены 3-но уровня можно выпустить один сертификат SSL типа wildcard.

Можете начать с настройки заббикса (включая алярмы в телеграмм и фильтрацию событий для разных пользователей), сислога, такакса, системы резервного копирования конфигураций (бекап конфигурации), системы IPAM, системы автоматической генерации конфигурации (чтобы можно было создать конфигурации на 100 отднотипгых коммутаторов, различающихся только ip-адресами и дескриптором портов), системой автоматизации конфигурации (ansimble, openconf). Естественно, выбираете варианты с сертификатами/шифрованиями, а для автоматизации используете bash/python.
А дальше думаете, как все, что вы настроили, перенести в облако за 1 час.

Каждый производитель по-разному может трактовать понятия. Но как правило стек это специальным кабелем с возможностью ещё и подключить дополнительные блоки питания ко всему стеку. А кластер это обычный Ethernet и протоколы управления по нему.

1) вы должны понимать, что два модема с двумя симками одного и того же оператора не увеличат скорость в два раза, так как используется тот же самый динамический частотный спектр. По крайней мере если не использовать агрегацию несущих и не подключать модемы к разным базовым станциям. А для этих фич вам нужны уже профессиональные модемы.
2) пять модемов - пять разных IP адресов. На какой из них будет литься трафик с камер? Нужно либо на каждой камере настраивать отдельные адреса приемника (пять камер на один адрес, пять на другой и тд), либо где-нибудь ставить железку с фиксированным подключением с одним IP-адресом (можно тот же хостинг), настраивать ее как медиа-сервер, а с неё уже лить трафик на ваш сервер. В вашей схеме между сервером надо использовать решения multipath tcp.

Это вопрос не инструмента, а методологии. Для ответа на него, надо понять, кто будет на схемы смотреть.
Мой опыт показал, что на детальные сетевые схемы не смотрит никто: они излишне перегружены, на них тяжело искать информацию, они огромны (попробуйте нарисовать на одной схеме хотя бы два 48-портовых коммутатора с полностью расключенными портами), не поддерживаю версионность, тяжело редактируемы (попробуйте добавить хотя бы один линк на схему с 50тью шнурками, уверен, вам придётся много чего подвигать)., а отсюда вытекает, что их редко поддерживают в актуальном состоянии.
Поэтому верное решение при ведении РАБОЧЕЙ документации - это сочетание схем и таблиц. Схема делается одна на типовое решение, а к ней добавляется таблица с учётом портов, IP-адресов, патчкордов и тд.
Для чего нужны детальные схемы?
Во-первых, они используются как тех. задание для организации подключения. Например, в подключении участвуют 12 разных подразделений, с ним надо согласовывать работы. Но если вы сам себе админ и подключаете для себя без привлечения третьих лиц, они вам не нужны.
Во-вторых, для тех поддержки. Но тех. поддержка работает с конкретным пользователем. То есть ей нужен один сервис. Но в мелких организациях админы сами являются тех поддержкой и все знают. Да и готовы ли вы держать отдельную схему на каждый компьютер? Опять же, такие схемы хороши, когда в организации сервиса принимают участие несколько отделов или компаний. Например, в моей типовой схеме при спутниковых включениях участвуют 12 отделов со своими сегментами сетей. Для этого нужна схема.
В-третьих, для работы с внешними организациями. В первую очередь это операторы. Но часто ли они у вас меняются? Для этого достаточно нарисовать одну схему раз в год с четырьмя портами и забыть.

Казалось бы, схемы должна смотреть дежурная смена. Но она смотрит на карту на заббиксе, нагиосе или другом инструменте мониторинга.

Теперь про инструменты. Они все выбираются в зависимости от масштаба сети и количества изменений в ней за определенный отрезок времени. Я приведу список инструментов, которые используются по возрастанию размеров сети, частоте изменений на сетевых элементах и количестве организаций, вовлечённых в эти изменения.
1) для совсем мелких организаций это draw.io для схем и гугл докс для таблиц.
2) далее офисный набор Микрософт, включая визио.
3) далее к офисному пакету добавляется система мониторинга или управления
4) вики-движки и CMDB
5) для ещё более крупных выделенные инструменты типа IPAM и NRI

P.S. Это касается рабочей документации. К исполнительной и проектной другой подход.

разве нельзя например сделать шифрованный IPsec самостоятельно?

Можно. Только возможностей у Континента больше чем у обычного IPSEC. Например, есть выделенный Центр Управления Сетью, есть программные клиенты типа Cisco any connect, есть возможность шифрования по ГОСТ. Кроме того, СКЗИ должны быть сертифицированны. Рекомендую почитать приказы 21 и 17 ФСТЭК.

промышленные предприятия не жалеют денег на подобное дорогостоящие оборудование?

Оно не такое уж и дорогостоящее, если сравнивать аналогичные по функционалу (но не по сертификатам) железки от Cisco/juniper.

IP адреса компьютеров, серверов, телефонов, принтеров, видеокамер

Решения типа IPAM. В зависимости от объема данных и количества пользователей разные продукты (от экселя до промышленных Network Resource Inventory).
Для серверов - решения типа CMDB.
Единого инструмента не будет, так как у всех своя особенность. Ну и надо плясать от ваших потребностей, для ведения IP плана на небольших проектах у меня отлично работает excel с выгрузкой в confluence.

Две сети - сеть для самого торгового центра и сеть Для арендаторов. Для арендаторов администрация ТЦ отводит закуток, куда все провайдеры ставят своё оборудование, от него тянут провода до помещений. Изощрённый арендатор нанимает контору, которая заранее сделает СКС до Помещений, которые будут снимать. Контора может быть хитрой и оформит на себя лицензию оператора, в таком случае при договоренности с администрацией услуги связи будет предоставлять только она одна (ну или оказывать последнюю милю для других операторов по ТЦ).
Сеть для самого ТЦ обычная корпоративная СКС, в которую подключаются камеры, СКУД, охрана, рабочие места персонала, серверное оборудование. Ну и отдельной позицией идёт радиосеть (wifi) - гостевая и служебная, планируется размещение коммутаторов с poe, расположение точек доступа в зависимости от проекта (и технического задания на него).

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

Техника blackhole. Мы распространяем маршрут по сети таким образом, чтобы весь трафик шёл на определенный маршрутизатор. Как только трафик придёт на маршрутизатор, он уже ни куда с него не выйдет, так как отправится в null0

У каждого своя специфика и свой уровень. Я вот читаю интернет изнутри

может freeradius принимать DHCP-request от пользователя, самостоятельно принимать аргументом из DHCP-request mac пользователя, а потом уже искать его в базе?

Конечно нет, это разные службы и протоколы. У операторов используется технология IPoE/ISG. Но тащить такое для учета внутренних пользователей совсем не стоит. Это может быть целесообразно, если у вас коммерческое облако. Но в этом случае такое решается опять же другими инструментами.

Мы же не знаем, как вы используете прокси. Судя по вашему описанию, подойдёт и 3proxy)
Плюшки керио - антивирус, ips и управление через морду. Если вам это не надо, то вперёд в мир линукса. Если надо, остальные решения будут ещё дороже.

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

Если работает три инженера (а если у вас 4K пользователей, то это ну максимум 200 коммутаторов), то файликов excel за глаза. Как правило все системы инвентаризации довольно сложны и неинтуитивны, вложение времени в их изучение и миграция данных в них при такой маленькой сети не особо оправдано.

Из бесплатного можете посмотреть nocproject. Не знаю правда, что это даст.

Вот хотя бы навскидку. Каждый пункт можно углубить.

• Функционал (не упрешься в ограничение "вот так мы делать не будем")
  
• Внутренние интеграции (те же CRM, сейчас еще АТС)
  
• Неограниченные возможности уведомления, хранения, а соответственно и интеграций с внешними системами
  
• Безопасность ваших данных (включая санкции регуляторов и силовых структур)
  
• Надежность инфраструктуры (включая доступ через интернет как самого офиса, так и целой страны - те же блокировки)
  
• Четкие SLA и отсутствие пустых зон ответственности (это очень важно при учете рисков)
  
• Независимость от поставщиков (санкции, юридические и договорные нюансы)
  
• Законодательные требования - обмен персданными