В настоящий момент на узлах 1 и 3 настроен ARS таким образом, что по префиксу 8 существует 2 маршрута: один через tg 103, второй через tg 305. Однако, как выяснилось, на узле 1 первый маршрут - 103, второй - 305. А на узле 3 наоборот. Вариант 3-го узла является правильным, поэтому решил изменить конфигурацию узла 1 поменяв местами маршруты. Но предварительно рещил проверить, корректно ли отрабатывает маршрут через tg 305. Отключил физически интерфейс потока tg 103 и попробовал позвонить наружу - неудачно. На аппарате высвечивалось Out of service.
Абоненты узла 3 успешно звонят через tg 305. Абоненты узла 1 успешно звонят через tg 103. Абоненты между узлами также могут звонить друг другу без проблем. Между станциями настроен ABC гибридный линк по IP (TG300). Никаких DDI трансляций не используется.
Транкгруппы:
Код
output of all Trunk_Groups and Links
-------------------------------------------------------------------
Numb | Name | Type | Var. | Node | Pfx
-------------------------------------------------------------------
TG 103 | MPLS-r | T2 | ISDN | 1 => local | No pfx
TG 300 | IP | T2-IP | ISDN | 3 => remote | C300
TG 305 | MPLS | T2 | ISDN | 3 => remote | No pfx
Маршруты ARS первого узла (lookars r 1)
Код
(1)node1> lookars r 1
Tue Mar 11 09:44:08 GMT-4 2014
====================================================================
| A R S R O U T E S L I S T No 1 |
--------------------------------------------------------------------
| ROUTES DEFINITIONS X |
--------------------------------------------------------------------
|
| 1) trk_grp = 103 dialing_table = 0
| nb_deleted_digits = 0 inserted_digits =
| vpnCostLimit = 0
| idx_atm = -1
|
| --> trk_grp 103 local TG name : MPLS-r state : PART_FREE
| type : T2 variante : ISDN
| fais_suiv = -1 category = 0 nbjonc = 30
| vpnRate = 50 vpnCostLimit = 0
| Route usefull for : SPEECH FAX
| Protocole Type = DEPENDENT ON TG
| Route Type = Public
| NPD Id = 67
| Preempter = 0
| Trunk group source = ROUTE
--------------------------------------------------------------------
|
| 2) trk_grp = 305
dialing_table = 0
| nb_deleted_digits = 0 inserted_digits =
| vpnCostLimit = 0
| idx_atm = -1
|
| --> trk_grp 305 remote TG name : MPLS
| type : T2 variante : ISDN
| node_number = 3 network_number = 15
| fais_suiv = -1
| Route usefull for : SPEECH FAX
| Protocole Type = DEPENDENT ON TG
| Route Type = Public
| NPD Id = 67
| Preempter = 0
| Trunk group source = ROUTE
--------------------------------------------------------------------
Пробовал включить трассировку между узлами. Для фильтрации, не зная, как можно настроить более конкретный фильтр, использовал trc C 0 c <INTIP slot>. К сожалению, ничего толкового поймать не смог: во-первых, между узлами достаточно интенсивное взаимодействие абонентов, поэтому в трассу попадает много лишнего, во-вторых, насколько я понял по пойманным данным, в связи с тем что между узлами используется гибридный линк с VPN overflow реальное взаимодействие ведется между виртуальными префиксами типа VPN Overflow. Вот пример трассировки:
в ARS кроме ARS Route есть еще и Time-based Route List основной затык в Time-based Route List это создание 2-х независисых тайм-листа, а надо в один и в нем прописать 2 роута
для проверка перехода из одного роута в другой не обязательно PRI дергать, достаточно в основном роуте указать Quality + Out Of Service
так же возможен затык в отсутствии исходящего АОН через роут удаленной ноды, тобишь как вариант пров бреет звонки где нет исходящего АОНа
Цитата
Vladimir Shushkov пишет: IE:[6c] CALLING_NUMBER (l=1) -> 81 Num :
Спасибо за разъяснения! Немного неясно первое замечание. Правильно ли я его понял, что по умолчанию, при создании 2х маршрутов в ARS таблице, они распределяются по разным Time based таблицам, в связи с чем в любом случае требуется редактирование этих таблиц с целью объединения маршрутов в одной таблице?
Читал раздел ARS документации. Насколько я помню, Time based списки необходимы в том случае, если мы хотим настроить изменение маршрутизации в зависимости от расписания. Или я ошибаюсь?
По поводу Quality - возьму на заметку. Спасибо!
Насчет АОНа - тоже интересно. С чем может быть связан тот момент, что источник не отдает АОНа? Вообще, верно ли мое предположение о том, что при VPN overflow реальные номера не передаются в явном виде, а упаковываются (подобно тому как при передаче данных функционируют туннели GRE и IPSec в туннельном режиме) с использованием неких внешних данных (в данном случае виртуальных номеров)? Можно ли в этом случае каким-то образом все-таки отследить, что передается внутри? Например, использовать какой-то специфический фильтр или что-то еще?
Читал. В разделе в основном речь идет о том, что данный метод применяется чтобы связать абонентов через публичную сеть, когда приватная не может быть использована. Но вот про использование VPN overflow для гибридных линков как-то совсем мало информации.
Тогда, если после lookvpn и пр., указанного в документации на ABC-IP Logical Link, непонятно и хочется получить простынку логов и куда-нибудь ее бомбануть, то есть ТС0672 и ТС0730.
Еще можно почитать документ VPN Overflow, он местами старый, но зато весь про VPN Overflow, после него простые вопросы возникать не должны.
Решил немного написать, про роуты и time based-route lists (для обычного, типового случая).
В ARS листе вы создаете роуты (до 10 шт), порядок их создания, номера, номера TG внутри них - не имеют никакого отношения к порядку их использования.
Порядок их использования - задается в time based route lists.
Вам надо создать ОДИН !!! time based route list, в котором перечислить в каком порядке, какой роут вы хотите использовать (типа 1,-1-1; 2,-1,-1; 4,-1,-1 - т.е. сначала роут номер 1, потом номер 2, потом номер 4). Типовая ошибка - вместо ОДНОГО листа с рутом 1 и 2, создают ДВА листа, один с рутом 1, второй с рутом 2. В этом случае ВСЕГДА будет использован рут номер 1.
И таки да - time based листы нужны всегда. Если у вас в ARS листе один рут - вы обязаны создать time based route list, в котором указать этот единственный роут.
Коллеги! Спасибо за Ваши разъяснения. Проблема была действительно в некорректной настройке time-based route листов. Исправил, настроив на узле N1 TBR лист с обоими маршрутами Speech+Fax. Стал проверять - выплыла другая проблема: На узле N1 для проверки корректной маршрутизации вызовов через TG305 отключаю маршрут через TG103, указав в роут листе Out Of Service (как Вы меня и учили). На интерфейса TG305 узла N3 включаю трассировку и пробую звонить на внешние корпоративные номера - на некоторые из них абонент узла N3 может позвонить а абонент узла N1 не дозванивается (музыка + функция отклонена).
Более подробно. Есть внешний абонент 1022400. Если звоню ему с узла N3, то всё ОК, хотя на экране телефона наблюдаю измененный номер 10213 (может быть перевод какой настроен - непонятно, высвечиваемый номер короче необходимого - вместо 7 цифр отображается 5). Вот трассировка успешного вызова с узла 3.
В первом случае - ОБА звонка неудачных (отклонены с сообщением No route to destination). Во втором оба удачны.
так-что спрашивайте вашего провайдера, куда включена плата 0-2 - чего не удается дозвониться до 1022400.
Для проверки - рекомендую создать в станции префиксы занятия TG - чтоб при проверке ARS - отделять мух от котлет. Позвонили ПРЯМО через префикс занятия в TG - и смотрим, дозвонились или нет.