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]<mailto:[email protected]>
Phone: +39 06 5164 5047
Cisco Systems Limited
[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
