The fatal clock timing flaw that causes a variety of switches, routers and security appliances to crash and die after about 18 months of service is apparently part of some Juniper products.\n\n\nCisco was the first vendor to post a notice about mortal clock fail earlier this month saying the notice includes some of the company\u2019s most widely deployed products, such as certain models of its Series 4000 Integrated Services Routers, Nexus 9000 Series switches, ASA security devices and Meraki Cloud Managed Switches. Clock components are critical to the synchronization of multiple levels of a given device.\n\n\n+More on Network World: Cisco: Faulty clock part could cause failure in some Nexus switches, ISR routers, ASA security appliances+\n\n\nCisco wrote: \u201cIn some units, we have seen the clock signal component degrade over time. Although the Cisco products with this component are currently performing normally, we expect product failures to increase over the years, beginning after the unit has been in operation for approximately 18 months. Once the component has failed, the system will stop functioning, will not boot, and is not recoverable.\u00a0\n\n\nIn what looks to be a screenshot of a Juniper Technical Service Bulletin posted on Reddit\u2019s Networking subReddit site this week, Juniper is now telling customers a similar story: \u201cAlthough we believe the Juniper products with this component are performing normally as of February 13, 2017 the [listed] Juniper products could after the product has been in operation for at least 18 months begin to exhibit symptoms such as the inability to boot, or cease to operate. Recovery in the field is not possible. Juniper product with this supplier\u2019s component were first placed into service on January 2016. Jupiter is working with the component supplier to implement a remediation. In addition, Juniper\u2019s spare parts depots will be purged and updated with remediated products.\u201d\n\n\nThe products in the warning comprise 13 Juniper switches, routers and other products including the MPC7E 10G, MPC7E (multi rate), MX2K-MPC8E, EX 920 Ethernet switches and PTX3000 integrated photonic line card.\n\n\nFor its part Juniper Networks said in a statement today that it \u201cis aware\u00a0of an issue\u00a0related to a component manufactured by a supplier which impacts a limited set of our product line.\u00a0We are currently working directly with any impacted customers on a swift solution.\u201d\n\n\n+More on Network World: Cisco, competitors infiltrate Avaya customer doubts+\n\n\nNeither Cisco nor Juniper have been willing to identify the killer clock signaling component but the problems coincide with difficulties described by Intel on its Atom C2000 chip that is used by a number of hardware makers.\n\n\nIt has been widely reported that problems with Atom hurt Intel\u2019s 2016 Q4 earnings. CFO Robert Swan is quoted in an earnings call transcript on the Seeking Alpha website as saying: \u201cBut secondly, and a little bit more significant, we were observing a product quality issue in the fourth quarter with slightly higher expected failure rates under certain use and time constraints, and we established a reserve to deal with that. We think we have it relatively well-bounded with a minor design fix that we're working with our clients to resolve. So, those two one-timers in the fourth quarter weighed on DCG margins, and we do not expect that to continue in 2017.\u201d\n\n\nThe IDG News Service recently wrote of the Atom\u2019s troubles, reporting in January that Intel added an erratum to the Atom C2000 documentation stating systems with the chip "may experience [an]\u00a0inability to boot or may cease operation."\n\n\nThe chip is the last among Intel's line of short-lived low-power Atom chips for servers. It was used in microservers\u00a0but also networking equipment from companies like Cisco, which has issued an advisory about a product defect related to a component degrading clock signals over time. A clock signal degrade hurts the ability of the chip to carry out tasks. Intel is trying to fix the issue\u00a0but declined to comment on when it'll deliver an update, the IDG story stated.\n\n\n"There's a board level workaround that we are sharing with customers now,"\u00a0an Intel spokesman said in an email to the IDG News Service\u00a0"Additionally, we are implementing and validating a minor silicon fix in a new product [update]."\n\n\n+More on Network World: Juniper founder, CTO Sindhu cuts role to focus on startup+\n\n\nWhile the Intel technology may or may not be at the heart of the problem, so far only Juniper and Cisco have released notice of the issue. Contacted by Network World, a number of vendors (including Avaya and Arista) have confirmed their products don\u2019t use the faulty product.\n\n\nFor example, Big Switch said it provides SDN-based offerings (Big Cloud Fabric and Big Monitoring Fabric), which are deployed with third party open networking (whitebox \/ britebox) switch hardware. \u201cAs soon as we became aware of the \u2018faulty clock hardware\u2019 issue, our team investigated it and our initial analysis indicated that it is purely hardware-related and no Big Switch software is affected. We will continue to monitor the situation closely with our open networking switch partners.\u201d\n\n\nBrocade said it does not use the affected control processor in any of its products. \u201cWe have not experienced any related failures, nor have we been contacted by any of our suppliers regarding an issue with their components or degradation of their clock signals.\u201d\n\n\nHPE and Dell have not responded to questions around the clock technology, though both are rumored to use it.\u00a0 Extreme declined to comment on the situation.\n\n\nFrom Cisco\u2019s site, here are a few of the FAQs about the problem. [A full version is available here].