LINUX.ORG.RU
Форум — Admin  

ipt_netflow и mac & vlan

 ,


1

1

Обновил, а заодно собрал с полезными флагами ipt_netflow:

# cat /proc/net/stat/ipt_netflow
ipt_NETFLOW 2.1, srcversion 89556420DEF91883C3D504B; mac nel vlan
Protocol version 10 (ipfix), refresh-rate 20, timeout-rate 30, (templates 13, active 13).

Запускаем nfcapd:

nfcapd -l '/var/log/netflow/' -t 300 -D -p 2055 -z

а в логах все так и нет маков/вланов. Вопрос на засыпку: их не передает модуль ядра, хотя он собран с поддержкой оных, или nfcapd про них «не знает»? Debian Jessie, nfdump, содержащий nfcapd взят из sid, так как старый с wheezy (в jessie пакета nfdump нет) не умеет 10-ю версию netflow.

iptables с "-j NETFLOW" естественно имеется.

UPD: nfcapd с -T 6,10,11 не помогло:-(

★★★★★

Последнее исправление: leg0las (всего исправлений: 6)
← Debug по определенному IP-адресу в Squid3
Документирование действий администратора →

Сам спросил, сам отвечу:

man nfcapd:

-T <extension list>
          Specifies  the list of extensions, to be stored in the netflow file.  Regardless of the extension list, the following netflow data is stored per record: first, last, fwd status, tcp flags, proto, (src)tos, src port,
          dst port, src ipaddr, dst ipaddr, in(packets), in(bytes). In addition nfcapd recognises the extensions as described below. Some are valid for v5/v7/v9, but most of them make only sense for v9. Any  specified  exten‐
          sions which do not exist in the input netflow records are ignored.

          Extensions:
           v5/v7/v9/IPFIX extensions:
            1 input/output interface SNMP numbers.
            2 src/dst AS numbers.
            3 src/dst mask, (dst)TOS, direction.
            4 line Next hop IP addr line
            5 line BGP next hop IP addr line
            6 src/dst vlan id labels
            7 counter output packets
            8 counter output bytes
            9 counter aggregated flows
           10 in_src/out_dst MAC address
           11 in_dst/out_src MAC address
           12 MPLS labels 1-10
           13 Exporting router IPv4/IPv6 address
           14 Exporting router ID
           ...
leg0las ★★★★★
() автор топика
Ответ на: комментарий от vel

У меня v10, с v9 тоже пробовал. Я уже частично разобрался, вывод делается с помощью nfdump -r <file> -A <атрибуты>, где в атрибутах указывается все, что нужно. Не понятно только, почему:

1. после обновления с 2.0.1 некоторые даты идут как 1970-01-01.

2. не везде есть src mac, местами 00-00-00...

3. практически везде отсутствует dst mac.

4. vlan id 0. В общем, буду завтра ковырять.

leg0las ★★★★★
() автор топика
Ответ на: комментарий от leg0las

mac-src/dst есть только в принятых.

на счет vlan-id там вообще все странно, особенно если есть аппаратная поддержка vlan

vel ★★★★★
()
Ответ на: комментарий от vel

С датами разобрался - такая хрень происходит на v9, на v5 все ок. Тогда пока посижу на v5, или может со временем соберу с гита.

leg0las ★★★★★
() автор топика
Ответ на: комментарий от vel

и в данных есть vlan-тег ?

В v5 же нет поля для vlan-тега? Можно передать только индекс интерфейса. Или его в какие-то другие поля записывают?

Deleted
()
Ответ на: комментарий от leg0las

IMHO если ты используешь vlan-интерфейс типа "-i eth1.47" то vlan-тег ты уже не получишь. Не совсем понятно влияет ли на это REORDER_HDR.

Вот если брать трафик с устройства (-i eth1), то там может/должна быть информация о vlan-е

vel ★★★★★
()
Ответ на: комментарий от leg0las

Глянул я в исходники - там все просто и топорно.

На сетевушках с аппаратной поддержкой vlan - оно не должно работать.

Возможно если отключить REORDER_HDR, то на входщих пакетах vlan должен быть виден.

vel ★★★★★
()
Ответ на: комментарий от vel

я использую интерфейс вида vlan123, в правилах iptables везде так фигурирует.

leg0las ★★★★★
() автор топика
Ответ на: комментарий от vel

На сетевушках с аппаратной поддержкой vlan - оно не должно работать

Охренеть. А зачем тогда такая поддержка vlan?

leg0las ★★★★★
() автор топика
Ответ на: комментарий от leg0las

Аппаратная поддержка vlan-ов - это хорошо. Это снижение нагрузки на cpu.

Если конкретно про ipt_NETACCT - то афторы просто поленились сделать нормальную поддержку vlan-ов для случая аппаратной поддержки vlan-ов. Фича не сильно востребованная. Можешь дописать полноценную реализацию? Напиши и может кто спасибо скажет.

А с другой стороны - если ты ведешь подсчет на конкретном интерфейсе, то зачем нам знать его vlan-id ? Вот если подсчет ведется на каком-нибудь зеркалируемом трафике, тогда оно может быть еще как-то пригодиться (я не могу придумать варианта где это даст пользу или где это необходимо).

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от vel

У меня бегает порядка 20 vlan`ов, мне иногда наглядней получить инфу «откуда эта хрень». На счет «допиши» - я не программист, я админ)

leg0las ★★★★★
() автор топика
Ответ на: комментарий от leg0las

ipt_NETFLOW - этот подсчет трафика IPv4/IPv6. Подумай - как там использовать vlan-id ?

у тебя есть вариант когда два пакета с одинаковыми адресами и портами приходят из разных vlan? И тебе важно об этом знать? Я тебе сочувствую!

А дописать нужно чуть больше 5 строк 

u_int16_t get_vlan_id(struct sk_buff *skb) {
  if(skb->dev && is_vlan_dev(skb->dev)) {
    struct vlan_dev_priv *vlan = vlan_dev_priv(skb->dev);
    return vlan->id;
  }
return 0;
}

Только на сколько этот код будет портабельным между различными версиями ядра - ХЗ.

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от vel

у тебя есть вариант когда два пакета с одинаковыми адресами и портами приходят из разных vlan?

Нет, все грамотно разнесено. Просто было интересно включить эту фичу и посмотреть поведение.

leg0las ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Debug по определенному IP-адресу в Squid3
Admin
Документирование действий администратора →