Akina

Отслеживать - нет.
Можно написать скрипт, который будет получать текущую таблицу (interface bridge host print либо interface ethernet switch host print) и сравнивать с предыдущей версией. По результатам сравнения сообщать. Период запуска, само собой, меньше времени жизни записи в кэше.
Хотя разумнее одним скриптом сливать в файл, а потом другим скриптом обрабатывать и кляузничать - но уже не так часто. Или вообще в БД писать, для истории...

1. Собственный сервер - скорее да, чем нет. На Windows - 33/67 (альтернативы - Linux и NAS). AD - точно нет.
2. Коммутатор, разделяющий сеть на изолированные сегменты с помощью VLAN. При необходимости ограниченного или контролируемого доступа из сегмента в сегмент - маршрутизация Микротиком.
3. См. п. 1.
4. Видео - есть. Полезных - нет.

Дополнительно. Организация надёжного резервного копирования, и в первую очередь баз 1С, на независимый носитель - критично обязательно.

SNR-SFP-W35-3 1000BASE-X 3km, 6dB TX 1310nm/RX 1550nm - это одномодовый свисток. Одноглазый, кстати.
ML-SG-2DFM-31LD 1.25G SFP 1310nm 2KM DDM - это многомодовый свисток. Вообще двуглазый.

Они говорят на разных языках. Работают на разном волокне. И никогда друг друга не поймут.

Mission impossible.

Между маршрутизаторами внутри частной сети WAN или LAN?

Частная - это по-ихнему private.
Private network - это подсеть, которая не маршрутизируется в Интернете (явно или условно). В первую очередь подсети "серых" адресов (RFC 1918), но вообще таких подсетей (именуемых bogon networks) под полтора десятка.
Сеть, адресация которой построена на не маршрутизируемых глобально адресах - это LAN.

Суёшь линк/ярлык в
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

Оборудование на другом конце - ситуация штатная. Тестер обязан её предусматривать, в т.ч. и вариант с PoE.

Про убитый тестером порт даже не слышал. Но если такое произойдёт, то это будет явно следствие неисправности тестера. Либо "после, но не вследствие".

А вот если на другом конце окажется что-то, что использует витую пару, но сетевым интерфейсом не является (например, порт "дальнобойной" АТС), можно остаться и без тестера...

Какое преимущество для текущей конфигурации обеспечивает настройка сетей VLAN?

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

В этом случае деление на VLAN однозначно убирает взаимную "видимость" узлов, включённых в разные VLAN, а также разделяет широковещательный трафик. Опять же безопасность и всё такое...

Можно же взять S1 и подключить к нему PC1, PC4 и т.д.

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

Так что никаких "можно же взять" - нельзя, и точка.

Есть 2 созданных сети на этом dhcp 10.0.0.1-10.0.0.100 и 10.1.1.1-10.1.1.100.

Это НЕ сети. Это диапазоны выделяемых адресов (scopes).

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

Gateway имеет ip адрес 10.0.0.1.

Это чей gateway? Операционной системы, на которой работает DHCP? Или это значение параметра в настройках скопа, отдаваемое сервером клиенту?

Это gateway куда? Шлюз по умолчанию? Шлюз в подсеть? Что-то ещё?

Каким образом можно указать для сети 10.1.1.1-100 gateway 10.0.0.1 , чтобы например, контейнеры proxmox, которые будут находиться в этой подсети имели выход в интернет ?

Самое простое - объединить скопы одной подсетью.
Соответствующая маска - /23 или шире.

не до конца наверное понимаю работу vlan

VLAN в первом приближении - это не просто, а очень просто.

Первый шаг - это разделение по отдельным VLAN. Мысленно представляешь, что у тебя не один коммутатор, а несколько. Вот прям вместо коммутатора стоИт стопка один на другом. В первом - только VLANID=1, во втором VLANID=2, и так далее. Каждый коммутатор обслуживает строго один VLAN, а все остальные порты, на которых текущий VLAN отсутствует, тупо залиты цементом. Если коммутаторов несколько - то каждый в схеме размножается таким образом, а соединения между портами коммутаторов ещё и раскрашиваются, например, тегованный кабель синий, а нетегованный красный. Соответственно если у тебя есть транковая связь (гибридный или транковый порт) с каждой из сторон) - то в преобразованной схеме один кабель между такими коммутаторами размножается на несколько, каждый в схеме для своего VLAN. А если попадается случай, когда с одной стороны провода VLANID есть, а с другой стороны его нет - получается кабель, с одной стороны вставленный в порт, а с другой нет. И соответственно в схеме для именно этого VLAN связи между коммутаторами нет. Аналогично для случаев соединения "tag на untag" с одной стороны красный кабель, с другой синий, у обоих вторые концы "в воздухе", а связи нет.

Второй, дополнительный, шаг - это соединение меж собой нетегованных портов разных VLAN в преобразованной схеме, если такие соединения исходно существуют, невзирая на номера VLAN. Скажем, если на порте есть нетегованный VLANID=2 (возможно, с другими VLANID, но тегованными), и порт соединён кабелем с другим портом того же или другого коммутатора, на котором есть нетегованный VLANID=3, то в преобразованной схеме ты соединяешь соотв. порты коммутаторов разных слоёв, соответствующих этим VLAN.

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

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

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

В общем случае получение полного маршрута - вообще без шансов.

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

на работе в серверной куча лапши из проводов и свичей

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

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

Любой маршрут пакета может быть представлен так:

(source IP1) - (IP2 router1 IP3) - (IP4 router2 IP5) - ... - (IPn destination)

У тебя весь маршрут точно известен. А потому временно добавляем на источнике (IP1) маршруты во все промежуточные подсети, если они не покрываются маршрутом по умолчанию или более широкими частными маршрутами, и с источника (IP1) начинаем последовательно пинговать IP2, IP3, IP4, .. и так до узла назначения.

Где-то возникнет проблема, и очередной IP не ответит. Вот именно знание, кто не ответил, и какой именно тип ошибки пинга возвращён, и позволит определить, на каком узле и по какой причине грабли. Конечно, следует понимать, что в маршруте может быть несколько последовательных ошибок, и даже несколько параллельных на одном узле.

Например, если проходит пинг на IP4, но не проходит на IP5, то в случае ответа No route to host проблема - в отсутствии маршрута в подсеть IP5 на узлах source (забыли добавить или сделали это неправильно) или router1, а в случае ответа Timeout проблемы с маршрутизацией на узле router2 или файрволом на любом из трёх задействованных в маршруте узлов.

Нужно изменить режим работы Роутера-2. Он должен работать в режиме не роутера, а точки доступа, т.е. просто служить конвертором интерфейса. Ну и, само собой, DHCP на нём отключить.
Тогда камера будет цепляться за него и через него слать запрос адреса на Роутер-1. Ну вернее слать запрос в проводной интерфейс, а там Роутер-1 единственный DHCP.
У ТПЛинка на сайте даже видео есть "Как превратить роутер в точку доступа?".

Не, вот зачем в такой простой и тупой сети столько маршрутизаторов?

PS. Как по мне, вся схема - одна большая ошибка.
PPS. И что вообще делают роутеры и брэндмауэр в L2-схеме?

Читайте договор.

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

Есть другая локальная сеть.

Eсли термин "другая локальная сеть" использован правильно, и речь идёт о физически изолированных сетях - то без объединения сетей - на самом сервере (вставить в него вторую сетевую) либо на отдельном устройстве в первой сети,- задача очевидно не решается.

Как сделать так что бы при вводе другого IP адреса с другой подсети пользователь попадал на сайт 10.2.2.10?

Если вопрос ставить ИМЕННО ТАК - то либо использовать destination NAT в варианте DMZ, либо socks proxy.

Любые остальные решения подходят только в случае, когда будут чётко определены конкретные протоколы и, для TCP/UDP - порты. И когда будет чётко и однозначно определено, что скрывается под загадочным термином "попадать".

Есть устоявшаяся практика: присваивать номер vlan номеру подсети

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

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

понятно ограничение на количество vlan на разном оборудовании

Если оборудование не поддерживает стандарт, который определяет 4к различных VLAN, то разумнее его не использовать - кто знает, что оно ещё делает не по стандарту...

Насколько крупный должен быть бизнес, чтобы человек был не админом-универсалом, а трушным сетевиком?

В основном это определяется не размером конторы, а областью её деятельности и разветвлённостью её сетевой инфраструктуры.

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

Крупной конторе с разветвлённой сетевой инфраструктурой (как правило, речь о территориально распределённых) выделенный сетевик или даже отдел - нужны. А если проблемы в сетевой инфраструктуре способны сильно влиять на бизнес и приводить к серьёзным потерям - то такой отдел необходим.

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

является ли такой режим и график работы для сетевика нормой?

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

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

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

Без промежуточных? Расстояние - в пределах домена коллизий.
Однако даже в таком случае расчёт времени невозможен. Например, оно может увеличиться (и сильно), если перестраивается RSTP.