Akina

Сети похрен. Коммутаторам тоже похрен.

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

Всё это проверено практикой. Обычное дело, когда наводишь порядок в сети с кучей ненастроенных коммутаторов. Сперва подключаешься быстренько к кому-нибудь, резко меняешь ему IP, запоминая МАС, и надеешься, что именно в этот момент не произойдёт "смена лидера" (именно поэтому никаких веб-интерфейсов, только телнет). А потом, избавившись от дубляжа, по ARP-таблицам, списку активных портов и прочим признакам (например, модель коммутатора или тип свистка, FC или FX, в комбо-порте) пытаешься понять, кто есть ху.

Это при условии, что адрес на коммутаторах не используется активно - скажем, как промежуточный узел маршрутизации на L2+ или L3 коммутаторе. А если используется - то обычные проблемы дублирования встанут в полный рост.

В настройках сети виртуальной машины стоит Сетевой мост. Доступ в интернет на хостовой машине прописан через статику.

Я думаю, вам надо внимательно почитать мануал по организации сетевой подсистемы VB. https://www.virtualbox.org/manual/topics/networkin...

Сетевой мост - это считай независимое подключение непосредственно к реальному сетевому адаптеру системы. То есть с точки зрения ОС в виртуалке она установлена на соседнем компьютере и подключена в тот же физический коммутатор, в какой подключена и реальная машина, а сетевые настройки базовой ОС не влияют на виртуальную ОС вообще никак.. Кто, спрашивается, должен дать ей адрес? у вас есть внешний по отношению к хостовой машине (или на самОй хостовой ОС) DHCP-сервер?

но в интернет не ходит, нет пинга до 8.8.8.8.

А почему надо пинговать сразу узел в жопе мира? Я уж не говорю о том, что "нет пинга" на самом деле это полдесятка разных сообщений об ошибке, сообщающих о разных причинах.

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

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

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

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

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

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

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

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

Mission impossible.

Как вы делите сеть на VLAN если не используете L3?

Вот сижу и думаю - что за бред? VLAN - чисто L2 штука. Где связь?

У меня вон стоят коммутаторы L2 (даже не L2+), и они распрекрасно себе умеют VLAN, причём и port-based, и MAC-based. Единственно чего, связанного с VLAN, они не умеют, так это держать несколько IP адресов внутреннего интерфейса в разных VLAN, только один IP, доступный либо из одного указанного VLAN, либо из вообще любого. Они даже GVRP умеют без проблем.

не до конца наверное понимаю работу 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, не обращая внимания на существование остальных.

Как мне объяснить микротику, что на одном из портов стоит коммутатор?

Ему вообще-то похрен.
А циска пусть работает как тупой свитч. То есть абсолютно всё, кроме коммутирования - нахрен.

я докупил Cisco Catalyst WS-C2960-24TC-L

Можно было обойтись любым неуправляемым коммутатором на нужное число портов.

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

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

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

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

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

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

Хотелось бы разнести устройства, чтобы каждый тип устройства был в своей подсети и получал адрес по dhcp

Вот вообще не вижу проблемы. Резервирование IP-адреса на DHCP-сервере по МАС-адресу - это единственное, что нужно для решения задачи.

PS. Правда, три DHCP-скопа, торчащие в одном L2-сегменте - это из разряда "странное"...

rundll32.exe keymgr.dll, KRShowKeyMgr

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

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

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

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

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

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

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

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

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

Мой компьютер - ПКМ - Управление - Общие папки - Общие ресурсы - нужный ресурс - ПКМ - Свойства - Разрешения для общего ресурса

Заодно проверьте в локальных политиках, разрешен ли доступ из сети с пустым паролем (у юзеров пароли же не установлены, верно?). И не запрещён ли кому вообще доступ из сети.

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

Вы неправильно понимаете, и от того неправильно мыслите.

Представим, что у нас на коммутаторе сделаны, скажем, 3 VLAN. Ну и подключены какие-то узлы-клиенты. Так вот - чтобы построить то же самое, но без управляемого коммутатора, Вы должны взять три отдельных коммутатора, и в соответствии с VLAN переключить на них всех клиентов.

Иными словами, сети различных VLAN изолированы друг от друга ПОЛНОСТЬЮ. И пусть Вас не обманывает, что все они сходятся в одном коммутаторе - внутри этого коммутатора никакого соединения между VLAN нет. Соответственно чтобы трафик ходил из одного VLAN в другой, нужен маршрутизатор, который одним интерфейсом смотрит в один VLAN, другим - в другой VLAN.

Вы хотите сделать у себя 5 VLAN. Соответственно если они, скажем, должны обращаться к одному и тому же серверу-файлопомойке, или через этот один сервер ходить в Интернет, значит, в этот сервер придётся вставить 5 сетевых карт, и каждую из карт подключить к отдельному порту коммутатора, являющемуся членом одного из имеющихся VLAN. Вот Вы точно этого хотите? А представляете, какой получится монстр, если количество VLAN будет не 5, а 15?

Да, в именно описанном случае можно спасти ситуацию, если использовать серверное оборудование и ПО, которые могут на одном внешнем интерфейсе создать несколько адресов из разных подсетей и статически зафиксировать для каждого из адресов определённый МАС-адрес, а на коммутаторе включить МАС-based VLAN. Но, поверьте, Ваша ситуация ну совершенно не располагает к созданию себе подобного геморроя...

--------------------

Как по мне, Вам вполне достаточно просто сделать несколько подсетей.