Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Juniper BGP monitoring #252

Open
SnDsound opened this issue Aug 7, 2017 · 11 comments
Open

Juniper BGP monitoring #252

SnDsound opened this issue Aug 7, 2017 · 11 comments
Labels
enhancement measure-design Related to improve design for metric gathering
Milestone

Comments

@SnDsound
Copy link

SnDsound commented Aug 7, 2017

Hi,

I'm trying to create measurement for BGP prefixes for Juniper products, but I stuck.
Maybe I don't know how to create this kind of measurements, or it's not possible to do this right now.

Base OID which should be used as index is regarding to Juniper documentation is: .1.3.6.1.4.1.2636.5.1.1.2.1.1.1.14
Output for this is:

$ snmpwalk -v2c device_ip .1.3.6.1.4.1.2636.5.1.1.2.1.1.1.14
.1.3.6.1.4.1.2636.5.1.1.2.1.1.1.14.10.1.172.18.3.25.1.172.18.3.26 = Gauge32: **4**
.1.3.6.1.4.1.2636.5.1.1.2.1.1.1.14.10.1.172.18.3.29.1.172.18.3.30 = Gauge32: **5**

So we have after .14:
10.1 - I don't know what it is
172.18.3.25 - Source IP
1 - I don't know what it is
172.18.3.26 - Destination IP

As value for particular index we have 4 or 5, which is a Juniper "index value" used for other things.
Then for example I would like to have number of received prefixes.
I should use value from jnxBgpM2PeerIndex, to get number of prefixes:

$ snmpwalk -v2c device_ip .1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7

.1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7.**4**.1.1 = Gauge32: 2
.1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7.**5**.1.1 = Gauge32: 2

So I've created 2 SNMP Metrics:
jnxBgpM2PeerIndex - .1.3.6.1.4.1.2636.5.1.1.2.1.1.1.14
jnxBgpM2PrefixInPrefixes - .1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7

juniper bgp - jnxbgpm2peerindex
juniper bgp - jnxbgpm2prefixinprefixes

Then Influx Measurements, where I'm getting Destination IP as TAG:
juniper bgp

But my table is not working as I expected. I have BGP peer IP, jnxBgpM2PeerIndex from SNMP, but there is no match for number of prefixes.

juniper bgp - device

SNMP Collector is always forwarding index from jnxBgpM2PeerIndex to jnxBgpM2PrefixInPrefixes
I've tried to use direct / indirect TAG, change IndexAsValue to true/false, but result is always the same.

time="2017-08-07 19:33:30" level=warning msg="MEASUREMENT [Juniper_BGP_Monitoring] Warning METRIC ID [jnxBgpM2PrefixInPrefixes] from MEASUREMENT[ Juniper_BGP_Monitoring ] with TAGS [map[device:XXXX bgp_peer:172.18.3.30]] has no valid data => See Metric Runtime [ &{cfg:0xc4202b10e0 ID:jnxBgpM2PrefixInPrefixes FieldName:jnxBgpM2PrefixInPrefixes Valid:false CookedValue:<nil> CurValue:<nil> LastValue:<nil> CurTime:0001-01-01 00:00:00 +0000 UTC LastTime:0001-01-01 00:00:00 +0000 UTC ElapsedTime:0 Compute:<nil> Scale:0x943850 SetRawData:0x943c60 RealOID:.1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7.10.1.172.18.3.29.1.172.18.3.30 Report:1 re:<nil> expr:<nil> condflt:<nil> log:0xc4201424b0} ]"
time="2017-08-07 19:33:30" level=warning msg="MEASUREMENT [Juniper_BGP_Monitoring] Warning METRIC ID [jnxBgpM2PrefixInPrefixes] from MEASUREMENT[ Juniper_BGP_Monitoring ] with TAGS [map[device:XXXX bgp_peer:172.18.3.26]] has no valid data => See Metric Runtime [ &{cfg:0xc4202b10e0 ID:jnxBgpM2PrefixInPrefixes FieldName:jnxBgpM2PrefixInPrefixes Valid:false CookedValue:<nil> CurValue:<nil> LastValue:<nil> CurTime:0001-01-01 00:00:00 +0000 UTC LastTime:0001-01-01 00:00:00 +0000 UTC ElapsedTime:0 Compute:<nil> Scale:0x943850 SetRawData:0x943c60 RealOID:.1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7.10.1.172.18.3.25.1.172.18.3.26 Report:1 re:<nil> expr:<nil> condflt:<nil> log:0xc4201424b0} ]"

How can I build this kind of measurement?

Best regards,
Peter

@sbengo
Copy link
Collaborator

sbengo commented Aug 8, 2017

Hi @SnDsound , first of all, thanks for your detailed explanation!

When you define an IndexOID it is expected that all the attached metrics use the same index as your IndexOID indexes and not values. Your desired behaviour is you want to use the values given by the IndexOID instead of indexes and use them as index for the attached metrics, right?

We will try to study the case and find a possible solution!

To be sure if I understand your issue and to summarise it:

  • Are the following lines your same case?

In your example:

IndexOID: .1.3.6.1.4.1.2636.5.1.1.2.1.1.1.14

IDX1 = [10.1.172.18.3.25.1.172.18.3.26, 10.1.172.18.3.29.1.172.18.3.30]
VAL1 = [4,5]

The attached metrics will use the IDX1 indexes to get the values, as you attached on your logs, it is trying to query BaseOID + IDX1:

Base OID: .1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7
It will use the IDX1 array to get the values:
BaseOID + IDX1[0]: .1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7[.10.1.172.18.3.29.1.172.18.3.26], 
BaseOID + IDX1[1]: .1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7[.10.1.172.18.3.29.1.172.18.3.30],

And your desired behaviour is BaseOID + VAL1:

Base OID: .1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7
It will use the VAL1 array to get the values:
BaseOID + VAL1[0]: .1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7.[4] 
BaseOID + VAL1[1]: .1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7.[5]

@SnDsound
Copy link
Author

SnDsound commented Aug 8, 2017

Hi @sbengo,

Thanks for prompt response.

Yes, I wan't to use IndexOID vaule, as index for next queries. In this case:

  • From IDX1 I want to extract BGP Peer IP in human readable format, as TAG.
  • I want to use VAL1 from IndexOID as index in next queries

This is for this case. Your explanation is ok, and BaseOID + VAL1 will cover this topic.
Of course if this VAL1 putted after OID will be probably recognized, because SNMP is returning .1.1 after each index in output:

$ snmpwalk -v2c device_ip .1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7

.1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7.**4**.1.1 = Gauge32: 2
.1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7.**5**.1.1 = Gauge32: 2

I had similar topic when I wanted to monitor resources on Cisco 9006 device (IOS-XR).
Even more, sometimes I need to put VAL1 in the middle, and select (add number to OID) and put it after VAL1, because it matters.

Please look at this topic: https://supportforums.cisco.com/document/73251/monitoring-cpu-utilization-ios-xr-based-platforms-using-snmp-tools, especially at Fabrice Ducomble post.

After you get the index for each card:

Step 1 : The snmpwalk of OID 1.3.6.1.2.1.47.1.1.1.1.7 gives us the mapping 
between index and line cards CPU :

SNMPv2-SMI::mib-2.47.1.1.1.1.7.16203662 = STRING: "module 0/0/CPU0"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.38557239 = STRING: "module 0/RSP0/CPU0"

You need to take index, put in in the middle, and at the end define numeric type. In this case 1 will represent other type of memory, 2 will be for processorMemory, 6 for multibusMemory, etc.
Maybe this can be done by coocked type metrics, but I didn't have chance to test this func.

Step 2 : use below OID to retrieve used & free mem :

1.3.6.1.4.1.9.9.221.1.1.1.1.18 gives the used memory :

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?objectInput=1.3.6.1.4.1.9.9.221.1.1.1.1.18&translate=Translate&submitValue=SUBMIT&submitClicked=true

1.3.6.1.4.1.9.9.221.1.1.1.1.20 gives free memory :

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?objectInput=1.3.6.1.4.1.9.9.221.1.1.1.1.20&translate=Translate&submitValue=SUBMIT&submitClicked=true
Please note ASR9k uses pool type 1 (other) as defined here :

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?objectInput=1.3.6.1.4.1.9.9.221.1.1.1.1.2&translate=Translate&submitValue=SUBMIT&submitClicked=true


Example for RSP0 in chassis 0 (index = 38557239):

SNMPv2-SMI::enterprises.9.9.221.1.1.1.1.18.38557239.1 = Counter64: 1439284872

SNMPv2-SMI::enterprises.9.9.221.1.1.1.1.20.38557239.1 = Counter64: 4734349312

Object cempMemPoolType
OID 1.3.6.1.4.1.9.9.221.1.1.1.1.2
Type CempMemPoolTypes

1:other
2:processorMemory
3:ioMemory
4:pciMemory
5:fastMemory
6:multibusMemory
7:interruptStackMemory
8:processStackMemory
9:localExceptionMemory
10:virtualMemory
11:reservedMemory
12:imageMemory
13:asicMemory
14:posixMemory

Permission | read-only
Status | current
MIB | CISCO-ENHANCED-MEMPOOL-MIB ;

Regards,
Peter

@pavleec
Copy link

pavleec commented Sep 5, 2017

The @SnDsound most requested feature would also greatly fix some of my problems. All of the above comes down generally to have an option to use $VAL1 from IndexOID as index for queries. Any chance of implementing that?

@pavleec
Copy link

pavleec commented Sep 27, 2017

Are there any chances to implement this?

@toni-moreno
Copy link
Owner

Hi @pavleec, rigth now, he have no time enough, but we have plans to implement ASAP.

@johnmca
Copy link

johnmca commented Oct 27, 2017

+1
Was just trying to solve the same issue @SnDsound describes with the CISCO-ENHANCED-MEMPOOL-MIB

@SnDsound
Copy link
Author

SnDsound commented Jan 5, 2018

Hi @toni-moreno,

Any news about implementation?

@sbengo
Copy link
Collaborator

sbengo commented Jan 10, 2018

Hello guys,

First of all, sorry for the delayed response!

We detected 2 needs on this issue:

$VAL1 as index

As you described quite well, @SnDsound , the first implementation would be set up the $VAL1 as the real index.
This is not really difficult, but the following need comes up:

Index suffix (single and mapped)

Both cases, the BGP and the Cisco Enhanced seems to have a suffix on the metric query: 1.1 on BGP and 1,2,..,14 on Cisco Enhanced Memory (types).

This suffix breaks the way that SNMPCollector maps the metric query result with the indexed ones: it is expected that both walks have the same index, the measurement and metric ones. Example:

Measurement IDX1 results : [1000,1001,1002...]
METRIC Base OID: 1.3.6.1

Result Metric snmpwalk:
1.3.6.1.[[1000].1.1] = 3
1.3.6.1.[[1001].1.1] = 4

Mapping:
Checking for indexes -->  1000.1.1 != 1000 --> Discarded!
Checking for indexes -->  1001.1.1 != 1001 -->  Discarded!

Implementing this would produce several changes on code (without breaking the existent one), so we have no foresight to implement it!

Thanks,
Greetings!

@tkacprzynski
Copy link

I think this is similar issue, but I have QoS RED drops for best-effort I would like to capture, but there is an interface index in the middle. In example below is interface index 593.

how snmp mib walk jnxCosIfqTotalRedDropPkts ascii | grep 593
jnxCosIfqTotalRedDropPkts.593."best-effort" = 129893556
jnxCosIfqTotalRedDropPkts.593."network-control" = 0
jnxCosIfqTotalRedDropPkts.593."assured-forwarding" = 0
jnxCosIfqTotalRedDropPkts.593."expedited-forwarding" = 0

Anyway I could get that if you implement this feature?

@SnDsound
Copy link
Author

Hi @sbengo / @toni-moreno

Do you have plans to implement mentioned functionalities?

  • $VAL1 as index
  • Index suffix (single and mapped)

Regards,
Peter

@toni-moreno
Copy link
Owner

Hello @SnDsound , We have recently updated wth 2 new measurement types:

Feel free to test if you can now query data as you need.

@toni-moreno toni-moreno added this to the 1.0.0 milestone Mar 7, 2021
@toni-moreno toni-moreno added enhancement measure-design Related to improve design for metric gathering labels Mar 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement measure-design Related to improve design for metric gathering
Projects
None yet
Development

No branches or pull requests

6 participants