Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 94
Самая интересная тема вскользь упомянута, но совсем не раскрыта — "тестирование нагрузкой протоколов прикладного уровня (http, ftp, etc...). ". :) Потому как уже не раз сталкивался с ситуацией, когда на уровне Ethernet и даже IP всё на первый взгляд красиво, а приложения не бегают.
В принципе методика rfc2544 подразумевает тесты с разным размером кадра, как раз для эмуляции разных типов трафика и нагрузочное тестирование должно показать проблемы, только по методике канал 10G можно только специальной коробочкой замерить, но коробочка проблему должна показывать.
Вообще часто бывает что коммутаторы не справляются с работой на заявленной скорости. Есть грустные примеры как неуправляемый коммутатор не справился со 100 мегабитами в секунду, не смотря на то, что все делало вид, что работает как надо.
Вообще часто бывает что коммутаторы не справляются с работой на заявленной скорости. Есть грустные примеры как неуправляемый коммутатор не справился со 100 мегабитами в секунду, не смотря на то, что все делало вид, что работает как надо.
Тема очень актуальна.
Мне, как человеку только погружающемуся в тематику, очень хотелось бы развернутую статью с реальным софтом и примерами )
P.s. Я прекрасно понимаю, что это на энтузиазме пишется. Но было бы полезно многим =)
Мне, как человеку только погружающемуся в тематику, очень хотелось бы развернутую статью с реальным софтом и примерами )
P.s. Я прекрасно понимаю, что это на энтузиазме пишется. Но было бы полезно многим =)
Не софтом, скорее аппаратно-программным комплексами. Такая статья, подробная, может наделать не мало шума. Не хотелось бы писать о печальных подробностях работы современного оборудования вот так громко)
Так вы сделайте шрифт помельче.)
Так а в чем проблема? Пускай страна знает своих героев. Мы живем в цивилизованном обществе, где за критику в интернете не отрезают палец. А хочешь, чтобы в таких тестах твое оборудование лидировало — делай качественно.
Очень интересна тема. Мы хотим горькую правду!!!
У меня впечатление от статьи как от редкостного маркетингового булщита, чтоб нбыть голословным с цитатами:
Намеренно искажается эффективность открытых инструментов и замалчиваются такие утилиты как hping3, yandex tank, MoonGen, DPDK и многих других, позволяющих как манипулировать типом, размером пакетов, так и генерировать пакеты собственного типа, составленные по частям, при этом генерации в районе 15 MPPS и/или 10 гигабит на обычном ПК или ноутбуке с 10G картой (даже на хабре было несколько статей по генерации больших объемов трафика на простом железе), к тому же способные проводить тестирование по собственному сценарию, актуальному для компании. Я бы понял если бы железные решения предлагались для более 10 гигабитных линков, но тут предложение для простого гигабита, но эти инструменты можно не замечать и предложить "волшебную" пилюлю в виде своего продукта, зачем нам сравнительные тесты или какие-то графики, ведь можно всех обозвать «коекакерами» и быть на коне.
И как же ваш чудопродукт решает эту проблему при использовании на живом канале? Или он волшебным образом почистит канал от других данных, изменит настройки QoS промежуточного железа и т.п. Снова намеренное ругание сторонних инструментов, при том, что собственный имеет ту же всем известную проблему.
Потому, что по факту за офигилион денег мы получаем железяку с устаревшим железом 5 летнего ноутбука, софтом от школьника с нулевой кастомизацией без возможности написания своих сценариев тестирования под определенную среду, полной залочкой прошивки и закрытым кодом, зато с кучей пафоса, сертификатов и красивых буклетов, при этом один хрен с собой приходится таскать осцилограф, рефлектометр, специально подготовленный ноутбук и человека, который может взлететь со всей этой хреновиной, зачем тут еще вендорлок коробка, проверить показания которой невозможно?
Отдельных лучей ненависти заслуживает голосовалка, которая дает выбрать из вариантов "я дурак" и "я лох и повелся на маркетинг", где вариант тестируем другими и все отлично работает, ваш не нужен, пока не доказал обратное.
И как эта волшебная коробочка, без собственных алгоритмов покажет что на узле А неправильно выставлены веса приоритетов на QoS, а приложение Б тормозит из-за того, что по умолчанию использует DNS в Новой Гвинее, не увидел в описании L5-L7 тестирования, так что ваше заявление, что должна показать голословно.
Я бы не стал писать этот огромный камент, но меня зацепило: "Такая статья, подробная, может наделать не мало шума. Не хотелось бы писать о печальных подробностях работы современного оборудования вот так громко)", что лично для меня является 100% показателем недобросовестности продавца, торговцы БАДами и гомеопатией любят такие же заявления с теориями заговора и скрытием подтвержденных данных, чтоб "не наделать шума".
По итогу: хочется видеть конкретику и сравнение с конкуретнами как открытыми так и закрытыми, желательно чтоб все тесты можно было проверить самостоятельно, графики таблицы с конкретными цифрами и показателями работы а также финансовой выкладкой, что именно ваш продукт позволит сэкономить компании денег, в отличие от конкурентов, без этих данных на техническом ресурсе ваша статья пустой маркетинговый треп. Прошу прощения если кого обидел.
Полноценным тестированием канала не могут являться echo запросы, ping и mtr никогда не расскажут какая у канала пропускная способность
Намеренно искажается эффективность открытых инструментов и замалчиваются такие утилиты как hping3, yandex tank, MoonGen, DPDK и многих других, позволяющих как манипулировать типом, размером пакетов, так и генерировать пакеты собственного типа, составленные по частям, при этом генерации в районе 15 MPPS и/или 10 гигабит на обычном ПК или ноутбуке с 10G картой (даже на хабре было несколько статей по генерации больших объемов трафика на простом железе), к тому же способные проводить тестирование по собственному сценарию, актуальному для компании. Я бы понял если бы железные решения предлагались для более 10 гигабитных линков, но тут предложение для простого гигабита, но эти инструменты можно не замечать и предложить "волшебную" пилюлю в виде своего продукта, зачем нам сравнительные тесты или какие-то графики, ведь можно всех обозвать «коекакерами» и быть на коне.
при одновременном использовании сети и тестировании софтовым утилитам не известен объем пользовательских данных, находящихся в канале в текущий момент
И как же ваш чудопродукт решает эту проблему при использовании на живом канале? Или он волшебным образом почистит канал от других данных, изменит настройки QoS промежуточного железа и т.п. Снова намеренное ругание сторонних инструментов, при том, что собственный имеет ту же всем известную проблему.
Для сдачи или приемки построенных линий и магистралей, для работы по высоким стандартам лучше всего иметь в штатном арсенале тестер-анализатор, хотя в интернете можно найти фирмы, специализирующиеся на выездном тестировании. Почему-то считается что покупать тестер-анализатор это очень дорого.
Потому, что по факту за офигилион денег мы получаем железяку с устаревшим железом 5 летнего ноутбука, софтом от школьника с нулевой кастомизацией без возможности написания своих сценариев тестирования под определенную среду, полной залочкой прошивки и закрытым кодом, зато с кучей пафоса, сертификатов и красивых буклетов, при этом один хрен с собой приходится таскать осцилограф, рефлектометр, специально подготовленный ноутбук и человека, который может взлететь со всей этой хреновиной, зачем тут еще вендорлок коробка, проверить показания которой невозможно?
Отдельных лучей ненависти заслуживает голосовалка, которая дает выбрать из вариантов "я дурак" и "я лох и повелся на маркетинг", где вариант тестируем другими и все отлично работает, ваш не нужен, пока не доказал обратное.
только по методике канал 10G можно только специальной коробочкой замерить, но коробочка проблему должна показывать.
И как эта волшебная коробочка, без собственных алгоритмов покажет что на узле А неправильно выставлены веса приоритетов на QoS, а приложение Б тормозит из-за того, что по умолчанию использует DNS в Новой Гвинее, не увидел в описании L5-L7 тестирования, так что ваше заявление, что должна показать голословно.
Я бы не стал писать этот огромный камент, но меня зацепило: "Такая статья, подробная, может наделать не мало шума. Не хотелось бы писать о печальных подробностях работы современного оборудования вот так громко)", что лично для меня является 100% показателем недобросовестности продавца, торговцы БАДами и гомеопатией любят такие же заявления с теориями заговора и скрытием подтвержденных данных, чтоб "не наделать шума".
По итогу: хочется видеть конкретику и сравнение с конкуретнами как открытыми так и закрытыми, желательно чтоб все тесты можно было проверить самостоятельно, графики таблицы с конкретными цифрами и показателями работы а также финансовой выкладкой, что именно ваш продукт позволит сэкономить компании денег, в отличие от конкурентов, без этих данных на техническом ресурсе ваша статья пустой маркетинговый треп. Прошу прощения если кого обидел.
Я бы понял если бы железные решения предлагались для более 10 гигабитных линков, но тут предложение для простого гигабита, но эти инструменты можно не замечать и предложить «волшебную» пилюлю в виде своего продукта, зачем нам сравнительные тесты или какие-то графики, ведь можно всех обозвать «коекакерами» и быть на коне.
Я в принципе ничего не предлагаю, а поделилась тем, что тестеры, сертифицированные Мин связи — доказательство SLA, а так "незаслуженно умолчанные" hping3, yandex tank, MoonGen, DPDK — не более чем игрушка. Нет указаний никаких специальных приборов, по этой причине искренне не понимаю о чем вы вообще здесь и сейчас пишете, так что предлагаю закрыть диалог за несостоятельностью заявлений.
У меня на большинстве площадок SLA 99.999, и открытые инструменты + система мониторинга прекрасно позволяет его отслеживать.
Вот именно один маркетинговый булщит, лучше бы спецификации и конкретные примеры выложили, а так пришлой идти на http://metrotek.spb.ru/products.html и там отрывки инфы смотреть, для примера посмотрел тот, что на КДВП, да уж впечатляющий http://metrotek.spb.ru/b45.html
Да диалог закрываем, общаться с маркетологом, а не техническим специалистом — это как говорить о болезнях с пастором вместо врача.
hping3, yandex tank, MoonGen, DPDK — не более чем игрушкаА Яндекс, а так-же другие компании первого эшалона то и не в курсе.
Нет указаний никаких специальных приборов
Вот именно один маркетинговый булщит, лучше бы спецификации и конкретные примеры выложили, а так пришлой идти на http://metrotek.spb.ru/products.html и там отрывки инфы смотреть, для примера посмотрел тот, что на КДВП, да уж впечатляющий http://metrotek.spb.ru/b45.html
Да диалог закрываем, общаться с маркетологом, а не техническим специалистом — это как говорить о болезнях с пастором вместо врача.
При работе на действующих каналах связи, важно не только мерить канал связи, предоставляемый операторами, но и иметь систему предъявления претензий при несоответсвии качества, а для этого просто необходимы признанные, доверенные аппартно-програмные решения, позволяющие проводить измерения от точки демаркации и исключать свое собственное оборудования. Интересно было по подробнее почитать именно про эти решения.
Если уж к моему ответу комментарий, а не к топикстартера, то отвечу я. В простейшем случае берем любую систему мониторинга, умеющую считать SLA, да хоть тот-же заббикс, цепляем на подконтрольных магистралях агентов, это могут быть как готовые ALM, так и собственные решения под нужную специфику, дружим все это по SNMP — получаем полный контроль нужных именно нам параметров сети, в одном сегменте нам нужна латенси, но плевать на общую длину пинга, ибо скажем радио, в другом нам нужен голос без потерь кадров, в третьем у нас мультикаст не должен рассыпаться и т.п. на каждый случай свой агент со своими настройками и SLA, тут волшебной железки нет, первое определяем что нужно смотреть, второе чем уже эти данные можно получить.
Хотелось бы понять, если необходимо измерять канал связи без своего активного оборудования, то как я понимаю, нужно поставить дополнительный измеритель (зонд) в "разрез". Я так понял в Вашем случае статистика снимается с оборудования оператора связи, необходимые измерения настроены, кроме того есть доступ к соответствующему оборудованию по SNMP?
Да нужен свой "зонд", выше писал про ALM (Access Link Monitor) — это как раз название специальных таких "зондов". Протокол SNMP универсальный и специально создан для мониторинга, он и с "зондов" статистику снимает и с активного оборудования плюс позволяет управлять оборудованием централизованно, например заставить все "зонды" определенного региона в определенное время запустить определенный тест. Без своего активного оборудования сложнее, но если погрешность не важна можно запросить у хозяина оборудования доступ только для чтения по SNMP, да данные будут не такие точные, но отследить загрузку каналов, загрузку самой железки, количество и тип пакетов, определить кольца и некоторые другие аномалии можно вообще без "зондов". Вопрос очень общий, все сильно зависит от задачи и что конкретно для нас критично, для видео и голоса нужно одно, для шифрованного трафика — другое, для мультикаста — третье и часто проще пожертвовать каким-то аспектом, если для конкретно нашей ситуации он не критичен, т.к. иметь идеальные показатели по всем фронтам в рамках более-менее разветвленной сети просто очень дорого. Простой пример из практики, есть компания которая занимается видео наблюдением в рамках региона (более 10К камер) им вот плевать на житер и латенси и даже на дискарды с дропами в рамках до 5% ну выпал один кадр из картинки и хрен с ним им важно чтоб общая полоса пропускания была как можно шире пусть при среднем качестве канала, а есть другая — гоняют свою телефонию по IP сетям, там наоборот плевать на ширину канала, т.к. голос много не жрет, но очень важен житер и латенси и нет толерантности к потерям. Естественно что для этих компаний мониторинг будет организован по-разному и внимание будет уделяться разным показателям.
Не совсем фреймворк, скорее набор драйверов и сетевых "улучшайзеров" для работы других инструментов, сам по себе понятно не тестирует но прокачивает сетевую подсистему сервера под высокие нагрузки. Сравнивать надо не отдельно DPDK, а комплекс из инструментов против аппаратного блоба. Проблемы готовых анализаторов я описал выше, основная — не возможность кастомизировать под свои сценарии. Грубо говоря мне нужно протестировать только прохождение udp пакетов определенного размера, чтоб понять правильно ли настроен QoS и фильтры, но большинство анализаторов в виде коробки мне не дадут собрать свой собственный пакет из кусков и растиражировать. Вот банальная задача для многих провайдеров, ограничить скорость по торрентам в часы пик, но при этом выдать приоритет голосу и видео. На собственном анализаторе я делаю пакет, моделирующий торрент трафик, запускаю на живой анализ при этом подкручиваю фильтры и смотрю в реальном времени лучше или нет, в мультивендорной сети правила могут работать мягко говоря "неожиданно", а так поработали с определенными типами трафика пару часов на стенде и знаем что куда нужно оптимизировать. Или другая задача, вот мне надо проверить как поведет себя сеть под DNS/NTP amplification, на открытом решении я в лабораторных условиях воссоздаю определенный объем потока нужных мне пакетов и смотрю на сколько это нагружает и что, для того чтоб это же проделать на готовой коробке мне минимум год надо задалбывать ее разработчиков, чтоб впилили конкретную фишку и отвалить за это мешок бабла. Я не говорю что у аппаратных средств нет сценариев применения, но они не панацея и хочется услышать от производителя конкретные примеры где их решение "сделает" конкурентов, а не "покупайте нашу панацею, все остальные говно"
Так и задача производителя донести сценарии применения своего устройства, показать что вот вы раньше, допустим, таскали с собой ноутбук с запущенным коллектором и анализатором трафика, вам надо было найти на устройстве свободный порт, зайти настроить зеркалирование трафика, и не факт, что оно есть, либо тащить с собой не дешевые призмы, а потом только провести анализ, мы же предлагаем ставить в разрыв и быстро видеть такие-то и такие-то показатели, вы экономите время и можете брать для диагностики менее квалифицированного инженера. Да за такие кейсы по каждой железке я бы первый поблагодарил автора а в случае реально удобных и не дорогих устройств включил бы их в бюджет на следующий квартал, а нагнетание обстановки в перемешку с теориями заговора не красят даже корпоративный блог.
Я себе поставила задачу ознакомить читателей о том, что существуют аппаратно-программные тестеры-анализаторы, а не прорекламировать оборудование конкретного производителя. Практически любой измеритель можно поставить в разрез, задать на нем любые интересующие параметры и получить данные себе на телефон или e-mail. Про конкретные кейсы я вовсе не против, давайте я к вам приеду, установлю тестеры-анализаторы или зонды и мы у вас все измерим, но вы мне подпишете, что вы не против публикации результатов в СМИ. Хабр это ведь не тендерная площадка чтоб говорить о ценах, правда?
Вот недавняя статья от другой компании, где читателя ознакамливают с проблемой и предлагают пути решения, тоже реклама, но читать приятно https://habrahabr.ru/company/muk/blog/279189/ У вас же голословный поток сознания не подтвержденный ни какими фактами даже в данном сообщении:
Вот меня интересует трафик в разрезе протоколов и адресов источника/назначения, то что, например, умеет любой анализатор на основе ipfix, в каком из ваших решений это есть? Или вот я хочу видеть в потоке только http трафик, причем не важно на каком он порту идет, а не только на 80, какой из ваших анализаторов это умеет? Вот ткните меня в спецификацию на вашем сайте, не надо абстрактных рассуждений. А даже ехать не нужно, давайте я вам банально вылью полный ipfix с сенсора, а вы своим анализатором расскажете где на данном сенсоре есть проблемный трафик, какой вообще трафик ходит не основываясь на номерах портов?
Практически любой измеритель можно поставить в разрез, задать на нем любые интересующие параметры и получить данные себе на телефон или e-mail.
Вот меня интересует трафик в разрезе протоколов и адресов источника/назначения, то что, например, умеет любой анализатор на основе ipfix, в каком из ваших решений это есть? Или вот я хочу видеть в потоке только http трафик, причем не важно на каком он порту идет, а не только на 80, какой из ваших анализаторов это умеет? Вот ткните меня в спецификацию на вашем сайте, не надо абстрактных рассуждений. А даже ехать не нужно, давайте я вам банально вылью полный ipfix с сенсора, а вы своим анализатором расскажете где на данном сенсоре есть проблемный трафик, какой вообще трафик ходит не основываясь на номерах портов?
А еще дама то ли путает, то ли не понимает разницы между Ethernet и интернет каналом. Сначала собирается тестировать Ethernet, потом как то плавно это превращается в тестирование качества телематических услуг.
А качество передачи данных по Ethenet никогда не превращается в доступ в Интернет? Или что мы тут все делаем?
Я вам процитирую википедию:
А Интернет канал это, по большей части, все что выше канального уровня модели OSI. Начиная с IP протокола и далее.
Ethernet определяют проводные соединения и электрические сигналы на физическом уровне, формат кадров и протоколы управления доступом к среде — на канальном уровне модели OSI
А Интернет канал это, по большей части, все что выше канального уровня модели OSI. Начиная с IP протокола и далее.
С каких это пор количество ссылок по той или иной теме доказывает правдивость утверждения? Вы подменяете понятия.
Поверх L2 есть еще какие-то каналы? Окей, я попробовал в поисковике поискать словосочетания «Ethernet channel» и «UDP channel» и сравнить количество результатов, Вы тоже попробуйте.
Что вы хотели этим сказать? Что их нет потому что мало ссылок на UDP против Ethernet? Поищите IP channel.
На мой взгляд Ethernet это достаточно конкретная вещь. Это всё равно что транспорт и автомобиль. Транспорт = Internet канал. Автомобиль = Ethernet. Поэтому прочитав заголовок "секреты тестирования ethernet" я ожидал увидеть как будут грузить свитчи, убивать сетевые карточки и выжимать все из последних 100 метров кабеля. Расскажут как потестить качество задели розетки и патч панелей. На деле же нам рассказали, что софт — фуфло. Покупайте наши тестеры или берите в аренду.
Кстати о тестировании.
У нас есть задача тестировать SFP+ (если они сразу мертвые — еще полбеды, но бывает так, что она начинает просто давать потери, причем не сразу), и 10G-линки в сборе. Посоветуйте, пожалуйста, вашу коробочку с поддержкой 10G, и будет ли целесообразно её применение именно для этих целей. Я так понимаю, нам поможет Беркут-ETX, но может мы не правы?;)
У нас есть задача тестировать SFP+ (если они сразу мертвые — еще полбеды, но бывает так, что она начинает просто давать потери, причем не сразу), и 10G-линки в сборе. Посоветуйте, пожалуйста, вашу коробочку с поддержкой 10G, и будет ли целесообразно её применение именно для этих целей. Я так понимаю, нам поможет Беркут-ETX, но может мы не правы?;)
Коробочка ETX запросто может помочь, она и инфу с sfp показывает, если доступно. Но это в общем-то все могут)
Коробочка нужна правильная. Чтобы вручить монтажникам и больше не возвращаться к вопросу "ой а чо у нас скорость низкая, ой а у нас ошибки на линке вылезли"
мы, когда sfp+ подбираем для поставки со свичом, прогоняем их BER-тестом при помощи того же ETX. но все ведь понимают, что не только в sfp/sfp+ дело. оптика ведь тоже — немножко наука о контактах.
для тестирования 10G-линков наш дивайс, конечно, подходит: нагрузку 100% может создать (с пакетами от 64 байт до 64 килобайт), битовые ошибки посчитает и параметры sfp-модуля покажет. но монтажников всё равно придётся обучать сначала.
ps. не буду спорить, хороший современный комп это всё тоже может. кроме, разве что, 100% нагрузки на маленьких пакетах (но нужны ли такие тесты?). правда, чтобы обеспечить точность измерений, придётся помучаться. и с собой его тяжелее таскать, чем портативный прибор. а результаты измерения с точки зрения метрологов — вообще отдельный вопрос ;)
для тестирования 10G-линков наш дивайс, конечно, подходит: нагрузку 100% может создать (с пакетами от 64 байт до 64 килобайт), битовые ошибки посчитает и параметры sfp-модуля покажет. но монтажников всё равно придётся обучать сначала.
ps. не буду спорить, хороший современный комп это всё тоже может. кроме, разве что, 100% нагрузки на маленьких пакетах (но нужны ли такие тесты?). правда, чтобы обеспечить точность измерений, придётся помучаться. и с собой его тяжелее таскать, чем портативный прибор. а результаты измерения с точки зрения метрологов — вообще отдельный вопрос ;)
>> она и инфу с sfp показывает, если доступно.
Полагаю, речь идет всего лишь о DDMI? Если да, то в чем смысл тестирования, если DDMI можно считать любой железякой, которая понимает DDMI? Мне кажется речь шла именно о тестировании реальных показателей. А посмотреть DDMI — это не тест, это справка.
Полагаю, речь идет всего лишь о DDMI? Если да, то в чем смысл тестирования, если DDMI можно считать любой железякой, которая понимает DDMI? Мне кажется речь шла именно о тестировании реальных показателей. А посмотреть DDMI — это не тест, это справка.
А вы статью читали? Что написано какие тесты выполняются и какие алгоритмы мы разработали для исключения ошибок и получения наиболее достоверных данных? Информация с spf не более чем фича, и как я написала ее могут выводить все и кто угодно?
>> А вы статью читали?
Я статью читал, а вы? Почему вы меня об этом спрашиваете, когда после прочтения вашей статьи, где ни слова про тестирование sfp, Night_Snake задает вполне разумный вопрос о тестировании sfp, которые могут давать потери, причем не сразу, а вместо этого вы ему отвечаете, что да, мы можем снять информацию с sfp. Это все равно что считать номинальные характеристики сетевой карты или свича, сказав, что это тест.
Какой из алгоритмов в результате теста может сказать, что вот этот SFP — плохой, а вот этот — ништяк?
Я статью читал, а вы? Почему вы меня об этом спрашиваете, когда после прочтения вашей статьи, где ни слова про тестирование sfp, Night_Snake задает вполне разумный вопрос о тестировании sfp, которые могут давать потери, причем не сразу, а вместо этого вы ему отвечаете, что да, мы можем снять информацию с sfp. Это все равно что считать номинальные характеристики сетевой карты или свича, сказав, что это тест.
Какой из алгоритмов в результате теста может сказать, что вот этот SFP — плохой, а вот этот — ништяк?
Crazybrake ответил 23 марта 2016 в 15:08
Не знаю, правильно ли я понял. Я втыкаю в девайс 2 SFP, соединяю их оптикой, прогоняю берами, на выходе получаю инфу, что беры зашкаливают или инфу, что SFP №1 — убитая?
если sfp/sfp+ не "одноглазый", то проще замкнуть rx на tx и тестировать. с мерами предосторожности, естественно (аттенюатор для дальнобойных модулей обязателен). btw, в 10g приборчике один порт для sfp+, поэтому тестировать сразу оба модуля не получится.
в гигабитном приборе можно тестировать пару, там два порта. но на практике "битых" 1g sfp меньше, чем 10g sfp+ и тестировать гиг не так интересно, как десятку ;)
в гигабитном приборе можно тестировать пару, там два порта. но на практике "битых" 1g sfp меньше, чем 10g sfp+ и тестировать гиг не так интересно, как десятку ;)
Можете так-же глянуть на продукцию IXIA, у них есть как софтварные решения так и ПАКи.
Один клиент с коробочкой способен сделать техотделу провайдера месяц изощренного секса. Потому что "коробочка показывает, что на 64 байтном пакете у меня 950 мбит, а должно быть 1000".
При том, что клиент никогда не будет использовать этот канал на 64-байтных пакетах при 1.5 мппс. Он там RDP гонять будет.
Коробочка автоматом умеет находить в л3 сети провайдера ECMP и LAG и тестировать все пути? Не думаю
Коробка выдаст 16k+ LSP на предмет тестирования Р-устройств и FRR в сети для этого количества транзитных LSP? Вряд ли.
Коробка такая нужна, когда непонятное железо, ты на нем делаешь L2VPN и тебе надо понять, железный он или софтовый, есть ли проблемы с максимальным количеством ппс…
Коробка хорошая, но со специфичными задачами, "не для всех".
При том, что клиент никогда не будет использовать этот канал на 64-байтных пакетах при 1.5 мппс. Он там RDP гонять будет.
Коробочка автоматом умеет находить в л3 сети провайдера ECMP и LAG и тестировать все пути? Не думаю
Коробка выдаст 16k+ LSP на предмет тестирования Р-устройств и FRR в сети для этого количества транзитных LSP? Вряд ли.
Коробка такая нужна, когда непонятное железо, ты на нем делаешь L2VPN и тебе надо понять, железный он или софтовый, есть ли проблемы с максимальным количеством ппс…
Коробка хорошая, но со специфичными задачами, "не для всех".
Один клиент с коробочкой способен сделать техотделу провайдера месяц изощренного секса. Потому что «коробочка показывает, что на 64 байтном пакете у меня 950 мбит, а должно быть 1000».Это если у техотдела нет _своей_ коробочки :) А вот вооруженный коробочкой техотдел провайдера способен сделать вот то самое изощренное поставщику оборудования (SFP, медиаконверторов, свичей, etc). Прелесть всех этих коробочек в том, что на выходе получается протокол внушительного вида, в который очень удобно тыкать носом. В том числе и неграмотного клиента с 64-байтными пакетами тыкать носом в его-же протокол :)
Один клиент с коробочкой способен сделать техотделу провайдера месяц изощренного секса.
клиент никогда не будет использовать этот канал на 64-байтных пакетах при 1.5 мппс. Он там RDP гонять будет.
А я вам расскажу, почему так бывает. И как раз про RDP. Реальная история — однажды у нас люди стали отваливаться от терминальных ферм. Со стороны клиента — ошибка протокола, со стороны сервера — ошибки службы Winlogon. Наши сетевики отмахиваются — канал работает, пинги бегают, другие приложения бегают, голос-видео бегает, скорость показывает… И будь это один сервер, я бы, скорее всего, так и завис в попытках выяснить, что же не так со стороны винды. Но здравый смысл подсказывал, что сразу несколько серверов в разных терминальных фермах при отсутствии на них каких-либо изменений начать глючить одинаковым образом не могут. И стал извращаться с проверкой канала связи подручными средствами. Так вот единственный эффект, который я смог быстро нарыть — канал отказывался пропускать пакеты больших (несколько килобайт) размеров. И вот уже это я смог предъявить нашим сетевикам, которые пошли разбираться с провайдером. Что там навертел провайдер — так в итоге и осталось неясным, но косяк они признали и решили.
Поэтому не надо удивляться, что клиент иногда тестирует странные вещи — сколько там у провайдера слоев разной инкапсуляции со странными настройками, клиенту неизвестно, и как эти слои между собой взаимодействуют, иногда не знает не только провайдер, но авторы кода решения. :)) А клиенту в такой ситуации только и остаётся, что дуть на воду, устраивать шаманские тесты, и надеяться, что ничего не заглючит.
К большому сожалению, в области приема в эксплуатацию, тестирования каналов ethernet существуют системные недоработки в области организационных, нормативных документов. Порядок приема канала не описан, и т.п., техническое измерение это только одна сторона процесса. Есть методики измерения, а вменяемого приказа минсвязи нет.
Приказа нет, а международные стандарты есть, есть сертификация минсвязи, приборы проходят поверку и могут быть использованы в суде. Так что для компании, у которой несколько тысяч вланов по всей стране в аренде, то проще ставить централизованные зонды в разрыв, мониторить качество и выставлять неустойки, главное чтоб SLA был описан в договоре, а не как обычно — "канал доступа на скорости до 10G" с таким договором никому ничего не докажешь. А небольшие операторы могут взять анализатор в аренду, в любой продажной лавке, за сущие копейки.
А есть какие либо стандарты касательно проверки оптики?
Вот кстати да. Тестеры-анализаторы, как и любое другое оборудование дают в аренду, так что можно даже не покупать и не просить у знакомых, а просто взять в аренду.
> софтовые утилиты определяют пропускную способность канала без учета размера заголовков, что на разных размерах пакетов вносит в подобное тестирование определенную неразбериху.
Совершенно неясно, зачем учитывать заголовки. Что за неразбериха? Тот же iperf умеет указывать конкретные размеры пакетов.
> Вы не сможете оценить качество арендованного vlan, глядя на график загрузки канала или скачивая объемные файлы из интернета.
Да? Почему? А что такое вообще «качество VLAN» и как его обнаруживают другие методы?
> Почему speedtest.net не является доказательством скорости предоставляемого канала наверное не стоит уточнять?
Смотря что мы доказываем. То, что как минимум данная скорость выдерживается — вполне. А там, если по правильным каналам да без левого трафика…
Тестирование Ethernet при помощи MPLS? Да и http и прочие тут тоже излишни. А по ссылке на BER у вас так и написано «Означает ли все это, что BERT абсолютно неприменим для паспортизации сетей Ethernet? Для паспортизации — скорее всего да, т.к. для этого существует методика RFC2544, тесты которой лучше отражают специфику пакетных сетей.»
Совершенно неясно, зачем учитывать заголовки. Что за неразбериха? Тот же iperf умеет указывать конкретные размеры пакетов.
> Вы не сможете оценить качество арендованного vlan, глядя на график загрузки канала или скачивая объемные файлы из интернета.
Да? Почему? А что такое вообще «качество VLAN» и как его обнаруживают другие методы?
> Почему speedtest.net не является доказательством скорости предоставляемого канала наверное не стоит уточнять?
Смотря что мы доказываем. То, что как минимум данная скорость выдерживается — вполне. А там, если по правильным каналам да без левого трафика…
Тестирование Ethernet при помощи MPLS? Да и http и прочие тут тоже излишни. А по ссылке на BER у вас так и написано «Означает ли все это, что BERT абсолютно неприменим для паспортизации сетей Ethernet? Для паспортизации — скорее всего да, т.к. для этого существует методика RFC2544, тесты которой лучше отражают специфику пакетных сетей.»
Тестирование Ethernet при помощи MPLS?
Извините, никак не могу найти, откуда вы подчерпнули такую информацию. И да, к BERT все четко описано, что это не стандарт, но качество предоставляемых услуг должно быть выше минимумов паспортизации, и стоит провести жирную черту между действительно довольным клиентом с неожиданными потребностями и предоставляемыми услугами с формулировкой SLA — "предоставляется, как есть".
> Извините, никак не могу найти, откуда вы подчерпнули такую информацию.
Ну так из статьи выше:
> Так как качество ethernet-канала это совокупность многих факторов, следовательно, правильное тестирование должно максимально охватывать все эти совокупности. При тестировании необходимо учесть многие аспекты и было бы полезно иметь расширенные возможности, такие [...] поддержку MPLS
Про «качество VLAN» всё-таки хотелось бы услышать ответ.
Ну так из статьи выше:
> Так как качество ethernet-канала это совокупность многих факторов, следовательно, правильное тестирование должно максимально охватывать все эти совокупности. При тестировании необходимо учесть многие аспекты и было бы полезно иметь расширенные возможности, такие [...] поддержку MPLS
Про «качество VLAN» всё-таки хотелось бы услышать ответ.
Про «качество VLAN» всё-таки хотелось бы услышать ответ.
Нет уж, давайте сначала разберемся как "поддержку MPLS" вы превратили в "Тестирование Ethernet при помощи MPLS?" Давайте вы мне сначала вот это объясните.
В статье про тестирование Ethernet вы пишите про поддержку MPLS. В абзаце, который касается качества Ethernet канала. В предложении, которое начинается со слов «При тестировании необходимо участь». Очевидно, что «поддержка MPLS» касается тестирования Ethernet.
Ваш тон в корпоративном блоге крайне негативно сказывается на впечатлении о компании.
Ваш тон в корпоративном блоге крайне негативно сказывается на впечатлении о компании.
Как наличие или отсутствие кармы должно влиять на высказывание мнения на ресурсе, вот у вас 0 и без публикаций? Вас стоит игнорировать по умолчанию? Карма показатель отношения к пользователю на ресурсе, но никак не обоснованности мнения.
> А пользователи оценивают поведение (я бы ввел метрику «дружелюбность»). Так и вот — что мы наблюдаем выше? Пользователь с отрицательной «дружелюбностью» дает совет, как повысить «дружелюбность». Ну да, ему ли не знать…
1. Я не давал советов, как повысить карму на сайте. Подмена понятий засчитана.
2. Мне нельзя повышать карму, только понижать, таким образом оценивать моё «поведение» можно только в одну сторону.
3. Раз это для вас такой веский аргумент, можете полюбопытствовать мою «дружелюбность» до принудительного обнуления: http://web.archive.org/web/20140830091445/http://habrahabr.ru/users/Sing/
1. Я не давал советов, как повысить карму на сайте. Подмена понятий засчитана.
2. Мне нельзя повышать карму, только понижать, таким образом оценивать моё «поведение» можно только в одну сторону.
3. Раз это для вас такой веский аргумент, можете полюбопытствовать мою «дружелюбность» до принудительного обнуления: http://web.archive.org/web/20140830091445/http://habrahabr.ru/users/Sing/
> У меня крайне мало информации о Вас — кто Вы в профессиональном плане, где сфера Ваших интересов, какова Ваша экспертиза. А вдруг Вы, извините, сеошник?
Это неважно. Попробуйте почитать тут: https://ru.wikipedia.org/wiki/Ad_hominem
Если и после этого не поймёте, то увы, расписываюсь в своём бессилии.
Это неважно. Попробуйте почитать тут: https://ru.wikipedia.org/wiki/Ad_hominem
Если и после этого не поймёте, то увы, расписываюсь в своём бессилии.
Совсем это не дружелюбность, вот несколько примеров, попробуйте самым дружелюбным тоном рассказать на ресурсе об вещах, не имеющих подтверждения в науке, высказаться положительно о принимаемых законах или поучаствовать в холиваре технология А против технологии Б, я вас уверяю, будьте вы самым миролюбивым, вежливым и дружелюбным человеком в мире — ваша карма уйдет в такой глубокий минус, что просто больше не сможете писать. Представитель коммерческой компании, пишущий статью — это лицо компании и продукта, прибыль компании и репутация, на него всегда будут нападки на любом ресурсе и отбиваться от них вежливо и аргументированно входит в правила игры, тогда как сторонние наблюдатели смотрят за этим и принимают решение стоит ли связываться с компанией и нести туда свои деньги. Компания может выпускать отличный продукт, но если не может его грамотно продать, рассказать потенциальному клиенту почему именно этот продукт лучше продукта конкурента, как этот продукт правильно использовать и где лучше применить, такая компания не сможет заработать на свободном рынке. Лично мое мнение, только мое и я никому его не навязываю — статья откровенно не удалась, много переходов от одного аспекта к другому идут необоснованные нападки на конкурентов, но не показаны свои сильные стороны, к чему-то прилеплены цитаты из RFC плюс ну очень много воды и общих рассуждений за минимумом конкретики. Для меня тема анализа трафика очень интересна, по-этому я прочел ее полностью и ввязался в спор с представителем вендора, но общее впечатление как от испорченного продукта, может он и полезный, но я не хочу его покупать.
Вы не знаете, какая репутация у Mail.Ru?
Если я ничего не упустил у них отличные технические статьи, но репутация полностью испорчена производством малварей, всяких гвардов и очень агрессивным маркетингом, в техническом плане к ним претензий нет
Вы, свой камень зачем кинули?
Так я же тролль :) А вообще из-за нападок на открытые продукты, не было бы их — прошел мимо.
Да, в учебнике так и написано. Жизнь значительно сложнее, чем любой учебник.
Ключевая фраза — на свободном рынке. Я не лезу в госзапупки и прочее, там совсем другие правила, выход со статьей на открытый ресурс без возможности модерации чужих комментариев — это именно свободный рынок, на их сайте я бы в дискуссию не вступал, потерли бы, чего время тратить.
Вот взять число просмотров
По этому показателю обзор нового китайского планшета или обсуждение очередного маразма роскомпозора сделает вообще всех, чего заморачиваться сфоткать красиво любимого кота представителя компании и лайков будет еще больше.
Вы выбираете продукт не по техническим характеристикам, а по статьям в блоге?
Вы точно инженер?
В том числе и по статьям, комьюнити часто в разы важнее самого продукта и из 2х продуктов я выберу тот, где комьюнити больше даже при некритичном отставании по технологиям, а общение в блоге косвенно показывает с чем столкнется приобретатель продукта при обращении в саппорт. Я вот по нескольким продуктам на представителей выходил именно через корпоративный блог и в случае проблем есть ответственность перед читателями ресурса + репутационный страх, а не пофиг на всех, продали и хоть трава не расти, репутация испортилась, ну так имя сменим. Технические показатели в среднем по больнице в сетях давно примерно сровнялись и выбор строится именно на открытости компании, комьюнити, поддержке и живом общении. Сейчас приведу пример, который у многих вызовет ненависть, но уж очень наглядный, те же телефоны Apple пользуются такой популярностью не из-за своих технических характеристик, будем откровенны, многие андроид устройства их превосходят по количеству попугаев и возможностей, но при этом у эпл поддержка и лояльность к потребителю делает на голову почти всех остальных вендоров в этом сегменте и купив айфон можно рассчитывать на новые прошивки и обновления безопасности еще не один год, а купив самый навороченный андроид от именитой компании через пол года может оказаться что пользователь нафиг ей не сдался, нужно новую модель делать, а старая дырявая и с багами, так пофиг пусть новую купит. Так что да, многие бренды я выбираю из-за лояльности, которая в том числе выражена в публичных публикациях. А даже будучи инженером я все равно вынужден верить на слово ТТХ на сайте компании, т.к. не имею возможности их проверить не купив продукт в большинстве случаев, так что приходится полагаться именно на отношение к компании.
Я не даю совет — я констатирую тон собеседника.
А вот то, что отрицательная карма — это повод обращаться в стиле «я вам тут покажу как жить надо» или «сперва добейся, а потом советуй», вы понимаете неправильно.
А вот то, что отрицательная карма — это повод обращаться в стиле «я вам тут покажу как жить надо» или «сперва добейся, а потом советуй», вы понимаете неправильно.
> Ну да, Ваш собеседник несколько эмоционален, все мы люди. Но это же некоторая очевидность?
Очевидно для стороннего наблюдателя, и явно неочевидно для автора комментария.
> Я не очень знаю местные правила хорошего тона — в комментариях к статье обычно обсуждается заданная ей тема, или психологические консультации тоже допустимы?
Большая часть комментария имела прямое отношение к теме поста. Вторая часть направлена на оценку собеседника. Я мог бы поставить, например, минус комментарию. Но, во-первых, не могу, а во-вторых, это не так эффективно.
> Да — как правило, официальную позицию компании (as in «пишу от имени компании») выражают специально уполномоченные люди в специально отведенных для этого местах.
Ну в том-то и дело, что кто попало в блог компании написать не сможет.
Очевидно для стороннего наблюдателя, и явно неочевидно для автора комментария.
> Я не очень знаю местные правила хорошего тона — в комментариях к статье обычно обсуждается заданная ей тема, или психологические консультации тоже допустимы?
Большая часть комментария имела прямое отношение к теме поста. Вторая часть направлена на оценку собеседника. Я мог бы поставить, например, минус комментарию. Но, во-первых, не могу, а во-вторых, это не так эффективно.
> Да — как правило, официальную позицию компании (as in «пишу от имени компании») выражают специально уполномоченные люди в специально отведенных для этого местах.
Ну в том-то и дело, что кто попало в блог компании написать не сможет.
Ваш тон в корпоративном блоге крайне негативно сказывается на впечатлении о компании.
Не стоит заниматься подменой понятий так явно, все же.
А где же тут подмена понятий? Вы — автор поста в корпоративном блоге, соответственно вы пишите от имени компании.
Я всё ещё жду ответа на вопрос про качество VLAN.
Я всё ещё жду ответа на вопрос про качество VLAN.
друзья, пожалуйста, не надо ругаться.
заметка субъективная, зато породила дискуссию, из которой можно извлечь много полезного. насчёт качества VLAN'а — сам не понимаю о чём речь. не зря же в конце статьи написано, что "мнение компании может не совпадать с мнением автора" :))
заметка субъективная, зато породила дискуссию, из которой можно извлечь много полезного. насчёт качества VLAN'а — сам не понимаю о чём речь. не зря же в конце статьи написано, что "мнение компании может не совпадать с мнением автора" :))
Подмена понятий это когда одни слова заменяются другими. Пример: "поддержка MPLS" и "Тестирование Ethernet при помощи MPLS?".
Поддержка протоколов тестирующими устройствами нужна для того, чтоб тестировать сети, где эти протоколы используются.
Вы арендуете виртуальные каналы связи? Каким бы не был ваш ответ, виртуальные каналы связи активно используются и являются очень распространенной услугой.
Потому что график загрузки канала — это график загрузки канала, а не определение пропускной способности. Вот, допустим, клиент арендует 10G, на графике загрузки вполне себе все прилично выглядит, есть редкие пиковые значение до 8G, средняя скорость 6G, как это может означать реальную пропускную способность? А сейчас вот на графике 1G, а почему? Потому что пользователи ничего не скачивают, или потому что пропускная способность в конкретный момент времени низкая?
Допустим качаем объемный файл, а скорость меньше 10G, о чем это говорит? Варианты ответа: a) О том, что коллега тоже качает файл; b) О том что скорость отдачи файла ниже чем 10G, в виду того, что винчестер медленный; c) Наш компьютер для теста не справляется с 10G, сетевую карту кстати — тестировали?
Такое тестирование запросто можно назвать викториной.
Это же касается и speedtest. Вы пишете — "Смотря что мы доказываем." в статье написано — мы доказываем SLA. Если нет SLA — нет и разговоров о тестировании, даже ICMP не нужен чтоб понять работает сеть или нет.
Качество любого канала связи, включая и vlan, состоит в оценке качества передачи данных, какая передача данных должна быть — описано в соответствующих протоколах передачи данных, в моей статье подробно описываются алгоритмы тестирования, так же существует "соглашение о качестве предоставляемых услуг" то есть Service Level Agreement, то есть это когда в договоре написано например так: "Услуга предоставления виртуального канала передачи данных на скорости не менее 10G, цена — 10000р. в месяц". Десять тысяч рублей клиент платит, тут все ясно, а как понять получает ли он услугу в полном объеме — ответ дает статья.
Поддержка протоколов тестирующими устройствами нужна для того, чтоб тестировать сети, где эти протоколы используются.
про качество VLAN
Вы арендуете виртуальные каналы связи? Каким бы не был ваш ответ, виртуальные каналы связи активно используются и являются очень распространенной услугой.
Вы не сможете оценить качество арендованного vlan, глядя на график загрузки канала или скачивая объемные файлы из интернета.
Да? Почему?
Потому что график загрузки канала — это график загрузки канала, а не определение пропускной способности. Вот, допустим, клиент арендует 10G, на графике загрузки вполне себе все прилично выглядит, есть редкие пиковые значение до 8G, средняя скорость 6G, как это может означать реальную пропускную способность? А сейчас вот на графике 1G, а почему? Потому что пользователи ничего не скачивают, или потому что пропускная способность в конкретный момент времени низкая?
Допустим качаем объемный файл, а скорость меньше 10G, о чем это говорит? Варианты ответа: a) О том, что коллега тоже качает файл; b) О том что скорость отдачи файла ниже чем 10G, в виду того, что винчестер медленный; c) Наш компьютер для теста не справляется с 10G, сетевую карту кстати — тестировали?
Такое тестирование запросто можно назвать викториной.
Это же касается и speedtest. Вы пишете — "Смотря что мы доказываем." в статье написано — мы доказываем SLA. Если нет SLA — нет и разговоров о тестировании, даже ICMP не нужен чтоб понять работает сеть или нет.
А что такое вообще «качество VLAN» и как его обнаруживают другие методы?
Качество любого канала связи, включая и vlan, состоит в оценке качества передачи данных, какая передача данных должна быть — описано в соответствующих протоколах передачи данных, в моей статье подробно описываются алгоритмы тестирования, так же существует "соглашение о качестве предоставляемых услуг" то есть Service Level Agreement, то есть это когда в договоре написано например так: "Услуга предоставления виртуального канала передачи данных на скорости не менее 10G, цена — 10000р. в месяц". Десять тысяч рублей клиент платит, тут все ясно, а как понять получает ли он услугу в полном объеме — ответ дает статья.
> Подмена понятий это когда одни слова заменяются другими. Пример: «поддержка MPLS» и «Тестирование Ethernet при помощи MPLS?».
Я же вам дал конкретную цитату. Ещё раз: «При тестировании [..] было бы полезно иметь [...] поддержку MPLS». Давайте я перефразирую вопрос: Каким образом достигается польза от поддержки MPLS при тестировании Ethernet?
> Потому что график загрузки канала — это график загрузки канала, а не определение пропускной способности.
Пропускная способность бывает номинальной и эффективной. Номинальная — та, что в спецификации. Эффективная — та, что замерена на реальных данных.
> Потому что пользователи ничего не скачивают, или потому что пропускная способность в конкретный момент времени низкая?
Ясно. А каким образом мы можем вычислить эффективную пропускную способность, учитывая других пользователей?
> Вы арендуете виртуальные каналы связи? Каким бы не был ваш ответ, виртуальные каналы связи активно используются и являются очень распространенной услугой.
> Качество любого канала связи, включая и vlan
VLAN не является каналом связи. Теперь понятно, вы перепутали VLAN и VPN.
Я же вам дал конкретную цитату. Ещё раз: «При тестировании [..] было бы полезно иметь [...] поддержку MPLS». Давайте я перефразирую вопрос: Каким образом достигается польза от поддержки MPLS при тестировании Ethernet?
> Потому что график загрузки канала — это график загрузки канала, а не определение пропускной способности.
Пропускная способность бывает номинальной и эффективной. Номинальная — та, что в спецификации. Эффективная — та, что замерена на реальных данных.
> Потому что пользователи ничего не скачивают, или потому что пропускная способность в конкретный момент времени низкая?
Ясно. А каким образом мы можем вычислить эффективную пропускную способность, учитывая других пользователей?
> Вы арендуете виртуальные каналы связи? Каким бы не был ваш ответ, виртуальные каналы связи активно используются и являются очень распространенной услугой.
> Качество любого канала связи, включая и vlan
VLAN не является каналом связи. Теперь понятно, вы перепутали VLAN и VPN.
Каким образом достигается польза от поддержки MPLS при тестировании Ethernet?
Если вы внимательно прочитаете весь абзац — станет достаточно очевидно, каким. Конечному пользователю канала, понимаете ли, глубоко безразлично тестирование собственно L1 и L2 уровней как таковое. Ему надо, чтобы приложения через него работали. Поэтому нужны инструменты тестирования, которые в состоянии проверить по возможности все уровни используемых в канале связи технологий.
VLAN не является каналом связи. Теперь понятно, вы перепутали VLAN и VPN.
Под VLAN, в зависимости от контекста, могут пониматься разные вещи. Что имелось в виду в данном конкретном случае — из этого самого контекста достаточно понятно. И это не синоним VPN. :))
> Если вы внимательно прочитаете весь абзац — станет достаточно очевидно, каким. Конечному пользователю канала, понимаете ли, глубоко безразлично тестирование собственно L1 и L2 уровней как таковое. Ему надо, чтобы приложения через него работали. Поэтому нужны инструменты тестирования, которые в состоянии проверить по возможности все уровни используемых в канале связи технологий.
Статья собственно про тестирование уровней L1 и L2. И в абзаце написано про тестирование именно Ethernet. И мне интересна именно эта связь, а не связь с требованиями пользователей.
> Под VLAN, в зависимости от контекста, могут пониматься разные вещи.
Интересно, что за контекст такой может быть, что мы под этим понимаем не Virtual Local Area Network?
> Что имелось в виду в данном конкретном случае — из этого самого контекста достаточно понятно. И это не синоним VPN. :))
Эээ… и что же имелось ввиду, если это не VPN?
Статья собственно про тестирование уровней L1 и L2. И в абзаце написано про тестирование именно Ethernet. И мне интересна именно эта связь, а не связь с требованиями пользователей.
> Под VLAN, в зависимости от контекста, могут пониматься разные вещи.
Интересно, что за контекст такой может быть, что мы под этим понимаем не Virtual Local Area Network?
> Что имелось в виду в данном конкретном случае — из этого самого контекста достаточно понятно. И это не синоним VPN. :))
Эээ… и что же имелось ввиду, если это не VPN?
Статья собственно про тестирование уровней L1 и L
Если вы, будучи посторонним человеком, полагаете, что знаете о целях и содержании статьи больше других читателей и даже её автора, и на этом основании считаете не относящимся к делу весь текст, где написаны прямо противоположные вашему мнению вещи, то конструктивный диалог вряд ли наладится. :)
И мне интересна именно эта связь, а не связь с требованиями пользователей.
Я вам объяснил связь в предыдущем ответе. Если вам непонятна мысль автора "при тестировании хорошо бы иметь расширенные возможности, вплоть до поддержки прикладных протоколов", и непонятно, зачем такая поддержка нужна — извините, не знаю, как вам ещё помочь. Мне, как человеку, услуги связи использующему, а не рассуждающему о них в вакууме, всё вполне очевидно.
Интересно, что за контекст такой может быть, что мы под этим понимаем не Virtual Local Area Network?
Ну, например, может иметься в виду собственно эта самая сеть (все устройства, в неё включенные), может — название конкретной настройки порта коммутатора (число), и т.д., и т.п.
Эээ… и что же имелось ввиду, если это не VPN?
Имелся в виду вполне конкретный способ организации VPN, а не любой VPN вообще.
> Если вы, будучи посторонним человеком, полагаете, что знаете о целях и содержании статьи больше других читателей и даже её автора, и на этом основании считаете не относящимся к делу весь текст, где написаны прямо противоположные вашему мнению вещи, то конструктивный диалог вряд ли наладится. :)
Я не говорил о том, что я знаю больше кого-то о содержании статьи. Я просто прочитал заголовок и решил, что он связан с содержанием.
> Мне, как человеку, услуги связи использующему, а не рассуждающему о них в вакууме, всё вполне очевидно.
Вы как человек «услуги связи использующий», видимо не знаете о многоуровневой модели сетевых технологий. То, что протоколы нижних уровней прекрасно работают независимо от протоколов верхних уровней — тоже. В то время как вы услуги связи используете, мы — разрабатываем, и нам было бы интересно, что имеет автор ввиду.
> Ну, например, может иметься в виду собственно эта самая сеть (все устройства, в неё включенные), может — название конкретной настройки порта коммутатора (число), и т.д., и т.п.
Нет, не может.
> Имелся в виду вполне конкретный способ организации VPN, а не любой VPN вообще.
И какой такой «конкретный способ организации VPN» имелся ввиду под VLAN?
Я не говорил о том, что я знаю больше кого-то о содержании статьи. Я просто прочитал заголовок и решил, что он связан с содержанием.
> Мне, как человеку, услуги связи использующему, а не рассуждающему о них в вакууме, всё вполне очевидно.
Вы как человек «услуги связи использующий», видимо не знаете о многоуровневой модели сетевых технологий. То, что протоколы нижних уровней прекрасно работают независимо от протоколов верхних уровней — тоже. В то время как вы услуги связи используете, мы — разрабатываем, и нам было бы интересно, что имеет автор ввиду.
> Ну, например, может иметься в виду собственно эта самая сеть (все устройства, в неё включенные), может — название конкретной настройки порта коммутатора (число), и т.д., и т.п.
Нет, не может.
> Имелся в виду вполне конкретный способ организации VPN, а не любой VPN вообще.
И какой такой «конкретный способ организации VPN» имелся ввиду под VLAN?
Статья собственно про тестирование уровней L1 и L2.
…
Я не говорил о том, что я знаю больше кого-то о содержании статьи.
:D. "Обвинению нечего добавить".
То, что протоколы нижних уровней прекрасно работают независимо от протоколов верхних уровней — тоже.
Речь идет об обратной ситуации — когда протоколы нижних уровней работают, а вот верхних — нет. И, чтобы сей факт не стал неприятным сюрпризом, тестеры оснащают дополнительными возможностями. А ещё интереснее становится, если вспомнить, что на дворе 2016 год, а не 80-е прошлого века, "нижний" Ethernet может совершенно неожиданно для некоторых оказаться "верхним" для транспортных или даже прикладных протоколов, и этот слоёный пирог может быть весьма толстым.
Нет, не может.
Что конкретно не может? Не могли бы вы изъясняться более полно?
И какой такой «конкретный способ организации VPN» имелся ввиду под VLAN?
Вероятно, выделение виртуальной L2 сети, используя технологии, описанные в стандарте 802.1q. Если автор имела в виду что-то другое, возможно, она меня поправит. Если ей не надоел этот флуд. :))
>> Статья собственно про тестирование уровней L1 и L2.
>>…
>>Я не говорил о том, что я знаю больше кого-то о содержании статьи.
>:D. «Обвинению нечего добавить».
Обвинение? Что? Где там про знание относительно кого-то? Что вы несёте?
> Что конкретно не может? Не могли бы вы изъясняться более полно?
Не может вся физическая сеть называться VLAN. И не может число проверяться на качество.
> Речь идет об обратной ситуации — когда протоколы нижних уровней работают, а вот верхних — нет.
Ещё раз, заголовок статьи: «Секреты тестирования Ethernet каналов».
> А ещё интереснее становится, если вспомнить, что на дворе 2016 год, а не 80-е прошлого века, «нижний» Ethernet может совершенно неожиданно для некоторых оказаться «верхним» для транспортных или даже прикладных протоколов, и этот слоёный пирог может быть весьма толстым.
Вот это мне неизвестно. Давайте примеры таких «прикладных протоколов», для которых L2 — это верхний уровень. Подсказка: можете не утруждаться, таких нет.
> Вероятно, выделение виртуальной L2 сети, используя технологии, описанные в стандарте 802.1q.
Чёрт возьми, 802.1q не связан с VPN и его качество нельзя измерить. Это настройка порта!
Диалог совершенно пустой ввиду вашей некомпетентности в вопросе и постоянных переходах на личности. Я могу понять ваш порыв стать Д'Артаньяном и защитить «даму в беде», однако даму никто не обижал — вопросы были заданы непосредственно по теме ею написанной статьи. И то, я не обрушивался с критикой, а вопросами намекал на нестыковки в статье. Вместо полемики на полстраницы при нормальной реакции это ограничилось бы двумя комментариями с последующей корректировкой статьи, только и всего.
>>…
>>Я не говорил о том, что я знаю больше кого-то о содержании статьи.
>:D. «Обвинению нечего добавить».
Обвинение? Что? Где там про знание относительно кого-то? Что вы несёте?
> Что конкретно не может? Не могли бы вы изъясняться более полно?
Не может вся физическая сеть называться VLAN. И не может число проверяться на качество.
> Речь идет об обратной ситуации — когда протоколы нижних уровней работают, а вот верхних — нет.
Ещё раз, заголовок статьи: «Секреты тестирования Ethernet каналов».
> А ещё интереснее становится, если вспомнить, что на дворе 2016 год, а не 80-е прошлого века, «нижний» Ethernet может совершенно неожиданно для некоторых оказаться «верхним» для транспортных или даже прикладных протоколов, и этот слоёный пирог может быть весьма толстым.
Вот это мне неизвестно. Давайте примеры таких «прикладных протоколов», для которых L2 — это верхний уровень. Подсказка: можете не утруждаться, таких нет.
> Вероятно, выделение виртуальной L2 сети, используя технологии, описанные в стандарте 802.1q.
Чёрт возьми, 802.1q не связан с VPN и его качество нельзя измерить. Это настройка порта!
Диалог совершенно пустой ввиду вашей некомпетентности в вопросе и постоянных переходах на личности. Я могу понять ваш порыв стать Д'Артаньяном и защитить «даму в беде», однако даму никто не обижал — вопросы были заданы непосредственно по теме ею написанной статьи. И то, я не обрушивался с критикой, а вопросами намекал на нестыковки в статье. Вместо полемики на полстраницы при нормальной реакции это ограничилось бы двумя комментариями с последующей корректировкой статьи, только и всего.
Диалог совершенно пустой ввиду вашей некомпетентности в вопросе и постоянных переходах на личности
, etc.
Я вот старательно (хотя, возможно, не всегда успешно) пытаюсь игнорировать подобное ваше поведение, но вы каждым постом всё нарываетесь и нарываетесь. :) Интересно, зачем?
Не может вся физическая сеть называться VLAN. И не может число проверяться на качество.
Безусловно, только вы снова дискутируете с самостоятельно придуманными утверждениями. Я писал иное.
Вот это мне неизвестно. Давайте примеры таких «прикладных протоколов», для которых L2 — это верхний уровень. Подсказка: можете не утруждаться, таких нет.
Вы слышали о технологиях, который позволяют сделать так, что машины в разных удаленных друг от друга местах полагают, что находятся в одной L2 сети, хотя на самом деле связаны через интернет? Модный термин SDN и всё такое? Под виртуальным "обычным Ethernet" там лежит какой-нибудь протокол туннелирования более высокого уровня. И было бы неплохо, если бы системы тестирования имели представление об этом.
Чёрт возьми, 802.1q не связан с VPN и его качество нельзя измерить. Это настройка порта!
Ох… Нет, это не "настройка порта". Это технология маркировки пакетов. И может использоваться как один из примитивных способов организации VPN. И, разумеется, качество подобного канала (на которое, помимо прочего, может влиять количество и приоритезация трафика, идущего по тем же физическим каналам, но в других VLAN) очень даже можно оценить.
>> Не может вся физическая сеть называться VLAN. И не может число проверяться на качество.
> Безусловно, только вы снова дискутируете с самостоятельно придуманными утверждениями. Я писал иное.
Да ладно? А это как понимать:
> Ну, например, может иметься в виду собственно эта самая сеть (все устройства, в неё включенные), может — название конкретной настройки порта коммутатора (число), и т.д., и т.п.
> Вы слышали о технологиях, который позволяют сделать так, что машины в разных удаленных друг от друга местах полагают, что находятся в одной L2 сети, хотя на самом деле связаны через интернет?
Нет. Даже не могу представить, зачем это нужно, когда есть VPN. Очень хочется гонять свой широковещательный трафик в Интернет?
> Модный термин SDN и всё такое?
SDN содержит контроллер сети, который, мне кажется, не может управлять узлами в Интернете. Впрочем, если у вас есть такая информация, прошу поделиться.
> Под виртуальным «обычным Ethernet» там лежит какой-нибудь протокол туннелирования более высокого уровня.
Даже если есть тоннели, пробрасывающие Ethernet кадры (кстати, интересно было бы почитать, скиньте ссылочку, сам не нашёл), тоннели не делают Ethernet верхним уровнем, над ним по-прежнему остаётся весь стек.
> Ох… Нет, это не «настройка порта». Это технология маркировки пакетов. И может использоваться как один из примитивных способов организации VPN.
Технология прямо? А не заключается ли она в том, что в пакет добавляется VID порта? Ну то есть, та самая настройка? И нет, это не способ организации VPN никоим образом.
> Безусловно, только вы снова дискутируете с самостоятельно придуманными утверждениями. Я писал иное.
Да ладно? А это как понимать:
> Ну, например, может иметься в виду собственно эта самая сеть (все устройства, в неё включенные), может — название конкретной настройки порта коммутатора (число), и т.д., и т.п.
> Вы слышали о технологиях, который позволяют сделать так, что машины в разных удаленных друг от друга местах полагают, что находятся в одной L2 сети, хотя на самом деле связаны через интернет?
Нет. Даже не могу представить, зачем это нужно, когда есть VPN. Очень хочется гонять свой широковещательный трафик в Интернет?
> Модный термин SDN и всё такое?
SDN содержит контроллер сети, который, мне кажется, не может управлять узлами в Интернете. Впрочем, если у вас есть такая информация, прошу поделиться.
> Под виртуальным «обычным Ethernet» там лежит какой-нибудь протокол туннелирования более высокого уровня.
Даже если есть тоннели, пробрасывающие Ethernet кадры (кстати, интересно было бы почитать, скиньте ссылочку, сам не нашёл), тоннели не делают Ethernet верхним уровнем, над ним по-прежнему остаётся весь стек.
> Ох… Нет, это не «настройка порта». Это технология маркировки пакетов. И может использоваться как один из примитивных способов организации VPN.
Технология прямо? А не заключается ли она в том, что в пакет добавляется VID порта? Ну то есть, та самая настройка? И нет, это не способ организации VPN никоим образом.
Да ладно? А это как понимать:
Ровно так, как написано — понятие VLAN может употреблять в разном контексте и, в зависимости от этого контекста, означать разные вещи. Брать употребление слова в одном контексте, переносить его в другой, после чего говорить "ой, ерунда" — не очень хороший способ вести содержательный разговор. Впрочем, языковую дискуссию я также прекращаю.
Нет. Даже не могу представить, зачем это нужно, когда есть VPN.
Если вкратце — затем, что бывает удобнее управлять своими распределенными сетями так, как если бы они были одной локальной сетью. Развернутый ответ требует отдельной большой статьи.
SDN содержит контроллер сети
SDN (software defined network) — это вообще просто концепция. Примерно как "cloud". :)) И в отсутствие (хочется верить, временное) единых стандартов каждый, кому это надо, развлекается по-своему.
кстати, интересно было бы почитать, скиньте ссылочку, сам не нашёл
Вот навскидку один из современных примеров — http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-03. А если поискать по Ethernet over IP, то и древности из прошлого века найдутся.
тоннели не делают Ethernet верхним уровнем, над ним по-прежнему остаётся весь стек.
С этим никто не спорил. Речь шла о том, что бывают случаи, когда работа Ethernet (не самого нижнего уровня, а того, который видит клиент) зависит от протоколов, которые формально в модели OSI расположены выше, а на практике используются для туннелирования Ethernet-трафика.
А не заключается ли она в том, что в пакет добавляется VID порта? Ну то есть, та самая настройка?
И "та самая настройка", и много чего ещё, помимо неё.
это не способ организации VPN никоим образом.
VPN, в общем случае — всего лишь организация частной сети по публичному каналу связи. Если провайдер выделяет клиенту VLAN и гонит его трафик по своему каналу вместе с каким-то другим — это, по определению, VPN. Но суть вопроса, напомню, не в том, VPN это или нет, а в том, что маркировка пакетов по 802.1q — это таки используемый на практике способ предоставить клиенту канал связи с некоторыми характеристиками, которые можно измерять и оценивать.
Я не знаю, как работает Hamachi, но я слышал, что эту программу используют геймеры, чтобы их компы думали, что они находятся в одном L2 сегменте. И да, это не делает Ethernet верхним уровнем, это добавляет еще один L2 уровень, поверх которого также есть L3, L4. Тут получается слоеный пирог что-то типа L2 — L3 — L4 — L2 — L3 — L4. Если я правильно понял принцип работы программы со слов знакомых геймеров, конечно.
И Vlan это не просто настройка порта. Если бы дело ограничивалось добавлением в L2 заголовок поля с тегом с дальнейшей коммутацией, то да, но на деле на базе вланов может работать множество всяких алгоритмов на коммутаторах (всякие снупинги, туннели, шейпинги, куосы, аклы), которые даже не все и везде работают аппаратно, и поэтому тоже могут портить этот самый «влан».
Однако я не поддерживаю мнение, что залог хорошего интернета — это качественный Ethernet/Vlan. На практике (статистически) я вижу, что интернет портится в 80% случаев на стороне абонента (плохой роутер, антивирус, вирус, фаервол). А оставшиеся 20% тоже часто никакого отношения к качеству Ethernet/Vlan не имеют. Работаю в интернет-провайдере четвертый год (самый крупный в городе). Хотя не исключено, что это только у нас в сети нет таких частых проблем с L1-L2.
И Vlan это не просто настройка порта. Если бы дело ограничивалось добавлением в L2 заголовок поля с тегом с дальнейшей коммутацией, то да, но на деле на базе вланов может работать множество всяких алгоритмов на коммутаторах (всякие снупинги, туннели, шейпинги, куосы, аклы), которые даже не все и везде работают аппаратно, и поэтому тоже могут портить этот самый «влан».
Однако я не поддерживаю мнение, что залог хорошего интернета — это качественный Ethernet/Vlan. На практике (статистически) я вижу, что интернет портится в 80% случаев на стороне абонента (плохой роутер, антивирус, вирус, фаервол). А оставшиеся 20% тоже часто никакого отношения к качеству Ethernet/Vlan не имеют. Работаю в интернет-провайдере четвертый год (самый крупный в городе). Хотя не исключено, что это только у нас в сети нет таких частых проблем с L1-L2.
Hamachi — это VPN, с туннелированием IP пакетов.
> И Vlan это не просто настройка порта. Если бы дело ограничивалось добавлением в L2 заголовок поля с тегом с дальнейшей коммутацией, то да
VLAN — нет, 802.1q — да. Речь шла именно о втором.
> Однако я не поддерживаю мнение, что залог хорошего интернета — это качественный Ethernet/Vlan.
Скорее всего, у вас ошибка выжившего. L2 — это очень простые технологии, которые нужно тестировать, но прежде всего производителям. После того, как железка протестирована и гарантирует работоспособность — безусловно, шанс того, что проблема юзера в них — минимальна.
> И Vlan это не просто настройка порта. Если бы дело ограничивалось добавлением в L2 заголовок поля с тегом с дальнейшей коммутацией, то да
VLAN — нет, 802.1q — да. Речь шла именно о втором.
> Однако я не поддерживаю мнение, что залог хорошего интернета — это качественный Ethernet/Vlan.
Скорее всего, у вас ошибка выжившего. L2 — это очень простые технологии, которые нужно тестировать, но прежде всего производителям. После того, как железка протестирована и гарантирует работоспособность — безусловно, шанс того, что проблема юзера в них — минимальна.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Секреты тестирования Ethernet каналов