There is presently only one Open Source management
system, that supports IPv6 and SNMPv3. That is Argus.
I like jffnms better ;-), there should be more tools.
From browsing the code:
jffnms has the advantage of being written in PHP so IP
adresses are, as far as I can see, passed as Strings,
leaving all validation to the underlying tools provided by net-
snmp.
To support IPv6, net-snmp needs an adress prefix
indicating the transport protocol "udp6 or tcp6", which
probably could be passed as part of the node "address".
Problems arise from features such as node discovery -
nmap barely support IPv6 and it will take a long time to
brute-force-scan an entire /64 subnet (mine has about 3
nodes on it!).
Instead, one probably must walk
the "inetCidrForwardingTable", probing all the "nexthops" for
more nodes/networks and pruning redundancies.
So, "First Level" IPv6 support - where User supplies Node
adresses/hostnames is relatively easy (I think); Full support
is harder because literally all netwok probes, NMAP,
SATAN, SARA do not support IPv6 beyond "Ping6".
Anonymous
Logged In: YES
user_id=450146
So, the only thing that is not working is Network Discovery?
can you poll a host that you added manually?
Logged In: YES
user_id=497128
No, Nothing works in IPv6 except the jffnms application itself -
come to think of it, "Application Polling" should have
worked though, hostnames are the same in IPv4 & IPv6
(Hmm - maybe I need to check that the names are resolved).
One cannot poll manually added hosts at all - I assume the
reason is that it is necessary to specify a Transport protocol
to the net-snmp tools that provide the SNMP support.
I am still looking in the code for the exact place
where "snmpget"/"snmpwalk" is hit - then I was planning to
work backwards to where the parameters is retrieved from
and find out how to add a few more.
Some further issues/rants are:
SNMPv3 with net-snmp tools needs a flurry of interrelated
parameters - effectively three, four different comandlines
depending on settings to work.
Engine-ID's must be registered in nodes (snmpd.conf) and in
the manager (node registry) i.e. managed, to gurantee that
Authentication will keep working (some bug/feature in snmpd
5.2.1 will on some condition reset the default engine ID,
loosing acess to all the SNMPv3 users. No, I haven't worked
it out yet).
In general: NEVER rely on defaults with net-snmp, specify,
specify, specify. If you do not, It WILL bide it's time, then turn
on you & bite your bottom. In spite of all that, net-snmp is
still one of the best tools there is. Used Properly.
Logged In: YES
user_id=497128
Nothing works with IPv6. One can add/delete
nodes/networks/customers and that is about that.
If an IPv6 host is added manually, the address is truncated.
hostnames will not work - and they are truncated too.
If ip6 localhost, ::1, is used as "workaround", the node will
not be polled anyway (not even known services, and not
SNMP which requires special parameters - as already
explained)
Hello,
Thanks for the ipv6 analysis. You're correct that JFFNMS code itself would have minimal problems handling IPv6 and most of the problems we would have with it would come from the underlying programs we use. Getting JFFNMS to understand IPv6 is something I will do one day, I have converted other programs I looked after so they are IPv6-aware, but it won't be one of the first things.
The next version of JFFNMS will have basic IPv6 support. The reachability and TCP/UDP port pollers will handle IPv6.
Most of the SNMP based pollers will not work with IPv6. This is purely because of a limitation of the SNMP PHP code. The underlying SNMP libraries are able to handle IPv6, it is just the small shim of PHP layer between those libraries and the application.
I agree about the network discovery. It's reasonably bad way to discover hosts using nmap, even for IPv4.