Akina

На PC-1 установлена 1 сетевая карта Realtek GBe Gaming Family Controller, поддерживающая VLAN (утилитой Realtek Ethernet Diagnostic Utility задали второй IP для компа - из подсети видео 172.16.99.*).

Сейчас найти карту, которая поддерживает VLAN, проще, чем карту, которая НЕ поддерживает.

Основной вопрос - поддерживает ли ваша карта multi-VLAN? Или иначе - после установки REDU, её запуска и выбора в левом окне вашей сетевой карты - появляется ли в среднем окне в дереве пункт VLAN?

Если нет, то всё плохо, и простого решения нет.

Если пункт есть, то всё элементарно:

1. Перенастроить порт свича к этой сетевой карте в режим транка, и включить его в оба VLAN в режим tagged.
   
2. С помощью REDU создать два указанных VLAN на сетевой карте. Рекомендую каждому VLAN присвоить вручную VMAC из диапазона незарегистрированных, и чтобы последние 4 цифры указывали на VLANID.
   
3. В свойствах сетевых подключений для каждого подключения установить требуемый адрес.
   

Как скорость передачи отдельного пакета может быть 100 Гбит/, если этот пакет передается в потоке со скоростью 50 Гбит/с?

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

Хост 100.124.0.1

Провайдер врёт, что он в душе не гребёт, какой это [censored] использует этот адрес. Потому что этот [censored] - именно сам твой провайдер. Это же второй хоп - ну о чём вообще речь? Ну или ты попадаешь на первую линию техподдержки, где сидит нечто не очень грамотное, способное только зачитывать по телефону простейшие инструкции из ЧаВо...

К слову, это зарезервированный адрес:

RFC 6598

IANA has recorded the allocation of an IPv4 /10 for use as Shared Address Space.

The Shared Address Space address range is 100.64.0.0/10.

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

И лишь на 4 хопе ты выходишь на Совинтел (87.229.204.182).

PS. А если бы на месте этого адреса был бы какой-то 10.11.12.1 (или другой богон-адрес, но из широко известных серых подсетей) - тебе бы сильно это помогло? Хотя... тогда было бы проще доказывать провайдеру, что косяк на его стороне.

Может ли мобильный оператор блокировать интернет при подключении компьютера?

Технически - да, может.
С правовой точки зрения - изучай договор. Если запрет не прописан явно - блокирование неправомочно.

Destination Host Unreacheable, если перевести с буржуинского, означает "Хост назначения недостижим".
Если переводить дальше - на обывательский, то это означает "У меня нет маршрута (адреса шлюза), через который я должен послать пакет узлу назначения".

Следовательно, хост 192.168.0.108 не имеет необходимого для общения с указанным адресом 52.43.49.19 дефолтного либо частного маршрута.

А с узлами своей подсети он общается напрямую, без шлюза. То есть виртуальный коммутатор функционирует нормально.

Я бы

1. Убрал неуправляемый коммутатор и соединил серверы напрямую (необязательно, но зачем лишняя фигня в сети?)
   
2. Поставил на обоих серверах гигабитные интерфейсы в автополучение адреса
   
3. Отключил на 100-мегабитных картах NetBIOS over TCP/IP (хотя это уже зависит от того, какие ресурсы и через какие пространства имён нужны в сети)
   
4. Дождался бы самовыделения APIPA-адресов (169.254) на обоих серверах
   
5. Прописал перекрёстно полученные адреса и соответствующие им имена серверов в HOSTS и в LMHOSTS
   

Итоги:

1. Серверы доступны друг другу по имени
   
2. При обращении по имени связь будет устанавливаться через этот канал (через гигабитные карты), а не через 100-мегабитные карты
   
3. Гарантированно не будет пересечения по диапазону адресов с другими системами в сети
   

Я в упор не понимаю, зачем тут вообще маршрутизация.

Все интерфейсы 10G - NAS, компьютер и Mikrotik,- помещаем в одну подсеть.
Интерфейс 1G - компьютер и Mikrotik,- помещаем в другую подсеть.
Для исключения L3-петли в файрволе Микротика блокируем любой трафик от и на адрес 10G интерфейса компьютера.

На компе дефолтным шлюзом адрес 1G интерфейса Mikrotik.
На NAS дефолтным шлюзом адрес 10G интерфейса Mikrotik.

Микрот - с компьютером и NAS общается напрямую, ибо одна подсеть, а в Инет идёт через свой WAN.
NAS - с компьютером и Микротом общается напрямую, ибо одна подсеть, а в Инет идёт через Микрот.
Компьютер - с NAS и Микротом общается напрямую, ибо одна подсеть, а в Инет идёт через Микрот.

Т.е. никакие маршруты, кроме маршрутов по умолчанию, в системе вообще не требуются.

Хотя согласен с предыдущими ораторами - дополнительный 1G линк явно избыточен.

хотелось бы больше подробностей

Если коротко.

Из Инета можно обратиться только к "белому" адресу. На NAS - "серый" адрес. Значит, нужен посредник (NAT-роутер). На нём будет работать port forwarding.

Работает оно так. На роутере-посреднике два интерфейса - внешний белый и внутренний серый. Создаётся правило: "Если что-то пришло на внешний адрес на порт XXX, переслать это на внутренний адрес YYY на порт ZZZ". В соответствии с этим правилом клиент снаружи стучится на внешний белый адрес на порт XXX, роутер от своего имени шлёт этот пакет с внутреннего адреса на адрес YYY (NAS) порт ZZZ. То есть с точки зрения самого NAS к нему обращается не внешний клиент, а роутер. Он отвечает роутеру. Роутер по запомненным характеристикам соединения делает обратное преобразование и шлёт ответ NAS клиенту от своего имени.

Если внутренний сервис требует для работы более одного порта - для каждого будет создано своё правило преобразования.

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

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 или шире.