The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Разделить асинхронный канал"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Маршрутизаторы CISCO и др. оборудование. (Public)
Изначальное сообщение [ Отслеживать ]

"Разделить асинхронный канал"  +/
Сообщение от ss777 (ok) on 01-Июл-09, 22:13 
Здравствуйте, я так понимаю, что для правильной работы QoS в целом, на интерфейсе необходимо указывать bandwidth, а как быть если канал асинхронный, например к fa интерфейсу подключен ADSL модем. В таком случае указывать к примеру для одного из клиентов 50% от bandwidth 2048kbis, где реальная скорость 2048/512 (dw/up) приведет к тому что он полностью забьет исходящий канал. Как быть в такой ситуации?
Высказать мнение | Ответить | Правка | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Разделить асинхронный канал"  +/
Сообщение от mdenisov email(ok) on 02-Июл-09, 11:42 
>Здравствуйте, я так понимаю, что для правильной работы QoS в целом, на
>интерфейсе необходимо указывать bandwidth, а как быть если канал асинхронный, например
>к fa интерфейсу подключен ADSL модем. В таком случае указывать к
>примеру для одного из клиентов 50% от bandwidth 2048kbis, где реальная
>скорость 2048/512 (dw/up) приведет к тому что он полностью забьет исходящий
>канал. Как быть в такой ситуации?

Здрасьте. Bandwidth для QoS'а нафик не нужен, он нужен для протоколов маршрутизации. Во-вторых bandwidth указывается в сторону от тебя, т. е для асинхронного канала на одной стороне ставится 2048, на другой 512.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Разделить асинхронный канал"  +/
Сообщение от ss777 (ok) on 02-Июл-09, 14:20 
>>Здравствуйте, я так понимаю, что для правильной работы QoS в целом, на
>>интерфейсе необходимо указывать bandwidth, а как быть если канал асинхронный, например
>>к fa интерфейсу подключен ADSL модем. В таком случае указывать к
>>примеру для одного из клиентов 50% от bandwidth 2048kbis, где реальная
>>скорость 2048/512 (dw/up) приведет к тому что он полностью забьет исходящий
>>канал. Как быть в такой ситуации?
>
>Здрасьте. Bandwidth для QoS'а нафик не нужен, он нужен для протоколов маршрутизации.
>Во-вторых bandwidth указывается в сторону от тебя, т. е для асинхронного
>канала на одной стороне ставится 2048, на другой 512.

Я уж понял, но тут теперь другая проблема. Суть у неё такая, есть LAN и два WAN-а, первый это int fa4 который смотрит во внутреннею сеть провайдера второй это Dialer1 доступ к интернету. Задача зарезать трафик для клиента из LAN, с IP адресом 10.10.77.3. Проблема в том что service-policy, а точнее class-map не воспринимает что у него написано в match access-group 119, и соответственно shape не работает.

!
class-map match-all class1
match access-group 119 <-- на это ему побарабану
match protocol ip
!
!
policy-map test
class class1
    shape peak 256000
!
interface FastEthernet4 <-- в сеть провайдера
ip address 192.168.х.х 255.255.255.0
ip nbar protocol-discovery
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
pppoe enable group global
pppoe-client dial-pool-number 1
service-policy output test
!
interface Vlan1
ip address 10.10.77.1 255.255.255.248
ip nat inside
ip virtual-reassembly
ip tcp adjust-mss 1452
!
access-list 119 permit ip host 10.10.77.3 any
!
!

Уже который день не могу решить проблему. :(

P.S. rate-limit по access-list тоже не работает.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Разделить асинхронный канал"  +/
Сообщение от mdenisov email(ok) on 02-Июл-09, 14:59 
>[оверквотинг удален]
> ip virtual-reassembly
> ip tcp adjust-mss 1452
>!
>access-list 119 permit ip host 10.10.77.3 any
>!
>!
>
>Уже который день не могу решить проблему. :(
>
>P.S. rate-limit по access-list тоже не работает.

Предполагаю что полиси-мэп матчится уже после того как он пронатится. Попробуйте повесить эту политику на вход интерфейса в который клиент смотрит. А еще уберите match protocol ip.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Разделить асинхронный канал"  +/
Сообщение от ss777 (ok) on 02-Июл-09, 15:22 
>[оверквотинг удален]
>>!
>>!
>>
>>Уже который день не могу решить проблему. :(
>>
>>P.S. rate-limit по access-list тоже не работает.
>
>Предполагаю что полиси-мэп матчится уже после того как он пронатится. Попробуйте повесить
>эту политику на вход интерфейса в который клиент смотрит. А еще
>уберите match protocol ip.

На vlan то повесить конечно можно, единственное, так это то, что у него ограничения по скорости на доступ к сети провайдера, и к сети интернет должны быть разные. Ну можно ещё access-list-ы для class-ов нарисовать, если трафик в инет то shape такой, если в сеть провайдера то другой и соответствующие классы со своими access-list-ми потом прописать в policy-map, но все же почему везде в примерах делается именно так сделано у меня сейчас, что для исходящего от клиента policy или rate-limit вешается на WAN, а для входящего к клиенту на его интерфейс, но у меня это почему-то не работает, точнее почему-то клиент сначала натится, а потом уже в class, который в пакетах не видит уже ни какого 10.10.77.3. Хотелось бы дойти до истины.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Разделить асинхронный канал"  +/
Сообщение от mdenisov email(ok) on 02-Июл-09, 15:26 
>[оверквотинг удален]
>сети интернет должны быть разные. Ну можно ещё access-list-ы для class-ов
>нарисовать, если трафик в инет то shape такой, если в сеть
>провайдера то другой и соответствующие классы со своими access-list-ми потом прописать
>в policy-map, но все же почему везде в примерах делается именно
>так сделано у меня сейчас, что для исходящего от клиента policy
>или rate-limit вешается на WAN, а для входящего к клиенту на
>его интерфейс, но у меня это почему-то не работает, точнее почему-то
>клиент сначала натится, а потом уже в class, который в пакетах
>не видит уже ни какого 10.10.77.3. Хотелось бы дойти до истины.
>

По идее правильнее шейпить на выходе т. к. если пакет уже пришел - ресурс в канале он уже занял. Это особенно актуально для полисинга где такой пакет дропнется и перепошлется вторично заняв канал. Если я прав по поводу очередности обработки ната и полиси - ничего не поделаешь, придется вешать на вход, ну или нат вынести на другую железку. Можно конечно поиздеваться с pbr'ами и лупбэками, но это не кошерно и будет работать в process switching.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Разделить асинхронный канал"  +/
Сообщение от ss777 (ok) on 02-Июл-09, 15:49 
>[оверквотинг удален]
>>не видит уже ни какого 10.10.77.3. Хотелось бы дойти до истины.
>>
>
>По идее правильнее шейпить на выходе т. к. если пакет уже пришел
>- ресурс в канале он уже занял. Это особенно актуально для
>полисинга где такой пакет дропнется и перепошлется вторично заняв канал. Если
>я прав по поводу очередности обработки ната и полиси - ничего
>не поделаешь, придется вешать на вход, ну или нат вынести на
>другую железку. Можно конечно поиздеваться с pbr'ами и лупбэками, но это
>не кошерно и будет работать в process switching.

Понятно, раз так значит так. Будет время, попробую разобраться что там происходит.

Спасибо.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

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




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

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