SuzieQ Enterprise Brief

Critical Network Visibility Through Unified IPv4 ARP & IPv6 Neighbor Data

Preserving endpoint visibility when gateways move to firewalls

Network troubleshooting often begins with a simple question: “Where is this device?” A user may provide an IP address, but locating the endpoint requires connecting that address to a MAC address and then to its network attachment. IPv4 ARP tables and IPv6 Neighbor Discovery Protocol (NDP) tables provide the essential IP-to-MAC relationship. SuzieQ consolidates collected neighbor information in its arpnd table, giving engineers a common, normalized starting point rather than requiring them to identify and query individual gateways.

The visibility gap: the gateway moves, but responsibility remains

Moving a subnet’s default gateway from a switch or router to a firewall can support security segmentation but it can also disrupt the network team’s troubleshooting workflow. The gateway’s neighbor information (ARP entries for IPv4 and neighbor-cache entries for IPv6) now resides on the firewall. If another team manages the firewall and network engineers lack access, a foundational source of endpoint information moves outside their operational reach.

The endpoint has not necessarily disappeared but its visibility has moved across an administrative boundary. Network engineers still need to locate devices as one of the most common troubleshooting steps, but may now depend on another team or system to retrieve information they previously accessed directly. Consolidating data from monitored switches does not automatically close that gap when the gateway is outside the collection scope.

How SuzieQ Enterprise helps close the gap

SuzieQ Enterprise extends visibility through correlation, supplementing collected ARP information with endpoint bindings available elsewhere in the monitored network. DHCP snooping and Cisco device-tracking information (ARP snooping) still live on the network and provide alternative sources of IP-to-MAC bindings when the gateway itself is inaccessible. This can preserve useful endpoint visibility without requiring direct access to the firewall.

A consolidated view helps engineers investigate practical questions in one step (CLI, GUI, REST, MCP):

Which MAC address is associated with an IP address?
Has an endpoint been observed previously?
Does the endpoint use DHCP or static addressing?
Which vendor is associated with the MAC address’s organizationally unique identifier (OUI)?

Operational value: troubleshooting and safer device moves

Unified endpoint information supports many network operation workflows.

Safer device moves

Engineers often find themselves in projects that require moving existing devices to a new subnet, VLAN, or gateway. Every move starts with the same questions: Where is the device, and does it use DHCP or a static address?

The answer determines the work. A DHCP client can usually follow the change on its own once the new scope is in place and its lease renews. A statically addressed device needs someone to find its owner, put hands on it, and make the configuration changes, which is common with operational technology and IoT equipment. Unified endpoint information helps engineers sort devices into those two groups early, locate owners, and plan the manual work before the change window. After the move, it helps confirm that devices have appeared at their new addresses.

Verifying IPAM allocations before use

Most organizations have an IP address management (IPAM) system, yet duplicate addresses still happen. Someone configures a static address without recording it, a device is restored from an old configuration, or a reservation is never cleaned up. The IPAM shows the address as free; the network says otherwise.

SuzieQ does not modify the IPAM, but it can supply the evidence for an automation workflow that does. A short Python script, for example, can check the IPAM’s answer against what the network has actually observed:

The script requests the next available address from the IPAM.
It queries SuzieQ’s arpnd data for that address over a recent window, such as the past day or week.
If SuzieQ has seen the address, the script marks it as in use in the IPAM, recording the MAC address and OUI vendor as clues to its owner, and requests the next one.
It repeats until an address has no recent sightings, then allocates it.

Because SuzieQ collects on a short, configurable polling interval and retains history, the check reflects recent network state rather than a daily or twice-daily export, and it catches devices that were active earlier in the window but are offline now. Each conflict the workflow finds also becomes an IPAM correction, bringing the record back in line with reality.

No sighting is strong evidence, not proof: a device may have been powered off for the entire window, or may sit behind a gateway outside the collection scope. Correlating DHCP snooping and device-tracking data helps narrow that gap.

Collecting directly from the firewall

Where firewall access is permitted, direct collection can further reduce the visibility gap. SuzieQ Enterprise support for Fortinet firewall networking data in L3 NAT mode brings that information into the broader operational view. Whether collected from the gateway or supplemented by supported access-layer sources, the goal remains the same: preserve the endpoint relationships engineers need to operate the network, even when security boundaries and administrative ownership change.