Я новичок в OVS и пытаюсь получить IPFIX работаю на моем мосту OVS. Я опираюсь на полезную информацию из предыдущего поста:
Хорошие новости: Я получил свой переключатель OVS для экспорта потоков IPFIX в мой коллектор. Плохая новость в том, что коммутатор не экспортирует потоки, которые мне нужны. Вместо экспорта записей потока, описывающих трафик между моими тестовыми хостами, коммутатор экспортирует только записи, описывающие трафик между коммутатором и коллектором… который является трафиком, который меня НЕ интересует.
Чтобы описать мою экспериментальную концепцию вкратце о среде: у меня есть коммутатор OVS с тремя виртуальными машинами; два тестовых хоста и один сборщик:
root@OVSHost# ovs-vsctl list bridge
_uuid : 2fb2fa30-e1ed-4cbf-a365-7462e5f83cbc
...
name : "myBridge"
...
ports : [1940fd00-2dcb-4c85-a077-bae1653d9841, 279e489d-a940-4056-b753-2213fd46d5fd,
31258106-589b-40b9-94c9-a29711991a91, ee38080d-3446-4760-a297-801c5ffe76bb]
root@OVSHost#
Я первым признаю, что не знаю, какие порты поддерживают тестовые хосты, а какие - сборщик. Я установил libIPFIX (бесплатный сборщик IPFIX) на виртуальной машине сборщика. Наконец, я включил экспорт IPFIX на моем мосте OVS, выполнив эти две команды:
ovs-vsctl clear bridge myBridge ipfix
ovs-vsctl -- set Bridge myBridge ipfix=@i -- --id=@i create IPFIX targets=\"192.168.2.2:4739\" obs_domain_id=123 obs_point_id=456 sampling=5
После того, как вышеперечисленные команды были на месте, я увидел, что записи потока поступают на мой сборщик. Но при ближайшем рассмотрении Я понял, что потоки, которые я видел, описывают трафик между мостом (192.168.2.1) и сборщиком (192.168.2.2). Вот одна такая запись, обработанная сценарием python, который я написал для устранения неполадок:
RECORD 123, using Template 284
138(observationPointId:4) 456
61(flowDirection:1) 0
4(protocolIdentifier:1) 17
8(sourceIPv4Address:4) 192.168.2.1
12(destinationIPv4Address:4) 192.168.2.2
7(sourceTransportPort:2) 37512
11(destinationTransportPort:2) 4739
Сначала я подумал, что мое программное обеспечение-сборщик неправильно настроено, но затем я запустил tshark на виртуальной машине-сборщике и увидел то же самое. (Отредактировано для краткости):
root@6bfcec0a4bd8:/# tshark -f 'port 4739' -d udp.port==4739,cflow -V -i eth1
Capturing on 'eth1'
Frame 64: 314 bytes on wire (2512 bits), 314 bytes captured (2512 bits) on interface 0
...
Ethernet II, Src: 32:fa:b2:2f:bf:4c (32:fa:b2:2f:bf:4c), Dst: 82:9e:f8:b2:e7:27 (82:9e:f8:b2:e7:27)
...
Internet Protocol Version 4, Src: 192.168.2.1, Dst: 192.168.2.2
...
User Datagram Protocol, Src Port: 37512, Dst Port: 4739
...
Cisco NetFlow/IPFIX
Flow 1
Observation Point Id: 456
IfName: myBridge
Protocol: UDP (17)
SrcAddr: 192.168.2.1
DstAddr: 192.168.2.2
SrcPort: 37512 (37512)
DstPort: 4739 (4739)
Понимаете, о чем я? Похоже, мой мост передает информацию о потоках в самом экспорте IPFIX. Что нормально…
… за исключением того, что 100% моих записей потока выглядят так, как указано выше. Когда я запускаю тестовый трафик между двумя тестовыми хостами, я никогда не вижу ни одной записи, описывающей этот трафик. Никогда. Это похоже на то, что мост экспортирует данные потока только тогда, когда поток описывает трафик, предназначенный сборщику, и игнорирует весь другой трафик.
Итак, на этом этапе, Я предполагаю, что команды, которые я использую для экспорта потоков из моста OVS, экспортируют только записи, связанные с трафиком сборщика мостов? Могу ли я изменить эти команды, чтобы включить или сосредоточить внимание исключительно на тестовых хостах?
Коллега нашёл мою ошибку... Мои тестовые хосты на самом деле не были привязаны к моему мосту, хотя я был уверен в этом. Как только мы правильно подключили тестовые хосты, я "автоматически" увидел экспорт, который я надеялся увидеть.
В этом и проблема виртуализации, не так ли? Иногда не видно самых очевидных проблем... Спасибо всем, кто прочитал и обдумал мой пост.