Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

Syslog message: 'D4P-x/x: FROML tx192 data path stuck'

0

0

Article ID: KB32924 KB Last Updated: 31 Jul 2018Version: 1.0
Summary:

This article explains the meaning of the message, 'D4P-x/x: FROML tx192 data path stuck'.

Symptoms:

This message is seen after OC192 interfaces go down.

Jun 19 23:12:45  router mib2d[1736]: SNMP_TRAP_LINK_DOWN: ifIndex 514, ifAdminStatus up(1), ifOperStatus down(2), ifName as7
Jun 19 23:12:45  router mib2d[1736]: SNMP_TRAP_LINK_DOWN: ifIndex 588, ifAdminStatus up(1), ifOperStatus down(2), ifName so-6/3/0
Jun 19 23:12:45  router mib2d[1736]: SNMP_TRAP_LINK_DOWN: ifIndex 120, ifAdminStatus up(1), ifOperStatus down(2), ifName as7.0
Jun 19 23:12:46  router fpc6 D4P-6/3: FROML tx192 data path stuck
Jun 19 23:12:47  router fpc6 D4P-6/3: FROML tx192 data path stuck
Jun 19 23:12:47  router fpc6 LCHIP(3): 1 new errors in LSIF
Jun 19 23:12:48  router fpc6 D4P-6/3: FROML tx192 data path stuck

On OC48 interfaces, a similar message 'D4P-x/x: FROML tx48 data path stuck' is logged.

Cause:

This log can be seen if garbage data is tranferred to sonet framer D4P chip on PIC in some transient state. During transient state or initialization, some garbage data flowed into D4P froml (egress) FIFO.

Garbage data is small in size, and EOP info is not set. This garbage data consumes some D4P buffer. D4P does not drain this data until more data comes into the buffer, but this OC48/192 port is unused and no more data will come into D4P. Eventually, garbage data resides in D4P for a long time. Periodic health check reports this status as data-path stuck.

This log will not be seen in OC48/192 ports which are in use. D4P of used sonet interface will have successive packet, and those successive data triggers D4P to drain data from it's buffer. Then the garbage data will be flushed out.

Solution:

If the log stops after interfaces come online, it can safely be ignored.
 
D4P buffer will be purged if data-path stuck is reported five times because data-path stuck can be reported five times at most.
This is considered as normal status of the initialization period.

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search