на главнуюВсе эхи RU.UNIX.BSD
войти ?

Мониторинг состояния туннелей и переключение роутинга

От Slawa Olhovchenkov (2:5030/500) к Alex Bakhtin

В ответ на Заголовок предыдущего сообщения в треде (Имя Автора)


Hello Alex!

20 Apr 09, Alex Bakhtin writes to Slawa Olhovchenkov:

AB>> Hу, на сети при всех закрученных параметрах, реальное время перерыва
AB>> сервиса колеблется в районе 50-100ms.

SO>> это из комнаты в комнату, да?
SO>> а из москвы в хабаровск? а в штаты?

AB> Это время переключения на бекапные TE туннели в ядре нормально
AB> построенной сети сервиспровайдера:) Hеобходимости сигнализировать из конца
AB> в конец за 50 ms отсутствует, срабатывает либо link либо node protection, в
AB> зависимости от...

тогда что ты изобретаешь?

SO>> hint: rtt.

AB> А при чем тут rtt? Должно быть два независимых источника кипалайвов,
AB> если мы не видим ПОЛУЧЕHHЫХ (не ответов на наши) кипалайвов в течение 30 ms
AB> - пора крутить роутинг.

а вот фиг. если ты не видишь этих кипалайвов это не значит, что та сторона не получает от тебя трафик. и не факт, что по альтернативному маршруту получит. как тебе такая анизотропия?

AB> Т.е. вопрос не в rtt а в джиттере в каждую сторону
AB> исключительно, пока он независимо от rtt укладывается в 30ms - все
AB> должно работать.

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

пусть между точками в одну сторону 100мс, джитер 0.
в момент 0 на точке а на первом канале авария.
через 100 мс + 30 мс об этом узнают на точке б и переключат роутинг.
по новому роутингу пакет придет еще через 100 мс.
т.е. на 230 мс точка а не будет иметь трафика.

так что rtt тут еще как причем.

SO>> что бы у тебя трафик начав идти по второму каналу вообще дошел до
SO>> нужной точки тебе может потребоваться не просто больше 50мс, а больше
SO>> 100мс. это мы еще время на детектирование необходимости переключения
SO>> не учли. ну еще ведь и скомандовать надо о переключении, а
SO>> односторонней проходимости канала никто не отменял... а ведь у нас
SO>> может быть не перерыв связи по первому каналу, а просто джитер. а на
SO>> какой джитер по интернет-каналу ты расчитываешь?
AB> Там, где мне это надо - я рассчитываю на rtt в единицы ms:)

а, т.е. в соседнюю комнату.

SO>> могу предложить гнать трафик по обоим туннелям, на приеме выбирать с
SO>> минимальным джитером.

AB>> Это IMHO сложно.

SO>> имхо нет, если там будет протокол типа rtp.
SO>> кстати, а если просто rtp гнать и сливать, он сам все не сделает ли?
SO>> он же вроде автоматом дубли выкидывать будет?

AB> Я думаю (исходя из общих соображение) что рано-или поздно у телефонов
AB> от этого снесет крышу:)

ну значит написать свой деджитер буфер.

для размножения уже есть ng_tee.

... А вы и ухом не моргнули!

--- GoldED+/BSD 1.1.5
* Origin: (2:5030/500)

Ответы на это письмо:

From: Username
Заголовок следующего сообщения в треде может быть длинным и его придется перенести на новую строку

From: Username
Или коротким

FGHI-url этого письма: area://RU.UNIX.BSD?msgid=2:5030/500+49ec7699