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

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

От Alex Bakhtin (2:5020/400) к Slawa Olhovchenkov

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


From: Alex Bakhtin <bakhtin@amt.ru>

>>>>> "SO" == Slawa Olhovchenkov writes:
Привет,

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

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

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

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

Слава, у меня дома нет того оборудования, да и технологически оно
неприменимо:-)

SO> hint: rtt.

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

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

Бекапный канал можно мониторить в обе стороны.

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

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

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

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

Ладно, согласен, я и не продумывал это серьезно.

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

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

Hу да, по москве. Слава, у меня есть freebsd в продакшене, но к
роутингу они не имеют никакого отношения. А до дома у меня < 5ms rtt по
основному каналу и ~10 ms по резервному.

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

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

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

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

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

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

В общем я понял, будет время - попробую подкрутить mpd.

--
Best regards, Alex Bakhtin, CCIE #8439
AMT Group, Cisco Systems Gold Partner, http://www.amt.ru
--- ifmail v.2.15dev5.4
* Origin: AMT Group (2:5020/400)

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

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

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

FGHI-url этого письма: area://RU.UNIX.BSD?msgid=<1187326641@bakhtin.amt.ru>+cc79d9a8