Comments 42
На forum.nag.ru после печально известного DES-3028 тестировали всё и вся. Результаты схожи с вашими.
А вы не могли бы дать точную ссылку, я не смог найти. Было бы интересно!
У меня нет ссылки, у меня есть нечто лучшее. Ссылка на статью со ссылками!
habrahabr.ru/post/155265/
habrahabr.ru/post/155265/
Кстати, хеш-функция обычно включает в себя ещё и номер VLAN-а. Это тоже надо учитывать — при большем разбросе VLAN-ов должно влезть больше MAC-ов.
Если ваша сеть построена таким образом, что домен L2 включает множество устройств, то можно ждать беды.
Немного недопонял.
С точки зрения ИБ могут возникнуть проблемы?
Если да, то какие?
Человек в статье по ссылке указывал не то, что трафик идет не на один порт, а на все, что подпадают под хеш. А это проблема ИБ. Так же можно «перекормить» некоторые коммутаторы и они откажутся принимать новые MAC-адреса, пока не пройдет aging-time старых.
A sdm prefer на циске какой был включен? (show sdm prefer)
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 адресов доступно), а в том, что очень много теряет, если слать на скорости порта, в медленном режиме все сильно лучше. Так же проблемы с рандомом, что у других вендоров не наблюдалось.
Ну я это к тому, откуда взялось 5507 вместо 12288
Статью стоит поправить чтобы не вводить людей в заблуждение. Раз уж ошиблись в настройках.
Я же явно указываю, что циска говорит о том, что она может переварить 6к маков. И сравниваю с этим значением показатели. Так же указал на то, что возможно «неверно приготовил» аппарат для того, чтобы он сожрал заявленные 12к. Мои претензии к ней связаны не с недостаточностью таблицы, а с потерями адресов при обучении.
3750G — [давно устаревший и снятый с продажи] L3 свитч, у которого один TCAM задействован под все виды форвардинга. Выше совершенно верно заметили, что надо менять SDM темплейт, он переразобьет TCAM.
Можно так:
3750#show sdm prefer vlan
«desktop vlan» 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: 12K
number of IPv4 IGMP groups: 1K
number of IPv4 multicast routes: 0
number of unicast IPv4 routes: 0
number of IPv4 policy based routing aces: 0
number of IPv4/MAC qos aces: 512
number of IPv4/MAC security aces: 1K
Ваше тестирование вообще ни о чем. Проверили работу хеш-функции? А толку? В последнем абзаце совершенно верное утверждение, что не должно быть тысяч хостов на L2 сегмент, нереалистичный это сценарий. Проверили бы хотя бы как влияет заполнение таблицы на форвардинг и на запоминание новых маков. Что происходит, когда банка заполнена? Новая запись не записывается? Или самая старая выталкивается? Этот момент не так очевиден.
Там, где прямо позарез надо очень много устройств, есть conversational mac learning (грубо говоря — не запоминаем smac пришедшего с транка пакета, если dmac не известен по одному из аксессных портов).
Можно так:
3750#show sdm prefer vlan
«desktop vlan» 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: 12K
number of IPv4 IGMP groups: 1K
number of IPv4 multicast routes: 0
number of unicast IPv4 routes: 0
number of IPv4 policy based routing aces: 0
number of IPv4/MAC qos aces: 512
number of IPv4/MAC security aces: 1K
Ваше тестирование вообще ни о чем. Проверили работу хеш-функции? А толку? В последнем абзаце совершенно верное утверждение, что не должно быть тысяч хостов на L2 сегмент, нереалистичный это сценарий. Проверили бы хотя бы как влияет заполнение таблицы на форвардинг и на запоминание новых маков. Что происходит, когда банка заполнена? Новая запись не записывается? Или самая старая выталкивается? Этот момент не так очевиден.
Там, где прямо позарез надо очень много устройств, есть conversational mac learning (грубо говоря — не запоминаем smac пришедшего с транка пакета, если dmac не известен по одному из аксессных портов).
Зря вы так категорично говорите о нереалистичности. Кейс родился не просто так: довольно крупный оператор очень интересовался поддержкой большого количества адресов, поскольку у них так сеть построена. То что так по дизайну не рекомендует cisco мне так же известно, потому я это и упомянул, но жизнь более многогранна и сети на начальном этапе строят не всегда CCDP.
Целью теста не было проверить влияние на коммутацию, поэтому не проводилась проверка заполняемости таблицы и функций форвардинга. Что же касается запоминания адресов — проблема есть, указал о ней чуть выше,- некоторые коммутаторы не очищают кеш, пока не пройдет aging-time, что приводит к отказу в обслуживании.
Целью теста не было проверить влияние на коммутацию, поэтому не проводилась проверка заполняемости таблицы и функций форвардинга. Что же касается запоминания адресов — проблема есть, указал о ней чуть выше,- некоторые коммутаторы не очищают кеш, пока не пройдет aging-time, что приводит к отказу в обслуживании.
>Целью теста не было проверить влияние на коммутацию, поэтому не проводилась проверка заполняемости таблицы и функций форвардинга.
А еще, видимо, не было задачи создать хотя бы относительно реалистичное с точки зрения SP заполнение TCAM :)
>Что же касается запоминания адресов — проблема есть, указал о ней чуть выше,- некоторые коммутаторы не очищают кеш, пока не пройдет aging-time, что приводит к отказу в обслуживании.
Где там был отказ в обслуживании?
И заодно:
>очень много теряет, если слать на скорости порта, в медленном режиме все сильно лучше.
А какой вообще смысл проверять такое на древнющей железке, которую уже даже не купишь кроме как подержанную? TCAM ведь штука медленная на запись. Да, могут быть проблемы на старых платформах. Проверьте что-нибудь более модное вроде замечательных 3650/3850 или шеститонник на PFC4.
>Так же проблемы с рандомом, что у других вендоров не наблюдалось.
Так и тесты ведь далеко не жизненные. Что если окажется, что с добавлением тега VLAN'а равномерность заполнения существенно улучшится у 3750 и ухудшится у остальных? И опять же, мы говорим про одну маленькую платформу. Если взять даже 3750Х — наверняка результат сильно изменится неизвестно в какую сторону.
А еще, видимо, не было задачи создать хотя бы относительно реалистичное с точки зрения SP заполнение TCAM :)
>Что же касается запоминания адресов — проблема есть, указал о ней чуть выше,- некоторые коммутаторы не очищают кеш, пока не пройдет aging-time, что приводит к отказу в обслуживании.
Где там был отказ в обслуживании?
И заодно:
>очень много теряет, если слать на скорости порта, в медленном режиме все сильно лучше.
А какой вообще смысл проверять такое на древнющей железке, которую уже даже не купишь кроме как подержанную? TCAM ведь штука медленная на запись. Да, могут быть проблемы на старых платформах. Проверьте что-нибудь более модное вроде замечательных 3650/3850 или шеститонник на PFC4.
>Так же проблемы с рандомом, что у других вендоров не наблюдалось.
Так и тесты ведь далеко не жизненные. Что если окажется, что с добавлением тега VLAN'а равномерность заполнения существенно улучшится у 3750 и ухудшится у остальных? И опять же, мы говорим про одну маленькую платформу. Если взять даже 3750Х — наверняка результат сильно изменится неизвестно в какую сторону.
Согласен. Более того, я даже призвал поучаствовать в тесте (ссылка на генератор дана). Мной проверялось на том, что было, если вы желаете предоставить железо для теста — проведу тест на нем. Статья все таки не о железе, а о практическом аспекте использования хеш-таблиц.
Немного не в тему, понятно что вы говорите об отсутствии полноты тестирования.
Но некоторые ваши утверждения об устаревшем железе, обескураживают :)
Создается впечатление, что компании так и «рвутся» покупать модные и современные железки.
У многих стоит целый зоопарк немодного железа который никуда исчезать не собирается.
Совсем недавно наткнулся в одном зоопарке на 2900XL. :)
Но некоторые ваши утверждения об устаревшем железе, обескураживают :)
— 3750G — [давно устаревший и снятый с продажи] L3 свитч
— А какой вообще смысл проверять такое на древнющей железке, которую уже даже не купишь кроме как подержанную?
— Проверьте что-нибудь более модное вроде замечательных 3650/3850
Создается впечатление, что компании так и «рвутся» покупать модные и современные железки.
У многих стоит целый зоопарк немодного железа который никуда исчезать не собирается.
Совсем недавно наткнулся в одном зоопарке на 2900XL. :)
>Создается впечатление, что компании так и «рвутся» покупать модные и современные железки.
Так если количественные требования меняются — да, закупается нечто более современное. Например, потому что тупо портов не хватает, а устаревшее уже не продается. Ну и по устаревшему железу уже сложно спросить TAC «чо это он не успевает TCAM наполнять?». И даже если TAC по железке еще работает, и удалось к примеру выявить ранее неизвестный и исправимый программный баг — его уже не исправят.
>Можно подумать цыска одумалась и перестала жлобствовать. ТКАМа и буферов как недокладывали, так и продолжают.
Большие буфера — зло, всё хорошо в меру, и в тех линейках, где их реально не хватало, эта проблема уже устранена в новых ревизиях/железках. TCAM'ов тоже хватает, если использовать железо по назначению, в соответствии с гайдлайнами. Плюс опять же доступные где-то оптимизации control plane вроде conversational mac learning — аксессный свитч запомнит мак пакета, если в этом мало смысла, скажем — отправитель пакета с другой стороны сети просто послал arp и не общается ни с кем подключенным к этому свитчу.
Так если количественные требования меняются — да, закупается нечто более современное. Например, потому что тупо портов не хватает, а устаревшее уже не продается. Ну и по устаревшему железу уже сложно спросить TAC «чо это он не успевает TCAM наполнять?». И даже если TAC по железке еще работает, и удалось к примеру выявить ранее неизвестный и исправимый программный баг — его уже не исправят.
>Можно подумать цыска одумалась и перестала жлобствовать. ТКАМа и буферов как недокладывали, так и продолжают.
Большие буфера — зло, всё хорошо в меру, и в тех линейках, где их реально не хватало, эта проблема уже устранена в новых ревизиях/железках. TCAM'ов тоже хватает, если использовать железо по назначению, в соответствии с гайдлайнами. Плюс опять же доступные где-то оптимизации control plane вроде conversational mac learning — аксессный свитч запомнит мак пакета, если в этом мало смысла, скажем — отправитель пакета с другой стороны сети просто послал arp и не общается ни с кем подключенным к этому свитчу.
Можно подумать цыска одумалась и перестала жлобствовать. ТКАМа и буферов как недокладывали, так и продолжают.
В последнем абзаце совершенно верное утверждение, что не должно быть тысяч хостов на L2 сегмент, нереалистичный это сценарий.
В мире ISP вполне реалистичный. Но это скорее исключение.
Почти одновременно написали.
Не с этим железом.
Даже представить себе не могу такую картину. Точнее представить могу, только с обязательным условием кривых рук админов или безмозглого руководства.
В реальности уже при 200 хостах в л2 сегменте начинает все дико лагать и глючить.
В реальности уже при 200 хостах в л2 сегменте начинает все дико лагать и глючить.
Вполне может быть.
Один L2 сегмент — это необязательно один широковещательный домен.
Это может быть, например, svlan с qinq. Либо один большой VLAN с traffic segmentation на всех конечных портах. Оба этих варианта имеют право на жизнь (каждый в своём случае, конечно) и каждый из них без проблем уместит хоть 10 тысяч, хоть 20 тысяч хостов — абы хватило таблицы MAC-адресов.
Один L2 сегмент — это необязательно один широковещательный домен.
Это может быть, например, svlan с qinq. Либо один большой VLAN с traffic segmentation на всех конечных портах. Оба этих варианта имеют право на жизнь (каждый в своём случае, конечно) и каждый из них без проблем уместит хоть 10 тысяч, хоть 20 тысяч хостов — абы хватило таблицы MAC-адресов.
UFO just landed and posted this here
del
В целом идея этого теста понятна. На моей практике, действительно встречались коммутаторы с коллизиями в хэш таблице CAM адресов, но это было оборудование не компании Cisco Systems.
Относительно тестирования и выводов — они не корректные.
В коммутаторах Cisco Catalyst действительно существует такое понятие, как SDM профайл. От выбора SDM профайла, зависит размер CAM таблицы. Читайте документацию.
Кто Вам сказал, что здесь виновата коллизия в CAM таблице?
Здесь проблема с большой вероятностью связана с производительностью control-plane коммутатора. Ибо MAC Learning для данной платформы — осуществляется на CPU, а не в «железе». Если в сторону control-plane поступает множество запросов, то есть риск того, что «ниточка» к CPU или сам CPU коммутатора будут перегружены. В этом случае — запрос будет сброшен. Кроме того, мы с Вами говорим про коммутатор третьего уровня и теоретически ситуация может осложняться (зависит от конфигурации коммутатора) при наличии L3 интерфейсов (в этом случае коммутатору, может потребоваться ARP Learning).
Далее, давайте посмотрим на Ваш генератор и «медленный режим»:
Файл etherraw/send_pkt.c — 211 строка
Файл «etherraw/send_pkt.h» — 20 строка
Смотрим дальше, 50000 microseconds = 0.05 sec. MAC aging time by default 300 seconds или 0.05/300 = 6000 адресов за 5 минут (или 1200 адресов в минуту).
Из Вашего поста непонятно. Когда был проверена CAM таблица? Через какое время? После 5 минут работы Вашего скрипта? Через 10 минут? Через 15 минут? Это имеет значение и может влиять на результаты.
Далее, очень многое зависит от L2 конфигурации коммутатора и портов. Вы пишите, что конфигурация порта выглядит следующим образом:
Это значит, что порт проходит все стадии 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?
В общем и целом — идея интересная, но методика тестирования неправильная, ибо вопросов больше, чем ответов.
Относительно тестирования и выводов — они не корректные.
Странно, но пишет, что у нее памяти всего на 5507 адресов:
В коммутаторах Cisco Catalyst действительно существует такое понятие, как SDM профайл. От выбора SDM профайла, зависит размер CAM таблицы. Читайте документацию.
Сгенерируем заведомо большее, чем заявлено, количество адресов (12288), я указал 13000:
cisco-01-TEST#show mac address-table count
Mac Entries for Vlan 20:
— Dynamic Address Count: 4281
Static Address Count: 0
Total Mac Addresses: 4281
Total Mac Address Space Available: 1219
Как видно, заполнить всю таблицу удалось не сразу и попали далеко не все адреса, вот вам и колизионность. Пробую еще раз:
Кто Вам сказал, что здесь виновата коллизия в CAM таблице?
Здесь проблема с большой вероятностью связана с производительностью control-plane коммутатора. Ибо MAC Learning для данной платформы — осуществляется на CPU, а не в «железе». Если в сторону control-plane поступает множество запросов, то есть риск того, что «ниточка» к CPU или сам CPU коммутатора будут перегружены. В этом случае — запрос будет сброшен. Кроме того, мы с Вами говорим про коммутатор третьего уровня и теоретически ситуация может осложняться (зависит от конфигурации коммутатора) при наличии L3 интерфейсов (в этом случае коммутатору, может потребоваться ARP Learning).
И медленный режим (максимум, что удалось вместить):
Mac Entries for Vlan 20:
— Dynamic Address Count: 5945
Static Address Count: 0
Total Mac Addresses: 5945
Total Mac Address Space Available: 3
cisco-01-TEST#show mac address-table count
Рандомный тест:
cisco-01-TEST#sh mac address-table count
Mac Entries for Vlan 20:
— Dynamic Address Count: 4417
Static Address Count: 0
Total Mac Addresses: 4417
Total Mac Address Space Available: 1499
Рандомный медленный тест:
cisco-01-TEST#sh mac address-table count
Mac Entries for Vlan 20:
— Dynamic Address Count: 5947
Static Address Count: 0
Total Mac Addresses: 5947
Total Mac Address Space Available: 1
Далее, давайте посмотрим на Ваш генератор и «медленный режим»:
Файл etherraw/send_pkt.c — 211 строка
/* Wait timeout */
if(workslow == 1) usleep(SleepTime);
Файл «etherraw/send_pkt.h» — 20 строка
#define SleepTime 50000 // microseconds
Смотрим дальше, 50000 microseconds = 0.05 sec. MAC aging time by default 300 seconds или 0.05/300 = 6000 адресов за 5 минут (или 1200 адресов в минуту).
Из Вашего поста непонятно. Когда был проверена CAM таблица? Через какое время? После 5 минут работы Вашего скрипта? Через 10 минут? Через 15 минут? Это имеет значение и может влиять на результаты.
Далее, очень многое зависит от L2 конфигурации коммутатора и портов. Вы пишите, что конфигурация порта выглядит следующим образом:
Настройки тестового порта:
interface GigabitEthernet1/0/1
switchport access vlan 20
switchport mode access
end
Это значит, что порт проходит все стадии 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?
В общем и целом — идея интересная, но методика тестирования неправильная, ибо вопросов больше, чем ответов.
Кто Вам сказал, что здесь виновата коллизия в 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 не перестраивался.
Это предположение. Схемотехники и временных диаграмм работы ASIC у меня нет,- это немного другое исследование, кстати тоже возможное.
А чего тут исследовать? Открыл, посмотрел какой ASIC стоит, поискал в Интернете спецификацию на чип (или запросил у вендора). Схему и внутр. устройство чипа конечно же не дадут, да и не нужна она (сомневаюсь, что у Вас цель — разработка своего ASIC).
Возможно, тем не менее проблема есть. Согласитесь, что вам, как пользователю, откровенно говоря, должно быть наплевать на то, у кого там проблема с производительностью при learning.
Коммутатор хоть и L3, но стоит он в тестовой стойке и никак не нагружен, не использует функционал L3 и не имеет L3 интерфейсов.
Не согласен! Не нужно здорового, записывать в больного.
Первое. Рекомендация — это подсеть не больше /24 (а это не более 254 IP адресов). Ибо в большом широковещательном домене Ethernet начинается масса других проблем.
Второе. Вы забываете, что рекомендованный дизайн для STP это не более 7 транзитных хопов. Даже если мы представим себе, что у нас к магистральному коммутатору подключено каскадом 5 коммутаторов по 48 портов (к которым в свою очередь подключен IP телефон + компьютер), то это не более 480 MAC адресов.
Третье. Даже если флапнет магистральный линк, то это далеко не значит, что все 480 хостов начнут моментально посылать пакеты. Более того, далеко не факт, что всем 480'ми хостам потребуется отправить трафик «наверх». Не забываем про поведение коммутатора в случаях с uknown unicast и для какого коммутатора и где будет возникать unknown unicast ситуация (это к вопросу сходимости L2 среды).
Четвертое. Коммутатор 3750G предназначен для офисной сети.
Пятое. Конечно же существуют сети, в которых больше тысячи MAC адресов, но это сети другого класса и оборудование там используется совершенно другое, ибо к ним предъявляют соотвествующие требование. Я еще ни разу не видел, чтобы кто-то для агрегации колец на Metro Ethernet или в ЦОДе ставил 3750, быстрее встретишь 4500/4900 серию (у которых аппаратная платформа одинаковая). У 4500 серии MAC Learning Rate в районе 20,000 MAC per second.
Шестое. Даже если коммутатор не под нагрузкой, это еще ни о чем не говорит. SDM тому пример.
Седьмое. В реальности, всю эту «ораву» MAC адресов нужно приземлить на L3 интерфейс маршрутизатора. И быстрее начнутся проблемы с ARP Learning и control-plane на маршрутизаторе, чем проблемы на коммутаторе.
Седьмое. 3750G — это старое железо и если мне не изменяет память, оно уже объявлено в EoS/EoL. На смену данному железу уже пришло оборудование следующего поколения и далеко не факт, что там будут такие же «проблемы».
Задается количество маков, которые генерируются, т.е. генерация не зависит от времени. Если взять ваши же расчеты, то получается, что 6к пакетов сгенерируется как раз за 300 секнд. На практике обучилось меньше, чем могло сгенерироваться и меньше, чем cisco пишет. Но стоит отметить, что таблица заполнилась полностью (она динамически изменяема), так что тут претензий нет. Претензия лишь в «потере» адресов в быстром режиме. Или для вас это не проблема?
Скажем так, control-plane вещь, которая требует к себе трепетного отношения. Как я уже сказал ранее, пакеты могут сбрасываться (discard), если пакет адресованный CPU сброшен, то и Learning'а не будет, это очевидно как 2x2. Что касается претензий, то в Вашей статье претензии предъявляются к «коллизиям» в CAM таблице, наличие которых — доказать не удалось. Что касается проблемы, отвечаю — да, это не проблема (смотри развернутый ответ выше).
Если бы тест был запущен сразу, то количество адресов в первом тестовом запросе равнялось бы нуля (у меня их там 10), что не верно, их там 10, что соответствует условию тестовой генерации. Последующие же этапы тестирования проводились без отключения от порта, следовательно STP не перестраивался.
Методика тестирования об этом умалчивает. Что касается того, перестраивался или не перестраивался STP — далеко не факт и нам это неочевидно (и мы (читатели), можем лишь предполагать). STP — это control-plane, а создавая большую нагрузку на control-plane не факт, что STP не дергался. Приведу пример. У моего знакомого была проблема, на одном из маршрутизаторов отлетали core линки, на которых весел BFD из-за большой нагрузки, которая была вызвана ARP Learning'ом и создаваемой этим процессом нагрузкой на control-plane (но это уже другая история). :-)
Более правильная методика тестирования (для всех коммутаторов, а не только Cisco).
Стенд:
коммутатор — генератор
Подготовка стенда к тестированию:
Отключить STP.
Отключить Aging для CAM таблиц.
Увеличить интервал для workslow скажем в четыре раза.
Проверить, что у нас нет L3 интерфейсов в этом VLAN'е.
Очищаем таблицу CAM — проверяем текущее количество MAC адресов.
Далее (тесты без VLAN'ов):
1. Тест — обычный increment битов в 2х последних октетах MAC адреса.
2. Тест — increment слева направо для предпоследнего октета в MAC адресе и справа налево в последнем октете MAC адреса.
3. Тест — повторить 1 и 2, но изменить предпоследний октет на 3,4 и 5.
4. Тест — random MAC
5. Тест — XOR хэширование
Далее (тесты с VLAN'ами):
Провести весь набор тестирования из первой группы тестов, для второй группы тестов, заменив один из октетов VLAN идентификатором.
Комментарий:
MAC адреса сгенерировать заранее (количество сгенерированных MAC адресов = количество свободных записей в CAM таблице). Вывод CAM таблиц сравнить.
PS: Хэширование CAM таблицы может включать в себя не только MAC + VLAN, но и Port ID (и даже Bridge ID :)).
Стенд:
коммутатор — генератор
Подготовка стенда к тестированию:
Отключить STP.
Отключить Aging для CAM таблиц.
Увеличить интервал для workslow скажем в четыре раза.
Проверить, что у нас нет L3 интерфейсов в этом VLAN'е.
Очищаем таблицу CAM — проверяем текущее количество MAC адресов.
Далее (тесты без VLAN'ов):
1. Тест — обычный increment битов в 2х последних октетах MAC адреса.
2. Тест — increment слева направо для предпоследнего октета в MAC адресе и справа налево в последнем октете MAC адреса.
3. Тест — повторить 1 и 2, но изменить предпоследний октет на 3,4 и 5.
4. Тест — random MAC
5. Тест — XOR хэширование
Далее (тесты с VLAN'ами):
Провести весь набор тестирования из первой группы тестов, для второй группы тестов, заменив один из октетов VLAN идентификатором.
Комментарий:
MAC адреса сгенерировать заранее (количество сгенерированных MAC адресов = количество свободных записей в CAM таблице). Вывод CAM таблиц сравнить.
PS: Хэширование CAM таблицы может включать в себя не только MAC + VLAN, но и Port ID (и даже Bridge ID :)).
А чего тут исследовать? Открыл, посмотрел какой 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. На смену данному железу уже пришло оборудование следующего поколения и далеко не факт, что там будут такие же «проблемы».
Скажите это тысячам операторов на территории этой страны, даже интересно, что вам ответит экономический отдел.
Вряд ли cisco вам пришлет даже обобщенный даташит на свои ASIC. Но мы здесь не про это говорим, проехали.
Открою Америку. В большинстве случаях, Cisco использует элементную базу других вендоров. Приведу примеры сходу: Marvell, Trident, EZchip, RISC CPU (всякие там Motorolla, IBM), x86 (Intel).
Рекомендация кого? Cisco? Да, есть такое, я тоже учился у них на курсах. Несколько выше я писал, откуда вообще кейс такой возник.
Рекомендация IEEE — стандарт IEEE 802.1D. Part 3: Media Access Control (MAC) Bridges, 108 страница, таблица 8-1 Maximum Bridge Diameter:
Table 8-1—Maximum Bridge Diameter
Parameter Recommended
value
Maximum bridge diameter 7
Это ваше умозаключение, основанное на ошибке, истолкованной вами же в пункте выше (так же упоминаете «рекомендованный дизайн»).
Это большинство сетей, статистика утверждает обратное. Исключения — Metro Ethernet у SP и DC, но как я уже сказал ранее, там используется оборудование другого класса.
Опять же ваши допущения. А если рассмотреть ситуацию несколько иначе. Есть злоумышленник, который генерит тонны маков, что будет с клиентами (кстати, почему мы только о cisco, в статье и о других говорится)?
Первое это уже все пройдено в SP сегменте. Второе большинство устройств позволяют ограничить колличество MAC адресов per port и сделать даже привязку (например Port-Security). Это умел даже старенький 3COM.
В некоторых случаях они просто не получат сервис.
С дуру, можно кое чего сломать.
И не надо сейчас говорить о vpls, atom, vlan-per-client и т.п. Я не спорю что это применимо и даже необходимо, просто сейчас мы не об этом.
Зачем? :-) Я даже и не начинал.
А я вот знаю как минимум 5 крупных операторов, сети 2 из которых я даже эксплуатировал, где стоят себе такие 3750 и даже не G и работают на благо клиентов. Так что замечание опять же из области теории и дизайна, навязываемого сиськами.
Замечания навязаны несколько Cisco, сколько личным опытом и здравым смыслом. Подобный подход (и то это редкость!), скорее характерен для пионернетов, которые лет 8 назад активно скупались крупными игроками центрального региона, нашей необъятной страны. И кстати проблемы у этих пионернетов были соотвествующие.
Опять же вы оперируете технологиями, которых просто может не быть в конкретном месте и в конкретное время. Я не говорю что вы не правы, с точки зрения дизайна — более чем верно, но реальный мир все таки отличается.
Опять же, давайте не будем выдавать желаемое за действительное. Этот 2900XL запросто может обслуживать офис из 5 человек или парочку стареньких маршрутизаторов и каналов в темном чулане.
Скажите это тысячам операторов на территории этой страны, даже интересно, что вам ответит экономический отдел.
Поверьте, я прекрасно знаю ситуацию и понимаю специфику в операторском сегменте.
Sign up to leave a comment.
Про MAC-таблицы в коммутаторах