Bgp peers routes adviertised / received info missing

Hi guys.
I have recently add my Huawei NE8000 to librenms.
After basic snmp setting I can see all my bgp peers , updates and peer status.
But:
Im not receiving info about advertised and received prefix for each peer.

Is there something I need to check on the router or lnms ?
Regards.
Leandro.

Hello @Leandro_Roggerone
Last time I worked with BGP support on VRP devices, these values were not available. And they are still not available on my devices (CloudEngines and AccessRouters). I don’t have any NetEngines to check.
Feel free to investigate with snmpwalk and if you find the values, get back to me.

Dear @PipoCanaja : Thanks for your words.
I have some news.
After checking with a NE40 operator friend, he confirmed , that using observium , bgp rev and adv prefixes graphs are created out of the box.
Also, after contacting huawei support they provided me following oids:

1.3.6.1.4.1.2011.5.25.177.1.1.3.1.1
1.3.6.1.4.1.2011.5.25.177.1.1.3.1.3

And after checking snmpwalk , I got the so desired results:

[root@monitoreo_wiber ~]# snmpwalk -v2c -c  X 172.22.255.254 1.3.6.1.4.1.2011.5.25.177.1.1.3.1.1
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.1.0.1.1.1.4.10.45.1.1 = Counter32: 2
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.1.0.1.1.1.4.10.45.2.2 = Counter32: 14140
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.1.0.1.1.1.4.10.45.3.2 = Counter32: 14144
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.1.0.1.1.1.4.10.65.11.2 = Counter32: 1
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.1.0.1.1.1.4.10.65.12.2 = Counter32: 0
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.1.0.1.1.1.4.45.189.216.158 = Counter32: 0
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.1.0.1.1.1.4.45.189.216.208 = Counter32: 0
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.1.0.1.1.1.4.177.16.216.252 = Counter32: 0
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.1.0.1.1.1.4.177.16.216.253 = Counter32: 0
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.1.0.1.1.1.4.177.16.216.254 = Counter32: 0
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.1.0.1.1.1.4.177.16.223.253 = Counter32: 0
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.1.0.1.1.1.4.177.16.223.254 = Counter32: 0
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.1.0.1.1.1.4.178.18.202.5 = Counter32: 0
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.1.0.1.1.1.4.270.23.206.1 = Counter32: 13125
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.1.0.1.1.1.4.270.23.206.2 = Counter32: 13117
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.1.0.1.1.1.4.274.199.0.169 = Counter32: 0
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.1.0.2.1.2.16.32.1.18.248.0.0.0.0.0.0.0.0.0.0.2.82 = Counter32: 0
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.1.0.2.1.2.16.32.1.18.248.0.0.0.0.0.0.0.0.0.0.2.83 = Counter32: 0
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.1.0.2.1.2.16.32.1.18.248.0.0.0.0.0.0.0.0.0.0.2.84 = Counter32: 0
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.1.0.2.1.2.16.32.1.18.248.0.0.0.0.0.0.0.0.2.35.2.83 = Counter32: 0
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.1.0.2.1.2.16.32.1.18.248.0.0.0.0.0.0.0.0.2.35.2.84 = Counter32: 0
[root@monitoreo_wiber ~]# snmpwalk -v2c -c X 172.22.255.254 1.3.6.1.4.1.2011.5.25.177.1.1.3.1.3
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.3.0.1.1.1.4.10.45.1.1 = Counter32: 1
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.3.0.1.1.1.4.10.45.2.2 = Counter32: 13133
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.3.0.1.1.1.4.10.45.3.2 = Counter32: 13133
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.3.0.1.1.1.4.10.65.11.2 = Counter32: 0
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.3.0.1.1.1.4.10.65.12.2 = Counter32: 0
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.3.0.1.1.1.4.45.179.216.158 = Counter32: 27
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.3.0.1.1.1.4.45.179.216.208 = Counter32: 27
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.3.0.1.1.1.4.177.16.216.252 = Counter32: 21
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.3.0.1.1.1.4.177.16.216.253 = Counter32: 21
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.3.0.1.1.1.4.177.16.216.254 = Counter32: 21
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.3.0.1.1.1.4.177.16.223.253 = Counter32: 21
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.3.0.1.1.1.4.177.16.223.254 = Counter32: 21
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.3.0.1.1.1.4.178.18.202.5 = Counter32: 18
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.3.0.1.1.1.4.270.23.206.1 = Counter32: 21
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.3.0.1.1.1.4.270.23.206.2 = Counter32: 21
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.3.0.1.1.1.4.274.199.0.169 = Counter32: 18
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.3.0.2.1.2.16.32.1.18.248.0.0.0.0.0.0.0.0.0.0.2.82 = Counter32: 0
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.3.0.2.1.2.16.32.1.18.248.0.0.0.0.0.0.0.0.0.0.2.83 = Counter32: 0
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.3.0.2.1.2.16.32.1.18.248.0.0.0.0.0.0.0.0.0.0.2.84 = Counter32: 0
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.3.0.2.1.2.16.32.1.18.248.0.0.0.0.0.0.0.0.2.35.2.83 = Counter32: 0
SNMPv2-SMI::enterprises.2011.5.25.177.1.1.3.1.3.0.2.1.2.16.32.1.18.248.0.0.0.0.0.0.0.0.2.35.2.84 = Counter32: 0

I also have been checking to modules section:
I can see (for my device):
Poller modules
bgp peer available unset unset
Discovery modules
bgp peer available unset unset

So … Is there some way to check / set the oid ? or other idea to get rcv and adv prefixes.
thanks!
leo.

Code for BGP Peers discovery and polling has to be adapted. All VRP devices are behaving differently and providing more or less data. I don’t have a NE8000 myself, so the code is only (more or less) handling the models I have.

A new update of this code will come in a few days.

You can test it by doing this :
./scripts/github-apply 12585

And to remove the patch after your test :

git checkout  includes/discovery/bgp-peers/vrp.inc.php 
git checkout  mibs/huawei/HUAWEI-BGP-VPN-MIB 
git checkout  tests/data/vrp_ce12804-withvrf.json 
git checkout  tests/snmpsim/vrp_ce12804-withvrf.snmprec 

Dear @PipoCanaja;
I tryed your script but have no luck.
I have a recently updated non in production platform to test this so, I can play more with this.
This is more debug output:

[root@smokeping librenms]# curl -H 'X-Auth-Token: 2bd54e1a3bfdebd17dd0a1c05c763800'  http://localhost/api/v0/routing/bgp/cbgp?hostname=10
{
    "status": "error",
    "message": "BGP counters does not exist"

Other thing I can mention is than aflter analize discover output I founded that avertised and received prefix information is available:

SNMP['/usr/bin/snmpbulkwalk' '-v2c' '-c' 'COMMUNITY' '-OQUs' '-m' 'HUAWEI-BGP-VPN-MIB' '-M' '/opt/librenms/mibs:/opt/librenms/mibs/huawei' 'udp:HOSTNAME:161' 'hwBgpPeerRouteTable']
hwBgpPeerPrefixRcvCounter.0.ipv4.unicast.ipv4."*" = 2
hwBgpPeerPrefixRcvCounter.0.ipv4.unicast.ipv4."*" = 14026
hwBgpPeerPrefixRcvCounter.0.ipv4.unicast.ipv4."*" = 14022
hwBgpPeerPrefixRcvCounter.0.ipv4.unicast.ipv4."*" = 1
hwBgpPeerPrefixRcvCounter.0.ipv4.unicast.ipv4."*" = 0
hwBgpPeerPrefixRcvCounter.0.ipv4.unicast.ipv4."*" = 0
hwBgpPeerPrefixRcvCounter.0.ipv4.unicast.ipv4."*" = 0
hwBgpPeerPrefixRcvCounter.0.ipv4.unicast.ipv4."*" = 0
hwBgpPeerPrefixRcvCounter.0.ipv4.unicast.ipv4."*" = 151152
hwBgpPeerPrefixRcvCounter.0.ipv4.unicast.ipv4."*" = 150922
hwBgpPeerPrefixRcvCounter.0.ipv4.unicast.ipv4."*" = 150003
hwBgpPeerPrefixRcvCounter.0.ipv4.unicast.ipv4."*" = 150663
hwBgpPeerPrefixRcvCounter.0.ipv4.unicast.ipv4."*" = 849776
hwBgpPeerPrefixRcvCounter.0.ipv4.unicast.ipv4."*" = 13000
hwBgpPeerPrefixRcvCounter.0.ipv4.unicast.ipv4."*" = 13000
hwBgpPeerPrefixRcvCounter.0.ipv4.unicast.ipv4."*" = 827066
hwBgpPeerPrefixRcvCounter.0.ipv6.unicast.ipv6."20:01:12:f8:00:00:00:00:00:00:00:00:00:00:02:52" = 0
hwBgpPeerPrefixRcvCounter.0.ipv6.unicast.ipv6."20:01:12:f8:00:00:00:00:00:00:00:00:00:00:02:53" = 0
hwBgpPeerPrefixRcvCounter.0.ipv6.unicast.ipv6."20:01:12:f8:00:00:00:00:00:00:00:00:00:00:02:54" = 0
hwBgpPeerPrefixRcvCounter.0.ipv6.unicast.ipv6."20:01:12:f8:00:00:00:00:00:00:00:00:02:23:02:53" = 0
hwBgpPeerPrefixRcvCounter.0.ipv6.unicast.ipv6."20:01:12:f8:00:00:00:00:00:00:00:00:02:23:02:54" = 0
hwBgpPeerPrefixActiveCounter.0.ipv4.unicast.ipv4."*" = 2
hwBgpPeerPrefixActiveCounter.0.ipv4.unicast.ipv4."*" = 1010
hwBgpPeerPrefixActiveCounter.0.ipv4.unicast.ipv4."*" = 9
hwBgpPeerPrefixActiveCounter.0.ipv4.unicast.ipv4."*" = 1
hwBgpPeerPrefixActiveCounter.0.ipv4.unicast.ipv4."*" = 0
hwBgpPeerPrefixActiveCounter.0.ipv4.unicast.ipv4."*" = 0
hwBgpPeerPrefixActiveCounter.0.ipv4.unicast.ipv4."*" = 0
hwBgpPeerPrefixActiveCounter.0.ipv4.unicast.ipv4."*" = 0
hwBgpPeerPrefixActiveCounter.0.ipv4.unicast.ipv4."*" = 1542
hwBgpPeerPrefixActiveCounter.0.ipv4.unicast.ipv4."*" = 46
hwBgpPeerPrefixActiveCounter.0.ipv4.unicast.ipv4."*" = 116928
hwBgpPeerPrefixActiveCounter.0.ipv4.unicast.ipv4."*" = 1
hwBgpPeerPrefixActiveCounter.0.ipv4.unicast.ipv4."*" = 438019
hwBgpPeerPrefixActiveCounter.0.ipv4.unicast.ipv4."*" = 13000
hwBgpPeerPrefixActiveCounter.0.ipv4.unicast.ipv4."*" = 0
hwBgpPeerPrefixActiveCounter.0.ipv4.unicast.ipv4."*" = 280171
hwBgpPeerPrefixActiveCounter.0.ipv6.unicast.ipv6."20:01:12:f8:00:00:00:00:00:00:00:00:00:00:02:52" = 0
hwBgpPeerPrefixActiveCounter.0.ipv6.unicast.ipv6."20:01:12:f8:00:00:00:00:00:00:00:00:00:00:02:53" = 0
hwBgpPeerPrefixActiveCounter.0.ipv6.unicast.ipv6."20:01:12:f8:00:00:00:00:00:00:00:00:00:00:02:54" = 0
hwBgpPeerPrefixActiveCounter.0.ipv6.unicast.ipv6."20:01:12:f8:00:00:00:00:00:00:00:00:02:23:02:53" = 0
hwBgpPeerPrefixActiveCounter.0.ipv6.unicast.ipv6."20:01:12:f8:00:00:00:00:00:00:00:00:02:23:02:54" = 0

I can post more info for debuggin if needed.
Regards.

Hello

In order to see if it works, you should check in the WebUI, not in API. So in the WebUI, do you see the prefixes or not ?

If not, during the discovery, after the SNMPWALK details you found, do you see any debug details that would show that prefixes were added to DB ?

Bye

@Dear Pipo:
From the ui , I got:
Draw error , on prefix and nan on ipv4unicast.
After a little investigation on the mysql table , I can confirm that bgpPeers_cbgp is empty.
And finally , after analize the discovery.php output I can see:
The corresponding mysql inserts statements per bgp peer:

SQL[INSERT IGNORE INTO bgpPeers_cbgp (device_id,bgpPeerIdentifier,afi,safi,context_name,AcceptedPrefixes,DeniedPrefixes,PrefixAdminLimit,PrefixThreshold,PrefixClearThreshold,AdvertisedPrefixes,SuppressedPrefixes,WithdrawnPrefixes,AcceptedPrefixes_delta,AcceptedPrefixes_prev,DeniedPrefixes_delta,DeniedPrefixes_prev,AdvertisedPrefixes_delta,AdvertisedPrefixes_prev,SuppressedPrefixes_delta,SuppressedPrefixes_prev,WithdrawnPrefixes_delta,WithdrawnPrefixes_prev) VALUES (:device_id,:bgpPeerIdentifier,:afi,:safi,:context_name,:AcceptedPrefixes,:DeniedPrefixes,:PrefixAdminLimit,:PrefixThreshold,:PrefixClearThreshold,:AdvertisedPrefixes,:SuppressedPrefixes,:WithdrawnPrefixes,:AcceptedPrefixes_delta,:AcceptedPrefixes_prev,:DeniedPrefixes_delta,:DeniedPrefixes_prev,:AdvertisedPrefixes_delta,:AdvertisedPrefixes_prev,:SuppressedPrefixes_delta,:SuppressedPrefixes_prev,:WithdrawnPrefixes_delta,:WithdrawnPrefixes_prev) {"device_id":47,"bgpPeerIdentifier":"204.199.0.169","afi":"ipv4","safi":"unicast","context_name":"","AcceptedPrefixes":0,"DeniedPrefixes":0,"PrefixAdminLimit":0,"PrefixThreshold":0,"PrefixClearThreshold":0,"AdvertisedPrefixes":0,"SuppressedPrefixes":0,"WithdrawnPrefixes":0,"AcceptedPrefixes_delta":0,"AcceptedPrefixes_prev":0,"DeniedPrefixes_delta":0,"DeniedPrefixes_prev":0,"AdvertisedPrefixes_delta":0,"AdvertisedPrefixes_prev":0,"SuppressedPrefixes_delta":0,"SuppressedPrefixes_prev":0,"WithdrawnPrefixes_delta":0,"WithdrawnPrefixes_prev":0} 1.4ms]

And … at the end:
A delete for every insert …

SQL[DELETE FROM bgpPeers_cbgpWHEREdevice_id=? AND bgpPeerIdentifier=? AND context_name=? AND afi=? AND safi=? [47,"204.199.0.169","","ipv4","unicast"] 0.92ms]

I think … here could be the problem … why is it deleting all rows ?
Thanks.

OK, good news the code see the peers, and there is now a condition that is probably mismatched.
Do you have the VRF module enabled ? If not that might be a reason if you use VPN Instances and if this peer is precisely in a VPN Instance

Do you have internet routes on this device ? If no, you could capture the SNMP data of your device and I would debug it on my dev machine. If you have them, impossible to capture the complete SNMP data, so you’ll have to debug the mismatched condition that does the delete.

Delete occurs in includes/discovery/bgp-peers/vrp.inc.php , line 138, and 154.

Have some feedback for you:
VRF module is enabled (from gui) globaly and in the device.
My peers are not at any vrf , this is the default vrf in my router:

[~HUAWEI]display ip vpn-instance interface
 Total VPN-Instances configured      : 2
 Total IPv4 VPN-Instances configured : 2
 Total IPv6 VPN-Instances configured : 1

 VPN-Instance Name and ID : __LOCAL_OAM_VPN__, 1
  Interface Number : 1
  Interface list : GigabitEthernet0/0/0

 VPN-Instance Name and ID : __dcn_vpn__, 2
  Interface Number : 1
  Interface list : LoopBack1023

About capture ;
I will capture traffic produced by /discovery.php against my router and then send to you.
where should I send capture file ?

About delete occurs ; I tryed commenting out the lines:

$af_query = 'SELECT bgpPeerIdentifier, afi, safi FROM bgpPeers_cbgp WHERE `device_id`=? AND bgpPeerIdentifier=?';
foreach (dbFetchRows($af_query, [$device['device_id'], $peer['ip']]) as $entry) {
    $afi = $entry['afi'];
    $safi = $entry['safi'];
    $vrfName = $entry['context_name'];
    if (! exist($bgpPeersCache[$vrfName]) ||
            ! exist($bgpPeersCache[$vrfName][$entry['bgpPeerIdentifier']]) ||
            $bgpPeersCache[$vrfName][$entry['bgpPeerIdentifier']][$entry['afi']] != $afi ||
            $bgpPeersCache[$vrfName][$entry['bgpPeerIdentifier']][$entry['safi']] != $safi) {
      #  dbDelete(
      #      'bgpPeers_cbgp',
      #      '`device_id`=? AND `bgpPeerIdentifier`=? AND context_name=? AND afi=? AND safi=?',
      #      [$device['device_id'], $address, $vrfName, $afi, $safi]
      #  );
    }
}

but , still have my table bgpPeers_cbgp empty

btw:
Max number of routes allowed for discovery does anything to do with this ?

Regards.
Leandro

Dear pipo , I have snmp capture available, please let me know how to send to you.
Leandro

This topic was automatically closed 186 days after the last reply. New replies are no longer allowed.