Элтекс

Здравствуйте!
Накопился ряд вопросов по шлюзу SMG1016M, которые хотелось бы для себя прояснить.
Общение по электронной почте, к сожалению приносит не тот результат который ожидал.
1) Декабрь-Январь. Шлюз был настроен в следующей конфигурации:
GE0-не тегированный порт
GE1- VLAN30
GE2- VLAN1100
Таблица маршрутиации была настроена так как надо. Трафик ходил совсем не так, как должен был. По каким то причинам не тегированный трафик ходил через порт GE2, соответственно коммутатор этот трафик дропал. Потери пакетов достигали 70%. Пробовали настроить все на GE2, эксперимент удачей не окончился. Общение по телефону, подключение через Team Viewer результата не принесли. Самостоятельно было определено, что если все настроить на порту GE0, проблема перестает волновать (повторюсь, при настройке на GE2 работоспособность шлюза была нарушена). Причины возникновения и решение на уровне ПО шлюза не уверен, что определено. Жду ответа, решена ли проблема в последней прошивке или нет. Все логи и полная информация есть у ваших специалистов
2) Февраль. По каким то причинам, при вызова с одного сип интерфейса_1 (172.19.252.18, абонентское окончание внутренней сети) через шлюз (172.19.252.191-внутренний адрес шлюза), по какой то причине RTP трафик шлюз начинает отдавать с другого интерфейса_2 (91.245.Х.Х), по логам непонятно почему, видно, что шлюз почему то пытается отдать голосовой трафик через интерфейс_2(внешний контрагент, с которым у нас стык по сипу). Причина возникновения проблемы, наличие решения на уровне ПО неизвестно.
3) Февраль. По совершенно непонятной причине, шлюз генерит UDP трафик на один сип интерфейс, после того, как через этот интерфейс, вызовы перестали маршрутизироваться (2014/02/15 20:13 последний звонок). Забивая им (клиенту, с которым у нас использовался стык по сип протоколу ) 5мбитный канал. Причины возникновения трафика непонятны. Все логи отправлены 17 февраля 2014. Пробовал в настройках шлюза поменять IP адрес на интерфейсе, результата не дало. Шлюз все так же ддосил адрес, который уже не был прописан нигде в настройках (!). Пришлось ограничить пропуск трафика на уровне коммутатора, благо стык с этим партнером (сип интерфейсом) временно перестал быть необходимым. (в настоящий момент, SMG1016M, все так же отправляет какие то пакеты на адрес, который отсутствует в настройках веб интерфейса).

Данные по шлюзу:
Версия ПО V.2.14.03.719. L. M. Build: Jan 21 2014 15:03:16
Версия SIP-адаптера 2.14.2.21
Время в работе 23d 01hour 17min 07sec

Т.к. как на вопросы по данным проблемам не было дано никакого фактического ответа, т.е. не было однозначно сказано, что эти проблемы решены в новой прошивке, задаю этот вопрос тут.
В результате ошибки описанной в п.1 (в ПО шлюза) получили кучу негатива от клиентов, лишении 100% премии всего IT отдела и пару бессонных ночей. Сейчас мне рекомендуют обновить прошивку, "попробуйте новую прошивку". Я не хочу обновлять прошивку, только ради того, чтоб ее обновить.
Прошу рассмотреть возможность написания некого "whats new" по новым версиям и очень жду информации по описанным проблемам.

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

AlexeyMish писал(а):Здравствуйте!
Общение по электронной почте, к сожалению приносит не тот результат который ожидал.

Я вас, возможно, удивлю, но на форуме работают те же самые инженеры поддержки, что и на телефоне с e-mail.
Конкретно ваша проблема в работе, в том числе и у разработчиков.
К сожалению вопрос решается не так быстро, как хотелось бы.

AlexeyMish писал(а):Т.к. как на вопросы по данным проблемам не было дано никакого фактического ответа, т.е. не было однозначно сказано, что эти проблемы решены в новой прошивке, задаю этот вопрос тут.
Сейчас мне рекомендуют обновить прошивку, "попробуйте новую прошивку". Я не хочу обновлять прошивку, только ради того, чтоб ее обновить.
Прошу рассмотреть возможность написания некого "whats new" по новым версиям и очень жду информации по описанным проблемам.

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

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

Bokrenok писал(а):Я вас, возможно, удивлю, но на форуме работают те же самые инженеры поддержки, что и на телефоне с e-mail.
Конкретно ваша проблема в работе, в том числе и у разработчиков.
К сожалению вопрос решается не так быстро, как хотелось бы.

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

Bokrenok писал(а):Проанализировав поведение 14-ой версии с вашими настройками, могу сказать, что в этой версии есть недостаток: медленная скорость применения сетевых настроек и сетевых маршрутов.
Поэтому было озвучено предложение попробовать свежую 15-ю версию.
В этой версии были существенно переработаны сетевые настройки и оптимизировано их применение, что может заметно улучшить работу с сетевыми интерфейсами.

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

По п.1, скажу откровенно, я боюсь. Сейчас у меня все более менее работает, в единственно возможном варианте, из тех что сочинились. Есть опасение, что после обновления, этот единственно возможный вариант, так же станет неработоспособным. Информации о том, что в новой версии этот вопрос решен не было. Трогать то, что с таким трудом довел до работоспособного состояния страшно.
По п.2 и п.3 установлена причина возникновения проблемы?
Я почти уверен, что после рестарта шлюза проблема на время исчезнет. Но без выяснения причин, решение будет временное. Это одна из причин, по которой не хочу обновляться, т.к. после обновление прошивки, будет рестарт устройства и как следствие, косметическое решение вопроса.
Хотя, если я правильно понял, других вариантов кроме как обновляться у меня нет. Проблемы выявленные на прошивке версией ниже, автоматически "сгорают" после выхода нового ПО?

AlexeyMish писал(а):По п.1, скажу откровенно, я боюсь. Сейчас у меня все более менее работает, в единственно возможном варианте, из тех что сочинились. Есть опасение, что после обновления, этот единственно возможный вариант, так же станет неработоспособным. Информации о том, что в новой версии этот вопрос решен не было. Трогать то, что с таким трудом довел до работоспособного состояния страшно.

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

AlexeyMish писал(а):По п.2 и п.3 установлена причина возникновения проблемы?
Я почти уверен, что после рестарта шлюза проблема на время исчезнет. Но без выяснения причин, решение будет временное. Это одна из причин, по которой не хочу обновляться, т.к. после обновление прошивки, будет рестарт устройства и как следствие, косметическое решение вопроса.
Хотя, если я правильно понял, других вариантов кроме как обновляться у меня нет. Проблемы выявленные на прошивке версией ниже, автоматически "сгорают" после выхода нового ПО?

По п.2 пока ничего не могу сказать, изучаю вопрос.
По п.3 есть предположение, что зависло несколько вызовов (не прошёл отбой по сигнализации).
У вас настроен контроль сессии какой-нибудь?

Доступные варианты контроля сессий:
- наличие втречного RTP потока (при пропадании потока и отсутствии в течение определенного времени - разрыв соединения)
- RTCP (при отсутствии RTCP от встречной стороны в течение определенного времени - разрыв соединения)
- таймер SIP-сессии RFC4028

AlexeyMish писал(а):Хотя, если я правильно понял, других вариантов кроме как обновляться у меня нет. Проблемы выявленные на прошивке версией ниже, автоматически "сгорают" после выхода нового ПО?

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

Bokrenok писал(а):

AlexeyMish писал(а):Хотя, если я правильно понял, других вариантов кроме как обновляться у меня нет. Проблемы выявленные на прошивке версией ниже, автоматически "сгорают" после выхода нового ПО?

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

Ок. Я все понимаю, и буду обновляться. Подготовлюсь, переведу все потоки на один шлюз, на втором поэкспериментирую. Возможно был излишне эмоционален, если так, прошу прощения.
По третьей проблеме, вы абсолютно правы, не был настроен контроль сессий и была толпа зависших каналов. После перезапуска ПО, вопрос решился. Наверное буду не оригинален, сказав, что перезапуск всего ПО излишне суровый способ решения вопроса. Может быть можно каким то образом прерывать соединения поканально? ЕМНИП, по SNMP можно получать данные соединений, включая продолжительность голосовой сессии каждого канала? По большому счету надо всего лишь сгенерить пакет "Bye" в нужный канал, если я правильно понимаю.
По поводу второй проблемы (которую вы изучаете), после рестарта ПО - вопрос остался актуальным (могу приложить свежий дамп). Если есть вероятность, что засада в сетевой части, готов отложить на некоторый срок рассмотрения вопроса, до перепрошивки шлюза.

AlexeyMish писал(а):Может быть можно каким то образом прерывать соединения поканально?

Не так давно мы тоже задумались над этим вопросом.
Сделаем механизм для разъединения подвисших разговоров.

AlexeyMish писал(а):По поводу второй проблемы (которую вы изучаете), после рестарта ПО - вопрос остался актуальным (могу приложить свежий дамп). Если есть вероятность, что засада в сетевой части, готов отложить на некоторый срок рассмотрения вопроса, до перепрошивки шлюза.

По п.2 проблему вчера вечером нашли. Проблема не в сетевой части.

По п.1 пока нет ясности изучаем поведение.

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

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

PS Проблема повторилась. Связался с Алексеем, отправил запрошенные логи.
PPS Встречная сторона признала, что является источником проблемы. Разбираются со своей стороны.