[zebra 22872] Re: Help for zebra ospf management vi snmp.
Czanik József <[email protected]>
| Newsgroups | gmane.network.zebra |
|---|---|
| Message-ID | <[email protected]> |
Dear Yasuhiro Ohara, Your patch worked well. I used your patch for zebra-0.95. Now the patched zebra is running well under the following OS FreeBSD, Red-Hat Linux, Solaris 8 and Solaris 9. The Network management software now can realize all OSPF Object IDs via SNMP. All Object IDs are answering well. Thank you very much for you and for David Nisbet for his help to solve this problem. I got just problem under Solaris 8. When I try to login to configure the zebra or the ospfd via telnet they are crashing. After when I wrote in the password they are crashed. But only under Solaris 8 the cli did not work. If I am writing the config files manually there are no problem. It is possible to start and stop and query them via SNMP. Best regards, 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: [email protected] ----------------------------------------------------------------------------------------------- -----Original Message----- From: Yasuhiro Ohara [mailto:[email protected]] Sent: Friday, May 19, 2006 9:03 PM To: Czanik József Cc: [email protected] Subject: Re: [zebra 22856] 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. > ******************************************************************************* > -------------------------------------------------------------------------------------------- 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.)