Akina

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

Просто считаешь общую мощность по классу, макс. паспортное потребление не выше середины бюджета для класса, избыток пойдёт на потери в линии. Если линия очень длинная или просто дерьмо, резервируй побольше.

В наличии 6 телефонов по типу d link dph 120se. Максимальное потребление 4вт.

Учитываем по классу 2, это 7 ватт на порт.

Две точки доступа Unifi ap ac lite,макс.потреб 6вт.

Эти по классу 3, т.е. 15.4 ватт на порт.

Итого нужен бюджет 6*7+2*15,4=73 ватта.

Вот какая связь между VLAN и адресом внутреннего интерфейса коммутатора? Никакой, от слова вообще. Данный адрес - именно адрес внутреннего интерфейса коммутатора. Запись просто утверждает, что внутренний интерфейс коммутатора доступен по указанному адресу в указанном VLAN. Т.е. если, находясь в данном VLAN, узел обратится по данному адресу - то он будет обращаться к коммутатору. Ну захотелось человеку, который настраивал сетку, присвоить коммутаторам адреса из разных подсетей, но в одном VLAN - имеет право. Неясно, правда, какой с того профит, но проблем с этого уж точно никаких. У меня в сети, например, для коммутаторов выделены аж три разные подсети в трёх разных management VLAN, различающихся по назначению, и некоторые из коммутаторов имеют адреса в двух, а магистральные даже во всех трёх, VLAN.

Я понимаю, если бы что-то бы интерферировало - скажем, один и тот же адрес, или один адрес был бродкастом подсети второго адреса. Тогда бы был предмет для беспокойства.

Если с такой настройки корячит - ну перенастрой.

Гибридные, транковые порты на коммутаторах, это всё порты для коммутаторов? Не для конечных устройств?

В общем - нет. Как правило - да.

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

подружить 2 VLAN (2 сети) на одном конечном устройстве?

Так вланы, и в них сети, разные, или разные сети в одном влане?

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

Официальный сайт реестра российской радиоэлектронной продукции (РРПО) — https://gisp.gov.ru/documents/10546664/

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

Диапазон от 194.58.80.0/24 до 194.58.95.0/24 - лучше. Он извне (на внешнем интерфейсе) накрывается одним маршрутом.

194.58.80.0 .. 194.58.95.0 = 194.58.80.0/20
194.58.72.0 .. 194.58.87.0 = 194.58.72.0/21 + 194.58.80.0/21

Впрочем, лучше - провайдеру. Потребителю - глубоко пофиг.

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

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

Однако, судя описанию, обе сетевые карты настроены на автоматическое получение адреса. И соответствующие DHCP-серверы не рвутся правильно анонсировать маршруты, а просто анонсируют шлюз по умолчанию.

Соответственно для нормальной работы нужно (при условии, что обе карты адресуются по DHCP):

1. Настроить метрики интерфейсов, поставить интерфейсу в корпоративной сети более высокую метрику (бОльшее значение метрики соответствует более низкому приоритету интерфейса, и соответственно его маршрутов).

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

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

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

Процитирую INTUIT.RU: Основы сетей передачи данных.

Постоянная и динамическая коммутация

Как сети с коммутацией пакетов, так и сети с коммутацией каналов можно разделить на два класса:

• сети с динамической коммутацией ;
  
• сети с постоянной коммутацией.
  
  

В сетях с динамической коммутацией:

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

Примерами сетей, поддерживающих режим динамической коммутации, являются телефонные сети общего пользования, локальные сети, сети TCP/IP.

Сеть, работающая в режиме постоянной коммутации:

• разрешает паре пользователей заказать соединение на длительный период времени;
  
• соединение устанавливается не пользователями, а персоналом, обслуживающим сеть;
  
• период, на который устанавливается постоянная коммутация, составляет обычно несколько месяцев;
  
• режим постоянной ( permanent ) коммутации в сетях с коммутацией каналов часто называется сервисом выделенных ( dedicated ) или арендуемых ( leased ) каналов;
  
• в том случае, когда постоянное соединение через сеть коммутаторов устанавливается с помощью автоматических процедур, инициированных обслуживающим персоналом, его часто называют полупостоянным (semi-permanent) соединением, в отличие от режима ручного конфигурирования каждого коммутатора.
  

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

Не надо слушать каждого начальствующего придурка. Его дело - поставить задачу и заткнуться. А вот как её решать и что для этого решения делать - должен решать ты. Подключив к процессу голову.

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

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

Почему подсеть перестает видеть при включении прокси?

Потому что все маршруты похерены. Клиент пытается искать другие подсети через новый канал. И ещё ваше счастье, что новый провайдер не отрубил вас за серый флуд.

Нет, это явное нарушение RFC.

Адрес 192.168.40.40 относится к категории немаршрутизируемых в Интернете. Любой узел, если он получил пакет на этот адрес на интерфейсе с маршрутизируемым адресом, либо если он должен согласно своей таблице маршрутизации отправить его через интерфейс с маршрутизируемым адресом, должен отказать в маршрутизации (какое при этом применить правило - deny или drop,- не описано). В трассе имеется адрес 188.***.172, не принадлежащий какой-либо немаршрутизируемой сети - следовательно, в маршрутизации пакета должно было быть отказано.

А что бардак - таки да, это в порядке вещей. Вы поснифьте свой внешний адресок да посмотрите, сколько на него попадает "грязи" - удивитесь.

при подключении провода подключение Wi-Fi автоматически гаснет.

Что значит "гаснет"? физически отключается адаптер? логически отключается привязанный к нему сетевой интерфейс? Старайтесь использовать более вменяемые термины, Вы же технический специалист.

Железка имеет DHCP, сразу выдаёт адрес

Не только адрес, но и ещё горсть параметров, включая шлюз по умолчанию. При этом уже имеющийся немедленно получает увеличение метрики и перестаёт использоваться.

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

Windows 10 игнорирует метрики, в зарубежных гайдах говорят "Перестала уважать метрики". Т.е. нет никакой разницы, если поставить "999" метрику на Ethernet и "1" на Wi-Fi

Явная и откровенная глупость. Абсолютное непонимание того, что есть метрика интерфейса и как она влияет на маршрутизацию.

Адрес, выдаваемый по DHCP, выдаётся для определённого аппаратного (МАС) адреса.

Сетевой адаптер (что реальный, что виртуальный) имеет только один МАС - соответственно ему будет выделен только один IP.

Gigalink GL-MC-UTPF SC1F-18SM-1310 - стамегабитный (Режим работы оптического порта, Мбит/с - 100).
Mikrotik S-53LC20D - гигабитный (Data Rate - 1.25G).

Они не подружатся. Никогда.

Значительный процент WiFi-AP по умолчанию использует изолированный режим работы беспроводной части - т.е. беспроводному клиенту разрешён только трафик в WAN-интерфейс. В проводной LAN-сегмент или к другому беспроводному клиенту - трафик блокируется.

Нарисуйте полную схему магистральных соединений сети. Всё активное L2 оборудование, все соединения между ними с номерами портов на каждой стороне. На каждой единице оборудования по каждому магистральному порту проверьте, что на нём имеются только tagged VLANы, а по каждому клиентскому (включая неиспользуемые) - только один untagged VLAN.

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

Да, не забудьте отдельный управляющий VLAN, чтобы рулить оборудованием. И не используйте VLANID=1.

255.255.255.255 - бродкаст сети 0.0.0.0/0. Т.е. глобальный бродкаст.

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

По договору с провайдером у меня динамический IP. Услугу статического IP я не подключал. Однако мой IP не меняется уже месяц.
[skipped]
Что делать и каким способом обнулить время аренды DHCP IP-адреса? Как вернуть динамический IP?

Для начала - не путайте тёплое с мягким. Да, с цветным тоже не путайте.

Динамический IP означает, что Вам не нужно прописывать настройки, что все настройки Вы получите от оборудования провайдера по DHCP. Это всё.

Повторяю - ЭТО ВСЁ! Больше ничего эта фраза в договоре не означает. Она не устанавливает, публичный адрес у Вас будет или приватный (белый или серый), не устанавливает, будет ли адрес всё время один и тот же, или будет периодически либо регулярно изменяться...

Далее. Время аренды адреса - это параметр, которым оперирует DHCP-сервер провайдера. Он напрямую связан с МАС-адресом Вашего оборудования (сетевая карта, роутер), подключенного к провайдеру, и выделенным для этого МАС IP-адресом. Соответственно "обнулить время аренды" можно двумя способами:

1) Выключить своё оборудования на время более текущего времени аренды. Ненадёжно - на DHCP соответствие будет сохраняться, пока этот IP не будет выдан кому-то ещё (что в случае проводных провайдеров событие маловероятное).

2) Сменить МАС-адрес на своём оборудовании. Не будет работать, если у провайдера имеется привязка по порту (причём может быть как привязка клиентского МАС, так и выделяемого IP).

Многие сайты считают меня ботом и не пускают. Иногда дело доходит до апсурда, и меня в гугле банят. Что искать в Google надо проходить проверку "я не робот", а это очень тяжело, особенно когда приходится две или три попытки делать.

Эта проблема вообще слабо связана во всем остальным. Тут надо скорее разбираться, откуда такое счастье. Скорее всего, у тебя приватный адрес, а публичный адрес прова используется для выхода в Инет не только тебя, но и ещё кучи клиентов. Тогда все проблемы ожидаемы, а реакции других сайтов - скорее всего, обоснованы.

Если отсутствие интерференции с другими клиентами действительно важно - следует приобрести у провайдера услугу выделенного реального IP-адреса. В данном случае:

"выделенный" - присвоенный только тебе, одновременно с тобой с этого адреса никто работать не может.

"реальный" - он же белый, адрес, маршрутизируемый в Инете.

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