pesvo

Благодарю за скрипт для проверки. Вот что имею в выводе ./sensornf9.pl ts: 1692031769, proto: 1, src 192.168.55.10:4078, dst: 77.88.55.60:4078, nat: xx.xx.xx.xx:4078, event: 1 ts: 1692031799, proto: 1, src 192.168.55.10:4096, dst: 5.255.255.70:4096, nat: xx.xx.xx.xx:4096, event: 1 ts: 1692031815, proto: 6, src 192.168.55.10:39362, dst: 185.125.190.49:80, nat: xx.xx.xx.xx:39362, event: 1 ts: 1692031820, proto: 6, src 192.168.55.10:39362, dst: 185.125.190.49:80, nat: xx.xx.xx.xx:39362, event: 2 ts: 1692031822, proto: 1, src 192.168.55.10:4220, dst: 5.255.255.70:4220, nat: xx.xx.xx.xx:4220, event: 1 ts: 1692031824, proto: 1, src 192.168.55.10:4078, dst: 77.88.55.60:4078, nat: xx.xx.xx.xx:4078, event: 2 ts: 1692031826, proto: 1, src 192.168.55.10:4222, dst: 5.255.255.70:4222, nat: xx.xx.xx.xx:4222, event: 1 ts: 1692031830, proto: 1, src 192.168.55.10:4096, dst: 5.255.255.70:4096, nat: xx.xx.xx.xx:4096, event: 2 ts: 1692031849, proto: 1, src 192.168.55.10:4220, dst: 5.255.255.70:4220, nat: xx.xx.xx.xx:4220, event: 2 ts: 1692031984, proto: 1, src 192.168.55.10:4222, dst: 5.255.255.70:4222, nat: xx.xx.xx.xx:4222, event: 2 ts: 1692032109, proto: 1, src 192.168.55.10:5120, dst: 5.255.255.70:5120, nat: xx.xx.xx.xx:5120, event: 1 ts: 1692032115, proto: 6, src 192.168.55.10:41078, dst: 185.125.190.48:80, nat: xx.xx.xx.xx:41078, event: 1 ts: 1692032118, proto: 6, src 192.168.55.10:41078, dst: 185.125.190.48:80, nat: xx.xx.xx.xx:41078, event: 2 Это говорит о том, что все передается ок? Вроде ts совпадают по времени. Если да, то как тогда на коллекторе nfcapd и в выводе nfdump получать до конца нужные поля(X-Src IP Addr:Port) и правильный формат времени? Мне интересно кто то использует ли этот модуль xt_Nat также для передачи netflow 9 на сорм? Изначально идея перехода с freebsd ipfw nat + shaper на debian нужна для отправки netflow 9 с NEL на СОРМ, потому что в freebsd нет сенсоров с отправкой NEL, так как этот модуль практически исполняет функцию cgnat, то хотелось бы его использовать нежели обычную связку iptables+ipt_netflow.

С гита nfdump поставил версию последнюю nfdump-1.7.2 вместо 1.6.18 nfdump -V nfdump: Version: 1.7.2-696f563 Options: NSEL-NEL Date: 2023-08-12 13:54:54 +0200 запустил и все равно одно и тоже 1970-01-01 03:00:00.000 время и 0 на X-Src IP Addr:Port в nfcapd показывает nfcapd -E -p 2055 -w /tmp/nfcap-test/ Verbose log level: 3 Add flow source: ident: none, IP: any IP, flowdir: /tmp/nfcap-test Bound to IPv4 host/IP: any, Port: 2055 Init v1 Init v5/v7: Default sampling: 1 Init v9: Max number of v9 tags enabled: 105, default sampling: 1 Init IPFIX: Max number of ipfix tags enabled: 91, default sampling: 1 Startup nfcapd. Process_v9: New v9 exporter: SysID: 1, Domain: 0, IP: xx.xx.xx.xx Flow Record: Flags = 0x01 EVENT, Unsampled Elements = 6: 1 2 12 20 22 25 size = 124 engine type = 0 engine ID = 0 export sysid = 1 first = 0 [<unknown>.000] last = 0 [<unknown>.000] received at = 1692020263687 [2023-08-14 16:37:43.687] proto = 1 ICMP tcp flags = 0x00 ........ ICMP = 3.238 type.code in packets = 0 in bytes = 0 src addr = 192.168.55.10 dst addr = 151.101.2.167 ip exporter = xx.xx.xx.xx снова поля first/last пустые , поэтому передает значения 1970-01-01 03:00:00.000 как в версии nfdump 1.6.18, но сути это не меняет. Снял дамп через tcpdump и посмотрел в wireshark что прилетает от nat сервера на этот порт 2055 по netflow v9 User Datagram Protocol, Src Port: 59337, Dst Port: 2055 Source Port: 59337 Destination Port: 2055 Length: 92 Checksum: 0x7b88 [unverified] [Checksum Status: Unverified] [Stream index: 0] [Timestamps] UDP payload (84 bytes) Cisco NetFlow/IPFIX Version: 9 Count: 2 SysUptime: 8155.520000000 seconds Timestamp: Aug 14, 2023 16:28:36.000000000 RTZ 2 (зима) CurrentSecs: 1692019716 FlowSequence: 54 SourceId: 0 FlowSet 1 [id=0] (Data Template): 300 FlowSet Id: Data Template (V9) (0) FlowSet Length: 40 Template (Id = 300, Count = 8) Template Id: 300 Field Count: 8 Field (1/8): PROTOCOL Field (2/8): L4_SRC_PORT Field (3/8): IP_SRC_ADDR Field (4/8): L4_DST_PORT Field (5/8): IP_DST_ADDR Field (6/8): postNATSourceIPv4Address Field (7/8): postNAPTSourceTransportPort Field (8/8): natEvent FlowSet 2 [id=300] (1 flows) FlowSet Id: (Data) (300) FlowSet Length: 24 [Template Frame: 1] Flow 1 Protocol: ICMP (1) SrcPort: 1001 SrcAddr: 192.168.55.10 DstPort: 1001 DstAddr: 151.101.2.167 Post NAT Source IPv4 Address: xx.xx.xx.xx Post NAPT Source Transport Port: 2025 Nat Event: NAT translation delete (Historic) (2) Немного не пойму вывод в pcap в wireshark, но вроде он передает нужные шаблоны Идеи пока закончились куда копать..

Нашёл свой косяк... Я думал, что надо вместе modprobe xt_NAT nat_pool=<Start IP>-<End IP> и затем modprobe xt_NAT nat_pool=<Start IP>-<End IP> nf_dest=127.0.0.1:2055 но по факту надо было просто прописать одной командой xt_NAT nat_pool=<Start IP>-<End IP> nf_dest=127.0.0.1:2055 и все. Но смущает один момент, я начал получать потоки в nfcapd на удаленном сервере nfcapd -E -T all -p 2055 -l /nfcap-test при чтение через nfdump nfdump -R nfcapd.202308141352 вижу странный вывод, что во-первых, время не корректное, хотя на обоих сервера время правильное и вкл. ntp, и что в столбце X-Dst IP Addr:Port 0.0.0.0:0 Версия nfdump nfdump -V nfdump: Version: NSEL-NEL1.6.18 nfdump -R nfcapd.202308141352 Date first seen Event XEvent Proto Src IP Addr:Port Dst IP Addr:Port X-Src IP Addr:Port X-Dst IP Addr:Port In Byte Out Byte 1970-01-01 03:00:00.000 DELETE Ignore TCP 192.168.55.55:5309 -> 64.233.165.138:443 xx.xx.xx.xx:5309 -> 0.0.0.0:0 0 0 1970-01-01 03:00:00.000 DELETE Ignore TCP 192.168.55.55:5307 -> 142.250.150.198:443 xx.xx.xx.xx:5307 -> 0.0.0.0:0 0 0 1970-01-01 03:00:00.000 CREATE Ignore UDP 192.168.55.55:54248 -> 64.233.165.104:443 xx.xx.xx.xx:54248 -> 0.0.0.0:0 0 0 1970-01-01 03:00:00.000 CREATE Ignore UDP 192.168.55.55:59572 -> 108.177.14.198:443 xx.xx.xx.xx:59572 -> 0.0.0.0:0 0 0 В сам nfcapd прилетает Flow Record: Flags = 0x46 EVENT, Unsampled label = <none> export sysid = 1 size = 96 first = 0 [1970-01-01 03:00:00] last = 0 [1970-01-01 03:00:00] msec_first = 0 msec_last = 0 src addr = 192.168.55.55 dst addr = 108.177.14.198 src port = 59572 dst port = 443 fwd status = 0 tcp flags = 0x00 ........ proto = 17 UDP (src)tos = 0 (in)packets = 0 (in)bytes = 0 ip router = xx.xx.xx.xx engine type = 0 engine ID = 0 received at = 1692010373229 [2023-08-14 13:52:53.229] src xlt port = 59572 dst xlt port = 0 src xlt ip = xx.xx.xx.xx dst xlt ip = 0.0.0.0 nat event = 1: ADD ingress VRF = 0 egress VRF = 0 Покопался на форме в разделе ipt_netflow у людей это было на старой версии nfdump, но тут у меня новая версия nfdump. Подскажите у тех кто использует этот модуль при отправке netflow 9 дата и время корректное и есть ли адреса в столбце X-Src IP Addr:Port? Спасибо.

modprobe xt_NAT nat_pool=xx.xx.xx.xx-xx.xx.xx.xx modprobe xt_NAT nat_pool=xx.xx.xx.xx-xx.xx.xx.xx nf_dest=127.0.0.1:2055 dmesg | grep xt_NAT [ 50.684198] xt_NAT: loading out-of-tree module taints kernel. [ 50.684310] xt_NAT: module verification failed: signature and/or required key missing - tainting kernel [ 50.685711] Module xt_NAT loaded [ 50.685718] xt_NAT DEBUG: IP Pool from xx.xx.xx.xx to xx.xx.xx.xx [ 50.685721] xt_NAT DEBUG: nat pool table mem: 4 [ 50.685723] xt_NAT DEBUG: NAT hash size: 262144 [ 50.685726] xt_NAT DEBUG: Users hash size: 65536 [ 50.687613] xt_NAT DEBUG: sessions htable inner mem: 4194304 [ 50.689106] xt_NAT DEBUG: sessions htable outer mem: 4194304 [ 50.689191] xt_NAT DEBUG: users htable mem: 1048576 [ 50.689192] xt_NAT DEBUG: nat pool table mem: 4 cat /proc/net/NAT/users 192.168.0.10 -> xx.xx.xx.xx (tcp: 21, udp: 51, other: 0) Total users: 1 cat /proc/net/NAT/statistics Active NAT sessions: 73 Tried NAT sessions: 384 Created NAT sessions: 384 DNAT dropped pkts: 337 Fragmented pkts: 0 Related ICMP pkts: 0 Active Users: 1 Модуль выгружал - загружал с опциями этими, сам сервер перезагружал. для теста отправлял и на Lo адрес тоже ничего не прилетает на nfcapd и в tcpdump ничего нет и на удаленный хост если указать в nf_dest соответственно тоже ничего не прилетает, порты тоже менял вместо дефолта 2055. Может я где-то мог допустить ошибку при настройке/установке модуля(модуль тоже переустанавливал), так как пока пробую переехать с freebsd ipfw nat на debian и провожу тесты, а с debian, к сожалению, пока особо не работал, но вроде все делал по инструкции с гита. Может в iptables надо что-то добавить для передачи по порту 2055?

@pppoetest Приветствую, собрал xt_NAT с ссылки гита которую Вы кинули с поддержкой netflow 9 на debian 11.7.0 ядро 5.10.0-22-amd64. Вроде натит нормально клиентов, в proc/net/nat есть данные статистика, сессии, юзеры, но когда хочу отправить потоки netflow на коллектор за счет netflow 9 вводя команду которая указана на гите "пул адресов нат , адрес коллектора и порт 2055" , но на коллектор ничего не прилетает , там запущен nfcapd с прослушиванием 2055 порта и по tcpdump тоже нет пакетов каких либо на этот порт от сервера где запущен xt_nat. Как понимаю у вас xt_nat долго стоит в проде и все прекрасно работает с netflow9 , подскажите в чем может быть дело, может надо какие то доп модули подзагрузить чтобы netflow 9 заработал на xt_nat?

Коллеги, добрый день! У нас в сети используется пару серверов freebsd13.1 nat + shaper на ipfw, требуется реализовать передачу netflow 9 с поддержкой адреса до нат и адреса после нат, то есть nat events(NEL). Почитав форум здесь нашел информацию только до 20год пару сообщение, что людям в итоге пришлось перейти на linux(debian) + iptables + ipt_netflow. На freebsd нашёл пару служб softflowd, ng_netflow с поддержкой netflow 9, но как понимаю там нет этих нужный полей с nat events. Подскажите может в 2023 году кто-то нашёл решение под freebsd для передачи по netflow 9 nat-events (NEL) адреса до нат и адреса после ната или все таки надо переходить на debian + iptables + ipt_netflow под эту задачу?

Решение найдено. Если требуется увеличить LMP V4 ucast da tcam table и в сети не используется ipv6, то помогает hardware profile ipv6 lpm-entries maximum 0 это увеличивает с 6к до 14к максимум на lpm ipv4 tcam на C93180YC-EX

Добрый день! Имеется в активной работе 65 дней C93180YC-EX без лицензии, так как данный коммутатор поддерживает honor based licensing,то соотв. L3 и остальные функции мне доступны, прошивка NXOS: version 9.3(11) На самом коммутаторе поднято 12 BGP-сессий с IX(точками обмена трафика), с каждой сессии получаю около 110-130к маршрутов. Коммутатор переведен в режим Configured System Routing Mode: Internet Peering, увеличена память в vdc resource как указано здесь - https://layer77.net/2019/11/20/upping-the-ipv4-unicast-route-limit-on-a-nexus-93180yc-ex/ sh vdc n9k-C93180YC-EX resource Resource Min Max Used Unused Avail -------- --- --- ---- ------ ----- vlan 16 4094 890 0 3204 vrf 2 4096 2 0 4094 port-channel 0 511 4 0 507 u4route-mem 512 512 27 485 485 u6route-mem 96 96 1 95 95 m4route-mem 58 58 1 57 57 m6route-mem 8 8 1 7 7 В общем сейчас на коммутаторе маршрутов - show system internal forwarding route summary slot 1 ======= IP routes summary Max host route entries : 1039360 Total number of IPv4 host routes used: 2101 Max LPM table entries : 1006592 Total number of IPv4 LPM routes used: 134577 IPv4 unicast route table space available То есть суммарно сейчас 134577 маршрутов используется из возможных 1006592 которое допускается на этом оборудование. Но дело в том, что последние дни в логах спамит куча разных маршутов, вот пару примеров. IPFIB-SLOT1-2-UFIB_ROUTE_CREATE: Unicast route create failed for INS unit 0, VRF: 1, 185.239.244.0/24, flags:0x0, intf:0x10047c, Error: Hw Trie full(201) %IPFIB-SLOT1-2-UFIB_ROUTE_CREATE: Unicast route create failed for INS unit 0, VRF: 1, 103.147.116.0/24, flags:0x0, intf:0x100301, Error: FIB TCAM FULL For IP Routes( 235) при вводе команды sh hardware internal forwarding table utilization заметил: IPv4/IPv6 hosts and routes summary on module : 1 -------------------------------------------------- Configured System Routing Mode: Internet Peering Trie mode : True Dynamic V6 Trie : True -------------------------------------------------- Max IPv4 Trie route entries: 1000448 Max IPv6 Trie route entries: 500224 Max TCAM table entries : 16384 Max V4 Ucast DA TCAM table entries : 6144 Max V6 Ucast DA TCAM table entries : 2048 Max native host route entries (shared v4/v6) : 32768 Max ARP entries: 32768 Max ND entries (Entries might overflow into tcam as Host-As-Route): 16384 Total number of IPv4 host trie routes used : 0 Total number of IPv4 host tcam routes used : 2 Total number of IPv4 LPM trie routes used : 130824 Total number of IPv4 LPM tcam routes used : 6120 Total number of IPv6 host trie routes used : 0 Total number of IPv6 host tcam routes used: 0 Total number of IPv6 LPM trie routes used : 0 Total number of IPv6 LPM tcam routes used : 2 Total number of IPv4 host native routes used in native tiles : 2096 Total number of IPv6 host native routes used in native tiles : 0 Total number of IPv6 ND/local routes used in native tiles : 0 Total number of IPv6 host /128 learnt routes used in native tiles : 0 IPv4 Host-as-Route count : 2 IPv6 Host-as-Route count : 0 Nexthop count : 2081 Percentage utilization of IPv4 native host routes : 6.39 Percentage utilization of IPv6 native host routes : 0.00 Percentage utilization of IPv6 ND/local routes : 0.00 Percentage utilization of IPv6 host /128 learnt routes : 0.00 Percentage utilization of IPv4 trie routes : 13.07 Percentage utilization of IPv6 trie routes : 0.00 Percentage utilization of IPv4 TCAM routes : 99.6 Percentage utilization of IPv6 TCAM routes : 0.09 Percentage utilization of nexthop entries : 6.35 То есть Total number of IPv4 LPM tcam routes used : 6120 почти достигает Max V4 Ucast DA TCAM table entries : 6144 и показывает Percentage utilization of IPv4 TCAM routes : 99.6 После перезапуска пару сессий с IX, то значение падает до Total number of IPv4 LPM tcam routes used : 3881 вместо 6120 либо ниже и нагрузка становится Percentage utilization of IPv4 TCAM routes : 63.23 , но через день снова возвращается к значениям 6120 и 99.6% За более 60 дней все работало нормально, но последние 2-3 дня наблюдается такая аномалия. Может ли кто объяснить, что такое Total number of IPv4 LPM tcam routes used и Max V4 Ucast DA TCAM table entries , как понимаю то, что используется 134577 маршрутов из 1006592 не связано с этим, так как это Total number of IPv4 LPM trie routes used и куда копать дальше. При это оборудование не перезагружается, общее состояние системы не перегружено и маршруты которые он спамит в логах доступны если ввести команду show forwarding ipv4 route и подсеть.