партнерский раздел
ФорумЭксплуатациятеряются приборы по с2000-Ethernet

Эксплуатация » теряются приборы по с2000-Ethernet

Добрый день. Схема приборов такая: Приборы-рс485-пульт-рс232-езернет-интернет-комп. Примерно 3 раза в день теряются все приборы на секунду и потом связь сразу восстанавливается. Макс пинг 12. в езернет Т=80 версия 2.55 протокол орион про, скорость 9600,пульт в режиме компьютер. . Версия пульта 3.02.Настройки пульта- пауза перед сеансом без смены направления передачи=110,Тайм-аут для ответа при поиске=230,Пауза после общей команды=220,Тайм-аут для ответа на запрос событий=520.
Вот настройки орион про :
https://yadi.sk/i/lLum27oR3K9PHT
https://yadi.sk/i/k51ALOJI3K9PLk
https://yadi.sk/i/r9ASDD4S3K9PMZ

11 месяцев 11 дней назад

avatar
Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

4 ответа

Добрый день. В настройках COM3 (программа Settings) параметр "Тайм-аут ожидания по локальной сети" установлен в значение 117 мс (видимо, время пинг не превышает 80 мс). Трансляция трафика идет через Интернет. Вполне вероятны моменты времени, когда пинг превышает 80 мс. В этих случаях могут возникать ситуации, когда на следующий запрос АРМ-а приходит предыдущий ответ (когда АРМ не дожидается задержавшийся ответ и отправляет новый запрос). Иными словами, происходит рассинхронизация трафика, которая со временем рассысывается, в т.ч. и через потерю/обнаружение пульта и подключенных к нему приборов. Три раза в день - это нормально для трансляции через Интернет. Возможно, стабильность увеличится, если поварьировать параметром "Тайм-аут ожидания по локальной сети" в сторону увеличения (например, 200 мс. поставить). Увеличение этого параметра в разумных пределах не затормозит работу систему по тому, как тайм-аут будет схлопываться по приему ответа от пульта (а ответ, как правило, будет приходить достаточно быстро).
P.S.: Если С2000-Ethernet (или др. преобразователи, например, РПИ) отсутствует в интерфейсе RS-485 пульта, то временные настройки пульта (программа RS485Settings) можно смело сбросить к значениям по умолчанию. Система будет работать быстрее.

10 месяцев 11 дней назад

avatar
Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

Если теряются сразу все приборы выведенные на Орион, то такая ситуация похожа на синхронизацию времени на компьютере.
Проверьте период синхронизации часов на компьютере.

10 месяцев 11 дней назад

avatar
Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

через месяц после пересаживания на оптику опять начались периодические пропадания связи, причём пропадания начинаются вечером в пятницу и заканчиваются утром в понедельник. В течение недели возможно тоже, но не так часто. Причина пропаданий скорее всего осталась прежней - резкое повышение пингов до 400-600мс, а вот почему это происходит не совсем понятно, вроде загруженность сети в будни выше должна быть. Настраивать маршрутизаторы я не могу, а компетентных специалистов нету, т.е. всё работает по-умолчанию.
Схема подключения приборов везде типовая: АРМ Орион ПРО (1.12.2.2) - ЛВС - езернет (пока версии разные 2.15, 2.52, 2.55, но собираюсь начать тотальное обновление) - рс232 - С2000М - рс485 - всё остальное оборудование. По индивидуальному виртуальному порту на каждый езернет.

В очередной раз перечитал РЭ на езернет и уже запутался, те же самые расчёты по формулам, обычный пинг менее 30мс, но вот эти редкие провалы до 600мс, если их учесть то тот же Таймаут по локальной сети будет 700мс, а ожидание квитанции 650мс не слишком ли много?
какие вообще параметры требуется изменить? Пауза после (перед) общей команды, Тайм-аут передачи по локальной сети, Пауза между посылками, ожидание квитанции, Протоколы везде "Орион" или могут различаться и это не принципиально? может ещё что-то?

5 месяцев 22 дня назад

avatar
Ситуация происходит со всеми приборами C2000-Ethernet или с конкретными направлениями? Когда пинг увеличивается, есть ли неответы на команду пинг или C2000-Ethernet отвечает 100%, но с большим временем ответа? Если ситуация происходит не на всех направлениях, то просьба посмотреть более детально и указать с приборами C2000-Ethernet каких версий есть подобные проявления. Если проявления на разных направлениях несколько отличаются, то лучше дать более детальное описание. "В течение недели возможно тоже, но не так часто " - как часто применительнок одному направлению (одному COM-порту)? Как часто это это происходит в выходные? Или в выходные стабильно пинг 600 мс.? Или с 600 падает до 4-х мс., а потом опять плавно нарастает и так перидоически?

Ольга 5 месяцев 22 дня назад

Неответ если может быть, то один и в самый момент провала пинга.
ну например за 3 число 8 периодов пропаданий было, одно в 0:00:03 (но это скорее с синхронизацией времени связано, там только одно направление упало), остальные вечером пошли, причём с 23 часов ажно 6 штук за час и везде 2.15 фигурировали и в 2 падениях ещё и остальные версии.
Пинг от 4 до 20 мс, падение до 600 мс это кратковременно случается с произвольной периодичностью, в это время и прибор теряются.

Волков Андрей 5 месяцев 22 дня назад

Рекомендую для начала обновить приборы C2000-Ethernet до v2.55, посмотреть на проявления и разбираться дальше. В случае просадки канала, возможна рассинхронизация запросов и ответов RS, в некоторых ситуациях прибор более ранних версий при работе в "прозрачном режиме" выполнял автоматический сброс, если фиксировал проблемы в RS (в v2.55 это исправлено; в v2.52 исправлено частично).  И ещё было бы интересно в моменты большого времени пинга послать бесконечную команду пинг до какого-либо другого устройства в сети, территориально расположенного там же. В случае резервирования каналов связи и включенном на сетевом оборудовании STP-протоколе, кратковременный большой пинг будет нормой при перестроении сетевым оборудованием маршрутов. При некорректной настройке STP (что вызывает большое количество ARP-запросов в лок.сети) постоянное перестроение маршрутов и ARP-таблиц сетевым оборудованием может быть причиной неустойчивого пинга прибора C2000-Ethernet. В любом случае, начать нужно с обновления приборов C2000-Ethernet.

Ольга 5 месяцев 21 день назад

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

Волков Андрей 5 месяцев 21 день назад

итак, до НГ обновил все езернеты до 2.55 (даже на Ресурсе), пропадания остались. За сегодня одно пропадание (в 20:23:44) даже в логи попалось:
непосредственно езернет ОПС
2018-01-02 20:23:42.800: From 192.168.50.21: bytes=60 seq=7cf8 TTL=255 ID=00f6 time=5.692ms
2018-01-02 20:23:44.055: From 192.168.50.21: bytes=60 SEQ=7cfa TTL=255 ID=00f8 time=260.584ms
2018-01-02 20:23:44.300: From 192.168.50.21: bytes=60 seq=7cfb TTL=255 ID=00f9 time=5.128ms
....
2018-01-02 20:23:45.795: Timeout waiting for seq=7cf9

это езернет Ресурса
2018-01-02 20:23:43.005: From 192.168.50.102: bytes=60 seq=7cf2 TTL=255 ID=0070 time=29.209ms
2018-01-02 20:23:44.039: From 192.168.50.102: bytes=60 SEQ=7cf4 TTL=255 ID=0072 time=63.209ms

2018-01-02 20:23:44.481: From 192.168.50.102: bytes=60 seq=7cf5 TTL=255 ID=0073 time=5.292ms
.....
2018-01-02 20:23:45.977: Timeout waiting for seq=7cf3

это медиаконвертер МОХА
2018-01-02 20:23:43.827: From 192.168.50.105: bytes=60 seq=7cec TTL=255 ID=08a9 time=1.775ms
2018-01-02 20:23:44.330: From 192.168.50.105: bytes=60 seq=7ced TTL=255 ID=08d0 time=4.433ms
2018-01-02 20:23:44.834: From 192.168.50.105: bytes=60 seq=7cee TTL=255 ID=08f6 time=1.109ms
2018-01-02 20:23:45.328: From 192.168.50.105: bytes=60 seq=7cef TTL=255 ID=091b time=2.324ms


это бевардовский IP-конвертер
2018-01-02 20:23:43.894: From 192.168.50.201: bytes=60 seq=7ce4 TTL=64 ID=bf77 time=1.085ms
2018-01-02 20:23:44.394: From 192.168.50.201: bytes=60 seq=7ce5 TTL=64 ID=bf78 time=1.640ms
2018-01-02 20:23:44.895: From 192.168.50.201: bytes=60 seq=7ce6 TTL=64 ID=bf79 time=0.833ms
2018-01-02 20:23:45.395: From 192.168.50.201: bytes=60 seq=7ce7 TTL=64 ID=bf7a time=2.016ms

 

всё это оборудование подключено в один маршрутизатор, самое дальнее расстояние по кабелю у езернета Ресурса (13 м), на 1,5 метра ближе МОХА, ещё на 1,5 метра ближе езернет ОПС, бевард на расстоянии 1 метра от маршрутизатора.
Странно что пинг подскочил только у езернетов.

сегодня ещё интересностей немного. Собирал логи с одного участка сети, а пропадания езернетов были в других, но и эти пропадания не остались незамеченными (в 0:46:23)
езернет ОПС (но он не отвалился)
2018-01-03 00:46:23.681: From 192.168.50.25: bytes=60 SEQ=2639 TTL=255 ID=0009 time=147.152ms
2018-01-03 00:46:24.038: From 192.168.50.25: bytes=60 seq=263a TTL=255 ID=000a time=4.753ms
2018-01-03 00:46:24.536: Timeout waiting for seq=2637
2018-01-03 00:46:24.544: From 192.168.50.25: bytes=60 seq=263b TTL=255 ID=000b time=7.891ms
2018-01-03 00:46:25.041: From 192.168.50.25: bytes=60 seq=263c TTL=255 ID=000c time=5.681ms
2018-01-03 00:46:25.541: From 192.168.50.25: bytes=60 seq=263d TTL=255 ID=000d time=6.038ms
2018-01-03 00:46:26.038: Timeout waiting for seq=2638

езернет Ресурса
2018-01-03 00:46:23.956: From 192.168.50.108: bytes=60 SEQ=2634 TTL=255 ID=00c7 time=112.042ms
2018-01-03 00:46:23.971: From 192.168.50.108: bytes=60 SEQ=2634 TTL=255 ID=00c7 time=127.813ms

2018-01-03 00:46:24.352: From 192.168.50.108: bytes=60 seq=2635 TTL=255 ID=00c8 time=5.229ms
2018-01-03 00:46:24.848: From 192.168.50.108: bytes=60 seq=2636 TTL=255 ID=00c9 time=4.494ms
2018-01-03 00:46:25.344: Timeout waiting for seq=2632
2018-01-03 00:46:25.349: From 192.168.50.108: bytes=60 seq=2637 TTL=255 ID=00ca time=5.119ms
2018-01-03 00:46:25.850: From 192.168.50.108: bytes=60 seq=2638 TTL=255 ID=00cb time=5.907ms
2018-01-03 00:46:26.344: Timeout waiting for seq=2633

и два медиаконвертера МОХА (которые абслютно никак не отреагировали)
2018-01-03 00:46:23.060: From 192.168.50.113: bytes=60 seq=262d TTL=255 ID=b4cf time=2.263ms
2018-01-03 00:46:23.560: From 192.168.50.113: bytes=60 seq=262e TTL=255 ID=b4e9 time=2.264ms

2018-01-03 00:46:23.000: From 192.168.50.115: bytes=60 seq=2626 TTL=255 ID=6f0c time=1.906ms
2018-01-03 00:46:23.500: From 192.168.50.115: bytes=60 seq=2627 TTL=255 ID=6f0d time=2.308ms

ещё одно пропадание (в 9:06:42) уже на ближайших участках, логгируемый сегмент не отваливался:
езернеты (через пару секунд на них и по паре тайм-аутов появилось)
2018-01-03 09:06:42.681: From 192.168.50.25: bytes=60 SEQ=10c1 TTL=255 ID=0056 time=7.472ms

2018-01-03 09:06:42.023: From 192.168.50.108: bytes=60 SEQ=10ba TTL=255 ID=0013 time=38.830ms

МОХА (стабильный пинг без тайм-аутов в рассматриваемом периоде)
2018-01-03 09:06:42.202: From 192.168.50.113: bytes=60 seq=10b5 TTL=255 ID=c5ee time=2.982ms

2018-01-03 09:06:42.140: From 192.168.50.115: bytes=60 seq=10ae TTL=255 ID=618d time=1.729ms

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

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

Ольга, что с этим делать то?

Волков Андрей 4 месяца 23 дня назад

Добрый вечер.
Поробуйте послать не просто команду пинг, а со временем ожидания (ключ -w), например, ping 192.168.50.25 -w 5000 (время ожидания ответа на команду пинг будет 5 сек.). Вероятно, во время увеличения времени ответа C2000-Ethernet в сети проходит большое количество широковещательного трафика либо не очень большое количество широковещательных пакетов большого размера (возможные причины: осуществляется пересторение маршрутов в случае работы STP-протокола либо в целом идёт какой-то поток широковещательного трафика). Возможные отличия С2000-Ethernet от других устройств в лок.сети: скорость работы в Ethernet - 10 Мбит, небольшой приёмный буфер. Если приёмный буфер переполнен, то запросы к С2000-Ethernet просто не попадут. Если пакеты попадают в очередь наполненного буфера, то образуется увеличенное время ответа.
Помимо широковаещательного трафика, причиной может служить и отсутствие достаточной пропускной способности в определённые моменты времени (например, в ночное время запускается какое-либо резервное копирование серверов). По этой части есть требования по гарантированной пропускной способности канала связи, необходимого для работы системы Орион с использованием приборов C2000-Ethernet (п.1.5 Требования к системе, РЭ С2000-Ethernet).
Чтобы что-то рекомендовать дальше, нужно сначала оценить реальное время ответа на команду пинг с ключом -w (либо отсутствие пинга).
Возможно, увеличенное время ответа окажется допустимым. Может, и не стоит бороться с одиночным провалом в системе за сутки. В целом, хотелось бы понять, как часто случаются потери и есть ли какие-либо закономерности (к сожалению, из предыдущего комментария не прояснилось).

Ольга 4 месяца 22 дня назад

Добрый день.
попробую пинговать все езернеты с этим ключом.
По потерям за сутки:
1 января: 15:39, 16:07, 18:00, 18:37
2 января: 20:23
3 января: 00:46, 9:06, 9:39, 9:44, 18:00
в локальной сети есть IP-камеры, но они есть постоянно связать их работу с пропаданиями как-то сложно, к тому же 1 января больше половины камер работали "вхолостую" - в офисе и ТЦ людей вообще не было, на парковках по минимуму - детекторы движения отдыхали в этот день, соответственно и потоки в сети были минимальные. 2 января уже пошло движение, но всего одно пропадание. Сегодня уже половина дня прошло, а тишина, хотя движение идёт, люди активно ходят везде.
Резервного копирования серверов нету, наша маленькая локальная сеть состоит из 2 видеосерверов, 1 Ориона (свою базу ежедневно рано утром складывает на второй диск), 1 Ресурса, 4 рабочих компов.

В общем и я не могу пока найти закономерности.

пробовал стандартным пингом и сторонней программой, в обоих ключ -w 5000 присутствовал: никаких изменений, тайм аут в ответах появляется через пару секунд после увеличенного пинга (по показаниям hrping), стандартный пинг таких точностей не показал, у него просто тайм аут.

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

Волков Андрей 4 месяца 22 дня назад

Была у нас такая же беда с изернетами в одной сети с камерами. Внезапно Пинг взлетал до 600 и более и изернетами отваливался. Однако камеры при этом работали без проблем. При этом в сети начинался шторм. Долго искали виновников и наконец нашли. Оказалась виновата одна из камер и настройка мультикаста (была включена). Это и давало широковещательный шторм. После выключения работа изернетов полностью востановилась

Ситников Алексей Юрьевич 4 месяца 18 дней назад

прошёлся по всем доступным камера, где нашёл мультикаст - отключил, но потеря всё равно проявилась(
а чем диагностировали шторм в сети? а то я ни разу не админ, инструментариев не знаю.

Волков Андрей 4 месяца 17 дней назад

Диагностировали шторм - резким увеличением времени и непостоянством значения пингов до оборудования. Резко взлетал пинг до изернетов до 600 и выше (стандартный пинг у нас 4-10 иногда до 16). Затем они отваливались. Пинд до другого оборудования колбасило в очень больших значениях от 10 до 400 (стандартный пинг у нас 4-8).
Искали виновника трое суток. Искали виновную настройку еще пару дней. 
Сначала все отклюбчили от сети. Затем подключили изернеты, так как сигнализация превыше видио. Контролириовали пинг до изернетов в течении пары часов. Затем подключали по одной или группе видеокамер и снова ждали по паре часов.
Длительное время ожидание связано с тем что шторм начинался не сразу после включения камеры а после некоторого времения (0,5-2 часа). Через несколько часов мог так же внезапно прекратится а затем все снова по новой.

Ситников Алексей Юрьевич 4 месяца 17 дней назад

Андрей, что значит "тайм аут в ответах появляется через пару секунд после увеличенного пинга" (время пинг 2000 мс. или что-то другое)?
Какое максимальное время пинга с ключом -w? И были ли неответы при отсылке пинг с ключом -w?

В настройках C2000-Ethernet-ов "Тип протокола" установлен в значение "Орион"? Параметр тип протокола, установленный в значение "Орион", позволяет C2000-Ethernet уничтожать и не ретранслировать в RS/Ethernet устаревшие пакеты в случае образования их очереди (актуальными считаются только последние 3 пакета, остальные не ретранслируются). Этот тип протокола в С2000-Ethernet можно использовать и для сторонних систем, и для опроса пульта С2000-М, и для опроса приборов Орион. Параметр исторически сохранил такое название. В самих ранних версиях прибора, действительно, была привязка к протоколу при анализе пакетов. Уже давно при работе в прозрачном режиме этот параметр определяет исключительно разновидность режима: "с оптимизацией" или "без оптимизации" данных. Если где-то установлен не "Орион", то установите "Орион".

Ольга 4 месяца 16 дней назад

Что за коммутатор у Вас?

Ситников Алексей Юрьевич 4 месяца 16 дней назад

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

Ольга, это в моём предыдущем большом сообщении видно, когда пинг подскакивает до 200-300мс, следующий пинг уже нормальный, а следом идёт тайм аут и потом опять всё идеально.
hrping показал такой результат за сутки:
Packets: sent=85458, rcvd=85451, error=0, lost=7 (0.0% loss) in 42728.505479 sec  
RTTs in ms: min/avg/max/dev: 4.237 / 5.374 / 281.844 / 1.847  

обычный пинг:
Пакетов: Отправлено = 83679, получено = 83676, потеряно = 3
    (0% потерь)
Приблизительное время приёма-передачи в мс:
    Минимальное = 4мс, максимальное = 21мс, среднее = 4мс

при этом потери приборов были в обоих случаях, ключ -w использовал.

проверил, в езернетах для ОПС везде Орион.
а тип Орион можно и для Ресурса использовать? у меня там показания со счётчиков теряться не будут?

Волков Андрей 4 месяца 16 дней назад

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

Для АРМ Ресурс лучше ставить режим без оптимизации (протокол, отличный от Орион). Возможно, и режим с оптимизацией для каких-то счётчиков будет актуален, но это зависит от протокола обмена счётчика. Если данные передаются без ожидания кивтирования, то оптимизацию включать не стоит (во избежание потери некоторых показаний счётчиков). При стабильном канале даже с режимом оптимизации всё будет работать без потерь по той причине, что оптимизация просто не будет срабатывать, т.к. не будет образовываться очередь пакетов для ретрансляции.

Ольга 4 месяца 16 дней назад

в большом окне ключа не было, там всё по-умолчанию. Добавление ключа -w 5000 к изменениям в логах не привело, т.е. пингов больше 200-300 мс не появилось и тайм ауты остались на своих местах, выглядит это так
2018-01-06 02:30:03.686: From 192.168.50.21: bytes=60 seq=6911 TTL=255 ID=0070 time=4.520ms
2018-01-06 02:30:05.903: From 192.168.50.21: bytes=60 SEQ=6915 TTL=255 ID=0074 time=221.627ms
2018-01-06 02:30:06.188: From 192.168.50.21: bytes=60 seq=6916 TTL=255 ID=0075 time=5.340ms
2018-01-06 02:30:06.686: From 192.168.50.21: bytes=60 seq=6917 TTL=255 ID=0076 time=4.458ms
2018-01-06 02:30:07.187: From 192.168.50.21: bytes=60 seq=6918 TTL=255 ID=0077 time=5.589ms
2018-01-06 02:30:07.686: From 192.168.50.21: bytes=60 seq=6919 TTL=255 ID=0078 time=4.697ms
2018-01-06 02:30:08.186: From 192.168.50.21: bytes=60 seq=691a TTL=255 ID=0079 time=4.557ms
2018-01-06 02:30:08.687: From 192.168.50.21: bytes=60 seq=691b TTL=255 ID=007a time=5.217ms
2018-01-06 02:30:09.186: From 192.168.50.21: bytes=60 seq=691c TTL=255 ID=007b time=4.596ms
2018-01-06 02:30:09.686: From 192.168.50.21: bytes=60 seq=691d TTL=255 ID=007c time=4.497ms
2018-01-06 02:30:10.186: From 192.168.50.21: bytes=60 seq=691e TTL=255 ID=007d time=4.768ms
2018-01-06 02:30:10.682: Timeout waiting for seq=6912
2018-01-06 02:30:10.682: Timeout waiting for seq=6913
2018-01-06 02:30:10.682: Timeout waiting for seq=6914

Да, визуально получается, что таймауты идут после увеличения пинга, но если посмотреть на номера seq, то в логе за 6911 сразу идёт 6915 и только через 5 секунд возвращается таймаут по 6912, 6913 и 6914.

езернеты в Ресурсе используем только для сбора данных с КДЛок-АСР2-импульсные, всякие сторонние счётчик через МОХА подключаем.

добрался до длинков, у нас это DGS-1510-20, открыл настройки и понял, что нам нужен админ))

Волков Андрей 4 месяца 16 дней назад

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

А так у Вас проблемы скорре всего с сетью.
Вообще Д-Линки иногда попадаются очень капризные и глючные - с одним оборудованием они работают запросто а с другим нивкакую (есть у меня ноутбук - так с д-линками серии DES-1210 он ни в какую не хочет конектится - конектится, проходит адентификацию, выставляет скорость по порту 100 вместо 1000 и отваливается. Подключаю к другому другому д-линку только серии DGS-1210 или НР, Планету, МОХА, алиедтесун, зукселю, микротику и  проблем нет. Приходится с д-линком вручную настравать лан порт ноутбука на тип передачи данных и скорости).

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

Ситников Алексей Юрьевич 4 месяца 16 дней назад

это бевардовский IP-конвертер
2018-01-02 20:23:43.894: From 192.168.50.201: bytes=60 seq=7ce4 TTL=64 ID=bf77 time=1.085ms

А вот это мне не понятно.
Если этот IP-конвертер включен в этот же коммутатор, то почему у него TTL=64 как будто пакет до него прошел через 191 узел (коммутатор). Должно быть значение 255 или чуть ниже в зависимости от кол узлов через которые проходит пакет пинга.
Попробуйте отключить конвертер и понаблюдать пинги до изернетов.
Настройки беварда можно глянуть?

Ситников Алексей Юрьевич 4 месяца 15 дней назад

обновление это наверное хорошо, мои длинки везде показывают версию 1.30.007 (на оф.сайте это считай самая первая), скачал 1.40.019, выбрал в ассистенте обновление прошивки, подсунул последнюю версию, ассистент сказал что Yes, is supported, прилежно подождал минут 10 до появления надписи Succeed, а версия так и осталась 1.30.007. Может конечно обновки не кумулятивные и надо прошивать последовательно все версии, но такое не описано.
Далее, сами коммутаторы были закуплены осенью-зимой, проблема с пропаданием была и до апгрейда сети, ещё на "меди", там топология точно не предусматривала колец)
С радостью бы задал и вланы и приоритеты, но я правда не админ и все эти настройки меня вгоняют в уныние:
Сетевые карты - может быть, т.к. на обоих серваках (Орион и Ресурс) почему-то линк выше 100мбит не желает подниматься, хотя и в настройках карт выбрано и порты на коммутаторах гигабитные, но замены нету((
Блоки питания со стороны езернетов - сплошные РИПы (что в ШПСе), со стороны коммутаторов - инелты. Если для отлова неисправности нужен осциллограф - отдельная печаль, нету такого богатства у нас.
Из подозрительной активности - сообщения от спайдера (др.вэб) про заблокированный JS.IFrame.393, появляется если опрашивать/открывать камеры (вроде были Polyvision) за ВПНом - подозреваю, что это братья-китайцы намудрили с вэб-интерфейсом своих камер, там же есть два езернета, с которыми проблем нету, они общаются с отдельным компом со своим ядром опроса.
почему TTL=64 не знаю, никакого дополнительного оборудования между комп-коммутатор-конвертер нету.
настройки заслуживающие внимание, всё остальное кроме RTSP отключено:

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

Волков Андрей 4 месяца 15 дней назад

Теперь нужно понять построение Вашей сети. Несколько вопросов:
1. Серверы воткнуты в тот же коммутатор что и отваливающиеся изернеты?
2. С какого компа Вы запускаете пинги изернетов и другого оборудования? Где в сети находится этот комп?
3. Какой IP адрес имеет коммутатор?
4. В настройках беварда указаны DNS из другой подсети это так и нужно или чтоб просто было? В настройках изернета какие сетевые настройки указаны?

По обновлению Длинка - скорее всего его нужно просто перезагрузить.

Ситников Алексей Юрьевич 4 месяца 15 дней назад

1. Да, разумеется не все, но самый часто отваливающийся находится в 10+2 метрах (по проводам) от сервера.
2. С сервера (192.168.50.20) и запускаю.
3. Теперь уже 192.168.50.11 (был по-умолчанию - 10.90.90.90)
4. Просто чтобы было, к интернету всё равно не подключен.
у езернетов: 192.168.50.ххх / 255.255.255.0 / 192.168.50.254 / полудуплекс / порты у всех свои

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

Волков Андрей 4 месяца 15 дней назад

По поводу TTL. Начальное значение TTL устанавливает тот, кто формирует пакет. Можно установить любое значение в диапазоне от 1 до 255. Далее TTL уменьшается на единицу при прохождении через промежуточный сетевой узел. При очень маленьком начальном значении TTL велика вероятность, что пакет может не дойти до конечного получателя. С наибольшей вероятностью, "бевардовский IP-конвертер" изначально устанавливает TTL = 64, когда формирует ответ на команду пинг.

По поводу отсутствия ответа на команду пинг с ключом -w 5000. Если бы ответы с таким временем ожидания были 100% и при этом в худшие моменты тайм-аут ответа не превышал, например, 1000 мс., то был бы смысл увеличить тайм-ауты в АРМ, как ранее советовал Налетов Константин. Но так как есть неответы, увеличением тайм-аутов в АРМ ситуацию не исправить (можно уменьшить вероятность возникновения,  но не устранить.. и не стоит забывать про побочный эффект, что увеличение тайм-аутов ожидания замедляет работу системы). То, что прибор не отвечает на команду пинг, говорит о том, что он и не получает сами запросы. Если такая ситуация возникает с запросами пинг, то она возникает и с запросами от АРМ (соответственно, если нет запроса к прибору, то нет и ответа от прибора). Приборы будут периодически теряться/обнаруживаться, если не устранить причину по которой это происходит (предполагаем, что причина в периодическом широковещательном трафике).

Ольга 4 месяца 14 дней назад

По поводу поиска источника широковещательного трафика. Если есть возможность и свободный порт на Dlink, то можно зазеркалировать трафик того Ehernet-порта, к которому подключен один из C2000-Ethernet, связь с приборами которого периодически теряется/восстанавливается. К этому свободному порту подключить ноутбук. На нём установить wireshark ( https://www.wireshark.org/#download ). ПО бесплатное. В wireshark настроить опцию сохранение лога в файл с автоматической генерацией нового файла, например, каждые 10 МБайт. Поставить в опциях удобочитаемое время c датой, временем и миллисекундами (view/time display format). Когда ситуация с потерей в АРМ повторится, посмотреть наличие широковещательного трафика в логах в этот момент времени или несколько раньше. Там же будет указан источник этого трафика (его IP и/или MAC). В более простом варианте можно сделать всё то же самое, но не зеркалируя трафик на свободный порт, а запустив wireshark на любом компьютере в лок.сети (просто может оказаться важным, где именно относительно С2000-Ethernet расположен этот компьютер). В большинстве случае, wireshark-а на каком-либо ПК без зеркалирования достаточно для обнаружения источника трафика (главное, включить логирование в файл, чтобы в онлайн окне просмотра нужная информация не затёрлась другими новыми пакетами).

Ольга 4 месяца 14 дней назад

Ну и в дополнении к ответу Ольги я могу добавить что нужно разбиратся с линком на портах серверов. Это непорядок когда гигапитный порт коммутатора и гигабитный порт сервера подключаются в автомате на сотке.
От себя могу сказать что причина скорее всего кроется в производителе чипа сетевой карты сервера. В моем случае у обоих проблемных ноутбуков был чип от Realtek (RTL), а у работающего от броадкома.
Поэтому нужно поставить в серверы сетевухи с чипами напримерт того же д-линка. благо они стоят не таких уж и большох денег.

Ситников Алексей Юрьевич 4 месяца 14 дней назад

пока пробую натравить "акулу" с рабочего компа, оказывается широковещанием занимаются и езернеты:
Frame 484: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: ZaoNvpBo_01:b7:76 (00:18:bc:01:b7:76), Dst: Broadcast (ff:ff:ff:ff:ff:ff)

Who has 192.168.50.20? Tell 192.168.50.26

20 - это Орион, 26 - один из езернетов.

Пока тишь да гладь.

Забавно, второй день как запустил "акулу" и пропаданий нету, было одно, но в момент "Отметки дат", судя по всему это связано с синхронизацией времени.

Волков Андрей 4 месяца 14 дней назад

Вы д-линки все обновили? Может и в них крылась засада?

Ситников Алексей Юрьевич 4 месяца 12 дней назад

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

Волков Андрей 4 месяца 12 дней назад

вроде что-то попалось, правда непонятно откуда оно у нас взялось:

итак, в момент пропадания в логе появилось огромное количество однотипных пакетов. Просмотрел случайные логи за другое время - протокол MPEG TS больше нигде не появлялся.
Адрес 10.115.202.14 это видимо внутренний адрес какого-то абонента у нашего провайдера, а 239.255.43.45 это из IP-TV, адрес Первого канала. Отсюда риторический вопрос - а к нам то оно как попало? Каким-то чудесным образом временами на пару секунд прорывается через наш роутер с маршрутизатора провайдера? В офисе точно смотреть некому - офис пустой, да и если бы был просмотр, то этот протокол появлялся в логах намного чаще. Похоже вопрос с этого форума плавно перетечёт в общение с провайдером))

Волков Андрей 4 месяца 11 дней назад

Источник мультикастовых MPEG-пакетов - это IP адрес 10.115.202.14. В логе MAC-адрес источника пакета - 00:07:4F:F7:39:00 (старшие 3 байта MAC адреса принадлежат производителю Cisco). По факту:
 - либо 10.115.202.14 находится в Вашей физической локальной сети и имеет MAC, равный 00:07:4F:F7:39:00 (может, всё-таки IP-камера ??? ... правда, не понятно причём тут тогда мультикастовый IP-TV 239.255.43.45.. );
 - либо 10.115.202.14 находится в другой локальной сети, тогда 00:07:4F:F7:39:00 - это MAC адрес внутреннего интерфейса того шлюза, через который этот трафик попадает в Вашу локальную сеть.

Можно ещё повнимательнее посмотреть лог-файл и попытаться понять, а кто захотел получать этот мультикаст ( https://habrahabr.ru/post/217585/ )..

Ольга 4 месяца 11 дней назад

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

Волков Андрей 4 месяца 10 дней назад

Наверное, получилось познавательно и содержательно для всех, читающих тему :))). Всем спасибо!

Ольга 4 месяца 10 дней назад

Наверное, получилось познавательно и содержательно для всех, читающих тему :))). Всем спасибо!– Ольга 1 минуту назад

Не могу не согласиться.

Тремасов Константин Александрович 4 месяца 10 дней назад

да-да, я хоть понял как интерпретировать показания пинга и слегка разобрался в wireshark, ну и подобновил парк оборудования.

Волков Андрей 4 месяца 10 дней назад

ну чтож, практически неделя прошла, а потерь больше не было, даже тех, которые в 0:00:00 иногда случались. Видимо от провайдерского оборудования всё и летело, т.к. мои настройки не повлияли.

Волков Андрей 4 месяца 4 дня назад

Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

не слишком ли много?

При таком пинге (600мс) нормально, не следует сильно заморачиваться на счёт большого значения, ведь это таймаут. То есть, если обмен произойдёт ранее, чем истечёт это время, то ожидание (таймаут) прервётся и обмен продолжится далее по алгоритму.

5 месяцев 22 дня назад

avatar
Всё верно. Но есть нюанс. Тайм-аут будет срабатывать полностью при поиске ещё не обнаруженных приборов. Если же прибор добавлен в базу данных Master-устройства (пульта/АРМ), но при этом физически не подключен, то тайм-аут будет выдерживаться не так уж и редко.

Ольга 5 месяцев 21 день назад

Ольга, есть ли у Болида какой либо документ (справка и т.п.), разъясняющий в деталях, как используются (применяются) таймауты, паузы (СОМ-портов, С2000-Ethernet и др.) в различных режимах работы аппаратуры? Например о том, что Вы упомянули выше, я не знал. Про настройку параметров RS-485/232 пульта С2000М вообще мало инфы.

Налетов Константин 5 месяцев 21 день назад

Константин, про настройку параметров пульта С2000M и АРМ информации мало по той причине, что при построении системы без использования различных преобразователей (С2000-Ethernet, РПИ и т.п.), изменение этих параметров крайне не рекомендуется. Т.е. параметры уже принимают оптимальные значения. Про сами тайм-ауты в деталях не рассказывается потому, что они являются следствием программной реализации протоколов обменов. Протоколы являются закрытыми. Программная реализация отличается в различных Master-устройствах, а иногда и в различных версиях одного и того же Master-устройства.
Рекомендации по настройке тайм-аутов приведены в документации на соответствующие преобразователи (С2000-Ethernet, РПИ и т.п.). В частности, в С2000-Ethernet приведены расчётные формулы, в которых учитывается время пинг. Но если рассуждать "в общем", словосочетание "тайм-аут ответа" предполагает максимальное время ожидания ответа на что-либо и он будет срабатывать по максимуму в случаях, когда ответ почему-то не пришёл (например, если запрос осуществлялся к тому, кого нет в интерфейсе, или если прибор присутствует в интерфейсе, но почему-то не сформировал ответ.. такого.. конечно, быть не должно.. это нештатная ситуация). С уверенностью можно сказать, что даже без открытия особенностей закрытых протоколов и их реализации в различных Master-устройствах, максимальное замедление от увеличенных тайм-аутов будет ощущаться в случае отсутствия в RS приборов, включённых в базу данных, либо при наличии проблем в RS-интерфейсе.

Ольга 4 месяца 14 дней назад

Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

Добавить ответ

Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

ПОКАЗАН

2191 раз

ЗАДАН

11 месяцев 11 дней назад

ПРОДУКТЫ

С2000-Ethernet

По каждому вопросу/ответу можно добавлять комментарии. Комментарии предназначены для уточнения вопроса/ответа.

Слева от каждого вопроса/ответа указано число – количество голосов. Над и под этим числом имеются стрелки, с помощью которых вы можете проголосовать за актуальный или понравившийся вам вопрос/ответ. Причем можете оставить свой голос как в «плюс» (верхняя стрелка), так и в «минус» (нижняя стрелка), если сообщение, например, неуместно или вы его не поддерживаете. Также можно отменить свой голос, если проголосовали ошибочно или передумали. Для отмены надо нажать на оранжевую стрелку.