Add route lookup ingress drop counter to interface and subinterface counters

[ostromart]

This change introduces a new operational state counter in-route-lookup-drop under common interface counters (/interfaces/interface/state/counters/in-route-lookup-drop and /interfaces/interface/subinterfaces/subinterface/state/counters/in-route-lookup-drop) to track inbound packets dropped during routing table lookup. This could be due to no matching route entry in the forwarding table (LPM miss) or matching an explicit drop route.
The version has been bumped to 3.11.0 in openconfig-interfaces.yang.

Change-Id: I2f1a6c4290871e86b3e94a815a1e2f89104b28cd

Change Scope

• Description: This PR introduces in-route-lookup-drop to openconfig-interfaces.yang (under interface-common-counters-state) to count inbound packets discarded on a routed interface or subinterface when a routing table lookup fails to find a matching route entry (LPM miss) or encounters an explicit drop/blackhole route.
• Backwards Compatibility: This change is fully backward compatible as it only adds a new read-only operational state leaf counter to the existing interface-common-counters-state grouping.

Use case

In routed fabrics (such as spine-leaf or multi-tenant networks), silent packet discards due to routing table misses or blackhole routes are difficult to isolate using generic discard counters (in-discards). Providing an explicit counter for route lookup drops (in-route-lookup-drop) enables network operations and automated failure pinpointing tools to immediately identify routing blackholes, unassigned IP prefix drops, or route table sync issues at both interface and subinterface granularity.

Platform Implementations

• SAI Specification: Defines explicit debug drop reasons for LPM miss and LPM drops: SAI_IN_DROP_REASON_LPM_MISS / SAI_IN_DROP_REASON_LPM_DROP (SAI Debug Counters Proposal).
• Google Switch Telemetry: Google production switches export granular ingress routing lookup drop telemetry via UMF and SAI debug counters.
• Cisco IOS Reference P202, Cisco YANG model, in-no-routes)** Exposes routing drop statistics (show ip traffic no route discards).
• SONiC / Broadcom Telemetry: Pipeline counters support tracking SWITCH_INGRESS_DROPS with drop reason SAI_IN_DROP_REASON_LPM4_MISS and SAI_IN_DROP_REASON_LPM6_MISS.

Tree View

 module: openconfig-interfaces
   +--rw interfaces
      +--rw interface* [name]
         ...
         +--ro state
         |  +--ro counters
         |     +--ro out-discards?            oc-yang:counter64
         |     +--ro out-errors?              oc-yang:counter64
         |     +--ro last-clear?              oc-types:timeticks64
+        |     +--ro in-route-lookup-drop?    oc-yang:counter64
         ...
         +--rw subinterfaces
            +--rw subinterface* [index]
               ...
               +--ro state
                  +--ro counters
                     +--ro out-discards?           oc-yang:counter64
                     +--ro out-errors?             oc-yang:counter64
                     +--ro last-clear?             oc-types:timeticks64
+                    +--ro in-route-lookup-drop?   oc-yang:counter64

[gemini-code-assist]

Code Review

This pull request updates the openconfig-interfaces YANG module to version 3.11.0, introducing a new 'in-route-lookup-drop' counter leaf. The review feedback highlights two main issues: first, a revision entry for version 3.9.0 is added but the corresponding 'ingress low-TTL discard counter' is missing from the code changes; second, the description for the 3.11.0 revision should be updated to clarify that the new counter applies to both interface and subinterface counters.

[ostromart]

This PR is intended to merge after #1528 and the version reflects that.

[navaneethyv]

OC operator review:

linked PR Chain : #1527
#1528
#1529

Waiting for any further comments.

[navaneethyv]

OC operators review August 11th:
Waiting on PR and any further comments

[earies]

A few general comments/doubts:

• I'm not sure about the references being entirely correct here as show ip traffic commands have tended to be system wide, possible punt path, etc.... not at an interface or subinterface granularity - @rgwilton @romeyod @jsterne to confirm from their end - I'm not seeing show ip traffic as an actual command for EOS so also not sure if references are LLM assisted
• From a Juniper/HPE ASIC perspective, this is not tracked per interface but rather collective per ASIC - this could rather be represented under integrated-circuit counters
• RE: SAI references are imo not necessarily references to ASIC side implementation so I'd be curious if this really fits the criteria of ultimately being neutral or the likely case of implementations deviating and conveying as best as possible via other means

[rgwilton]

To add to Ebben's comment. XR doesn't track no route drops on a per interface basis (e.g., the referenced show ip traffic command has no per interface filter), so please can you correct the references in the PR because otherwise they are misleading to those reviewing or considering the PR.

We do have per device and per node level versions of these counters, and we would also be able to provide them on a per ASIC basis, but not at a higher granularity today.

[navaneethyv]

OC operator review Sept1 2026.

@ostromart requesting you to share your responses so that we can move ahead

[ostromart]

• Cisco IOS IP Application Services Command Reference P202: show ip traffic interface ethernet 0/0, output shows no route.
• SAI provides an ASIC/vendor agnostic set of APIs and while it does not strictly point to a specific ASIC implementation, major industry vendors are part of the SAI community or working groups where and at least two ASIC vendors sign off on any change to the SAI specification. SONiC test suites are used to ensure that all ASICs adhere to the standard.

[navaneethyv]

OC operators review September 8th.

@ostromart has updated the Cisco reference, and there are some notes w.r.t NVIDIA implementation which he will add to the PR. along with the description update to the new references.

@rgwilton / @earies kindly take a look. Regarding SAI and its implications to new open config paths that are not yet supported, we will take it up in the community meeting and decide the way forward.

[ostromart]

Regarding NVIDIA example, WJH only logs non-zero counters, so to demonstrate that the Non-routable packet event populates the port columns it's necessary to set up and run an experiment on a lab switch - we only have access to prod Nvidia switches.