|
|
Добрый день. Схема приборов такая: Приборы-рс485-пульт-рс232-езернет-интернет-комп. Примерно 3 раза в день теряются все приборы на секунду и потом связь сразу восстанавливается. Макс пинг 12. в езернет Т=80 версия 2.55 протокол орион про, скорость 9600,пульт в режиме компьютер. . Версия пульта 3.02.Настройки пульта- пауза перед сеансом без смены направления передачи=110,Тайм-аут для ответа при поиске=230,Пауза после общей команды=220,Тайм-аут для ответа на запрос событий=520. 7 лет 6 месяцев назад 
Меркуль Игорь Юрьевич 141Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?) |
|
|
Добрый день. В настройках COM3 (программа Settings) параметр "Тайм-аут ожидания по локальной сети" установлен в значение 117 мс (видимо, время пинг не превышает 80 мс). Трансляция трафика идет через Интернет. Вполне вероятны моменты времени, когда пинг превышает 80 мс. В этих случаях могут возникать ситуации, когда на следующий запрос АРМ-а приходит предыдущий ответ (когда АРМ не дожидается задержавшийся ответ и отправляет новый запрос). Иными словами, происходит рассинхронизация трафика, которая со временем рассысывается, в т.ч. и через потерю/обнаружение пульта и подключенных к нему приборов. Три раза в день - это нормально для трансляции через Интернет. Возможно, стабильность увеличится, если поварьировать параметром "Тайм-аут ожидания по локальной сети" в сторону увеличения (например, 200 мс. поставить). Увеличение этого параметра в разумных пределах не затормозит работу систему по тому, как тайм-аут будет схлопываться по приему ответа от пульта (а ответ, как правило, будет приходить достаточно быстро). 7 лет 5 месяцев назад
Сигуа Ольга 216Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?) |
|
|
Если теряются сразу все приборы выведенные на Орион, то такая ситуация похожа на синхронизацию времени на компьютере. 7 лет 5 месяцев назад
Налетов Константин 2021Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?) |
|
|
через месяц после пересаживания на оптику опять начались периодические пропадания связи, причём пропадания начинаются вечером в пятницу и заканчиваются утром в понедельник. В течение недели возможно тоже, но не так часто. Причина пропаданий скорее всего осталась прежней - резкое повышение пингов до 400-600мс, а вот почему это происходит не совсем понятно, вроде загруженность сети в будни выше должна быть. Настраивать маршрутизаторы я не могу, а компетентных специалистов нету, т.е. всё работает по-умолчанию. 7 лет назад
Волков Андрей 3822Ситуация происходит со всеми приборами C2000-Ethernet или с конкретными направлениями? Когда пинг увеличивается, есть ли неответы на команду пинг или C2000-Ethernet отвечает 100%, но с большим временем ответа? Если ситуация происходит не на всех направлениях, то просьба посмотреть более детально и указать с приборами C2000-Ethernet каких версий есть подобные проявления. Если проявления на разных направлениях несколько отличаются, то лучше дать более детальное описание. "В течение недели возможно тоже, но не так часто " - как часто применительнок одному направлению (одному COM-порту)? Как часто это это происходит в выходные? Или в выходные стабильно пинг 600 мс.? Или с 600 падает до 4-х мс., а потом опять плавно нарастает и так перидоически?
– Сигуа Ольга 7 лет назад Неответ если может быть, то один и в самый момент провала пинга.
ну например за 3 число 8 периодов пропаданий было, одно в 0:00:03 (но это скорее с синхронизацией времени связано, там только одно направление упало), остальные вечером пошли, причём с 23 часов ажно 6 штук за час и везде 2.15 фигурировали и в 2 падениях ещё и остальные версии. Пинг от 4 до 20 мс, падение до 600 мс это кратковременно случается с произвольной периодичностью, в это время и прибор теряются. – Волков Андрей 7 лет назад Рекомендую для начала обновить приборы C2000-Ethernet до v2.55, посмотреть на проявления и разбираться дальше. В случае просадки канала, возможна рассинхронизация запросов и ответов RS, в некоторых ситуациях прибор более ранних версий при работе в "прозрачном режиме" выполнял автоматический сброс, если фиксировал проблемы в RS (в v2.55 это исправлено; в v2.52 исправлено частично). И ещё было бы интересно в моменты большого времени пинга послать бесконечную команду пинг до какого-либо другого устройства в сети, территориально расположенного там же. В случае резервирования каналов связи и включенном на сетевом оборудовании STP-протоколе, кратковременный большой пинг будет нормой при перестроении сетевым оборудованием маршрутов. При некорректной настройке STP (что вызывает большое количество ARP-запросов в лок.сети) постоянное перестроение маршрутов и ARP-таблиц сетевым оборудованием может быть причиной неустойчивого пинга прибора C2000-Ethernet. В любом случае, начать нужно с обновления приборов C2000-Ethernet.
– Сигуа Ольга 7 лет назад ну с обновлением согласен, старенькие чаще всех летают.
а вот по параметрам: "Пауза после (перед) общей команды, Тайм-аут передачи по локальной сети, Пауза между посылками, ожидание квитанции, Протоколы везде "Орион", для моей схемы достаточно их или ещё какие-то надо будет поменять? Расчёты то сделаю уже по факту замеров. – Волков Андрей 7 лет назад итак, до НГ обновил все езернеты до 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 (!!!) езернетов в локальной сети, правда в этот раз потерялся в орионе только один. Ольга, что с этим делать то? – Волков Андрей 6 лет 11 месяцев назад Добрый вечер.
Поробуйте послать не просто команду пинг, а со временем ожидания (ключ -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 (либо отсутствие пинга). Возможно, увеличенное время ответа окажется допустимым. Может, и не стоит бороться с одиночным провалом в системе за сутки. В целом, хотелось бы понять, как часто случаются потери и есть ли какие-либо закономерности (к сожалению, из предыдущего комментария не прояснилось). – Сигуа Ольга 6 лет 11 месяцев назад Добрый день.
попробую пинговать все езернеты с этим ключом. По потерям за сутки: 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), стандартный пинг таких точностей не показал, у него просто тайм аут. После обнаружения потерянных приборов команды до них ещё минуты две не доходят, а это как раз и раздражает всех. – Волков Андрей 6 лет 11 месяцев назад Была у нас такая же беда с изернетами в одной сети с камерами. Внезапно Пинг взлетал до 600 и более и изернетами отваливался. Однако камеры при этом работали без проблем. При этом в сети начинался шторм. Долго искали виновников и наконец нашли. Оказалась виновата одна из камер и настройка мультикаста (была включена). Это и давало широковещательный шторм. После выключения работа изернетов полностью востановилась
– Ситников Алексей Юрьевич 6 лет 11 месяцев назад прошёлся по всем доступным камера, где нашёл мультикаст - отключил, но потеря всё равно проявилась(
а чем диагностировали шторм в сети? а то я ни разу не админ, инструментариев не знаю. – Волков Андрей 6 лет 11 месяцев назад Диагностировали шторм - резким увеличением времени и непостоянством значения пингов до оборудования. Резко взлетал пинг до изернетов до 600 и выше (стандартный пинг у нас 4-10 иногда до 16). Затем они отваливались. Пинд до другого оборудования колбасило в очень больших значениях от 10 до 400 (стандартный пинг у нас 4-8).
Искали виновника трое суток. Искали виновную настройку еще пару дней. Сначала все отклюбчили от сети. Затем подключили изернеты, так как сигнализация превыше видио. Контролириовали пинг до изернетов в течении пары часов. Затем подключали по одной или группе видеокамер и снова ждали по паре часов. Длительное время ожидание связано с тем что шторм начинался не сразу после включения камеры а после некоторого времения (0,5-2 часа). Через несколько часов мог так же внезапно прекратится а затем все снова по новой. – Ситников Алексей Юрьевич 6 лет 11 месяцев назад Андрей, что значит "тайм аут в ответах появляется через пару секунд после увеличенного пинга" (время пинг 2000 мс. или что-то другое)?
Какое максимальное время пинга с ключом -w? И были ли неответы при отсылке пинг с ключом -w? В настройках C2000-Ethernet-ов "Тип протокола" установлен в значение "Орион"? Параметр тип протокола, установленный в значение "Орион", позволяет C2000-Ethernet уничтожать и не ретранслировать в RS/Ethernet устаревшие пакеты в случае образования их очереди (актуальными считаются только последние 3 пакета, остальные не ретранслируются). Этот тип протокола в С2000-Ethernet можно использовать и для сторонних систем, и для опроса пульта С2000-М, и для опроса приборов Орион. Параметр исторически сохранил такое название. В самих ранних версиях прибора, действительно, была привязка к протоколу при анализе пакетов. Уже давно при работе в прозрачном режиме этот параметр определяет исключительно разновидность режима: "с оптимизацией" или "без оптимизации" данных. Если где-то установлен не "Орион", то установите "Орион". – Сигуа Ольга 6 лет 11 месяцев назад Алексей Юрьевич, мне для таких диагностик потребуется сутки ждать, чтобы прям точно, т.к. мои штормы могут быть очень редки. Коммутаторы вроде Длинки были.
Ольга, это в моём предыдущем большом сообщении видно, когда пинг подскакивает до 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 использовал. проверил, в езернетах для ОПС везде Орион. а тип Орион можно и для Ресурса использовать? у меня там показания со счётчиков теряться не будут? – Волков Андрей 6 лет 11 месяцев назад И предыдущее большое окно было видно, и последнее небольшое.. Но нигде не видно, с каким временем указывался ключ -w. Поэтому не понятно, какое макимальное время ожидался ответ на команду пинг.
Для АРМ Ресурс лучше ставить режим без оптимизации (протокол, отличный от Орион). Возможно, и режим с оптимизацией для каких-то счётчиков будет актуален, но это зависит от протокола обмена счётчика. Если данные передаются без ожидания кивтирования, то оптимизацию включать не стоит (во избежание потери некоторых показаний счётчиков). При стабильном канале даже с режимом оптимизации всё будет работать без потерь по той причине, что оптимизация просто не будет срабатывать, т.к. не будет образовываться очередь пакетов для ретрансляции. – Сигуа Ольга 6 лет 11 месяцев назад в большом окне ключа не было, там всё по-умолчанию. Добавление ключа -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, открыл настройки и понял, что нам нужен админ)) – Волков Андрей 6 лет 11 месяцев назад Д-линки нужно обновить последней прошивкой, уж больно много там пофиксено ошибок.
Далее я бы камеры и изернеты разделил по отдельным виланам задав ограничение трафика по портам и смотреть дальше. А так у Вас проблемы скорре всего с сетью. Вообще Д-Линки иногда попадаются очень капризные и глючные - с одним оборудованием они работают запросто а с другим нивкакую (есть у меня ноутбук - так с д-линками серии DES-1210 он ни в какую не хочет конектится - конектится, проходит адентификацию, выставляет скорость по порту 100 вместо 1000 и отваливается. Подключаю к другому другому д-линку только серии DGS-1210 или НР, Планету, МОХА, алиедтесун, зукселю, микротику и проблем нет. Приходится с д-линком вручную настравать лан порт ноутбука на тип передачи данных и скорости). Кстати виновниками шторма могут быть: 1. кольцо топологии соединения (изернет может быть только древовидным); 2. неисправность сетевой карты одного из компьютеров в сети или порта оборудования; 3. Неисправность блока питания, который гонит вместо фильтрованного питания еще и кучу помех, которые и сводят с ума сетевой порт оборудования; 4. вирус. – Ситников Алексей Юрьевич 6 лет 11 месяцев назад это бевардовский 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 или чуть ниже в зависимости от кол узлов через которые проходит пакет пинга. Попробуйте отключить конвертер и понаблюдать пинги до изернетов. Настройки беварда можно глянуть? – Ситников Алексей Юрьевич 6 лет 11 месяцев назад обновление это наверное хорошо, мои длинки везде показывают версию 1.30.007 (на оф.сайте это считай самая первая), скачал 1.40.019, выбрал в ассистенте обновление прошивки, подсунул последнюю версию, ассистент сказал что Yes, is supported, прилежно подождал минут 10 до появления надписи Succeed, а версия так и осталась 1.30.007. Может конечно обновки не кумулятивные и надо прошивать последовательно все версии, но такое не описано.
Далее, сами коммутаторы были закуплены осенью-зимой, проблема с пропаданием была и до апгрейда сети, ещё на "меди", там топология точно не предусматривала колец) С радостью бы задал и вланы и приоритеты, но я правда не админ и все эти настройки меня вгоняют в уныние:  Сетевые карты - может быть, т.к. на обоих серваках (Орион и Ресурс) почему-то линк выше 100мбит не желает подниматься, хотя и в настройках карт выбрано и порты на коммутаторах гигабитные, но замены нету(( Блоки питания со стороны езернетов - сплошные РИПы (что в ШПСе), со стороны коммутаторов - инелты. Если для отлова неисправности нужен осциллограф - отдельная печаль, нету такого богатства у нас. Из подозрительной активности - сообщения от спайдера (др.вэб) про заблокированный JS.IFrame.393, появляется если опрашивать/открывать камеры (вроде были Polyvision) за ВПНом - подозреваю, что это братья-китайцы намудрили с вэб-интерфейсом своих камер, там же есть два езернета, с которыми проблем нету, они общаются с отдельным компом со своим ядром опроса. почему TTL=64 не знаю, никакого дополнительного оборудования между комп-коммутатор-конвертер нету. настройки заслуживающие внимание, всё остальное кроме RTSP отключено:  отключить конечно попробую, но это камера на стройке, надо будет посовещаться. – Волков Андрей 6 лет 11 месяцев назад Теперь нужно понять построение Вашей сети. Несколько вопросов:
1. Серверы воткнуты в тот же коммутатор что и отваливающиеся изернеты? 2. С какого компа Вы запускаете пинги изернетов и другого оборудования? Где в сети находится этот комп? 3. Какой IP адрес имеет коммутатор? 4. В настройках беварда указаны DNS из другой подсети это так и нужно или чтоб просто было? В настройках изернета какие сетевые настройки указаны? По обновлению Длинка - скорее всего его нужно просто перезагрузить. – Ситников Алексей Юрьевич 6 лет 11 месяцев назад 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 / полудуплекс / порты у всех свои возможно, надеялся, что такая умная железка сама знает когда ей пора перезагрузиться. – Волков Андрей 6 лет 11 месяцев назад По поводу TTL. Начальное значение TTL устанавливает тот, кто формирует пакет. Можно установить любое значение в диапазоне от 1 до 255. Далее TTL уменьшается на единицу при прохождении через промежуточный сетевой узел. При очень маленьком начальном значении TTL велика вероятность, что пакет может не дойти до конечного получателя. С наибольшей вероятностью, "бевардовский IP-конвертер" изначально устанавливает TTL = 64, когда формирует ответ на команду пинг.
По поводу отсутствия ответа на команду пинг с ключом -w 5000. Если бы ответы с таким временем ожидания были 100% и при этом в худшие моменты тайм-аут ответа не превышал, например, 1000 мс., то был бы смысл увеличить тайм-ауты в АРМ, как ранее советовал Налетов Константин. Но так как есть неответы, увеличением тайм-аутов в АРМ ситуацию не исправить (можно уменьшить вероятность возникновения, но не устранить.. и не стоит забывать про побочный эффект, что увеличение тайм-аутов ожидания замедляет работу системы). То, что прибор не отвечает на команду пинг, говорит о том, что он и не получает сами запросы. Если такая ситуация возникает с запросами пинг, то она возникает и с запросами от АРМ (соответственно, если нет запроса к прибору, то нет и ответа от прибора). Приборы будут периодически теряться/обнаруживаться, если не устранить причину по которой это происходит (предполагаем, что причина в периодическом широковещательном трафике). – Сигуа Ольга 6 лет 11 месяцев назад По поводу поиска источника широковещательного трафика. Если есть возможность и свободный порт на Dlink, то можно зазеркалировать трафик того Ehernet-порта, к которому подключен один из C2000-Ethernet, связь с приборами которого периодически теряется/восстанавливается. К этому свободному порту подключить ноутбук. На нём установить wireshark ( https://www.wireshark.org/#download ). ПО бесплатное. В wireshark настроить опцию сохранение лога в файл с автоматической генерацией нового файла, например, каждые 10 МБайт. Поставить в опциях удобочитаемое время c датой, временем и миллисекундами (view/time display format). Когда ситуация с потерей в АРМ повторится, посмотреть наличие широковещательного трафика в логах в этот момент времени или несколько раньше. Там же будет указан источник этого трафика (его IP и/или MAC). В более простом варианте можно сделать всё то же самое, но не зеркалируя трафик на свободный порт, а запустив wireshark на любом компьютере в лок.сети (просто может оказаться важным, где именно относительно С2000-Ethernet расположен этот компьютер). В большинстве случае, wireshark-а на каком-либо ПК без зеркалирования достаточно для обнаружения источника трафика (главное, включить логирование в файл, чтобы в онлайн окне просмотра нужная информация не затёрлась другими новыми пакетами).
– Сигуа Ольга 6 лет 11 месяцев назад Ну и в дополнении к ответу Ольги я могу добавить что нужно разбиратся с линком на портах серверов. Это непорядок когда гигапитный порт коммутатора и гигабитный порт сервера подключаются в автомате на сотке.
От себя могу сказать что причина скорее всего кроется в производителе чипа сетевой карты сервера. В моем случае у обоих проблемных ноутбуков был чип от Realtek (RTL), а у работающего от броадкома. Поэтому нужно поставить в серверы сетевухи с чипами напримерт того же д-линка. благо они стоят не таких уж и большох денег. – Ситников Алексей Юрьевич 6 лет 11 месяцев назад пока пробую натравить "акулу" с рабочего компа, оказывается широковещанием занимаются и езернеты:
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 - один из езернетов. Пока тишь да гладь. Забавно, второй день как запустил "акулу" и пропаданий нету, было одно, но в момент "Отметки дат", судя по всему это связано с синхронизацией времени. – Волков Андрей 6 лет 11 месяцев назад Вы д-линки все обновили? Может и в них крылась засада?
– Ситников Алексей Юрьевич 6 лет 11 месяцев назад да, все. Но до того как запустил сниффер пропадания ещё были и один, самый важный длинк не перезагружал, чтобы окончательно версия сменилась. Запустил сниффер и тихо сразу стало) чуть позже перезагрузил последний длинк, естественно получил все потери - от него же сервак жил, но непредсказуемых потерь больше не случалось.
– Волков Андрей 6 лет 11 месяцев назад вроде что-то попалось, правда непонятно откуда оно у нас взялось:
 итак, в момент пропадания в логе появилось огромное количество однотипных пакетов. Просмотрел случайные логи за другое время - протокол MPEG TS больше нигде не появлялся. Адрес 10.115.202.14 это видимо внутренний адрес какого-то абонента у нашего провайдера, а 239.255.43.45 это из IP-TV, адрес Первого канала. Отсюда риторический вопрос - а к нам то оно как попало? Каким-то чудесным образом временами на пару секунд прорывается через наш роутер с маршрутизатора провайдера? В офисе точно смотреть некому - офис пустой, да и если бы был просмотр, то этот протокол появлялся в логах намного чаще. Похоже вопрос с этого форума плавно перетечёт в общение с провайдером)) – Волков Андрей 6 лет 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/ ).. – Сигуа Ольга 6 лет 11 месяцев назад спасибо за помощь)
отправил тот скрин в техподдержку провайдера, уже сказали, что всё готово, но оперативно это никак не проверить - остаётся только ждать. – Волков Андрей 6 лет 11 месяцев назад Наверное, получилось познавательно и содержательно для всех, читающих тему :))). Всем спасибо!
– Сигуа Ольга 6 лет 11 месяцев назад да-да, я хоть понял как интерпретировать показания пинга и слегка разобрался в wireshark, ну и подобновил парк оборудования.
– Волков Андрей 6 лет 11 месяцев назад ну чтож, практически неделя прошла, а потерь больше не было, даже тех, которые в 0:00:00 иногда случались. Видимо от провайдерского оборудования всё и летело, т.к. мои настройки не повлияли.
– Волков Андрей 6 лет 10 месяцев назад Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?) |
|
|
не слишком ли много? При таком пинге (600мс) нормально, не следует сильно заморачиваться на счёт большого значения, ведь это таймаут. То есть, если обмен произойдёт ранее, чем истечёт это время, то ожидание (таймаут) прервётся и обмен продолжится далее по алгоритму. 7 лет назад
Налетов Константин 2021Всё верно. Но есть нюанс. Тайм-аут будет срабатывать полностью при поиске ещё не обнаруженных приборов. Если же прибор добавлен в базу данных Master-устройства (пульта/АРМ), но при этом физически не подключен, то тайм-аут будет выдерживаться не так уж и редко.
– Сигуа Ольга 7 лет назад Ольга, есть ли у Болида какой либо документ (справка и т.п.), разъясняющий в деталях, как используются (применяются) таймауты, паузы (СОМ-портов, С2000-Ethernet и др.) в различных режимах работы аппаратуры? Например о том, что Вы упомянули выше, я не знал. Про настройку параметров RS-485/232 пульта С2000М вообще мало инфы.
– Налетов Константин 7 лет назад Константин, про настройку параметров пульта С2000M и АРМ информации мало по той причине, что при построении системы без использования различных преобразователей (С2000-Ethernet, РПИ и т.п.), изменение этих параметров крайне не рекомендуется. Т.е. параметры уже принимают оптимальные значения. Про сами тайм-ауты в деталях не рассказывается потому, что они являются следствием программной реализации протоколов обменов. Протоколы являются закрытыми. Программная реализация отличается в различных Master-устройствах, а иногда и в различных версиях одного и того же Master-устройства.
Рекомендации по настройке тайм-аутов приведены в документации на соответствующие преобразователи (С2000-Ethernet, РПИ и т.п.). В частности, в С2000-Ethernet приведены расчётные формулы, в которых учитывается время пинг. Но если рассуждать "в общем", словосочетание "тайм-аут ответа" предполагает максимальное время ожидания ответа на что-либо и он будет срабатывать по максимуму в случаях, когда ответ почему-то не пришёл (например, если запрос осуществлялся к тому, кого нет в интерфейсе, или если прибор присутствует в интерфейсе, но почему-то не сформировал ответ.. такого.. конечно, быть не должно.. это нештатная ситуация). С уверенностью можно сказать, что даже без открытия особенностей закрытых протоколов и их реализации в различных Master-устройствах, максимальное замедление от увеличенных тайм-аутов будет ощущаться в случае отсутствия в RS приборов, включённых в базу данных, либо при наличии проблем в RS-интерфейсе. – Сигуа Ольга 6 лет 11 месяцев назад Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?) |
|
|
Добрый день , подскажите как избавиться от потери и подмены устройств , у нас установлены 5 РПИ , где 1 мастер и 2 ретранслятора , по инструкции болида была произведена настройка 3 года 1 месяц назад
Воронин Дмитрий Сергеевич 18найдите источник помех или установите устойчивую связь.
– Ситников Алексей Юрьевич 3 года 1 месяц назад На диапазоне 2.4? Там источников столько, и все двигаются. Тапком не прихлопнуть...
– Леготин В В 3 года 1 месяц назад Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?) |
12141 раз
7 лет 6 месяцев назад
По каждому вопросу/ответу можно добавлять комментарии. Комментарии предназначены для уточнения вопроса/ответа.
добавить комментарий