При переключении порта в транк связь прерывается секунд на 5-10, но при этом клиенту для продолжения работы с нетегированными пакетами перенастраивать ничего не нужно (понятно, что для использования второго VLAN-а перенастройка необходима).

Посмотреть эти настройки можно командами «show int f0/1 switchport» и «show int f0/1 trunk». Кстати, в выводе первой команды можно увидеть строчку, в которой говорится, что на родном VLAN-е включено тегирование:
cs#sh int f0/1 switchport
...
Administrative Native VLAN tagging: enabled
...

Однако, работает всё нормально и в Интернете люди склонны считать, что это просто глюк и ссылаются на вывод другой команды:
cs#sh vlan dot1q tag native
dot1q native vlan tagging is disabled

Если на другой стороне тоже свич Cisco, то там также нужно указать родной влан, транк и т.п. Однако, если на той стороне будет стоять, например, компьютер с FreeBSD, то родной VLAN настраивается и работает как обычный, нетегированный линк, например:
ifconfig xl0 10.0.1.2 netmask 255.255.255.0
Ну и интерфейс для тегированного VLAN-а настраивается как обычно в таких случаях, например:
ifconfig vlan100 create vlan 100 vlandev xl0
ifconfig vlan100 192.168.1.2 netmask 255.255.255.0

Указание родного VLAN-а для создания подинтерфейса на роутере Cisco я не проверял, но вроде должно быть как-то так:
cs(config)# int f0/1.500
cs(config-subif)# encapsulation dot1q 500 native
cs(config-subif)# ip address 10.0.1.2 255.255.255.0

При этом база была в работе и в таблицу данные поступали без видимых проблем.

Похоже понадобилась оптимизация ещё одной таблицы – стал замечать медленный запрос,  которого раньше даже видно не было. Ничего особенно не менялось, чтобы вызвать какое-либо замедление выполнения запросов. Таблица на момент написания этой заметки содержала 1659783 записей, объём IBD-файла составлял почти 2 ГБ (2000683008 Б). Таблица содержит тексты личных сообщений пользователей форума, так что записи в ней часто удаляются и добавляются, так что оптимизация не помешает.

Команда «optimize table» выполнялась 5 минут 28 секунд и размер файла уменьшился до 1,4 ГБ (1488977920 Б).

Посмотрим, изменит ли это ситуацию с медленным запросом.

Попутно решил оттимизировать и несколько других таблиц.

2060421 строк, файл в 400МБ обработан за 1 минуту 54 секунда, размер файла стал 310 МБ.
434582 строк, файл в 330МБ обработан за 37 секунд, размер файла уменьшился мало – до 315 МБ.
Показателен файл таблицы с неким кэшем движка – 1588 строк, объём файла 1,9 ГБ – оптимизация длилась меньше 1 секунды и размер файла стал 10 МБ.

Озаботился проблемой разрастания таблиц в БД. Надо их дефрагментировать. Таблицы в InnoDB. Провёл пару замеров с одной из самых больших таблицей под рукой – log:
- больше 3 миллионов записей;
- размер файла log.ibd – 3,5ГБ;

Для начала мне нужно было заменить значение одного из полей таблицы:
mysql> update log set tip='no data';
До замены в этом поле была довольно длинная строка с информацией user-agent, полученной от браузеров, посетителей, т.е. новая строка в несколько раз короче старой.
Результаты:
Query OK, 3033596 rows affected (57 min 56.91 sec)
Rows matched: 3239214 Changed: 3033596 Warnings: 0
Размер файла заметно увеличился – 4ГБ. Очевидно надо дефрагментировать таблицу (это был плавный переход к следующему тесту)))

Второй тест – оптимизация таблицы:
mysql> optimize table log;
Результаты:
mydb.log | optimize | note | Table does not support optimize, doing recreate + analyze instead
mydb.log | optimize | status | OK
2 rows in set (38 min 47.55 sec)
Размер файла существенно уменьшился – 2,7ГБ, а было ведь 4ГБ!
Напрашивается вывод о том, что оптимизацию надо проводить почаще, но тут надо учитывать, что во время оптимизации таблица будет заблокирована и недоступна для ваших скриптов.

Для полноты картины конечно не обойтись без информации о сервере – старенькая рабочая станция:
- софт – FreeBSD 7.2, apache 2, php, MySQL;
- Intel Pentium4 3.40GHz;
- RAM 3GB;
- система и БД лежат на двух разных винтах;
- сервер, фактически, выделенный;

Следующим будет оптимизация боевого, сильнонагруженного сервера, с кучей больших таблиц, общим размеров гигов под 10. Результаты сообщу дополнительно. Вот только надо выбрать время и заявить ТО на пару часов )

Дополнение от 03-08-2010

Добавление индекса к база размером более 4ГБ и с более 4 с половиной мульёна строк заняло 18 минут полного отказа СУБД от обслуживания:
mysql> alter table log add index (id_site);
Query OK, 4784444 rows affected (18 min 49.74 sec)
Records: 4784444 Duplicates: 0 Warnings: 0

Проблема довольно чётко выявляется по логам PHP:
[Tue Oct 27 08:24:36 2009] [error] [client 10.0.0.13] PHP Warning: Zend Optimizer for PHP 4.4.x cannot be found (expected at '/usr/local/Zend/lib/Optimizer-3.3.0/php-4.4.x/ZendOptimizer.so') - try reinstalling the Zend Optimizer in Unknown on line 0


И действительно папки «/usr/local/Zend/lib/Optimizer-3.3.0/php-4.4.x» нет, ну и, соответственно, файла «ZendOptimizer.so» тоже нет.
Зато в дистрибутиве Zend Optimizer, в директории «data», есть вот такие папки:
4_2_0_comp
4_2_x_comp
4_3_x_comp
4_4_x_comp
5_0_x_comp
5_1_x_comp
5_2_x_comp

По-моему, весьма показательные названия )
Проверяем – копируем папку с названием, соответствующим версии нашего PHP, в папку, упоминаемую в логах:
cp -r data/4_4_x_comp /usr/local/Zend/lib/Optimizer-3.3.0/php-4.4.x

Проверяем и убеждаемся, что ошибки более не появляются в логах.

В общем-то уже ура, но я предпочитаю устанавливать Zend Optimizer сразу для всех версий PHP, которые есть в дистрибутиве, ну-у-у… например, для того, чтобы не думать об этом при обновлении PHP. Поэтому для автоматизации процесса сделал небольшой shell-скрипт, который привожу здесь не тщеславия ради, а токмо чтобы не потерять его )

Собственно скриптик:
#!/bin/sh

#eof


Дополнение от 29-10-2009

Тут ещё выяснилась проблема с Zend Optimizer под PHP5 под FreeBSD 7.2 amd64 – не работает с конфигурацией, которую генерит инсталлятор Zend Optimizer. Надо добавить ещё строчку «zend_optimizer.optimization_level=14″:
[Zend]
zend_optimizer.optimization_level=14
zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.3.0
zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-3.3.0
zend_optimizer.version=3.3.0a
zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so
zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so


В качестве сборщика выбран пакет flow-tools, последней на данный момент версии – 0.68, который был установлен из портов: «/usr/ports/net-mgmt/flow-tools».
В качестве хранилища взят MySQL версии 5.1.34.

Установка указанных пакетов не вызвала никаких проблем и описывать её я не буду )

На первом этапе надо наладить сбор данных и их экспорт в таблицу MySQL.

Мои знания о netflow вообще и о flow-tools в частности весьма поверхностны, так что просьба не пинать за не самые лучшие решения, а помочь советом в случае чего )

Запуск сборщика данных

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

/usr/local/bin/flow-capture
 -n48
 -N0
 -w /data/flow
 -E1G
 0/10.0.1.13/2055

Опишу использованные мной параметры:

• -n48 – количество ротаций файлов за сутки, 48 раз – это каждые полчаса;
• -N0 – формат имён файлов со статистикой, 0 – просто файл в указанной папке;
• -w /data/flow – папка для хранения файлов;
• -E1G – размер файла, по достижении которого, файл со статистикой ротейтится – 1ГБ, если размер файла не достигает указанного, то файл ротейтится согласно параметра -n48;
• 10.0.1.5/10.0.1.13/2055 – принимать данные, отправленные на адрес 10.0.1.5/принимать данные только от экпортёра 10.0.1.13/порт для ожидания данных;

Сборщик будет висеть на указанных айпишнике и порту, принимать данные от указанного адреса и складывать их во временный файл в папке /data/flow, например с таким именем:

tmp-v05.2009-05-11.183644+0600

Через промежуток времени, согласно параметра -n48, а в нашем случае это полчаса, временный файл будет переименован в окончательный, например вот такой:

ft-v05.2009-05-11.183644+0600

И затем будет создан новый временный файл:

tmp-v05.2009-05-11.190609+0600

Пишем скриптик для запуска коллектора и помещаем его в «/usr/local/etc/rc.d», в простом случае он может быть вот такой:

#!/bin/sh

CMD="/usr/local/bin/flow-capture
 -n48
 -N0
 -w /data/flow
 -E5G
 10.0.1.5/10.0.1.13/2055"

PID="/var/run/flow-capture.pid.2055"

case "$1" in
 start)
  echo "Start flow-capture"
  $CMD
 ;;
 stop)
  echo "Stop flow-capture"
  kill -TERM `cat $PID`
 ;;
 *)
  echo " Usage: `basename $0` { start | stop }"
  exit 1
 ;;
esac

exit 0

Ну и конечно надо разрешить в нашем файрволе входящие пакеты с адреса экспортёра на адрес коллектора по протоколу udp и на порт 2055.

Настройка экспорта данных с циски

Настраиваем циску для экспорта данных с нужного нам интерфейса:

cs#conf t
cs(config)#ip flow-export version 5
cs(config)#ip flow-export destination 10.0.1.5 2055
cs(config)#int bvi1
cs(config-if)#ip flow egress
cs(config-if)#ip flow ingress
cs(config-if)#^Z

Посмотреть что получилось на циске можно вот так:

cs#show ip flow interface
BVI1
  ip flow ingress
  ip flow egress
cs#show ip flow export
Flow export v5 is enabled for main cache
  Export source and destination details :
  VRF ID : Default
    Destination(1)  10.0.1.5 (2055)
  Version 5 flow records
  4084394 flows exported in 150001 udp datagrams
  0 flows failed due to lack of export packet
  0 export packets were sent up to process level
  0 export packets were dropped due to no fib
  0 export packets were dropped due to adjacency issues
  0 export packets were dropped due to fragmentation failures
  0 export packets were dropped due to encapsulation fixup failures

Экспорт данных из файла в текстовый вид

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

flow-export -f2 -mDPKTS,DOCTETS,SRCADDR,DSTADDR < raw_file

Ключ -f2 задаёт формат вывода - ASCII с полями, разделёнными запятой. Поля, которые вы хотите увидеть задаются параметром -m, список всех полей есть в мане к flow-export. При указании полей, насколько я понял, нужно перечислять их в порядке следования в списке в мане, например, указать поле DPKTS после поля DSTADD нельзя - это приведёт к ошибке:

# flow-export -f2 -mDOCTETS,SRCADDR,DSTADDR,DPKTS < raw_file
flow-export: Out of order field: DPKTS
flow-export: ftxfield_parse(): failed

Список полей для экспорта можно задать и при помощи масок, что будет короче в написании, но сложнее в восприятии )

Подготовка MySQL для сохранения данных

Понятно, что прежде чем записывать данные в MySQL, нужно создать пользователя, базу данных и таблицу с нужными нам полями.
Описывать создание пользователя и базы я не буду в виду тривиальности задачи )
Остановлюсь на создании таблицы, в моём случае это было примерно так:

create table export (
 unix_secs int(11) unsigned null,
 exaddr varchar(16) null,
 dpkts int(10) unsigned null,
 doctets int(10) unsigned null,
 first int(11) unsigned null,
 last int(11) unsigned null,
 srcaddr varchar(16) null,
 dstaddr varchar(16) null,
 srcport smallint(5) unsigned null,
 dstport smallint(5) unsigned null,
 prot tinyint(3) unsigned null,
 key (srcaddr)
);

Возможно, из-за отсутствия опыта работы с netflow, я мог собрать ненужные мне поля, а какие-то интересные, наоборот, пропустить. Это можно легко поправить в рабочем порядке )

Экспорт данных из файла в MySQL

Теперь, когда СУБД готова к приёму наших данных, можно их экспортировать:

/usr/local/bin/flow-export -f3
 -mUNIX_SECS,EXADDR,DPKTS,DOCTETS,FIRST,
 LAST,SRCADDR,DSTADDR,SRCPORT,DSTPORT,PROT
 -u "flow:DBPassword:localhost:/tmp/mysql.sock:flow:export" < raw_file

Параметр -f3 задаёт формат экспорта - MySQL, параметр -u задаёт данные для доступа к базе данных - "пользователь:пароль:хост:порт:база:таблица".

Так же не забываем о необходимости соблюдения соответствия очерёдности полей, экпортируемых из файлов, с очерёдности полей, созданных в таблице.

Периодичность запуска этой процедуры определите сами с учётом своих нужд. В моём случае довольно и одного раза в час.

Также, в зависимости от ваших потребностей и возможностей, решайте экспортировать ли все данные в одну таблицу или в разные таблицы, например по дате. В последнем случае, конечно, одной указанной выше командой не обойтись - нужно, как минимум, ещё и создавать таблицы по мере необходимости.
Так же нужно подумать об удалении уже обработанных файлов с netflow-данными, чтобы не занимали место на диске почём зря )

Я решил, что мне удобнее хранить данные посуточно в отдельных таблицах с названиями типа "export_0512". Для это я написал небольшой скрипт на perl, который проверяет наличие таблицы для данного дня, при необходимости создаёт её и экспортирует в неё данные указанной выше командой, а также удаляет таблицу за этот день, но прошлого месяца.

Выборки из MySQL

Как извлекать нужные данные из БД учить не буду, т.к. и сам не очень хорошо в этом разбираюсь. Приведу лишь несколько запросов, которые я использую.

Найти десятку самых активных хостов из сети "10.255.0" по количеству исходящих байт:

select srcaddr,sum(doctets) as traf_out from export_0511
 WHERE srcaddr like '10.255.0.%' group by srcaddr order by traf_out desc limit 10;

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

select srcaddr,sum(doctets) as traf_int,dstport,prot from export_0512
 WHERE srcaddr like '10.255.0.3' group by dstport  order by traf_int desc limit 10;

Найти десятку удалённых хостов, на которые был наибольший исходящий трафик с указанного айпишника:

select srcaddr,dstaddr,sum(doctets) as traf_int from export_0511
 WHERE srcaddr like '10.255.0.3' group by dstaddr  order by traf_int desc limit 10;

Заключение

Данный пример позволяет только лишь быстро запустить сбор данных и сделать какие-либо запросы из базы данных. Различные проверки ошибок, удобства и т.п. каждый реализует сам в меру своих требований и фантазии )
Кому-то, наверняка, потребуется и веб-интерфейс для запросов в базу, но лично для меня и данного случая такой необходимости пока нет.

Буду благодарен за конструктивную критику и советы )

Поменял переменную ядра:
~> sudo sysctl vfs.usermount=1

Прописал то же самое в /etc/sysctl.conf:
vfs.usermount=1

В файле /etc/rc.conf дописал:
devfs_system_ruleset="localrules"

Создал файл /etc/devfs.rules:
[localrules=10]
add path 'da*' mode 0660 group wheel
Таким образом поменял для всех устройств, начинающихся с «da», группу на wheel и дал права на чтение и запись для владельца и группы. По-умолчанию указана группа operator, в которую я не вхожу.

Посмотрел какие права на устройстве в данный момент:
~> ls -l /dev/da0*
crw-r----- 1 root operator 0, 138 Mar 31 16:15 /dev/da0
crw-r----- 1 root operator 0, 139 Mar 31 16:15 /dev/da0s1

Переконфигурировал устройства:
~> sudo /etc/rc.d/devfs restart

Убедился, что права и группа изменились в нужную сторону:
~> ls -l /dev/da0*
crw-rw---- 1 root wheel 0, 138 Mar 31 16:15 /dev/da0
crw-rw---- 1 root wheel 0, 139 Mar 31 16:15 /dev/da0s1

Теперь надо назначить себя владельцем точки монтирования:
~> sudo chown malik:wheel /mnt/flash
Ну или, если угодно, создать свою точку монтирования:
~> mkdir ~/flash

Кстати, для монтирования CD-ROM от имени пользователя достаточно чтобы точка монтирования принадлежала этому самому пользователю, т.к. писать на CD-ROM стандартным средствами системы мы не собираемся )

И, наконец, монтирую флешку:
~> mount_msdosfs /dev/da0s1 /mnt/flash

Всё нормально – флешка подмонтирована и можно нормально работать с файлам и папками от имени пользователя, не прибегаю к правам рута.

Замечание:
Монтирование флешки с указание локальной кодировки от имени обычного пользователя возможно только после хотя бы одного монтирования из-под суперпользователя:
~> mount_msdosfs -L ru_RU.KOI8-R /dev/da0s1 /mnt/flash
mount_msdosfs: cannot find or load "msdosfs_iconv" kernel module
mount_msdosfs: msdosfs_iconv: Operation not permitted
~> sudo mount_msdosfs -L ru_RU.KOI8-R /dev/da0s1 /mnt/flash
Password:
~> sudo umount /mnt/flash
~> mount_msdosfs -L ru_RU.KOI8-R /dev/da0s1 /mnt/flash
~>


Как оказалось проблема была из-за какой-то ошибки файловой системы, fsck помог:
fsck /dev/sda4

За столько лет работы под ФриБСД ни разу с такой хренью не сталкивался )

Процедура простая, но требует наличия установочного диска.

Железка: Sun Blade 100.
Система: SunOS 5.8.
Установочный DVD-диск.

1. Нажимаем комбинацию клавиш STOP + A, чтобы остановить систему. Я делал это в процессе загрузки системы. Должно появиться приглашение:

ok

2. Загружаем систему с диска в однопользовательский режим:

boot cdrom -s

3. проверяем, если нужно, корневой раздел диска:

fsck /dev/dsk/c0t0d0s0

4. монтируем корневой раздел:

mount /dev/dsk/c0t0d0s0 /a

5. Удаляем зашифрованный пароль пользователя root:

vi /a/etc/shadow

По идее нужно будет ещё и поменять права на файл:

chmod u+w /a/etc/shadow

6. Перегружаемся, но уже с жёсткого диска:

reboot

7. Заходим под пользователем root без пароля и задаём ему новый пароль:

passwd

Всё.

Один раз измерил количество пакетов приходящих на адрес форума за минуту – получилось 29347.

Вот мне интересно кому это нужно? Смысл не совсем понятен. Ну приходится мне закрывать все обращения из внешнего мира, но ведь ясно, что подавляющее большинство посетителей приходит из местных сетей.