zed_0xff

я когда-то задался вопросом - что лучше юзать в правилах: "...{ via em1 or via em2 or via em3 }" или "via em*", расковырял исходники, вытащил алгоритм, протестил. в результате получилось что одна обработка вида "via em*" ("via ng*" в вашем случае) примерно в 120 раз медленне, чем просто "via emX" так что попробуйте как-то уменьшить количество проверок с масками, или перегруппировать правила так чтобы нужна было всего пара таких "тяжелых" матчеров

поддерживаю

можно попробовать через snmp. я так с цисок собираю вывод "sh cdp ne" и списки маков на портах

так и было, но при 200 с лишним вланах это начинает выглядеть примерно так: (кликабельно) и очень некомфортно это всё хозяйство было поддерживать еще начиная с фри 5-ки.. постоянно что-то где-то отпадывало.. то в ядре лимита количества нетграфовских нод не хватает, то буфера заканчиваются, и при каждом добавлении нового влана надо не забыть еще к нему нод создать и подключить.. как бы очень очевидно что в такой ситуации решение со всего одним соединением физический_интерфейс <-> ng_netflow выглядит гораздо более идеологически правильным и красивым, нежели как минимум количество_вланов*2 соединений (а то и больше, учитывая что считать трафик надо в обе стороны)

поспокойнее. бред, можно научить. научите, люблю узнавать что-то новое. ну, то что "© не помню кто" - это конечно всё меняет! а сами пробовали? я вот только что попробовал, специально думаю, вдруг починили и всё ок. ан нет - как было в одну сторону так и есть. ifconfig vlan10 create ifconfig vlan10 vlandev em0 vlan 10 ifconfig vlan10 10.10.0.2/24 ngctl mkpeer em0: tee lower left ngctl name em0:lower tee0 ngctl conn em0: tee0: upper right напускаем в em0 тэгированного трафика, либо смотрим на живом роутере. результат один и тот же: смотрим "nghook -a tee0: left2right" - трафик есть. смотрим "nghook -a tee0: right2left" - трафика нет!! о чем я и писал во 2-м сообщении этой темы.

если ifIndex не важен - то можно, а если надо сохранять в ifIndex номер влана - то надо патчить. ну и опять же если это роутер - то трафик будет только в одну сторону считаться. проверено на 7.1

нельзя. точнее, можно, но пакеты будут считаться только в одну сторону. поймать можно будет только пакеты, которые из роутера наружу исходят. ибо входящие ядро "развиланивает" :) мимо нетграфа, и они сразу попадают на интерфейсы vlanXXX. варианты решения проблемы: 1) забить и считать только в одну сторону 2) развиланивать трафик внутри нетграфа через ng_vlan. как он по производительности в сравнении с решением через ifconfig - хз. не пробовал. 3) (imho оптимальный вариант) поднять в качестве коллектора отдельный тазик. причем можно уложиться в 8 т.р. и десктопное железо :) но по железу это уже каждый сам решает.. в этот тазик сливается циской зеркало трафика, тазик сам ничего не развиланивает, там висит специально обученный ng_netflow, всё считает и сливает в базу или куда угодно. наглядный результат оптимизации ng_netflow :)

отлично! добавлю в мэйкфайл

Все правильно, в спецификации протокола написано что возвращается либо "белый" айпишник (если есть), либо "первый попавшийся серый" (вольный перевод :)

t0ly, попробуйте так: cc -g -I/usr/local/include -I/usr/local/include/libnet-1.1 -I/usr/include/pcap -I/usr/local/include/libnet11 -I/usr/local/include/libnet113 -g -L/usr/local/lib -L/usr/local/lib/libnet-1.1 -L/opt/csw/lib -L/usr/local/lib/libnet11 -L /usr/local/lib/libnet113 -o lltdscan lltdscan.c -lnet -lpcap -lrt и сообщите о результате

hiller, установите пакеты libnet* (libnet-devel, libnet-headers если есть)

XP тоже.Спасибо.

Собственно, написал утилитку для обнаружения в сети юзеров, которых ни пингом, ни arping-ом обнаружить не получается. Например, когда абонент сбил настройки. Позволяет увидеть машину абонента по маку, даже если у него прописан совершенно левый айпишник (arping по маку не предлагать! ибо на ICMP broadcast вообще никто не отвечает) пример работы: #./lltdscan -t1300 -v interface eth0 101 bytes from 00:01:33:ed:54:a1 (192.168.123.12 ): time=929 ms name="XZ" Host ID: 00 01 ee ff 22 a1 Charact.: 20 00 00 00 (full-duplex) Media: 00 00 00 06 (Ethernet) Perf.cntr: 00 00 00 00 00 36 9e 99 Link speed: 100 Mbit/s Name: 31 00 43 00 QoS: 60 00 00 00 (802.1q-support, 802.1p-support) found 1 hosts in 1.302 seconds #lltdscan -i vlan112 interface vlan234 109 bytes from 00:e0:4c:4c:23:32 (192.168.18.2 ): time=300 ms name="pc2009" 127 bytes from 00:1d:60:35:ad:dd (192.168.13.4 ): time=601 ms name="microsof-11798c" 105 bytes from 00:0e:a6:bb:11:22 (192.168.11.8 ): time=601 ms name="kkkk" 109 bytes from 00:01:6c:b7:33:55 (192.168.33.8 ): time=623 ms name="pc2009" 115 bytes from 4c:00:10:00:f1:64 (192.168.19.46): time=903 ms name="zemlyanka" 127 bytes from 00:1f:c6:e9:19:31 (192.168.18.58): time=932 ms name="microsof-2fa310" 107 bytes from 00:e0:4c:15:49:5e (192.168.18.8 ): time=950 ms name="w0r5t" 127 bytes from 00:c0:9f:b3:53:58 (192.168.78.06): time=952 ms name="rgzkv6snijlrhln" 127 bytes from 00:0c:76:cc:52:5b (192.168.35.12): time=990 ms name="microsof-34de4d" found 9 hosts in 3.101 seconds предыстория и некоторые подробности тут: lltd scanner код утилиты тут: http://github.com/zed-0xff/lltdscan UPD: если программа понравилась, плюсание плз карму на хабре - http://zed-0xff.habrahabr.ru/ а то не хватает там разместить.

а в три влана он не умеет одновременно вещать? :)

для каждого канала надо создать свой mvr group с соотвествующим адресом: mvr group 224.0.200.1 mvr group 224.0.200.2 и т.д. но в вашем случае получается что MVR вам скорее всего не подходит :( можно сделать так: между ресивером и 3550 воткнуть слабенькую машинку на freebsd, которая будет с одной стороны ловить поток с ресивера, а с другой дублировать его в 2 влана(5 и 50) и отправлять в транк на gi0/2. тогда все mvr нафиг отключаем, а на длинковских access-ах уже рулим либо через ISM где есть, либо без ISM-а т.к. в этом влане уже будет копия потока

мультикаст не может входить сразу в два влана. входит он всегда в один :) а MVR позволяет ему выходить в два и более вланов. т.е. gi0/2 делаем mode access; mvr type source; access vlan 2 а на интерфейсах на которых хотим ловить поток (которые у вас видимо в mode access для вланов 1 и 50) - делаем mvr type receiver и все должно пойти

в gi0/2 только ресивер или что-то еще воткнуто?

не верьте документации :) приемные порты могут быть транковыми. проверено на 2950/2960/3550. просто надо сделать финт ушами - вот например 3550-T12: #sh mvr interface Gi0/6 RECEIVER Access 416 ACTIVE/UP DISABLED Gi0/9 SOURCE Trunk 2 ACTIVE/UP DISABLED Gi0/10 SOURCE Trunk 2 ACTIVE/UP DISABLED Gi0/11 SOURCE Trunk 2 ACTIVE/UP DISABLED Gi0/12 SOURCE Trunk 2 ACTIVE/UP DISABLED она с Gi0/11 и Gi0/12 ловит входящий видео-поток в 2-м VLAN-е, далее локально раздает в 416-й акцесом (смотрим через VLC в офисе :) и далее по портам 9 и 10 кидает на другие циски(2960), с которых идет на другие VLANы. крайне неочевидная фишка в том что порты должны быть объявлены как MVR TYPE SOURCE. далее, обязательно MVR-ный влан должен быть в бд вланов (sh vlan), просто одного объявления "mvr vlan NN" недостаточно. далее, мультикаст роутер не нужен. а нужен ip igmp snooping querier, именно такой командой он включается на 3550/2960(LANBASE!). а вот "ip igmp snooping vlan 50 querier address 10.90.90.10" надо убрать если в gi 0/2 воткнут _только_ стример исключительно для вещания, то конфиг будет примерно такой: (пусть MVR vlan будет также 2-й, например) ! no ip igmp snooping vlan 50 mrouter interface gigabitethernet0/1 no ip igmp snooping vlan 50 querier address 10.90.90.10 ! ip igmp snooping querier ! mvr mvr vlan 2 mvr group 228.1.23.4 # убедитесь что именно на этот мультикаст-адрес идет трафик! ! interface GigabitEthernet0/2 switchport mode access switchport access vlan 2 mvr type source ! interface Fa0/2 description это "Человек подключен на этой же циске в другом порту скажем в 10м влане" switchport mode access switchport access vlan 10 mvr type receiver ! vlan 2 !

конфиг "приличного сервака" в студию плз

p4 2.66GHz s775, 1Gb DDR, 1xRealtek (100Mbit) + 1x3COM (100Mbit), 120Gb mirror soft-raid.сейчас (12 часов ночи) load avg=0.5 днем, в пике бывает и до 4 :( в основном system+interrupt. 3Com - с поллингом. нат сейчас через natd, фаервол через ipfw (~1100 правил). ipnat чем-то лучше natd? намного? также, может, ipfw - не самый лучший фаервол? ipfilter? pf? ну и сетевухи бы тоже интересно было узнать мнение - какие лучше :) сам склоняюсь к гигабитным интеловским.. ну и чем обосновано что 2 сервака вместо одного? спасибо :)

Нужен сабж. Есть ISP уровня небольшого города, ~500 абонентов, ~150 vlan'ов. Задача: NAT всех в один 10Mbit аплинк, NetFlow ната и всех между собой (локальный трафик - платный (зависит от тарифа)). Суммарный объем всего трафика за месяц ~8 Тб. Сейчас всё крутится на серваке под freebsd6 + cisco 2950. Сервак с каждым новым клиентом всё более перестает удовлетворять. Хотелось бы увеличить скорость, разгрузить сервак (оставить на нем почту, сбор NetFlow, NAT?). От циски хотелось бы чтобы она держала суммарный поток ~500Mbit, обсчитывая (почти) всё. Пока смотрю на Cisco 7507 50T Bundle (RSP8 + VIP4-80 + PA-GE) = $7400 Соответственно, порядок цен примерно такой, а лучше и ниже. PS: Еще смущает то что, голая Cisco 3825 стоит столько же, сколько и вышеуказанный бандл. Хотя по скорости вроде проигрывает.. Или нет?