[Beast]

Та-ак!!! Нук давай пройдемся по фактологии, чего мы там не читали...?

может в Сибири и Питере это в порядке вещей, но местами устройство теплых полов с присоединением их к системам отопления и/или гвс ... скажем так: хороший способ нажить себе проблемы.

 

[MrBear]

Та-ак!!! Нук давай пройдемся по фактологии, чего мы там не читали...?

может в Сибири и Питере это в порядке вещей, но местами устройство теплых полов с присоединением их к системам отопления и/или гвс ... скажем так: хороший способ нажить себе проблемы.

Ага, понятно, фактологии не будет. Тогда я тебе скажу - никакой 183-й ФЗ не запрещает включать теплый пол между вводным вентилем домохозяйства и ...канализацией. Особенно в отсутствии теплосчетчика удобно получается. :)

[evd]

Продавая 25% QoS за вдвое большие деньги можно со 100% утилизированной полосы вручить 0,75+0,25*2 = в 1,25 большие деньги

 

Задача как всунуть еще 25% трафика в канал загруженный на 100% с моей точки зрения не решается. Извини.

В условиях дефицита ресурсов любое решение повышающее доход с единицы полосы приближает точку апгрейда.

А продавая 75% полосы, без всякого QoS, но зато и без дропов, и тоже за вдвое большие деньги - можно выручить в 1.5 раза больше. Если не жадничать, забивая полосу по самое нехочу

 

И еще при этом можно сэкономить на "умных людях за настройку QoS" ;)

 

[Клава Маус]

Да, не умеют у нас еще продавцы продавать за большие деньги.

Или покупатели покупать за них не умеют.

Хоть без дропов, хоть с косом, хоть с чертом лысым. Никак не умеют.

 

"Зато мы умные", - вздыхают умные, с жалостью глядя на неумелых покупателей и продавцов, обсуждающих отопление от ГВС, охлаждение от вечной мерзлоты и питание от соседского фидера, в процессе допивания очередного литра текилы... :))

[mezonin]

Вот мне интересно , как другие умные люди до сих пор не изобрели что-нибудь наподобие FEC(forvard error correction) овер IP.

Ведь так просто, посылать сразу дублированные данные, ну и пусть теряется несколько процентов пакетов, на выходе все восстановится.

Или может есть уже?

[AlexBT]

Ага, понятно, фактологии не будет. Тогда я тебе скажу - никакой 183-й ФЗ не запрещает включать теплый пол между вводным вентилем домохозяйства и ...канализацией. Особенно в отсутствии теплосчетчика удобно получается. :)

А нафига устраивать геморрой самому себе?

Отключили горячую воду зимой на пару недель? Или понизили температуру градусов до 30?

Уж если хочется теплый пол с водным контуром, то может сделать замкнутый контур с нагревательным бачком и подпиткой от холодного водопровода?

Тем более, что и счетчик электроэнергии тоже могут отсутсвовать, у энергетиков абонентка тоже есть...

[MrBear]

Отключили горячую воду зимой на пару недель? Или понизили температуру градусов до 30?

Уж если хочется теплый пол с водным контуром, то может сделать замкнутый контур с нагревательным бачком и подпиткой от холодного водопровода?

Не поверишь, бачок у меня тоже есть, вот только горячую воду зимой отключали крайний раз уж как лет 7-8, примерно. :) И речь, как всегда, не о том, как Правильно, а о том, как делают. В разрыв ГВС отдельные отморозки тоже включают, замечу.

[evd]

Вот мне интересно , как другие умные люди до сих пор не изобрели что-нибудь наподобие FEC(forvard error correction) овер IP.

Ведь так просто, посылать сразу дублированные данные, ну и пусть теряется несколько процентов пакетов, на выходе все восстановится.

Или может есть уже?

Imho есть. Протокол tcp называется :)

Посылает дублированные данные, но не сразу, а по необходимости. Дабы не забивать полосу, порождая новые потери...

 

Избыточность могла бы быть полезна в udp-потоках imho, но и там в первую очередь борются за экономию полосы и вычислительных ресурсов одновременно...

 

[Sonne]

Здорово!

Вместо того чтобы говорить по теме, Вы с блеском доказали заведомо истинное высказование.

Да, есть такие ситуации когда Qos применим. Ну и что?

 

ЗЫ:А что Вы будете делать с входящим трафиком?

В описаной вами ситуации можно взять берст при физике в 100Mb на всех линках, чем не решение. (Вам ли не знать!)

Кроме того на больших объемах трафик ведет себя гараздо предсказуемей.

Если этот пост адресован мне, то еще раз повторю. Задача гарантированной доставки опредленного класса трафика не решается путем манипуляции с полосой если количестов портов в системе больше двух. Это голимая математика.

 

Поэтому не работает QoS у любителей запаса полосы, принципиално не может работать. Единственна сеть где это работает выглядит так:

 

Локальный порт 10Мб - (роутер A) - Магистральный канал 100М - (роутер Б) - Локальный канал 10Мбит

 

На практике такая абсурдная схема не встречается, ибо экономия идет на самом дорогом канале, которорый агрегирует трафик с большого еоличемтва выскоростных каналов. Вот этот канал забивается первым, на нем применяется QoS.

[KLM-8]

Ведь так просто, посылать сразу дублированные данные, ну и пусть теряется несколько процентов пакетов, на выходе все восстановится.

Даеш удвоение трафика!

[evd]

Если этот пост адресован мне, то еще раз повторю. Задача гарантированной доставки опредленного класса трафика не решается путем манипуляции с полосой если количестов портов в системе больше двух. Это голимая математика.

 

Поэтому не работает QoS у любителей запаса полосы, принципиално не может работать. Единственна сеть где это работает выглядит так:

 

Локальный порт 10Мб - (роутер A) - Магистральный канал 100М - (роутер Б) - Локальный канал 10Мбит

 

На практике такая абсурдная схема не встречается, ибо экономия идет на самом дорогом канале, которорый агрегирует трафик с большого еоличемтва выскоростных каналов. Вот этот канал забивается первым, на нем применяется QoS.

Sonne, сначала определитесь, пожалуйста, что и куда Вы собираетесь гарантированно доставлять (а также, гарантированно получать?) на 100% загруженной сети. Что конкретно и кому конкретно Вы собираетесь гарантировать?

 

Простоты ради, можно даже не принимать во внимание реакцию не-vip-клиентов на ваши (теоретические, надеюсь) эксперименты...

 

Без абстракций про три дырки можно?

Изменено 1 декабря, 2008 пользователем evd

[Прохожий]

Мда... У меня резко появилось желание писать через мать, в стиле МрБира на пике раздражения...

 

Многим стоило бы хотя бы в общих чертах разобраться с тем, как вообще работают сети пакетной маршрутизации, особое внимание уделив концепции per hop behaviour как таковой. А так же происходящей из этого однонаправленной природе IP-сетей. Необходимо так же не упустить идею о том, что их функционирование описывается не в терминах арифметики, а в терминах теории вероятностей и математической статистики. Потом уже можно переходить к рассмотрению механизмов приоритезации, конкретно разбараясь, при каких условиях и как сии механизмы включаются в работу, ГДЕ КОНКРЕТНО они работают и как.

 

Как только это будет усвоено хотя бы на тройку, можно начинать осмысливать следующий тезис:

 

Механизмы классов обслуживания в IP предназначены НЕ для запихивания двух метров в один, а для "догрузки" ресурса трафиком, который не жалко дропнуть, при сохранении в полном объеме обслуживания трафика, который так или иначе важен. Это раз. И второе - для ранжирования трафика (или сервисов) таким образом, чтобы при отработке отказов наиболее критичные приложения максимально долго сохраняли свою работоспособность...

 

А если Вам надо продавить "просто трафик" без разделения на более и менее важный - то тогда звиняйте, "зебра ответить не может" (с)

[AlexBT]

Прохожий, ИП - наше фсе!!!

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

[Sonne]

Если этот пост адресован мне, то еще раз повторю. Задача гарантированной доставки опредленного класса трафика не решается путем манипуляции с полосой если количестов портов в системе больше двух. Это голимая математика.

 

Поэтому не работает QoS у любителей запаса полосы, принципиално не может работать. Единственна сеть где это работает выглядит так:

 

Локальный порт 10Мб - (роутер A) - Магистральный канал 100М - (роутер Б) - Локальный канал 10Мбит

 

На практике такая абсурдная схема не встречается, ибо экономия идет на самом дорогом канале, которорый агрегирует трафик с большого еоличемтва выскоростных каналов. Вот этот канал забивается первым, на нем применяется QoS.

Sonne, сначала определитесь, пожалуйста, что и куда Вы собираетесь гарантированно доставлять (а также, гарантированно получать?) на 100% загруженной сети. Что конкретно и кому конкретно Вы собираетесь гарантировать?

 

Простоты ради, можно даже не принимать во внимание реакцию не-vip-клиентов на ваши (теоретические, надеюсь) эксперименты...

 

Без абстракций про три дырки можно?

Не могу без абстракций, не вижу понимания базовых терминов.

 

QoS это банка вазилина, которой смазывают черенок от лопаты прежде чем загнать его в задницу. Без QoS загнать тоже можно, но выходит дольше, больнее и процес может сорваться от истерики пациента. Однако засунуть два черенка одновременно кос у же не поможет. Так же он не дает ответа на вопрос зачем нужно это извращение, т.е. зачем грузить сеть на 100%.

 

На ваш вопрос куда - отвечаю: из пункта А в пункт Б ( схема выше).

На вопрос что гарантировать - отвечаю: процент потерь пакетов, максимальный джитер для значимой доли пакетов, например 90% или 99%. Это статистические величины.

На вопрос кому - потребителю который оплачивает более высокий приоритет.

 

И на вопрос как

1) Вырезаю полосу которая всегда свободна. Это технологические меры.

2) Отбираю лопату у тех кто собирался сунуть ее куда не нужно и бью по рукам. Это административные меры.

[evd]

Механизмы классов обслуживания в IP предназначены НЕ для запихивания двух метров в один, а для "догрузки" ресурса трафиком, который не жалко дропнуть, при сохранении в полном объеме обслуживания трафика, который так или иначе важен. Это раз. И второе - для ранжирования трафика (или сервисов) таким образом, чтобы при отработке отказов наиболее критичные приложения максимально долго сохраняли свою работоспособность...

Такой подход ближе к реальности чем у Sonne. Но, увы, небезупречен imho

 

Начнем с того, что любой трафик дропать - себе в убыток. То есть, Вам, может быть, и не жалко, но тот, кто его не получил, имеет полное право обидеться ;)

 

Btw, чем Вы собираетесь "догружать" сеть? "Возьмите у меня трафика, недорого, но с дропами"?

 

Далее начинаются всякие досадные "мелочи". Во-первых, требуется отмаркировать весь влетающий в сеть трафик. А это обычно не три дырки, как в примере у Sonne. Предварительно, понятное дело, определившись с принципами приоритизации. (И сознавая, что влетающий извне трафик уже к Вам влетел, положив тем самым на QoS большой болт с левой резьбой)

 

Следом, надо назначить размер очереди на backbone-портах для каждого класса. На живой сети, а не в лабораторных условиях. Не забывая при этом про network control, дабы сеть не замахала крыльями, как ночная бабочка. Из каких соображений будем выбирать соотношение очередей?

 

Ну хорошо, допустим для простоты, что выделили мы на трафик "для баловства" 10% полосы, а 90% - это "для бизнеса". С точки зрения железок - распределили размеры очередей в надлежащей пропорции. Пока сеть стоит незагруженная (очереди пусты) - конкретные цифры значения не имеют

 

Веселье начинается, когда перестает хватать полосы. Ну, случился DDoS. Как водится, внезапно. И весь, или частично, попал в "бизнес-класс" (ну очень похож). Или суточные колебания профиля трафика достигли угрожающей амплитуды. Да и фиг бы с ним, у нас же есть запас прочности, обеспечиваемый великим и могучим QoS. Беда только в том, что за красивым названием не стоИт ничего, кроме возможности перераспределять размеры исходящих очередей на физическом порту. (Ну да, есть еще LLQ, очередь вне очереди, но только там уже ни о каких процентах полосы речь не идет, планированию сия как-бы-еще-одна-очередь не подлежит, и туда лучше не лезть imho, если нет желания уложить всю сеть одним неверным движением)

 

И выясняется вдруг, что 10% "для баловства" - это непозволительная роскошь. Потому что "эконом-класс" ставшую дефицитом полосу как кушал, так и кушает, а "бизнес-класс" (сюрприз!) лежит весь убитый. А хотелось-то как раз наоборот! И как раз для этого наоборот все и затевалось!

 

Sorry за (легкое) утрирование. И вообще, это моё сугубо личное imho: хотите разумного (в смысле волей разума) управления трафиком своим телом - отключите мозжечок и двигайте конечности сигналами от лобных полушарий ;)

 

[mezonin]

Ведь так просто, посылать сразу дублированные данные, ну и пусть теряется несколько процентов пакетов, на выходе все восстановится.

Даеш удвоение трафика!

Там все гораздо компактнее :)

не больше процентов 20 обычно.

http://en.wikipedia.org/wiki/Forward_error_correction

[Sonne]

evd

 

видна попытка мысли, но ключевые моменты ошибочно вывернуты наизнанку.

Я вам могу показать и разъяснить эти моменты, если пойму что это пойдет на пользу,

а в ответ не услышу оскорбления как от тупых телефонистов.

 

Давайте для начала спросим вы настраивали кос на сети какого размера?

Лично я на примерно 2000 роутеров (дырок). Что принесло несколько сотен тысяч зеленых доп доходов в год.

[evd]

evd

 

видна попытка мысли, но ключевые моменты ошибочно вывернуты наизнанку.

Я вам могу показать и разъяснить эти моменты, если пойму что это пойдет на пользу,

а в ответ не услышу оскорбления как от тупых телефонистов.

 

Давайте для начала спросим вы настраивали кос на сети какого размера?

Лично я на примерно 2000 роутеров (дырок). Что принесло несколько сотен тысяч зеленых доп доходов в год.

Sonne, обещаю не переходить на личности. Но и к Вам просьба не задавать вопросы кто такой, откуда взялся, и чем занимаюсь ;)

 

Про "попытку мысли" - я честно предупредил, что (слегка) утрирую. Трафику "для баловства" надо выделять 0% полосы. Но и исходный посыл Прохожего предполагал не 2 класса обслуживания. Так что по сути описанная картина не сильно далека от реальности imho. Если заблуждаюсь - буду признателен за разъяснения: где и в чём именно?

 

И - хотелось бы понять, как Вы собираетесь обеспечить стабильный jitter, выделяя для голоса 20% полосы?

 

[ugluck]

и вовсе не обязательно всю полосу заранее распределять на %%... есть WRR а есть strict priority (в терминах цыски). на входе в сеть трафик раскрашивается.

как Вы собираетесь обеспечить стабильный jitter, выделяя для голоса 20% полосы?

покрасим голос, но не более 20% полосы, все, что больше - exceed-action policed-dscp-transmit. и queue mode strict.

Изменено 1 декабря, 2008 пользователем ugluck

[AlexBT]

Давай покрасим холодильник в черный цвет!

Он синим был, зелным был, а черным нет! (с) Народное...

 

Как защитить порт маршрутизатора или сам маршрутизатор от перегрузки большим количеством мелких пакетов?

[bitbucket]

Как защитить порт маршрутизатора или сам маршрутизатор от перегрузки большим количеством мелких пакетов?

Никак. Можно внешней программой, что меряет pps и делает down порту. Это если роутер аппаратный. А программный - rtfs и вперед.

 

ЗЫ: И таких "хотелок" для вендоров я могу с десяток написать. Например, очень надо кроме выявления пакета по u32 (или как модно DPI) еще

иметь возможность править этот пакет, с перерасчетом всех контрольных сумм.

[Прохожий]

Начнем с того, что любой трафик дропать - себе в убыток. То есть, Вам, может быть, и не жалко, но тот, кто его не получил, имеет полное право обидеться ;)

На обиженных - воду возят. Если вы обещали бест еффорт - хера ли обижаться? Кроме того, обида - понятие НЕ юридическое и НЕ экономическое. Т.е. в терминах бизнеса - херня полная. Впрочем, смотря КТО обижается. КОС - это способ переместить обиды в наименее значимый сегмент потребителей.

 

Btw, чем Вы собираетесь "догружать" сеть? "Возьмите у меня трафика, недорого, но с дропами"?

Не так. Возьмите у меня дороже, без дропов.

 

Далее начинаются всякие досадные "мелочи". Во-первых, требуется отмаркировать весь влетающий в сеть трафик. А это обычно не три дырки, как в примере у Sonne. Предварительно, понятное дело, определившись с принципами приоритизации. (И сознавая, что влетающий извне трафик уже к Вам влетел, положив тем самым на QoS большой болт с левой резьбой)

Ага, а большинство граждан хочет купить фотоаппарат с одной кнопкой "шЫдевр!". Естественно, придется моск включить и подумать. Без внятной модели приоритетов обслуживания ничего не получится. А влетевший трафик... Ну влетел, дальше что? Вы управляете качеством на СВОЕЙ сети.

 

Следом, надо назначить размер очереди на backbone-портах для каждого класса. На живой сети, а не в лабораторных условиях. Не забывая при этом про network control, дабы сеть не замахала крыльями, как ночная бабочка. Из каких соображений будем выбирать соотношение очередей?

Опять замес. Нетвор контроль надо предусматривать в модели приоритетов. А очереди уже формировать по модели. На доброй половине оборудования очереди сами по себе не рулятся - рулятся механизмы их обработки - строгий приоритет или взвешенный.

 

Ну хорошо, допустим для простоты, что выделили мы на трафик "для баловства" 10% полосы, а 90% - это "для бизнеса". С точки зрения железок - распределили размеры очередей в надлежащей пропорции. Пока сеть стоит незагруженная (очереди пусты) - конкретные цифры значения не имеют

Соотношение таким быть не может. Если хотите давать приоритетный трафик - его должно быть сравнительно мало. 30-40% максимум - потому что есть еще и аварии

 

Веселье начинается, когда перестает хватать полосы. Ну, случился DDoS. Как водится, внезапно. И весь, или частично, попал в "бизнес-класс" (ну очень похож). Или суточные колебания профиля трафика достигли угрожающей амплитуды. Да и фиг бы с ним, у нас же есть запас прочности, обеспечиваемый великим и могучим QoS.

Если перестает хватать полосы под критичный трафик - апгрейд без вариантов. Если ДОС попадает в высший приоритет - вырвать руки тому, кто делал. Доверия к маркировке входящего нет по определению.

 

Беда только в том, что за красивым названием не стоИт ничего, кроме возможности перераспределять размеры исходящих очередей на физическом порту. (Ну да, есть еще LLQ, очередь вне очереди, но только там уже ни о каких процентах полосы речь не идет, планированию сия как-бы-еще-одна-очередь не подлежит, и туда лучше не лезть imho, если нет желания уложить всю сеть одним неверным движением)

Кстати, среди всего прочего на кону еще и управляемость сети в ЛЮБОМ ее состоянии. Или Вы на столько богаты, что можете себе аут-оф-бенд до каждого свича позволить?

 

И выясняется вдруг, что 10% "для баловства" - это непозволительная роскошь. Потому что "эконом-класс" ставшую дефицитом полосу как кушал, так и кушает, а "бизнес-класс" (сюрприз!) лежит весь убитый. А хотелось-то как раз наоборот! И как раз для этого наоборот все и затевалось!

"Учиться, учиться и еще раз учиться!" (с) В.И.Ленин

 

Переврали Вы в итоге абсолютно все :)

 

Sorry за (легкое) утрирование. И вообще, это моё сугубо личное imho: хотите разумного (в смысле волей разума) управления трафиком своим телом - отключите мозжечок и двигайте конечности сигналами от лобных полушарий ;)

Кхм, сам понял, что сказал? Я - нет :)

[SergeiK]

Я заметил, что те, кто активно против QoS никогда не делали и не знаю что это.

А тем не менее, 90% сетей QoS использует по умолчанию, так сказать. Протоколы маршрутизация и служебные пакеты идут с высокими приоритетами и на большинстве оборудования (серьезного) это поддерживается и работает, так же, по умолчанию.

Возвращаясь к аналогии с транспортом (довольно хорошая аналогия, единственное - так дропы битых и неумещающихся в очередь пакетов трудно реализовать :) ) никто не спорит, что надо расширять дороги. Но, обеспечить приоритет скорой, пожарникам, милиции надо в любом случае.

 

[st_re]

В нормальных странах для обеспечения приоритета скорой пожарной итд остальные не имеют права ездить по обочинам и т.п. и не ездят (есть резерв полосы), и скорые там едут быстро. но когда полоса уложена в полку (машины по 2-х полосной дороге едут в 5 потоков занимая все полости, включая небольшие уширения на остановки для общественного транспорта и трамвайные пути) то никакая скорая никуда не пролезет. никак. нисмотря ни на какой приоритет.

[Прохожий]

то никакая скорая никуда не пролезет. никак. нисмотря ни на какой приоритет.

Это и есть хреново настроенная сеть :)

 

Кстати, важное дополнение: часто говорят про "резервирование", NN% и т.д. Это все полный бред, потому что:

1. Нет никакого резирвирования. Есть обслуживание в соответствии с приоритетом в каждом узле коммутации.

2. %% приоритетного трафика на сети определяется... да ХЗ чем! На самом деле - настройкой полисеров и классификаторов в тех точках, где появляются пакеты + реальной нагрузкой по данному виду трафика.

 

То есть задача получается следующая: мониторинг нагрузки ПО КЛАССАМ и упреждающий апгрейд в случае, если пиковая нагрузка по ПРИОРИТЕТНОМУ трафику превышает N%

 

Теперь давайте рассмотрим простейшую модель приоритетов, рациональную для сети доступа на основе технологии Ethernet. Возьмем L2, не будем на IP заморачиватсья для простоты. При этом учтем следующие обстоятельства:

 

1. Стандартом 802.1D предусмотрено три бита (8 значений), 7 - максимальный.

 

2. Большинство свичей невысокого класса реально имеют четыре очереди (попарно мапят 8 классов), при этом старшая очередь - строгая, остальные - взвешенные.

 

3. Используется серая адресация.

 

Таким образом, разумно следующее:

7,6 - служебный трафик, управление сетью

5,4 - трафик клиентских VLAN, если предоставляется услуга объединения сетей по L2

трафик собственных игровых серверов

3,2 - трафик Интернет, трафик к собственным ресурсам (?)

1,0 - все остальное

 

Вот такая простенькая модель. Что она дает:

1. Чего бы не творили юзвери внутри сети, основные ключевые услуги - не страдают

2. При любой плотности ДОСа не страдают внутренние коммуникации корпоративных клиентов

3. Чего бы там ни было с нагрузками - сеть остается управляемой, что в конечном итоге позволяет разруливать ситуацию...

 

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