Description

SNMP Walk might fail for the OID ipCidrRouteDest  by reporting "Request failed: OID not increasing"

 

user@router> show snmp mib walk ipCidrRouteDest 

ipCidrRouteDest.0.0.0.0.0.0.0.0.0.23.203.153.28 = 0.0.0.0

ipCidrRouteDest.10.0.0.0.255.255.255.0.0.0.0.0.0 = 10.0.0.0

ipCidrRouteDest.10.0.4.0.255.255.255.0.0.0.0.0.0 = 10.0.4.0

ipCidrRouteDest.10.0.5.0.255.255.255.0.0.0.0.0.0 = 10.0.5.0

ipCidrRouteDest.10.0.6.0.255.255.255.0.0.0.0.0.0 = 10.0.6.0

...

...

ipCidrRouteDest.10.17.100.0.255.255.255.0.0.10.203.153.28 = 10.17.100.0

ipCidrRouteDest.10.17.101.0.255.255.255.255.0.0.0.0.0 = 10.17.101.0

Request failed: OID not increasing: ipCidrRouteDest.10.17.101.0.255.255.255.255.0.0.0.0.0 >= ipCidrRouteDest.10.17.101.0.255.255.255.255.0.0.0.0.0 <<<<<<

 

Symptoms

SNMP Walk might fail for the OID ipCidrRouteDest  by reporting "Request failed: OID not increasing"

Solution

This is happening because the prefix 10.17.101.0 is having IPV6 address as next-hop address.

While this is a valid route and valid NH, however w.r.t SNMP MIB its not a valid NH. Hence OID increment is failing.

10.17.101.0/32   *[BGP/170] 5w6d 22:06:12, localpref 100, from dead:beef:11:3202::1

          AS path: 65534 I, validation-state: unverified

            to dead:beef:11:3202::1 via ae201.0

          > to dead:beef:11:3203::1 via ae202.0

            to dead:beef:11:3204::1 via ae203.0

            to dead:beef:11:3205::1 via ae204.0

 

As per RFC RFC 4292 'IP Forwarding Table MIB' and Juniper SNMP MIB Explorer:

IpCidrRouteEntry ::= SEQUENCE {




      ipCidrRouteNextHop  IpAddress, <<<<<<<<<




    }




ipCidrRouteNextHop OBJECT-TYPE




  SYNTAX IpAddress <<<<




  ACCESS read-only




  STATUS mandatory




  DESCRIPTION




    "On remote routes, the address of the next sys-




    tem en route; Otherwise, 0.0.0.0."




  ::= { ipCidrRouteEntry 4 }

 

Hence, 'Request failed: OID not increasing:' may occur because ipCidrRouteNextHop can hold a 4 bytes value (an IPv4 address) and not a 16 bytes value (IPv6 address).

As a workaround, from 25.4 onwards, even though its invalid NH w.r.t SNMP, SNMP walk will not quit instead it will continue the walk and report 0.0.0.0 as NH for the IPV4 prefixes with the IPV6 NH.

Modification History

2026-04-15 : Article Created