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) <
apiep...@cisco.com> 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:* 'net-snmp-users@lists.sourceforge.net'
> *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.
> apiep...@cisco.com
> 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
> Net-snmp-users@lists.sourceforge.net
> 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
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
