Before you read: this is not about making silent hosts louder
The feature Cisco introduced in Catalyst Center 3.2.3 is called Silent Host Discovery, and the name is slightly misleading. Silent hosts are not "made louder." They do not suddenly begin generating traffic. What changes is that the feature is demand-triggered: when transit traffic arrives at the fabric edge destined for an EID that is not present in the local site table, LISP triggers SISF to send a unicast probe to that host rather than simply dropping the packet. That probing is a LISP-level mechanism, not a simple ARP broadcast, and understanding the distinction matters if you want to design around it rather than just tick a box and move on. Critically, if no transit traffic arrives for an unregistered host, no probe is sent: the mechanism is reactive, not a periodic or autonomous sweep.
This article covers why silent endpoints have always been a control-plane blind spot in SD-Access, what the two pre-existing approaches require of your infrastructure, what Catalyst Center 3.2.3 adds, and how to verify registration state without manufacturing test traffic. We are not covering IP Multicast for overlay traffic, Layer 2 Flooding as a general topic, or the broader SD-Access assurance stack. Those are separate subjects.
The core problem: silent hosts and the LISP control plane
In an SD-Access fabric, fabric edge nodes run as LISP xTRs (Ingress and Egress Tunnel Routers). An endpoint's IP address is registered with the Control Plane Node (the LISP Map-Server) only when Switch Integrated Security Features (SISF) creates a binding table entry. That binding is triggered by network activity: an ARP request, a DHCP transaction, or an 802.1X authentication event. When any of those occur, SISF records the endpoint IP and MAC, and the edge node registers that EID (Endpoint Identifier) with the Map-Server.
Endpoints that never initiate traffic produce none of those triggers. A PLC that sits at a static IP address and waits for commands from a SCADA system, an IP camera that only streams when polled, a UPS controller that has not generated an alert in months: none of these creates a SISF binding entry unless something else prompts them. Cisco's Manufacturing Validated Profile identifies the variety of endpoints on manufacturing floors as one of the biggest problems in OT networks, noting that some of these (devices with static IP addresses that may go untouched for years) fall into the category of silent hosts.
The consequence is invisible but serious. A remote fabric edge that needs to reach a silent host sends a Map-Request to the Control Plane Node. If the host has never registered, the Map-Server returns a negative cache entry with the action send-map-request. Traffic is dropped. The CEF forwarding entry for that unregistered EID is set to glean, meaning the ingress fabric edge node (acting as ITR) initiates both a LISP Map-Request and an ARP resolution simultaneously. If the host never responds to ARP, neither path resolves and connectivity fails silently from the perspective of the sender.
Cisco defines silent hosts as endpoints that "respond only when prompted, rather than sending packets at regular intervals … send control packets solely on an on-demand basis." This definition maps directly to OT and infrastructure equipment: PLCs, RTUs, sensors and production stations with static IP addresses that may be untouched for years.
Two approaches before 3.2.3, and why each has limits
Cisco has documented two mechanisms for handling silent hosts in SD-Access. Understanding what each requires of the infrastructure helps frame why the 3.2.3 addition is meaningful.
IP Directed Broadcast
Available from Catalyst Center 1.3 and IOS-XE 17.3 onwards, IP Directed Broadcast is enabled per anycast gateway via a checkbox in Catalyst Center. The mechanism operates across two distinct sub-paths. In the directed broadcast path, a subnet-directed broadcast packet arriving at the fabric border is converted into a subnet broadcast that floods to all fabric edge nodes on that VLAN; the silent host must respond to that broadcast, but the packet type depends on what the host is programmed to respond to: it may be ICMP, a UDP Echo, or a broadcast ARP, not necessarily ARP alone. In the Unknown Unicast path, the border generates a unicast ARP request for an unregistered EID and floods it to all edges. Cisco's configuration guide notes explicitly that "a silent host must ignore packets such as subnet broadcasts if it is not programmed to respond to them. Some endpoints require a 'magic packet' (such as a UDP Echo), while others respond only to a broadcast ARP." In either sub-path, when the host does respond, SISF records the binding and the edge registers the EID with the Control Plane.
The limitations are significant. First, the directed broadcast must originate from a device outside the fabric. An inter-VLAN trigger from one fabric edge to a silent host on another edge is explicitly documented as unsupported. Second, the feature requires underlay multicast (PIM), and enabling it automatically activates Layer 2 Flooding across the fabric. Third, it requires a Cisco DNA Advantage licence on the switch and IOS-XE 17.3 as a minimum. Catalyst 3000, 4000, and 6000 Series devices and Nexus 7000 are not supported for this feature.
For environments already running underlay multicast and holding DNA Advantage licences, IP Directed Broadcast is a working solution. For environments that lack either, or that need intra-fabric triggering, it is not.
database-mapping silent-host-detection (LISP-native)
Introduced in IOS-XE 17.11.1 (Dublin), this is a keyword addition to the database-mapping command in LISP instance-service mode. The full syntax is:
database-mapping <eid-prefix>/<len> locator-set <RLOC-name> silent-host-detection
When enabled, and when traffic arrives for an EID not present in the local site table, LISP triggers SISF to send a probe: a unicast ARP request or an IPv6 Neighbor Solicitation, depending on the address family. If the host responds, SISF creates the binding and the edge registers the EID. This mechanism requires no underlay multicast, no external broadcast source, and no Layer 2 Flooding. The anycast gateway SVI on the edge node does the probing directly.
The operational problem with this approach prior to 3.2.3 was scale. Applying the configuration manually via CLI, across every relevant EID prefix on every fabric edge, is not realistic in a Catalyst Center managed environment. Before 3.2.3, there was no dedicated anycast gateway toggle in Catalyst Center for this configuration.
What Catalyst Center 3.2.3 adds
Catalyst Center 3.2.3 release notes list the following under SD-Access new features: "Support for silent host detection in Cisco SD-Access fabric network: Catalyst Center supports the configuration of silent host discovery in anycast gateways. Silent host discovery enables the detection of silent hosts, thereby enhancing endpoint reachability."
In practice, this means a Silent Host Discovery checkbox is now available when creating or editing an anycast gateway. The GUI path is: Provision > Virtual Networks > Anycast Gateway > Create Anycast Gateways. Based on the feature description and the underlying IOS-XE mechanism, enabling the checkbox is expected to cause Catalyst Center to push database-mapping ... silent-host-detection configuration to the fabric edge nodes associated with that gateway. To verify what was actually pushed after provisioning, run show run | section lisp on a fabric edge node and confirm the silent-host-detection keyword is present in the relevant database-mapping entries. Silent Host Discovery in Catalyst Center is a checkbox. Correctly understanding what it does to your control plane, and verifying it has worked, is the engineering task.
Pre-Auth VLAN integration
For environments using 802.1X closed authentication, Catalyst Center 3.2.3 supports an optional Pre-Auth VLAN configuration alongside Silent Host Discovery. The user guide states: "To enable silent host detection with Pre-Auth VLANs, click Edit Pre-Auth VLANs." The authentication template must be in open, closed, or low impact mode with Authentication Control Direction set to In. If control direction is set to "both," egress packets to the host are dropped, the probe never reaches it, and discovery fails. There is also a sequencing requirement: if you need a non-default Pre-Auth VLAN, an additional anycast gateway with "Candidate Pre-Auth VLAN" enabled must be created before the Silent Host Discovery gateway is configured.
IOS-XE version requirement
The underlying silent-host-detection keyword was introduced in IOS-XE 17.11.1. The Catalyst Center 3.2.x user guide does not explicitly state the minimum IOS-XE version required on fabric edge nodes for this feature. Consult the SD-Access compatibility matrix for supported platforms and minimum IOS-XE versions before deploying.
Licensing
IP Directed Broadcast explicitly requires a Cisco DNA Advantage licence on the switch. The Silent Host Discovery checkbox in 3.2.3 is backed by the LISP-native mechanism rather than the Directed Broadcast path, and Cisco does not state a licence requirement for it in either the 3.2.3 release notes or the 3.2.x user guide. We are deliberately not inferring one from the Directed Broadcast requirement: the two features sit on different mechanisms, so the licensing position of one says nothing definitive about the other. Confirm the entitlement against your own account team before you plan a rollout around it.
Verifying registration without generating test traffic
Silent host discovery is demand-triggered: a probe is sent when transit traffic arrives for an EID not yet in the local site table, not on a schedule. This means that once the first real transit packet has triggered the probe and the host has responded, registration state is established in the control plane. At that point, verifying registration does not require pinging the host again or manufacturing additional test traffic. The verification workflow below checks control and data plane state directly, rather than relying on ping success as a proxy for fabric visibility. Note that if no transit traffic has yet arrived for a given host, no probe will have fired and no registration state will exist to verify.
Do not expect to see an ARP entry or a device-tracking entry on the border; ARP validation for the silent host should be done at the edge node. As Cisco's IP Directed Broadcast configuration guide notes: "The Border never resolves ARP for the silent host; only the endpoint registration is required. When the silent host replies, the ARP packet is sent as a Layer 2 unicast, so it is not flooded toward the Border. As a result, do not expect to see an ARP entry or a device-tracking entry on the Border."
Confirm the SISF binding table shows the host as reachable (on the edge node):
show device-tracking database interface <interface> | be Network
The expected state is REACHABLE. This confirms the host has an active binding in the device-tracking table; it is consistent with the host having responded to the SHD unicast ARP probe, though the binding table does not distinguish SHD-triggered probes from other SISF detection events.
Confirm the EID is registered in the local LISP database (on the edge node):
show lisp instance-id <L3-IID> ipv4 database | sec <host-IP>
Expected output shows the host IP with a local RLOC (site-self, reachable), confirming the edge node has a local database entry for the EID.
Confirm registration propagated to the Control Plane Node:
show lisp instance-id <L3-IID> ipv4 server <host-IP>/32
To list all EIDs registered under silent-host-detection on the Control Plane Node:
show lisp instance-id <L3-IID> ipv4 server silent-host-detection
Confirm the map-cache entry is positive (on the border or control plane):
show lisp instance-id <L3-IID> ipv4 map-cache <host-IP>
In a LISP Pub/Sub deployment, a registered host shows via pub-sub, complete, local-to-site. Before registration, the same command returns send-map-request, the negative cache action that causes traffic drops. This is the clearest single indicator of whether the problem is solved.
Confirm CEF is forwarding via the LISP tunnel and not glean (on the edge node):
show ip cef vrf <VRF-name> <host-IP>/32 detail
A glean entry means the host is not yet registered. A LISP tunnel entry means forwarding is resolved.
Check the silent-host database counter on the Control Plane Node:
show lisp instance-id <L3-IID> ipv4 statistics
The output includes a line for silent-host database size/limit. One sample output in the command reference shows a limit of 32,768 entries; the actual limit may vary by platform or configuration context. Monitor the size/limit counter in large OT environments.
Design considerations and caveats
IP Directed Broadcast
Inter-VLAN silent host triggering from a fabric edge (rather than a border) is explicitly unsupported with IP Directed Broadcast. The Cisco IP Directed Broadcast configuration guide notes: "Once LISP identifies the endpoint as an unknown EID, subsequent packets do not trigger additional ARP requests." A fabric edge that needs to reach a silent host on another edge will receive a negative cache entry on the first Map-Request, and the host will remain unreachable until it registers through some other path. Whether this inter-VLAN limitation applies equally to the LISP-native silent-host-detection mechanism is not established in the command reference for that feature.
Enabling IP Directed Broadcast automatically enables Layer 2 Flooding across the fabric. The LISP-native Silent Host Discovery mechanism does not carry this side effect, which is a meaningful advantage in environments where Layer 2 Flooding introduces scale or security concerns.
IP Directed Broadcast: transit environments
For environments running IP Directed Broadcast over an SD-Access transit, you must manually add ip network-broadcast to the LISP sub-interface on the local-site border (such as interface LISP0.4099); this is not provisioned automatically. This consideration is specific to the IP Directed Broadcast path and does not apply to the LISP-native mechanism.
LISP-native Silent Host Discovery (the 3.2.3 mechanism)
In 802.1X closed-mode environments, Wake-on-LAN must be enabled in the authentication template if a silent host needs to be woken. Without it, access-session control-direction both drops egress packets to the host, preventing the probe from arriving. Setting control direction to In is a required step; Wake-on-LAN must also be enabled in the authentication template, and if a non-default Pre-Auth VLAN is used, the sequencing requirement described above applies.
Before deploying this feature in large or OT environments, review several operational parameters that this article does not cover: the probe retry count, probe rate limiting, probe timeout values, how long a silent-host entry ages out after successful registration, the negative-cache duration after a failed probe, and what happens when the silent-host database ceiling is reached (the show lisp instance-id <L3-IID> ipv4 statistics output includes a size/limit counter, but the limit itself appears to be platform- or context-dependent). These parameters directly determine whether the feature resolves intermittent reachability in practice and how it behaves under scale in a large OT subnet. Consult the IOS-XE SD-Access command reference for the database-mapping command and the show lisp statistics output for your platform before committing to a deployment design.
Our Experience
At Entek IT, we have encountered silent host reachability issues at multiple customers. The pattern is consistent: a network team knows roughly where a device should be and knows its IP address from a spreadsheet, but the fabric has never seen it because the device was provisioned, configured, and then left to respond on demand. In the Client and Endpoint inventory view in Catalyst Center Assurance, the device does not appear: there is no current LISP registration entry for Assurance to surface it there. The device only became visible in Catalyst Center once there was active traffic originating from it; until that point, regardless of what other configuration was in place, Assurance had nothing to surface. A ping from across the fabric fails. The device itself is working; the control plane simply has no record of it.
A related failure mode we have seen multiple times is the switch reload scenario. When traffic to or from a silent host is active and continuous enough that entries do not time out, everything appears to work: the MAC and IP bindings are in the table, the EID is registered, connectivity is fine. But when a switch reloads, during an upgrade for example, those entries are gone. The host will not re-register on its own because it never initiates traffic, so connectivity does not come back until something else triggers discovery again. From an operational standpoint this is easy to miss in planning: the device worked before the maintenance window, and it fails after it, with no obvious explanation if you are not aware of how LISP registration depends on host-initiated traffic.
In some of those cases we used static device-tracking mapping as a workaround, manually creating a binding table entry so the edge node had something to register with the Control Plane without waiting for the host to generate traffic. It works, but it does not scale and it requires knowing the exact IP-to-MAC-to-interface mapping for every silent host in advance.
The IP Directed Broadcast approach has served as the other available tool in those scenarios, alongside the infrastructure commitments it requires. The gateway-level Silent Host Discovery in Catalyst Center 3.2.3 addresses a genuine operational gap, particularly for OT and manufacturing environments where static-addressed, low-activity endpoints are the norm rather than the exception, and where requiring underlay multicast just for endpoint visibility is a real deployment constraint.
Everything above about the 3.2.3 toggle itself is drawn from Cisco's documentation rather than from our own hands-on testing, and we want to be straight about that distinction. The installation of Catalyst Center 3.2.3 is currently running in our lab. The next steps are to build out the SD-Access fabric on it and then put Silent Host Discovery through a real test: enable the toggle on an anycast gateway, confirm with show run | section lisp what Catalyst Center actually pushes to the fabric edge nodes, and walk a genuinely silent endpoint through the verification sequence above to see where the registration state lands at each step. The questions we most want answered are the ones the documentation leaves open: the probe retry and rate-limiting behaviour, how a silent-host entry ages out once it has registered, and whether the inter-VLAN limitation documented for IP Directed Broadcast applies to the LISP-native path as well.
We will follow up with a field note once that testing is done. Until then, treat this article as the design reasoning you need before you enable the checkbox, not as a validation report.
If you are working through silent host reachability in an SD-Access environment, or planning a fabric deployment for an OT or mixed-use network, feel free to reach out to us at Entek IT.
