SUrov_IBM

Jffulcrum, здравствуйте. Большое спасибо за ответ! Благодаря Вам и форуму, буду спать спокойно. 😉

Уважаемые знатоки, приветствую Вас. Прошу прощения за глупый вопрос, по уму нужно сделать тестовый стенд и не приставая ни к кому самому проверить, но интересует Ваше мнение, на то он и форум - возможно, кто-то знает верный ответ. Вопрос: имеется VM с CHR 7.16.1, после установки лицензия "Free" (с ограничением интерфейсов в 1 МБ/Сек) обновлена до "Trial P-Unlimited" (сроком 60 дней). Собственно после истечения "deadline-at" и отсутствием связи с лицензирующим сервером, каким образом себя поведёт CHR, условно потеряет возможность обновления прошивки или вернётся к лицензия "Free" (с ограничением интерфейсов в 1 МБ/Сек)? Дело не в жлобстве с экономией на лицензии, просто VM с CHR находится в изолированной, без доступа в публичный Интернет схеме, как с следствие серверам лицензирования. В этом случае разницы между "Trial" или приобретённой лицензией по-моему особо нет, ведь для проверки лицензии периодически формируется запрос к серверам лицензирования? Было замечено, что CHR 6 версии при недоступности серверов лицензирования и истечении "deadline-at" не изменил состояние лицензии и не ограничил интерфейсы в 1 МБ/Сек, возможно в 7 версии что-то принципиально изменилось. Заранее благодарю за ответ, если кто-то столкнулся с подобным вопросом. В любом случае попробую сделать тестовый стенд, чтобы совершить "прыжок в будущее". 😉

Saab95, здравствуйте. Дело в том, что оригинатором (создателем письма) рассылки "Расчетных отчетов" является непосредственно платформа "1С Предприятие". Поэтому при взаимодействии с внешним рассыльным потребуется какой-то relay механизм. CRP / API в данном случае никто городить не будет, поэтому остаётся SMTP. В любом случае спасибо за советы. Рискну осуществить рассылку более привычными / понятными в настройке способами, например MTA relay на VPS. Благодарю всех, кто откликнулся! 🙂

MMM, здравствуйте. Благодарен за консультацию в каком направлении смотреть. >>Я предположил, что цель именно на своих серверах делать рассылки. Да, рассылка предполагается с MTA компании, для отправки отчётов сотрудникам компании (на публичные адреса электронной почты). >>А так то да. Извиняюсь за глупый вопрос, возможно Вы сможете порекомендовать компанию предоставляющую услугу рассылки, в моём случае ретрансляции почтовых сообщений с внутреннего MTA на публичные адреса? Jffulcrum, здравствуйте. Благодарю Вас за расширенный ответ!

Уважаемые знатоки, не обойтись без Вашего мнения. Потребовалось организовать рассылку "Расчетных отчетов" для сотрудников компании на публичные адреса электронной почты. В общем-то технических проблем нет. Возникли сомнения, что при рассылке приблизительно 2000 писем, отправляющий MTA может быть определён как "SPAM рассыльный", с последующий блокировкой в "Spamhaus" и т.п. Подскажите - помимо ключевых соответствий в DNS: "A" ="PTR" ="HELO/EHLO ", полюс наличие записей SPF, DMARC, DKIM. Какие неочевидные параметры возможно должен иметь отправляющий MTA, чтобы не опасться быть определён как "SPAM рассыльный"? P.S. Прошу сильно "не кидаться тапками", с рассылкой большого количества корреспонденции дела не имел, возможно мой вопрос в принципе глупый.

Den4ikArgv, здравствуйте. Для линейки кошек 2800 чаще всего использую c2800nm-adventerprisek9-mz.151-4.M1. Ссылка для скачивания - https://cloud.mail.ru/public/krXW/aQ5cpoi7S

Andrei, здравствуйте. Всё же предположу, что проблема кроется в UTP кабеле. Сталкивался с некачественными новыми кабелями (из магазина), которые не обеспечивали работу AP по PoE 802.3at на расстоянии более 50 метров, правда проблемы в виде перезагрузки наблюдались практически сразу. Так же сталкивался, что на оборудовании Infinet Wireless работающим по Passive PoE, некачественные кабели напитывали воду атмосферных осадков, что приводило к замыканию в районе RG45 jack cо стороны инжектора (вода стекала "вниз") и перезагрузке радио-модуля. Для теста, я бы переместил инжектор максимально близко к Ubiquiti, если радио-модуль перестанет перезагружаться, это даст возможность не теряя показаний посмотреть CRC счётчик на его порту.

Motto, здравствуйте. Из приведённой короткой отладки неудачного вызова "в глаза бросается" - 0x84A2 "No circuit/channel available". Т.е. по логике не хватает свободного "B канала" в потоке, либо ресурсов DSP самой CISCO (про ресурс DSP могу и ошибаться, возможно там другое сообщение), НО в приведённой отладке удачного вызова занимается всё тот же "Channel 31"... Хм, тем более Вы говорите, что видите на "АТС 2" попытку транзита неудачного вызова в сторону оператора? Попробую тыкнув пальцем в небо предположить, что "АТС 2" в отличии от исходящих вызовов собственных внутренних линий, принудительно не закрывает групповым номером (495) XXX-XX-XX транзитные вызовы направленные в оператора. Т.е. при исходящем вызове с "АТС 1" до оператора пролезает некорректный номер "А (?) /ISDN Type" (внутренней линии или переадресации с "АТС 1"), хотя судя по отладке в случае успешного и неуспешного вызовов "Calling num" одинаковые, оператор отбивает вызов не удовлетворившись полученным АОН или ISDN Type, а "АТС 2" получив отбой от оператора закрывает "B канал" в сторону CISCO, хотя это и ненормальное поведение без причины отбоя в сигнализации. Самое интересное в процессе неудачного вызова осталось за кадром - "ISDN Se0/0/1:15 Q931: call_disc: PI received in disconnect; Postpone sending RELEASE for callid 0x...?". :) P.S. В изложенной схеме не очевидно соединение "АТС 1" и CISCO, если это VoIP с сигнализацией SIP / H.323, можно попробовать снять трассировку удачного и неудачного вызовов сниффером Wireshark. Но сначала хотелось бы увидеть полный код отбоя "call_disc: PI received in disconnect; Postpone sending RELEASE for callid 0x" обрезанный при копировании текста отладки.

Fox_m, приветствую! Если Вы не используете сервисы требующие поддержки IPv6, можно полностью исключить работу протокола со стороны клиентской ОС. Понимаю, в меня "полетят тапки" за предложение подобной "кастрации". В своей локальной среде, я бы именно так поступил, чтобы не ловить грабли IPv6 DNS. ОС Windows 10 (и выше): В ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters Создать DWORD (32-bit) параметр DisabledComponents Шестнадцатеричное значение ff После перезагрузить ОС. P.S. DisabledComponents можно распространять через групповую политику Active Directory, если потребуется.

Уважаемые форумчане, приветствую Вас. Если встретиться специалист по Panasonic, возможно подскажет. Суть: АТС KX-TDE600 "из коробки" поддерживает возможность импульсного набора для аналоговых extension (подключенных к ней ТА). Самое интересное в следующем - после набора номера и установления соединения (точно не знаю в пред-ответной или ответной стадии) АТС KX-TDE600 конвертировала полученный с аналогового ТА импульс в тон DTMF. Что позволяло набрать добавочный номер в DISA / IVR вызываемой (Б) стороны. Знаю точно, поскольку используемый ТА имел дисковый номеронабиратель и промежуточных конверторов в линии до АТС не использовалось. И собственно вопрос - как называлась данная волшебная функция, придуманная японским умом? Чтобы можно было понять, в каких моделях мини-АТС Panasonic она присутствовала. :)

Merk055, здравствуйте. При упоминании PON, почему-то сразу представляется PPPoE. Если используется PPPoE, сниженное MTU и соответственно MSS. Форумчанин Jffulcrum очень правильно это заметил! Попробуйте зарезать MSS "предельно низко" на "внешних" интерфейсах смотрящих в сторону двух операторов. Например таким образом: /ip firewall mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=no tcp-flags=syn protocol=tcp out-interface=*название_WAN интерфейса_1го_оператора* tcp-mss=1300-65535 log=no /ip firewall mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=no tcp-flags=syn protocol=tcp in-interface=*название_WAN интерфейса_1го_оператора* tcp-mss=1300-65535 log=no /ip firewall mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=no tcp-flags=syn protocol=tcp out-interface=*название_WAN интерфейса_2го_оператора* tcp-mss=1300-65535 log=no /ip firewall mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=no tcp-flags=syn protocol=tcp in-interface=*название_WAN интерфейса_2го_оператора* tcp-mss=1300-65535 log=no

AndrK189100, здравствуйте. Извиняюсь, что отвечаю не по теме QoS. Хотел уточнить, если со стороны сервера используется MS Windows 2022/2019/2016 Server, для работы RDP возможно использование UDP соединения (порт 3389) - RDP версия 8.1. В TCP соединении передаются клавиатура и мышь клиента, в нескольких UDP соединениях передаются медиа-данные от сервера. Опыта работы с Remmina у меня нет, поэтому не могу сказать, поддерживает данный RDP клиент UDP соединение? Если поддержка есть, то возможно канал занимается UDP соединениями поступающими от сервера к клиенту? Можно попробовать отключить поддержку UDP соединения на стороне сервера. Правда, это ухудшит получаемое с сервера качество изображения.

AlwaysWannNymon, здравствуйте. Я правильно понимаю Вашу схему: [АТС (1) IP 192.168.35.35] <=> [MIKROTIK (1)] <={VPN}=> [MIKROTIK (2)] <IP 172.28.63.62/30 ={VoIP VLAN}= IP 172.28.63.62/30> [IP маршрутизатор] <=> [АТС (2) IP 172.28.61.10] ? Важное замечание с точки зрения телефонии, а именно - каким способом АТС (2) IP 172.28.61.10 сконфигурирована на взаимодействие с АТС (1) IP 192.168.35.35: - 1 вариант: АТС (2) IP 172.28.61.10 ожидает "на себе" регистрацию SIP User Agent (IP телефон / IP АТС / Soft-фон) с использованием SIP REGISTER (регистрация по - номер, логин и пароль), но с явной "привязкой" к IP адресу 172.28.63.62? Данный способ применяется если между SIP UA и IP АТС предполагается NAT. - 2 вариант: АТС (2) IP 172.28.61.10 ожидает, что SIP User Agent SIP работает "без регистрации" (не посылая SIP REGISTER) и фактически располагается на IP адресе 172.28.63.62? Условно если бы IP телефон или IP АТС включались в VoIP VLAN без маршрутизатора. Если используется 1 вариант, на MIKROTIK (2) Вам необходимо настроить Source NAT (src-nat) для сети 192.168.35.0/xx (возможно для одного IP адреса 192.168.35.35, но некоторые IP АТС используют два и более IP адресов подсети (например для DSP процессоров)). При этом должна быть "полная" IP связанность [АТС (1) IP 192.168.35.35] и [MIKROTIK (2)] через VPN. /ip firewall nat add action=src-nat chain=srcnat src-address=192.168.35.0/24 to-addresses=172.28.63.62 Чтобы пакеты посылаемые [АТС (1) IP 192.168.35.35] пройдя VPN "закрывались" IP адресом 172.28.63.62 src-nat NAT трансляцией в направлении IP адреса 172.28.61.10 на [MIKROTIK (2)]. Так же, на [MIKROTIK (1)] и [MIKROTIK (2)] обязательно выключайте SIP ALG (/ip firewall service-port set sip disabled=yes), ибо этот помощник "сам себе на уме". При использовании 2 варианта (UA SIP работает "без регистрации") и данной схеме, всё будет гораздо неприятней, с применением "дополнительных костылей" в схеме. Примечание: Посылаемые в сторону АТС (2) IP 172.28.61.10 SIP запросы, можно "смотреть" внешним анализатором трафика на [MIKROTIK (2)]. Например Wireshark'ом, чтобы убедиться в корректности запросов и правильной настройки src-nat.

Qlement, здравствуйте. Как выше сказали коллеги по цеху - это платы расширения для АТС Nortel CS1000 (Meridian). Более точно обозначение плат указано на лицевой стороне (мордочке). АТС использовалась в крупных ведомственных организациях, бизнес центрах с единой телефонной структурой и в маленьком варианте, в манерных офисах. К АТС подключаются Digital телефонные аппараты производства Nortel (поддерживающие дополнительные услуги АОН / перевод / перехват / конференции) и обычные аналоговые (с минимальным набором функций). Всё это ограничено длинной прямых аналоговых линий от АТС до телефонов. Правда существовали и выносные модули, подключаемые по потоку (для расширения). К сожалению, как сказали выше, это уже прошедшее время - станция не масштабируется в отличии от IP телефонии и не поддерживает современные дополнительные услуги. Плюс требует определённых специфических знаний по настройки даже обычных функций, не каждый специалист бы взялся. P.S. Если смотреть с точки зрения продажи этого добра, самый простой путь "Авито", но возможно будет продаваться вечно и за копейки, к сожалению такая правда для этого оборудования.

Jffulcrum, здравствуйте. Спасибо большое, что ткнули носом! ;) >>Дык, откуда у него POE? - Cisco Catalyst 3750 Series Switches Data Sheet - Cisco Естественно - "Смотрю в книгу, вижу фигу"! Т.е. смотрю на описание WS-C3750-24PS-S и ломаю себе мозг...