Configuring switch Ports to operate as supplicants for 802.1X connections to other switches

A switch port can operate as a supplicant in a connection to a port on another 802.1X-aware switch to provide security on links between 802.1X-aware switches. (A port can operate as both an authenticator and a supplicant.)

Suppose that you want to connect two switches, where:

  • Switch “A” has port A1 configured for 802.1X supplicant operation.

  • You want to connect port A1 on switch “A” to port B5 on switch “B”.

Supplicant Operation
  • When port A1 on switch “A” is first connected to a port on switch “B”, or if the ports are already connected and either switch reboots, port A1 begins sending start packets to port B5 on switch “B”.

    • If, after the supplicant port sends the configured number of start packets, it does not receive a response, it assumes that switch “B” is not 802.1X-aware, and transitions to the authenticated state. If switch “B” is operating properly and is not 802.1X-aware, then the link should begin functioning normally, but without 802.1X security and password.

    • If, after sending one or more start request packets, port A1 receives a request packet from port B5, then switch “B” is operating as an 802.1X authenticator. The supplicant port then sends a response/ID packet. If switch “B” is configured for RADIUS authentication, it forwards this request to a RADIUS server. If switch “B” is configured for Local 802.1X authentication, the authenticator compares the switch “A” response to its local user name.

  • The RADIUS server then responds with an MD5 access challenge that switch “B” forwards to port A1 on switch “A”.

  • Port A1 replies with an MD5 hash response based on its user name and password or other unique credentials. Switch “B” forwards this response to the RADIUS server.

  • The RADIUS server then analyzes the response and sends either a “success” or “failure” packet back through switch “B” to port A1.

    • A “success” response unblocks port B5 to normal traffic from port A1.

    • A “failure” response continues the block on port B5 and causes port A1 to wait for the “held-time” period before trying again to achieve authentication through port B5.