The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"Traffic-shape + CBWFQ ?"
Вариант для распечатки Архивированная нить - только для чтения! 
Пред. тема | След. тема 
Форумы Маршрутизаторы CISCO и др. оборудование. (Public)
Изначальное сообщение [Проследить за развитием треда]

"Traffic-shape + CBWFQ ?" 
Сообщение от sergeda emailНайти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации.(ok) on 07-Сен-04, 10:50  (MSK)
Здравствуйте. Подскажите пожалуста, как можно использовать CBWFQ для приоритезации трафика. Я так понимаю он работает только на исходящем интерфейсе. Тогда можно ли на внутреннем интерфейсе весь трафик, приходящий с внешнего, зажать traffic-shap-ингом до полосы пропускания внешнего и настроить на внутреннем интерфейсе CBWFQ? Сработает ли этот вариант?
  Рекомендовать в FAQ | Cообщить модератору | Наверх

 Оглавление

Индекс форумов | Темы | Пред. тема | След. тема
Сообщения по теме

1. "Traffic-shape + CBWFQ ?" 
Сообщение от ВОЛКА emailНайти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации. on 07-Сен-04, 10:58  (MSK)
а смысл..? оно же уже пришло...
  Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "Traffic-shape + CBWFQ ?" 
Сообщение от sergeda emailНайти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации.(ok) on 07-Сен-04, 11:12  (MSK)
>а смысл..? оно же уже пришло...

Да, но отправляющая сторона ждет подтверждения и если мы будем тормозить, то она по идее должна снижать скорость. То есть косвенно, не важный для нас трафик будет тормозиться. Или я чего-то не понимаю? Тогда возможно ли это сделать в принципе?

  Рекомендовать в FAQ | Cообщить модератору | Наверх

3. "Traffic-shape + CBWFQ ?" 
Сообщение от Beginner emailНайти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации.(??) on 07-Сен-04, 11:44  (MSK)
>>а смысл..? оно же уже пришло...
>
>Да, но отправляющая сторона ждет подтверждения и если мы будем тормозить, то
>она по идее должна снижать скорость. То есть косвенно, не важный
>для нас трафик будет тормозиться. Или я чего-то не понимаю? Тогда
>возможно ли это сделать в принципе?

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

  Рекомендовать в FAQ | Cообщить модератору | Наверх

4. "Traffic-shape + CBWFQ ?" 
Сообщение от sergeda emailНайти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации.(ok) on 07-Сен-04, 12:00  (MSK)
>>>а смысл..? оно же уже пришло...
>>
>>Да, но отправляющая сторона ждет подтверждения и если мы будем тормозить, то
>>она по идее должна снижать скорость. То есть косвенно, не важный
>>для нас трафик будет тормозиться. Или я чего-то не понимаю? Тогда
>>возможно ли это сделать в принципе?
>
>Если трафик UDP то зажимать бесполезно, если TCP, то будет влиять, но
>как сильно - зависит от многих факторов. Количество приходящего трафика легко
>может в полтора раза превышать то количество которое ты отдаешь потребителю.
>
Тоесть никак невозможно это сделать? И один пользователь закачкой сможет забивать весь канал? Зачем же тогда все эти QoS нагородили? Я же не могу провайдера просить поднимать у него CBWFQ для себя.

  Рекомендовать в FAQ | Cообщить модератору | Наверх

5. "Traffic-shape + CBWFQ ?" 
Сообщение от Beginner emailНайти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации.(??) on 08-Сен-04, 17:07  (MSK)
>Тоесть никак невозможно это сделать? И один пользователь закачкой сможет забивать весь
>канал? Зачем же тогда все эти QoS нагородили? Я же не
>могу провайдера просить поднимать у него CBWFQ для себя.

QoS нагородили для того чтобы контролировать трафик. Если организация вледеет каналом (например между офисами) QoS для него самое то.
Насчет невозможно - тоже неправильно поставлен вопрос. Возможно, но надо учесть что
1 зависимости неточные и зависят от многих факторов
2 ты будешь уничтожать уже принятые пакеты и тем самым терять уже полученный трафик
Один из вариантов - принудительное проксирование со справедливым дележем канала, но это уже совсем другая история

  Рекомендовать в FAQ | Cообщить модератору | Наверх

6. "Traffic-shape + CBWFQ ?" 
Сообщение от sergeda emailНайти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации.(ok) on 08-Сен-04, 18:31  (MSK)
>>Тоесть никак невозможно это сделать? И один пользователь закачкой сможет забивать весь
>>канал? Зачем же тогда все эти QoS нагородили? Я же не
>>могу провайдера просить поднимать у него CBWFQ для себя.
>
>QoS нагородили для того чтобы контролировать трафик. Если организация вледеет каналом (например
>между офисами) QoS для него самое то.
>Насчет невозможно - тоже неправильно поставлен вопрос. Возможно, но надо учесть что
>
>1 зависимости неточные и зависят от многих факторов
>2 ты будешь уничтожать уже принятые пакеты и тем самым терять уже
>полученный трафик
>Один из вариантов - принудительное проксирование со справедливым дележем канала, но это
>уже совсем другая история


Хорошо, если я согласен на потерю полученного трафика, как лучше это реализовать? Ну а по поводу проксирования - проблема в том что не весь трафик можно проксировать.

  Рекомендовать в FAQ | Cообщить модератору | Наверх

7. "Traffic-shape + CBWFQ ?" 
Сообщение от Beginner emailНайти другие сообщения данного автораПоместить сообщение в закладки. См. нижнее поле навигации.(??) on 09-Сен-04, 08:27  (MSK)
>>>Тоесть никак невозможно это сделать? И один пользователь закачкой сможет забивать весь
>>>канал? Зачем же тогда все эти QoS нагородили? Я же не
>>>могу провайдера просить поднимать у него CBWFQ для себя.
>>
>>QoS нагородили для того чтобы контролировать трафик. Если организация вледеет каналом (например
>>между офисами) QoS для него самое то.
>>Насчет невозможно - тоже неправильно поставлен вопрос. Возможно, но надо учесть что
>>
>>1 зависимости неточные и зависят от многих факторов
>>2 ты будешь уничтожать уже принятые пакеты и тем самым терять уже
>>полученный трафик
>>Один из вариантов - принудительное проксирование со справедливым дележем канала, но это
>>уже совсем другая история
>
>
>Хорошо, если я согласен на потерю полученного трафика, как лучше это реализовать?
>Ну а по поводу проксирования - проблема в том что не
>весь трафик можно проксировать.


Не весь, но и не весь трафик может создать значительную нагрузку (никогда не слышал чтобы пользователи зафлуживали линк ICQ сообщениями или телнетом). Если народ не балуется мультимедиа по сети, но наибольшую нагрузку создают
1. почта
2. ftp
3. www
Они проксируются вполне нормально.

  Рекомендовать в FAQ | Cообщить модератору | Наверх


Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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