отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
Объявления
Добро пожаловать в Сообщество Технической поддержки Cisco. Мы рады получить обратную связь .
New Member

Не сбрасывается sip-соединение при переключении с backup на outside

Всем - привет!

Не сбрасывается установленное udp-соединение при переключении с backup на outside. Даже не знаю что предположить как причину и куда, соответственно, покопать для решения. Подскажите пож-та ваши идеи.

ASA5505 двое суток назад перешла backup-провайдера (ntkisp), а полтора суток назад вернулась на основной канал (outside), но установленное udp-соединение (через ntkisp) не сбросилось, счетчики байтов по нему продолжали расти, хотя роутинг уже полтора суток работал через outside:

 

# sh local-host 192.168.1.172
Licensed host limit: Unlimited.

Interface ntkisp: 1 active, 2 maximum active, 0 denied
Interface outside: 213 active, 2163 maximum active, 0 denied
Interface inside: 47 active, 55 maximum active, 0 denied
local host: <192.168.1.172>,
    TCP flow count/limit = 0/unlimited
    TCP embryonic count to host = 0
    TCP intercept watermark = unlimited
    UDP flow count/limit = 2/unlimited

  Xlate:
    PAT Global 79.135.111.111(40293) Local 192.168.1.172(5060)
    PAT Global 91.246.222.222(51008) Local 192.168.1.172(5060)

  Conn:
    UDP ntkisp 213.159.111.111:5060 inside 192.168.1.172:5060, idle 0:00:00, bytes 6872450, flags T
    UDP outside 213.159.111.111:0 inside 192.168.1.172:5060, idle 0:01:35, bytes 0, flags ti
Interface _internal_loopback: 0 active, 0 maximum active, 0 denied

# sh local-host 192.168.1.172
[...skip...]

  Conn:
    UDP ntkisp 213.159.111.111:5060 inside 192.168.1.172:5060, idle 0:00:06, bytes 6880559, flags T
    UDP outside 213.159.111.111:0 inside 192.168.1.172:5060, idle 0:03:25, bytes 0, flags ti

# sh route
[...skip...]
S*   0.0.0.0 0.0.0.0 [1/0] via 79.135.111.11x, outside

Полечилось насильным сбросом соединения clear local-host 192.168.1.172. Но не каждый же раз после переключения с backup-канала всех руками сбрасывать...

 

Да, такая проблема оказалась не у всех телефонных аппаратов (инициатор соединения - 192.168.1.172). Сименс Гигасеты отработали этот момент нормально, без данной проблемы, а вот Cisco SPA303 - показали эту проблему.

Ситуация устойчивая, т.е. при каждом переключении на основной канал.

 

Спасибо заранее.

1 УТВЕРЖДЕННОЕ РЕШЕНИЕ

Утвержденные решения

Это нормально. Дайте "timeout

Это нормально. Дайте "timeout floating-conn 0:00:30" тогда само будет.

 

6 ОТВЕТ.

Это нормально. Дайте "timeout

Это нормально. Дайте "timeout floating-conn 0:00:30" тогда само будет.

 

New Member

Большое спасибо, Олег!Я на

Большое спасибо, Олег!

Я на практике подтверждения ещё не получил, но по описанию в cmdref 100% подходит под решение описанной проблемы.

Не думал, что на столь базовую вещь сделают конфигурируемый тайм-аут, да мало того по дефолту выставят его в "бесконечность"!...

New Member

Одно не очень понятно -

Одно не очень понятно - почему на Гигасетах это никак не проявилось, а на SPA303 - в полной мере...

С т.зр. ASA эти соединения д

С т.зр. ASA эти соединения д.б. эквивалентны. Вероятно эти Гигасеты открыли новые соединения, которые отмаршрутизировались правильно.
 

New Member

Дело ещё в том, что SPA303 ни

Дело ещё в том, что SPA303 ни один раз перегружали, пока поняли, что искать надо на ASA. Т.е. и после перезагрузки SPA303 не открывал новое соединение или каким-то образом "попадал" в старое. Мне как-то с трудом представляется эта ситуация...

Ну а почему нет? Там же и

Ну а почему нет? Там же и порт отправителя и порт получателя 5060. Поэтому и попадал.

50
Просмотры
0
Полезный материал
6
Ответы