LINUX.ORG.RU
Форум — Admin  

QoS для VoIP


0

0

Есть распредленная сеть объединяющая удаленные точки и офис.Точки через роутеры (Linux) подключны к магистрали, которая приходит в офис (тоже роутер Linux). Задача кроме данных гонять еще и VoIP и соответственно обеспечить для него QoS. Перечитав кучу статей и форумов понял, что все алгоритмы обеспечения QoS работают на исходящий трафик,а то что есть для входящего - реально мало помогает. Исходя из этого вошел в ступор - а как же тогда решают такие задачи в сетях с несколькими точками ? В случае с 2 точками (равнозначными) - все ясно и понятно, а вот тут.... Если точка 1 начала гнать в офис VoIP трафик,то все хорошо, а если в это время точка 2 вдруг решит в офис гнать обычный траффик, то она ничего не знает про VoIP трафик точки 1 и будет гнать свое по полной - соответственно загадив весь канал на входе у офиса. А если точек 10-15... Подскажите плз как быть ?

PS: Какие вообще алгоритмы лучше пользовать для QoS VoIP трафика ?

anonymous
← host под винду
vpn + дополнительный route →

Чтобы более-менее эффективно управлять входящим (относительно офиса) трафиком, нужно управлять им на том интерфейсе, что в офис смотрит (управлять как исходящим относительно роутера).

fagot ★★★★★
()
Ответ на: комментарий от fagot

Т.е. срезать трафик идущий от роутера в LAN ? Да, про такое я тоже читал, но насколько понял это действует только на TCP (UDP пофиг) и все равно в начале передачи будет всплеск трафика,который потом по протоколу TCP вроде как снизится, но эти начальные всплески все равно жизнь VoIP испортят.

anonymous
()
Ответ на: комментарий от anonymous

>Т.е. срезать трафик идущий от роутера в LAN ?

ага.

>Да, про такое я тоже читал, но насколько понял это действует только на TCP (UDP пофиг)

Ну, где-то так и есть, поскольку при уничтожении TCP-трафика, он повторно пересылается, но с меньшей интенсивностью, а UDP - просто повторно пересылается (ну, или не пересылается, зависит от приложения).

Но тут ничего не поделаешь, для нормального QoS нужно использовать TCP/IP поверх ATM и резать на соответствующем уровне. Или управлять Ethernet-кадрами, с помошью меток 802.1p/Q.

>и все равно в начале передачи будет всплеск трафика,который потом по протоколу TCP вроде как снизится, но эти начальные всплески все равно жизнь VoIP испортят.

чесно говоря не знаю, у меня VoIP нету, но подозреваю, что что-то такое очень даже может быть :)

Но как-то же оно у людей работает ;)

Я бы попробовал настроить PRIO-дисциплину, по идее голосовой трафик не очень интенсивный, поэтому много отъедать не будет, но обслуживаться должен в первую очередь.

Если при этом еще и (значительно?) уменьшить MTU, то проблем с задержкой почти наверняка станет гораздо меньше, хотя и общая производительность упадет, конечно.

fagot ★★★★★
()
Ответ на: комментарий от fagot 

Для начала вот это
http://www.opennet.ru/docs/RUS/adv_route_qos/
Не ясно вот что - магистраль обеспечивает механизмы качества обслуживания ? Frame-relay например. Если в магистрали ethernet то нужно идти от ее максимальной полосы пропускания. 
Решение скорее всего одно - резать по полосе.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← host под винду
Admin
vpn + дополнительный route →