dignity Опубликовано 3 апреля, 2011 (изменено) Добрый день. Представим, что есть два канала: 1. узкий но с высоким качеством round-trip/jitter 2. широкий с best-effort Хотелось бы на основе значения DSCP, выкидывать трафик или в 1 или в 2 с выставлением Next-Hop. Что-то в духе route-map только по DSCP. Есть такая штука в Cisco, а конкретно в 6500 Sup2? PS. Вполне может быть что я не с той стороны к проблеме подхожу, поэтому вкратце опишу что хочу. Хочу чтобы у клиента полоса, скажем 5Мбит функционировала следующим образом: до 1Мбит все шло в узкий канал, а весь овер 1Мбит в обычный. access-list 101 permit ip any any dscp af22 route-map rm-af22 permit 10 match ip address 101 set ip next-hop 10.10.10.10 ! Так будет работать, как считаете? Спасибо. Изменено 3 апреля, 2011 пользователем dignity Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alexandr Ovcharenko Опубликовано 3 апреля, 2011 Хочу чтобы у клиента полоса, скажем 5Мбит функционировала следующим образом: до 1Мбит все шло в узкий канал, а весь овер 1Мбит в обычный. А каким боком тут dscp? Если например воип-трафик превысит 1Мбит, то часть его пакетов должна выкинуться в худший канал, или согласно dscp-policy они всеже должны толкаться в узкий но хороший канал? Как-то неопределенно... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dignity Опубликовано 3 апреля, 2011 (изменено) Хочу чтобы у клиента полоса, скажем 5Мбит функционировала следующим образом: до 1Мбит все шло в узкий канал, а весь овер 1Мбит в обычный. А каким боком тут dscp? Если например воип-трафик превысит 1Мбит, то часть его пакетов должна выкинуться в худший канал, или согласно dscp-policy они всеже должны толкаться в узкий но хороший канал? Как-то неопределенно... Если не влезет, то да, именно так и должно быть. Абонент будет знать о таком поведении. Суммарно это выглядит так: первоначально весь трафик идет как приоритетный (для упрощения), проходя через полисер весь лишний помечается как best effort. В общем, идея должна заключаться в том, что пока абонент в приоритетном канале, ему должно быть нормально (хорошо), например, игровой трафик не занимает большую полосу или VoIP. Как только происходит переполнение (то есть абонент начал пользоваться HTTP, торренты), другими словами, перестал контроллировать свою полосу (стал стремиться к максимальной утилизации), трафик должен утилизировать два канала. По сути, без разницы как происходит маркировка и перемаркировка, идея в том чтобы все что не входит в премиум-полосу попадало в best-effort. Изменено 3 апреля, 2011 пользователем dignity Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 3 апреля, 2011 (изменено) Как-то так: На входящий интерфейс вешаем rate-limit в котором в качестве действия указываем mark ip access-list standard any-traf permit any class-map match-all ANY-TRAF match access-group name any-traf ! ! policy-map test class ANY-TRAF police 1000000 80000 conform-action set-dscp-transmit af22 exceed-action set-dscp-transmit default на исходящий access-list 101 permit ip any any dscp af22 route-map DSCP-POL permit 10 match ip address 101 set ip default next-hop AA.AA.AA.AA Хотя, учитывая, что все это отрабатывается аппаратно, я-бы во входящей политике раскрасил трафик как-то попестрее, чем в два цвета. Типа, ВоИП, ДНС, Игрушка - в первый канал, остальное - во второй. Изменено 3 апреля, 2011 пользователем sol Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dignity Опубликовано 3 апреля, 2011 Спасибо. Сейчас просто вырабатываю модель на уровне proof-of-concept) потому как на другой стороне канала тоже придется красить и раскидывать и т.п. стараюсь пока не усложнять Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...