Привествую всех, сразу отмечу, что перерыл фактические все листы по теме Cisco, но так и не нашел то что искал.Предыстория:
Есть Cisco 2811, к ней подключены Вася и Петя(через Саб-интерфейсы). Каждый из них имеет сеть белых ип адресов по префексу /29.Один ип в каждой сети занимает моя 2811 и соотвественно являеться шлюзом, как для Васи, так и для Пети.Для 'нарезки' скорости используеться CBWFQ.
Из-за экономики. Вася и Петя на двоих делят 10 Mbit\s.
Вопрос:
Как сделать так, что бы когда Вася не работает Петя мог брать все 10 Mbit\s и наоборот. А когда появляеться Петя или Вася, канал делился 50% на 50%, между Петей и Васей ?Заранее всем спасибо.
Копаю этот вопрос долго, может и ленивый, ежели поможете, вечный огонь вам :-)
Если задачу нужно решить только маршрутизатором, то сразу вопрос:
Как железка узнает что Вася или Петя _не_работают_ ?
>Если задачу нужно решить только маршрутизатором, то сразу вопрос:
>Как железка узнает что Вася или Петя _не_работают_ ?Зачем знать?
Нужно QoS настроить, только я незнаю как циско его настраивать...
Думаю Старшие товарищи подскажут ;)
>>Если задачу нужно решить только маршрутизатором, то сразу вопрос:
>>Как железка узнает что Вася или Петя _не_работают_ ?
>
>Зачем знать?
>Нужно QoS настроить, только я незнаю как циско его настраивать...
>Думаю Старшие товарищи подскажут ;)Вот и я не знаю.
Уж кому не знать как cisco, есть ли Вася в сети или его нет. Да и вопрос то не правильный. Качает Вася или Петя что либо вот в чем прикол..... а cisco узнать это не проблема....
>Уж кому не знать как cisco, есть ли Вася в сети или
>его нет.Ребят еще раз. Раутер не знает ни про васю не про петю. Он знает про сети и про пакеты. когда вы добавляете туда кос (суть дополнительные правила обработки этих пакетов), для маршрутизатора ничего не меняется.
Повторю еще раз если мы ограничены одним маршрутизатором мы можем сделать:
10 мегабит на двоих с fair queue & random-detect, но это не точное разделение.
по 5 мегабит на брата с таким же раскладом, но тогда нельзя будет делать превышение.Вешаем мапу на входе в маршрутизатор, нужное количество трафика для каждого джигита маркируем одним "цветом" превышение другим. На выходе соответственно нужное количество пропускаем по одному правилу, а все остальное по другому, в таком раскладе будет всем сестрам по серьгам и возможно превышение, а вот впишется это в ваш дизайн смотрите.
Есть еще четвертый вариант когда у вас есть радиус и биллинг, тогда мы может точно знать кто работает, а кто нет и тогда у нас появляется математический аппарат для руления этим делом.
>Ребят еще раз.Прошу прощения за цыганский акцент и грамматику.
>>Ребят еще раз.
>
>Прошу прощения за цыганский акцент и грамматику.Да нет, оочень даже ничего. По логике понятно, а есть ли возможность расписать как и что ?
>>>Ребят еще раз.
>>Прошу прощения за цыганский акцент и грамматику.
>Да нет, оочень даже ничего. По логике понятно, а есть ли возможность
>расписать как и что ?Извини, некогда.
Может у кого побольше времени распишет.
>>>Ребят еще раз.
>>
>>Прошу прощения за цыганский акцент и грамматику.
>
>Да нет, оочень даже ничего. По логике понятно, а есть ли возможность
>расписать как и что ?Вот мой вариант:
class-map match-all Vasya
match access-group Vasya
class-map match-all Petya
match access-group Petya
class-map match-all All
match anypolicy-map Shape
class Vasya
bandwidth percent 37
class Petya
bandwidth percent 37
class class-default
fair-queue
random-detect
policy-map All
class All
shape average 10000000
service-policy Shapeinterface fa1
service-policy output All
access-list Vasya permit ip any <сеть Васи>
access-list Petya permit ip any <сеть Пети>Смысл этой настройки такой. На интерфейс вешается шейпинг на 10 мегабит. А внутри этого шейпинга работает QoS, которому приказано полосу делить поровну между Васей и Петей.
Теоретически вместо чисел 37 в строке bandwidth percent могут быть и меньшие равные числа, например по 20.
Fa1 - это ваш внутренний физический интерфейс, на котром существуют два подынтерфейса для Васи и Пети.
Данная схема будет работать только с тарфиком, который идёт от вашей циски в сети Васи и Пети.
Прошу понимать, что это только набросок, поэтому в конфигурации могут быть неточности. В общем пробуйте и проверяйте, как работает, командой show policy-map interface.
>[оверквотинг удален]
>Васей и Петей.
>Теоретически вместо чисел 37 в строке bandwidth percent могут быть и меньшие
>равные числа, например по 20.
>Fa1 - это ваш внутренний физический интерфейс, на котром существуют два подынтерфейса
>для Васи и Пети.
>Данная схема будет работать только с тарфиком, который идёт от вашей циски
>в сети Васи и Пети.
>Прошу понимать, что это только набросок, поэтому в конфигурации могут быть неточности.
>В общем пробуйте и проверяйте, как работает, командой show policy-map interface.
>Вот это человек и получает ВЕЧНЫЙ ОГОНЬ!:-)
огромное спасибо vnn. Ценно.
Если есть возможность поясни плх, каким образом система будет работать. ,Т.е. Вася 37% не выкушивает, а скажем всего 10%,то сможет ли Петя есть свои законные 37% + 27 % Васи ?
>Вот это человек и получает ВЕЧНЫЙ ОГОНЬ!:-)
>
>огромное спасибо vnn. Ценно.
>
>Если есть возможность поясни плх, каким образом система будет работать. ,Т.е. Вася
>37% не выкушивает, а скажем всего 10%,то сможет ли Петя есть
>свои законные 37% + 27 % Васи ?Значит если прописать bandwidth percent для разных классов трафика, как и сделано в моём примере, то циска будет применять Class-based Weighted Fair Queueing (CBWFQ). Это значит, что весь трафик, который хочет уйти с определённого интерфейса будет делиться на классы. В данном случае на 3 класса - трафик Пети, трафик Васи и ВСЁ ОСТАЛЬНОЕ. И трафик из разных классов будет слаться по очереди, но пропорционально прописанному проценту в команде Bandwith percent. То есть если например прописать по 20% для классов Vasya и Petya, то из буфера будут отправлять сначала 2 пакета (условно), относящиеся к классу Vasya, потом 2 пакета из класса Petya, потом 6 пакетов из остального трафика, потом заново по кругу. Естественно, если до определённого класса дошла очередь, а в буфере нет пакетов из данного класса, то будут немедленно отправляться пакеты из следующего по очереди класса. В нашем случае для Васи и Пети можно прописать хоть по 37, хоть по 2%, потому что мы не ожидаем какого-то ещё трафика на интерфейсе, с которым им придётся конкурировать. Почему в примере я написал 37%, потому что сумма 74% близка к максимально возможным 75%, которые вы можете прописать. Если попытаться прописать больше, то циска начнёт ругаться и не даст сделать такую конфигурацию. То есть 25% всегда должно оставаться для class-default в расчёте на ARP, STP, протоколы маршрутизации и прочий служебный трафик.
Итак, что у нас будет. Если и Вася, и Петя будут слать трафика с избытком, то в рамках 10 мегабит их пакеты будут отправляться в равном количестве, так как их классам мы задали равные веса. А что значит равное количество пакетов за одинаковое время - это значит одинаковую скорость передачи данных. То есть в случае полной загрузки Вася и Петя получат по 5 мегабит. При этом пакеты я условно считаю равной длины. Так как естественно на самом деле в расчёт принимается количество трафика а не число пакетов.
Если кто-то будет слать данные со скоростью меньше, чем в 5 мегабит, то в какой-то момент времени его очередь опустеет и будут слаться пакеты из другой очереди, если конечно в буфере будут пакеты, принадлежащие другому классу. Это даст товарищу скорость больше, чем 5 мегабит.
Вопроса о том, каким образом будет поддерживаться общая скорость не превышающая 10 мегабит я не касался, поскольку в деталях этого процесса уже не помню :). Ещё в этом всём деле есть важный процесс отбрасывания пакетов при перегрузке интерфейса. Его я тоже не касался.
Спасибо, в целом понятно.Дабы в целом не дать васе и пете выкушивать более 10 Мбит\с, стоит в родительском классе, прописать шэйпер на 10 мегобит\с + покрутить буфер для класа, что касаеться Петеных и Васиных настрое, то в полне достаточно указать те самые bandwidth percent
>Спасибо, в целом понятно.
>
>Дабы в целом не дать васе и пете выкушивать более 10 Мбит\с,
>стоит в родительском классе, прописать шэйпер на 10 мегобит\с + покрутить
>буфер для класа, что касаеться Петеных и Васиных настрое, то в
>полне достаточно указать те самые bandwidth percentПродолжу...
Т.е.
Если правильнопонимаю ТО:class-map match-all Vasya
match access-group Vasya
class-map match-all Petya
match access-group Petya
class-map match-all All
match anypolicy-map Shape
class Vasya
bandwidth percent 37
class Petya
bandwidth percent 37
class class-default
fair-queue
random-detect
policy-map All
class All
shape average 10000000
service-policy Shapeinterface fa1
service-policy output All
access-list Vasya permit ip any <сеть Васи>
access-list Petya permit ip any <сеть Пети>То есть именно в Родительском policy-map All и задаеться основная поласа пропускания. Которая делиться - bandwidth percent 37, на равную полосу для Пети и для Васи.
Хотел бы услышать ваше мнение по поводу моего высказывания, так сказать подытожить правильности хода моих мыслей, уважаемый VVN.
>interface fa1
> service-policy output All
>access-list Vasya permit ip any <сеть Васи>
>access-list Petya permit ip any <сеть Пети>2 VVN
Красивое решение, я про каскадирование поленился писать :).
Топик стартер бы еще проверил что оно действительно работает.2 Baronzz
Аксес листы лучше разные.
(1 для васи, 2 для пети, 3 для всего).
Связано с внутренними механизмами работы софта.
>[оверквотинг удален]
>>access-list Petya permit ip any <сеть Пети>
>
>2 VVN
>Красивое решение, я про каскадирование поленился писать :).
>Топик стартер бы еще проверил что оно действительно работает.
>
>2 Baronzz
>Аксес листы лучше разные.
>(1 для васи, 2 для пети, 3 для всего).
>Связано с внутренними механизмами работы софта.А если привязываться не к аксес листам а интерфейсу Пети Васи в класс карте ?
>[оверквотинг удален]
>>Красивое решение, я про каскадирование поленился писать :).
>>Топик стартер бы еще проверил что оно действительно работает.
>>
>>2 Baronzz
>>Аксес листы лучше разные.
>>(1 для васи, 2 для пети, 3 для всего).
>>Связано с внутренними механизмами работы софта.
>
>А если привязываться не к аксес листам а интерфейсу Пети Васи в
>класс карте ?Ладно, понял, буду пробовать )!
О результатах отпишусь )!
>2 Baronzz
>Аксес листы лучше разные.
>(1 для васи, 2 для пети, 3 для всего).
>Связано с внутренними механизмами работы софта.Здесь имеется ввиду первый, второй, третий.
а если попробовать что то типаinterface FastEthernet0/0.2 (саб Пети и Васи)
traffic-shape group group_Vasya 5000000 7936 7936 1000
traffic-shape group group_Piter 5000000 7936 7936 1000
в листах:
access-list group_Vasya permit ip any net_Vasya
access-list group_Piter permit ip any net_Piterпросто шейпить скорости Пети и Васи.. ?
>[оверквотинг удален]
>
>traffic-shape group group_Vasya 5000000 7936 7936 1000
>traffic-shape group group_Piter 5000000 7936 7936 1000
>
>
>в листах:
>access-list group_Vasya permit ip any net_Vasya
>access-list group_Piter permit ip any net_Piter
>
>просто шейпить скорости Пети и Васи.. ?На сколькоя понимаю, в этом случае Вася сможет качат со скоростью не более чем 5 мегобит, даже если Петя не качает ни чего!
>[оверквотинг удален]
>>
>>в листах:
>>access-list group_Vasya permit ip any net_Vasya
>>access-list group_Piter permit ip any net_Piter
>>
>>просто шейпить скорости Пети и Васи.. ?
>
>На сколькоя понимаю, в этом случае Вася сможет качат со скоростью не
>более чем 5 мегобит, даже если Петя не качает ни чего!
>а разве задача не такая была??
во втором варианте тогда,
на интерфейсе:
traffic-shape group group_Frends 10000000 7936 7936 1000access-list group_Frends permit ip any net_Vasya
access-list group_Frends permit ip any net_Piterтак они будут делить между собой канал ,
у меня так шейпер на симантек настроен.
будет работать bandwidth на inter fastEthernet
>[оверквотинг удален]
>>
>
>а разве задача не такая была??
>
>во втором варианте тогда,
>
>
>на интерфейсе:
>traffic-shape group group_Frends 10000000 7936 7936 1000
>Задача была не разделить поравну, а разделить поравну и при условие того что Вася нефига не качает, дать Пете, использовать полусу пропускания Васи.
>
>
>access-list group_Frends permit ip any net_Vasya
>access-list group_Frends permit ip any net_Piter
>
>так они будут делить между собой канал ,
> у меня так шейпер на симантек настроен.
вы хотите сказать что так не будет работать???
попробуйте.в том то и дело что подсети Васи и Пети будут принадлежать ОДНОМУ access листу group_Frends, и шейпиться будет ,этот же,лист traffic-shape group group_Frends
пусть топик стартер отпишется получилось или нет.
> вы хотите сказать что так не будет работать???
>попробуйте.
>
>в том то и дело что подсети Васи и Пети будут принадлежать
>ОДНОМУ access листу group_Frends, и шейпиться будет ,этот же,лист traffic-shape
>group group_Frends
>
>пусть топик стартер отпишется получилось или нет.В том то и дело, что И у Пети и у Васи разные сабы.
ждём отчета о проделоной работе