Power Inline Force-On Command

The power inline force-on command was introduced in version 4.10.3.26 to resolve field compatibility issues where certain powered devices could not be detected or powered up. Some devices fail the switch's normal power-on validation process due to class overcurrent conditions, preventing them from receiving power even though they would function properly once powered.

The power inline force-on {enable | disable} command provides administrators with manual override capability to force power delivery to connected devices that fail the switch's standard detection and classification process. When enabled, the command bypasses the normal detection and classification phases, allowing the switch to deliver power directly to devices that would otherwise be rejected. Administrators should enable this feature selectively and only when normal power delivery fails, as bypassing standard safety checks may pose risks to non-compliant devices.

The command includes a safety warning prompting administrators to confirm their action: “Force delivering power to the connected device may damage it. Are you sure? (Y/N)[N]”

“dot1x timeout tx-period” Range Change

In earlier versions, the supported range for the seconds parameter in the dot1x timeout tx-period seconds command was 30–65535 seconds. As of version 4.10.3.26, the supported range has been extended to 1–65535 seconds. This enhancement provides greater flexibility when configuring this parameter.

802.1x Unauthorized Ports – Unidirectional Traffic Blocking

In earlier C1300X versions, both ingress traffic (traffic from the supplicant to the switch interface) and egress traffic (traffic from the switch interface towards the supplicant) are blocked for an IEEE 802.1X unauthorized port. This provides a high security level - until a supplicant successfully authenticates, no traffic is allowed in either direction, preventing unauthorized access or data leakage.

However, in some cases it is required to block only ingress traffic and allow egress traffic even if the interface is not authorized. An example of a protocol that requires only ingress traffic blocking is Wake-on-LAN (WoL). WoL requires that a “magic packet” be sent to the sleeping client to wake it up – even if the client is not authenticated. If the port blocks egress traffic (from the network to the supplicant), the WoL packet cannot reach the device, preventing it from waking up. Allowing egress traffic on an unauthorized port also allows IT administrators to send configuration or management traffic to endpoints before authentication.

As of version 4.10.3.26, a new setting defines whether both ingress and egress traffic are blocked on an 802.1X unauthorized interface, or only ingress traffic. The default behavior is to block traffic in both directions for an unauthorized interface. The configuration is applied only to interfaces that are in the 802.1X multi-session mode. Interfaces that are in the multi-host or single-host mode continue to block traffic in both directions even if the command was configured on the interface.

The following CLI commands were added or updated to support this feature:

• dot1x control-direction {both | in} – defines the direction of traffic that is blocked on an unauthorized interface

• show dot1x – the output of the command was modified to display the control direction setting

RADIUS Attribute 32 (NAS-Identifier) Support

As of version 4.10.3.26, support was added for including RADIUS Attribute 32 (NAS-Identifier) in RADIUS Access-Request and Accounting packets. By default, the device does not send this attribute. Users can explicitly enable transmission of Attribute 32 using the radius-server attribute 32 include-in-access-req and/or radius-server attribute 32 include-in-accounting-req commands. When enabled, the NAS-Identifier is sent using the device hostname by default. An optional format parameter allows users to configure a custom NAS-Identifier string; in this version, support is limited to a user-defined string format.

This feature is configured through the CLI only and is not supported by the GUI management interface. GUI support is planned for a future release.

Extended SNMPv3 Authentication and Privacy Password Length

As of version 4.10.3.26, the maximum supported length for SNMPv3 authentication and privacy passwords has been increased from 32 characters to 64 characters. This enhancement applies to SNMP users configured using the snmp-server user command and supports both authentication and privacy credentials.

Extending the supported password length provides greater flexibility when aligning SNMPv3 configurations with modern security policies and external authentication standards that mandate longer credentials. This improvement enables stronger password selection without impacting existing configurations, as previously supported password lengths remain valid.

RFC 2863 Counter32 and Counter64 Interface Packet Counters

As of version 4.10.3.26, all unicast, multicast, and broadcast input and output packet counters defined in RFC 2863 were updated to align with the standard definitions for Counter32 and Counter64 types. In previous versions, counters such as ifInUcastPkts in the ifTable MIB were incorrectly reported as Counter64, which did not comply with RFC 2863 requirements.

With this update, ifInUcastPkts and similar RFC 2863 counters are now reported as Counter32, while the corresponding high-capacity (HC) counters (for example, ifHCInUcastPkts) provide Counter64 statistics. This follows the RFC requirement that 32-bit counters must remain available even when 64-bit counters are supported.

This change improves standards compliance and interoperability with SNMP management and monitoring systems that expect strict RFC 2863 behavior, while still supporting high-traffic interfaces through HC counters for accurate long-term statistics.

Syslog over TCP Support (RFC 6587)

As of version 4.10.3.26, support was added for syslog transmission over TCP in accordance with RFC 6587, in addition to the existing syslog over UDP support. To support this new behavior, the logging host command was enhanced with the [transport {udp|tcp}] [port <port-number>] parameter, allowing users to explicitly configure the transport protocol and destination port for each syslog server.

Supporting syslog over TCP provides increased reliability for log delivery, ensuring that critical system events are not lost due to packet drops, which can occur with UDP-based transport. This added flexibility allows users to align syslog behavior with network policies, firewall requirements, and log-collection infrastructures that mandate TCP-based logging, while maintaining backward compatibility with existing UDP configurations.

Syslog – Username Added to Logging Enable/Disable Messages

As of version 4.10.3.26, the username and management information are added to the syslog message generated when logging is enabled or disabled (command logging on/ no logging on). This is a logging related security feature (tractility).

Changes to the MAC Table Hash Collision SYSLOG Message

The switch stores learned MAC addresses in a hardware Forwarding Database (FDB) using a hash function to map each (VLAN, MAC) pair to a storage location. When too many MAC addresses happen to map to the same location – a hash collision – the switch cannot store the new entry and generates the %2SWMACTBL-PORTMACHASHFAILED syslog message (for example %2SWMACTBL-N-PORTMACHASHFAILED: Port gi9 ,MAC 72:8d:77:6f:a3:09 : Cannot be added to the FDB (Hash Table Collision)). This is expected behavior inherent to hash-based hardware tables and is not a bug; it may occur in networks with a large number of active MAC addresses.

However, in case of multiple collisions the message may create unnecessary alarm and clutter operational logs. In addition, the message was missing the VLAN ID of the entry, which is an important part of the hash and the FDB entry. To address these issues, as of version 4.10.3.26 the message severity was lowered to debug and the VLAN ID of the entry was added to the message. The new message format (example only) is as follows:

%2SWMACTBL-D-PORTMACHASHFAILED: Port gi9, VLAN 613, MAC 72:8d:77:6f:a3:09 : Cannot be added to the FDB (Hash Table Collision)

No functionality changes were added beyond this change.

rlifPresentTable MIB

In version 4.10.3.26 a new MIB table, rlifPresentTable, was added to report only interfaces that are physically present in the stack. Unlike the standard ifTable, which also includes non-existent interfaces (for example, units not currently part of the stack), this table allows management applications to query only interfaces that actually exist. This simplifies monitoring and polling in stacked deployments where users need to operate solely on active stack members.

CBD Network Probe Version

In Version 4.10.3.26 the CBD Network Probe version was upgraded to version 2.12.1.20260608.

New and Updated GUI Pages

This section lists GUI pages and settings that were added or updated in this version and are not reflected in the features listed above – for example, GUI support that was added for features introduced in earlier versions without GUI support.

Caveats Resolved in Relase 4.10.3.26