On Tue, Jul 7, 2009 at 12:23 PM, Fikru Getachew <fikr...@yahoo.com> wrote:
>
> Dear all, first of all thank you for your cooperation!
> Presently I am working on multi-stage router management plane implemented
> in Linux. To describe the architecture in simple words: Multi-stage router
> - multiple Linux based PCs connected to a switch but act as single router.
> We are using this architecture to enhance the capacity of a single PC
based
> router architecture.
> One of those PCs act as a representative of the whole PCs in the
> architecture to respond to SNMP request.
> My question is:
> - How can I make this PC to receive the request from the manager, analyze
> the request, forward it to the other PCs in the Multi-stage router,
collect
> information from them, compute the information (may be averaging, .... ),
> and then give back a single common data to the manager?
> (Clarification: Why to send it as a single common information? -- well,
> the multi-stage router, even though it has multiple PCs, it acts as a
> single router for the external devices. For example, the manager want
> to know the Uptime of this router. Which PC's Uptime the representative
> PC should send to the manager? I want to take the average of the Uptime
> of each PCs in the multistage router and send that back to the manager.
> That means, I have to delay the response to the manager, collect Uptime
> information from all the PCs in the multistage router, average it and then
> respond to the manager with the average value). How can I do that?
>

Visions of Deja vu...

This sounds almost exactly like the needs of a project I did a few years
ago.

In my case, we had a rack of chassis, each full of (proprietary) router
cards
and a (number of redundant) management processor(s).  Although each router
was
individually addressable and accessible via SNMP, our customer wanted a
'unified view' of that collection of devices.  Ie.  Only _one_ config table,
_one_ set of protocol tables, _one_ set of statistics, ONE interface table.
You get the idea.

So instead of 64 different 8 port devices, the set was mapped into a view
that presented one device with 512 ports.

So all queries to the 'virtual collection' of devices were sent to the
management processor, who in turn collected the required information from
the various component devices, it built a 'new view' of that information
and then handed it back out to the NMS as per its requests.

What this meant was that (for example) when the 'management' processor was
queried for the interface table, it in turn queried for the appropriate
mapped/proxied entry in the appropriate specific router's interface table.
Once it got the response, the management process would re-write the OID
(and sometimes the value as required) for the response that was returned to
the NMS.

So our problem decomposed into:

1/ how does the management processor 'know' what the component devices were
   and their addresses.
2/ What happens when those 'components' come and go (hint: route all traps
to the management system, and when it sees restarts and interface state
changes
it needs to re-query the appropriate component to rebuild its 'unified
view'.)
3/ Know how to map an incoming query to a component address and component
specific query.
4/ Query the component
5/ re-write the component's response to the 'unified view' (OID and value)
6/ send the response to the NMS

Things to consider:
Some things are indexed by interface number, others by arbitrary indexes,
other are singular per component and need to have index added for
unification,
other are multiply indexed with some or all of the indexing I just
described!

Also, since traps needed to 'grand unified' also, the same basic discovery
and
re-writing rules had to be followed to proxy those also.

So, how do you do it?
Simply, the action routines in the management processor 'know' how to:
obtain
index translation information, proxy/rewrite the requests and rewrite the
responses.

Needless to say, its a 'real pain in the ...' to get all the boundary and
operational
failure modes (when things come and go) taken care of.

Good luck.

Fulko
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to