WeOS
5.29.0

# 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.

Note

The behavior described above applies to the default MAC Based port method. See Port Method for information about alternative port methods.

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.

Related Examples and Use-Cases

- 802.1X Basic Setup HowTo
- MAC-Auth using RADIUS (MAB)
- MAC-Auth using accept list
- Dynamic VLAN Assignment with 802.1X
- Dynamic VLAN Assignment with MAC Authentication Bypass (MAB)

## 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.

Note

When using the MAC Based port method (default), a WeOS unit acting as Authenticator will only unlock the port for the authorised MAC address. Other MAC addresses are still blocked on that port. This mode is stricter than defined in the IEEE 802.1X1 standard. With the Port Based method, the entire port is unlocked after successful authentication.

### 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.

Note

For best performance, it is recommended to use IP address (rather than domain name) when defining the RADIUS server.

    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.1X1. 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.

When Using VLAN Assignment

When using VLAN assignment it will not be possible to have any of the port access ports be configured tagged in any VLANs, this will result in a configuration error.

## 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.

Be aware of the network topology when using Port Based method

Just to be clear, be mindful when selecting the Port Based method, so that you will not inadvertently provide access for anyone, as mentioned above, this is especially important if multiple clients could be behind the port access port.

Before WeOS 5.28

Support for configuring a specific Port Method did not exist before WeOS 5.28. Before that the implicit port method was what is now referred to at MAC Based and the concept of Port Based was not supported.

## 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.

Basic examples and use-cases related to VLAN assignment

- Dynamic VLAN Assignment with 802.1X HowTo
- Dynamic VLAN Assignment with MAC Authentication Bypass (MAB) HowTo

### 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.

VLAN Interfaces

Only VLANs that have an associated VLAN interface can be used for dynamic assignment. When a VLAN is created, a VLAN interface is automatically created for it, it currently cannot be controlled explicitly.

If the maximum number of VLAN interfaces allowed on the device is reached, the next VLAN that is created will not have an associated VLAN interface created. It should be possible to have up to 64 VLAN interfaces.

### 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.

About These Scenarios

The table below assumes that basic port access authentication requirements are met. Without VLAN assignment enabled, the authentication would succeed. The scenarios describe only the additional checks performed for VLAN assignment that determine whether authentication is granted or denied and what the resulting VLAN assignment for the port will be when authentication is granted.

A | B | C | D | E | F | Status | Details
--- | --- | --- | --- | --- | --- | --- | ---
No | No | - | - | - | - | Allowed | Port remains in statically configured VLAN
No | Yes | No | - | - | - | Denied | No VID and no default VLAN configured
No | Yes | Yes | No | - | - | Allowed | Port assigned to Default VLAN
No | Yes | Yes | Yes | Yes | - | Allowed | Default VLAN matches current assignment
No | Yes | Yes | Yes | No | - | Denied | No preemption, Default VLAN differs from current assignment
Yes | No | - | - | - | - | Allowed | Port remains in statically configured VLAN (VLAN assignment disabled, VID ignored)
Yes | Yes | - | - | - | No | Denied | VID not in allowed VLANs list
Yes | Yes | - | No | - | Yes | Allowed | Port assigned to server-provided VID
Yes | Yes | - | Yes | Yes | Yes | Allowed | VID matches current assignment
Yes | Yes | - | Yes | No | Yes | Denied | No preemption, VID differs from current assignment

- 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:

Attribute Name | ID | Value | Description
--- | --- | --- | ---
`Message-Authenticator` | 80 | Calculated value | Used to protect the integrity of the RADIUS message
`User-Name` | 1 | Username from client | The username provided by the client in the EAPOL request
`Called-Station-ID` | 30 | Port MAC address | The MAC address of the port the client is authenticating on (format: `XX-XX-XX-XX-XX-XX`)
`NAS-Port-Type` | 61 | 15 (Ethernet) | Indicates the physical port type is Ethernet
`Service-Type` | 6 | 2 (Framed-User) | Indicates 802.1X authentication
`NAS-Port` | 5 | Port ifindex | The interface index of the authenticating port
`NAS-Port-Id` | 87 | Port name | Human-readable port name (e.g., `eth1`)
`Calling-Station-ID` | 31 | Client MAC address | The MAC address of the client trying to authenticate (format: `XX-XX-XX-XX-XX-XX`)
`Connect-Info` | 77 | Connection details | Information about the client’s connection, such as link speed
`Framed-MTU` | 12 | 1500 | Standard MTU size for Ethernet
`EAP-Message` | 79 | EAP message | The EAP message from the client’s EAPOL request
`NAS-IP-Address` | 4 | IP address | The IP address used to communicate with the RADIUS server

### 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:

Attribute Name | ID | Value | Description
--- | --- | --- | ---
`Message-Authenticator` | 80 | Calculated value | Used to protect the integrity of the RADIUS message
`Service-Type` | 6 | 10 (Call-Check) | Indicates MAC authentication bypass (MAB)
`Calling-Station-ID` | 31 | Device MAC address | The MAC address of the device trying to authenticate (format: `XX-XX-XX-XX-XX-XX`)
`NAS-Port-Type` | 61 | 15 (Ethernet) | Indicates the physical port type is Ethernet
`Framed-MTU` | 12 | 1500 | Standard MTU size for Ethernet
`User-Name` | 1 | Device MAC address | Same MAC address as `Calling-Station-ID`
`User-Password` | 2 | Device MAC address (encrypted) | Same MAC address as `Calling-Station-ID`, encrypted
`NAS-Port` | 5 | Port ifindex | The interface index of the authenticating port
`NAS-IP-Address` | 4 | IP address | The IP address used to communicate with the RADIUS server

Note

Many RADIUS servers may expect the Call-Check service type for MAB, with the device’s MAC address provided in both the `User-Name` and `User-Password` attributes. Using this service type is a common approach to indicate to the RADIUS server that MAC authentication bypass (MAB) is being performed.

#### Attributes with Service-Type Authenticate-Only

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

Attribute Name | ID | Value | Description
--- | --- | --- | ---
`Message-Authenticator` | 80 | Calculated value | Used to protect the integrity of the RADIUS message
`Service-Type` | 6 | 8 (Authenticate-Only) | Alternative service type for MAC authentication
`Calling-Station-ID` | 31 | Device MAC address | The MAC address of the device trying to authenticate (format: `XX-XX-XX-XX-XX-XX`)
`NAS-Port-Type` | 61 | 15 (Ethernet) | Indicates the physical port type is Ethernet
`Framed-MTU` | 12 | 1500 | Standard MTU size for Ethernet
`NAS-Port` | 5 | Port ifindex | The interface index of the authenticating port
`NAS-IP-Address` | 4 | IP address | The IP address used to communicate with the RADIUS server

Note

The Authenticate-Only service type is provided for backwards compatibility. Note that when using this service type, the `User-Name` and `User-Password` attributes are not included in the request. Many RADIUS servers commonly expect the Call-Check service type for MAB.

## 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:/#>

Column | Description
--- | ---
# | Sequential entry number
MAC-ADDRESS | MAC address of the authenticated client
SUPPLICANT | Supplicant username provided during authentication (if available)
PORT | Port name where the client is authenticated (e.g., eth1, eth2)
SERVER | IP address of the RADIUS server that authenticated the client
DATE-ADDED | Date and time when the client was authenticated

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:/#>

Column | Description
--- | ---
# | Sequential entry number
MAC-ADDRESS | MAC address of the authenticated client
PORT | Port name where the client is authenticated
METHOD | Authentication method: “MAB ()” for RADIUS-based authentication, or “accept-list” for local list authentication
DATE-ADDED | Date and time when the client was authenticated

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:/#>

Column | Description
--- | ---
PORT | Port name (e.g., eth1, eth2)
METHOD | Port method: “MAC Based” or “Port Based”
STATE | For MAC Based: number of authenticated clients (e.g., “2 Authentications”). For Port Based: “Locked” or “Unlocked”
AUTHENTICATED-MAC | Comma-separated list of MAC addresses currently authenticated on the port

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:/#>

Column | Description
--- | ---
PORT | Port name
ENABLED | Whether VLAN assignment is enabled for the port (Yes/No)
STATE | Assignment state: “Assigned” or “Unassigned”
FROM | Source of VLAN assignment: “Server” for RADIUS-provided, “Default” for default VLAN, or “-” if unassigned
ASSIGNING-CLIENT | MAC address of the client that triggered the VLAN assignment
VLAN | Assigned VLAN in the format “VID ()”, or “-” if unassigned

##### Instance-Specific Status

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

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

Tab Completion

The command supports tab-completion for the existing instance IDs.

##### Audit Log

To view port access related audit log messages:

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

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.

##### 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)    │
      └────────────────────────────────────────────────────────────────────────────┘

1. IEEE 802.1X-2004: Port-Based Network Access Control, IEEE Standard for Local and metropolitan area networks ↩↩

« Previous Next »