Description

In MX and PTX Series routers, the Simple Network Management Protocol (SNMP) may run into a defect where snmpwalk dot3adAggPortPartnerOperPort or dot3adAggPortAttachedAggID returns no output.

This article suggests a workaround and indicates the Junos OS releases in which the issue has been resolved.

 

Symptoms

snmpwalk dot3adAggPortPartnerOperPort or dot3adAggPortAttachedAggID returns no output as shown in the example below:

Non-Working One 

{MASTER}
lab@router> show snmp mib walk ifDescr | match ae308                     
ifDescr.1227  = ae308
ifDescr.1853  = ae308.3808
ifDescr.1854  = ae308.32767
 
{MASTER}
lab@router> show snmp mib walk dot3adAggPortAttachedAggID | match 1227
                           <<<<<<<<<< no output
                        
{MASTER}
lab@router> show lacp interfaces ae308
Aggregated interface: ae308
    LACP state:       Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  Activity
      xe-7/1/5       Actor    No    No   Yes  Yes  Yes   Yes     Fast    Active
      xe-7/1/5     Partner    No    No   Yes  Yes  Yes   Yes     Fast    Active
    LACP protocol:        Receive State  Transmit State          Mux State
      xe-7/1/5                  Current   Fast periodic Collecting distributing

Working One 

{MASTER}
lab@router> show snmp mib walk ifDescr | match ae308
ifDescr.1231  = ae308
ifDescr.1852  = ae308.32767
ifDescr.1853  = ae308.3708
 
{MASTER}
lab@router> show snmp mib walk dot3adAggPortAttachedAggID | match 1231
dot3adAggPortAttachedAggID.1854 = 1231  
dot3adAggPortAttachedAggID.1855 = 1231
 
{MASTER}
lab@router> show lacp interfaces ae308
Feb 20 03:46:10
Aggregated interface: ae308
    LACP state:       Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  Activity
      xe-7/1/5       Actor    No    No   Yes  Yes  Yes   Yes     Fast    Active
      xe-7/1/5     Partner    No    No   Yes  Yes  Yes   Yes     Fast    Active
    LACP protocol:        Receive State  Transmit State          Mux State
      xe-7/1/5                  Current   Fast periodic Collecting distributing

 

Solution

Lag children interfaces are learned via a stats request sent to the parent ae interface because the stats response for a lag parent interface contains stats for all individual lag children interfaces. This stats response helps mib2d to detect all the children interfaces associated with a particular lag ae port.

In this case (for example, router reboot), the FPC might be slow to populate all the children, resulting in the initial stats request timing out in the kernel -> PFC layer. Hence, mib2d receives an empty stats response and is not able to learn the lag children interfaces. This state continues to exist until a change happens on the ae interface, which triggers another request to refresh/repopulate the lag children interfaces or until mib2d is restarted, which will also trigger a stats request for relearning the ae parent interface.

 

As per PR1220988 , the issue has been resolved in Junos OS releases ​16.1R3-S4, 16.1R4-S3, 16.1R5, 16.2R3, and 17.1R1.

Meanwhile, a workaround is to restart mib2d with the following command: 

restart mib-process​