umike

какое-то из устройств шлёт кадры flowcontrol, если коммутаторы их пропускают, то кадры распространяются по всему сегменту. Все, кто их понимает, реагирует как положено - замолкает на указанное время. Некоторые неуправляемые коммутаторы (например, DES-1016/1024) при перегрузке умеют сами слать flowcontrol во все активные порты. Но тогда Вы не нашли бы "визуально" нужный порт т.к. все моргали бы очень активно. Захватывайте трафик и смотрите что это. Другого пути нет.

гм. Изменили мак на 20:cf:30:88:8a:11, флуд прикратился. Всё-таки проблема хэша сразу у всех коммутаторов? Гм... any comments?

есть "дерево" из коммутаторов, в одном из "листьев" находится пользователь с мак-адресом 20:cf:30:88:8a:19. Весь трафик идущий к данному пользователю, флудится во все порты "дерева". Во flood_fdb его нет :) Более того: номер vlan по дороге меняется с одного на другой, коммутаторы разных моделей и вендоров (DGS-3120, DES-3200 B/C, DES-3028, Edge-Core ES3528), на стороне пользователей есть неуправляемые также различных вендоров. Трафик на этот мак виден везде. Мак не броадкаст, не мультикаст, я что-то еще упустил?

возможно flowcontrol

DES-3200-28F DGS-3120-24SC Accton Edge-Core ES3528-WDM Rubytech FGS-... Extreme Summit ... тысячи их, почти у каждого вендора есть. А также поиск по форуму, например http://forum.nag.ru/...showtopic=60051

спасибо. Толкните в нужном направлении как работает mask внутри access_id для PCF профилей? То есть как, например, работает конструкция create access_profile packet_content_mask c_tag A profile_id 25 config access_profile profile_id 25 add access_id 100 packet_content c_tag B mask C... ? без маски понятно, это аналогично if( (c_tag && A) == B ), а с маской как? (c_tag && A) == (B && C) чтоли? Возможно ли сделать permit для tagged трафика? :) count enable подсказывает что для untagged c_tag=1. Подозреваю что как раз при помощи вышеприведенной конструкции с mask это должно получиться, как конкретно? Добавлено: если tagged разрешить не получится (жаль, нет отрицательных условий вида c_tag not 0x0001), то можно все правила переписать, указывая c_tag 0xFFFF и c_tag 0x0001 дабы они tagged трафик не торгали. Верно?

При этом create access_profile packet_content_mask offset1 l2 0 0xFFFF profile_id 400 config access_profile profile_id 400 add access_id 1 packet_content offset1 0x0800 port 1-10 permit config access_profile profile_id 400 add access_id 2 packet_content offset1 0x0806 port 1-10 permit create access_profile packet_content_mask offset1 l2 0 0x0 profile_id 500 config access_profile profile_id 500 add access_id 2 packet_content offset1 0x0000 port 1-10 deny работает так, как ожидается. PCF профили отрабатывают последними несмотря на profile_id ?

переписываю правила на PCF, делаю по http://www.dlink.ru/ru/faq/62/954.html подопытный DES-3200-10 A1 немного заблудился в смещениях, поэтому пробую банальное "разрешить ether proto 0x800, 0x806, остальное запретить", все порты untagged в default vlan delete access_profile all create access_profile packet_content_mask offset1 l2 0 0xFFFF profile_id 400 config access_profile profile_id 400 add access_id 1 packet_content offset1 0x0800 port 1-10 permit config access_profile profile_id 400 add access_id 2 packet_content offset1 0x0806 port 1-10 permit create access_profile ethernet source_mac 00-00-00-00-00-00 profile_id 500 config access_profile profile_id 500 add access_id 500 ethernet source_mac 00-00-00-00-00-00 port 1-10 deny Срабатывает 500й профиль и блокируется всё. Что я делаю не так?

и маску подсети у клиента

nuclearcat, для примера возьмём какой-нибудь APC на 8-10kVA . В нём 32 батарейки, причём лежат на боку. К данным ИБП можно подключить десяток штатных внешних блоков. В каждом из блоков тоже 32 батарейки и тоже на боку. Итого суммарно можно получить 11х32=352 батарейки в объеме порядка 36 юнитов и весе под тонну :) Если они газуют и греются, то от того что они плотно упакованы в корпус с шильдиком APC, меньше греться и газовать не станут. Скорее наоборот. Тем не менее указаний на то, что современные ИБП с внешними блоками надо ставить в шкаф с вытяжкой я не встречал. Но одно дело, когда у тебя это в красивых корпусах закрыто, а другое дело - мозолит глаза.

zoro, спасибо danilbal, вентиляцию шкафа надо стена улица дырка делать что владельцы арендуемых помещений не всегда приветствуют. К штатным внешним блокам ИБП нет требований дополнительно их вентилировать с вытяжкой за борт, а в них стоят точно-такие-же батереи. Поэтому отдельная вентиляция - лишняя сущность. Вопрос электробезопасности решаем. Но это всё логика и размышления...

Подскажите дилетанту - допускается ли нормативкой открытое размещение батарей ИБП тут-же рядом с другим работающим оборудованием, например, отдельной полкой в той-же стойке/шкафу? Естесственно речь идёт о батареях, специально прендназначенных для ИБП, например, изготовленные по технологии AGM или даже гелевых т.е.явно заявленные производителем как герметизированные и необслуживаемые. Например, ИБП может быть специально предназначен для подключения внешних батарей и внутренних не иметь. Или, например, в качестве внешних блоков к ИБП подключены неродные (но именно ИБПшные) батарейки. Гм?

и сразу вспоминается ASCII версия Star Wars telnet towel.blinkenlights.nl

если я верно помню, то по отзывам продавцов dreamwifi, гонявших наносы в разных позах, без правил в фаерволе М серия тащит порядка 18-19k pps, не М-серия порядка 4-5k pps (размер пакета не помню, но вроде бы говорили не о самых мелких). Даже со скидкой на ребрендинг в рапиру/дримвифи сомневаюсь что все четыре вместе взятые камеры генерят хотябы один кппс и представляют серьезную нагрузку для точки доступа даже несмотря на то, что это wifi. Если бы камер было полтора десятка, то да, они могли бы позатыкаться в wifi без TDMA/polling. Так сколько там в ппс и мегабитах?

насколько я понял активно используется flowtable. И не впадает в ступор?

это какая версия? Настройками не поделитесь? У меня если взять дефолтные дрова на 8.2 картина выглядит как-то вовсе безрадостно net.isr.numthreads: 4 net.isr.bindthreads: 0 net.isr.maxthreads: 4 net.isr.direct: 0 net.isr.direct_force: 0 11 root 171 ki31 0K 32K CPU3 3 39.2H 100.00% {idle: cpu3} 11 root 171 ki31 0K 32K RUN 1 38.6H 100.00% {idle: cpu1} 11 root 171 ki31 0K 32K CPU0 0 38.3H 100.00% {idle: cpu0} 11 root 171 ki31 0K 32K CPU2 2 37.6H 91.26% {idle: cpu2} 12 root -44 - 0K 192K WAIT 2 178:44 15.28% {swi1: netisr 3} 12 root -44 - 0K 192K WAIT 3 86:39 1.37% {swi1: netisr 0} 0 root -68 0 0K 96K - 0 108:37 0.00% {dummynet} 0 root -68 0 0K 96K - 0 22:00 0.00% {em1 taskq} 0 root -68 0 0K 96K - 3 15:50 0.00% {em0 taskq} 12 root -32 - 0K 192K WAIT 1 6:51 0.00% {swi4: clock}

а что в 8.2 следует использовать для успокоения dummynet? Поставил на тестирование 8.2 релиз, трафика мегабит 20-30 всего, dummynet периодически съедает до 100% одного ядра без всяких видимых причин (каких-то увеличений pps и mbps в эти моменты нет) . Рядом в таком-же тазу стоит 7.х с яндекс-драйверами + сpuset и такого не наблюдается на трафе в десятки раз большем. А тут что?

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

судя по фото "хотспоты - это черные коробки" на вокзалах это Cisco AIR-(L)AP1242 -...

бридж это бридж, цеплять в рабочий мост еще и ноутбук - дурная затея. Лучше поставить дома отдельную точку. Чтобы прицепиться к наносу М2 обычными устройствами G-стандарта нужно поставить в настройках наноса ширину полосы 20MHz а не 40. Только это всё равно что купить 24" монитор, заклеить половину картоном и никогда не использовать.

Коллеги, а подскажите коммутаторы 16-24 10/100 медных портов (можно 10/100/1000) как можно меньшего размера. Интересуют как управляемые (можно смарты) так и неуправляемые, но стабильные. Минимализм это "в размер 8-портовой "мыльницы" 16 портов" или для наглядного примера это примерно в половину всем известных DES-1024D/1016D или примерно 13x4x8 см. В идеале самая длинная сторона устройства должна представлять собой блок 16-24 порта + 5-10мм обрамления корпуса, не более да, порой бывают странные фантазии :)

http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/127209 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/135476 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/144269 в общем-то так короче проявляется такое на большой нагрузке и при частых манипуляциях add/del с таблицами

имхо лучше не смотреть, RSTP/MSTP этот мамонт не умеет

Не надо мучаться, добавьте в скрипт print scrMAC и запускайте scapy -c scriptfilename >>maclog, после чего проверяйте любым способом, например cat maclog | sort -n | uniq -d При одиночных запусках по 8к маков я проверял - повторов не было.

установить scapy, код for n in xrange(7000) : srcMAC = "00"+str(RandMAC())[2:] dstMAC = "00:55:AE:AE:14:11" pkt = Ether(src=srcMAC, dst=dstMAC)/IP(src="127.0.0.1",dst="10.10.10.10")/Padding(load="X"*18) srcMAC + " " + str(n) sendp(pkt, verbose=0) сохранить в файл. Пробелы перед строками и ентеры в конце (в самом конце кода два перевода строки сделать)нужны обязательно как уже указали выше cat filename | scapy или scapy -c filename под фрюхой у меня скрипт падает после 30 итераций ровно, под убунтой всё ок. Можно добавить указание интерфейса для машин с несколькими сетевухами в последней строке sendp(pkt, iface='eth0', verbose=0) и вывод маков - в середину/конец (не забываем пробелы) print srcMAC, записывать в файл типа scapy -c filename >maclog (для выхода жать Ctrl+D), после чего проверять на уникальность, например cat maclog | sort -n | uniq -d