есть Фря 5.0 релиз.
Скачал последнюю версию сабжа 4.4.
делаю ./configure
потом make и получаю
____________________________________________________________________

cd src/snmplib; make
cd src/apps; make
cd src/bgp; make
gcc  -I../../src/bgp/integrat -I../.. -DNETRAMET -DNF_OCX_BGP=1 -DFREEBSD -DHAVE_CONFIG_H -c ../../src/bgp/integrat/readbgp.c
../../src/bgp/integrat/readbgp.c:122: conflicting types for `sys_nerr'
/usr/include/stdio.h:344: previous declaration of `sys_nerr'
In file included from ../../src/bgp/integrat/readbgp.c:130:
../../src/bgp/wattcp/tcp.h:16:1: warning: "inet_ntoa" redefined
In file included from ../../src/bgp/wattcp/tcp.h:7,
                 from ../../src/bgp/integrat/readbgp.c:130:
/usr/include/arpa/inet.h:124:1: warning: this is the location of the previous definition
*** Error code 1

Stop in /usr/home/dim/filez/NeTraMet44/src/bgp.
*** Error code 1

Stop in /usr/home/dim/filez/NeTraMet44.
________________________________________________________________________
Причем на другой машине всё собирается без проблем, правда там машина 4.7.

В чем собака порылась? Или плюнуть на Netramet и что нибудь другое посмотреть?

Спасибо за помощь, Митт.

• Камарадос, похелпите, не ставится Netramet :(,Вячеслав, 14:23 , 18-Июл-03
  • Спасибо, сие уже испробовано и не прокатило, взял и тупо поставил(+),kitkat, 14:33 , 18-Июл-03
    • Спасибо, сие уже испробовано и не прокатило, взял и тупо пос...,Вячеслав, 18:28 , 18-Июл-03
      • Большое спасибо за обстоятельное объяснение!,kitkat, 09:53 , 21-Июл-03
        • Большое спасибо за обстоятельное объяснение!,Вячеслав, 15:29 , 21-Июл-03
          • Спасибо Мастер!,kitkat, 15:58 , 21-Июл-03

ИМХО лучше взять версию 4.5b8, там кое какие косяки поправили :)

>../../src/bgp/integrat/readbgp.c:122: conflicting types for `sys_nerr'
>/usr/include/stdio.h:344: previous declaration of `sys_nerr'

А так первое что приходит в голову это смотрим что там в файле
/usr/include/stdio.h:344 определяеся, потом что же там в
/src/bgp/integrat/readbgp.c:122 пытались определить и приводим в соответствие. Можно на ура попробовать просто закоментировать
строку /src/bgp/integrat/readbgp.c:122 и перекомпилить :)
Скорее всего скомпилится и работать будет, но не гарантирую :)

>In file included from ../../src/bgp/integrat/readbgp.c:130:
>../../src/bgp/wattcp/tcp.h:16:1: warning: "inet_ntoa" redefined
>In file included from ../../src/bgp/wattcp/tcp.h:7,

>     from ../../src/bgp/integrat/readbgp.c:130:
>/usr/include/arpa/inet.h:124:1: warning: this is the location of the previous definition

Здеся тоже аналогично :)

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

Митт.

>из портов, всё теперь радотает, вот только теперь маюсь в написании скрипта,
>который бы суммировал статистику, пока не получается, изучаю вот perl, жалко
>не программер я =(
>
>Митт.

Скрипт это даже не полдела, это так - процентов 30 :) Нетрамет весьма
мощный и гибкий комплекс, но и в то же время оченно навороченный. Чтобы довести все до ума надо... :)

1. Определится откуда и какой трафф нуна снимать. Если это никсовый  
   роутер, то проще, если же кошак и на нем НАТ или тунель подняты то
   намаетесь - без RouterNextHop при поднятом НАТ-е правильно исходящий
   траф не посчитаешь т.к. у кошака если поднят НАТ имеем глюки с дест
   интерфеем. А нетрамет параметр RouterNextHop из нетфлова никак не
   обрабатывает. Да и вааще глюков у циско нетфлов хватает, хоть
   отбавляй...

2. определиться с ротацией логов коллектора/ридера и результирующего
   файла ридера, интервалом вычитывания данных ридером из колектора.
   Я рекомандовал бы убивать ридера по крону раз в сутки, интервал    
   вычитывания  взять равным  561 секунде :)

3. Обязательно!!! написать свои правила и разобраться с компилятором srl
   (который тоже не безглючен) Стандартные rules.x-ip годятся только
   для пробы, чтобы понять что куда и откуда сыпится, чтобы по полученной
   инфе написать свои правила. Иначе если вы правилами не приведете
   флов в приемлимый и удобный для обработки вид, то а) получите х метров
   бесполезного мусора и тем самым сведете на нет все преимущества
   комплекса, который как раз и ценен тем что правила мона написать так,
   что дампится будет исключительно нужная инфа б) замаетесь писать скрипт
   который будет разгребать этот мусор. А он при этом должен быть ооочень
   умным чтобы корректно разгрести этот мусор и работать будет весьма
   медленно.

4. Написать собственно скрипт, который будет обсчитывать полученные
   дельты. Его сложность, скорость работы и объемы обрабатываемой
   информации напрямую зависят от того, насколько грамотно будут написаны
   правила. В идеале при несложной задаче, правильно написанных правилах
   и небольшом траффике скрипт можно сваять даже на шелле. НО лучше сразу
   писать его на перле или ваще озаботиться хранением инфы в базе SQL
   сервера. Шелл слишком медленно работает для таких дел (и имеет
   ограниченные по сравнению с перлом возможности обработки текстов)плюс
   задача развиваясь может быстро "вырасти из штанов" и скрипт все равно
   придется переписывать.

>2. определиться с ротацией логов коллектора/ридера и результирующего
>   файла ридера, интервалом вычитывания данных ридером из колектора.
>   Я рекомандовал бы убивать ридера по крону раз в
>сутки, интервал
>   вычитывания  взять равным  561 секунде :)
Это сделано, благодаря статье на opennet.ru
>4. Написать собственно скрипт, который будет обсчитывать полученные
>   дельты. Его сложность, скорость работы и объемы обрабатываемой
>   информации напрямую зависят от того, насколько грамотно будут написаны
>
>   правила.
Вот этот этам меня и интересует в настоящее время ;)
>НО лучше сразу
>   писать его на перле или ваще озаботиться хранением инфы
>в базе SQL

К сожалению еще не знаком с SQL-ем, и вообще мало представляю как это всё дело можно запихнуть в Базы SQL.

Митт.

>Вот этот этам меня и интересует в настоящее время ;)
Детально писать в конфе что и зачем в рулезах, как писать скрипт и т.п. слишком долго, скажу в кратце о....

....граблях srl (те, что я знаю) :

1. в ряде случаев некорректно отрабатывает компиляция конструкций
   IF
   ELSE IF
   ELSE

   Если не хотите геморроя, то пользуйте только IF-ELSE

2. Конструкции типа IF a==1 && b==2 лучше заменять на аналогичные
   IF a==1
    IF b==2

или же если совсем в немоготу и логическое И все же нужно, то перед
каждой командой COUNT, IGNORE и NOMATCH вставляйте строку
optimise 1;

У srl очень криво написан процесс построения условий содержащих && и процедура оптимизации (тоже весьма кривая) запускающаяся при втором проходе иногда некорректно удаляет лишние переходы. Чтобы это преодолеть
автор на ура отключает оптимизацию (srl-emit.c строка 653
emit_opt_level(0);  /* Mark break between expressions to be optimised */ )
и далее забывает ее включить. В итоге рулесы оказываются неоптимизировнными и при загрузке правил немак злобно
ругается на строки, которые никогда не будут выполняться. Хотя
работать правила все же будут и теоретически на это мона забить, но
это ИМХО не совсем правильно :)
  
.... и основных принципах написания самих рулесов:

1. каждый пакетик флова индивидуально обрабатывается правилами. Обработка
   завершается по команде COUNT IGNORE NOMATCH. Все что стоит после них
   ВЫПОЛНЯТЬСЯ НЕ БУДЕТ и srl и немак будут ругаться на наличие
   неиспользуемого кода.
2. COUNT вносит флов в память коллектора отведенную под счетчики (и  
   потом его от туда вычитывает ридер), IGNORE отбрасывает флов и он
   нигде не посчитается, NOMATСH меняет местами все соурс и дест,
   значения входящего/исходящего траффа и т.п., также ОБНУЛЯЕТ все
   служебные переменные и запускает обработку "перевернутого" флова с
   самого начала. Была ли выполнена команда NOMATСH можно определить
   по переменной MatchingStoD, она равна 0 если было NOMATСH иначе 1
3. По умолчанию ряд параметров (соурс/дест адрес,порт,интерфей и т.п.)
   не пишутся и если не сказать SAVE то в логе получите нули. Чем
   большим параметрам скажете SAVE, тем больше будет лог, больше памяти
   потребуется коллектору под рулесы и сложнее будет скрипт все это
   разгребающий. Сохраняйте только то, что Вам действительно нужно.
   Например если Вас интересует трафф например на 110 порт, то нет
   смысла сохранять порт с которого пришел траффик т.к. почтовый клиент
   его юзает динамически, будет выделена целая куча каунтеров для
   хранения, куча записей в логе, а смысл хранить эту информацию
   практически равен нулю. Или если вас интересует какой из ваших хостов
   сколько нажег траффа но не интересна раскладка куда, то не сохраняйте
   адреса если они не принадлежат вашим хостам. В итоге файл флова будет
   содержать нужную вам инфу и весить при этом на порядок меньше.
4. Весь разбор трафика делайте правилами коллектора, выставляя
   соответствующие признаки в служебных переменных и сохраняя нужные из
   них (достаточно просто включить в описание формата). А скриптом уже
   суммируйте нужные дельты исходя из значения сохраненной(ых) служебных
   переменных

Удачи !

Митт