Re: Vopros po trafficu

Отправлено: AE on April 16, 2000 at 18:49:35:

В ответ на: Re: Vopros po trafficu posted by LK on April 15, 2000 at 23:09:30:

Лёня, к сожалению, ты несколько заблуждаешься, пакетики "совсем сбрасывает" несколько иной механим, а traffic-shape их просто "задерживает" (даже sh traf s честно пишет, что ону delayed, а про дропы пишут в queue), если их много, то queue начинает их drop'ать, но делает он это как прописано в настройках, однако, сейчас многие пользуют rate-limit, который существенно эффективнее и делает то, что ему прописано в exeed-action.

Касаемо исходной картинки (когда-то у нас были подобные проблемы). Да в самом деле, traffic-shape нужно ставить у uplink провайдера с одной стороны, другой стороны, если Вы почитаете как работает IP, точнее потоковые его протоколы и принятые соглашения по управлению потоками, то увидите, что скорость у приложений будет падать сама, если просто дропать пакетики и снижать её будет отправитель (такая вот замечательная технология IP ;-) так что по сути нет разницы где drop'ать пакетики, важно их именно дропать и по приложениям, то есть по каждому приложению.

Есть ещё одна проблема, которая сводит смысл generic traffic shape к нулю - учёт трафика, ибо, если провайдер считает байты, то drop'нутые на выходном интерфейсе он тоже посчитает как переданные (это логично, он то их уже получил). Соответсвенно, единственное эффективное решение - жестокие drop'ы на клиентсоки интерфейсе, которые можно организовать через rate-limit или traffic-shape + RED и маленький буфер. Такие вот беды... в принципе всё это очень подробно описано в документации от Cisco и глобальные мысли там очень правильные (что так делать не надо, а надо настривать QoS и приоритеты и давить трафик по приложениям, а потом уже по получателям).

----
АЕ

> Если я не ошибаюсь, то при настроенном traffic-shape Cisco просто отбрасывает те пакетики, которые не укладываются в ограничение по полосе. Так что никто у вас там не толпится, дожидаясь своей очереди. Иное дело, что они уже прошли через интерфейс провайдера, на котором он меряет ваш трафик (и пройдут еще раз, поскольку не дошли до адресата).

> > Ne podskajite li sleduyushee

> > U menia skajem kanal na 128K u upstream providera

> > tak kak moyi usera slishkom mnogo kachayut ya reshil stavit u sebia na
> > cisce traffic-shape rate 64 po no4am chto bi hot kak to ograni4it traffic
> > teper prishla misl chto traffic to nado ograni4ivat uje u upstream providera
> > tak kak tak skazat uje skachannie userami megabayti (uje proydia cherez
> > ciscu upstream providera) prosto tolpiatsa dojidayas svoey o4eredi u menia na portu
> > i.e. esli ya postavlyu u sebia na cisce traffic shape 64 po no4am
> > arenduya kanal na 128 to viigrayu li ya po trafiku (ili nado stavit u upstream providera shape?)

Отклики:

Написать ответ

Ваше имя:
E-Mail:

Тема:

Ваше сообщение:
> Лёня, к сожалению, ты несколько заблуждаешься, пакетики "совсем сбрасывает" несколько иной механим, а traffic-shape их просто "задерживает" (даже sh traf s честно пишет, что ону delayed, а про дропы пишут в queue), если их много, то queue начинает их drop'ать, но делает он это как прописано в настройках, однако, сейчас многие пользуют rate-limit, который существенно эффективнее и делает то, что ему прописано в exeed-action. > Касаемо исходной картинки (когда-то у нас были подобные проблемы). Да в самом деле, traffic-shape нужно ставить у uplink провайдера с одной стороны, другой стороны, если Вы почитаете как работает IP, точнее потоковые его протоколы и принятые соглашения по управлению потоками, то увидите, что скорость у приложений будет падать сама, если просто дропать пакетики и снижать её будет отправитель (такая вот замечательная технология IP ;-) так что по сути нет разницы где drop'ать пакетики, важно их именно дропать и по приложениям, то есть по каждому приложению. > Есть ещё одна проблема, которая сводит смысл generic traffic shape к нулю - учёт трафика, ибо, если провайдер считает байты, то drop'нутые на выходном интерфейсе он тоже посчитает как переданные (это логично, он то их уже получил). Соответсвенно, единственное эффективное решение - жестокие drop'ы на клиентсоки интерфейсе, которые можно организовать через rate-limit или traffic-shape + RED и маленький буфер. Такие вот беды... в принципе всё это очень подробно описано в документации от Cisco и глобальные мысли там очень правильные (что так делать не надо, а надо настривать QoS и приоритеты и давить трафик по приложениям, а потом уже по получателям). > ---- > АЕ > > Если я не ошибаюсь, то при настроенном traffic-shape Cisco просто отбрасывает те пакетики, которые не укладываются в ограничение по полосе. Так что никто у вас там не толпится, дожидаясь своей очереди. Иное дело, что они уже прошли через интерфейс провайдера, на котором он меряет ваш трафик (и пройдут еще раз, поскольку не дошли до адресата). > > > Ne podskajite li sleduyushee > > > U menia skajem kanal na 128K u upstream providera > > > tak kak moyi usera slishkom mnogo kachayut ya reshil stavit u sebia na > > > cisce traffic-shape rate 64 po no4am chto bi hot kak to ograni4it traffic > > > teper prishla misl chto traffic to nado ograni4ivat uje u upstream providera > > > tak kak tak skazat uje skachannie userami megabayti (uje proydia cherez > > > ciscu upstream providera) prosto tolpiatsa dojidayas svoey o4eredi u menia na portu > > > i.e. esli ya postavlyu u sebia na cisce traffic shape 64 po no4am > > > arenduya kanal na 128 to viigrayu li ya po trafiku (ili nado stavit u upstream providera shape?)

Optional Link URL:
Link Title:
Optional Image URL:

E-mail: sales@comptek.ru tel: (095) 785-2525