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

Multicast over GRE

PIM can be configured on GRE interface. Multicasting traffic and PIM protocol packets can go through GRE tunnels. That can provide multicast connectivity across networks without support multicast such as Internet.

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.

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.

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.