портов то кот наплакал

живых

QoS тестировал

работает. :)

Ок, спасибо)

прям там в UNL разворачивал хост с Ostinato и пулял в ноды трафиком.

прям там в UNL разворачивал хост с Ostinato и пулял в ноды трафиком.

Т.е. при желание можно им зафлудить всю виртуальную сеть?

можно

но зачем? %)

а в прочем это не моё дело. :)

но зачем? %)

А чего еще на работе делать?

второй раз за час уже. мы всё поняли про SNMP.

А чего еще на работе делать?

просвещаться :)

кто-то туда должен что-то положить

В таком случае как он узнает что у него новый Мак? Я не думаю, что проц каждый Фрейм просматривает. Я думал там отдельное application specific circuitry ? нет? я думаю для mac-learning в ASIC-е реализованы, нет? о.О

у Димы был как-то вебинар про свичинг

нет

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

он это рассказывал

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

или когда он не находит сорс мак на порту с которого пришел фрейм

Кстати по вчерашнему SDN

В ЦОДах вполне норм бы работало :)

просвещаться :)

Ну так, зафлудить все и погрузиться в нирвану:)

Ну так, зафлудить все и погрузиться в нирвану:)

Оно на виртуалке?

У вас-с

Оно на виртуалке?

Оно?

The Thing

Чуваки, а в EVE в обыкновенном треугольнике луп реально замутить чтоб cpu взлетело?

чет пару образов попробовал с spanning-tree portfast spanning-tree bpdufilter enable ничо не работает

Потерял нить беседы :) Вроде речь шла о том, что сеть собрана на виртуалке, ту что флудить собирались

Короче, господа. мы ушли от темы. Вообщем надо добавить сурсов или не пытаться вообще? =)

почему ушли то

в самый раз

ставь Ostinato - делай генерацию трафика с перебором маков

правда не помню, можно ли там инкременировать адрес мака

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

уверен, что такой софт есть

https://www.archlinux.org/packages/?name=macchanger

не, не то

остинато короче

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

прям чтоб каждый пакет с новым маком и частотой 10к в сек? =)

а что такого?

хотя точно помню что была софтинка на линь которая генерила пакеты с рандомным сорсом

в кали точно есть

чтоб свитчи в хабы превращать

macof этож

macof этож

о!

блин а он точно прерывание с целью mac-learning отправляет? получается первый фрейм проходит с повышенной latency ?

нет

разделяй однако

форвардинг плейн от контрол плейна

чтоб форварднуть пакет совсем не обязательно запоминать его сорс мак

это независымые друг от друга процессы

тоесть он это асинхронно выполняет?

конечон

а если прийдет 2 маленьких фрейма один за другим, он второй тоже всем кинет?

эх

сорс и дестинейшн это разные вещи)

тю да

просто интересно, как быстро он потом учит... и может ли за это время что-то ещё произойти

ответ за это время не придет

ну это понятн

но вообще процесс не шустрый

хотя если запустить виртуалку на хорошем проце - будет быстрей чем физический свитч работать

поэтому по моему он у вас тут и не проседал

ERROR: S client not available

может 2е прерывание отправит зато, если два маленьких подряд , хотя это уже гадание наверное :) он то инфу из CAM берет.

такие тонкости алгоритма мне не знакомы

тут мои знания кончаются

да врядли это существенно для сетевиков)

не скажу про все платформы циско, но по крайней мере на некоторых свитчах CAM - это просто раздел TCAM

соответственно, свитчинг и маршрутизация c CEF - это физически один и тот же процесс

просто к кадрам применяются разные обработчики

если приходит кадр, который содержит IP-пакет, который не получается проCEF'ить, он пунтится на process switching

если приходит кадр с мака, которого нет в CAM - он точно так же пунтится на ЦП, просто на другой обработчик

это очень упрощенная схема

я сейчас к тому, что CAM и TCAM - физически одна и та же сущность

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

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

так вот - ничем не отличаются (по крайней мере на некоторых платформах). таблица мак-адресов физически хранится в TCAM

например, всем известные SDM темлейты на cat 3750x, когда сменой темплейта можно увеличть кол-во изучаемых MAC адресов, ценой уменьшения кол-ва роутов.

ostinato-0.7-v1

так вот - ничем не отличаются (по крайней мере на некоторых платформах). таблица мак-адресов физически хранится в TCAM

Так а в чем разнится тогда ? Слова синонимы ?

не совсем

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

поэтому там маски всегда нулевые (если говорить в терминах ipv4 wildcard масок)

CAM tables provide only two results: 0 (true) or 1 (false) TCAM provides three results: 0, 1, and "don't care."

неа

result - это выход

а в TCAM в качестве эталонов для сравнения элементы хранятся в таком троичном виде

это не выход логического элемента, а один из входов

мы при работе с ТСАМ даем на вход бинарный образец, тернарный эталон для сравнения и задаем вопрос: они похожи?

и результат всегда бинарный - да или нет

это не выход логического элемента, а один из входов

верно, я фигню написал

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