What is barking traffic and why it matters
Barking traffic describes repetitive, non‑progressing network control messages that repeat the same information without advancing a connection or flow. In everyday terms, it is the network equivalent of a stuck alarm: a message or signal that keeps sounding, consumes bandwidth, and can mask legitimate communication. This explainer covers how barking traffic appears in common protocols, the performance and reliability impacts you can measure, proven detection techniques, and practical mitigations you can apply in enterprise and data‑center environments.
Typical sources and protocol contexts
Barking traffic most often originates from control‑plane exchanges that should transition to stable data‑plane behavior but instead remain in a repeating signaling state. Common sources include routing protocol adjacencies that cannot reach a stable neighbor state, session‑establishment handshakes that retransmit without completion, and keep‑alive mechanisms stuck in a loop. Because these behaviors repeat at fixed intervals, they can persist for long periods if not detected and remediated.
OSPF and adjacency storms
In link‑state routing, an OSPF adjacency storm can occur when devices repeatedly lose and renegotiate neighbor relationships. This generates a high volume of Hello and Database Description packets that look like control traffic yet do not forward user data. Indicators include frequent adjacency changes, incrementing router‑LSA sequences without topology stability, and control‑plane load spikes on impacted interfaces.
TCP handshake retransmissions and keep‑alive loops
Transmission Control Protocol handshakes that retransmit SYN segments without completing the three‑way handshake can produce sustained barking traffic. Misconfigured TCP keep‑alive timers or middlebox interference such as asymmetric security policies can force endpoints to repeat keep‑alive probes that never advance the connection state. The result is a persistent low‑rate stream that consumes session resources while delivering no application payload.
BGP session flapping and route‑updates loops
Border Gateway Protocol sessions that flap between idle and connect states repeatedly advertise and withdraw the same prefixes. Each transition can trigger UPDATE bursts that, while individually small, accumulate significant overhead. Common catalysts include unstable IGP reachability, mismatched timers, and route‑policy or filtering rules that repeatedly add and remove next‑hop reachability.
Measurable impacts on performance and reliability
Although barking traffic is not always volumetric, it can degrade key performance indicators by occupying control‑plane and shared resources. Repeating signaling consumes CPU and memory on routers and firewalls, delays legitimate control processing, and may increase convergence time after actual failures. On shared segments, the extra chatter can raise latency jitter and reduce effective throughput for data flows that compete for queue space.
Indicators and baselines to watch
Establish baseline metrics for control‑plane and session metrics so deviations are obvious. Useful indicators include the rate of protocol packets per interface, session retransmit counts, adjacency renegotiation frequency, and control‑plane CPU utilization. Comparing current values to a stable historical window reveals patterns that resemble barking behavior.
| Attribute | Verified Detail | Source Type |
|---|---|---|
| OSPF Hello interval mismatch | Adjacent routers configured with different Hello timers cause repeated adjacency resets | Protocol specification and vendor guidance |
| TCP retransmit rate above baseline | Sustained retransmissions without new data indicate incomplete handshakes or keep‑alive storms | Flow and device counters |
| BGP UPDATE rate spikes with stable NLRI | Frequent route withdrawals and re‑advertises from flapping peers | Route server logs and RIB updates |
| Control‑plane CPU percent consistently high | Elevated utilization on route processors tied to protocol input queues | Device performance metrics |
| Keep‑alive probe frequency and loss | Frequent keep‑alives retransmitted across an unstable path | Session diagnostics and packet captures |
Practical detection techniques
Detecting barking traffic relies on correlating control‑plane statistics with active probing and packet inspection. Start by enabling protocol specific counters and logging on routers, switches, and firewalls. Use NetFlow, sFlow, or IPFIX to observe session and flow behavior at scale, and pair these with control‑plane policing and access lists to limit unnecessary flooding. On endpoints, TCP and application diagnostics can expose incomplete handshakes and excessive retransmissions.
Stepwise detection workflow
- Collect baseline protocol and session metrics for at least one stable business cycle (24–72 hours).
- Set alerts on protocol packet rates, retransmit counters, and adjacency renegotiation frequency.
- Correlate spikes with control‑plane CPU and queue depths to confirm resource pressure.
- Use targeted packet captures on suspected segments to verify message patterns and endpoints.
- Document repeat offenders and map them to physical or logical dependencies.
Common root causes and failure modes
Understanding root causes helps you address barking traffic at the source rather than treating symptoms. In many cases, the issue stems from timing mismatches, misconfigured timers, or unstable underlay connectivity. In other cases, policy or filtering rules repeatedly add and remove routes or sessions, driving repeated signaling that never stabilizes.
Configuration and timer issues
Timer mismatches are among the most frequent causes. For example, OSPF Hello and Dead intervals must agree on adjacent devices; TCP keep‑alive settings that are too aggressive can produce a steady stream of probes; and BGP hold‑time values that are too low can trigger repeated session reestablishment under minor loss. Each protocol has recommended and validated timer ranges that should be aligned across peers.
Underlay and connectivity problems
A lossy or asymmetric underlay can force protocols to repeat control exchanges. High packet loss, microbursts that exceed egress policers, and path MTU issues that trigger excessive retransmissions can all manifest as barking traffic without obvious application impact. Verify physical links, interface counters, and queuing behavior when control‑plane issues persist despite clean configurations.
Policy, filtering, and load balancer interactions
Security policies, NAT rules, and load balancer health probes can inadvertently cause sessions to flap. If a probe is allowed in one direction but denied in the reverse, endpoints may interpret the loss as a failure and start new connections, generating repeated handshakes. Similarly, route dampening or filtering that repeatedly adds and removes next‑hop reachability can drive BGP UPDATE storms.
Reliable mitigation and remediation steps
Address barking traffic by stabilizing configurations, aligning timers, improving underlay reliability, and applying sensible policy design. Begin with rapid containment to limit impact, then move to root‑cause fixes and long‑term hardening. Use control‑plane protection features to shield devices from excessive protocol input, and enforce input policing on untrusted or edge segments.
Immediate containment actions
- Rate‑limit protocol input on edge interfaces using control‑plane policing to protect CPU.
- Temporarily disable non‑essential features known to cause retransmission storms, such as aggressive keep‑alives, while diagnosing.
- Quarantine flapping peers using manual administrative shutdown or route‑filtering until root cause is resolved.
Configuration and timer remediation
- Align protocol timers (OSPF Hello/Dead, BGP hold‑time and keep‑alive, TCP keep‑alive and idle timeouts) across peers.
- Remove duplicate or conflicting filters, route maps, or NAT rules that cause repeated session creation and teardown.
- Standardize timers on load balancers and health probes to avoid inducing session flaps.
Underlay and monitoring improvements
Improve link reliability and reduce packet loss by addressing physical errors, adjusting QoS for control traffic, and fixing MTU issues. Implement continuous monitoring with thresholds tied to protocol packet rates and session metrics so future deviations are caught early.
When to escalate and involve other teams
Complex environments often require coordination across networking, security, and application teams. Escalate when barking traffic originates from shared services, when underlay issues point to platform networking, or when policy changes span multiple domains. Provide stakeholders with clear evidence—such as control‑plane CPU trends and specific protocol counters—to accelerate diagnosis and resolution.
Key takeaways and best practices
- Barking traffic is repetitive control signaling that does not advance application or connection state; it consumes resources and can mask real issues.
- Common causes include timer mismatches, unstable underlay, session retransmission storms, and policy‑driven session flapping.
- Detect early with protocol counters, flow records, and control‑plane CPU monitoring; correlate with packet captures when needed.
- Mitigate quickly with control‑plane protection and temporary rate limits, then remediate root causes through timer alignment, policy cleanup, and underlay improvements.
- Maintain baselines for protocol and session metrics so deviations are obvious and actionable over time.