форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"QoS, priority-queue"

Сообщение от haha (??) on 24-Апр-09, 11:12

Подумалось... А не рискованно ли использовать priority-queue на коммутаторах? Поясню. Собрал схему на 3550 с двумя подключенными к ней voip телефонами и двумя серверами для генерирования трафика. Никак не мог загрузить Gi0/1(аплинк для петель) в потолок, что бы попадать под разные трелшоды. Загружал под 900-990Мбит udp/tcp трафиком. Голосу хоть бы что, качество хорошее(пускал в priority-queue). Решил поменять местами голосовой трафик и генерируемый для загрузки. Выставил на голос IPP 0, на генерируемый IPP5 и пустил его в priority-queue. Коммутатор умирал. У голоса даже сигнализация не проходила. С таким успехом можно отличные DOS атаки проводить если пускать в priority-queue. Может стоит от неё отказаться и использовать все 4 очереди с разными весами и глубиной, просто голос выделять в отдельную из них. interface GigabitEthernet0/1 description Uplik for Loops switchport trunk encapsulation dot1q switchport trunk allowed vlan 2-4,500,501,555,600-621,700,701 switchport mode trunk load-interval 30 flowcontrol send off mls qos trust dscp mls qos monitor dscp 0 8 16 24 32 40 48 56 wrr-queue bandwidth 10 30 60 1 wrr-queue queue-limit 55 30 10 5 wrr-queue random-detect max-threshold 1 70 80 wrr-queue random-detect max-threshold 2 60 80 wrr-queue random-detect max-threshold 3 80 90 wrr-queue random-detect max-threshold 4 90 95 wrr-queue cos-map 1 0 1 2 wrr-queue cos-map 2 3 4 wrr-queue cos-map 3 6 7 wrr-queue cos-map 4 5 wrr-queue dscp-map 2 1 2 3 4 5 6 7 8 wrr-queue dscp-map 2 9 10 11 12 13 14 15 16 wrr-queue dscp-map 2 17 18 19 20 21 22 23 32 wrr-queue dscp-map 2 33 34 35 36 37 38 39 40 wrr-queue dscp-map 2 41 42 43 44 45 46 47 56 wrr-queue dscp-map 2 57 58 59 60 61 62 63 priority-queue out spanning-tree bpdufilter enable end interface GigabitEthernet0/2 description Generator traffica-2 switchport access vlan 600 switchport trunk encapsulation dot1q switchport mode access load-interval 30 flowcontrol send off mls qos cos 5 mls qos cos override mls qos monitor dscp 0 8 16 24 32 46 48 56 wrr-queue bandwidth 10 30 60 1 wrr-queue queue-limit 55 30 10 5 wrr-queue random-detect max-threshold 1 50 70 wrr-queue random-detect max-threshold 2 60 80 wrr-queue random-detect max-threshold 3 80 90 wrr-queue random-detect max-threshold 4 90 95 wrr-queue cos-map 1 0 1 2 wrr-queue cos-map 2 3 4 wrr-queue cos-map 3 6 7 wrr-queue cos-map 4 5 wrr-queue dscp-map 2 1 2 3 4 5 6 7 8 wrr-queue dscp-map 2 9 10 11 12 13 14 15 16 wrr-queue dscp-map 2 17 18 19 20 21 22 23 32 wrr-queue dscp-map 2 33 34 35 36 37 38 39 40 wrr-queue dscp-map 2 41 42 43 44 45 46 47 56 wrr-queue dscp-map 2 57 58 59 60 61 62 63 priority-queue out no cdp enable spanning-tree bpdufilter enable end interface FastEthernet0/33 description VoIP-1 switchport access vlan 700 switchport trunk encapsulation dot1q switchport mode access load-interval 30 mls qos cos override mls qos monitor dscp 0 40 48 wrr-queue bandwidth 10 30 60 1 wrr-queue min-reserve 1 5 wrr-queue min-reserve 2 6 wrr-queue min-reserve 3 7 wrr-queue min-reserve 4 8 wrr-queue cos-map 1 0 1 2 wrr-queue cos-map 2 3 4 wrr-queue cos-map 3 6 7 wrr-queue cos-map 4 5 priority-queue out end interface FastEthernet0/34 description VoIP-2 switchport access vlan 701 switchport trunk encapsulation dot1q switchport mode access load-interval 30 mls qos cos override mls qos monitor dscp 0 40 48 wrr-queue bandwidth 10 30 60 1 wrr-queue min-reserve 1 5 wrr-queue min-reserve 2 6 wrr-queue min-reserve 3 7 wrr-queue min-reserve 4 8 wrr-queue cos-map 1 0 1 2 wrr-queue cos-map 2 3 4 wrr-queue cos-map 3 6 7 wrr-queue cos-map 4 5 priority-queue out end

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

Сообщения по теме

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

1. "QoS, priority-queue"

Сообщение от Luxor (??) on 24-Апр-09, 14:48

>[оверквотинг удален] > wrr-queue min-reserve 1 5 > wrr-queue min-reserve 2 6 > wrr-queue min-reserve 3 7 > wrr-queue min-reserve 4 8 > wrr-queue cos-map 1 0 1 2 > wrr-queue cos-map 2 3 4 > wrr-queue cos-map 3 6 7 > wrr-queue cos-map 4 5 > priority-queue out >end Конечно рисковано использовать priority-queue точно не убедившись что эта технология необходима. Ни в одной книжке cisco задевающую вопросы качества обслуживания не видел чтобы голосовой трафик засовывали в priority-queue, для него достаточно отдельной очереди. Если возвращаться к вопросу использования технологии priority-queue то в этой очереди должен обслуживаться трафик жизненонеобходимый для работы сети - например данные таблиц маршрутов протоколов динамической маршрутизации (RIP, OSPF и т.д.), ничего лишнего в этой очереди быть не должно.

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

	2. "QoS, priority-queue"
	Сообщение от haha (??) on 24-Апр-09, 16:22
	>Конечно рисковано использовать priority-queue точно не убедившись что эта технология необходима. Ни >в одной книжке cisco задевающую вопросы качества обслуживания не видел чтобы >голосовой трафик засовывали в priority-queue, для него достаточно отдельной очереди. Если >возвращаться к вопросу использования технологии priority-queue то в этой очереди должен >обслуживаться трафик жизненонеобходимый для работы сети - например данные таблиц маршрутов >протоколов динамической маршрутизации (RIP, OSPF и т.д.), ничего лишнего в этой >очереди быть не должно. Даже если использовать её под протоколы динамической маршрутизации, сеть управления устройствами, не суть под что, появляется большая опасность получить кувалдой по голове от злоумышленника во время простенького DOS`а, если он будет знать как маркировать трафик DOS`а для помещения в priority очередь. Что-то чем больше провожу тестов и анализирую полученные результаты, тем больше задумываюсь о зле priority-queue. А Вы сами её используете исключительно под жизненно-необходимые для сети сервисы или отказались от неё? А по поводу книжек и VoIP трафика в priority очередь, auto-qos сделайте сами на интерфейсе и посмотрите что получите, будете удивлены.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "QoS, priority-queue"
	Сообщение от Luxor (??) on 24-Апр-09, 18:28
	>[оверквотинг удален] >Даже если использовать её под протоколы динамической маршрутизации, сеть управления устройствами, не >суть под что, появляется большая опасность получить кувалдой по голове от >злоумышленника во время простенького DOS`а, если он будет знать как маркировать >трафик DOS`а для помещения в priority очередь. Что-то чем больше провожу >тестов и анализирую полученные результаты, тем больше задумываюсь о зле priority-queue. >А Вы сами её используете исключительно под жизненно-необходимые для сети сервисы >или отказались от неё? > >А по поводу книжек и VoIP трафика в priority очередь, auto-qos сделайте >сами на интерфейсе и посмотрите что получите, будете удивлены. priority-queue это не зло, это всего лишь инструмент который можно применить для решения задач. Не понимаю, почему вы боитесь, что злоумышленник будет маркировать трафик и он (трафик) попадет не в ту очередь, ведь Вы весь трафик будете перемаркировывать на своих распределительных узлах, если только на интерфейсах не будет установлен параметр верить значениям полей качества обслуживания (у ИОС эта команд mls qos trust dscp/ip-precedence/cos), ну а верить выставленных значений полей dscp/ip-precedence/cos из клиентских сетей вообще нельзя. Если у вас все сделано по человечески, то все управляемое оборудование выделенно в отдельную комутируемую сеть, соответсвенно злоумышленик может появится только в точках где есть доступ в административную сеть, а это серверные, рабочие места некоторых сотрудников и узлы связи. Вряд ли найдется злоумышленник который взломает замки, заберется в серверную и первым делом начнет искать где подлючиться в административную сеть, а далее снифать административный трафик и генерировать левый трафик который бы гасил распределительные узлы, думаю он скорее свиснет оборудование, ну или какую-нибудь важную информацию скопирует))) Я раньше использовал priority-queue, в эту очередь я выделил трафик протокола  RIP между маршрутизаторами и трафик telnet и ssh внутри своих управляющих и административной сетей и между ними еще, чтобы управлять было комфортней) сейчас они просто болтаются в отдельной очереди.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "QoS, priority-queue"
	Сообщение от haha (??) on 26-Апр-09, 10:39
	>[оверквотинг удален] >доступ в административную сеть, а это серверные, рабочие места некоторых сотрудников >и узлы связи. Вряд ли найдется злоумышленник который взломает замки, заберется >в серверную и первым делом начнет искать где подлючиться в административную >сеть, а далее снифать административный трафик и генерировать левый трафик который >бы гасил распределительные узлы, думаю он скорее свиснет оборудование, ну или >какую-нибудь важную информацию скопирует))) >Я раньше использовал priority-queue, в эту очередь я выделил трафик протокола   >RIP между маршрутизаторами и трафик telnet и ssh внутри своих управляющих >и административной сетей и между ними еще, чтобы управлять было комфортней) >сейчас они просто болтаются в отдельной очереди. Так оно и есть, подключающимся не верю, если им не предоставляется SLA согласно договору. Перемаркировываю/сбрасываю всех непонятных в 0, подключаю всех к untrusted портам. Боюсь не то что попадут на узлы и украдут что-то, а то что шнурок вытащеный с порта с предоставлением SLA может стать большой угрозой всей сети. Каждый умник запрашивающий SLA, уже априори является злоумышленником, потому что он знает что он делает :) Нет это не фобия и не параноя, ну если только чуть-чуть :) Получается, необходимо либо принудительно сбрасывать его приоритеты на порту при достижении определенной скорости/процента_загрузки от покупаемого канала и "смело" использовать priority-queue на аплинк портах, либо вообще отказаться от priority-queue. Но если за каждым портом так тщательно следить, а портов таких сотни или тысячи, то как быть с распространением политик QoS по всей сети. Ручаная работа довольно кропотлива на большом количестве устройств. Вы чем нибудь пользуетесь аля Qos Pollicy Manager для распространения QoS политик?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "QoS, priority-queue"
	Сообщение от Luxor (??) on 27-Апр-09, 12:32
	>[оверквотинг удален] >это не фобия и не параноя, ну если только чуть-чуть :) > >Получается, необходимо либо принудительно сбрасывать его приоритеты на порту при достижении определенной >скорости/процента_загрузки от покупаемого канала и "смело" использовать priority-queue на аплинк портах, >либо вообще отказаться от priority-queue. > >Но если за каждым портом так тщательно следить, а портов таких сотни >или тысячи, то как быть с распространением политик QoS по всей >сети. Ручаная работа довольно кропотлива на большом количестве устройств. Вы чем >нибудь пользуетесь аля Qos Pollicy Manager для распространения QoS политик? Qos Pollicy Manager не использую так у меня всего лишь два распределительных узла, хотя было бы интересно поюзать) SLA не предоставляем ввиду невостребованности его на нашем провинциальном рынке )) Я бы на Вашем месте не стал зацикливаться так на такой мелочи как механизм priority-queue (у вас определенно все хорошо в сети раз вы начали такие косточки перемалывать), просто используйте технологию исходя из здравого смысла и из опыта, главное помнить - если будет хоть малейший шанс, что клиент может в вашей сети что-то испортить, это обязательно произойдет (рано или поздно) )) Я бы вообще не стал использовать priority-queue для обслуживания клиентского трафика, максимум сервисный трафик и то можно обойтись) если эта штука будет действительно необходима вы сразу это почувтсвуете)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]