Subject: Re: OSPF MIB support for multiple OSPF processes

From: Tom Petch <[email-masked]>
Date: Mon, 20 Jan 2003 18:15:38 -0000

Yes.
In SNMPv1, this can be done by having multiple 'agents' identified by
different community names or different IP addresses, each accessing a
distinct incarnation of MIB II and its subordinate branches.
In SNMPv3, there is a more sophisticated mechanism of contexts which
formalises the techniques given above.
I do not think you should ever return more than one instance of a
given object in GET or GETNEXT.

Tom Petch
[email-masked]

-----Original Message-----
From: Roy Jose <[email-masked]>
To: [email-masked] <[email-masked]>
Date: 20 January 2003 16:04
Subject: OSPF MIB support for multiple OSPF processes

>Hi,
>
>Rfc1850 doesn't talk about what to be done regarding the
retrieval(GET) of
>MIB values when multiple OSPF processes exist on a router. Out first
>impression is to return details about all the processes. The problem
is
>while selecting values for MIB objects like
>ospfRouterId,ospfAreaBdrRtrStatus, ospfASBdrRtrStatus etc. They may
differ
>in separate processes. The Qn is, can we really support multiple
processes
>with rfc1850?
>Thanks,
>Roy

---

From: Roy Jose <[email-masked]>
Date: Tue, 21 Jan 2003 15:15:01 +0530

Hi Tom,

Thanks.

> distinct incarnation of MIB II and its subordinate branches.

Say OSPF process 2 is mapped to a MIB view V1. How does the NMS know the
details it collects through SNMP GET/GETNEXT are meant for process 2?

I doubt if this MIB view concept is based on MIB object id's, meaning we may
not be able to have separate MIB views for each OSPF processes since we
can't map them to any object id's.

Thanks,
Roy

---

From: Acee Lindem <[email-masked]>
Date: Tue, 21 Jan 2003 10:00:55 -0500

Roy, Tom,

Using a separate community per instance works quite naturally if
you have a virtual router model where each virtual router has
its own SNMP configuration, RIB, and routing protocol instances. Our
product uses this technique. However, within a virtual router (we call
them contexts) one still has the problem when multiple routing protocol
instances and RIBs are supported. The problem isn't unique to OSPF so
I don't think an OSPFv2 specific solution is appropriate. I don't think
making everything a table and adding instance ID as a table index is
desirable.

--
Acee

---

From: Roy Jose <[email-masked]>
Date: Tue, 21 Jan 2003 22:38:04 +0530

Hi Acee,

> making everything a table and adding instance ID as a table index is

I am not able to think any other solution than going for this table option.
I think adding an extra index to an existing table won't be a big issue.
Only major change I can fprsee is the conversion of ospfGeneralGroup to a
table.

Thanks,
Roy