<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Cisco on Netdata</title><link>https://www.netdata.cloud/tags/cisco/</link><description>Recent content in Cisco on Netdata</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://www.netdata.cloud/tags/cisco/index.xml" rel="self" type="application/rss+xml"/><item><title>Interface discards with low utilization: diagnosing ifInDiscards/ifOutDiscards</title><link>https://www.netdata.cloud/guides/network/network-interface-discards/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/network/network-interface-discards/</guid><description>&lt;p&gt;ifOutDiscards is climbing on a critical uplink. Utilization sits at 35%. No CRC errors, no input errors, no physical-layer alarms. The link is up and passing traffic, but something is silently dropping packets, and your averaged utilization metrics are not telling you why.&lt;/p&gt;&#10;&lt;p&gt;The gap between what the counters show and what the silicon is doing comes down to two things: the averaging window on utilization, and the fact that discards happen at buffer-queue granularity, not at link-rate granularity.&lt;/p&gt;</description></item><item><title>SD-WAN tunnel up but degraded: when the control plane lies</title><link>https://www.netdata.cloud/guides/network/network-sdwan-data-plane-degraded/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/network/network-sdwan-data-plane-degraded/</guid><description>&lt;p&gt;The orchestrator shows your SD-WAN tunnel as UP. Control connections to vSmart or vBond are healthy. OMP sessions are Established. But users at the far end report slow applications, dropped voice calls, or timeouts.&lt;/p&gt;&#10;&lt;p&gt;The control plane reports a healthy tunnel while the data plane is degraded with packet loss, latency spikes, or silent traffic drops. Interface counters show UP/UP because the degradation is on the underlay path or inside the encapsulated data plane, not on the local interface.&lt;/p&gt;</description></item><item><title>Trap and syslog flood from link flaps: surviving the storm</title><link>https://www.netdata.cloud/guides/network/network-trap-syslog-flood/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/network/network-trap-syslog-flood/</guid><description>&lt;p&gt;A single bad SFP starts flapping. Within seconds, your trap receiver is processing hundreds of linkDown/linkUp pairs per second, your syslog pipeline is drowning in LINK-3-UPDOWN messages, and STP topology change notifications are cascading across the L2 domain. The kernel socket buffer on UDP 162 overflows, and the root-cause hardware alarm is as likely to be dropped as any other datagram in the flood.&lt;/p&gt;&#10;&lt;p&gt;The core problem is architectural. Traps and syslog arrive over UDP, a lossy transport with no retransmission. When a receiver socket buffer fills, the kernel silently discards datagrams. There is no per-source accounting. You cannot tell which device&amp;rsquo;s traps were dropped, only that some were. During a flood, any datagram arriving during the overflow window can vanish, including the one that matters most.&lt;/p&gt;</description></item></channel></rss>