PC61 Client Identification & Client Table Management
1. Purpose
To clearly define how PC61 detects, identifies, and maintains a list of connected LAN-side clients using:
Passive traffic observation
Active ARP-based discovery
This SOP ensures accurate client visibility, reliable monitoring, and predictable troubleshooting behavior.
2. Scope
This SOP applies to:
All PC61 appliances
LAN-side client monitoring only
Environments where PC61 functions as: Router/Gateway
3. Design Principles (Important Context)
PC61 does not rely on DHCP tables or switch CAM tables.
Instead, it builds its client table dynamically based on:
Observed traffic
ARP responses
This design ensures:
Vendor-agnostic discovery
Real-time accuracy
Independence from DHCP servers
4. High-Level Process Overview
PC61 maintains its client table using two complementary mechanisms:
Passive Traffic Detection
Learns clients when they send traffic
Active ARP Probing
Periodically verifies which clients are still alive
Together, these ensure:
New devices are discovered quickly
Inactive devices are aged out safely
5. End-to-End Flow Diagram
6. Detailed Procedure
Step 1: Client Detection via Passive Traffic Monitoring
What triggers detection
Any traffic received by PC61 from a LAN device, including:
ARP requests
IP packets
Application traffic
PC61 records the following fields:
IP address
MAC address
Interface / LAN port
Timestamp (Last Seen)
Outcome
Device is immediately classified as:
Connected
Active
This allows instant visibility without waiting for polling intervals.
Step 2: Client Discovery via Active ARP Broadcast
ARP Polling Behavior
PC61 sends a broadcast ARP request:
Every 3–5 minutes
On each LAN interface
Purpose
Validate which clients are:
Still powered on
Still reachable
Still on the local LAN
Client Response
Active clients respond with ARP replies
PC61 updates:
IP–MAC bindings
Last seen timestamp
Outcome
Client table is refreshed
Stale entries are identified
7. Client Table Update Logic
Client is ADDED when
Device sends any traffic to PC61
ORDevice responds to ARP broadcast
Client is MARKED INACTIVE or REMOVED when
No traffic is observed
ANDNo ARP response received
across multiple polling cycles
This prevents false positives while avoiding aggressive removal.
8. Verification & Validation
To confirm correct operation:
Verify client list contains:
Valid IP–MAC mappings
Correct LAN interface
Generate test traffic from a client
Confirm appearance within seconds
Wait one ARP interval (3–5 min)
Confirm timestamps refresh
Expected behavior
Active devices persist
Silent devices age out gracefully
9. Design Limitations & Notes
ARP discovery applies only to LAN-side clients
Devices in:
Different VLANs
Different subnets
will not appear unless traffic is routed through PC61
Silent devices may not appear unless:
They generate traffic
They respond to ARP
10. Operational Implications (Very Important)
PC61 client list is state-based, not static
Absence from client list does not always mean disconnected
Always validate using:
Traffic generation
ARP response timing
11. Conclusion
PC61 maintains a reliable, real-time client inventory by combining:
Passive traffic learning for immediate detection
Active ARP probing for lifecycle validation
This hybrid approach ensures:
Accurate visibility
Low false positives
Predictable behavior during troubleshooting