librenms is a great tool, the best I think.
Just would like to suggest to add two things.
netflow visualization using nfcapd daemon, similar than nfsen.
Nfsen is great but it is not well maintanied , same happen with smokeping.
Both tools are mandatory in networking monitoring, it would be great to have them natively supported on librenms.
For whatever it’s worth, if you haven’t yet looked at ElastiFlow…I find it to be probably the best and free netflow/sflow visualizing tool. It would be really cool if it was easy to integrate it with LibreNMS. Despite having several years of web development under my belt (with MS mainly) and a little bit of an aptitude for programming – I wouldn’t know where to start with php and everything else. =(
Anything that ingests flows is going to eat up disk space…that’s a given. I didn’t really find that Elastiflow was really resource heavy vs. nfsen…it probably is but nowadays with virtual servers etc. I don’t think it’s as much of an issue as it was years ago where we’d have to dedicate a physical server to a service.
Disk space I’m not so worried about, though elasticsearch itself eats a lot of iops. But still, I might test it, working with nfsen was just horrible
One would also have to think what to integrate between libre and whichever flow monitor. Direct graphs or autoconfig via api from libre to said system for example? What do you have in mind?
Have you ever worked with nfsen ?
Can you point some differences ?
What about install process ? is this very hard ?
Can I host this on my proxmox ? the Elastik stak enviroment is free ?
Nfsen interface is not so cool , but installation is easy and platform provides everything I need.
I think diagnosing any problem or even planning for the future involves the questions of “who, what, when, where and how.” Often times figuring all of this out means hopping between different monitoring or management servers to gain an understanding of what is happening on the network.
Suppose I’m looking at network weathermap and I see a spike in network utilization between two switches. Next I would click down to see what ports are being used. Next I want to know what the end points are on those ports as well as what the actual traffic is.
If you indeed monitor a lot of routed ports it would be handy. But in layer 2 side you won’t be able to do that anyway so depends on the use case a lot. But I don’t think you can get very easily a “seamless” integration between the systems. So most likely the integration would be between API calls or having a (possibly authenticated) shortcut to a flow graph when looking at a device.
yeah I use sflow. Our network used to be three buildings and three routers (one per building) and obviously vlans can’t traverse routers. We ended up ditching the cisco routers and run L3 switching between the buildings and we export sflow. With elastiflow we can get some really good data but the machine ends up screwing up on us at some point or another and we haven’t figured out why…a couple of linux beginners here.
Sounds like a nice setup. You just doing static routing or using something like bgp or ospf? If you need some linux hints you can pop to the librenms discord chat, even though not directly related, I can try to help of course.
It’s fairly simple here. The previous admin had 3 routers running OSPF and it was way more complicated than it needed to be because on the Cisco routers with the switch module, there was this weird transform between L2 and L3 for the service-module to work. Way more complicated than it needed to be considering he used 3 class B networks in the 10.X space, one for each building…well actually 6 class B spaces if you count the VOIP phones…yes 2 class B’s per building with only 300 employees total.
So yeah it’s static out the door now. All of the L3 stuff happens at the datacenter. It’s L2 between the buildings back to the datacenter over 10GB fiber where our internet ingress / egress is…so if we lose connectivity between buildings, everything stops anyhow…no need on making it anymore complicated because work is just going to stop.