RFC L2 (switch) topology. Mainly off-topic.
Subhendu Ghosh
sghosh at sghosh.org
Wed Apr 7 16:17:08 CEST 2004
Hi Stanley
I'm interested...
-sg
On Fri, 5 Mar 2004, Stanley Hopcroft wrote:
> Dear Ladies and Gentlemen,
>
> <this is at most marginally on topic>
>
> I am writing to ask if there is any interest in using layer two
> topological information with Nagios.
>
> Potential uses include (that I will not probably not contribute to)
>
> . custom status maps that show the bridge/switch layout with respect to
> the spanning tree, which in many cases is the inter switch path viewed
> from the point of the root bridge.
>
> This is perhaps less useful than it may seem because the status map
> would ideally show the relationship of the hosts to the switches and
> while this is doable, it is slow with more than a small number of
> switches (say less than 10).
>
> . custom checks that analyse the spanning tree (and whine if the
> favourite/most powerful/least powerful/XP in bridge mode/some stray
> wireless node bridge is not or is the root bridge.
>
> What you would get ?
>
> 1 Net::SNMP (an absolute joy of a Perl module) pollers that ascertain
>
> - bridge MAC addresses (for relating to name and or IP)
> - descendant bridges
> - the switch 'designated bridge'
> - nodes in a netblock that are switches (ie respond to the
> dot1dBaseType with a value of 'transparent')
>
> 2 A Perl CGI that displays them (primitively) in a tree form with the
> root at the top
>
> This is the only application I have at the moment, although in
> principle, generating a dot map and having graphviz generate a .png for
> a better looking web display 'shouldn't be too hard' (TM).
>
> Switch topology.
>
> SCBR21-C5K-2
> DBR21-C5K-1
> DNGR21-C29-10
> DNGR22-C28-11
> DN1R21-C29-20
> DN1R22-C28-21
> DN1R23-C28-22
> DN1R24-C28-23
> DNR21-C29-30
> DN2R23-C28-32
> DN2R24-C28-33
> DN2R22-C28-31
> DN3R21-C29-40
> DN3R22-C28-41
> DN3R23-C28-42
> DN3R24-C29-43
> DN4R21-C29-50
> DN4R22-C28-51
> DN4R23-C28-52
> .. snip ..
>
> SC1R41-C29-65
> SC1R42-C28-66
> SC1R43-C28-67
> SC1R44-C28-68
> SC1R45-C28-69
> SC1R46-C29-162
>
> What about the bad bits ?
>
> 1 The pollers don't reliably discover switches since
>
> 1.1 agents don't respond if they have better things to do
>
> 1.2 the switch discovery wants to be fast; I haven't bothered to retry
> the requests; maybe I should.
>
> 2 The code is not suitable for publication ie supportable or without
> known showstoppers (how can you have showstoppers in 300 lines of Perl ?
> well, I can).
>
> In fact, there may even be conceptual flaws also.
>
> 3 It almost certainly doesn't scale.
>
> At the moment the switch discovery and polling of ~ 80 switches in a /24
> takes less than 5 seconds - without connectivy or utilisation problems.
>
> wins> /home/anwsmh/perl5/dotime 5 ./update_switch_topology
> Running ./update_switch_topology 5 times
> 1 2 3 4 5 done
> Avg 1 2 3 4 5
> ------ ------ ------ ------ ------ ------
> real 3.730 3.52 4.17 3.69 3.51 3.76
> user 1.120 1.19 1.18 1.08 1.08 1.07
> sys 0.062 0.07 0.07 0.07 0.04 0.06
> wins>
>
>
> Please would you let me know if there is any interest or that
>
> - this is stupid; L2 sucks (sure does)
>
> - we already use big name product foo to do this and foo is great
>
> - why would you want to do this
>
> - we need it done for big_number k switches across n netblocks
>
> - does it work for Cisco rapid spanning tree (probably not).
>
>
> </this is at most marginally on topic>
>
> Yours sincerely.
>
>
--
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue.
::: Messages without supporting info will risk being sent to /dev/null
More information about the Users
mailing list