когда мы говорим про CAM, которая таблица мак-адресов, и которая тоже пользуется TCAM, она хранит дерево хэшей, каждый из которых записан в бинарном виде

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

CAM это CAM, просто тип памяти, а ты говоришь о том, что мак таблица прекрасно хранится и в TCAM, и это верно

ну да, теоретически на свитчах других производителей, где нет ТСАМ, используется именно САМ, бинарная память

речь просто шла про то, почему виртуальный цискосвитч не ложится при петле по перегрузке процессора

именно потому что событие лернинга на нем не возникает достаточно часто, чтобы уложить цп в 100%

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

собсна что на картике. а у других че не так? =)

и проиллюстрировать это можно хорошо всем знакомым процессом cef punting, который имеет ту же природу

Была инфа, что разные Реализации поддерживают разное количество лукапов в TCAM (на один пакет). Кто-то упирался в это ограничение?

к примеру, виртуальный роутер выживет, если ему пропунтить десяток тысяч пакетов в секунду

так же и виртуальный свитч выживет от десятка тысяч лернингов в секунду

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

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

если получилось загнать проц в 30% - мало лернингов

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

возможно, форвардинг плейн на виртуальном свитче умрет раньше, чем лернингов станет достаточно для 100% загрузки

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

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

за unicast flooding отвечает асик

а в рамках виртуального appliance?

http://www.netcraftsmen.com/resource/protecting-a-cisco-catalyst-6500-switch-against-layer-2-loops/ Интересный тест на cat6500, намеренно создается петля, а затем с помощью storm-control и control plane policing загрузка CPU удерживатеся в приемлемых рамках.

http://www.netcraftsmen.com/wp-content/uploads/2011/09/cpu-utilization-all-cases.png

http://www.netcraftsmen.com/resource/protecting-a-cisco-catalyst-6500-switch-against-layer-2-loops/ Интересный тест на cat6500, намеренно создается петля, а затем с помощью storm-control и control plane policing загрузка CPU удерживатеся в приемлемых рамках.

тут вроде пришли к выводу что основная причина загрузки CPU это прерывания на проц из за ненахождения мака источника на порту с которого кадр получен, такое ведь нельзя через CoPP ограничить?

хотя при большом количестве трафа из примера по идее все верно) EIGRP, HSRP, SSH, SNMP, TACACS, DHCP, IGMP, and PIM.

хотя при большом количестве трафа из примера по идее все верно) EIGRP, HSRP, SSH, SNMP, TACACS, DHCP, IGMP, and PIM.

Из броадкаста DHCP discover сюда должен попадать, да.

тут вроде пришли к выводу что основная причина загрузки CPU это прерывания на проц из за ненахождения мака источника на порту с которого кадр получен, такое ведь нельзя через CoPP ограничить?

Если это ограничит то любой clear MAC address-table на девайсе лопатящим гиги трафика будет приводит к куче фладинга надолго

ну да, логично, не нужно это

Machine Learning Algorithms применяют же при обучении всяких Security Appliance, верно? Кто-нибудь работал в вендоре фаерволов и dpi всяких?

AMP помещает все/или часть скачиваемого (не уточняет) в сандбокс и после чего решает херовая штука или нет, и соответсвенно подобные sha блокируются или как они там с этим борятся. ну если они помещают все подряд то обучения нет (: http://www.cisco.com/c/ru_ru/products/security/web-security-appliance/index.html#t=6m15s

или этот ASIC отправляет на проц прерывание когда получает фрейм с новым MAC-Адрессом?

Вообще круто, недавно читал эту тему из CCNP SWITCH, толи не уловил, толи этого там не было. Я думал при шторме основную нагрузку создают АРП-запросы и прочий контролл-плейн широковещательный и мультикаст трафик, и думал это можно пофиксить CoPP механизмами

Прям просветили

Одного не понимаю

при петле проблема не только и не столько в перегрузке проца

на ccnp же рассказываются три основные беды от петли

Если ASIC сравнивает маки SA в Фреймах и имеющиеся в CAM таблице, то зачем ему для записи изменений проц, почему сам не может, там же не нужен никакой Intellegence особо

при петле проблема не только и не столько в перегрузке проца

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

перегрузка каналов мусором, перегрузка асика, неправильные сопоставления портов к макам в CAM

сдохнет или не сдохнет проц, уже не сильно важно

У меня аплинк 10g а петля в 1g, по этому аплинк пропустит трафик, но я ничего не могу сделать, из-за загрузки проца

ок, при таком раскладе да

л2 - зло

У нас такая клевая архитектура, что 100мбитный микрот клал всю сеть с 10гиг портами

Потом начали end-to-end вланы резать

У нас такая клевая архитектура, что 100мбитный микрот клал всю сеть с 10гиг портами

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

Режем до сих пор... ибо их много, и нужно с перерывом сервиса

У нас такая клевая архитектура, что 100мбитный микрот клал всю сеть с 10гиг портами

Каким-то образом генерировалось столько трафика, что забивались 10г порты или просто умирал control plane коммутаторов?

А вот хрен поймёшь они один за другим начали сыпаться по-моему просто какая-то 35 50 а превратилась в хаб и это сделало Amplification такой

Я тогда работал ещё недели 2 поэтому не всю сетку знал, но у нас это повторялось пару раз

Первые 3550 причём всегда падали, 65е и 49е стоят до последнего...

У меня в практике MX80 очень плохело от одного клиента с петлёй в 20 мбит на VDSL-модеме

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

хотя свичам по дороге было ваще пофиг на это

У нас такая клевая архитектура, что 100мбитный микрот клал всю сеть с 10гиг портами

А вай фай мосты убиквити разве не клали :))) Прям при настройке, прям в офисе прям в самом центре :)

??? Этого я не слышал, ты учудил?:)

Ага и всех админов похачил:) это эпично)))

@metallicat20

Он ядовитый

ERROR: S client not available

:(

вот я только хотел добавить "...may be"

Ну это я шучу)

Ночи всем

Простой вопрос - к микроту подключено две тд, напрямую, могули я на микроте резать с них трафик

По определенным портам к примеру

По определенным портам к примеру

В настройках файрволла есть много чего

Ну это я шучу)

зато он спит, закрывая глаза ушами

а чего добился ты?

В настройках файрволла есть много чего

Я понимаю...к примеру на интерфейсе бросать пакеты на 445 порт которые идут?

Дропать*

Я понимаю...к примеру на интерфейсе бросать пакеты на 445 порт которые идут?

In interface, dst tcp 443, action drop

Чё-то непонятно, это взрослый и маленький кенгуру (типа один в другом) или оба маленькие? :)

Я не знаю, какие они там бывают. Слышал только про Роджера, у которого мускулатура похлеще, чем у человека

это валлаби

маленькие

это мама с детенышем в кармане

выглядит неопасно ?

эти совсем ручные

к красному кенгуру я б так не приближался

он ростом с меня

а этих можно гладить как кошек домашних

они даже детей своих дают погладить, сам не ожидал

А его ты видил?

А его ты видил?

я бы к нему задом не поворачивался

а ведь у них есть руки, нормальное вполне тело, могли бы эволюционировать и сталь альтернативной разумной расой на земле