Axen

@McSea спасибо, натолкнул на нужную мысль, посмотрел более внимательнее на политику в филиале, и нашёл ошибку в ней. Всем спасибо!

Благодарю, буду смотреть чего не сделал.

Не могу дать ума ни как, как это может помочь в моём случае? На клиенте, маршрут до сетей филиалов есть. При трассировке, первый хоп 192.168.10.1 (R01), дальше обрывается. То есть, делаю вывод, пакеты доходят до R01, а дальше маршрутизатор не понимает что с ними делать.

1. IP статический только на главном офисе (R01) 2. Часть остальных офисов находятся за NAT провайдера, NAT внутренней сети торгового центра, или просто отсутствует возможность взять статический IP Спасибо, пошёл читать, думать, пробовать. P.S. А в целом, согласен с Вами, проще использовать ipsec с каким либо интерфейсом, что бы использовать классическую маршрутизацию. И начинаю склоняться к использованию проверенного варианта L2TP/IPsec.

Здравствуйте, начал работать с ipsec (чистый IKEv2 на сертификатах), успешно сделал связь между главным офисом и филиалами. Теперь появилась задача что бы можно было подключиться из вне к главному офису, и подключиться к устройствам как и в главном офисе, так и в филиалах. Первая часть задачи выполнена успешно, подключаемся из вне к главному офисе, и спокойно попадаем на устройства внутри него. А дальше проблема, не удаётся попасть на другие филиалы. Схема: То есть клиент, подключившись с помощью IKEv2 к R01, должен попасть на устройства, находящиеся в сетях за R02-R04, связанных с R01 так же с помощью IKEv2. В сеть находящуюся за R01 клиент попадает. Клиенту выдаётся адрес из подсети 192.168.99.0/24. Из оборудования используются Mikrotik RB941-2nD. Теперь сам вопрос, такое возможно вообще реализовать на чистом ipsec, без L2TP, GRE и так далее?

Понял, спасибо за информацию. Будет хотя бы направление, в какую сторону мыслить!

Да проблема как раз таки уже, и на полностью исправном коммутаторе :( Вот.

Ни у кого нет, ни каких идей?

И так, результаты тестов. Выключил сгоревшие порты на DG S-1210-52MP/ME, и запретил на них POE: Тестировать будем на 9-м порту DGS-1210-52MP/ME. Пустой порт: При подключении Cisco 7942G: После того, как Cisco 7942G окончательно включится: Подключаем Cisco 8941. Ни какой реакции, ни чего не менялось, как будто ни чего и не втыкали: Переходим к Cisco Catalyst 2960-48PST-S. У него часть портов, то же не подают питание PoE, но в тех портах где оно работает, всё включается исправно. Подключили 7942G: Чуть позже коммутатор понимает кто в него вставлен: И после того как телефон полностью включился, потребление немного падает: Подключаем 8941: И чуть позже, когда телефон включился окончательно:

Хорошо, завтра сделаем.

Добрый день. На форуме D-Link да же ни кто не ответил в теме, попробую здесь счастья. Проблема с питанием по PoE, телефона Cisco 8941. В то же время, телефоны Cisco 7942G и 9971, точка доступа Cisco AIR-CAP3602I-R-K9, работают без проблем. Коммутатор: Device Type : DGS-1210-52MP/ME MAC Address : 10-62-EB-49-67-D2 System Boot Version : 1.00.023 System Firmware Version : 6.14.B039 System Hardware Version : A1 System Serial Number : S37D1GC000027 Текущее состояние PoE на коммутаторе: Power Limit : 370.0 Power Consumption : 45.0 Power Remained : 325.0 Power Disconnection Method : Deny low priority port Detection Legacy PD : Enabled Из особенностей коммутатора, не давно выгорели 5 и 6-й порты. 6-й порт полностью не работает, ни данные, ни PoE. В 5-м не передаются данные, и не работает PoE для всех телефонов, кроме проблемного. То есть если в 5-й воткнуть любое устройство кроме проблемного, то оно не включится, а если воткнуть то с которым у нас сейчас проблема, оно включится (но данные не будут передаваться). Рассматривать пример, будем только с полностью рабочими портами. Для Cisco 7942G, в datasheet прописано следующее: "Supports IEEE 802.3af PoE (Class 2)". На самом телефоне 48V 0.38A Для Cisco 9971, в datasheet прописано следующее: "IEEE Power over Ethernet 802.3af and 802.3at supported, class 4. The 9971 is compatible with both class 3 and class 4 IEEE PoE switch blades and...". На самом телефоне, к сожалению, нет данных по питанию. Для Cisco AIR-CAP3602I-R-K9, в datasheet прописано следующее, PoE+ 802.3at, PoE 802.3af, от 15,4Вт до 22Вт в зависимости от режима работы, наличие модулей. На самой точки доступа написано 48V 350mA Теперь проблемный телефон, Cisco 8941. В datasheet написано "The phones can receive power from IEEE 802.3af-compliant blades. The phone is PoE Class 1.". На самом телефоне 48V 0.375A. По мощности, телефон один из самых менее требовательных. То есть скорее всего, какие то настройки, а не не хватка питания. В логи, Dlink ни чего не пишет. Если переключить на передней панели индикацию портов с Link на PoE, то тот порт, в который вставили 8941, начинает светится оранжевым - "PoE Failure". Какие ещё действия производили: 1. Пробовали все порты на коммутаторе, кроме не рабочих, 5 и 6, на обоих экземплярах данной модели телефона (один из экземпляров новый, из коробки). 2. Пробовали оба экземпляра Cisco 8941 в другом коммутаторе, Cisco Catalyst 2960-48PST-S, работают успешно. 3. Включали/выключали "Detection Legacy PD" 4. Пробовали выставлять разные классы PoE. 5. Включали телефоны (оба экземпляра), в такой же коммутатор DGS-1210-52MP/ME, но со всеми рабочими портами. Телефоны не включаются. Идей просто нет уже, "напните" хоть в каком ни будь направлении.

Да в том то и дело, DES-3200-18 прошит последней прошивкой, и ради эксперимента пробовали чуть постарше, то есть 1.91.B004 - 1.91.B007. В конечном итоге хорошенько подумали, и решили отказаться от STP, а использовать только loopdetect.

Чувствую хорошенько подумаем, и наверное откажемся от STP, по крайней мере на D-Link. А будем использовать просто Loopdetect... А не подскажите, чем можно заменить D-Link, по схожей цене, но что бы не было такого количества "волшебства" в прошивках? Да и синтаксис CLI меняющийся от версии к версии прошивки и между коммутаторами, честно говоря уже начал надоедать...

@passerДля 1210 7.03.B030. Для DES-3200-18 1.91.B004, могу ошибаться с последней цифрой. @AlKov На самом деле, изначально случилось то, что по некоторым причинам, соединили две "ветки" от ядра между собой, в нескольких местах и через не управляемые коммутаторы, мыльницы и т.п. (постарались пользователи). Можете не говорить что это какой то пи.., сами знаем. Сейчас когда всё по убирали, восстановили работу, успокоились, поняли, что можно с умом использовать "кольцо", решили проработать вопрос. Но по факту да, если не делать кольца, то можно обойтись банальным Loopdetect. По зоопарку, сами себе не завидуем, "наследие" как говорится. @[anp/hsw] Не думали в этом направлении, спасибо за идею. Сегодня попробовали поменять местами последний в цепочке 1210 и 3200, получили DGS-1210-52-->DES-3200-18-->DGS-1210-52. И, в итоге 1210 перед 3200, заблокировал порт... Поняли что не в конфигурации дело. Решил эксперимента ради, загрузить 3200-18 с очень старой прошивки, 1.28.009. И не поверите, заработало. Дело в том, что у нас DES-3200-18 ревизии B1, старенький очень. @passer Спасибо за совет, по поводу PVID, будем пробовать.

Cisco, Dlink, WiTek вендоры сетевого оборудования. И скоро чувствую будет ещё Eltex. Прошивки самые последние установлены.

Имеется следующая топология: Cisco Catalyst 4503E (Root) ---> Cisco Catalyst 2960-48PST-S ---> DGS-1210-52MP/ME ---> DES-3200-52 -X-> DES-3200-18 Немного предыстории. Изначально, никакого STP настроено не было, за исключением оборудования Cisco. Затем, в следствии ремонта, возникли петли, которые долго разгребали, тут же вспомнили про Loopdetect, STP и так далее. В связи с мультивендорной сетью, было принято использовать MSTP. Cisco Catalyst 4503E является ядром сети. От него идёт несколько веток, решили настраивать постепенно, по одной ветке. Проблема возникла сразу же на первой ветке. И всё в принципе настраивалось прекрасно, пока не дошла очередь до DES-3200-18. После настройки и включения, он просто перестал быть доступным, и всё ПК что были в него подключены, аналогично потеряли доступ до сети. В ходе диагностики, было выявлено, что на DES-3200-52, порт смотрящий в сторону DES-3200-18 state discarding role designated. На самом же 3200-18 порт forwarding. Решили не мучать пользователей, отключили STP на DES-3200-18, и собрали следующую схему-стенд, в DGS-1210-52MP/ME (боевой коммутатор) воткнули последовательно два DGS-1210-52/ME, и затем такой же DES-3200-18, настроили аналогичным образом, и такая же ситуация что и в прошлый раз. Порт в discarding. Cisco Catalyst 4503E (Root) ---> Cisco Catalyst 2960-48PST-S ---> DGS-1210-52MP/ME ---> DGS-1210-52/ME(стендовый) ---> DGS-1210-52/ME(стендовый) -X-> DES-3200-18(стендовый) Заметили следующую особенность, если взять, и последний DGS-1210-52/ME отключить от его соседа, то есть оставить соединённые между собой только два коммутатора 1210-52 и 3200-18, то порт на 1210-52 тут же переходит в состояние forwarding. Думал, что может где-то ошибся с конфигурацией, ещё что-то. Пересмотрел всё на много, раз, тайминги одинаковы, наименование конфигураций одинаково, все vlan в одной instance – 0, во всех коммутаторах, которые работают – root один, Designated Root Bridge – верные (то есть топология дерева соответствует задуманной). Части конфигурации касающиеся STP, Loopdetect и BPDU Guard. DGS-1210-52/ME: DES-3200-18:

Спасибо за ответ. Примерно то же самое и поддержка ответила)

Думал что может есть какие то "обходные пути"... Спасибо, спрошу у техподдержки.

Подскажите пожалуйста, по записи с внешнего микрофона, подключенного напрямую к "AUDIO IN" видеорегистратора. Имеется видеорегистратор DS-H108U, в нём есть 4-е аудиовхода, и успешно подключено два внешних активных микрофона. Имеется видеорегистратор DS-H208Q, в нём только один аудио вход, и к сожалению, никак не получается сделать так, чтоб записывался звук. Так же есть DS-N204P(B), который ещё не запустили, но у него тоже один аудио вход, и хотелось бы сразу узнать, можно ли на нём включить запись звука с внешнего микрофона подключенного к аудио входу регистратора?) Если на DS-H208Q и DS-N204P(B), нельзя записать звук с внешнего микрофона, подключённого непосредственно к регистратора, то не подскажите, какие IP регистраторы (не важно какого производителя) поддерживают эту функцию, и поддерживают ли вообще IP регистраторы её или она доступна только на аналоговых регистраторах? Если можно, подскажите какие конкретно модели поддерживают эту функцию.

Это все было закуплено давным давно. То что как решается, это понятно) И то что всё можно решить, то же понятно. Вопрос в том, что в случае серьёзной проблемы, официальной поддержки, ни кто не даст. Я вот с умершей нодой UCCX до сих пор не разобрался. Поставил на паузу, так как чисто этой проблемой занимался неделю. А что если откинется CUCM? В то же время с астериском у меня ни когда такой проблемы не было. Почти все проблемы, да же крупные, решались за один-два дня. Местами логика работы того же CUBE поражает. Мне надо маршрутизировать исходящий, на основе того, какой внутренний. Как я в итоге понял, из того что мне объяснили коллеги, мне надо в CUCM добавить префикс, и в CUBE с помощью него смаршрутизировать, и затем убрать этот префикс. А что если у меня 50, 100 внешних sip соединений? P.S. прошу критики)

Ну то же верно) Убираем это из минусов. А что ни будь по остальному, можете прокомментировать? Есть смысл "насилования" и данного продукта, и себя? Ибо обновляться оно ни когда не будет, а устаревать будет всё время. Может стоит раньше озадачиться о переходе на другой продукт.

Данная тема, и Ваш пост толкнул всё таки задать один вопрос, который мучает меня давно. "Досталось" ("лучше бы не доставалось") в наследство Cisco CUBE (2921), CUCM 9.12, UCCX 9.0, Unity Connection, Cisco Unified CM IM 9.1.1. Лицензии - 270 устройств. Телефоны 7942, 8941, 9971. Задачи перед телефонией стоят простые: 1. Звонки внутри организации 2. Звонки наружу 3. Не сложные голосовые меню и автосекретарь 4. Запись разговоров 5. Может быть конференции (не видео) И вот после возникновении ряда задач, а так же падения одной из нод UCCX (publisher), начал крайне активно свербить вопрос: "А не похоронить ли всё это хозяйство и не поднять старый добрый Asterisk?!" Чуть подробнее, почему начал свербить: -старый продукт, который более не будет обновляться, закрываться уязвимости и на который я не могу найти мануалов (может плохо конечно искал, поправьте если не прав), и при всём желании, техподдержки не будет; -с вероятностью в 95% утеряны все документы, которые могут потребоваться при переустанови всего этого добра, как на пример с "побитой нодой" UCCX, коллеги на другом форме подсказали, что нужно диагностировать CVD, который толком не задокументирован, и нормально дебажить его умеет тех.поддержка, в итоге до сих пор воюю с переустановкой. Хорошо если там лицензия нормально перенесётся с secondary ноды; -ни каких денег на переход на более новый продукт, не будут выделены ни когда, с вероятность в 146%; -прекрасно понимаю, что данный "монстр" способен на гигантские подвиги, но когда его функционалом не будут пользоваться и на 30%... смысл? -маршрутизация звонков через разных провайдеров, опять же по общению с коллегами, понял что надо выполнять через трансляцию/добавление префиксов на стыке CUCM-CUBE, что бы нормально это реализовать, и вспоминая как делается это на Asterisk, наворачиваются слёзы. Хочется после этого как минимум выкинуть CUBE, и поставить кластер Asterisk (благо есть где развернуть), который возьмёт на себя маршрутизацию внешних вызовов и автосекретаря, голосовых меню. Понимаю, что с большей вероятностью тут проблема во мне, "не умею готовить" может быть, но соотношение трудозатраты/результат, пока оно себя не оправдывает. Ну или же нужен всё таки проученный специалист именно по телефонии Cisco. Возможные минусы работы с asterisk: -нет web интерфейса; -не такое удобное конфигурирование телефонов, не через WEB интерфейс. -количество телефонов в итоге ~ 300 штук Но опять же, пути решения этих вопросов знакомы. Покритикуйте пожалуйста, интересно в чём прав я, в чём нет. P.S. Если этот вопрос лучше вынести в отдельную тему, скажите)

И это "боль" :( Сейчас сделал схему что srv1 связывается с srv2 по PJSIP, а принимает соединение от srv2 на SIP на другой порт отличный от PJSIP. В итоге когда звонок с srv2 у нас SIP->PJSIP, а когда звонок с srv1, то SIP-SIP. Но и тут сейчас возникла проблема, пытаюсь решить.

Я создавал два транспорта, с разными портами, не помогало) Проблема в PJSIP, он не понимает видимо, когда он устанавливает соединение на IP/PORT, а с этой же пары потом пытаются установить соединение с ним.

Пробовал, не помогает. Похоже что надо инициировать соединение с разных портов, но со стороны srv2, sip пока :(