[zebra 22861] Re: Help for zebra ospf management vi snmp.

Nisbet is correct, I checked the patch:
http://lists.quagga.net/pipermail/quagga-dev/2003-September/000253.html

and regenerate it for Zebra CVS HEAD (the patch is attached).
It includes only some part from Nisbet's,
namely fix for only "get" (e.g. not for metric set).

Would you try and let us know the result ?

regards,
yasu


From: "Nisbet, David " <[email protected]>
Subject: [zebra 22857] Re: Help for zebra ospf management vi snmp.
Date: Fri, 19 May 2006 11:08:47 +0100
Message-ID: <[email protected]>

> Czanik,
>  
> The SNMP interface to OSPF has been broken for some time and doesn't respond
> correctly to snmpwalk. 
> I posted a patch for quagga 0.96.2, the active fork of zebra, back in 2003
> however, as far as I know, it never got incorporated. I also produced a
> patch against quagga 0.96.4. I never tried to patch zebra, but the changes
> should be similar. I havn't looked at the software for some time.
>  
> The patch altered the behaviour of ospfIfLookup and ospfIfMetricLookup on
> receipt of an inexact OID from smux. This is the case when the MIB is
> walked using getnext. The change helped to ensure that interface tables in
> the MIB were traversed correctly.
> It also provided a write method for the interface metric and returned the
> currently set metric.
> Finally it enableed access to point-to-point interface data by using the
> (more conventional) local interface address value.
> 
> If you would like a copy of the 0.96.2 patch you can find it in the quagga
> mailing list archives. I think you would have to hack it a bit to get it to
> work with zebra and I would recommend quagga instead. I can also supply the
> 0.96.2 or 0.96.4 patches directly if you wish. You could also try the
> current quagga ( www.quagga.net <http://www.quagga.net> ) to see if SNMP
> works properly for these OIDs. If not I can probably modify the patch to
> suit.
>  
> Regards
>  
> David Nisbet
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Czanik József
> Sent: 19 May 2006 10:25
> To: [email protected]
> Subject: [zebra 22856] Help for zebra ospf management vi snmp.
> 
> 
> 
> Dear zebra users,
> 
> I would like get a little help from somebody.
> 
> I am using zebra 0.95 and NET-SNMP under solaris 9 OS.
> 
> I would like to manage the zebra ospf via SNMP.
> 
> But unfortunately when I am polling this host not all objects ID are
> answering.
> 
> I got answer from:              Object ID .1.3.6.1.2.1.14.1
> 
> 	Object ID .1.3.6.1.2.1.14.2
> 
> 	Object ID .1.3.6.1.2.1.14.4
> 
> 	Object ID .1.3.6.1.2.1.14.10
> 
> 	Object ID .1.3.6.1.2.1.14.12
> 
> But !!! Unfortunately I couldn't get answer from:
> 
> 	Object ID .1.3.6.1.2.1.14.7
> 
> 	Object ID .1.3.6.1.2.1.14.8
> 
> The SNMP software therefore said there is no ospf on this host.
> 
> Does anybody know how can I get these two containers from the zebra via
> SNMP?
> 
> The NET-SNMP configure command " ./configure -with-mib-modules=smux
> 
> The zebra configure command: ./configure -enable-snmp
> 
> Please help me! 
> 
> Thanks!
> 
> Jozsef
> 
> Jozsef CZANIK
> 
> Networkmanager
> 
> Budapest Stock Exchange
> 
> Budapest
> 
> Deak Ferenc u. 5.
> 
> 1052 Hungary
> 
> Phone: + 36 1 429 6774
> 
> Fax: + 36 1 328 0480
> 
> Mobile: +36 30 303 6774
> 
> e-mail:  <mailto:[email protected]> [email protected]
> 
> ----------------------------------------------------------------------------
> -------------------
> 
> 
> 
> 
> 
> 
> 
>   _____  
> 
> Ez az elektronikus levél bizalmas és/vagy jogilag védett információkat
> tartalmazhat, és kizárólag a címzettnek szól. Amennyiben ezt a levelet
> sérülten kapta meg vagy nem Ön annak valós címzettje kérjük, haladéktalanul
> tájékoztassa erről a feladót, és a levelet törölje rendszeréből. Az
> elektronikus levél engedély nélküli másolása, sokszorosítása, terjesztése,
> módosítása és nyilvánosságra hozatala szigorúan tiltott.
> 
> (Az elektronikus úton történő levelezés elsősorban információs célokat
> szolgál. A Budapesti Értéktőzsde Részvénytársaság nem tesz és nem fogad el
> hivatalos kötelezettségvállalásokat kizárólag elektronikus levél útján,
> hacsak erről ellentétes tartalmú megállapodás nem született a felek között.)
> 
>   _____  
> 
> This e-mail may contain confidential and/or copyrighted information and is
> intended solely for the person or organization to whom it is addressed. If
> you receive this e-mail in a damaged form or if you are not the intended
> recipient, please inform the sender immediately and delete the e-mail from
> your system. Unauthorised copying, distribution, modification, or disclosure
> of this e-mail is strictly forbidden.
> 
> (E-mails are primarily sent for informational purposes. The Budapest Stock
> Exchange Ltd. neither undertakes nor acknowledges any official obligations
> via e-mails, unless the parties have agreed otherwise.) 
> 
> 
> *******************************************************************************
> This email and any files transmitted with it are intended solely for the use of
> the individual or entity to whom they are addressed and may not be divulged to
> any third party without the express permission of the originator.  Any views
> expressed in this message are those of the individual sender, except where the
> sender specifically states them to be the views of Thales Research & Technology
> (UK) Limited.
> *******************************************************************************
>

_______________________________________________
Zebra mailing list
[email protected]
http://ml.zebra.org/mailman/listinfo/zebra

Index: ospfd/ospf_snmp.c
===================================================================
RCS file: /cvsroot/zebra/ospfd/ospf_snmp.c,v
retrieving revision 1.33
diff -u -r1.33 ospf_snmp.c
--- ospfd/ospf_snmp.c	24 Nov 2004 10:03:06 -0000	1.33
+++ ospfd/ospf_snmp.c	19 May 2006 18:45:56 -0000
@@ -1680,8 +1680,27 @@
     return NULL;
 
   oi = ospf_if_lookup_by_local_addr (ospf, ifp, ifaddr);
-  if (oi == NULL)
-    return NULL;
+
+  if (exact)
+    {
+      if (oi == NULL)
+        return NULL;
+    }
+  else
+    {
+      while (oi == NULL)
+        {
+          /* Skip to the next interface. This is because, by simply
+             just returning, libsnmp will not preserve the matched ifp's
+             ifaddr and ifindex, and so it leads to just failing
+             on a first interface for every variables */
+          ifp = ospfIfLookup (v, name, length, &ifaddr, &ifindex, exact);
+          if (ifp == NULL)
+            return NULL;
+
+          oi = ospf_if_lookup_by_local_addr (ospf, ifp, ifaddr);
+        }
+    }
 
   /* Return the current value of the variable */
   switch (v->magic) 
@@ -1853,8 +1872,27 @@
     return NULL;
 
   oi = ospf_if_lookup_by_local_addr (ospf, ifp, ifaddr);
-  if (oi == NULL)
-    return NULL;
+
+  if (exact)
+    {
+      if (oi == NULL)
+        return NULL;
+    }
+  else
+    {
+      while (oi == NULL)
+        {
+          /* Skip to the next interface. This is because, by simply
+             just returning, libsnmp will not preserve the matched ifp's
+             ifaddr and ifindex, and so it leads to just failing
+             on a first interface for every variables */
+          ifp = ospfIfMetricLookup (v, name, length, &ifaddr, &ifindex, exact);
+          if (ifp == NULL)
+            return NULL;
+
+          oi = ospf_if_lookup_by_local_addr (ospf, ifp, ifaddr);
+        }
+    }
 
   /* Return the current value of the variable */
   switch (v->magic)