[evd]

Клавдий, Вы рядом график счетчика дропов приложите

Надо полагать, что если КМ обрежет полосу на гигабитном порту до 800 метров, то дропы канут в лету, и будет скупому клиенту щазсчастье? ;)

[Клава Маус]

Визирь, у меня дропы не на сети, а непосредственно на порту к клиенту. На том порту, который он заказал и полностью без лукавства его утилизует. И клиент это осознает и непосредственно видит. И это картинка не с жесткой полкой, кои я видАл на ДВ, в Сибири и у домушников, когда они только начинали предлагать анлимы.

 

А вот, если 1GE порт не может отдать чистых 0,94GE без оверхедов, то дропы уже внутри вашей сети.

У вас узлы или каналы между ними болеют. Вот тут и просите вам показать дропы, нагрузки процев, ошибки и т.п., чтобы причину найти и лечение придумать.

[j_box]

МрБир, Клава Маусович!

Нет никакого преднамеренного резервирования полосы у магистралов.

Если у ТТК точно такие же "симптомы" как и у РТ, то дело ИМХО в следующем:

 

РТ строил свою ПД сеть на существующем "телефонном" синхронном транспорте. То есть не было смысла поднимать лишние лябды там, где хватало для старта уже построенной полосы. Синхронный транспорт - это СТМы. Вся схема предоставления услуг ПД выглядит так: бордер - маршрутизатор - интерфесная плата SDH мукса - плата кросс-коммутации SDH мукса - транспортная интерфейсная плата SDH мукса - траспондер DWDM - цветной сигнал в магистраль. То есть работает схема Ethernet over SDH over DWDM.

 

Кирилл недавно говорил (лень искать) что есть платы, с четыремя гигабитными интерфейсами. но поддерживающими де-факто лишь гигабит...

Думаю это не так. Какой разработчик будет делать платы заявленный функционал которых не будет соответсвовать действительности? Я бы ни за что не рискнул двигать такую свою продукцию на профессиональном рынке. Это пи@@@ц деловой репутации фирмы ни за грош.

 

Знаю есть такие прецеденты в бытовухе (например с мобилами). Модели один в один по техническому исполнению. Одна стоит 100 баксов, другая 300 баксов. Разница только лишь в прошивке чипа, позволяющего реализовать потенциал модели на 100%.

 

Ну да ладно. Я отвлекся. Может быть жадных так наказывают и на профессиональном уровне. Сэкономил 100 баксов из тысячи, получил производительность в 4-е раза меньшую.

 

Я о другом. Схема Ethernet over SDH - имеет свои особенности. ( Тут небольшой экскурс в технологию )

SDH - синхронная технология. То есть нигде, никогда нет очередей на входных и выходных буферах. SDH предназначен для передачи телефонного сигнала т.е. каждую секунду 8000 раз АЦП считывает сигнал с микрофона телефонной трубки и оцифровывает его 8 битами. Данный байт - немедленно уходит абоненту на другом конце провода. Получаем 8 х 8000 = 64к - стандартный оконечный цифровой телефонный канал или ОЦК.

Один ОЦК - и есть один тайм-слот в потоке Е1. Тайм-слотов в Е1 - 30 штук ( полезная нагрузка 30 + 2 служебных). Итого 2048 кБ/с = Е1

 

То есть, оборудование работающее с Е1 передает 8000 раз в секунду пакет (виртуальный контейнер VC12) размерами 8 * 32 = 256 бит.

Заметно, что 16кбит информации - служебные ( не доступны пользователю для передачи полезной информации ).

Значит реальная пропускная способность Е1 ( для пользователя) = 30 * 8000 = 1920кб/с.

 

Дальше больше. Е1 пакуются в STM-1 по 63 штуки (больше не помещается. Сделано так для совместимости со стандартами США где 30 разговорных каналов помещаются в 1,5 Мб/с) Итого 63 * 2048 = 129 мб/с = реальная пропускная способность STM-1 но есть ньюансы...

Это верно если грузить СТМ двушками. Если грузить плезеохронным сигналом ( не разбивая на Е1) можно закачать 140 Мб/с.

К полезной нагрузке добавляется заголовок (регенераторной секции, мультиплексорной секции + указатель) и получается транспортный модуль

155 мб/с.

 

Это и есть СТМ-1. или витруальный контейнер 4-го уровня (VC4). Реальная пропускная способность его (полезная нагрузка) 129 мб/с.

 

Дальше еще больше. Мультиплексоры SDH могут выполнять роль L2 коммутаторов. то есть есть платы с 1GE портами для данных мультиплексоров, но в магистраль передаются не 1GE, а адаптированные под SDH технологии Е1 х 500 или VC4 x 7. В первом случае реальная пропускная способность 960 мб/с во втором 129 * 7 = 903 мб/с. или 140 * 7 = 980 мб/с Вся остальная полоса 2съедается заголовками СТМ - кадра...

 

В каждом конкретном случае нужно смотреть как сконфигурирует мультиплексор админ, такой и будет реальная полоса.

 

Если же в качестве трнспорта (хребта магистрали) использовать Ethernet ( 10GE over DWDM). то ничего подобного не происходит. Все пакеты уходят как им положено не подстраиваясь под SDH технологии и не теряя полосу на заголовки SDH, что убедительно доказал Клава Маусович MRTG графиком.

 

Резюме. SDH предназначен для синхронной передачи информации. В нем неизбежно будут Ethernet пакеты паковаться еще и в виртуальные контейнеры SDH. и реальная полоса не соответствует привычной провайдерам. SDH идеально подходит для передачи голоса ( 8000 контейнеров в секунду... всегда будь то Е1, Е3 или СТМ-х. SDH резервируется по схеме 1+1 при кольцевом резервировании и в состоянии дать связь с гарантированным качеством ( скорость переключения на резерв 50мс). Именно поэтому L2VPN поднятые на транспорте так приглянулись провайдерам доступа, но по сути провайдеры получают гораздо более дорогую услугу, чем IP-транзит. Они пполучают гарантированный тоннель, не зависящий от загруженности маршрутизаторов. Такой L2VPN на скорости 1GE равен по цене VC4 x 7 SDH или 500 х Е1 на данном маршруте.

 

ЗЫ: Я пару раз упоминал на форуме про "экстратрафик". Это тот трафик, который используется для резервирования проданных синхронных каналов (Е1, СТМ-х и пр.). По сути они 99,999% времени не задействованы. Технически сконфигурировать Ethernet, используемый для бекапа (продажа не полосы на погиговке) с плат мультиплексоров на по трассам Экстратрафика (верхняя часть диапазона) позволит сэкономить до 5 гиг/с на на КАЖДОЙ магистрали, где Ethernet шурует поверх SDH.

 

Это удвоение мощности существующей сети без аппаратного апгрейда!!!

Я пробовал это решение (чисто в познавательных целях) когда-то в учебном классе!!! Это работает. Е1 - резервируются как и прежде. Интернет провайдеры получают полосу, используемую под резервирование SDH трафика в момент "Ч" на своих магистралях, но только при условии. что все "дорогие" связи SDН функционируют в штатном режиме...

 

ЗЫЫ: Черт возьми!!!! Почему мне нужно служить интерфейсом между синхронными технологиями и технологиями ПД? И те и другие мне кажется не как не поймут на каком же языке разговаривает их сосед... Вроде все слова по русски, но суть... разница от обеих сторон ускользает... :(((

 

Сейчас словоблудие было для обеих сторон. Вот пакет (ПД) - который передается асинхронно. Вот СТМ-кадр который передается 8000 раз в секунду и сколько в него успел загрузить данных юзер - его проблемы. Давайте разбираться господа. Тестить. И не бросаться словами как господин Дятел или еще кто по поводу "фу... отстой...". :(((

 

С уважением....

Изменено 18 мая, 2009 пользователем j_box

[ingress]

многа букаф. перечитаю позже :)

[СУХОВ]

Кирилл недавно говорил (лень искать) что есть платы, с четыремя гигабитными интерфейсами. но поддерживающими де-факто лишь гигабит...

Думаю это не так. Какой разработчик будет делать платы заявленный функционал которых не будет соответсвовать действительности?

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

Изменено 18 мая, 2009 пользователем СУХОВ

[wawa]

Кирилл недавно говорил (лень искать) что есть платы, с четыремя гигабитными интерфейсами. но поддерживающими де-факто лишь гигабит...

Думаю это не так. Какой разработчик будет делать платы заявленный функционал которых не будет соответсвовать действительности? Я бы ни за что не рискнул двигать такую свою продукцию на профессиональном рынке. Это пи@@@ц деловой репутации фирмы ни за грош.

может он про это говорил про оверсабскрайб 4 к 1 ?

вот Вам, пожалуйста, пример:

Cisco WS-X4424-GB-RJ45 - все порты сгруппированы по четыре

и если есть превышение - оно летит в корзинку

Cat 450x вполне себе профессиональный прибор, не самый свежий правда.

Но оверсабскрайб такого типа живее всех живых.

Изменено 18 мая, 2009 пользователем wawa

[evd]

Нет никакого преднамеренного резервирования полосы у магистралов

А если вдруг где-то и обнаружилась свободная полоса, то это чистая случайность ;)

 

Схема Ethernet over SDH - имеет свои особенности

IP over SDH уже не модно? Всякие там PPP, HDLC и иже с ними

Или Вы про 10G wan-phy? Ну да, там есть свои особенности. Абсолютно прозрачные для тех, кто эту технологию использует

 

SDH - синхронная технология. То есть нигде, никогда нет очередей на входных и выходных буферах

Ethernet-фреймы/ip-пакеты прилетают строго по расписанию? ;)

Вообще же, Джей, ваша правда: sdh-мультиплексор и ethernet-свич таки работают по-разному. Один вопрос остался: какое это имеет отношение к резервированию полосы?

Изменено 18 мая, 2009 пользователем evd

[Клава Маус]

Браво, Джей!

А я уже забыл как набрать 1GE из ОЦК.

 

И просто так, в качестве язвы классическим телефонистам под дыхло, так и не познавшим ATM и ISDN, чтобы сделать по-настоящему супер хорошо и супер непокупаемо дорого: Вы все еще over SDH, тогда мы идем к Вам... :))

 

[separaf]

эммм

в крупных сетях 99% траффика насколько я знаю так и организовывается, как написал джей.

только забыли еще про конкатенацию добавить.

 

На деле реализацию IP через DWDM я видел всего 1 раз. на 10гиговых джуповских платах. странно вообще (лично для меня) использовать волокно меньше чем для stm-64 (его жеж прокладывать замучаешся :) )

 

Хотя интересно было бы послушать, у кого еще как организован IP транзит.

 

ЗЫ насчет эктратрафика, ну фиг знает, вариант канала который "какбы" работает имхо мало кого устроит. а вот если продумать это дело( какиенить сцепленные кольца, правда время переключения возрастает) то тогда да 50% апгрейд емкости.

Изменено 18 мая, 2009 пользователем separaf

[Дятел]

Давайте разбираться господа. Тестить. И не бросаться словами как господин Дятел или еще кто по поводу "фу... отстой...". :(((

г-н Джей!

Пропуск 300мегабит/сек в том месте, где по договору стоит "до 1Гбит/сек" никакого отношения к упаковке, заголовкам и прочим техническим терминам не имеет. А имеет отношение только к желаниям продать то, чего ещё (или уже) нет.

 

[visir]

Визирь, у меня дропы не на сети, а непосредственно на порту к клиенту. На том порту, который он заказал и полностью без лукавства его утилизует. И клиент это осознает и непосредственно видит.

Я никоим образом не наезжал на вашу сеть.

 

Загрузка более 80% при усреднении в пять минут (как на вашем графике) часто означает кратковременные прыжки до 90% и выше, а значит наличие заметного джиттера, а то и вовсе дропов. К сожалению, легко визуализировать на графиках можно только второе...

 

Клиенты бывают разные, да. Кто-то любит полку по 20 часов в сутки... другие готовы доплачивать за полный гигабит лишь из-за того, что на нем не будет висеть полисера/шейпера.

Бывают и желающие купить 300мбит через один STM-1... я не шучу. Еще больше поражают манагеры, готовые им это продать ("да, я знаю, что не прокачает через S1 он столько, но вы поставьте, как в бумаге написано, ограничение в 300М и все - остальное не наши с вами проблемы").

А вот операторов, которые предупреждают о недостижимости интерфейсных скоростей я еще не встречал :-).

 

Вы конечно хорошо пишете сочинения... вот только к реальности они никакого отношения не имеют.

Для информации: POS-интерфейс STM-64 на маленьких пакетах более эффективен, чем 10GE LAN PHY (но не на столько, чтоб за это переплачивать).

Касаемо 4к1: http://www.juniper.net/techpubs/en_US/rele...et-iq2-qpp.html ;)

 

Про Ethernet-over-SDH я вам еще больше скажу: при составлении линка из множества VC у него большие проблемы с поляризацией трафика - в один из VC может идти больше трафика, чем в другой - то есть один на полке, а другой еще скажем на половине... это при реальном трафике, а IMIX-трафик от крутого генератора трафика при этом распределяется между VC идеально :-)

 

Вы все еще over SDH, тогда мы идем к Вам... :))

OTN - наше все :-)

 

странно вообще (лично для меня) использовать волокно меньше чем для stm-64

DWDM системы с S16 еще долго будут жить...

Изменено 18 мая, 2009 пользователем visir

[vIv]

Кирилл недавно говорил (лень искать) что есть платы, с четыремя гигабитными интерфейсами. но поддерживающими де-факто лишь гигабит...

Я видел карточки 16ГЕ с 10ГЕ на карту. Но к ним шло уточнение, что это карты или высокоскоростного доступа, или для серверных ферм малонагруженных. Т.е. внутри карты wirespeed, но с карты в шасси только 10-ка.

[j_box]

Визир. Мне до вашего уровня владения темой далеко. Больше словоблудия и попыток нахвататься верхушек у более знающих людей. :(

Заметье я ни разу не упомянул Джупы. Я их не знаю. К сожалению. :((

 

Теперь о сабже. Вы сами прекрасно знаете какие возможности у транспортной сети. Но не самое главное связать ключевые точки нужной пропускной способностью. Главное дать достаточное количество нужных портов и полосу на переферию. А это уже дороже, гораздо дороже и дольше. Я предложил вариант решающий эпизодические проблемы на переферии во многих и многих начинающих сужаться местах сети. Дешево. Без апгрейда. Почувствуйте разницу...

 

Ну а в остальном мне трудно спорить. Мало знаю. :(

[LeOs]

Уважаемые, пара комментов:

- у Juniper как раз есть ограничения пропусконой способности интерфейса, вызванне модульной структурой (http://www.juniper.net/techpubs/en_US/rele...s/frameset.html, например),

- когда говорят о пропуске EoSDH, стоит, наверно, упомянуть и GFP (например, GFP-T) маппирование,

- практика показывает ограничение трафика по STM-1 в 145Мбит/с, а не 140, т.к. размещение идет не в VC-4, а в AU-4,

- да и с E12 - если unframe, то 32 * 8000*8 =2048кб/с,

 

Но я, как вшивый, опять о бане: 80-85% из каких соображений? только из-за возможных всплесков, и, как следствие, потерь, или же я просто упускаю еще какой-то фактор ?

[visir]

Но я, как вшивый, опять о бане: 80-85% из каких соображений? только из-за возможных всплесков, и, как следствие, потерь

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

[LeOs]

Но я, как вшивый, опять о бане: 80-85% из каких соображений? только из-за возможных всплесков, и, как следствие, потерь

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

А не сочтете за труд, поянить недогадливому, о каких буферах идет речь, если, по умолчанию, идет тоько Интернет, все помечено классом нормал, и ограничения производителности железа еще не достигнуты ?

[Клава Маус]

Загрузка более 80% при усреднении в пять минут (как на вашем графике) часто означает кратковременные прыжки до 90% и выше, а значит наличие заметного джиттера, а то и вовсе дропов. К сожалению, легко визуализировать на графиках можно только второе...

Прыжки делового трафика в штатном режиме на гигабитном интерфейсе величиной в 100Мбит и выше, не видимые на фоне усреднения? А на сколько же скачут у вас пики в 10GE?

Это какой такой тип клиента/сервиса/железа их организует?

Может у вас вся совокупность пользователей на том конце сети чудом синхронизуется на несколько секунд в попытке вдуть пик, а на другом конце сети этим же чудом в этот же момент синхронизуются потребители этих коротких пиков? А потом эти чудом синхронизированные предъявляют претензии, хором тряся эсэлеями, где вы прописали нормативы по джиттеру?

И поэтому, написав в заказе 1000Мбит, вы клиенту их не даете, в борьбе за минимизацию джиттера клиентских пакетов :)?

[j_box]

практика показывает ограничение трафика по STM-1 в 145Мбит/с, а не 140, т.к. размещение идет не в VC-4, а в AU-4,

Полез я в доки... вспоминать...

 

AU-PTR муксы разбирают из STM кадра на каждой мультиплексорной секции еще до кросс-комутации. Это указатель. При следующей сборке STM кадра мукс влепит туда новое значение. использовать эти девять байт под полезную нагрузку не получится. ИМХО.

 

А вот VC4 можно пропустить через матрицы кросс-комутации не разбирая, но на входе и выходе из транспорта мукс отрежет РОН...

Отсанется С4 а это 260 * 8 * 9 * 8000 = 142,82 Мб/с Все. Больше из STM-1 не выжать. ИМХО.

 

 

[visir]

А вот VC4 можно пропустить через матрицы кросс-комутации не разбирая, но на входе и выходе из транспорта мукс отрежет РОН...

Отсанется С4 а это 260 * 8 * 9 * 8000 = 142,82 Мб/с Все. Больше из STM-1 не выжать. ИМХО.

Джей, упаковывать данные в VC4 могут только дорогие Channelized платы.

Обычные POS-ы тупо без сложной упаковки используют весь payload STM-фрейма, получается ~150мбит для HDLC/PPP-трафика. Что с учетом HDLC-заголовков и bit/byte stuffing-а дает ~135-145 мбит на IP уровне.

Для мультиплексирования в верхние уровни в payload заглядывать необязательно.

Изменено 19 мая, 2009 пользователем visir

[Нерубящий инспектор]

Заметно, что 16кбит информации - служебные ( не доступны пользователю для передачи полезной информации ).

Значит реальная пропускная способность Е1 ( для пользователя) = 30 * 8000 = 1920кб/с.

Я так понимаю - это если Е1 фракшинл ( по нашему ИКМ 30), а если унфракшнл - то все 2048 (по нашему ИКМ 32). А есть еще и ... по нашему ИКМ 31.

 

[visir]

А не сочтете за труд, поянить недогадливому, о каких буферах идет речь, если, по умолчанию, идет тоько Интернет, все помечено классом нормал, и ограничения производителности железа еще не достигнуты ?

И что, при этом буфера не используются ?

Результат получается такой:

Изменено 19 мая, 2009 пользователем visir

[evd]

- у Juniper как раз есть ограничения пропусконой способности интерфейса, вызванне модульной структурой (http://www.juniper.net/techpubs/en_US/rele...s/frameset.html, например),

Не совсем так. У (младших) Джуниперов M-серии существует ограничение по пропускной способности FPC. Карточка STM16, занимающая как раз все четыре слота FPC M20, например, способна пропустить ровно столько трафика, сколько влезает в STM16. А вот 4 гигабитных PIC'а, вставленных в этот же FPC, загрузить все разом свыше 80% не получится. Но можно раскидать их по двум FPC, получив полноценные 4Gbps full duplex

[vsn]

Доброго времени, уважаемые!

 

Если позволите, приведу разъяснения, откуда взялись эти пресловутые 80% в данном, конкретном случае.

Дело в том, что в нашем случае, клиент не забирает услугу напрямую с магистрального порта КТТК. Между КТТК и клиентом есть последняя миля. Миля с интерфейсом GE. Давным-давно в КТТК, разработана процедура паспортизации линий доступа с Ethernet окончаниями, согласно которой, основная услуга, передаваемая по этой ПМ не должна занимать более 80% пропускной способности ПМ. Т.е. - не более 800 Мб/с по гиговому линку.

Хорошо это, или плохо - разговор другой, но обойти это требование удается только в экстренных случаях.

 

 

[LeOs]

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

[vsn]

Ой, надеюсь, что уважаемые разберутся, о каком конкретно случае речь идет? :)

К Ростелеку я отношения не имею :)