Support FS Models S5860-24MG-U, S5860-24XMG, S5860-48XMG-U and S5860-48XMG

PICOS 4.4.3.13 release for FS models S5860-24MG-U, S5860-24XMG, S5860-48XMG-U and S5860-48XMG.

S5860-24MG-U has 24x5G copper ports, 4x25G SFP28 ports.

S5860-24XMG has 24x10G copper ports, 4x10G SFP+ ports and 4x25G SFP28 ports. 

S5860-48XMG-U/S5860-48XMG has 48x10G copper ports, 4x25G SFP28 ports and 2x40G QSFP+ ports.

Support FS model N8560-32C

PICOS 4.4.3.8 only release for FS model N8560-32C.
N8560-32C has 32x100G QSFP28 ports.

Support FS Models S5860-20SQ and S5860-24XB-U

PICOS 4.4.3.3 release for FS models S5860-20SQ and S5860-24XB-U.

S5860-20SQ has 20x10G SFP+ ports, 4x25G SFP28 ports and 2x40G QSFP+ ports.
S5860-24BX-U has 24x10G copper ports, 4x10G SFP+ ports and 4x25G SFP28 ports.

Support FS Models S5810-48TS, S5810-48FS, S5810-28FS and S5810-28TS

PICOS 4.4.3.2 release for FS S5810 Series switches.

S5810-48TS has 48x1G copper ports, 4x10G SFP+ ports.
S5810-48FS has 48x1G SFP ports, 4x10G SFP+ ports.
S5810-28FS has 8x1G copper ports, 28x1G SFP ports, 4x10G SFP+ ports. The 8x1G copper ports and first 8x1G SFP ports are combo ports.
S5810-28TS has 28x1G copper ports, 4x1G SFP ports, 4x10G SFP+ ports. The last 4x1G copper ports and 4x1G SFP ports are combo ports.

Support FS model S5810-48TS-P

PICOS 4.4.3.1 only release for FS model S5810-48TS-P.
S5810-48TS-P has 48x1G copper ports, 4x10G SFP+ ports.

Support FS models N5850-48S6Q,N8550-48B8C and N8550-32C

From 4.4.2.2 PICOS support FS switches N5850-48S6Q, N8550-48B8C and N8550-32C.
N5850-48S6Q has 48x10G SFP+ ports, 6x40G QSFP ports.
N8550-48B8C has 48x25G SFP28 ports, 8x100G QSFP28 ports and 2x10G SFP+ ports.
N8550-32C has 32x100G QSFP28 ports, 2x10G SFP+ ports.

Support AS4625-54P and AS4625-54T

AS4625-54P and AS4625-54T are Gigabit platforms of AS4625-N series. Each of these 2 platforms has 48x1000BASE-T ports, and 6x10G SFP+ ports and 2x1G me ports path to CPU. AS4625-54P is a PoE capable platform of which the ports from ge-1/1/41 to ge-1/1/48 support IEEE802.3bt standard with up to 90W power delivery, and the rest 1000BASE-T ports from ge-1/1/1 to ge-1/1/40 supports IEEE802.3at and IEEE802.3af with up to 30W delivery.

IPv6 ND Inspection

IPv6 Neighbor Discovery (ND) Inspection is a security feature designed to enhance the protection of IPv6 networks by managing and validating Neighbor Discovery Protocol (NDP) messages, which are essential for the proper operation of IPv6 communication. Please have the details by reference document IPv6 Neighbor Discovery Inspection.

IPv6 ND Snooping

IPv6 Neighbor Discovery (ND) Snooping is a security feature that safeguards IPv6 networks to prevent various types of attacks. It functions similarly to ARP (Address Resolution Protocol) Snooping in IPv4 networks. Please have the details by reference document IPv6 Neighbor Discovery Snooping.

MPLS

MPLS (Multiprotocol Label Switching) operates between the link layer and the network layer in the TCP/IP protocol stack. It offers connectivity services to the IP layer while leveraging services from the link layer. Unlike traditional IP forwarding, MPLS uses label switching to direct traffic through the network. Please have the details by reference document MPLS Configuration.

PIM BSR (Bootstrap Router)

Dynamic RP allows multiple PIM devices within a PIM domain to be configured as C-RPs (Candidate RPs). Among these C-RPs, an RP is determined through an election process. The BSR aggregates information from all C-RPs in the network into an RP Set using Bootstrap messages and distributes it to all PIM devices. Each PIM device uses the RP Set to calculate and compare based on consistent rules, ultimately selecting an RP from the available C-RPs. Please have the details by reference document PIM Configuration Guide.

Ingress Buffer

Supports ingress buffer management, including guaranteed/shared/headroom management. Please have the details by reference document Configuring PFC Buffer.

PFC Watchdog Manual Control

The PFC Watchdog feature detects and resolves PFC (Priority Flow Control) deadlocks. Recovery methods include both automatic and manual recovery, allowing users to choose the appropriate approach for resolving deadlock scenarios. Please have the details by reference document Configuring PFC Watchdog.

PFC Deadlock Prevention

To avoid PFC deadlock issues, the DSCP value and corresponding Dot1p priority of the message can be modified so that the modified message can be forwarded using the new DSCP value in the new Dot1p priority queue, avoiding messages with the same DSCP value from remaining in PFC deadlock state. Please have the details by reference document Configuring PFC Deadlock Prevention.

Easy ECN

Explicit Congestion Notification (ECN) is a congestion notification mechanism operating at the IP and transport layers, serving as an extension to the TCP/IP protocol. With Easy ECN, users can enable WRED (Weighted Random Early Detection) policies, configure WRED thresholds, and set the maximum packet loss probability to manage network congestion more effectively. Please have the details by reference document Configuring Easy ECN.

DLB (Dynamic Load Balance) 

DLB breaks through the limitations of traditional static hash mechanisms by introducing timestamp and real-time load measurement factors (port bandwidth load, queue size) to optimize load balancing in both time and bandwidth space dimensions, providing a dynamic and intelligent hash mechanism. Please have the details by reference document /wiki/spaces/PicOS44sp/pages/178585601.

Standby IP Address

In cases where the management port cannot connect to the DHCP server and no static IP has been set through CLI during the switch's startup, it will default to using the secondary management IP address 192.168.1.1. This IP address serves as a backup, allowing management of the device even if DHCP services are unavailable. It is primarily used when the management port is directly connected to a PC, ensuring uninterrupted device management via this IP address. Please have the details by reference document Default Settings for Out-of-band Management Interface.

Perpetual PoE

Perpetual PoE (also known as hot-start uninterruptible power supply or permanent PoE) refers to the ability of Power Sourcing Equipment (PSE) to continue providing power during a system restart. This includes restarts initiated through CLI commands such as "request system reboot" or by rebooting under the Linux shell. Additionally, it supports uninterrupted power during system upgrades, including upgrades triggered via CLI or Linux-based upgrade methods. This feature ensures that PoE-powered devices remain operational even when the system is restarting or undergoing an upgrade. Please have the details by reference document Configuring Perpetual PoE.

PFC/ECN

GRPC monitoring PFC and ECN, in conjunction with gRPC, can provide PFC pause frame counts, PFC deadlock monitoring and ECN-marked packet counts for statistical queries. Please have the details by reference document PFC and ECN Statistical Reporting through gRPC.

DHCP Server Enhancement

In versions prior to 4.5.0E, clients were unable to obtain an address in a DHCP relay scenario. However, starting from version 4.5.0E, this issue has been resolved, and the system now fully supports DHCP address assignment in relay scenarios.

DHCP ZTP

After enabling the DHCP server with PicOS, address pools can be configured to allocate IP addresses to clients, along with additional network information such as gateway, DNS server addresses, log server addresses, TFTP server addresses, boot file names, and other options. These configurations are applied and synchronized with the clients as addresses are allocated. Please have the details by reference document Zero Touch Provisioning (ZTP).

PIM over GRE

PIM can be configured on GRE tunnel interfaces. Multicast traffic can go through GRE tunnels and reach to the receivers. PIM over GRE is used in scenarios where multicast traffic needs to be extended across unicast networks or when multicast traffic needs to be isolated from certain parts of the network. This feature is not supported on N22XX platforms.

Support BGP dot & dot+ AS-notation

When configure the BGP AS number, an AS2B and AS4B value can be presented by using two numbers separated by a period.
XorPlus/New Feature

DHCP Relay over GRE

With DHCP relay enabled, to have the IP address, the DHCP DISCOVERY and REQUEST packets from a host can go through a GRE tunnel to reach the remote DHCP server. And on the other hand, the DHCP OFFER and ACKNOWLEDGE packets from the DHCP server can return back to the host through the GRE tunnel. Both IPv4 and IPv6 are supported in case of DHCP relay over GRE.

Support EVPN MAC Mobility

When a host moves from one Ethernet segment to another segment in the EVPN network, Provider Edge (PE) switches will identify the host MAC address from its local interfaces or from remote PE devices. By means of MAC mobility extended community, the PE switches can determine the correct location of the MAC address location. With EVPN MAC mobility, the MAC address will not be learned on multiple interfaces on a specific PE switch. That could prevent traffic loop in case such as VRRP over EVPN network.

Overlay Host Routes over VPLAG

The outgoing ports of EVPN overlay host routes can be VPLAG ports when execute "run show route forward-host ipv4 all". Therefore, in case of EVPN multi-homing deployment, the L3 traffic from a host can be routed out VPLAG port and reach to the remote host via VXLAN tunnel.

DHCP Server Enhancement

In versions prior to 4.5.0E, clients were unable to obtain an address in a DHCP relay scenario. However, starting from version 4.5.0E, this issue has been resolved, and the system now fully supports DHCP address assignment in relay scenarios.

DHCP ZTP

After enabling the DHCP server with PicOS, address pools can be configured to allocate IP addresses to clients, along with additional network information such as gateway, DNS server addresses, log server addresses, TFTP server addresses, boot file names, and other options. These configurations are applied and synchronized with the clients as addresses are allocated. Please have the details by reference document Zero Touch Provisioning (ZTP).

PBR ECMP

PBR (Policy-Based Routing) action supports not only specifying a next-hop router or modifying DSCP values, but also enables the use of nexthop-group for ECMP (Equal-Cost Multi-Path) routing, allowing for more advanced and efficient traffic distribution across multiple paths.

[PIM CLI] PIM RP Commit Failed Due to FRR Issue

Merge FRR issue #12978: pimd: IN_MULTICAST needs host order. The bug is fixed in 4.4.3.

Add "show lacp ~" & "show mlag ~" Command in tech_support File

From the tech_support file, users can get LACP and MLAG debug informations.

[Eth0 DHCP] DHCP Process is not Run if Set Eth0 DHCP when Eth0 is not Connected to DHCP Network.

In Debian default behavior, if eth0 cannot get IP address the DHCP process will be killed, 4.4.3 fix this issue. When eth0 is down or some reason cannot get IP address, the DHCP process still exist.

[CLI]: Configurations that Commit Failed Cannot be Removed, which Results in Any Subsequent Configurations Cannot Commit Successfully

This issue is introduced in PICOS 4.4.2 and fixed in 4.4.3. When use the 'exit discard' command to enter the operation mode from the configuration mode with failed committed configurations, the failed committed configurations cannot be removed correctly from the command tree, which causes committing one new command failed as all the failed configurations are also committed again. This results in any subsequent configurations cannot commit successfully.

[7326]: Failed to Install PICOS Version using ONIE

In previous versions, PICOS supports AS7326_56X hardware label_revision from R01F to later. From PICOS 4.4.2.2, PICOS also supports AS7326_56X old label_revision R01A - R01E.

Mroute Counters are Incorrect

The numbers of statistic counters are not correct when execute “run show mroute count”. For example, the number of "Packets" for a specific multicast group is still grow up even though stop sending multicast traffic. This issue is fixed in 4.4.2.

EVPN BUM Doesn't Work if Configure Same Multicast Group on Different VXLAN VNI

When enable EVPN BUM (Broadcast, Unknown-unicast and Multicast) flooding, if configure multicast group on different VXLAN VNIs (Virtual Network ID), MC VXLAN network interfaces cannot be created and the BUM traffic cannot go through the VXLAN tunnels for specific VXLAN VNIs. This issue is fixed in 4.4.2.

RMAC is Incorrect

In an EVPN multihoming site, if some Provider Edge (PE) switches shut down, on the remote site, the RMAC of the EVPN routes may be the system MAC of the down PE switches. This issue is fixed in 4.4.2.

802.1x authentication-open Doesn't Work

DHCP packets cannot pass an unauthorized NAC (Network Access Control) port even though authentication-open is enabled on this port. This issue is fixed in 4.4.2.

CLI "run show bfd xxxx" Does Not Work

Under default VRF, if enable BFD for a BGP neighbor such as 192.168.1.1, cannot display the BFD information when execute "run show bfd 192.168.1.1". Additionally, CLI command "run show bfd multihop peer" doesn't work. This issue is fixed in 4.4.2.

MTU on L3 Interface

By default, on the side of ASIC pipeline, MTU is not limited on the L3 interface; on the software side, MTU is not limited on the L2 interfaces of the virtual bridge in the kernel. The jumbo packets with size over 1500 can be routed out of the switch if the MTU on the associated physical ports is reset to a number big enough. When path-mtu-discovery is enabled on a specific L3 interface, the MTU configured on this L3 interface will be applied to the ASIC pipeline.

BFD Echo Packets

Under BFD echo mode, the BFD echo packets are trapped to CPU via the default (default-class) CoPP queue instead of BFD (bfd-class) queue. This issue is fixed in 4.4.0.

Delete LAG Port with EVPN Enabled

When delete a LAG port with EVPN multihoming ESI configured, the EVPN multihoming ESI configuration is still there in FRR. This issue is fixed in 4.4.0.

Cannot Display Advertised and Received Routes of Dynamic BGP Neighbor

With regard to a dynamic BGP neighbor such as a BGP neighbor from a configured listening range, cannot display either advertised or received routes of this neighbor when execute "run show bgp neighbor XXXX received-routes" or "run show bgp neighbor XXXX advertised-routes".

Link Activity LEDs Don't Work on AS5835_54X and AS5835_54T

On AS5835_54X and AS5835_54T, when an 100G port (xe-1/1/1 and xe-1/1/4) is split into 4 x 10G ports, the link activity LED of the breakout ports such as xe-1/1/1.1 cannot work.

Consistency of EVPN MAC and ARP/NDP

EVPN MAC addresses and ARP/NDP entries are not consistent in case such as MAC addresses or an ARP/NDP entries are aged out on one EVPN PE switch. EVPN MAC addresses and ARP/NDP entries will be maintained by EVPN module and synced up among PE switches by BGP EVPN messages. They cannot be cleaned up manually.

MAC Update on VPLAG Port

In case of EVPN multi-homing deployment, if turn down the uplink VXLAN network ports, the associated VXLAN tunnels will be down and the MAC addresses learned on the affected VPLAG ports will be removed. And then turn up the uplink VXLAN ports, it may take too long, over 150 seconds sometimes, to get back the MAC addresses on the VPLAG ports when execute "run show vxlan address-table" even though the VXLAN tunnels is up. This is fixed in 4.4.0.

Can't Delete BGP Local AS

With BGP EVPN configuration in a specific VRF, the local AS numbers configured in default VRF are not allowed to be deleted. Will give understandable prompt message when user tries to do it. If delete all BGP configurations, it can work.

BGP Configuration with Route Leak

In previous 4.x.x versions, PICOS allows the BGP configurations as following:
set protocols bgp vrf vrf1 local-as 1
set protocols bgp vrf vrf1 ipv4-unicast import vrf vrf2
set protocols bgp vrf vrf2 local-as 2
That will cause configuration from PICOS CLI is not consistent with FRR configuration. Specifically, FRR will add "set protocols bgp local-as 1" to its configuration automatically, which is not in PICOS CLI. In 4.4.0, if "set protocols bgp local-as 1" is not configured, the above configurations are not allowed.

Flow Control Issue

On AS4625-54T and AS4625-54P, with flow control enabled on the ingress ports, traffic with 1G line speed can pass the switch with no packet loss. If introduce the burst traffic, a small proportional number of packets will be discarded on the ingress ports from which even though pause frames are sent out.

Don't Support OVS

Imports match is not supported in the ICAP table on this AS4625-54T and AS4625-54P with Broadcom Trident3 X2 embedded. That will have significant impact on OVS functionalities. Therefore, OVS is not supported on AS4625-54T and AS4625-54P. 

Delete VRF or L3 Interface with PIM Enabled

If PIM is configured on a L3 interface added to a VRF, when delete the VRF or the L3 interface after delete PIM, and then roll back to the original configuration, PIM will not work with no multicast routes generated.

Configuration Limitation of PIM over GRE

If configure PIM on a GRE interface, PIM should be configured on the GRE underlay L3 interface too. Otherwise, PIM cannot build the session with the remote neighbor on the other side of GRE tunnel. 

RMAC Update in EVPN Multihoming Deployment

When bounce the up-link of a VTEP switch within an ESI in case of EVPN deployment, the remote RMAC with regard to an L3VPN may not be synced up to this PE VTEP switch. This issue could happen if reboot the PE VTEP switches. 

Failed to Be Authenticated by Going with ClearPass TACACS+ (4.3.3.3)

If connect to a ClearPass TACACS+ sever, a user is failed to be authenticated with prompt message "authentication error , wrong password". This issue is fixed in 4.4.0.

Ports Are UP During PICOS Bootup (4.3.2.3)

The ports on platforms with external PHY such as AS5835_54T or AS5812_54T may be up even though PICOS is not ready due to bootup. The traffic received on these ports will be dropped because these ports cannot transmit traffic under this circumstance. In case of MLAG configured on these ports, may lead to long time (2 to 3 minutes) traffic loss during bootup of one MLAG spine switch.

MSTP Process Crash (4.3.3.3)

The process of MSTP may crash in the environment of running MSTP over MLAG. This issue is fixed in 4.4.0.