Various questions (BGP/Discovery/Pseudowires/Hostname truncating)
First off, let me say thanks to the developers of Observium. This piece of code is one of the most amazing pieces of code I have used for my network monitoring purposes to date.
I have a few questions that I'm hoping someone can answer -
BGP: ---- I have a few eBGP speakers that live inside a VRF. Observium picks up the VRFs just fine, but the routing tab for the device only seems to show the BGP sessions that exist in the global (non-VRF) table. Is it possible to show the BGP sessions that exist inside a VRF?
Pseudowires: ------------ I see lots of data inside the pseudowires table on the observium database, but I don't see any of that inside the pseudowires tab from within a device where I know pseudowires are configured. These pseudowires exist on IOS boxes, IOS-XR boxes and IOS-XE boxes. I do see a few. Observium > Ports > Pseudowires shows me 11 pseuowires. 6 of them are duplicates of one another while 5 are unique. The database shows hundreds.
While looking through a ./discovery.php -d I ran against one of our XR boxes, I did see this:
Cisco Pseudowires : SQL[SELECT * FROM `pseudowires` WHERE `device_id` = '1'] DEBUG: SNMP Auth options = -v2c -c ************ /usr/bin/snmpbulkwalk -v2c -c ************ -OQUs -m CISCO-IETF-PW-MPLS-MIB -M /opt/observium/mibs udp:router:161 cpwVcID cpwVcID = No Such Instance currently exists at this OID
DEBUG: SNMP Auth options = -v2c -c ************ /usr/bin/snmpbulkwalk -v2c -c ************ -OQUs -m CISCO-IETF-PW-MPLS-MIB -M /opt/observium/mibs udp:router:161 cpwVcName cpwVcName = No Such Instance currently exists at this OID
DEBUG: SNMP Auth options = -v2c -c ************ /usr/bin/snmpbulkwalk -v2c -c ************ -OQUs -m CISCO-IETF-PW-MPLS-MIB -M /opt/observium/mibs udp:router:161 cpwVcType cpwVcType = No Such Instance currently exists at this OID
DEBUG: SNMP Auth options = -v2c -c ************ /usr/bin/snmpbulkwalk -v2c -c ************ -OQUs -m CISCO-IETF-PW-MPLS-MIB -M /opt/observium/mibs udp:router:161 cpwVcPsnType cpwVcPsnType = No Such Instance currently exists at this OID
DEBUG: SNMP Auth options = -v2c -c ************ /usr/bin/snmpbulkwalk -v2c -c ************ -OQUs -m CISCO-IETF-PW-MPLS-MIB -M /opt/observium/mibs udp:router:161 cpwVcDescr cpwVcDescr = No Such Instance currently exists at this OID
DEBUG: SNMP Auth options = -v2c -c ************ /usr/bin/snmpbulkwalk -v2c -c ************ -OQUs -m CISCO-IETF-PW-MPLS-MIB -M /opt/observium/mibs udp:router:161 cpwVcMplsPeerLdpID cpwVcMplsPeerLdpID = No Such Instance currently exists at this OID
That seems to show that pseudowire support for XR isn't there yet? Is that on the road map, by chance?
Discovery: ---------- There are a couple of devices that aren't getting discovered for some reason. The IP that their hostname resolves to is within the 'nets' arrays configured inside config.php and I have other SNMP devices that reach those boxes, so I know the SNMP side is sound. Likewise, I can see the device in question in the CDP table of an adjacent device, so I know that part is working as well.
I've looked at a ./discovery -d of an adjacent device hoping to see a clue about why the device is being skipped, but nothing is striking out at me.
Hostname truncating: -------------------- We name our devices <device><device_number>.<pop>.<city>.domain.tld. In the devices view, it shows the full device name no problem. In the VRF view, for example, however, it shows only <device><device_number>, truncating the pop and city portions.
If anyone has any insight or guidance on these issues, I'd be grateful!
Thanks in advance.
I just want to reply to my own thread here with an odd update..
On 2012-10-15, at 8:22 PM, Jason Lixfeld jason@lixfeld.ca wrote:
Discovery:
There are a couple of devices that aren't getting discovered for some reason. The IP that their hostname resolves to is within the 'nets' arrays configured inside config.php and I have other SNMP devices that reach those boxes, so I know the SNMP side is sound. Likewise, I can see the device in question in the CDP table of an adjacent device, so I know that part is working as well.
I've looked at a ./discovery -d of an adjacent device hoping to see a clue about why the device is being skipped, but nothing is striking out at me.
Miraculously, last night, one of the two devices was discovered. All I can think of that I did that might have triggered something was to run ./discovery.php -h <adjacent_device> -d -- where <adjacent_device> is a) a device that Observium has already discovered and has been polling since last week b) was initially discovered as part of the ./discovery.php -h all that is run after the first ./addhost.php <seed_device> <community> c) is directly connected to the device that was not getting discovered.
There is still no change on the second of the two previously undiscovered devices. Interestingly enough, it too is connected to the same device that I ran the aforementioned -d discovery on yesterday which ultimately led to the first of the two previously undiscovered devices finally being discovered.
Any thoughts? Anything I can do to try to help troubleshoot this?
Incase this fell out of anyone's inbox, still looking for some input on any of these items. My limited debugging abilities with PHP aren't helping matters much :(
On 2012-10-15, at 8:22 PM, Jason Lixfeld jason@lixfeld.ca wrote:
First off, let me say thanks to the developers of Observium. This piece of code is one of the most amazing pieces of code I have used for my network monitoring purposes to date.
I have a few questions that I'm hoping someone can answer -
BGP:
I have a few eBGP speakers that live inside a VRF. Observium picks up the VRFs just fine, but the routing tab for the device only seems to show the BGP sessions that exist in the global (non-VRF) table. Is it possible to show the BGP sessions that exist inside a VRF?
Pseudowires:
I see lots of data inside the pseudowires table on the observium database, but I don't see any of that inside the pseudowires tab from within a device where I know pseudowires are configured. These pseudowires exist on IOS boxes, IOS-XR boxes and IOS-XE boxes. I do see a few. Observium > Ports > Pseudowires shows me 11 pseuowires. 6 of them are duplicates of one another while 5 are unique. The database shows hundreds.
While looking through a ./discovery.php -d I ran against one of our XR boxes, I did see this:
Cisco Pseudowires : SQL[SELECT * FROM `pseudowires` WHERE `device_id` = '1'] DEBUG: SNMP Auth options = -v2c -c ************ /usr/bin/snmpbulkwalk -v2c -c ************ -OQUs -m CISCO-IETF-PW-MPLS-MIB -M /opt/observium/mibs udp:router:161 cpwVcID cpwVcID = No Such Instance currently exists at this OID
DEBUG: SNMP Auth options = -v2c -c ************ /usr/bin/snmpbulkwalk -v2c -c ************ -OQUs -m CISCO-IETF-PW-MPLS-MIB -M /opt/observium/mibs udp:router:161 cpwVcName cpwVcName = No Such Instance currently exists at this OID
DEBUG: SNMP Auth options = -v2c -c ************ /usr/bin/snmpbulkwalk -v2c -c ************ -OQUs -m CISCO-IETF-PW-MPLS-MIB -M /opt/observium/mibs udp:router:161 cpwVcType cpwVcType = No Such Instance currently exists at this OID
DEBUG: SNMP Auth options = -v2c -c ************ /usr/bin/snmpbulkwalk -v2c -c ************ -OQUs -m CISCO-IETF-PW-MPLS-MIB -M /opt/observium/mibs udp:router:161 cpwVcPsnType cpwVcPsnType = No Such Instance currently exists at this OID
DEBUG: SNMP Auth options = -v2c -c ************ /usr/bin/snmpbulkwalk -v2c -c ************ -OQUs -m CISCO-IETF-PW-MPLS-MIB -M /opt/observium/mibs udp:router:161 cpwVcDescr cpwVcDescr = No Such Instance currently exists at this OID
DEBUG: SNMP Auth options = -v2c -c ************ /usr/bin/snmpbulkwalk -v2c -c ************ -OQUs -m CISCO-IETF-PW-MPLS-MIB -M /opt/observium/mibs udp:router:161 cpwVcMplsPeerLdpID cpwVcMplsPeerLdpID = No Such Instance currently exists at this OID
That seems to show that pseudowire support for XR isn't there yet? Is that on the road map, by chance?
Discovery:
There are a couple of devices that aren't getting discovered for some reason. The IP that their hostname resolves to is within the 'nets' arrays configured inside config.php and I have other SNMP devices that reach those boxes, so I know the SNMP side is sound. Likewise, I can see the device in question in the CDP table of an adjacent device, so I know that part is working as well.
I've looked at a ./discovery -d of an adjacent device hoping to see a clue about why the device is being skipped, but nothing is striking out at me.
Hostname truncating:
We name our devices <device><device_number>.<pop>.<city>.domain.tld. In the devices view, it shows the full device name no problem. In the VRF view, for example, however, it shows only <device><device_number>, truncating the pop and city portions.
If anyone has any insight or guidance on these issues, I'd be grateful!
Thanks in advance. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
On 22/10/2012 10:21, Jason Lixfeld wrote:
Incase this fell out of anyone's inbox, still looking for some input on any of these items. My limited debugging abilities with PHP aren't helping matters much :(
On 2012-10-15, at 8:22 PM, Jason Lixfeld jason@lixfeld.ca wrote:
First off, let me say thanks to the developers of Observium. This piece of code is one of the most amazing pieces of code I have used for my network monitoring purposes to date.
I have a few questions that I'm hoping someone can answer -
BGP:
I have a few eBGP speakers that live inside a VRF. Observium picks up the VRFs just fine, but the routing tab for the device only seems to show the BGP sessions that exist in the global (non-VRF) table. Is it possible to show the BGP sessions that exist inside a VRF?
The BGP4-MIB is incapable of showing these sessions, as it has no VRF awareness. This is something only the vendor can fix.
Pseudowires:
I see lots of data inside the pseudowires table on the observium database, but I don't see any of that inside the pseudowires tab from within a device where I know pseudowires are configured. These pseudowires exist on IOS boxes, IOS-XR boxes and IOS-XE boxes. I do see a few. Observium > Ports > Pseudowires shows me 11 pseuowires. 6 of them are duplicates of one another while 5 are unique. The database shows hundreds.
While looking through a ./discovery.php -d I ran against one of our XR boxes, I did see this:
Cisco Pseudowires : SQL[SELECT * FROM `pseudowires` WHERE `device_id` = '1'] DEBUG: SNMP Auth options = -v2c -c ************ /usr/bin/snmpbulkwalk -v2c -c ************ -OQUs -m CISCO-IETF-PW-MPLS-MIB -M /opt/observium/mibs udp:router:161 cpwVcID cpwVcID = No Such Instance currently exists at this OID
DEBUG: SNMP Auth options = -v2c -c ************ /usr/bin/snmpbulkwalk -v2c -c ************ -OQUs -m CISCO-IETF-PW-MPLS-MIB -M /opt/observium/mibs udp:router:161 cpwVcName cpwVcName = No Such Instance currently exists at this OID
DEBUG: SNMP Auth options = -v2c -c ************ /usr/bin/snmpbulkwalk -v2c -c ************ -OQUs -m CISCO-IETF-PW-MPLS-MIB -M /opt/observium/mibs udp:router:161 cpwVcType cpwVcType = No Such Instance currently exists at this OID
DEBUG: SNMP Auth options = -v2c -c ************ /usr/bin/snmpbulkwalk -v2c -c ************ -OQUs -m CISCO-IETF-PW-MPLS-MIB -M /opt/observium/mibs udp:router:161 cpwVcPsnType cpwVcPsnType = No Such Instance currently exists at this OID
DEBUG: SNMP Auth options = -v2c -c ************ /usr/bin/snmpbulkwalk -v2c -c ************ -OQUs -m CISCO-IETF-PW-MPLS-MIB -M /opt/observium/mibs udp:router:161 cpwVcDescr cpwVcDescr = No Such Instance currently exists at this OID
DEBUG: SNMP Auth options = -v2c -c ************ /usr/bin/snmpbulkwalk -v2c -c ************ -OQUs -m CISCO-IETF-PW-MPLS-MIB -M /opt/observium/mibs udp:router:161 cpwVcMplsPeerLdpID cpwVcMplsPeerLdpID = No Such Instance currently exists at this OID
That seems to show that pseudowire support for XR isn't there yet? Is that on the road map, by chance?
It's all from the same MIBs. I've not looked at the pseudowire code for a very, very, very long time, so it's possible that it's not correctly tracking them.
Discovery:
There are a couple of devices that aren't getting discovered for some reason. The IP that their hostname resolves to is within the 'nets' arrays configured inside config.php and I have other SNMP devices that reach those boxes, so I know the SNMP side is sound. Likewise, I can see the device in question in the CDP table of an adjacent device, so I know that part is working as well.
I've looked at a ./discovery -d of an adjacent device hoping to see a clue about why the device is being skipped, but nothing is striking out at me.
The device needs a valid reverse dns entry, and its hostname can't clash with another hostname. Its SNMP "sysName" must be resolveable.
Hostname truncating:
We name our devices <device><device_number>.<pop>.<city>.domain.tld. In the devices view, it shows the full device name no problem. In the VRF view, for example, however, it shows only <device><device_number>, truncating the pop and city portions.
You have a crappy naming scheme which takes too much space! In many places in the interface we have to truncate the hostname for space reasons.
adam.
participants (2)
-
Adam Armstrong -
Jason Lixfeld