...
| Code Block |
|---|
service nfdump stop dpkg-divert --rename --divert /lib/systemd/system/nfdump.service.disabled --add /lib/systemd/system/nfdump.service rm -f /etc/systemd/system/nfdump.service /etc/systemd/system/multi-user.target.wants/nfdump.service systemctl daemon-reload # note that this will only work fully if you use the nfdump init script from /usr/local/omk/install/nfdump.init.d! service nfdump start |
opCommon
The following changes can be made in the opCommon config file /usr/local/omk/conf/opCommon.nmis
...
Linking with opCharts/NMIS can be done to an NMIS instance on the same server (Local) or can integrate to a remote instance of opCharts. The server (local or remote) If you are running opCharts3 as the remote it must not be a master instance it must be a normal poller instance. If you are running opCharts4 the remote server can be a poller or a master.
If you are linking to a local omkd do not use a remote connection.
...
Remote integration requires settting setting 3 config items, these are used so the opFlow server can access an opCharts server. When this is working the GUI will show ifDescr and Descriptions in the agent selector, and when filtering on an agent/interface will display the interface info panel.
...
| Code Block |
|---|
cat /etc/resolv.conf # verify the listed nameservers and search order works, # using dig, nslookup or host |
...
If you have very large numbers of distinct IP addresses in your flows you should DISABLE DNS lookup, change 'opflow_resolve_endpoint_dns' => 'true', to false in /usr/local/omk/conf/opCommon.nmis to speed up performance. Each of the opflow processes will have to wait for each of the DNS lookups which means you will have a large number processes waiting for DNS to return information. This is especially true on internet traffic as resolution will require a PTR lookup through to the SOA for that IP which could take a while.