Port Access Control

Table of contents

• Introduction
• IEEE 802.1X
  • Specifying Authentication Server
  • Authenticator Initiation
  • Re-authentication Interval
  • MAC Authentication
  • 802.1X and MAC Authentication co-existence
  • Port Access and Trunk ports
• Port Method
• VLAN Assignment
  • Assignable VLANs
  • Authentication Success/Failure Scenarios When Using VLAN Assignment
• RADIUS Server Communication Attribute Value Pairs
  • MAC Address Format in RADIUS Attributes
  • RADIUS Attributes for 802.1X
  • RADIUS Attributes for MAC Authentication
  • Attributes with Service-Type Call-Check (Default)
  • Attributes with Service-Type Authenticate-Only
• CLI Command Syntax
  • Port Access Control Context
  • 802.1X Configuration Context
  • MAC Auth Configuration Context
  • VLAN Assignment Configuration Context
  • Port Access Control Status
  • Viewing Status from Admin-Exec Context
    • Summary View
    • Individual Status Tables
    • Instance-Specific Status
    • Audit Log
    • JSON Format
  • Port Access Status Context

Introduction

Port access control is used to stop unauthorised hosts from accessing the network. Authentication is required to gain access.

Port access provides two authentication mechanisms for hosts that wish to access a network. These two are:

• IEEE 802.1X authentication: Only clients (supplicants) able to prove the identity using 802.1X cryptographic handshake are allowed to access the network.
• MAC authentication: Only clients with granted MAC addresses are allowed to access the network.

                                 |
       Authentication         .--.-.
          Server            ( (    )__
         .------.          (_,  \ ) ,_)
         |RADIUS|            '-'--`--'
         '--+---'                |Internet/
            |                    |Intranet
         .--+------+------+------+--.
         |  5      6      7      8  |  Authenticator
         |           WeOS           | (Switch/Router)
         |  1      2      3      4  |
         '--+------+------+------+--'
            |      |      X      X  <== Controlled Ports
            |      |      |
          .-+--. .-+--. .-+--.
          | H1 | | H2 | | H3 |       Hosts/Supplicants
          '----' '----' '----'
      Authorised Hosts | Blocked Ports

Figure 1: WeOS Switch/Router with ports eth1-eth4 subject to access control.

Switch ports configured for port access control will by default be blocked for incoming traffic. Only when a connected device has successfully authenticated itself, it will be allowed to send data through the port. Packets from unauthorised devices are still dropped, i.e., only packets with a source MAC address of devices authorised via 802.1X or MAC authentication are allowed. Unknown multicast and broadcast will be blocked from egress on a controlled port until there is at least one MAC address authenticated on this port. For unknown multicast to egress a port at all, the ‘Multicast Flood Unknown’ setting must be enabled on this port.

Port access configuration is available from the general configuration context. The example below shows how to define the set of ports subject to access control.

example:/#> config
example:/config/#> port-access
example:/config/port-access/#> port eth1..eth4
example:/config/port-access/#> leave
example:/#>

You also need to specify which control mechanism to use (802.1X or MAC-Auth, or both), and which RADIUS server or local MAC list (Only for MAC-Auth) to use for authorisation. This is described in the sections below.

IEEE 802.1X

WeOS units are able to act as IEEE 802.1X authenticators. WeOS uses the RADIUS protocol with extensions for Extensible Authentication Protocol, EAP (RFC 2869), to communicate to a back-end authentication server. WeOS neither includes a RADIUS server nor a local authentication server mechanism for 802.1X. Instead the 802.1X authentication server must be provided externally as depicted in Figure 1.

Assuming you have already setup a RADIUS server instance, configuring port access control with 802.1X can be done as follows (the 802.1X Basic Setup HowTo provides a more extensive example).

example:/#> config
example:/config/#> port-access
example:/config/port-access/#> port eth1..eth4
example:/config/port-access/#> dot1x
example:/config/port-access/dot1x/#> authentication-server 1
example:/config/port-access/dot1x/#> leave
example:/#>

Figure 2 and Figure 3 illustrate the principles of a successful authentication with IEEE 802.1X. In reality the protocol exchanges several messages between the supplicant, the authenticator and the RADIUS back-end server (see the standard documents for details). The WeOS unit acts as an IEEE 802.1X authenticator, relaying the EAP messages to the RADIUS server.

          Authentication            |
             Server              .--.-.
            .------.            ( (    )__
            |RADIUS|           (_,  \ ) ,_)
            '--+---'             '-'--`--'
 RADIUS      ^ |                    |Internet/
 EAP Request | |                    |Intranet
            .--+------+------+------+--.
            |  5      6      7      8  |  Authenticator
            |           WeOS           | (Switch/Router)
            |  1      2      3      4  |
            '--+------+------+------+--'
               X      X      X      X  <== Controlled Ports
     EAPoL   ^ |                           (All Blocked by
     Request | |                            Authenticator)
            .--+-.
            | H1 |
            '----'

Figure 2: H1 (Supplicant) initiates EAP authentication handshake (EAPoL Request). Authenticator relays EAP message onto back-end RADIUS server.

         Authentication             |
             Server              .--.-.
            .------.            ( (    )__
            |RADIUS|           (_,  \ ) ,_)
            '--+---'             '-'--`--'
 RADIUS      | |                    |Internet/
 EAP Success V |                    |Intranet
            .--+------+------+------+--.
            |  5      6      7      8  |  Authenticator
            |           WeOS           | (Switch/Router)
            |  1      2      3      4  |
            '--+------+------+------+--'
             | |      X      X      X  <== Controlled Ports
     EAPoL   | |                           (Port 1 unblocked
     Reply   V |                            by Authenticator)
            .--+-.
            | H1 |
            '----'

Figure 3: At the end of a successful EAP handshake, the RADIUS server sends an EAP Success message. The Authenticator unblocks the port.

Specifying Authentication Server

WeOS requires an external RADIUS server to authenticate the 802.1X supplicant. It is possible to specify two servers for 802.1x where the secondary specified server will be used if the first fail to answer the radius authentication request.

example:/#> config
example:/config/#> aaa
example:/config/aaa/#> remote-server 1
Creating new remote server 1
example:/config/aaa/remote-server-1/#> address 192.168.2.1
example:/config/aaa/remote-server-1/#> password MyS3cret
example:/config/aaa/remote-server-1/#> end
example:/config/aaa/#> remote-server 2
example:/config/aaa/remote-server-2/#> address 192.168.3.1
example:/config/aaa/remote-server-2/#> password MyS3cret
example:/config/aaa/remote-server-2/#> end
example:/config/aaa/#> end
example:/config/#> port-access 
example:/config/port-access/#> dot1x 
example:/config/port-access/dot1x/#> authentication-server 1,2
example:/config/port-access/dot1x/#> leave
example:/#>

See AAA configuration for more information on how to define RADIUS servers in WeOS.

Authenticator Initiation

WeOS supports Authenticator initiated authentication as defined by §8.1.2.1 in IEEE 802.1X¹. This is enabled by default with interval 30 seconds.

When enabled, authenticator actively sends EAP Identity Requests every 30 seconds by default until a supplicant successfully authenticates. The interval is configurable in range 10-300 seconds). The example below shows how to set the interval to 60 seconds.

example:/#> config
example:/config/port-access/#> dot1x
example:/config/port-access/dot1x/#> active-authentication 60
example:/config/port-access/dot1x/#> leave
example:/#>

no active-authentication disables authenticator initiated authentication. If disabled the 802.1X client (supplicant) must be capable to initiate the authentication procedure to gain access.

Re-authentication Interval

The authenticator can periodically request the supplicant to re-authenticate itself. By default, period re-authentication is disabled. If enabled, the default request interval is 3600 seconds, see the example below. The interval can be configured in range 10 to 352800 seconds. Note that a value lower than 600 is not recommended and only possible to configure via cli.

example:/#> config
example:/config/port-access/#> dot1x
example:/config/port-access/dot1x/#> re-authenticate 
example:/config/port-access/dot1x/#> show re-authenticate 
3600
example:/config/port-access/dot1x/#> leave
example:/#>

MAC Authentication

MAC based authentication is not as secure as IEEE 802.1X. Devices are granted access based on the MAC address without any cryptographic authentication exchange, and it is fairly easy to modify the MAC address on a PC and most other equipment.

MAC authentication is useful for devices that do not support 802.1X, such as printers or legacy equipment. These devices cannot act as 802.1X supplicants, so MAC authentication provides a way for them to gain access to the network based on their MAC address alone.

To define which MAC address(es) to grant, it is possible to configure a local accept list with MAC addresses to grant access. It is also possible to let the WeOS use a backend RADIUS to control what MAC addresses to accept - the latter method is also referred to as MAC authentication bypass (MAB).

          Authentication            |
             Server              .--.-.
            .------.            ( (    )__
            |RADIUS|           (_,  \ ) ,_)
            '--+---'             '-'--`--'
 RADIUS      ^ |                    |Internet/
 Calling-ID  | |                    |Intranet
 (MAC-H1)   .--+------+------+------+--.
            |  5      6      7      8  |  Authenticator
            |           WeOS           | (Switch/Router)
            |  1      2      3      4  |
            '--+------+------+------+--'
               X      X      X      X  <== Controlled Ports
             ^ |                           (All Blocked by
  Data Pkt   | |                            Authenticator)
  Src MAC   .--+-.
 (MAC-H1)   | H1 |
            '----'

Figure 4: H1 (Host/Supplicant) connects to port controlled by MAC Authentication. Switch looks in local 'Accept-list' or (as here) forwards H1's MAC address to a back-end RADIUS server.

         Authentication             |
             Server              .--.-.
            .------.            ( (    )__
            |RADIUS|           (_,  \ ) ,_)
            '--+---'             '-'--`--'
 RADIUS      | |                    |Internet/
 Accept      V |                    |Intranet
            .--+------+------+------+--.
            |  5      6      7      8  |  Authenticator
            |           WeOS           | (Switch/Router)
            |  1      2      3      4  |
            '--+------+------+------+--'
               |      X      X      X
               |
               |
            .--+-.
            | H1 |
            '----'

Figure 5: After successful authentication, the RADIUS server sends an Accept message back to the Authenticator. The Authenticator unblocks the port for the MAC address of H1.

• When defining a local accept list, the list can consist of one or more MAC address patterns. MAC patterns may contain a wild-card at the end to match a whole range of addresses. Examples: The pattern 00:11:22:33:44:55 matches exactly one address, while the pattern 00:aa:bb:* matches all addresses beginning with 00:aa:bb.
• When using a RADIUS server (MAB), it is currently only possible to specify a single server. WeOS passes the MAC address of the connecting host in a RADIUS Calling-ID attribute.
• It is possible to use both accept list and RADIUS server.

example:/#> config
example:/config/#> aaa
example:/config/aaa/#> mac-auth 1
example:/config/aaa/mac-auth-1/#> mac match 00:11:22:33:44:55
example:/config/aaa/mac-auth-1/#> mac match 00:aa:7c:*
example:/config/aaa/mac-auth-1/#> end
example:/config/aaa/#> end
example:/config/#> port-access
example:/config/port-access/#> mac-authentication 
example:/config/port-access/mac-auth/#> accept-list 1
example:/config/port-access/mac-auth/#> leave
example:/#>

See AAA configuration for more information on how to define RADIUS servers in WeOS.

MAC-Auth using RADIUS (MAB) and MAC-Auth using accept list HowTos provide more extensive examples.

802.1X and MAC Authentication co-existence

It is possible to enable both 802.1X and MAC Authentication for a single port access control instance. The reason for using both methods could be if you have a mix of 802.1X capable devices and legacy (non-802.X capable) devices in your network.

If both authentication methods are enabled, the first one that does a successful authentication will take precedence. If a successful 802.1X authentication attempt has been made, subsequent MAC Auth attempts are cancelled, and vice versa.

Port Access and Trunk ports

If a port is configured to belong to several VLANs, a successful authentication triggered on any of the VLANs will result in access being granted on all the VLANs the port is a member of (for MAC Based method, the specific MAC address is unlocked; for Port Based method, the entire port is unlocked). A constraint for 802.1X is that the authentication must be performed on an untagged VLAN - this may change in future releases.

Port Method

Each port access control instance can select one of two different Port Methods that will determine how the selected ports will behave in terms of providing access to the network. The two methods are:

• MAC Based (Default): Each individual client must be authenticated, where its MAC address is unlocked on the port.
• Port Based: The entire port is unlocked for all traffic when a single client has been successfully authenticated on a given port. When the port is unlocked, all traffic will be allowed to access the port, essentially the port will now behave like a regular port without access control. The unlocked state is “controlled” by the client that was authenticated, meaning that if that client is deauthenticated the port will be locked again.

          Authentication            |
             Server              .--.-.
            .------.            ( (    )__
            |RADIUS|           (_,  \ ) ,_)
            '--+---'             '-'--`--'
 RADIUS      ^ |                    |Internet/
 Calling-ID  | |                    |Intranet
 (MAC-H1)   .--+------+------+------+--.
            |  5      6      7      8  |  Authenticator
            |           WeOS           | (Switch/Router)
            |  1      2      3      4  |
            '--+------+------+------+--'
               X      X       X      X
                      |
                      |
                .-----+-----.
       .----.   |           |   .----.
       | H1 +---+  Switch   +---+ H4 |
       '----'   |           |   '----'
                '--+-----+--'
                   |     |
                .--+-. .-+--.
                | H2 | | H3 |
                '----' '----'

Figure 6: With Port Based method, the entire port is unlocked for all traffic when a single client has been successfully authenticated on a given port. In this example, when H1 successfully authenticates, the entire port is unlocked and thus H2, H3 and H4 will also have access to the network. With MAC Based method, only H1 would have access to the network after successful authentication, and H2, H3 and H4 would still be blocked until they have successfully authenticated themselves.

This setting may be more important to consider if what is behind the port access port is not a single end device but rather a switch or an access point which could have multiple clients behind it, as in the example above. If only one end device will be behind a given port access port, both methods will, for all practical purposes, behave the same.

VLAN Assignment

Dynamic VLAN assignment allows the network administrator to centrally manage which VLAN a port is placed in upon successful authentication, using RADIUS policies instead of static per-port VLAN configuration on the switch. This is useful for segmenting traffic based on role, department, or security level.

Dynamic VLAN assignment is supported for both 802.1X and MAC authentication (MAB). When enabled, the switch can receive VLAN assignment information from the RADIUS server and dynamically assign the port to the specified VLAN upon successful authentication.

The following is an overview of the constraints and behaviors that apply when using dynamic VLAN assignment:

• Ports can only be dynamically assigned untagged to a VLAN.
• Ports can only be assigned to VLANs that:
  • Already exist on the device.
  • Are configured as allowed VLANs in the port access configuration.
  • Have an associated VLAN interface created for it on the device.
• Port access ports cannot be configured as tagged members of any VLAN when VLAN assignment is enabled for the instance.
• Authentication will fail if the RADIUS server specifies a VLAN ID that is not in the configured allowed VLANs list.
• VLAN information from the RADIUS server must be provided in the Tunnel-Private-Group-ID attribute as a VLAN ID (VID) only. VLAN names are not supported.
• Multiple clients on the same port can only be authenticated if they all request assignment to the same VLAN. The first authenticated client will determine the VLAN assignment for the port, and subsequent clients must request the same VLAN assignment to be able to authenticate successfully.
• Dynamic VLAN assignment is not pre-emptive. If a port is already assigned to a VLAN, it cannot be reassigned to another VLAN until the last client that is authenticated on that port is deauthenticated, and the port is moved back to its statically configured untagged VLAN, i.e. the starting VLAN.
• When using MAC Based port method: Multiple clients on the same port can only be authenticated if they all request assignment to the same VLAN.
• When VLAN assignment is disabled, ports always remain in their statically configured untagged VLAN, regardless of RADIUS server responses.

Assignable VLANs

When dynamic VLAN assignment is enabled, VLANs are not automatically created. Only VLANs that already exist on the device can be assigned to ports. This provides better control and security over which VLANs authenticated clients can access.

Figure 7: Illustration showing the subset of VLANs that are assignable through port access.

For a VLAN to be assignable through port access, it must meet all of the following requirements, as illustrated in Figure 7:

• The VLAN must already exist on the device
• The VLAN must have an associated VLAN interface created on the device
• The VLAN must be configured as an allowed VLAN in the port access configuration

For example, to make VLANs 10, 20, and 30 available for dynamic assignment, first create the VLANs:

example:/#> config
example:/config/#> vlan 10
example:/config/vlan-10/#> end
example:/config/#> vlan 20
example:/config/vlan-20/#> end
example:/config/#> vlan 30
example:/config/vlan-30/#> end
example:/config/#>

Then configure these VLANs as allowed in the port access VLAN assignment configuration. If the RADIUS server specifies a VLAN ID that is not in the allowed VLANs list, authentication will fail.

Authentication Success/Failure Scenarios When Using VLAN Assignment

The following table shows when authentication succeeds or fails based on VLAN assignment configuration, RADIUS server response, and current port state. When Allowed the client is authenticated and the port is assigned to the specified VLAN, or it remains in the VLAN it is currently assigned to. When Denied the authentication fails and the port remains in its current VLAN and the client is not granted access to the network.

• A: RADIUS server provides a VLAN ID (VID) in the Tunnel-Private-Group-ID attribute as part of the authentication response.
• B: VLAN assignment is enabled in the port access configuration.
• C: Default VLAN is enabled in the port access configuration.
  • When default VLAN is enabled it will currently be implicitly set to be the VLAN that the port is statically configured as an untagged member of. So it happens to be the same as the starting VLAN for the port, but it is a different concept from the starting VLAN. (It is possible that the default VLAN could be configurable with a different VLAN than the starting VLAN in the future.)
• D: There are other clients authenticated on the same port.
• E: The VID to be assigned matches the currently assigned VLAN for the port.
• F: The VID to be assigned is in the configured allowed VLANs list for the port access instance.

RADIUS Server Communication Attribute Value Pairs

This section describes the RADIUS Attribute Value Pairs (AVPs) that WeOS provides in the RADIUS communication for port access authentication. These attributes are included in the authentication requests for both 802.1X and MAC authentication.

Understanding these attributes can be helpful when configuring your RADIUS server to work with WeOS, or when troubleshooting authentication issues.

MAC Address Format in RADIUS Attributes

When MAC addresses are provided in RADIUS attributes, they use the following format by default, as specified by RFC 3580:

• Hyphen-separated hexadecimal octets in uppercase
• Example: 00-A1-B2-C3-D4-E5

This format is used in attributes such as Calling-Station-ID and Called-Station-ID. For MAC authentication (MAB), it also applies to User-Name and User-Password attributes when Service-Type is set to Call-Check.

RADIUS Attributes for 802.1X

When performing 802.1X authentication, WeOS sends the following RADIUS attributes in the authentication request:

RADIUS Attributes for MAC Authentication

For MAC authentication (MAB), different RADIUS attributes are sent depending on the configured Service-Type. The Service-Type can be configured as either Call-Check (default) or Authenticate-Only.

Attributes with Service-Type Call-Check (Default)

When Service-Type is set to Call-Check, which is the default and recommended setting for MAB, the following attributes are sent:

Attributes with Service-Type Authenticate-Only

When Service-Type is set to Authenticate-Only, the following attributes are sent:

CLI Command Syntax

Port Access Control Context

Port Access Control context is reached via the General Configuration context. Multiple port access control instances can be configured, if no instance ID is provided it will create a new instance with the next available instance ID:

example:/#> config
example:/config/#> port-access
Creating new Port Access instance 1.
example:/config/port-access-1/#>

In order to configure a specific instance, the instance ID must be provided (can be tab-completed):

example:/#> config
example:/config/#> port-access 1
example:/config/port-access-1/#>

[no|show] port-access [INSTANCE-NUM]

Port access control settings (IEEE 802.1X and MAC Auth)

no

Remove port access control.

INSTANCE-NUM

Port access instance number. If not provided, the next available instance number will be used to create a new instance.

[no] enable

Activate or deactivate port access control. Deactivating does not remove port access control configuration.

no

Disable/deactivate port access control.

[no] <PORT[,PORT ...] | PORT..PORT>

Port(s) to be managed by 802.1X and/or MAC authentication.

The selected ports will be managed by the port access control instance. All the selected ports will be locked when this port access instance is enabled. The only way to gain access on any of these ports will be to authenticate using either 802.1X or MAC authentication.

A Port is valid for selection if it fulfills the following criteria:

• Is a physical ethernet port.
• Is a bridge port, i.e. it is configured as part of a VLAN.
  • If VLAN assignment is enabled the port cannot be tagged in any VLAN, it is only allowed to be untagged.
• The port is not configured as part of another port access instance.

Warning

Be careful when selecting ports, as it is possible to lock yourself out if the device is accessed remotely, e.g. via SSH or Web interface, and one of the selected ports is the one the device is accessed through.

Examples

example:/config/port-access-1/#> port eth1
example:/config/port-access-1/#> port eth1 eth2 eth3
example:/config/port-access-1/#> port eth1..eth5
example:/config/port-access-1/#> no port eth1

no

Disable port access control of PORT(S)

PORT

A single port, e.g. eth1.

[no] description [STRING]

Free form string describing current port access control configuration.

no

Remove description.

STRING

Free form string. If the string contains spaces, it must be enclosed in quotes "Example description".

[no] port-method [mac-based|port-based]

Set port access control method.

The port-method determines how authentication behaves for clients on the managed ports. The behavior of the different methods is:

• mac-based: Clients are authenticated based on their MAC address. In other words, this means that all clients must be individually authenticated to be granted access.

• port-based: If a single client is authenticated on the port, the entire port is opened, granting access to all other clients on the network.

Be aware of the network topology when using Port Based method

Be mindful of the fact that any device connected to a port with port-based authentication will be able to access the network once a client is authenticated. Therefore, when using this mode, consider carefully what is located behind the port(s). For instance if there will only be one single end device connected to the port, such as a printer or a camera, port-based authentication might be sufficient. But if there is a possibility that there will be multiple end devices behind the port(s) consider who is responsible for authenticating and which other devices may be granted access afterwards.

Default: mac-based

Examples

example:/config/port-access-1/#> port-method mac-based
example:/config/port-access-1/#> port-method port-based
example:/config/port-access-1/#> no port-method

no

Reset to default (mac-based)

mac-based

Keyword to select MAC Based port method.

port-based

Keyword to select Port Based port method.

[no] dot1x

Enable (and enter) or disable the 802.1X sub-context.

When enabled, this option enters the 802.1X configuration context. See 802.1X configuration context below.

no

Disable 802.1X.

[no] mac-auth

Enable (and enter) or disable the MAC authentication sub-context.

When enabled, this option enters the MAC authentication configuration context. See MAC authentication configuration context below.

no

Disable MAC authentication.

[no] vlan-assignment

Enable (and enter) or disable the VLAN assignment sub-context.

When enabled, this option enters the VLAN assignment configuration context. See VLAN assignment configuration context below.

no

Disable VLAN assignment.

802.1X Configuration Context

802.1X configuration is a sub-context of port access control context.

example:/#> config
example:/config/#> port-access
example:/config/port-access/#> dot1x
example:/config/port-access/dot1x/#>

[no] enable

Enable or disable 802.1X authentication.

no

Disable 802.1X authentication

[no] authentication-server <SERVER-ID|SERVER-ID,SERVER-ID>

Select one or two remote authentication servers to use.

If a secondary remote authentication server is also configured, it will be tried if the first remote server has failed retransmitting according to 802.1x standard behaviour. A retry connecting to the first remote authentication server will be done 600 seconds after the first connection attempt.

The SERVER_ID represents a remote-server configured under the aaa configuration context. Only remote servers of type radius can be used as authentication servers for 802.1X.

Tab Completion

The command supports tab-completion of configured remote servers.

Examples

example:/config/port-access-1/dot1x/#> authentication-server 1
example:/config/port-access-1/dot1x/#> authentication-server 1,2
example:/config/port-access-1/dot1x/#> no authentication-server

no

Disable the use of the given authentication server.

SERVER-ID

The ID of the (RADIUS) authentication server to use. If no authentication server with the specified ID exists or is misconfigured, a warning will be shown. For information on configuring authentication server, see AAA configuration.

[no] active-authentication [INTERVAL]

Enable or disable active-authentication.

When enabled, the device will periodically send EAP Identity Request frames to attempt to initiate authentication with potential supplicants located behind the configured port access ports. If any supplicant is authenticated successfully on a port, the periodic EAP Identity Request will stop for that port. The periodic EAP Identity Request will resume if all authenticated supplicants on the port are de-authenticated.

The interval is specified in seconds and can be configured to a value in the range 10..300 seconds.

Default: Enabled (30 seconds)

Examples

example:/config/port-access-1/dot1x/#> active-authentication
example:/config/port-access-1/dot1x/#> active-authentication 30
example:/config/port-access-1/dot1x/#> no active-authentication

no

Disables active-authentication

INTERVAL

INTERVAL in seconds (range 10-300). Argument is optional with default 30 seconds.

[no] re-authenticate [INTERVAL]

Enable or disable periodic re-authentication.

When enabled, the device will periodically request re-authentication for already authenticated clients. If an authenticated client fails to re-authenticate, the client will be de-authenticated.

The interval is specified in seconds and can be configured to a value in the range 10..352800 seconds.

Default: Disabled (when enabled, default is 3600 seconds)

Examples

example:/config/port-access-1/dot1x/#> re-authenticate
example:/config/port-access-1/dot1x/#> re-authenticate 600
example:/config/port-access-1/dot1x/#> no re-authenticate

no

Disables periodic re-authentication

INTERVAL

INTERVAL in seconds (range 10-352800 seconds, i.e., 10 seconds to 1 week). Argument is optional with default 3600 seconds.

[no] quiet-period [INTERVAL]

Enable or disable quiet period.

The quiet period is a time interval, after a failed authentication attempt, during which any new authentication requests from the same client will not be processed.

The quiet period is useful to prevent immediate repeated authentication attempts from a client that is unable to authenticate.

The interval is specified in seconds and can be configured to a value in the range 3..3600 seconds.

Default: Enabled (10 seconds)

Examples

example:/config/port-access-1/dot1x/#> quiet-period
example:/config/port-access-1/dot1x/#> quiet-period 10
example:/config/port-access-1/dot1x/#> no quiet-period

no

Disables quiet period

INTERVAL

INTERVAL in seconds (range 3-3600).

MAC Auth Configuration Context

MAC authentication configuration is a sub-context of port access context.

example:/#> config
example:/config/#> port-access
example:/config/port-access/#> mac-authentication
example:/config/port-access/mac-auth/#>

[no] enable

Enable or disable MAC authentication.

no

Disable MAC authentication.

[no] authentication-server <SERVER-ID>

Select a remote authentication server to use for MAB.

The SERVER_ID represents a remote-server configured under the aaa configuration context. Only remote servers of type radius can be used as authentication servers for MAC Authentication Bypass (MAB).

Tab Completion

The command supports tab-completion of configured remote servers.

Examples

example:/config/port-access-1/mac-auth/#> authentication-server 1
example:/config/port-access-1/mac-auth/#> no authentication-server

no

Disable the use of the given authentication server.

SERVER-ID

The ID of the (RADIUS) authentication server to use. If no authentication server with the specified ID exists or is misconfigured, a warning will be shown. For information on configuring authentication server, see AAA configuration.

[no] service-type [call-check|authenticate-only]

Select the service type used for the MAB RADIUS requests.

Configure the RADIUS Service-Type attribute for MAC Authentication Bypass (MAB) requests.

The Service-Type attribute determines how authentication credentials are sent to the RADIUS server during MAB authentication:

• call-check: Uses Service-Type 10 (Call Check). The device will use the client’s MAC address as both username and password in the authentication request to the RADIUS server.

• authenticate-only: Uses Service-Type 8 (Authenticate Only). The device will not send any username or password in the authentication request to the RADIUS server.

Default: call-check

Examples

example:/config/port-access-1/mac-auth/#> service-type authenticate-only
example:/config/port-access-1/mac-auth/#> service-type call-check
example:/config/port-access-1/mac-auth/#> no service-type

no

Reset to default (call-check)

[no] accept-list <MAC-LIST-ID>

Specify a local MAC address whitelist to use for authentication.

The MAC_LIST_ID represents a mac-auth list configured under the aaa configuration context. This allows local authentication of specific MAC addresses without requiring a RADIUS server.

Tab Completion

The command supports tab-completion of configured MAC lists.

Examples

example:/config/port-access-1/mac-auth/#> accept-list 1
example:/config/port-access-1/mac-auth/#> no accept-list

no

Disable the use of the given MAC list.

MAC-LIST-ID

The ID of the MAC List to use. If the specified MAC-LIST-ID does not exist or is misconfigured, a warning will be shown. For information on creating MAC lists, see [AAA configuration][mac-list].

VLAN Assignment Configuration Context

VLAN assignment configuration is a sub-context of port access context.

example:/#> config
example:/config/#> port-access
example:/config/port-access/#> vlan-assignment
example:/config/port-access/vlan-assignment/#>

[no] enable

Enable or disable VLAN assignment.

When enabled, the authenticated ports will be assigned to VLANs based on information received from the authentication server.

When enabled the server must provide VLAN information in the authentication response, otherwise the port will not be authenticated. The exception is when default-vlan is enabled.

In addition, the VLAN provided by the server must be in the list of allowed-vlans configured for the instance, otherwise the port will not be authenticated. For a VLAN to be allowed, it must be explicitly listed in the allowed-vlans configuration.

No Tagged VLANs Allowed

When VLAN assignment is enabled, the configured port access ports cannot be tagged in any VLANs. The ports must be untagged members of one VLAN (the PVID), as soon as VLAN assignment is enabled.

Default: Disabled

no

Disable VLAN assignment.

[no] allowed-vlans [VLAN [VLAN...]]

Specify which VLANs are allowed for assignment.

The list of allowed VLANs specifies which provided VLANs from the authentication server that are permitted for assignment to the authenticated ports. If the server provides a VLAN that is not in this list, the port will not be authenticated.

For a VLAN to be selectable, it must be manually configured in the VLAN configuration. In other words, the VLAN will not be automatically created by the VLAN assignment handling, it will only assign ports to existing VLANs.

Same as allowed-vids

The allowed-vlans and allowed-vids commands configure the same setting, just with different input formats. These two commands are simply aliases for the same configuration, so they have the same effect and constraints.

Tab Completion

The command supports tab-completion of existing VLANs on the device.

Default: No allowed VLANs are configured

Examples

The VLANs are specified by their entire interface name, this supports tab completion for existing VLANs.

example:/config/port-access-1/vlan-assignment/#> allowed-vlans vlan10
example:/config/port-access-1/vlan-assignment/#> allowed-vlans vlan10 vlan20
example:/config/port-access-1/vlan-assignment/#> no allowed-vlans

no

Clear the list of allowed VLANs.

VLAN

The VLAN to allow for assignment, specified by its interface name, e.g. vlan10. The VLAN must already exist on the device to be selectable.

[no] allowed-vids [VID [VID...]]

Specify which VLAN IDs (VIDs) are allowed for assignment.

The list of allowed VLAN IDs specifies which provided VLAN IDs from the authentication server that are permitted for assignment to the authenticated ports. If the server provides a VLAN ID that is not in this list, the port will not be authenticated.

For a VID to be selectable, the VLAN corresponding to that VID must be created manually in the VLAN configuration. The VLAN for the VID will not be created automatically by the VLAN assignment handling; it will only assign ports to existing VLANs.

Same as allowed-vlans

The allowed-vids and allowed-vlans commands configure the same setting, just with different input formats. These two commands are simply aliases for the same configuration, so they have the same effect and constraints.

Tab Completion

The command supports tab-completion of existing VLANs on the device, by their VID in the format 10, e.g. vlan10 for VID 10.

Default: No allowed VLAN IDs are configured

Examples

The VLAN IDs are specified by their numeric VID value.

example:/config/port-access-1/vlan-assignment/#> allowed-vids 10
example:/config/port-access-1/vlan-assignment/#> allowed-vids 10 20 30
example:/config/port-access-1/vlan-assignment/#> no allowed-vids

no

Clear the list of allowed VLAN IDs.

VID

The numeric VLAN ID (VID) to allow for assignment, e.g. 10. The VLAN corresponding to the VID must already exist on the device to be selectable.

[no] default-vlan

Enable or disable default VLAN assignment.

When enabled, assignment to a default VLAN for an authenticated port is allowed, if the server does not provide any VLAN information in the authentication response.

When disabled, the server must provide VLAN information in the authentication response, otherwise the port will not be authenticated.

The default-vlan for a port is the configured PVID of the port, i.e. the VLAN the port is an untagged member of. Every selected port access port, for the instance, is required to be configured untagged in a VLAN, as soon as VLAN assignment is enabled.

No Tagged VLANs Allowed

When VLAN assignment is enabled, the selected ports cannot be tagged in any VLANs, only untagged VLANs are allowed.

Default: Disabled

no

Disable default VLAN assignment.

Port Access Control Status

Port access control status can be viewed and monitored through several different commands and views. The status information is organized into four main sections, each focusing on different aspects of port access:

• 802.1X Authentications - Currently authenticated 802.1X clients (supplicants), showing MAC address, supplicant username, port, authentication server, and date added.

• MAC Auth Authentications - Currently authenticated MAC addresses, showing MAC address, port, authentication method (MAB or accept-list), and date added.

• Ports - Port access port status, showing port name, port method (MAC Based or Port Based), state (unlocked/locked or number of authentications), and list of authenticated MAC addresses.

• VLAN Assignment - VLAN assignment status for each port, showing whether VLAN assignment is enabled, current assignment state, assignment source (server or default), assigning client MAC, and assigned VLAN.

The status can be viewed in two main ways:

1. Direct command execution - Run status commands directly from the admin-exec context using show port-access [options].

2. Status context - Enter the port-access status context to access status commands and enable additional display options.

Viewing Status from Admin-Exec Context

Summary View

To view a summary of all port access status information:

example:/#> show port-access
Number of Port Access Instances: 1
Table Instance Dividers        : Disabled

╒ 802.1X Authentications ════════════════════════════════════════════════════╕
│#  MAC-ADDRESS        SUPPLICANT    PORT    SERVER           DATE-ADDED     │
│1  76:03:0e:ff:ba:ab  supplicant1   eth1    198.19.10.1      Feb 26 16:26:26│
└────────────────────────────────────────────────────────────────────────────┘

╒ MAC Auth Authentications ══════════════════════════════════════════════════╕
│#  MAC-ADDRESS        PORT    METHOD                         DATE-ADDED     │
│1  76:03:0e:eb:11:68  eth3    MAB (198.19.10.1:4000)         Feb 26 16:19:39│
└────────────────────────────────────────────────────────────────────────────┘

╒ Ports ═════════════════════════════════════════════════════════════════════╕
│PORT    METHOD      STATE                           AUTHENTICATED-MAC       │
│eth1    MAC Based   1 Authentication                76:03:0e:ff:ba:ab       │
│eth2    MAC Based   0 Authentications               -                       │
│eth3    MAC Based   1 Authentication                76:03:0e:eb:11:68       │
└────────────────────────────────────────────────────────────────────────────┘

╒ VLAN Assignment ═══════════════════════════════════════════════════════════╕
│PORT    ENABLED  STATE       FROM     ASSIGNING-CLIENT   VLAN               │
│eth1    No       Unassigned  -        -                  -                  │
│eth2    No       Unassigned  -        -                  -                  │
│eth3    Yes      Assigned    Server   76:03:0e:eb:11:68  VID 30 (vlan30)    │
└────────────────────────────────────────────────────────────────────────────┘

- Use 'show port-access audit' to display related events in the audit log.
- Use 'show port-access INSTANCE' to show details for a specific instance.
- Use 'port-access instance-dividers' to enable dividers between instances
  in the tables.
example:/#>

Individual Status Tables

Individual status tables can also be displayed separately, as shown in the examples below.

802.1X Authentications

example:/#> show port-access dot1x-authentications
#  MAC-ADDRESS        SUPPLICANT      PORT    SERVER           DATE-ADDED     
1  76:03:0e:ff:ba:ab  supplicant1     eth1    198.19.10.1      Feb 26 16:26:26
example:/#>

MAC Auth Authentications

example:/#> show port-access mac-auth-authentications
#  MAC-ADDRESS        PORT    METHOD                           DATE-ADDED     
1  76:03:0e:eb:11:68  eth3    MAB (198.19.10.1:4000)           Feb 26 16:19:39
example:/#>

Ports

example:/#> show port-access ports
PORT    METHOD      STATE                           AUTHENTICATED-MAC         
eth1    MAC Based   1 Authentication                76:03:0e:ff:ba:ab
eth2    MAC Based   0 Authentications               -
eth3    MAC Based   1 Authentication                76:03:0e:eb:11:68
example:/#>

VLAN Assignment

example:/#> show port-access vlan-assignment
PORT    ENABLED  STATE       FROM     ASSIGNING-CLIENT     VLAN               
eth1    No       Unassigned  -        -                    -
eth2    No       Unassigned  -        -                    -
eth3    Yes      Assigned    Server   76:03:0e:eb:11:68    VID 30 (vlan30)
example:/#>

Instance-Specific Status

To view status for a specific instance, provide the instance ID:

example:/#> show port-access 1
[Instance 1 status displayed...]
example:/#>

Audit Log

To view port access related audit log messages:

example:/#> show port-access audit
[Audit log messages related to port access...]
example:/#>

JSON Format

To view status in JSON format:

example:/#> show port-access json
{
        "instance_count": 1,
        "enabled_instance_count": 1,
        "instances": [
                {
                        "id": 1,
                        "dot1x": {
                                "enabled": true,
                                "pid": 1234,
                                "authentications": [...]
                        },
                        "mac_auth": {
                                "enabled": true,
                                "pid": 1364,
                                "authentications": [...]
                        },
                        "ports": [...]
                }
        ]
}
example:/#>

Port Access Status Context

For more convenient access to status commands and additional display options, enter the port-access status context:

example:/#> port-access
example:/port-access/#>

Or for a specific instance:

example:/#> port-access 1
example:/port-access-1/#>

Within this context, the following commands are available:

show

Show a summary of all port access status information.

This command displays all four status tables: 802.1X Authentications, MAC Auth Authentications, Ports, and VLAN Assignment. When executed from the general port-access context (without a specific instance), it shows information for all configured instances. When executed from a specific instance context, it shows only that instance’s information.

The same output can be obtained in JSON format by using show json.

show dot1x-authentications

Show currently authenticated 802.1X clients.

Displays a table of all currently authenticated 802.1X clients (supplicants).

show mac-auth-authentications

Show currently authenticated MAC addresses.

Displays a table of all currently authenticated MAC addresses using MAC authentication (MAB or accept-list).

show ports

Show port access port status.

Displays a table showing the status of all ports configured for port access.

show vlan-assignment

Show port access VLAN assignment status.

Displays a table showing the VLAN assignment status for each port access port.

Note

A port is considered “Assigned” only when port access has dynamically assigned it to a VLAN (either from RADIUS server or default VLAN), even if the assigned VLAN is the same as the port’s starting VLAN.

show audit

Show port access related log messages from the audit log.

This command serves as a quick way to access relevant audit log messages related to port access directly from this context. The messages displayed are the same as those that would appear when viewing the full audit log, but filtered to show only port access related events.

Audit Trail Access Required

Access to the audit log is restricted to user roles with Audit trail view permissions. See the Authorization levels section in the AAA documentation for more information about roles and permissions.

show log

Alias for audit. Show port access related log messages from the audit log.

[no] instance-dividers

Enable or disable dividers between instances in the output of show commands.

This is a non-persistent setting that only affects the display of show commands in this context. When enabled, show commands will include dividers between instances to make it easier to distinguish which information belongs to which instance.

Default: Disabled

Example with dividers enabled

example:/port-access/#> instance-dividers
example:/port-access/#> show
Number of Port Access Instances: 2
Table Instance Dividers        : Enabled


╒ 802.1X Authentications ════════════════════════════════════════════════════╕
│#  MAC-ADDRESS        SUPPLICANT    PORT    SERVER           DATE-ADDED     │
│Instance 1                                                                  │
│1  76:03:0e:ff:ba:ab  supplicant1   eth1    198.19.10.1      Feb 26 16:26:26│
│Instance 2                                                                  │
│No 802.1X Authentications for Port Access Instance 2                        │
└────────────────────────────────────────────────────────────────────────────┘


╒ MAC Auth Authentications ══════════════════════════════════════════════════╕
│#  MAC-ADDRESS        PORT    METHOD                         DATE-ADDED     │
│Instance 1                                                                  │
│No MAC Auth Authentications for Port Access Instance 1                      │
│Instance 2                                                                  │
│1  76:03:0e:eb:11:68  eth3    MAB (198.19.10.1:4000)         Feb 26 16:19:39│
└────────────────────────────────────────────────────────────────────────────┘


╒ Ports ═════════════════════════════════════════════════════════════════════╕
│PORT    METHOD      STATE                           AUTHENTICATED-MAC       │
│Instance 1                                                                  │
│eth1    MAC Based   1 Authentication                76:03:0e:ff:ba:ab       │
│eth2    MAC Based   0 Authentications               -                       │
│Instance 2                                                                  │
│eth3    MAC Based   1 Authentication                76:03:0e:eb:11:68       │
└────────────────────────────────────────────────────────────────────────────┘


╒ VLAN Assignment ═══════════════════════════════════════════════════════════╕
│PORT    ENABLED  STATE       FROM     ASSIGNING-CLIENT   VLAN               │
│Instance 1                                                                  │
│eth1    No       Unassigned  -        -                  -                  │
│eth2    No       Unassigned  -        -                  -                  │
│Instance 2                                                                  │
│eth3    Yes      Assigned    Server   76:03:0e:eb:11:68  VID 30 (vlan30)    │
└────────────────────────────────────────────────────────────────────────────┘