[xphoenix]

Ситуация следующая - стоит АП bullet 2hp, клиенты locom2 и nanobridgem2, ранее раздачей инета занимался rb750 за булитом, теперь необходимо прокидывать бриджем всех клиентов на роутер провайдера (его условия), авторизация pppoe, динамический реальный адрес. Проблема в том что провайдер не дает нужные нам тарифы, минимальный у них 8мбит, а летом будет 14, кидать такой трафик на клиентов мягко говоря не целесообразно... Вопрос: чем в данной ситуации резать скорость? МТ умеет резать бридж? или вообще убрать из цепочки микротик, кидать напрямую с булита и резать на клиентских точках Incoming Traffic Limit (пароли от них только у меня)? Но не получится ли тогда что от АП до клиента будет идти весь канал 8 мбит, а резаться будет только сам лан порт? Эфиру тогда крышка?

Изменено 4 мая, 2012 пользователем xphoenix

[fhntv_smart]

Микротик умеет шейпить и приоритизировать проходящий трафик... Ищите презентацию Мегиса.

Вот только не знаю как с ппое пакетами...

Если у них есть адрес источник из локалки то работать будет.

 

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

И будет в PCQ лимит на клиента, а в дереве лимит на группу.

Ваш вариант тоже подойдет, но с HTB будет лучше.

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

Изменено 4 мая, 2012 пользователем fhntv_smart

[kosmich7]

а резаться будет только сам лан порт?

Вот тут и шейпить.

[mousus]

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

[Saab95]

В манглах есть пункт Src MAC Address, можно попробовать использовать его для нарезки трафика. Если PPPoE клиент поднимается клиентом UBNT - его мак адрес и нужно указывать.

 

 

[xphoenix]

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

не совсем понял зачем всем отдельные вланы? Клиентские ubnt должны поднимать пппое из бриджа МТ, так как пров хочет видеть всех клиентов.

Микротик умеет шейпить и приоритизировать проходящий трафик... Ищите презентацию Мегиса.

Вот только не знаю как с ппое пакетами...

Если у них есть адрес источник из локалки то работать будет.

 

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

И будет в PCQ лимит на клиента, а в дереве лимит на группу.

Ваш вариант тоже подойдет, но с HTB будет лучше.

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

умно, но я пока еще наверное с таким не справлюсь ) чуть поподробнее бы..

вариант с манглом мне кажется наиболее хорошим, и легким для себя, так как с вланом и древом точно буду долго мучаться.

 

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

 

xphoenix (Сегодня, 13:05) писал:

а резаться будет только сам лан порт?

 

Вот тут и шейпить.

а канал не будет загружаться? например я ограничу в 2мбита, а по радио будет постоянно скакать от 2 до 8 (так как 8 приходит от прова)

Изменено 4 мая, 2012 пользователем xphoenix

[mousus]

общий канал |b|Vlan1---shape1---абонент1

------------|r|Vlan2---shape2---абонент2

------------|i|Vlan3---shape3---абонент3

------------|d|Vlan4---shape4---абонент4

------------|g|Vlan5---shape5---абонент5

------------|e|Vlan6---shape6---абонент6

 

вот и вся логика -- абонентам в радиоканале отдавать тегом вланы

тут только булет плюс кучка локо нужно, схема реализуется на булете

[fhntv_smart]

вариант с манглом мне кажется наиболее хорошим, и легким для себя, так как с вланом и древом точно буду долго мучаться.

то что написанно про мангл это часть моего плана. :)

в мангл мы пакеты маркируем, а в дереве шейпим.

Хотя, если пакеты маркированы, можно и в простых очередях шейпить.

Но лучше в дереве. там можно поставить лимит на группу равным физ лимиту базы, а лимит на человека чуть больше.

И оно будет честно делить скорость на всех.

[rmika]

может поставить пакет (rshaper) на локо и резать на нем...

Изменено 4 мая, 2012 пользователем rmika

[Saab95]

Не забывайте, что UBNT имеет привычку терять маки клиентов при работе по L2. При некотором количестве клиентов можете столкнуться с проблемой постоянных дисконнектов PPPoE соединения.

 

 

[NewUse]

чё парится?, выставляете на клиентах нужную полосу с помощью ГУИшного шепера.

[xphoenix]

чё парится?, выставляете на клиентах нужную полосу с помощью ГУИшного шепера.

в смысле в самих клиентских устройствах ?

 

При некотором количестве клиентов можете столкнуться с проблемой постоянных дисконнектов PPPoE соединения.

некотором это сколько??

 

общий канал |b|Vlan1---shape1---абонент1

------------|r|Vlan2---shape2---абонент2

------------|i|Vlan3---shape3---абонент3

------------|d|Vlan4---shape4---абонент4

------------|g|Vlan5---shape5---абонент5

------------|e|Vlan6---shape6---абонент6

 

вот и вся логика -- абонентам в радиоканале отдавать тегом вланы

тут только булет плюс кучка локо нужно, схема реализуется на булете

резать то в итоге чем?? не нашел на булите в разделе VLAN шейпера...

 

не по теме... начал выпендриваться один locom2. Радио видит, питание и лан тоже горят, но при подключении к компу не может до него достучаться, в свойствах сетевого подключения отправленные пакеты идут, а принятых нету. 1,20 не пингуется, даже если вручную прописать айпи. Пробовал подключать на 3 разных компа, на 2 блока питания, кабели разные переобжимал - результат один. Ресет не помог, теперь и радио не видит соответственно. Какие посоветуете действия по реанимированию? или сразу отправлять по гарантии?

Изменено 4 мая, 2012 пользователем xphoenix

[NewUse]

клиенты locom2 и nanobridgem2,

в них есть встроенны шейпер, им и режьте.

http://wiki.ubnt.com/AirOS_5.3#Traffic_Shaping

[alex8031]

Ситуация следующая - стоит АП bullet 2hp, клиенты locom2 и nanobridgem2, ранее раздачей инета занимался rb750 за булитом, теперь необходимо прокидывать бриджем всех клиентов на роутер провайдера (его условия), авторизация pppoe, динамический реальный адрес. Проблема в том что провайдер не дает нужные нам тарифы, минимальный у них 8мбит, а летом будет 14, кидать такой трафик на клиентов мягко говоря не целесообразно... Вопрос: чем в данной ситуации резать скорость? МТ умеет резать бридж? или вообще убрать из цепочки микротик, кидать напрямую с булита и резать на клиентских точках Incoming Traffic Limit (пароли от них только у меня)? Но не получится ли тогда что от АП до клиента будет идти весь канал 8 мбит, а резаться будет только сам лан порт? Эфиру тогда крышка?

 

А вот эта железка не поможет?

http://zyxel.ru/kb/2179

[roysbike]

клиенты locom2 и nanobridgem2,

в них есть встроенны шейпер, им и режьте.

http://wiki.ubnt.com/AirOS_5.3#Traffic_Shaping

Верно и еще отключите на ubnt кнопку ресет, чтобы клиент не выствил себе шейпер больше.

[xphoenix]

вариант с шейпером прямо на клиенте конечно прост, но как я смогу потом удаленно попадать на клиентскую точку? Раньше у меня были внутренние статические айпи на которые я попадал через переадресацию с МТ, к тому же на АП в графе last ip у всех почему-то unknown. Видимо потому что у самой АП статикой на бридже стоит, а клиенты pppoe, как добиться того чтобы ап отображала айпи который получит клиент залогинившись у провайдера?

Изменено 6 мая, 2012 пользователем xphoenix

[Megas]

xphoenix, я не пойму что у вас там твориться, но честно смахивает на какое-то садо мазо с pppoe по wifi, может проще отказаться от тунелей и перевести все клиентские порты в свои vlan? а дальше отдавать на сервере пару ip в каждый из vlan и все, головняк закончился)

[NewUse]

вариант с шейпером прямо на клиенте конечно прост, но как я смогу потом удаленно попадать на клиентскую точку? Раньше у меня были внутренние статические айпи на которые я попадал через переадресацию с МТ, к тому же на АП в графе last ip у всех почему-то unknown. Видимо потому что у самой АП статикой на бридже стоит, а клиенты pppoe, как добиться того чтобы ап отображала айпи который получит клиент залогинившись у провайдера?

+1 какого хрена у Вас ПППоЕ делает?

поднимайте обычный management vlan для управления, и vlan-ы под каждого клиента.

[Saab95]

Те, кто советует влан на каждого пользователя забивать, у вас сколько баз используется?

 

Что-то мне кажется не очень удобно забивать вланы при большом количестве клиентов, если вдруг понадобится перевести клиента на другую базу, или если одна база выйдет из строя. При большом количестве пользователей туннели использовать очень удобно - тут и легкое подключение откуда угодно, легко отключать клиента - достаточно запретить ему подключаться к серверу, тогда он не сможет ничего в сеть передать.

 

 

[kosmich7]

не очень удобно забивать вланы при большом количестве клиентов, если вдруг понадобится перевести клиента на другую базу

Че мешает на всех базах поднять нужные веланы ?

 

Это не атака на старичка 95го просто ересь несеться с этих постов.

[Megas]

а накой в обще на всех базах поднимать чего?

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

Изменено 6 мая, 2012 пользователем Megas

[Saab95]

В таком случае будет куча мусора по сети гулять. Вланы надо на базе снимать, а не на клиентах.

 

Поэтому и получается что PPPoE самое простое и удобное средство.

[NewUse]

В таком случае будет куча мусора по сети гулять.

Поэтому и получается что PPPoE самое простое и удобное средство.

Не понял в чём преимущества ПППоЕ, мусора в этом случае скорее увеличется, а вот vlan-per-client на базах штука прикольная, но гемор с настройкой, если базы на юбикьюти, если на микротиках, то вроде это штатна фича?

 

Вланы надо на базе снимать, а не на клиентах.

зависит от количества клиентов, до 20 на базу -- можно не париться, QinQ, если память не зменяет что микротик, что юбикути без проблем кушают...

[Saab95]

В таком случае будет куча мусора по сети гулять.

Поэтому и получается что PPPoE самое простое и удобное средство.

Не понял в чём преимущества ПППоЕ, мусора в этом случае скорее увеличется, а вот vlan-per-client на базах штука прикольная, но гемор с настройкой, если базы на юбикьюти, если на микротиках, то вроде это штатна фича?

 

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

 

Влан на клиента на микротике делается легко, но тут надо либо авторизацию по EAP прикручивать, чтобы автоматизировать добавление вланов, либо через логи по SSH добавлять связку vlan+WDS на базы. Если забивать все руками - не удобно при переезде клиентов с базы на базу. Ну и естественно IP адреса выделять сложнее, чем через PPPoE.

 

Вланы надо на базе снимать, а не на клиентах.

зависит от количества клиентов, до 20 на базу -- можно не париться, QinQ, если память не зменяет что микротик, что юбикути без проблем кушают...

 

Можно не парится когда баз мало. А если со временем будут добавляться к основным базам локальные базы, установленные для работы в непосредственной близости с клиентами этот способ уже будет не удобный. Так же при подключении 2-3 этажных домов влан на пользователя не удобен - ведь нужно ставить какой-то управляемый коммутатор. В схеме с PPPoE можно навешать мыльниц по 300р. и менять их пачками после гроз.

[kosmich7]

у клиента нужный растегируете.

Не вариант.

 

vlan-per-client на базах штука прикольная

+1

 

В схеме с PPPoE можно навешать мыльниц по 300р. и менять их пачками после гроз.

Вот это наш человек)))

В каждом случае нужно индивидуально планировать схему построения сети, и тупые свичи в этих схемах отсутствуют.

 

И к стати даже в предложеной вами схеме тупые прекрасно пропускают тег)

А 7ка сама растегирует) если сетевая умеет)

Изменено 7 мая, 2012 пользователем kosmich7