Hello Merci pour toutes ces infos, mais j'avais déjà effectivement desactivé la MIB par défaut pour passer sur la MIB Juniper. Ma question était plutot, est-ce que tous les constructeurs ont intégrés ça dans une MIB propriétaire, ne respecte pas la RFC sur la MIB générique (ie, ont remplacé Integer32 par Unsigned32), ou bien s'appuie sur la MIB BGP4V2-MIB. En clair, qu'elle est (si elle existe) la solution la plus générique possible pour intégrer le max d'équipements (je n'ai que du Juniper et Fortinet sous la main, pas de Cisco, etc.)
A+ Le mer. 4 sept. 2019 à 02:32, Olivier Benghozi <olivier.bengh...@wifirst.fr> a écrit : > Tu vois bien que cet oid est défini (bêtement) dans la MIB standard > BGP4-MIB comme Integer32, cad un entier signé sur 32 bits. > Tu n'as donc aucune chance d'y voir une valeur positive supérieure à > 2^31-1 (2147483647) autrement que comme valeur négative. > C'est donc sans aucun rapport avec le constructeur. > > Bien sûr tu pourrais remplacer Integer32 par Unsigned32 pour cet oid > bgpPeerRemoteAs dans ton fichier BGP4-MIB. > > Mais note que dans BGP4V2-MIB il existe déjà à la place un > bgp4V2PeerRemoteAs de type InetAutonomousSystemNumber défini comme > Unsigned32 dans INET-ADDRESS-MIB. > Et qu'il y a l'équivalent dans BGP4-V2-MIB-JUNIPER (jnxBgpM2PeerRemoteAs), > pris en charge par ailleurs par observium. > > Donc encore plus incroyable: tu désactives la MIB BGP4-MIB pour ce routeur > dans observium, ou tu fais une view pour exclure les oid BGP4-MIB dans ton > routeur. > > Bref, le bug est dans la MIB d'origine (des entiers signés pour des > valeurs sans signe, quelle bonne idée). > > > > Le 4 sept. 2019 à 01:34, Guillaume Barrot <guillaume.bar...@gmail.com> > a écrit : > > > > Sur un équipement dont je tairai l'équipementier, par respect pour son > > honneur technique, je fais face à ce magnifique bug : > > > > Session BGP > > > > Peer AS InPkt OutPkt OutQ Flaps Last > > Up/Dwn State|#Active/Received/Accepted/Damped... > > x.x.x.x *4200000001 *1811 1734 0 0 > 13:12:59 > > Establ > > y.y.y.y *4200000002* 22981 21976 0 0 6d > 23:42:02 > > Establ > > > > et quand on veut remonter ça en SNMP, on obtient : > > > > bgpPeerRemoteAs.198.19.174.9 = *-94967295* > > bgpPeerRemoteAs.198.19.174.11 = *-94967294* > > > > Bref, les plages d'AS privés 32 bit (4200000000 - 4294967294) remontent > en > > SNMP en valeur négative sur la MIB standard. > > > > J'aurai tendance à penser que la limitation vient de la MIB en elle même, > > mais je n'ai pas d'autres fournisseurs sous la main pour valider cette > > théorie. > > Donc si de bonnes ames peuvent regarder sur du Cisco, Juniper, Brocade, > > whatever si ils reproduisent le "bug" je serai intéressé du résultat pour > > savoir ce qu'il va falloir corriger. > > > > Pour info, en Netconf, 0 issue, la valeur 32 bit remonte bien. > > Mais bon Observium / Librenms ne fonctionnent pas en netconf, alors SNMP > > c'est quand même pratique. > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Cordialement, Guillaume BARROT --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
