ЛБ7.X Лифтовые блоки и сеть Ethernet

  • Автор темы Автор темы miras
  • Дата начала Дата начала
ЛБ7.X

miras

Новичок
Здравствуйте
В нашем проекте есть 3 VLAN.
601vlan - Лифтовые блоки 172.16.16.0
Есть Core switch уровня L3 на котором все vlan коммутируются. DHCP сервер для всех влан, работает на WinServ 2016.
Все наши свитчи доступа управляемые L2.
При назначении на свитче доступа, любого порта как access, для влан 601 и подключении к нему ЛБ, он не берет IP адрес из под 172.16.16.0 сети. При том что если подключить к тому же порту ноутбук, IP адрес автоматический назначается из нужной сети влан 601.
При подключении ЛБ к влан 1, IP адрес Лб-ку назначается из 172.16.40.0 сети. Но это не совсем то что мне нужно.
Связанно ли это как с самим лифтовым блоком? С остальными вланами проблем нету, транк порты везде настроенны.
Либо я что-то упустил при конфигурации свитчей?
 
Последнее редактирование модератором:
miras написал(а):
Здравствуйте
В нашем проекте есть 3 VLAN.
601vlan - Лифтовые блоки 172.16.16.0
Есть Core switch уровня L3 на котором все vlan коммутируются. DHCP сервер для всех влан, работает на WinServ 2016.
Все наши свитчи доступа управляемые L2.
При назначении на свитче доступа, любого порта как access, для влан 601 и подключении к нему ЛБ, он не берет IP адрес из под 172.16.16.0 сети. При том что если подключить к тому же порту ноутбук, IP адрес автоматический назначается из нужной сети влан 601.
При подключении ЛБ к влан 1, IP адрес Лб-ку назначается из 172.16.40.0 сети. Но это не совсем то что мне нужно.
Связанно ли это как с самим лифтовым блоком? С остальными вланами проблем нету, транк порты везде настроенны.
Либо я что-то упустил при конфигурации свитчей?
Сразу сказать что-либо внятное сложно. Ситуацию поможет немного прояснить содержимое вкладки "Собственные" конфигуратора ЛБ. В частности "IP адрес DHCP" сервера. Полезно сравнить с полученными данными подключения к этому же порту ноутбука.
(Конфигуратором подключаться к ЛБ напрямую через USB кабель, на вкладке "Собственные" несколько раз нажать на кнопку "Обновить".)
 

Вложения

  • DHCP.JPG
    DHCP.JPG
    47.3 KB · Просмотры: 0
Последнее редактирование модератором:
oleg написал(а):
Сразу сказать что-либо внятное сложно. Ситуацию поможет немного прояснить содержимое вкладки "Собственные" конфигуратора ЛБ. В частности "IP адрес DHCP" сервера. Полезно сравнить с полученными данными подключения к этому же порту ноутбука.
(Конфигуратором подключаться к ЛБ напрямую через USB кабель, на вкладке "Собственные" несколько раз нажать на кнопку "Обновить".)


к одному и тому же свитчу подключены ноут и ЛБ, ноут к влан 601 соответсвенно берет берет ip из 172.16.16.0
а ЛБ к порту с влан1 где он берет айпи из сегмента 172.16.40.0
Пробовал переключить и на другой сегмент 10.10.0.0 но так же без результатно.
 

Вложения

  • 1.JPG
    1.JPG
    142.9 KB · Просмотры: 1
Последнее редактирование модератором:
Для начала обновить для начала ПО ЛБ 7.2. У вас версия ПО 7.1.2 от 07.06.2020. В версии 7.1.6 30.06.2022 - В режиме DHCP - добавлено обнаружение и автообновление сетевых параметров ЛБ при изменении конфигурации DHCP сервера сети. И понаблюдать за поведением...
 
apathy написал(а):
Для начала обновить для начала ПО ЛБ 7.2. У вас версия ПО 7.1.2 от 07.06.2020. В версии 7.1.6 30.06.2022 - В режиме DHCP - добавлено обнаружение и автообновление сетевых параметров ЛБ при изменении конфигурации DHCP сервера сети. И понаблюдать за поведением...


Сменил прошивку, но без результатно.
 

Вложения

  • 22.JPG
    22.JPG
    49.2 KB · Просмотры: 1
Уверенны что именно правильную прошивку вы залили для вашей СУЛ? Исходя из сообщения выше у вас была MITSUBISHI GPS, а сейчас просто MITSUBISHI. А тут надо смотреть на конфигурацию ваших Vlan на коммутаторах доступа
 
miras написал(а):
к одному и тому же свитчу подключены ноут и ЛБ, ноут к влан 601 соответсвенно берет берет ip из 172.16.16.0
а ЛБ к порту с влан1 где он берет айпи из сегмента 172.16.40.0
Пробовал переключить и на другой сегмент 10.10.0.0 но так же без результатно.
Приложенный скрин конфигуратора показывает что ЛБ с ID: 88779 стандартно отработал протокол DHCP и ШТАТНО получил IP адрес 172.16.40.5 , который ему ВЫДАЛ DHCP сервер Вашей сети с IP адресом: 172.16.40.2.
Считаю решение проблемы кроется не в ЛБ, а особенностях настройки DHCP сервера Ваших сетей.
Копать в сторону поиска ответа на вопрос: почему на запрос ЛБ DISCOVERY, DHCP сервер с IP адресом: 172.16.40.2, назначил ЛБ IP адрес 172.16.40.5 вместо 172.16.16.23.

Как временную меру решения вопроса работы ЛБ в указанных сетях (пока идет разбирательство с назначением IP адреса DHCP сервером), можно использовать статическое назначение IP адреса ЛБ.
 
Последнее редактирование модератором:
apathy написал(а):
Уверенны что именно правильную прошивку вы залили для вашей СУЛ? Исходя из сообщения выше у вас была MITSUBISHI GPS, а сейчас просто MITSUBISHI. А тут надо смотреть на конфигурацию ваших Vlan на коммутаторах доступа


У меня на руках пока только два блока, оба Mitsubishi. Перед прошивкой решил проверить воторй блок. И прошивка подобранна именоо для Mitsubishi.
 
oleg написал(а):
Приложенный скрин конфигуратора показывает что ЛБ с ID: 88779 стандартно отработал протокол DHCP и ШТАТНО получил IP адрес 172.16.40.5 , который ему ВЫДАЛ DHCP сервер Вашей сети с IP адресом: 172.16.40.2.
Считаю решение проблемы кроется не в ЛБ, а особенностях настройки DHCP сервера Ваших сетей.
Копать в сторону поиска ответа на вопрос: почему на запрос ЛБ DISCOVERY, DHCP сервер с IP адресом: 172.16.40.2, назначил ЛБ IP адрес 172.16.40.5 вместо 172.16.16.23.

Как временную меру решения вопроса работы ЛБ в указанных сетях (пока идет разбирательство с назначением IP адреса DHCP сервером), можно использовать статическое назначение IP адреса ЛБ.


Проблема кроется в коммутаторе доступа, который по не понятным причинам не раздает DHCP адреса IP камерам и ЛБ. Потому что даже статические адреса на устройствах не коммутируются.

Хотя при подключении к тем же портам компы под управлением Windows, IP адреса назначаются к соответсвию с их ВЛАН к которму они подключенны.

На свитчах Cisco у меня проблем бы не было. А тут коммутаторы от китайской компании ONV. CLI и web интерфейсы которые очень замудренные.
 
miras написал(а):
Проблема кроется в коммутаторе доступа, который по не понятным причинам не раздает DHCP адреса IP камерам и ЛБ. Потому что даже статические адреса на устройствах не коммутируются.
Правильно ли я понял, что даже при статически назначенных IP адресах в ЛБ - прохождение пакетов через коммутаторы ONV.CLI между ЛБ и Компьютером диспетчера для подсетей 172.16.16.X нестабильно (или не работает)?
Второй вопрос: А работа ЛБ и диспетчерской в подсети 172.16.40.X - обеспечивается?
 
Последнее редактирование модератором:
oleg написал(а):
Правильно ли я понял, что даже при статически назначенных IP адресах в ЛБ - прохождение пакетов через коммутаторы ONV.CLI между ЛБ и Компьютером диспетчера для подсетей 172.16.16.X нестабильно (или не работает)?
Второй вопрос: А работа ЛБ и диспетчерской в подсети 172.16.40.X - обеспечивается?


1) Да, пакеты не проходят т.е. не работает
2) Да, с этим проблем нету так как 172.16.40.0 работает на 1 влане. и соотвественно для коммутатора нету пробелм назначать адреса

Моя задача разделить потоки от камер, Лб и 1-го влана.
 
miras написал(а):
1) Да, пакеты не проходят т.е. не работает
2) Да, с этим проблем нету так как 172.16.40.0 работает на 1 влане. и соотвественно для коммутатора нету пробелм назначать адреса

Моя задача разделить потоки от камер, Лб и 1-го влана.
Вот и наметился определенный путь решения вопроса. Прежде всего надо разобраться с непрохождением пакетов сетки 172.16.16.0 через коммутаторы. Как идея требующая проверки: возможно коммутаторам что-то "не нравится" в маске 255.255.248.0 сетки 172.16.16.0
Остальные хлопоты - уже производная от "непрохождения" пакетов.
 
oleg написал(а):
Вот и наметился определенный путь решения вопроса. Прежде всего надо разобраться с непрохождением пакетов сетки 172.16.16.0 через коммутаторы. Как идея требующая проверки: возможно коммутаторам что-то "не нравится" в маске 255.255.248.0 сетки 172.16.16.0
Остальные хлопоты - уже производная от "непрохождения" пакетов.


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

Спасибо большое Вам!
 

Вложения

  • 33.JPG
    33.JPG
    60.8 KB · Просмотры: 1
Подскажите для связи с LKDSCloud ЛБ использует тот же дефолтный порт 46000?
 
revit написал(а):
ЛБ<->облако - 4999
облако<->cервер 4997


Вот это ещё больше спасибо, хотя уже методом тыка нашли.

Теперь новый вопрос к разработчикам.
Имеем закрытую сеть. Нужно два блока подключить к LKDScloud. Понятно что обоим блокам надо разрешить исходящие подключения по порту 4999. Теперь вопрос по входящим, я звонил в техподдержку и мне сказали что входящие подключения идут на порт 46000 (ака дефолтный). Как быть со вторым?
 
очень странно что так ответили.. видимо вопрос был поставлен не совсем корректно.

при работе с облаком используется: ЛБ<->облако - 4999, а вот как происходит автозамена (подмена) порта в этой закрытой сетке... сие ведомо только властителем этих сетей.


poiZon написал(а):
Вот это ещё больше спасибо, хотя уже методом тыка нашли.

Теперь новый вопрос к разработчикам.
Имеем закрытую сеть. Нужно два блока подключить к LKDScloud. Понятно что обоим блокам надо разрешить исходящие подключения по порту 4999. Теперь вопрос по входящим, я звонил в техподдержку и мне сказали что входящие подключения идут на порт 46000 (ака дефолтный). Как быть со вторым?
 
котяра написал(а):
очень странно что так ответили.. видимо вопрос был поставлен не совсем корректно.


Вопрос был кмк очень чёткий: "какие порты надо дать блоку для обмена с облаком?", на что было сказано что блок использует исходящий порт 4999, а входящий адресуется на порт 46000.
 
Назад
Сверху