Re: Concatenating MIBs over multiple contexts

Fedor Sumkin <[email protected]>
Newsgroups gmane.network.net-snmp.user
Message-ID <CAEoYLjP=+9HtAi1J2YsCc+X9j+7Q2JLYPpibTj6-86X0xKM4Hw@mail.gmail.com>
Hi Antonio,

Probably this issue may be related to the usage of the root oids with
length of two(.1.3 and .1.4).

Can you please check if proxying works on oids with length>2?

Regards,
Fedor

On Thu, Aug 20, 2015 at 3:30 PM, Antonio Piepoli (apiepoli) <
[email protected]> wrote:

> Hello everybody,
>
>
>
> sorry for the double mail; maybe I have provided too much background and
> not enough info about the problem that I am facing.
>
>
>
> Assuming this:
>
>
>
> pass_persist .1.3.6.1.3.54 /home/ciscolab/test.py
>
>
>
> proxy -Cn ctx -v 2c -c public  localhost .1.4 .1.3.6.1.3.54
>
> proxy -Cn ctx -v 2c -c public  localhost .1.3 .1.3.6.1.3.54
>
>
>
> with test.py:
>
>
>
> #!/usr/bin/python -u
>
> import snmp_passpersist as snmp
>
> from random import randint
>
>
>
> def update():
>
>    pp.add_str('0.1',string)
>
>    pp.add_int('0.2',randint(0,100))
>
> pp=snmp.PassPersist(".1.3.6.1.3.54")
>
> pp.start(update,10)
>
>
>
> If I walk over .1.3.6.1.3.54 I get this:
>
>
>
> root@debian:/home/ciscolab# snmpwalk -v2c -c public localhost
> .1.3.6.1.3.54
>
> iso.3.6.1.3.54.0.1 = STRING: "string"
>
> iso.3.6.1.3.54.0.2 = INTEGER: 95
>
>
>
> If I walk over .1.4 (community fakecomm) I get this:
>
>
>
> root@debian:/home/ciscolab# snmpwalk -v2c -c fakecomm localhost .1.4
>
> iso.4.0.1 = STRING: "string"
>
> iso.4.0.2 = INTEGER: 70
>
> iso.4.0.2 = No more variables left in this MIB View (It is past the end of
> the MIB tree)
>
>
>
> and If I walk over .1.3 (community fakecomm):
>
>
>
> root@debian:/home/ciscolab# snmpwalk -v2c -c fakecomm localhost .1.3
>
> iso.3.0.1 = STRING: "string"
>
> iso.3.0.1 = STRING: "string"
>
> Error: OID not increasing: iso.3.0.1
>
> >= iso.3.0.1
>
>
>
> On  the server side:
>
>
>
> when I query 1.4:
>
>
>
> Connection from UDP: [127.0.0.1]:56075->[127.0.0.1]:161
>
> ucd-snmp/pass_persist: open_persist_pipe(1,'/home/ciscolab/test.py')
> recurse=0
>
> ucd-snmp/pass_persist: persistpass-sending:
>
> getnext
>
> .1.3.6.1.3.54
>
> Connection from UDP: [127.0.0.1]:36559->[127.0.0.1]:161
>
> Connection from UDP: [127.0.0.1]:56075->[127.0.0.1]:161
>
> ucd-snmp/pass_persist: open_persist_pipe(1,'/home/ciscolab/test.py')
> recurse=0
>
> ucd-snmp/pass_persist: persistpass-sending:
>
> getnext
>
> .1.3.6.1.3.54.0.1
>
> Connection from UDP: [127.0.0.1]:36559->[127.0.0.1]:161
>
> Connection from UDP: [127.0.0.1]:56075->[127.0.0.1]:161
>
> ucd-snmp/pass_persist: open_persist_pipe(1,'/home/ciscolab/test.py')
> recurse=0
>
> ucd-snmp/pass_persist: persistpass-sending:
>
> getnext
>
> .1.3.6.1.3.54.0.2
>
>
>
> when I query 1.3:
>
>
>
> Connection from UDP: [127.0.0.1]:53500->[127.0.0.1]:161
>
> Connection from UDP: [127.0.0.1]:52397->[127.0.0.1]:161
>
> ucd-snmp/pass_persist: open_persist_pipe(1,'/home/ciscolab/test.py')
> recurse=0
>
> ucd-snmp/pass_persist: open_persist_pipe: opened the pipes
>
> ucd-snmp/pass_persist: persistpass-sending:
>
> getnext
>
> .1.3.6.1.3.54
>
> Connection from UDP: [127.0.0.1]:53500->[127.0.0.1]:161
>
> Connection from UDP: [127.0.0.1]:52397->[127.0.0.1]:161
>
> ucd-snmp/pass_persist: open_persist_pipe(1,'/home/ciscolab/test.py')
> recurse=0
>
> ucd-snmp/pass_persist: persistpass-sending:
>
> getnext
>
> .1.3.6.1.3.54
>
>
>
>
>
> Thanks
>
>
>
> *From:* Antonio Piepoli (apiepoli)
> *Sent:* Wednesday, August 19, 2015 6:09 PM
> *To:* '[email protected]'
> *Subject:* Concatenating MIBs over multiple contexts
>
>
>
> Hello everybody,
>
>
>
> I am Antonio and I am trying to solve a problem using net-snmp and
> pass_persist (with python). I would ask your support/opinion on this.
>
>
>
> There is a former implementation of the BGP MIB(1.3.6.1.2.1.15.3.1.2) on
> some Cisco routers that stores all the information about all the BGP peers
> (in all the VRFs). In the new IOS XR this is not happening. In particular
> the BGP MIB now stores only the information about the peers in the global
> routing table of the router (so it does not store information about the
> peers in other VRFs). To address this a new MIB was created:
> CISCO-BGP4-MIB(.1.3.6.1.4.1.9.9.187).  This MIB does not replicate the same
> behavior of the former BGP MIB. This MIB is context aware and therefore is
> necessary to configure on the routers multiple contexts; to map the context
> to a VRF and at the end to map a community to a context. At the end
> querying the device on the community that is mapped to a VRF through a
> context I am able to get the BGP peers in that VRF.
>
>
>
> Long story short I am trying to emulate the former behavior of the BGP
> MIB. In particular my idea is to, through a proxy, intercept the query and
> run a script that collects all the information, querying over all the
> communities, and returns the concatenation of the content of the tree over
> all the communities(vrfs).
>
>
>
> I am using net-snmp as proxy and pass_persist to call a python script that
> populates the tree like the former bgp MIB.
>
>
>
> More or less the conf is (omitting all the auth stuffs):
>
>
>
> pass_persist .1.3.6.1.3.60 /home/ciscolab/CiscobgpMIB_router1.py
>
> pass_persist .1.3.6.1.3.70 /home/ciscolab/CiscobgpMIB_router2.py
>
> com2sec -Cn ctx notConfigUser  default fakecomm
>
> com2sec -Cn ctx2 notConfigUser  default fakecomm2
>
>
>
> proxy -Cn ctx -v 2c -c public  <IP ROUTER 1> 1.3
>
> proxy -Cn ctx -v 2c -c public  localhost .1.3.6.1.4.1.9.9.187 .1.3.6.1.3.60
>
>
>
> proxy -Cn ctx2 -v 2c -c public  <IP ROUTER 2> 1.3
>
> proxy -Cn ctx2 -v 2c -c public  localhost .1.3.6.1.4.1.9.9.187
> .1.3.6.1.3.70
>
>
>
> So far I was able to perform this concatenation for the CISCO-BGP4-MIB but
> not for the BGP MIB.
>
>
>
> In order to perform the concatenation for the BGP MIB I would so something
> like:
>
>
>
> pass_persist .1.3.6.1.3.61 /home/ciscolab/bgpMIB_router1.py
>
> pass_persist .1.3.6.1.3.71 /home/ciscolab/bgpMIB_router2.py
>
>
>
> proxy -Cn ctx -v 2c -c public  localhost .1.3.6.1.2.1.15.3.1.2
> .1.3.6.1.3.61
>
> proxy -Cn ctx2 -v 2c -c public  localhost .1.3.6.1.2.1.15.3.1.2
> .1.3.6.1.3.71
>
>
>
> But is not working. Is there any sort of mechanism that prevents the proxy
> to work on standard MIBS? If I change to .1.4.6.1.2.1.15.3.1.2 it works
> without modifying anything else.
>
>
>
>
>
> Any Idea?
>
>
>
> Thanks a lot
>
>
>
>
>
> *Antonio Piepoli*
> NCE  - Network Consulting Engineer.
> [email protected]
> Phone: +39 06 5164 5047
>
> *Cisco Systems Limited*
>
> [image: http://www.cisco.com/web/europe/images/email/signature/logo05.jpg]
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Net-snmp-users mailing list
> [email protected]
> Please see the following page to unsubscribe or change other options:
> https://lists.sourceforge.net/lists/listinfo/net-snmp-users
>
>

------------------------------------------------------------------------------

_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
image001.jpg (image/jpeg, 5.5 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.