Я новичок в 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, экспортируют только записи, связанные с трафиком сборщика мостов? Могу ли я изменить эти команды, чтобы включить или сосредоточиться исключительно на тестовых хостах?
Коллега обнаружил мою ошибку ... Мои тестовые хосты на самом деле не были подключены к моему мосту, хотя я был уверен, что они есть. Как только мы правильно соединили тестовые хосты, я «автоматически» увидел экспорт, который я надеялся увидеть.
В этом проблема виртуализации, не так ли? Иногда не видно наиболее очевидных проблем ... Спасибо всем, кто прочитал и рассмотрел мой пост.