Увеличение пропускной способности

[kolizey]

Доброе утро всем. Имеется стабильно работающий бридж на оборудовании Ubiquiti NanoBridge M5 из пункта А в пункт Б. Хочется увеличить пропускную способность канала до баз в точке Б, путем добавления аналогичного параллельного бриджа. Вопрос, каким образом пустить трафик по этим бриджам параллельно, чтоб он(трафик) делился поровну между мостами???

[Constantin]

Вопрос, каким образом пустить трафик по этим бриджам параллельно, чтоб он(трафик) делился поровну между мостами???

хотите стабильный канал не стоит заниматься порнографией

 

из за не стабильного джитера нормальной работы не будет

 

проще и надежней поставить оборудование которое обеспечит большую пропускную способность.

[DiVerSant]

Доброе утро всем. Имеется стабильно работающий бридж на оборудовании Ubiquiti NanoBridge M5 из пункта А в пункт Б.

 

Какое у вас расстояние и объём проходящего трафика ?

[tartila]

Доброе утро всем. Имеется стабильно работающий бридж на оборудовании Ubiquiti NanoBridge M5 из пункта А в пункт Б. Хочется увеличить пропускную способность канала до баз в точке Б, путем добавления аналогичного параллельного бриджа. Вопрос, каким образом пустить трафик по этим бриджам параллельно, чтоб он(трафик) делился поровну между мостами???

 

Самый лучший вариант, конечно, поделить канал на логическом уровне с помощью IP подсетей и/или PBR, если это возможно. Худший вариант - это сделать агрегацию на свитче или на самих устройствах. Как показала практика на Mikrotik с аналогичной задачей, самая лучшая агрегация получилась на устройствах с алгоритмом round-robin, то есть - пакет в один канал, пакет в другой канал. У каждого из вариантов есть свои минусы, например в первом случае балансировка будет не идеальной и при падении одного из каналов перестанет работать часть сетей. У второго варианта (rr-balance) минус, что если из строя выйдет один из каналов - потери у всех клиентов будут составлять 50%.

[kolizey]

Доброе утро всем. Имеется стабильно работающий бридж на оборудовании Ubiquiti NanoBridge M5 из пункта А в пункт Б.

 

Какое у вас расстояние и объём проходящего трафика ?

 

Расстояние 2 км приблизительно, объемы разные, но в пике нагрузки канала все же уже не хватает...

 

Вопрос, каким образом пустить трафик по этим бриджам параллельно, чтоб он(трафик) делился поровну между мостами???

хотите стабильный канал не стоит заниматься порнографией

 

из за не стабильного джитера нормальной работы не будет

 

проще и надежней поставить оборудование которое обеспечит большую пропускную способность.

Такое решение предполагается, но в данной ситуации не имеет смысла делать бОльшие финансовые вложения, пока сеть не перешла на самоокупаемость (

 

Доброе утро всем. Имеется стабильно работающий бридж на оборудовании Ubiquiti NanoBridge M5 из пункта А в пункт Б. Хочется увеличить пропускную способность канала до баз в точке Б, путем добавления аналогичного параллельного бриджа. Вопрос, каким образом пустить трафик по этим бриджам параллельно, чтоб он(трафик) делился поровну между мостами???

 

Самый лучший вариант, конечно, поделить канал на логическом уровне с помощью IP подсетей и/или PBR, если это возможно. Худший вариант - это сделать агрегацию на свитче или на самих устройствах. Как показала практика на Mikrotik с аналогичной задачей, самая лучшая агрегация получилась на устройствах с алгоритмом round-robin, то есть - пакет в один канал, пакет в другой канал. У каждого из вариантов есть свои минусы, например в первом случае балансировка будет не идеальной и при падении одного из каналов перестанет работать часть сетей. У второго варианта (rr-balance) минус, что если из строя выйдет один из каналов - потери у всех клиентов будут составлять 50%.

Момент с подсетями все же интересней ) будет хоть какое то резервирование, все же на одном канале в случае его падения. отвалится весь райончик )

[Constantin]

У второго варианта (rr-balance) минус, что если из строя выйдет один из каналов - потери у всех клиентов будут составлять 50%.

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

[tartila]

У второго варианта (rr-balance) минус, что если из строя выйдет один из каналов - потери у всех клиентов будут составлять 50%.

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

 

Только в tcp "вытикающие", если реордеринг. Потом я лично делаю балансирую тоннели между микротиками (eoip) и link-monitoring вырубаю к чертям, что бы не происходило сюрпризов во время работы нагруженного канала. Отсюда, из опыта я говорю о том, что лучше 50% потерь во время реальной проблемы с радио, нежели чем произвольное кол-во потерь из-за софт проблем микротика.

[NewUse]

Какая текущая пропускная способность, какая целевая?

В вай-фай лучше разделять трафик по направлениям входящий/исходящий, а не по маршрутам.

[tartila]

Какая текущая пропускная способность, какая целевая?

В вай-фай лучше разделять трафик по направлениям входящий/исходящий, а не по маршрутам.

 

Справедливо для среды передачи Wi-Fi, но, наверное поломает TCP...