Is possible monitor the source of the network from a device?

[tgriep]

Try running the fprobe command and then run the following to see what the error message is.

Code: Select all

grep fprobe /var/log/messages

Sorry about the confusion, Netflow is the protocol used to send the data.
I am wondering if you can change the settings on the Windows host to use version 5 of the protocol?

[xerez]

So you are not receiving anything still with the tcpdump? Are you sure there's not something in the middle blocking it?

No, I NNA doesn't receive data and I'm sure that in the middle is nothing.

Try running the fprobe command and then run the following to see what the error message is.

Code: Select all

grep fprobe /var/log/messages

Sorry about the confusion, Netflow is the protocol used to send the data.
I am wondering if you can change the settings on the Windows host to use version 5 of the protocol?

Ok, don't worry about the confusion, but I think Windows machine works fine and the problem is with I pause and resume NNA each time, because the date isn't update.

About fprobe command, I have tried even with different versions (1, 5 and 7):

Code: Select all

[root@linux sbin]#  grep fprobe /var/log/messages
Nov  9 16:40:14 linux fprobe[17059]: [INFO]: collector #1: 192.168.10.99:2001/0.0.0.0/m
Nov  9 16:41:48 linux fprobe[17059]: [INFO]: SIGTERM received. Emitting flows cache...
Nov  9 16:41:48 linux fprobe[17059]: [INFO]: Done.
Nov  9 16:41:56 linux fprobe[17519]: [WARNING]: Filter expression is empty! Are you sure?
Nov  9 16:41:56 linux fprobe[17519]: [INFO]: Starting 1.1...
Nov  9 16:41:56 linux fprobe[17519]: [INFO]: pid: 17519
Nov  9 16:41:56 linux fprobe[17519]: [INFO]: interface: nflog, datalink: UNKNOWN (239)
Nov  9 16:41:56 linux fprobe[17519]: [INFO]: filter: ""
Nov  9 16:41:56 linux fprobe[17519]: [INFO]: options: p=1 s=5 g=30 d=60 e=300 n=1 a=0.0.0.0 x=0:0 b=10000 m=0 q=100 B=0 r=0 t=0:0 S=256 K=18 k=0 c= u= v=6 l=1
Nov  9 16:41:56 linux fprobe[17519]: [INFO]: collector #1: 192.168.10.99:2001/0.0.0.0/m

[jolson]

At this point I'm a little lost. I would like to clear a few things up.

1. How many sources did you set up in Nagios Network Analyzer? You should be setting up one source per device (1 for Windows and 1 for Linux).

2. Are either of your hosts working at this point? It sounds like your Windows host is working occasionally and your Linux host is not working at all. Is that still correct?

3. When you are logged into your Linux machine, are you running commands as root user, or as a different user?

NNA is not meant to be paused and resumed - keep it running if at all possible. Pausing and resuming the device can be problematic in many ways, but especially because of dates and the way that services use dates.

[xerez]

At this point I'm a little lost. I would like to clear a few things up.

1. How many sources did you set up in Nagios Network Analyzer? You should be setting up one source per device (1 for Windows and 1 for Linux).

2. Are either of your hosts working at this point? It sounds like your Windows host is working occasionally and your Linux host is not working at all. Is that still correct?

3. When you are logged into your Linux machine, are you running commands as root user, or as a different user?

NNA is not meant to be paused and resumed - keep it running if at all possible. Pausing and resuming the device can be problematic in many ways, but especially because of dates and the way that services use dates.

1. I have two sources, one for Windows and one for Linux.

2. Sorry, Linux machine is working 24x7. Windows machine is working from about 8:30 to 18:00 (my work hours), and NNA is working as a VM in my Windows machine. When I leave, I turn off my Windows machine and therefore NNA.

3. Root.

[eloyd]

2. Sorry, Linux machine is working 24x7. Windows machine is working from about 8:30 to 18:00 (my work hours), and NNA is working as a VM in my Windows machine. When I leave, I turn off my Windows machine and therefore NNA.

This may be part of your problem. NNA is designed to be up and running all the time and the NetFlow agents (fprobe and your Windows service) may get confused when the NetFlow collector (NNA) is not available for hours.

However, this explains your problem. The Linux machine works fine because it just drops packets that it can't send when trying to send to NNA while the Windows host is down. The Windows machine may not work properly because the timing between when the agent starts and when the guest NNA server starts may cause the Windows service to be unable to initialize until after NNA has started. That means it isn't doing anything until you restart the NetFlow sender after NNA starts.

I hope that makes sense.

The bottom line: If at all possible, try running NNA on a box that isn't going to be power cycled every day.

[rkennedy]

Thanks for contributing @eloyd! Does that provide clarification for you @xerez?

[xerez]

Ok, I will try to test NNA in a machine always on. Thanks.

[rkennedy]

Sounds good. I will leave this thread open for now - be sure to let us know how it works for you on a machine running 24/7.