Статистика интересная, но есть вопрос к вам, как агрегатору: проверяете ли вы хоть немного тех, кто находится в списке? Например, еще с прошлой статьи стал неспешно искать себе VDS или хостинг для данных (у некоторых называется HDD, SSD и т.п.).
Пример запроса (по vds). Третьим в списке мне выпла некий hostlix (не сочтите за рекламу). Вот их страничка на вашем сервисе. Перешел на их сайт, далее в раздел контакты: надо же понимать, с кем заключать договор. Может быть и не обратил бы внимания, но в реквизитах заметил странное наименование компании: «Компания Айти — Баланс», а такой формулировки в НК РФ я не помню, и еще более странный ОГРН, на две цифры больше, чем у организаций. Странное чувство повело меня на сайт налоговой тыц. И оказалось, что это никакая не компания, а индивидуальный предприниматель. Это еще ладно… Сомнительно то, что он подал заявление о прекращении деятельности 20.05.2015, а прекратил свою деятельность как ИП, судя по реестру 27.05.2015. Получается либо человек более полугода занимается незаконной предпринимательской деятельностью, либо преднамеренно кто-то его подставил и вывесил у себя на сайте его реквизиты.
Мне кажется, что проверять участников каталога на ликвидность все-таки стоит. Я имею ввиду сделать галочку: проверялось или не проверялось. Таким образом для разных целей будет возможность выбрать разных поставщиков по цене, качеству и достоверности.
Не надо предполагать — на многие вопросы есть ответ у теплотехников (с универа помню подобные задачи), а здесь немного подробнее. На самом деле жидкости смешиваются и тепломассообмен проходит в рамках условия второго рода, т.е. жидклсть-жидкость-окр.среда, а через стенку в рамках условий третьего рода там двойная экспонента (на самом деле натур логарифм) первая — граница раздела жидкость (уже смешанная) — стенка кружки, вторая — граница стенка-окр.среда. Вроде ничего не спутал.
А чего тут исследовать? Открыл, посмотрел какой ASIC стоит, поискал в Интернете спецификацию на чип (или запросил у вендора). Схему и внутр. устройство чипа конечно же не дадут, да и не нужна она (сомневаюсь, что у Вас цель — разработка своего ASIC).
Вряд ли cisco вам пришлет даже обобщенный даташит на свои ASIC. Но мы здесь не про это говорим, проехали.
Не согласен! Не нужно здорового, записывать в больного.
Не понял аналогии, далее по тексту.
Первое. Рекомендация — это подсеть не больше /24 (а это не более 254 IP адресов). Ибо в большом широковещательном домене Ethernet начинается масса других проблем.
Рекомендация кого? Cisco? Да, есть такое, я тоже учился у них на курсах. Несколько выше я писал, откуда вообще кейс такой возник.
Второе. Вы забываете, что рекомендованный дизайн для STP это не более 7 транзитных хопов. Даже если мы представим себе, что у нас к магистральному коммутатору подключено каскадом 5 коммутаторов по 48 портов (к которым в свою очередь подключен IP телефон + компьютер), то это не более 480 MAC адресов.
Это ваше умозаключение, основанное на ошибке, истолкованной вами же в пункте выше (так же упоминаете «рекомендованный дизайн»). Хотя в идеальном мире не могу с вами не согласиться.
Третье. Даже если флапнет магистральный линк, то это далеко не значит, что все 480 хостов начнут моментально посылать пакеты. Более того, далеко не факт, что всем 480'ми хостам потребуется отправить трафик «наверх». Не забываем про поведение коммутатора в случаях с uknown unicast и для какого коммутатора и где будет возникать unknown unicast ситуация (это к вопросу сходимости L2 среды).
Опять же ваши допущения. А если рассмотреть ситуацию несколько иначе. Есть злоумышленник, который генерит тонны маков, что будет с клиентами (кстати, почему мы только о cisco, в статье и о других говорится)? В некоторых случаях они просто не получат сервис. И не надо сейчас говорить о vpls, atom, vlan-per-client и т.п. Я не спорю что это применимо и даже необходимо, просто сейчас мы не об этом.
Четвертое. Коммутатор 3750G предназначен для офисной сети.
А я вот знаю как минимум 5 крупных операторов, сети 2 из которых я даже эксплуатировал, где стоят себе такие 3750 и даже не G и работают на благо клиентов. Так что замечание опять же из области теории и дизайна, навязываемого сиськами.
Пятое. Конечно же существуют сети, в которых больше тысячи MAC адресов, но это сети другого класса и оборудование там используется совершенно другое, ибо к ним предъявляют соотвествующие требование. Я еще ни разу не видел, чтобы кто-то для агрегации колец на Metro Ethernet или в ЦОДе ставил 3750, быстрее встретишь 4500/4900 серию (у которых аппаратная платформа одинаковая). У 4500 серии MAC Learning Rate в районе 20,000 MAC per second.
Опять же вы оперируете технологиями, которых просто может не быть в конкретном месте и в конкретное время. Я не говорю что вы не правы, с точки зрения дизайна — более чем верно, но реальный мир все таки отличается.
Седьмое. В реальности, всю эту «ораву» MAC адресов нужно приземлить на L3 интерфейс маршрутизатора. И быстрее начнутся проблемы с ARP Learning и control-plane на маршрутизаторе, чем проблемы на коммутаторе.
Вообще — да, но задача теста была другая.
Седьмое. 3750G — это старое железо и если мне не изменяет память, оно уже объявлено в EoS/EoL. На смену данному железу уже пришло оборудование следующего поколения и далеко не факт, что там будут такие же «проблемы».
Скажите это тысячам операторов на территории этой страны, даже интересно, что вам ответит экономический отдел.
Кто Вам сказал, что здесь виновата коллизия в CAM таблице?
Это предположение. Схемотехники и временных диаграмм работы ASIC у меня нет,- это немного другое исследование, кстати тоже возможное.
Здесь проблема с большой вероятностью связана с производительностью control-plane коммутатора. Ибо MAC Learning для данной платформы — осуществляется на CPU, а не в «железе». Если в сторону control-plane поступает множество запросов, то есть риск того, что «ниточка» к CPU или сам CPU коммутатора будут перегружены. В этом случае — запрос будет сброшен. Кроме того, мы с Вами говорим про коммутатор третьего уровня и теоретически ситуация может осложняться (зависит от конфигурации коммутатора) при наличии L3 интерфейсов (в этом случае коммутатору, может потребоваться ARP Learning).
Возможно, тем не менее проблема есть. Согласитесь, что вам, как пользователю, откровенно говоря, должно быть наплевать на то, у кого там проблема с производительностью при learning.
Коммутатор хоть и L3, но стоит он в тестовой стойке и никак не нагружен, не использует функционал L3 и не имеет L3 интерфейсов.
Смотрим дальше, 50000 microseconds = 0.05 sec. MAC aging time by default 300 seconds или 0.05/300 = 6000 адресов за 5 минут (или 1200 адресов в минуту).
Из Вашего поста непонятно. Когда был проверена CAM таблица? Через какое время? После 5 минут работы Вашего скрипта? Через 10 минут? Через 15 минут? Это имеет значение и может влиять на результаты.
Задается количество маков, которые генерируются, т.е. генерация не зависит от времени. Если взять ваши же расчеты, то получается, что 6к пакетов сгенерируется как раз за 300 секнд. На практике обучилось меньше, чем могло сгенерироваться и меньше, чем cisco пишет. Но стоит отметить, что таблица заполнилась полностью (она динамически изменяема), так что тут претензий нет. Претензия лишь в «потере» адресов в быстром режиме. Или для вас это не проблема?
Это значит, что порт проходит все стадии STP. Теперь поговорим на тему TCN/STP, flushing CAM таблиц и Aging-time.
Every bridge is then notified and reduces the aging time to forward_delay (15 seconds by default) for a certain period of time (max_age + forward_delay). It is more beneficial to reduce the aging time instead of clearing the table because currently active hosts, that effectively transmit traffic, are not cleared from the table.
Опять же, когда был запущен тест? Сразу? После того, как стал доступен другой хост? Через 15 секунд, после того, как порт перешел в состояние forwarding?
Если бы тест был запущен сразу, то количество адресов в первом тестовом запросе равнялось бы нуля (у меня их там 10), что не верно, их там 10, что соответствует условию тестовой генерации. Последующие же этапы тестирования проводились без отключения от порта, следовательно STP не перестраивался.
Я же явно указываю, что циска говорит о том, что она может переварить 6к маков. И сравниваю с этим значением показатели. Так же указал на то, что возможно «неверно приготовил» аппарат для того, чтобы он сожрал заявленные 12к. Мои претензии к ней связаны не с недостаточностью таблицы, а с потерями адресов при обучении.
Согласен. Более того, я даже призвал поучаствовать в тесте (ссылка на генератор дана). Мной проверялось на том, что было, если вы желаете предоставить железо для теста — проведу тест на нем. Статья все таки не о железе, а о практическом аспекте использования хеш-таблиц.
Зря вы так категорично говорите о нереалистичности. Кейс родился не просто так: довольно крупный оператор очень интересовался поддержкой большого количества адресов, поскольку у них так сеть построена. То что так по дизайну не рекомендует cisco мне так же известно, потому я это и упомянул, но жизнь более многогранна и сети на начальном этапе строят не всегда CCDP.
Целью теста не было проверить влияние на коммутацию, поэтому не проводилась проверка заполняемости таблицы и функций форвардинга. Что же касается запоминания адресов — проблема есть, указал о ней чуть выше,- некоторые коммутаторы не очищают кеш, пока не пройдет aging-time, что приводит к отказу в обслуживании.
cisco-01-TEST#show sdm prefer
The current template is «desktop default» template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.
number of unicast mac addresses: 6K
number of IPv4 IGMP groups + multicast routes: 1K
number of IPv4 unicast routes: 8K
number of directly-connected IPv4 hosts: 6K
number of indirect IPv4 routes: 2K
number of IPv4 policy based routing aces: 0
number of IPv4/MAC qos aces: 0.5K
number of IPv4/MAC security aces: 1K
Но я указал, что в зависимости от профиля и ios возможны вариации. Проблема не в этом (она же честно сразу пишет, что 5507 адресов доступно), а в том, что очень много теряет, если слать на скорости порта, в медленном режиме все сильно лучше. Так же проблемы с рандомом, что у других вендоров не наблюдалось.
Человек в статье по ссылке указывал не то, что трафик идет не на один порт, а на все, что подпадают под хеш. А это проблема ИБ. Так же можно «перекормить» некоторые коммутаторы и они откажутся принимать новые MAC-адреса, пока не пройдет aging-time старых.
Пример запроса (по vds). Третьим в списке мне выпла некий hostlix (не сочтите за рекламу). Вот их страничка на вашем сервисе. Перешел на их сайт, далее в раздел контакты: надо же понимать, с кем заключать договор. Может быть и не обратил бы внимания, но в реквизитах заметил странное наименование компании: «Компания Айти — Баланс», а такой формулировки в НК РФ я не помню, и еще более странный ОГРН, на две цифры больше, чем у организаций. Странное чувство повело меня на сайт налоговой тыц. И оказалось, что это никакая не компания, а индивидуальный предприниматель. Это еще ладно… Сомнительно то, что он подал заявление о прекращении деятельности 20.05.2015, а прекратил свою деятельность как ИП, судя по реестру 27.05.2015. Получается либо человек более полугода занимается незаконной предпринимательской деятельностью, либо преднамеренно кто-то его подставил и вывесил у себя на сайте его реквизиты.
Мне кажется, что проверять участников каталога на ликвидность все-таки стоит. Я имею ввиду сделать галочку: проверялось или не проверялось. Таким образом для разных целей будет возможность выбрать разных поставщиков по цене, качеству и достоверности.
Да и на момент его выпуска были более приятные варианты.
Вряд ли cisco вам пришлет даже обобщенный даташит на свои ASIC. Но мы здесь не про это говорим, проехали.
Не понял аналогии, далее по тексту.
Рекомендация кого? Cisco? Да, есть такое, я тоже учился у них на курсах. Несколько выше я писал, откуда вообще кейс такой возник.
Это ваше умозаключение, основанное на ошибке, истолкованной вами же в пункте выше (так же упоминаете «рекомендованный дизайн»). Хотя в идеальном мире не могу с вами не согласиться.
Опять же ваши допущения. А если рассмотреть ситуацию несколько иначе. Есть злоумышленник, который генерит тонны маков, что будет с клиентами (кстати, почему мы только о cisco, в статье и о других говорится)? В некоторых случаях они просто не получат сервис. И не надо сейчас говорить о vpls, atom, vlan-per-client и т.п. Я не спорю что это применимо и даже необходимо, просто сейчас мы не об этом.
А я вот знаю как минимум 5 крупных операторов, сети 2 из которых я даже эксплуатировал, где стоят себе такие 3750 и даже не G и работают на благо клиентов. Так что замечание опять же из области теории и дизайна, навязываемого сиськами.
Опять же вы оперируете технологиями, которых просто может не быть в конкретном месте и в конкретное время. Я не говорю что вы не правы, с точки зрения дизайна — более чем верно, но реальный мир все таки отличается.
Вообще — да, но задача теста была другая.
Скажите это тысячам операторов на территории этой страны, даже интересно, что вам ответит экономический отдел.
Это предположение. Схемотехники и временных диаграмм работы ASIC у меня нет,- это немного другое исследование, кстати тоже возможное.
Возможно, тем не менее проблема есть. Согласитесь, что вам, как пользователю, откровенно говоря, должно быть наплевать на то, у кого там проблема с производительностью при learning.
Коммутатор хоть и L3, но стоит он в тестовой стойке и никак не нагружен, не использует функционал L3 и не имеет L3 интерфейсов.
Задается количество маков, которые генерируются, т.е. генерация не зависит от времени. Если взять ваши же расчеты, то получается, что 6к пакетов сгенерируется как раз за 300 секнд. На практике обучилось меньше, чем могло сгенерироваться и меньше, чем cisco пишет. Но стоит отметить, что таблица заполнилась полностью (она динамически изменяема), так что тут претензий нет. Претензия лишь в «потере» адресов в быстром режиме. Или для вас это не проблема?
Если бы тест был запущен сразу, то количество адресов в первом тестовом запросе равнялось бы нуля (у меня их там 10), что не верно, их там 10, что соответствует условию тестовой генерации. Последующие же этапы тестирования проводились без отключения от порта, следовательно STP не перестраивался.
Целью теста не было проверить влияние на коммутацию, поэтому не проводилась проверка заполняемости таблицы и функций форвардинга. Что же касается запоминания адресов — проблема есть, указал о ней чуть выше,- некоторые коммутаторы не очищают кеш, пока не пройдет aging-time, что приводит к отказу в обслуживании.
Но я указал, что в зависимости от профиля и ios возможны вариации. Проблема не в этом (она же честно сразу пишет, что 5507 адресов доступно), а в том, что очень много теряет, если слать на скорости порта, в медленном режиме все сильно лучше. Так же проблемы с рандомом, что у других вендоров не наблюдалось.