For this, I used IPFIX - Netflow is the original protocol invented by Cisco, and IPFIX is the evolved and more standardised IETF version. Which means you can just write a kernal module and get it to do whatever you like! Usefully, someone has written an iptables module that can output netflow & IPFIX traffic. IPTables is both awesome, and extensible. This thing is basically a combination of using an iptables module to output netflow/ipfix flows to Logstash, which can then pipe them into Elasticsearch. This led me down a path to try and find something better. However, after a while, it became apparent that while the functionality was good, the stability was less so. Some time after that, I came across ntopng which seemed to effectively answer the question of “What flows are going where?”. This is how I ended up with a small x86 box running Debian 8 as my home router. Having previously run OpenWRT, pfSense and a few others, I decided a while back that running a linux box would provide some pretty effective capabilities (ppp, VLANs etc) while also having a proper grown up OS and package ecosystem to play with. I’ve been running my own build router at home for a while now. Thanks.Fun with netflow / IPFIX and Elasticsearch 26 November 2016 I've set a sFlow instance pointing at my manager node for the receiver and set the sampling and polling to the standards for a 1 Gbps port.Īny other thoughts on what I might be missing here? All assistance is very much appreciated. There really isn't much to the switch-side configuration. However, I have configured them to use the standard netflow port udp/2055 instead of the default sFlow port of udp/6343. Technically speaking, it is sFlow, not netflow that I'm sending from my switches. I am still not seeing "netflow" packets from my switches though. I do receive netflow packets from nflow-generator and can view them as part of the netflow.log dataset in Kibana. I've also set up an instance of the nflow-generator application and tested netflow ingestion using it. I have run so-filebeat-module-setup again and it does list netflow as one of the modules. It took a little bit, but I was finally able to get back to troubleshooting this issue. If all that looks good, try sending traffic to 2055/UDP using a Netflow generator (something like ) to confirm that the issue isn't something on the sending/formatting side. If you run "sudo so-filebeat-module-setup", does it list the netflow module in the output as its setting up the ingest pipelines? If that's all clear, then the traffic should be able to come from your devices to the filebeat module. Does "sudo iptables -L | grep 2055" show the firewall hole to let the traffic into the local host and Docker environment?.Does "sudo docker ps | grep 2055" show the so-filebeat container accepting connections on that port?.Does "sudo so-firewall listports netflow udp" return 2055?.Does "sudo so-firewall includedhosts netflow" show the IPs or subnets that you are expecting traffic from?.Thanks.īeta Was this translation helpful? Give feedback.Īs noted in that other discussion post that you linked, you should need to manually enable the fileset on a newer version of SO, like the one that you're running. (Aruba defaults to port udp/6343 for sFlow, but it has been configured to use udp/2055).Īny assistance is very much appreciated. There are devices on the allowed networks that are configured to send sFlow traffic to the Manager node on udp/2055. I can provide other information if necessary. Var.key: '/usr/share/filebeat/keynamehere2.key' Var.certificate: '/usr/share/filebeat/keynamehere.pem'
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |