OPERATIONAL DEFECT DATABASE
...
...
snmpwalk aborts when performing a snmpwalk on CISCO-BGP4-MIB, when any bgp peer is configured with both VPNv4 Unicast AF(afi=1, safi=128), IPv6 Unicast AF (afi=2, safi=1) and/or IPv6 Multicast AF(afi=2, safi=2). Snmpwalk on the following tables are affected and will not be queried completely and aborts when querying VPNv4 unicast AF of any peer with above mentioned configuration: - cbgpPeerAddrFamilyTable - cbgpPeerAddrFamilyPrefixTable - cbgpPeer2AddrFamilyTable - cbgpPeer2AddrFamilyPrefixTable This issue will abort snmpwalk on cbgpPeer (1.3.6.1.4.1.9.9.187.1.2) or any oid tree that includes these tables. Example: .1.3.6.1.4.1.9.9.187.1.2.7.1.3.1.4.19.0.101.6.2.1 = IPv6 Unicast .1.3.6.1.4.1.9.9.187.1.2.7.1.3.1.4.19.0.101.6.1.128 = VPNv4 Unicast
Occurs when any bgp peer is configured with both VPNv4 Unicast AF(afi=1, safi=128), IPv6 Unicast AF (afi=2, safi=1) and/or IPv6 Multicast AF(afi=2, safi=2)
Since this issue breaks the snmpwalk to cbgpPeer and the other oid trees which queries the tables in CISCO-BGP4-MIB, snmpwalks can work only with oid trees which do not include CISCO-BGP4-MIB, under this configuration/scenario without aborting. The CISCO-BGP4-MIB tables can be queried separately to get the information from the unaffected tables. Further, snmpget is not affected by this issue and will provide the correct outputs but can only be used to query specific oids.
Snmpwalk oids have to be queried incrementally, but in this case, IPv6 unicast and IPv6 multicast AFs are sent queries before VPNv4 unicast AF which has a lower oid value, this aborts the snmpwalk query.
Click on a version to see all relevant bugs
Cisco Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.
