Уважаемые дамы и господа! Для вас сохранен старый форум по адресу http://forum.intersyst.ru

Страницы: 1
RSS
ARS switchover problem, Проблема переключения на резервный маршрут
 
Здравствуйте!
Имеется следующая структура

OXE map

В настоящий момент на узлах 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. Вот пример трассировки:

Код
mtracer started ...
(635968:000001) MTRACER host (10.197.133.1, gu_20), version: R8.0.1-g1.503-12-a- X ru-c7s2
(635968:000001) MTRACER num: 010, time: 2014/02/06 13:09:27, loss: 0%
 ______________________________________________________________________________
| (636014:000019) 1085: Send_IO1 (link-nbr=17, sapi=0, tei=0) :
| long: 101  desti: 0  source: 15  cryst: 0  cpl: 17  us: 8  term: 1  type a5
| tei: 0  <<<<  message sent : SETUP [05]    Call ref :  18 5c
|______________________________________________________________________________
|
| [9f] Non-locking shift. codeset : 7
| [a1] EI_IP_TYPE_NODE
| [9f] Non-locking shift. codeset : 7
| IE:[05] EI_IP_INFOS (l=9) -> G723  Ece 1 Vad 1 Profil 2, IPv4 :10.197.133.13.
| [9f] Non-locking shift. codeset : 7
| IE:[06] EI_IP_PAYLOADS (l=1) -> G711a Ece 1 Vad 0
| [9f] Non-locking shift. codeset : 7
| IE:[07] EI_IP_QOS (l=3) b8 a0 00
| [9f] Non-locking shift. codeset : 7
| IE:[0a] EI_RTP_INFO (l=30)
|    -> stop_packet=0 stop_rtp=0 h323=0 wc=0 rf=0 udp=1 rqm=0
|    -> Transm_Bande=1 detection_Q23=1 dtmf_payload=96
|    -> Port RTP     = 32732, IPv4 :    10.  197.  133.    4.
|    -> Port RTCP SR = 32733, IPv4 :    10.  197.  133.    4.
|    -> Port RTCP RR = 32733, IPv4 :    10.  197.  133.    4.
|    -> Port Fax     = 0, IPv4 :     0.    0.    0.    0.
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3)  a8 83 82 -> T2 : No B channel
| IE:[6c] CALLING_NUMBER (l=1)  ->  81  Num :
| IE:[70] CALLED_NUMBER (l=6)  ->  81  Num : 17760
| IE:[7d] HLC (l=2) 91 81
| [a1] Sending complete


Префикс 17760 как раз имеет значение VPN overflow.

Подскажите пожалуйста, в чем может быть проблема и как ее диагностировать?

Большое спасибо!
Изменено: Vladimir Shushkov - 15.03.2014 23:06:00
 
в 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 :
Изменено: error - 16.03.2014 12:37:11
Пути IP-пакета неисповедимы
 
Уважаемый, Коллега!

Спасибо за разъяснения! Немного неясно первое замечание. Правильно ли я его понял, что по умолчанию, при создании 2х маршрутов в ARS таблице, они распределяются по разным Time based таблицам, в связи с чем в любом случае требуется редактирование этих таблиц с целью объединения маршрутов в одной таблице?

Читал раздел ARS документации. Насколько я помню, Time based списки необходимы в том случае, если мы хотим настроить изменение маршрутизации в зависимости от расписания. Или я ошибаюсь?

По поводу Quality - возьму на заметку. Спасибо!

Насчет АОНа - тоже интересно. С чем может быть связан тот момент, что источник не отдает АОНа? Вообще, верно ли мое предположение о том, что при VPN overflow реальные номера не передаются в явном виде, а упаковываются (подобно тому как при передаче данных функционируют туннели GRE и IPSec в туннельном режиме) с использованием неких внешних данных (в данном случае виртуальных номеров)? Можно ли в этом случае каким-то образом все-таки отследить, что передается внутри? Например, использовать какой-то специфический фильтр или что-то еще?

Спасибо!
 
все правильно Time based по времени
но каждый Time based еще регулируется по роутам ars-а
Пути IP-пакета неисповедимы
 
Владимир, а вы читали раздел документации про VPN Overflow ?
 
Читал. В разделе в основном речь идет о том, что данный метод применяется чтобы связать абонентов через публичную сеть, когда приватная не может быть использована. Но вот про использование 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.
Код
______________________________________________________________________________
| (271847:000548) 1010: Send_IO1 (link-nbr=2, sapi=0, tei=0) :
| long: 54  desti: 0  source: 15  cryst: 0  cpl: 2  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : SETUP [05]    Call ref :  07 97
|______________________________________________________________________________
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3)  a9 83 82 -> T2 : B channel 2 exclusive
| IE:[6c] CALLING_NUMBER (l=9)  ->  01  81  Num : 1111473
| IE:[70] CALLED_NUMBER (l=8)  ->  81  Num : 1022400
| IE:[7d] HLC (l=2) 91 81
| [a1] Sending complete
|______________________________________________________________________________

 ______________________________________________________________________________
| (271847:000554) Concatenated-Physical-Event :
| long: 23  desti: 0  source: 0  cryst: 0  cpl: 2  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : CALL PROC (02)  Call ref :  87 97
|______________________________________________________________________________
|
| IE:[18] CHANNEL (l=3)  a9 83 82 -> T2 : B channel 2 exclusive
|______________________________________________________________________________

 ______________________________________________________________________________
| (271863:000556) Concatenated-Physical-Event :
| long: 22  desti: 0  source: 0  cryst: 0  cpl: 2  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : DISCONNECT [45]  Call ref :  87 97
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 80 83 -> [83] NO ROUTE TO DESTINATION
|______________________________________________________________________________

 ______________________________________________________________________________
| (271863:000557) 1010: Send_IO1 (link-nbr=2, sapi=0, tei=0) :
| long: 22  desti: 0  source: 15  cryst: 0  cpl: 2  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : RELEASE [4d]   Call ref :  07 97
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________

 ______________________________________________________________________________
| (271863:000560) Concatenated-Physical-Event :
| long: 22  desti: 0  source: 0  cryst: 0  cpl: 2  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : REL COMP [5a]  Call ref :  87 97
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________


Теперь совершаю аналогичный вызов со станции 1. Неуспех - функция отклонена. Трассировка:
Код
______________________________________________________________________________
| (272665:000582) 1010: Send_IO1 (link-nbr=2, sapi=0, tei=0) :
| long: 54  desti: 0  source: 15  cryst: 0  cpl: 2  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : SETUP [05]    Call ref :  07 99
|______________________________________________________________________________
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3)  a9 83 84 -> T2 : B channel 4 exclusive
| IE:[6c] CALLING_NUMBER (l=9)  ->  01  81  Num : 1111568
| IE:[70] CALLED_NUMBER (l=8)  ->  81  Num : 1022400
| IE:[7d] HLC (l=2) 91 81
| [a1] Sending complete
|______________________________________________________________________________

 ______________________________________________________________________________
| (272665:000588) Concatenated-Physical-Event :
| long: 23  desti: 0  source: 0  cryst: 0  cpl: 2  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : CALL PROC (02)  Call ref :  87 99
|______________________________________________________________________________
|
| IE:[18] CHANNEL (l=3)  a9 83 84 -> T2 : B channel 4 exclusive
|______________________________________________________________________________

 ______________________________________________________________________________
| (272680:000590) Concatenated-Physical-Event :
| long: 22  desti: 0  source: 0  cryst: 0  cpl: 2  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : DISCONNECT [45]  Call ref :  87 99
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 80 83 -> [83] NO ROUTE TO DESTINATION
|______________________________________________________________________________

 ______________________________________________________________________________
| (272680:000591) 1010: Send_IO1 (link-nbr=2, sapi=0, tei=0) :
| long: 22  desti: 0  source: 15  cryst: 0  cpl: 2  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : RELEASE [4d]   Call ref :  07 99
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________

 ______________________________________________________________________________
| (272680:000594) Concatenated-Physical-Event :
| long: 22  desti: 0  source: 0  cryst: 0  cpl: 2  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : REL COMP [5a]  Call ref :  87 99
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________



Есть другой внешний абонент 1030172. Когда звоню на него с узла 3, звонок проходит, на экране наблюдаю аналогичную подмену на 10213. Трассировка:

Код
______________________________________________________________________________
| (273641:000638) 1010: Send_IO1 (link-nbr=2, sapi=0, tei=0) :
| long: 54  desti: 0  source: 15  cryst: 0  cpl: 2  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : SETUP [05]    Call ref :  07 9c
|______________________________________________________________________________
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3)  a9 83 87 -> T2 : B channel 7 exclusive
| IE:[6c] CALLING_NUMBER (l=9)  ->  01  81  Num : 1111473
| IE:[70] CALLED_NUMBER (l=8)  ->  81  Num : 1030172
| IE:[7d] HLC (l=2) 91 81
| [a1] Sending complete
|______________________________________________________________________________

 ______________________________________________________________________________
| (273641:000644) Concatenated-Physical-Event :
| long: 23  desti: 0  source: 0  cryst: 0  cpl: 2  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : CALL PROC (02)  Call ref :  87 9c
|______________________________________________________________________________
|
| IE:[18] CHANNEL (l=3)  a9 83 87 -> T2 : B channel 7 exclusive
|______________________________________________________________________________

 ______________________________________________________________________________
| (273653:000646) Concatenated-Physical-Event :
| long: 18  desti: 0  source: 0  cryst: 0  cpl: 2  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : ALERT (01)  Call ref :  87 9c
|______________________________________________________________________________

 ______________________________________________________________________________
| (273653:000647) Concatenated-Physical-Event :
| long: 30  desti: 0  source: 0  cryst: 0  cpl: 2  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : CONNECT (07)  Call ref :  87 9c
|______________________________________________________________________________
|
| IE:[1e] PROGRESS_ID (l=2) 81 82
| IE:[4c] CONNECTED_NUMBER (l=6)  ->  a1  Num : 10213
|______________________________________________________________________________

 ______________________________________________________________________________
| (273653:000648) 1010: Send_IO1 (link-nbr=2, sapi=0, tei=0) :
| long: 18  desti: 0  source: 15  cryst: 0  cpl: 2  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : CONNECT ACK (0f)  Call ref :  07 9c
|______________________________________________________________________________

 ______________________________________________________________________________
| (273703:000687) Concatenated-Physical-Event :
| long: 22  desti: 0  source: 0  cryst: 0  cpl: 2  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : DISCONNECT [45]  Call ref :  87 9c
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________

 ______________________________________________________________________________
| (273703:000690) 1010: Send_IO1 (link-nbr=2, sapi=0, tei=0) :
| long: 22  desti: 0  source: 15  cryst: 0  cpl: 2  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : RELEASE [4d]   Call ref :  07 9c
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________

 ______________________________________________________________________________
| (273703:000693) Concatenated-Physical-Event :
| long: 22  desti: 0  source: 0  cryst: 0  cpl: 2  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : REL COMP [5a]  Call ref :  87 9c
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________



Теперь с узла 1. Звонок также проходит успешно. Трассировка:

Код
| (274059:000698) 1010: Send_IO1 (link-nbr=2, sapi=0, tei=0) :
| long: 54  desti: 0  source: 15  cryst: 0  cpl: 2  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : SETUP [05]    Call ref :  07 9d
|______________________________________________________________________________
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3)  a9 83 88 -> T2 : B channel 8 exclusive
| IE:[6c] CALLING_NUMBER (l=9)  ->  01  81  Num : 1111568
| IE:[70] CALLED_NUMBER (l=8)  ->  81  Num : 1030172
| IE:[7d] HLC (l=2) 91 81
| [a1] Sending complete
|______________________________________________________________________________

 ______________________________________________________________________________
| (274059:000704) Concatenated-Physical-Event :
| long: 23  desti: 0  source: 0  cryst: 0  cpl: 2  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : CALL PROC (02)  Call ref :  87 9d
|______________________________________________________________________________
|
| IE:[18] CHANNEL (l=3)  a9 83 88 -> T2 : B channel 8 exclusive
|______________________________________________________________________________

 ______________________________________________________________________________
| (274078:000706) Concatenated-Physical-Event :
| long: 18  desti: 0  source: 0  cryst: 0  cpl: 2  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : ALERT (01)  Call ref :  87 9d
|______________________________________________________________________________

 ______________________________________________________________________________
| (274078:000707) Concatenated-Physical-Event :
| long: 30  desti: 0  source: 0  cryst: 0  cpl: 2  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : CONNECT (07)  Call ref :  87 9d
|______________________________________________________________________________
|
| IE:[1e] PROGRESS_ID (l=2) 81 82
| IE:[4c] CONNECTED_NUMBER (l=6)  ->  a1  Num : 10213
|______________________________________________________________________________

 ______________________________________________________________________________
| (274078:000708) 1010: Send_IO1 (link-nbr=2, sapi=0, tei=0) :
| long: 18  desti: 0  source: 15  cryst: 0  cpl: 2  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : CONNECT ACK (0f)  Call ref :  07 9d
|______________________________________________________________________________

 ______________________________________________________________________________
| (274128:000735) Concatenated-Physical-Event :
| long: 22  desti: 0  source: 0  cryst: 0  cpl: 2  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : DISCONNECT [45]  Call ref :  87 9d
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________

 ______________________________________________________________________________
| (274128:000738) 1012: Send_IO1 (link-nbr=2, sapi=0, tei=0) :
| long: 22  desti: 0  source: 15  cryst: 0  cpl: 2  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : RELEASE [4d]   Call ref :  07 9d
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________

 ______________________________________________________________________________
| (274128:000742) Concatenated-Physical-Event :
| long: 22  desti: 0  source: 0  cryst: 0  cpl: 2  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : REL COMP [5a]  Call ref :  87 9d
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|______________________________________________________________________________



Таким образом, звонки на внешних абонентов с узла 1 проходят как-то избирательно - есть успехи, есть отказы.

В чем может быть проблема?

Спасибо!
 
В первом случае - ОБА звонка неудачных (отклонены с сообщением No route to destination).
Во втором оба удачны.

так-что спрашивайте вашего провайдера, куда включена плата 0-2 - чего не удается дозвониться до 1022400.

Для проверки - рекомендую создать в станции префиксы занятия TG - чтоб при проверке ARS - отделять мух от котлет. Позвонили ПРЯМО через префикс занятия в TG - и смотрим, дозвонились или нет.
Страницы: 1
Читают тему