QoS для VoIP

[LSN]

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

 

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

[puh]

кроме приоретизации на третьем уровне должна быть ещё приоретизация на втором уровне. На всей сети

[LSN]

кроме приоретизации на третьем уровне должна быть ещё приоретизация на втором уровне. На всей сети

 

Т.е. магистральные коммутаторы должна обрабатывать метки ToS ?

[Microsoft]

А почему не делать QoS в офисе, куда подключены все точки?

Ведь весь трафик все-равно проходит через него, я правильно понял?

[LSN]

А почему не делать QoS в офисе, куда подключены все точки?

Ведь весь трафик все-равно проходит через него, я правильно понял?

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

[Microsoft]

Если точка 1 начала гнать в офис VoIP трафик,то все хорошо, а если в это время точка 2 вдруг решит в офис гнать обычный траффик, то она ничего не знает про VoIP трафик точки 1 и будет гнать свое по полной - соответственно загадив весь канал на входе у офиса. А если точек 10-15... Подскажите плз как быть ?  

Ну как же так получается у вас, что точка 2 загадит канал?

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

Или я чего-то не понимаю?

[LSN]

Так то оно так, но у меня там IPSec VPN еще ходит, а оно protocol 50 (ESP) и UDP port 500, ну IKE (udp 500) - ладно это немного, а вот ESP - вообщем то практически весь трафик в нем и будет, а принцип работы ESP - я честно скажу - не знаю...

И мне кажется, что при начале передачи TCP тоже будет всплеск, который потом спадет конечно, но нагадить успеет.. Или я не прав...

 

А вообще ктонить реально использует подобную схему в жизни ? Интересны работающие примеры.

[Microsoft]

Так то оно так, но у меня там IPSec VPN еще ходит, а оно protocol 50 (ESP) и UDP port 500, ну IKE (udp 500) - ладно это немного, а вот ESP - вообщем то практически весь трафик в нем и будет, а принцип работы ESP - я честно скажу - не знаю...  

Или ставить QoS, который умеет приоритетить то, о чем вы говорите, или ставить QoS в том месте, где трафик уже не инкапасулированный, т. е в вашем случае во внутренней сети офиса между граничным маршрутизатором и остальной сетью офиса, но в этом случае граничный маршрутизатор будет форвардить трафик не предназначенный офису и пакеты до железки с QoS не дойдут. Тогда чтобы приоритетить траффик между точками - задача усложняется. Как выход из этой ситуации:

1. или отказаться от VPN;

2. или менять (усложнять) топологию сети в офисе;

3. или делать QoS на входе всех точек;

4. или может еще чего.

И мне кажется, что при начале передачи TCP тоже будет всплеск, который потом спадет конечно, но нагадить успеет.. Или я не прав...  

Всплеск определяется размером TCP-окна, которое может быть максимального размера 64 КБ. Другими словами, каждое TCP соединение может послать без подтверждения максимум 64 КБ, но не факт, что если можно послать 64 КБ, то все сразу будут начинать TCP-передачу с таким размером окна. На практике обычно окно меньше при начале передачи (зависит от реализации стека).

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

Если у вас 64 KБ - то да, про VoIP + данные можно забыть :)

[puh]

Если у вас 64 KБ - то да, про VoIP + данные можно забыть :)

то есть, я правильно понял, что ты утверждаешь, что при канале 64K голос+данные гонять нельзя???? Забавно, забавно...

[Microsoft]

Если у вас 64 KБ - то да, про VoIP + данные можно забыть :)

то есть, я правильно понял, что ты утверждаешь, что при канале 64K голос+данные гонять нельзя???? Забавно, забавно...

Оно-то конечно забавно, да только одно но:

прежде чем стебаться, читаем первый пост внимательнее:

"...А если точек 10-15... Подскажите плз как быть ?..."

И вы это сможете назвать "голосом", при 64 Кбит/с? Это будет уже не голос...

Делим ширину канала офиса на 10-15 и гоняем по нему голос + данные... Вот это будет забавно :)

[LSN]

Да наверное надо было сразу ширину канала огласить :).

Клиенты на 10Мбитах - магистраль и офис на 100 Мбитах. Но как показвает практика даже в офисной 100 Мбитной сетке можно голос задавить очень просто.

[Microsoft]

Клиенты на 10Мбитах - магистраль и офис на 100 Мбитах. Но как показвает практика даже в офисной 100 Мбитной сетке можно голос задавить очень просто.

Тогда "всплески" в 64 K ничего не попортят.