The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Ограничение входящего трафика на Cisco (cisco shaper limit traffic )


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: cisco, shaper, limit, traffic,  (найти похожие документы)
Date: Tue, 15 Oct 2002 11:15:40 +0600 From: "Vasiliy A. Belov" <vab@rtcomm.ru> Newsgroups: ftn.ru.cisco Subject: Ограничение входящего трафика на Cisco >> Коллеги, правильно ли я понял, что теперь стало возможно шейпить входящий >> трафик (при помощи service-policy)? > Hет. Приведите цитату с CCO, откуда вы сделали такой вывод ? Поскольку вопрос скорее всего вызван моим письмом, то принимаю огонь на себя... ;) Еще раз: допустим я делаю все на Serial-е - двушке, пишу acl для неважного трафика и скажу так (пусть будет в терминах CAR, вариант конфига с классами был в предыдущем письме) - interface Serial X/Y rate-limit input access-group LOWPRIORITY 1500000 281250 281250 conform-action transmit exceed-action drop IMHO дропанье пакетов низкоприоритетного трафика при скоростях его выше чем 1.5Mb/s вызовет падение скоростей "тяжелых" tcp сессий и немного разгрузит входящий канал в т.ч. и для критичных приложений. Я ошибаюсь? Просто никогда особо не надо было, т.к. можно с другой стороны на out policy сделать, но для "клиентов" это м.б. интересно и весьма. Василий Белов, vab@rtcomm.ru P.S. Т.е. мой ответ "шейпить" в широком смысле этого слова на входе - можно. "Широкий смысл" шейпинга - policing.
From: "Vasiliy A. Belov" <vab@rtcomm.ru> > Hет, я спрашивал не про rate-limit, а именно и конкретно про shaping. > Что будет, если сделать так: > int Serial 0/0 > service-policy input TEST > policy-map TEST > class TEST > shape average 16000 Так работать не будет. С чего бы ему. Рекомендую попробовать все то же rate-limit input access-group acl_for_TEST --сколько нужно-- exceed-action drop
From: "Denis V. Schapov" <dschapov@dsi.ru> > В описании "Modular Quality of Service Command-Line Interface" > не сказано обратное. Данный документ создает впечатление, что > произвольную service policy можно приложить как на input, так и на > output. Hи о каких ограничениях речи нет. > Меня это, признаюсь, удивило и я решил уточнить в конференции. Да, в документации на CCO есть неосвещенные моменты, которые можно трактовать неоднозначно. Hа самом деле, все QoS фичи, имеющие отношение к queueing (GTS, CBWFQ, LLQ, RED и т.д.), работают только на output.

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

Обсуждение [ RSS ]
  • 1, Kirill M. (?), 08:41, 21/08/2003 [ответить]  
  • +/
    Всем привет, обращаяс к последнему оратору,
    хотел бы спросить, где можно подробно
    почитать"Modular Quality of Service Command-Line Interface", заранее благодарен
     
  • 2, HannibalUT (?), 14:39, 11/01/2004 [ответить]  
  • +/
    >> Коллеги, правильно ли я понял, что теперь стало возможно шейпить входящий
    >> трафик (при помощи service-policy)?

    Не нужно путать "Congestion Managment" с "Shaping".
    Service-policy используется при CBWFG, LLQ, QoS - а это управление траффиком в период загрузок канала до 100Если канал не перегружен - то вышеуказзанные Queueing Algorithms просто не работают (все это Congestion Management).
    Совсем другое дело Shaping, при котором просто не допускаются перегрузка канала определенными типами траффика - так работают GTS, CAR!!!

     
  • 3, Тимур (?), 06:19, 23/04/2007 [ответить]  
  • +/
    На входящий траффик, половина буфферов interface_а не ютилизированны роутером, поэтому Shaping не может работать эффективно, хотя конфигурация позволяет его настроить. Единственная реально-работающий метод это в тупую резать Window size Rate-limit_ом привязанным к Extended ACL_у.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру