Drag and Drop Question Based on the configuration below, identify the correct sequence of events for wired DHCP profiling for IoT devices with HPE Aruba Networking ClearPass. Answer:

Question

Exhibit

Answer Area

Explanation

Wired DHCP Profiling for IoT Devices - ClearPass Sequence Explained

Overview of the Flow

This sequence describes a two-phase network access pattern: first grant a temporary "profiling" role to gather device fingerprint data, then reassign the device to its correct final role. Understanding why each phase exists is the key to understanding the ordering.

Step-by-Step Breakdown

Step 1 - The client device is connected to the switch and the port is now up.

Why first: This is the physical trigger for everything. No 802.1X/MAC auth, no RADIUS, no DHCP - none of it is possible until Layer 1 (the physical link) is established. Port-up is the event the switch listens for to begin the authentication process.

Step 2 - MAC address is learned on the port and MAC auth is triggered.

Why second: When the port comes up, the switch learns the source MAC address from the first frame the device sends. Because MAC authentication is configured on that port, the switch immediately initiates a RADIUS Access-Request to ClearPass, using the MAC address as both the username and password (formatted as aabbcc-ddeeff or similar). This happens before the device has an IP address - DHCP hasn't run yet.

Common misconception: Students often assume DHCP happens before authentication. It doesn't - MAC auth fires at Layer 2 the moment the port is up, before any IP-layer activity.

Step 3 - ClearPass processes the MAC authentication and sends RADIUS Accept with Aruba-User-Role=PROFILING VSA.

Why third: ClearPass receives the Access-Request and evaluates it against its policy rules. Because the device is unknown or not yet fully profiled, ClearPass applies a "catch-all" profiling policy and returns a RADIUS Access-Accept containing the Aruba-User-Role vendor-specific attribute (VSA) set to a profiling role. The Accept (not Reject) is critical - the device must get some access so it can send DHCP traffic for profiling to work.

Common misconception: Thinking ClearPass would deny access for unknown devices. Instead, it intentionally grants limited/provisional access specifically to collect profiling data.

Step 4 - The switch assigns a role with the PROFILING VLAN to the client device.

Why fourth: The switch receives the RADIUS Accept from ClearPass and enforces the Aruba-User-Role=PROFILING VSA by placing the device into the PROFILING VLAN. The switch acts on the RADIUS response - it cannot enforce a role before ClearPass tells it what role to assign. The PROFILING VLAN is configured to allow DHCP traffic and relay it to ClearPass, but restrict everything else.

Note the dependency: Step 3 (ClearPass sends the instruction) must precede Step 4 (switch acts on it).

Step 5 - The client device sends DHCP DISCOVER which is relayed to ClearPass and used to update the endpoint database.

Why fifth: Now that the device is on the PROFILING VLAN, it requests an IP address via DHCP. The switch/relay agent forwards the DHCP DISCOVER to ClearPass. ClearPass inspects the DHCP options (e.g., Option 55 parameter request list, Option 60 vendor class identifier, hostname) to fingerprint the device type. This data is written into the ClearPass Endpoint Repository, enabling policy decisions for the next authentication.

Common misconception: Thinking the device fingerprint is known before this step. ClearPass may have no prior knowledge - the entire purpose of the PROFILING VLAN is to create the conditions under which this DHCP data can be collected.

Step 6 - ClearPass sends a Change of Authorization (CoA) to the switch.

Why sixth: Once ClearPass has updated the endpoint profile, it now has enough information to make a final policy decision. It proactively pushes a CoA packet (RFC 5176) to the switch to trigger re-evaluation of the session. CoA allows ClearPass to dynamically change an active session without waiting for re-authentication to be initiated by the switch or the device. This is what makes the profiling workflow seamless and automatic.

Common misconception: Placing CoA before DHCP. CoA is triggered by the profiling data - it cannot logically precede the event that produces that data.

Step 7 - The device is re-authenticated and the final role is assigned using the Aruba-User-Role=IoT VSA.

Why seventh: The CoA causes the switch to re-run MAC authentication for the device. This time, ClearPass evaluates the request against the now-updated endpoint profile (which includes the DHCP fingerprint identifying it as an IoT device) and returns a new RADIUS Accept with Aruba-User-Role=IoT. The correct, permanent role is now assigned.

Common misconception: Thinking re-authentication happens before CoA. The CoA is precisely what initiates the re-authentication. Without it, the switch has no trigger to reauthenticate a device that already passed MAC auth.

Step 8 - The device has network access on the IoT VLAN.

Why last: The switch enforces the new IoT role, which maps to the IoT VLAN with the appropriate ACLs and network access rights. This is the end state - the device has the access it was always intended to have, but only after its identity was confirmed through profiling.

Summary of Key Dependencies

The entire workflow is a deliberate observe-then-enforce pattern: grant minimal provisional access, collect identity data passively, then dynamically upgrade to the correct policy without requiring any manual intervention or device-side agent.

No community discussion yet for this question.