<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>ARP / IP Neighbor Topology on Netdata</title><link>https://www.netdata.cloud/tags/arp-ip-neighbor-topology/</link><description>Recent content in ARP / IP Neighbor Topology on Netdata</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 22 Aug 2026 05:09:03 +0300</lastBuildDate><atom:link href="https://www.netdata.cloud/tags/arp-ip-neighbor-topology/index.xml" rel="self" type="application/rss+xml"/><item><title>Network Topology Mapping Explained</title><link>https://www.netdata.cloud/academy/network-topology-mapping/</link><pubDate>Wed, 24 Jun 2026 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/academy/network-topology-mapping/</guid><description>&lt;p&gt;Network topology mapping is the process of discovering and visualizing how devices, endpoints, and services connect across a network. It captures both physical (Layer 2) relationships - which switch port links to which device - and logical (Layer 3) relationships - how subnets, routes, and autonomous systems reach each other. A topology map can range from a hand-drawn diagram to a live, continuously updated graph built from protocol data such as LLDP, CDP, ARP, FDB, OSPF, and BGP.&lt;/p&gt;</description></item><item><title>ARP cache staleness: when IP-to-MAC mapping goes bad</title><link>https://www.netdata.cloud/guides/network/network-arp-cache-staleness/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/network/network-arp-cache-staleness/</guid><description>&lt;p&gt;Hosts on the same subnet stop reaching each other after a VM live-migrates, a container gets rescheduled, or a firewall fails over. ICMP works from some hosts but not others. TCP sessions hang or reset. The data plane is healthy, but the ARP cache on one or more hosts holds a stale IP-to-MAC mapping.&lt;/p&gt;&#10;&lt;p&gt;ARP cache staleness is the gap between when a MAC address changes and when every interested host learns about the change. On Linux, this gap is governed by the neighbor (NUD) state machine and its timing parameters. On Windows Vista and later, the neighbor cache follows the same RFC 4861 model. Both platforms default to roughly the same reachable time window: about 15 to 45 seconds before an entry transitions to a stale state, followed by a probe sequence that adds several more seconds before resolution or eviction.&lt;/p&gt;</description></item><item><title>Stale FDB/MAC tables: why endpoint location is wrong</title><link>https://www.netdata.cloud/guides/network/network-fdb-mac-staleness/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/network/network-fdb-mac-staleness/</guid><description>&lt;p&gt;Your topology platform says endpoint &lt;code&gt;aa:bb:cc:dd:ee:ff&lt;/code&gt; is on switch port &lt;code&gt;Gi1/0/24&lt;/code&gt;. Your security team sends someone to that port. The endpoint is not there. It moved hours ago, or it went offline, or it vMotioned to a different host. The FDB entry was stale and the platform presented it as current.&lt;/p&gt;&#10;&lt;p&gt;The Forwarding Database (FDB), also called the MAC address table or CAM table, maps MAC addresses to switch ports. Topology inference engines use FDB data, cross-referenced with ARP tables and CDP/LLDP neighbor data, to deduce where endpoints are physically connected. The inference is probabilistic. It degrades as input data freshness degrades.&lt;/p&gt;</description></item></channel></rss>