headers
Morten Brekkevold | 15 Oct 2009 11:00
Picon
Picon
Gravatar

Re: EdgeCore ES4612 no port info

Kostua <kostua@...> wrote:

>> Do you mean to say that each port's traffic graph is blank, or that
>> Cricket does not even list the switch ports?
>>   
> traffic graph is blank

Are you receiving any error messages in your Cron Daemon email from
Cricket?  What do your cricket logs show?  

You say the traffic graph is blank for all ports, but what are the
values listed in the summary field above the graph?  Are they zero
values, or are they NaN, i.e. no data has been collected?

--

-- 
mvh
Morten Brekkevold
UNINETT
Permalink | Reply | 0 comments |
headers
Morten Brekkevold | 15 Oct 2009 11:14
Picon
Picon
Gravatar

Re: VS: Radius service monitor

On Fri, 02 Oct 2009 12:12:41 +0200 "Istvan Bernath" <ibe@...> wrote:

> Sorry about the inconvenience!
>
> I've been on the sidelines in the past 3 years, receiving all
> messages from the nav-users list and running a maintained and
> updated test installation all that time.
>
> To my pleasure this time it will be official, and the Faculty of
> Life Sciences, Copenhagen University gives NAV a chance as the
> global monitoring tool of all the new HP 2510 switches our net is
> now upgraded to.  

Music to my ears.  Although I'm curious as to how NAV will perform on
an all HP network.  We've had some problems with HP in the past.  Not
all of them are completely behind us, but they hopefully will be in
NAV 3.6.

> Monitoring of several services will also be crucial.

NAV's service monitoring capabilities have been somewhat downplayed by
UNINETT, due to lack of resources.  We've left maintenance of those
systems in the capable hands of the University of Tromsø.  Hopefully,
their developers can answer your questions, as I don't know radius or
the service monitor all that well.  I've prodded one of their guys to
look at your servicemon question.

> I have though problems with monitoring the Radius service, and booth
> topology and MAC behind a port do not work with the new HP ProCurve
> switches.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Istvan Bernath | 15 Oct 2009 13:06
Picon
Favicon

Re: VS: Radius service monitor

Thanks for the kind reply!

Right now all our active switches are registered in NAV. There are about
130 pcs. 2510-48 and a couple of 2600-8, 2610, 2626, 2650, 2810 and 2824.
The core switches are two 5406 and a single 5412.
Traffic data is collected from the switches correctly. Statistics are presented
fine via Cricket.
Alerts, like firmware upgrade and cold start, are all noticed via Alert Manager
as it should.

Topology right now is totally missing, but luckily I've cached a hint of topology
with a single 2824 in the middle and one 2626 one 2650 and a 2510 as the
neighbors before my colleague, sorry to say, have updated to the latest firmware.
The magic surely was, that the 2824 had a complete CDP and LLDP implementation
in the old firmware, while all the new HP firmware has only a crippled Receive Only
CDP implementation.
The missing topology is rather crucial since we can be flooded by SMS and mails
in case a box at the top fails.

MAC information is collected, so it is possible to find a MAC number belonging to an
IP number, but the MAC is not associated to any switch port, so we can not trace
MAC, and use Arnold.

Service monitoring is rather important for us, since our server people do need
a better identification of a functioning server than a simple ping. Needless to say
that a process can fail while the server still is pingable.
Right now we are monitoring DNS, HTTP, IMAP, SMB, SMTP with success.
The only service we are missing, for the time beeing, is the RADIUS.

If I can help the developers with any tests, I would be more than happy to do it!
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ingeborg Hellemo | 15 Oct 2009 14:59
Picon
Picon
Favicon

Re: VS: Radius service monitor


ibe@... said:
> Right now we are monitoring DNS, HTTP, IMAP, SMB, SMTP with success. The only
> service we are missing, for the time beeing, is the RADIUS. 

Perhaps you are missing a couple of (undocumented?) dependencies? The Radius 
service monitor depends on 'freeradius' and 'pyrad'. Our experience is also 
that /usr/local/etc/raddb/ must be readable for all (default on FreeBSD is 700)

--Ingeborg
--

-- 
Ingeborg Østrem Hellemo  --  ingeborg.hellemo@...
Dep. of Information Technology  ---  Univ. of Tromsø
Permalink | Reply | 0 comments |
headers
Morten Brekkevold | 16 Oct 2009 09:58
Picon
Picon
Gravatar

Re: VS: Radius service monitor

On Thu, 15 Oct 2009 13:06:20 +0200 "Istvan Bernath" <ibe@...> wrote:

> Topology right now is totally missing, but luckily I've cached a hint of topology
> with a single 2824 in the middle and one 2626 one 2650 and a 2510 as the
> neighbors before my colleague, sorry to say, have updated to the latest firmware.
> The magic surely was, that the 2824 had a complete CDP and LLDP implementation
> in the old firmware, while all the new HP firmware has only a crippled Receive Only
> CDP implementation.

The switches' forwarding tables are collected by the getBoksMacs
program (nav start mactrace).  Do you see any error messages in your
getBoksMacs.log file?  It might also help to make sure that
getBoksMacs is logging at debug level (level 6, see nav.conf).

NAV builds a table of neighbor candidates.  It would be nice to know
some statistics from this table.  Could you access the PostgreSQL
database (sudo -u postgres psql nav) and show the output of the
following queries:

  SELECT COUNT(*) FROM swp_netbox;
  SELECT COUNT(DISTINCT netboxid) FROM swp_netbox;

> Right now we are monitoring DNS, HTTP, IMAP, SMB, SMTP with success.
> The only service we are missing, for the time beeing, is the RADIUS.

Thinking about it now, I remember discovering a while back that there
are some complicated issues surrounding the RADIUS service checker.

I remember discussing this with the original author of the service
checker plugin.  He also happens to be the Debian maintainer for the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ingeborg Hellemo | 21 Oct 2009 11:49
Picon
Picon
Favicon

FYI: FreeBSD and XMPP

In case someone wants to configure XMPP on FreeBSD the correct python-library 
to install is net-im/py-xmpppy (not net-im/py-pyxmpp...)

--Ingeborg
--

-- 
Ingeborg Østrem Hellemo  --  ingeborg.hellemo@...
Dep. of Information Technology  ---  Univ. of Tromsø
Permalink | Reply | 0 comments |

Gmane