FabricFlow RN v12.x.x.x Rev09 Published 01072022
FabricFlow RN v12.x.x.x Rev09 Published 01072022
RELEASE NOTES
FabricFlow v12.x.x.x
This document provides a summary of the new features, defect corrections, and other
pertinent details for the FabricFlow™ v12.x.x.x release series.
Supported Platforms:
The following Niagara Networks platforms* are supported in FabricFlow v12.x.x.x:
• 2825 • 3299TT • 4248-6XL
• 2845 S2 • 3808 • 4272
• 2847 S2 • 3808E • 4432
• 3299 • 4248-6C • 4540
*Note: Not all platforms are supported for every release. See the “About this Release”
section of each individual release to view the specific platforms that are supported.
Niagara Networks™
FabricFlow v12.x.x.x Release Notes Rev 09
Contents:
1 FABRICFLOW VERSION 12.4 ............................................................................................ 9
APPENDIX D. UPGRADING THE FIRMWARE FROM V10.5 THRU V10.9 TO V12.4 .......... 112
D.1 Upgrading Packet Master Locally Using the GUI ..................................................... 112
Upgrade Paths
Depending on the firmware version you currently have installed, follow one of the applicable
upgrade paths:
If you are currently on a firmware version that is earlier than v10.5, use the following
upgrade path:
1. First, upgrade to v10.5.0. (Refer to the upgrade instructions in the “B-Series Packet
Master Release Notes Rev 08c,” located on the Niagara Support Portal.
2. Then, upgrade from v10.5.0 to v12.4. (Refer to “Upgrading the Firmware from v10.5
thru v10.9 to v12.4” on page 112.)
If you are currently on a firmware version between v10.5 and v10.9, you can upgrade
directly to v12.4. However, this upgrade process requires three installation files. (Refer to
“Upgrading the Firmware from v10.5 thru v10.9 to v12.4” on page 112.)
If you are currently on a firmware version between v10.10.2 and later, you can upgrade
directly to v12.4. This upgrade process requires one installation file. (Refer to “Upgrading the
Firmware to v12.4” on page 116.)
If you are currently on firmware v12.0.0.x to v12.2.2, you can upgrade directly to v12.4.
This upgrade process requires one installation file. (Refer to “Upgrading the Firmware to
v12.4.”) Note: If your device is currently on v12.2, please read “Manage v12.2 to v12.4
Upgrade Accessibility for High CPU Usage” before upgrading to v12.4.
If your device is on v12.1 or 12.1.0.1, then you can upgrade the 3808 and 3808E platforms
directly to v12.3. This upgrade process requires one installation file. (Refer to “Upgrading the
Firmware to v12.4” on page 116.)
NOTE: If your 3808 device firmware is currently on v11.x, please refer to “FabricFlow Release
Notes for v12.1” for information on upgrading to v12.1. Release Notes are located on the
Niagara Support Portal
If your 3299 device is currently on v5.0.3.1, you must first use the migration tool provided to
migrate to v12.0.0.x before you can upgrade to v12.4. The migration tool is necessary to
migrate the system configurations (including the IP address of the device). The migration
tool is based on v12.0.0.x firmware only as the tool is written based on the CLI commands
present in v12.0.0.x. To migrate from v5.0.3.1 to v12.4, perform the following high-level
steps:
1. From v5.0.3.1, migrate the system configurations using the migration tool.
At this point, v12.0.0.x firmware will be loaded with the migrated configurations.
4. Save the current system configuration using one of the following methods:
o In the GUI, navigate to System > Save Configuration to save the current
configuration options.
o In the CLI, use the following command to save the current configuration options:
Niagara# write startup-config
5. Upgrade to v12.4. (Refer to “Upgrading the Firmware to v12.4” on page 116.
Downgrade Paths
If you need to perform a firmware downgrade, please contact a Niagara support
representative for guidance (https://www.niagaranetworks.com/support).
Highlighted Features
As of v12.4, a Support Portal link is provided in the FabricFlow GUI that enables you to
access documentation for the applicable release.
While on a selected GUI page, click the user icon at the top-right corner of the page
and then click Support Portal. The Support Portal Login Screen displays for you to sign
in and view documentation for the current release.
As of v12.4, GRE Tunneling is supported on the 3299 platform. GRE tunneling allows
‘Initiation,’ where the system encapsulates or wraps a packet’s payload (inner packet)
within an outer packet and then delivers that packet directly to a specified endpoint.
You can configure GRE Tunnels through the GUI, CLI or REST API. In the GUI, access
Packet Master > Tunnel Configuration > GRE Tunnel Configuration tab to configure
Initiation for the 3299.
For instructions on how to configure GRE Initiation in the GUI, refer to the “Packet
Broker User Guide v12.4” located on the Niagara Support Portal.
Note: As of FabricFlow v12.4, this feature applies to the following platforms only: 4248-6C
and 4540.
FabricFlow now enables you to strip the MPLS header on one or more Ingress ports. An
MPLS Header Stripping option is available for each port, which is disabled by default.
When enabled, you can strip up to seven labels, and MPLS headers can be stripped for
both L2 and L3 MPLS packets without the need to configure labels.
When MPLS headers are stripped at the port level, traffic is forwarded based on the
configuration maps created. Furthermore, you can have multiple input ports on a
configuration map, where only some of the ports have MPLS header stripping enabled.
In the GUI, you can enable or disable the MPLS Stripping option for a port under
Advanced properties.
In the CLI, use the following command to create the manage MPLS Stripping on an
Ingress port:
Niagara# configure terminal
Niagara(config)# interface ex 0/1
set mpls-stripping {enable | disable }
In the FabricFlow GUI, the System Resources Page now shows the following information
for appliable Niagara Packet Broker platforms:
Note: Not all Niagara platforms will show the CPLD, TPM, or PTP module information.
CPLD Information
Shows the Complex Programmable Logic Device (CPLD) hardware circuit component
currently installed in the device.
• Primary Revision: Displays the revision of the first CPLD. This field cannot be
modified.
• Secondary Revision: Displays the revision of the second CPLD. This field cannot be
modified. (Applicable for certain devices only.)
• Tertiary Revision: Displays the revision of the third CPLD. This field cannot be
modified. (Applicable for certain devices only.)
TPM Information
Shows information about the Trusted Platform Module (TPM) installed in the device for
secure hardware design.
• Device Mode: Displays the type of TPM installed in the device. This field cannot be
modified.
• Firmware Version: Displays the current version of the TPM installed in the device.
This field cannot be modified.
PTP Information
Shows information about the Precision Time Protocol (PTP) module installed in the
device for hardware clock synchronization.
• ASIC ID: Displays the application-specific integrated circuit identifier for the
microchip installed in the device. This field cannot be modified.
• Hardware Revision: Displays the current version of the PTP module hardware
installed in the device. This field cannot be modified.
• SW ID: Displays the current version of the PTP module software installed in the
device. This field cannot be modified.
In the CLI, use the following ‘show’ command to view system resource information for a
device:
Niagara# show system resources all
In v12.4, a new CLI command is available to view device uptime, which is useful for
troubleshooting purposes. Use the following command:
Niagara# show system uptime
You can now view the "show management-if route" information when using the "show
running-config" command. The information displays for both DHCP/Static IP modes.
Each Packetron module installed requires its own firmware to function properly. Typically,
the firmware loaded on Packetron modules is the default Packetron firmware. However,
certain Packetron features require you to install a feature-specific firmware onto the
Packetron module instead of the default Packetron firmware.
Flow slicing is a Packetron processing feature designed to reduce the volume of network
traffic sent to appliance tools. By sending only the most essential parts of the network
traffic, Flow Slicing promotes more efficient packet processing and traffic-flow analysis.
In the FabricFlow GUI, access Packet Master > Packetron Configuration to create a
new Flow Slicing Packetron Profile.
For instructions on how to configure Packetron Flow Slicing in the GUI, refer to the
“Packetron User Guide v12.4” located on the Niagara Support Portal.
In the CLI, use the following command to create the Flow Slicing profile:
Niagara(config)# packetron profile PP1
Niagara(packetron-profile-PP1)#
packetron profile-type flow-slicing
The Flow Slicing feature is also supported in the FabricFlow REST API solution.
Issue Description
NR-7385 Packetron profile name is removed when a profile type is changed via the
GUI.
NR-7504 On the 2825 platform, segment flaps when the HB generation mode is set
to Advanced in the 100G Bypass module.
NR-7543 A configuration map/priority endpoint used with an integer ID causes
system instability.
NR-7633 On the 4432 platform, certain 40G split ports do not receive traffic at Rx
side on split port 0/28.4 when there is bidirectional traffic.
NR-7968 On the 3299 platform, the console hangs when DHCP is configured without
valid DHCP server.
NR-7986 Remove the condition that SFP must be present from the Link Mode option
NR-8155 in the Online Help and User Guide.
NR-5742 Cannot install multiple L2 UDB offset base criteria to a configuration map.
NR-5844 When a port is added as an output port in the configuration map with strip
VLAN as advanced action and an egress filter with VLAN priority as a criteria
and permit action is created on the port, traffic will be dropped on the
egress port.
Issue Description
Limitations for the 4540 and 4248-6C platforms
NR-5489 If Port Bypass feature is enabled, you must reserve ports to use Port Bypass
functionality. Reserve the required number of data ports on the Reserved
tab of the Ports page. Once a port is reserved, it is not available for user
configuration; instead, it will be used specifically for Port Bypass until it is
no longer reserved. Additionally, if needed, one port must be reserved for
each port in a port-channel.
NR-6330 Microburst functionality is not supported.
NR-6270 L3 MPLS Strip advance action (via Configuration Map > Filter > Edit) is not
supported.
NR-6584 If an incoming packet with OuterVLAN as 4001 hits the configuration map
which has any filter criteria and advanced action as NONE, OuterVLAN 4001
will be stripped in the outcoming packet. The same applies to any
InnerVLAN, if present.
NR-6604 In L3 GRE Initiation and termination, Incoming VLAN will be retained in the
outer Ethernet frame of outgoing packet.
NR-6648 Untagged traffic will be filtered and forwarded when VLAN priority 0 is
configured as filter criteria in a configuration map.
NR-7012 The 4540 platform does not support mixed-speed SFP combinations, such
NR-7036 as 25G, 10G and 1G, in one group of ports. The ‘set force-speed’ setting in
the GUI or CLI is applied to all four ports from the group.
Additional Limitations
NR-6975 The system will not allow save configurations if there is already no storage
space left in the Flash the available space is not enough to hold the new
configuration information. In such cases, users will see a message in the
console that states "MSR Flash storage is nearly full and failed to save the
configurations," and a SYSLOG related to the Save failure also displays
(which is expected).
NR-8144 On 3299 platforms for v12.4, the following restriction applies:
• In general, if backup files were already created in a previous version,
they should not be removed as the files may be needed for restore
and use.
• However, if this causes a problem when saving additional backup
files, remove the old files and then save the new backup files.
Highlighted Features
Niagara Networks is proud to introduce two new network packet broker platforms: Niagara
4248-6C and Niagara 4540. Both platforms are available in a 1U form factor and support a
robust set of packet broker and bypass features, including the powerful Packetron module
for advanced packet processing capabilities.
The Niagara 4248-6C comes in a 1U, fixed-configuration chassis unit that has 54 front-panel
ports. There are 48 x 100M/1G/10G/25G SFP+ ports and 6 x 40G/100G QSFP28 ports on the
front panel. Additionally, the FabricFlow v12.x.x.x supports split-port capabilities to break
down the port speed on a 1x40G or 1x100G port, across several different child ports, such
as 4x10G or 4x25G ports respectively (based on Packetron module presence).
Chassis Description
4248-6C-MN-AC 4248-6C main chassis AC, includes two field replaceable power
supply units and two field replaceable fan units. OVP Enabled for
up to 2 rear Packetron modules (sold separately). Includes License
for 48 ports of 10/25Gb and 6 ports of 40/100Gb. Transceivers sold
and ordered separately.
4248-6C-MN-DC 4248-6C main chassis DC, includes two field replaceable power
supply units and two field replaceable fan units. OVP Enabled for
up to 2 rear Packetron modules (sold separately). Includes License
for 48 ports of 10/25Gb and 6 ports of 40/100Gb. Transceivers sold
and ordered separately.
Refer to the Niagara 4248-6C Quick Start Guide for more details about this new platform.
The Niagara 4540 is also a fixed network packet broker designed to provide 1G/10G/25G and
40G/100G connectivity.
The 4540 is a 1U, fixed-configuration chassis unit with 36 front-panel ports. There are
28 x 40G/100G QSFP28 ports and 8 x 25G SFP28 ports on the front panel. The 25G ports also
support 1G/10G port connectivity.
Chassis Description
4540-MN-16P-AC 4540 main chassis AC, includes two field replaceable power
supply units and two field replaceable fan units. Supports 28
ports of 40/100Gb and 8 ports of 10/25Gb. OVP Enabled for up
to 2 rear Packetron modules (hardware modules and
applications sold separately). Includes License for 16 ports of
40/100Gb, 8 ports of 10/25Gb. Transceivers sold and ordered
separately.
4540-MN-16P-DC 4540 main chassis DC, includes two field replaceable power
supply units and two field replaceable fan units. Supports 28
ports of 40/100Gb and 8 ports of 10/25Gb. OVP Enabled for up
to 2 rear Packetron modules (hardware modules and
applications sold separately). Includes License for 16 ports of
40/100Gb, 8 ports of 10/25Gb. Transceivers sold and ordered
separately.
4540-LC-28P 4540 license upgrade to activate ports 17 through 28
(40/100GbE).
Refer to the Niagara 4540 Quick Start Guide for more details about this new platform.
The Niagara 4248-6C and 4540 platforms offer the following rear modules that can be
installed on the back of the units. Note: The rear modules are not hot swappable.
Fan Modules Packetron Modules
The new packet broker platforms ship with two fan modules that are installed on the back
panel. Each module has two fans, for a total of four fans.
Both platforms also support up to two rear Packetron modules, supporting 200G processing
capability. The Packetron IO modules have enhanced packet processing capabilities to
reduce the processing load on the network packet broker. The Packetron module resembles
the fan module, but there is a built-in Packetron port on the inside of each module.
Note: The rear-panel Packetron module does not have a status LED. (NR-5546)
Refer to the Niagara Packetron User Guide for more details about using Packetron.
Module Description
FXD-PKTRN-A-S Packetron processor acceleration module. Rear module. Up to
100Gbps processing. Includes Packet Slicing software licensing. 64GB
RAM. 512GB SSD. For FixedBroker product line.
FXD-PKTRN-A2-S Packetron processor acceleration module. Rear module. Up to
100Gbps processing. Includes Packet Slicing software licensing. 96GB
RAM. 512GB SSD. For FixedBroker product line.
FXD-PKTRN-A3-S Packetron processor acceleration module. Up to 100Gbps
processing. Includes Packet Slicing software licensing.
96GB RAM 1TB SSD
The FabricFlow system now displays the COM Express (computer-on-module) vendor and
type information, as well as the module’s BIOS-related data. The COM Express module
integrates core CPU and memory functionality into the network packet broker and bypass
hardware. Each platform’s hardware design may use a different type of COM Express
module. Therefore, knowing details about the type of COM module and BIOS installed helps
to troubleshoot possible device issues or limitations.
In the GUI, the System Resources page (System > System Resources) shows the following
Com Express and BIOS details:
In the CLI, use the following command to display the COM Express and BIOS details:
Niagara# show com-express information
The fans in the 4248-6C and 4540 platforms are not hot swappable as in other Niagara
network packet brokers because the fans are part of the IO modules themselves.
Because of this, you cannot swap out a fan when there is a failure. It requires a system
shut down and the entire IO module replaced.
In the CLI use the “show system resources fan” and “show system resources all”
commands to view fan statuses:
Each fan in the I/O module is mapped to the Packetron module to show where each fan
is in systems with rear I/O module support such as the 4540 and 4248-6C.
To view the IO mapping in the GUI, access the Packet Master > IO Modules page.
In the CLI, use the “show hardware management information” command to view the
fan mapping on the rear panel.
Each Packetron module installed requires its own firmware to function properly. Typically,
the firmware loaded on Packetron modules is the default Packetron firmware. However,
certain Packetron features require you to install a feature-specific firmware onto the
Packetron module instead of the default Packetron firmware.
NR-5880 There is a Speed set configuration There are two workarounds for this
limitation that affects the N4540 device. known issue:
A known limitation exists on the system • Workaround 1: Use only one type of
port speed setting. Customers cannot SFP in a single port group.
use mixed speeds like 25G, 10G, and 1G • Workaround 2: Apply the same force-
in one group ports. speed setting on the N4540 and the
peer device.
The N4540 has two groups of ports that
consist of 4 ports in each group (group-
1: ports 0/29-0/32, group-2: ports 0/33-
0/36).
Customers must use the same types of
SFPs in all four ports from a single port
group, and the peer-side devices must
also have the same types of SFPs in use.
NR-6045 Mixing 10G and 25G is not supported
because the hardware simply does not
support it due to a lack of a 2.5 divider.
Issue Description
NR-6584 If an incoming packet with OuterVLAN as 4001 hits the configuration map
which has any filter criteria and advanced action as NONE, OuterVLAN 4001
will be stripped in the outcoming packet. The same applies to any
InnerVLAN, if present.
NR-6604 In L3 GRE Initiation and termination, Incoming Vlan will be retained in the
outer Ethernet frame of outgoing packet.
NR-6648 Untagged traffic will be filtered and forwarded when VLAN priority 0 is
configured as filter criteria in a configuration map.
NR-7012 The 4540 platform does not support mixed-speed SFP combinations, such
NR-7036 as 25G, 10G and 1G, in one group of ports.
The N4540 has two groups of ports that consist of four ports in each group
(group-1: ports 0/29-0/32, group-2: ports 0/33-0/36).
The ‘set force-speed’ setting in the GUI or CLI is applied to all four ports
from the group.
Upgrade Paths
Depending on the firmware version you currently have installed, follow one of the applicable
upgrade paths:
If you are currently on a firmware version that is earlier than v10.5, use the following
upgrade path:
7. First, upgrade to v10.5.0. (Refer to the upgrade instructions in the “B-Series Packet
Master Release Notes Rev 08c,” located on the Niagara Support Portal.
8. Then, upgrade from v10.5.0 to v12.3. (Refer to “Upgrading the Firmware from v10.5
thru v10.9 to v12.2” on page 112.)
If you are currently on a firmware version between v10.5 and v10.9, you can upgrade
directly to v12.3. However, this upgrade process requires three installation files. (Refer to
“Upgrading the Firmware from v10.5 thru v10.9 to v12.3” on page 112.)
If you are currently on a firmware version between v10.10.2 and later, you can upgrade
directly to v12.3. This upgrade process requires one installation file. (Refer to “Upgrading the
Firmware to v12.3” on page 116.)
If you are currently on firmware v12.0.0.x to v12.2.2, you can upgrade directly to v12.3.
This upgrade process requires one installation file. (Refer to “Upgrading the Firmware to
v12.3.”) Note: If your device is currently on v12.2, please read “Manage v12.2 to v12.3
Upgrade Accessibility for High CPU Usage” before upgrading to v12.3.
If your device is on v12.1 or 12.1.0.1, then you can upgrade the 3808 and 3808E platforms
directly to v12.3. This upgrade process requires one installation file. (Refer to “Upgrading the
Firmware to v12.3 on page 116.)
NOTE: If your 3808 device firmware is currently on v11.x, please refer to “FabricFlow Release
Notes v12.1” for information on upgrading to v12.1. Release Notes are located on the
Niagara Support Portal
If your 3299 device is currently on v5.0.3.1, you must first use the migration tool provided to
migrate to v12.0.0.x before you can upgrade to v12.3. The migration tool is necessary to
migrate the system configurations (including the IP address of the device). The migration
tool is based on v12.0.0.x firmware only as the tool is written based on the CLI commands
present in v12.0.0.x. To migrate from v5.0.3.1 to v12.3, perform the following high-level
steps:
1. From v5.0.3.1, migrate the system configurations using the migration tool.
At this point, v12.0.0.x firmware will be loaded with the migrated configurations.
4. Save the current system configuration using one of the following methods:
o In the GUI, navigate to System > Save Configuration to save the current
configuration options.
o In the CLI, use the following command to save the current configuration options:
Niagara# write startup-config
5. Upgrade to v12.3. (Refer to “Upgrading the Firmware to v12.3.”)
Downgrade Paths
If you need to perform a firmware downgrade, please contact a Niagara support
representative for guidance (https://www.niagaranetworks.com/support).
Highlighted Features
The 3808E platform now supports GRE Tunnel configuration. GRE tunneling in the 3808E
supports ‘Initiation,’ where the system encapsulates or wraps a packet’s payload (inner
packet) within an outer packet and then delivers that packet directly to a specified
endpoint. GRE tunneling also supports ‘Termination,’ where the packet is decapsulated
or unwrapped to reveal the payload when forwarding to an output port.
The 3808E supports up to 3000 Layer-2 and Layer-3 GRE tunnels, and you can configure
a tunnel in Dynamic mode or Static mode to resolve the destination address
automatically through address resolution protocol (ARP) or by manual configuration
You can configure GRE Tunnels through the GUI, CLI or REST API.
In v12.3 and earlier releases, we used the management MAC address to distribute the
MAC address to data ports. As of v12.3, FabricFlow now uses a device’s uploaded license
file for MAC address allocation.
FabricFlow will parse the license file to obtain the base MAC address as well as the
number of MAC addresses allowed for data ports as specified in the license.
NOTE: Currently, data-port MAC addresses are only used by the GRE, MPLS, and VXLAN
features in FabricFlow.
The following example shows how MAC addresses are determined for data ports in a
device:
Base MAC address: 00:0C:BD:0D:16:5E
Port 0/1 MAC address: 00:0C:BD:0D:16:5F => Base MAC + 1
Port 0/2 MAC address: 00:0C:BD:0D:16:60 => Base MAC + 2
As shown above, once a valid license is uploaded successfully, port MAC addresses are
assigned using the base MAC address +1, +2, +3 and so on, until each port is assigned a
unique address.
NOTE: If there are more data ports than there are available MAC addresses in the license
file, the system will still assign additional MAC addresses to the remaining ports. As a result,
there is a chance for data ports in two or more devices to have duplicate MAC addresses
when ports are assigned outside the boundary of available ports based on the license file
for each device.
The following system scenarios describe how the MAC address allocation policy is
applied in different system configurations:
Scenario 1: Fresh Configuration (with a valid license uploaded before configuring the
system.)
Because a valid license file is uploaded first, a user can configure GRE, VXLAN, or MPLS
Stripping features. Port MAC addresses are assigned using the base MAC address +1, +2,
+3 and so on.
Because no valid license file is uploaded, the port MAC addresses will be 00:00:00:00:00:00.
A user cannot configure any GRE, VXLAN, or MPLS Stripping features.
Scenario 3: Boot up a device with existing system configurations but license is NOT
present.
During a device bootup, if a valid license file is not present in the system, the saved
configurations (such as GRE tunnel, VXLAN tunnel, and configuration map with advanced
action of GRE or MPLS) are moved to Disabled state. Once a valid license file is uploaded,
these configurations will move to Active state automatically.
Scenario 4: Upgrade to v12.3 and then perform a system restore using a saved
configuration from an earlier version (with a valid license file present).
The configurations will be restored successfully. However, after the upgrade, the existing
port MAC addresses will change and are now assigned using the base MAC address +1, +2,
+3 and so on.
Note: When a system is upgraded to v12.3, syslogs are recorded during bootup stating that
the previous port mac addresses will change based on the new MAC address allocation
policy.
Scenario 5: Upgrade to v12.3 and then perform a system restore using a saved
configuration from an earlier version (without a valid license file present).
The configurations will be restored successfully. However, after the upgrade, features using
the data-port MAC addresses (i.e., GRE, VXLAN, or MPLS Stripping) will show as conflicting
configurations in the system.
When a valid license file does get uploaded, the existing Port MAC addresses will change
and will be assigned using the base MAC address +1, +2, +3 and so on. Additionally, the
conflicting configurations that depend on port MAC addresses will resync to use the
changed port MAC addresses.
Note: When a system is upgraded to v12.3, syslogs are recorded during bootup stating that
the previous port MAC addresses will change based on the new MAC address allocation
policy.
The system will allocate the MAC addresses for the split ports during the split operation.
Each split port is assigned a static port MAC address; the assigned port MAC addresses will
remain with each split port even after a port is no longer split (i.e., no-split operation).
Similar to regular ports, if the split-port operation results in additional ports outside the
boundary of available ports based on the license file, the system will continue to assign
port MAC numbers until all ports in the system have a MAC address.
FabricFlow creates bypass segments automatically for modular packet broker platforms.
These segments are created by default based on the hardware and cannot be deleted.
In v12.3 You can also create ‘virtual segments,’ which are user-defined software
segments that can utilize physical data ports as well as Packetron virtual ports (i.e.,
secondary ports) to configure a segment.
NOTE: Packetron virtual ports are only available if the modular packet broker has one or
more Packetron modules installed. Packetron is supported on the N2 2845 and N2 2847
platforms only.
For non-modular packet broker platforms, FabricFlow does not create segments
automatically. All segments must be created as user-defined virtual segments.
Be aware of the following limitations when working with virtual segments in the
FabricFlow system.
• You can create a maximum of 32 virtual segments.
• The Packetron virtual port (i.e., secondary port) can only be used as network ports
in a segment.
• Passive-Bypass is not applicable for virtual segments.
• Tap-Bypass configuration is not supported if one of the segment network ports is a
Packetron virtual port.
• Segment Synchronization IDs can range from 1 to 428).
In v12.3, to prevent possible traffic loss when a firewall appliance is down, you can
configure the client-firewall and server-firewall virtual ports as network ports of a virtual
segment and configure the firewall appliance as a segment appliance.
Using the virtual segment configuration will achieve the following traffic flows, which
prevents possible traffic loss if a firewall appliance goes down:
• If the virtual segment status is Inline, traffic will flow via the firewall appliances.
• If the virtual segment status is Bypass, traffic will flow between the virtual ports of
client-firewall & server-firewall.
The 3808 platforms now support Redundancy configuration to deploy multiple instances
of a network device or traffic path for high availability (HA) within a network environment.
In the GUI, use the Redundancy page to view and define heart-beat and peer detail for
primary and secondary devices when deploying a redundancy solution.
You can now also use the Redundancy page to control the status of device ports when a
device is in Standby state.
For network ports, you can choose to drop (or) forward the network traffic when a device
moves to Standby. For non-network ports, traffic is not forwarded through the
configuration maps when a device is in Standby state. However, you can choose whether
to keep these ports in an operationally Up or Down state when the device is in Standby.
Note: These settings will not have an impact when a device is in Active state.
Be aware of the following restrictions and limitations when configuring redundancy ports
and settings:
NR-4123, NR-4124: Enhance the RADIUS and TACACS Pages for Server
Configuration
Supported Platforms: N2 2845, N2 2847, 3299, 3299TT, 3808, 3808E, 4248-6XL, 4272, 4432
In v12.3, changes were made to better support server configuration through the GUI and
REST API.
Two new traffic modes are available in v12.3 to support Active Tap functionality in the
FabricFlow bypass switch segments.
Tap-Split Mode
In Tap-Split mode, a copy of data traffic from network ports will be forwarded to the
appliance ports (i.e., N1—>A1, N2—>A2), and the traffic between the network ports will
continue to flow. If multiple appliances are present, a copy of the network port traffic will
be forwarded to all the appliance ports (i.e., N1—>A1, A3, N2—>A2, A4). Below is the
packet flow for Tap-Split mode.
Tap-Aggregation Mode
In Tap-Aggregation Mode, a copy of data traffic from both the network ports will be
forwarded to the appliance ports (i.e., (N1+N2)—>A1, A2), and the traffic between the
network ports will continue to flow. If multiple appliances are present, a copy of the
network port traffic will be forwarded to all the appliance ports (i.e., (N1+N2)—>A1, A2,
A3, A4). Below is the packet flow for Tap-Aggregation mode.
In the GUI, you can set these new traffic modes on the Heart-beat tab, located under
Bypass > Segment #/# > Advanced. In the CLI, use the following command to set the
active tap traffic modes:
Niagara(config-bypass-segment)# traffic mode { load-balance | tool-
chain | active-bypass | passive-bypass | tap-split | tap aggregation }
NOTE: These traffic modes require that the Heart-beat mode be set to Manual-Inline. Also,
configuration maps are not visible when an Active Tap traffic mode is used.
In v12.3, you can implement user privileges for input port and output port components
added to a configuration map. The following privilege methods are available:
When one or more configuration map components are added to the input port or output
port on a configuration map, the Hierarchical Privilege method is enabled by default.
With this privilege method, the system looks for the lowest privilege level assigned to a
user for the Ports, Port-Groups, and Configuration Maps privileges, then applies the
lowest privilege found to any configuration maps the user tries to create or modify.
For example, there might be a situation where a user is a member of a user group with
the following privilege levels assigned:
In this scenario, ‘Access’ level is the lowest privilege of the three. When Hierarchical
Privilege is enabled, since the user has only Access-level privilege for port-groups, they
cannot create a configuration map with a port-group added as output. Furthermore, for
existing configuration maps that already have a port-group added as output, the user
will have only Access-level privilege to those configuration maps. This means they cannot
make any changes to the ports or port-groups on the configuration map.
Note: In addition to Ports and Port-Groups, a Virtual Packetron Port is also considered an
input/output component on a configuration map and uses the privilege level assigned to the
‘System’ privilege on the User Group page.
There are two options available on the Configuration Map page, under Advanced
Properties > Hierarchical Privilege tab, which allow you to disable or enable the
Hierarchical Privilege method for input and output ports on a configuration map.
Note: You must have a user account that is a member of the ‘Administrator’ user group to
modify the Hierarchical Privilege settings.
When the Hierarchical Privilege method is disabled for an Input or Output port (or both),
the Component-Level Privilege method becomes enabled. With this privilege method,
the system looks at the privilege level assigned specifically to each individual input and
output component on a configuration map to determine the level of access a user has.
For example, there might be a situation where the Hierarchical Privilege setting is
disabled for the Input port on a configuration map. If a user is a member of a user group
with Ports 0/1, 0/2, and 2/2 privilege levels set to ‘Modify or Full,’ and Port-Groups
privilege level set to ‘Access,’ the user can add, delete, or modify Ports 0/1, 0/2, and 2/2
on a configuration map because the lowest privilege (i.e., Access) is not taken into
account. However, the user will have view-only access to the port-group on the
configuration map; they cannot add, modify, or delete a port group on the map.
A Note about Downgrading and Hierarchical Privilege: If one or both Hierarchical Privilege
options are disabled, and later, changes are made to a configuration map based on the
Component-Level Privilege settings, downgrading to an earlier firmware version may affect
what configuration maps a user can view. This is because earlier versions of the firmware only
support the Hierarchical Privilege method, which means the system will use the lowest privilege
level assigned to the Ports, Port-Groups, and Configuration Maps privilege settings to
determine if a user can view a configuration map.
The FabricFlow system now displays the COM Express (computer-on-module) vendor and
type information, as well as the module’s BIOS-related data. The COM Express module
integrates core CPU and memory functionality into the network packet broker and bypass
hardware. Each platform’s hardware design may use a different type of COM Express
module. Therefore, knowing details about the type of COM module and BIOS installed helps
to troubleshoot possible device issues or limitations.
In the GUI, the System Resources page (System > System Resources) shows the following
Com Express and BIOS details:
In the CLI, use the following command to display the COM Express and BIOS details:
Niagara# show com-express information
Each Packetron module installed requires its own firmware to function properly.
Typically, the firmware loaded on Packetron modules is the default Packetron firmware.
However, certain Packetron features require you to install a feature-specific firmware
onto the Packetron module instead of the default Packetron firmware.
Note: If you are currently on a version of FabricFlow that is earlier than v10.12.3 and you
upgrade to v12.3, the following consideration applies:
If you decide to downgrade Mobile Visibility firmware on a Packetron module from
gsrm-2.0.0 to gsrm-1.0.32, the following error occurs:
Firmware upgrade for module 7 failed: Failed to mount the image.
Pktron Upgrade failed.
When this happens, the Packetron module configuration settings are temporarily cleared.
Note: The above does not apply if you are upgrading from v10.12.3 to v12.3.
We overhauled the previous Packetron L7 Filtering feature for v12.3, and now offer a
brand-new, license-free solution to enforce and monitor application filtering on a
network.
As of v12.3, the previous L7 Filter feature has been replaced with the new license-free
Application Filtering solution.
The new Application Filtering feature uses the power of Packetron to provide
customizable traffic-policy processing based on a variety of application protocols,
categories, and breeds. The protocols are actual applications that you can restrict or
allow, such as Google, YouTube, and many more. Categories let you control traffic by the
type of application traffic that may come through the network, such as email, media, and
more. Breeds allow you to control traffic by the traffic’s indicated threat level, such as
safe or dangerous.
Using an application protocol group combined with one or more traffic policies,
Application Filtering enables you to restrict or allow matching traffic, which is useful when
monitoring and implementing traffic security across a network.
For example, a company could use Application Filtering on applications like Netflix and
Facebook and assign a ‘Drop’ traffic policy action to the filter. As incoming packets flow
through the company’s network, packets matched to Netflix or Facebook are dropped,
while unrestricted application traffic packets are forwarded as normal, as shown in the
above diagram.
In this example, using the Application Filtering profile essentially restricts employee
access to those unauthorized applications, meeting the requirements of the established
work policy.
In addition to Drop and Forward actions that you can apply to incoming traffic, the
Application Filtering feature also allows you to send a copy of matching traffic to an out-
of-band (OOB) appliance, and you can also redirect matching traffic to a firewall.
Application Filtering not only allows you to restrict incoming traffic, you can also use this
filter for the reverse path to control traffic that is forwarded. For example, if an employee
is suspected of using Steam® online video game application at work, the Application Filter
could be used as a monitoring filter. To do this, connect a tap to Packetron and configure
Application Filtering to forward Steam packets. This way, if the employee tries to access
Steam while at work, the packets are forwarded to capture evidence of the employee
breaking work policy.
To deploy Application Filtering on the network, filter profiles are applied to the
configuration maps you create manually in FabricFlow. You can create one or more
Application Filtering profiles and attach them to one or multiple configuration maps.
You can configure the Application Protocols Group(s), the Packetron Application Filtering
Profile, and the Filtering Policy options using the GUI, CLI, or REST API.
In v12.3, the Packetron Packet Slicing feature now has the following Header Offset types
you can choose:
Header Offset Type: Indicates the type of packet to slice when the Offset Slice option is
selected. Choose one of the following: GTP-C, GTP-U, HTTP, HTTPS, IP, IPv4, IPv6, MPLS,
SSH, SCTP, TCP, UDP.
The Packetron Mobile Visibility feature now provides subscriber-aware load balancing as
a method to filter mobile network subscriber traffic more efficiently. In addition to the
core configuration settings for Mobile Visibility, specific options are available in the
Packetron Mobile Visibility profile that allow you filter and load balance GTP-U traffic in
a subscriber-aware manner. Packetron applies actions to the matching subscriber traffic
based on the filter action settings that are specified in the profile.
The following IP-address configurations will enable the system to load balance
uncorrelated GTP-U traffic based on subscriber traffic:
• User IP Address Configuration – User IP Address configuration is matched against
the inner-IP address to identify a subscriber for load balancing. The User IP Address
can have up to 20 IP addresses, along with masking parameters. This option supports
a combination of IPv4 and IPv6 addresses in the same list.
• Gateway IP Address Configuration (Core IP) – The Gateway IP Address uses
gateway protocols to filter subscriber-aware traffic. You can configure up to 10
unique IP addresses for each protocol type, which includes SGW, PGQ, SGSN, GGSN,
and Node B. However, masking is not supported for this configuration method.
For detailed configuration instructions, refer to the “Creating a Subscriber-Aware (GTP-U)
Profile for Load Balancing” section of the “Packetron User Guide v12.3” located on the
Niagara Support Portal.
In v12.3, to prevent possible traffic loss when a firewall appliance is down, you can
configure the client-firewall and server-firewall virtual ports as network ports of a virtual
segment and configure the firewall appliance as a segment appliance.
Using the virtual segment configuration will achieve the following traffic flows, which
prevents possible traffic loss if a firewall appliance goes down:
• If the virtual segment status is Inline, traffic will flow via the firewall appliances.
• If the virtual segment status is Bypass, traffic will flow between the virtual ports of
client-firewall & server-firewall.
For detailed configuration instructions for Inline Decryption, refer to the “Inline
Decryption” section of the “Packetron User Guide v12.3” located on the Niagara Support
Portal.
In the Inline Decryption profile, the Peer Verification option indicates whether to verify
the peer certificate for outbound connections. As of v12.3. when the Peer Verification
option is set to False, the related Certificate Information options become disabled and
are not configurable.
You can now configure what to do with unencrypted or unmatched traffic that flows
through the network for Packetron Inline-Decryption processing. New options are
available when you add a policy to the Packetron Inline-Decryption profile. You can
configure these new options using the GUI, CLI, or REST API.
• Unencrypted Action: When the Default TLS or HTTPS policy type is selected, this
option specifies how to handle unencrypted, non-TSL traffic. Required Option) This
option is mandatory when the policy type is set to Default TLS or HTTPS. Choose from
the following options:
• Deny: Indicates the unencrypted traffic will be dropped. No traffic output will
happen.
• Pass-through: Indicates the unencrypted traffic will be sent from client to
server and server to client without decryption. No secondary output traffic
will happen.
• Pass-through + OOB: Captures the unencrypted client and server traffic for
output to out-of-band appliances.
• Unmatched Filter Action: Specifies how to handle traffic that does not match any
policy type. Choose from the following options:
• Deny: Indicates the unmatched traffic will be dropped. No traffic output will
happen.
• Pass-through: Indicates the unmatched traffic will be sent from client to
server and server to client without decryption. No secondary output traffic
will happen.
• Pass-through + OOB: Captures the unmatched client and server traffic for
output to out-of-band appliances.
• IP & Port Configuration: Specifies destination port and the source IP and
destination IP. (IPv4) Each policy should be configured with a destination
port/port-range. You can select a specific port number or select to use a port
range and then specify the minimum and maximum port. Enter source and
destination IP addresses with optional mask (IPv4). Click the plus sign (+) to
add more rows or the minus sign (-) to remove rows.
For detailed configuration instructions, refer to the “Inline-Decryption Configuration”
section of the “Packetron User Guide v12.3” located on the Niagara Support Portal.
The Inline Decryption Client-side and Server-side Gateway configuration was enhanced
to include a new option – No ARP. When selected, Packetron will learn the MAC address
from the TCP SYN packets.
Therefore, the following three options are available when configuring the MAC Type field:
MAC Type: Indicates how the MAC address is resolved. Dynamic ARP is the default
option. Choose one of the following options:
• Dynamic ARP: Indicates the MAC address is resolved dynamically. If selected,
Packetron will use the ARP to resolve the uplink Gateway MAC address.
• Static: Indicates the MAC address is static. If selected, type the address in the MAC
address field.
• No ARP: Indicates Packetron will learn the MAC address from the TCP SYN packets.
Version 12.3 introduces a way for the system handle individual configuration maps more
efficiently when a Packetron module goes down.
Note: A module topology automatically tries to recover from a failure three times before the
topology process fails.
When a topology fails, a Syslog is generated for each related configuration map that
becomes disabled or moves to bypass. To manage the configuration maps related to a
topology failure, perform the following steps:
1. Review the Syslog to determine the configuration maps that are disabled and
require attention.
2. For each configuration map that is disabled, use the GUI or the CLI to remove the
Inline-Decryption profile from the configuration map and then save the map.
3. Add the same Inline-Decryption profile back to the configuration map and then
resave the map.
Once the profile is added to the configuration map, a topology ID is assigned, and the
traffic will flow based on the configuration map settings.
Additional Features
The Niagara network packet broker now supports Websocket connections for NVC. See
the “NVC v2.9 Release Notes” for more information.
NR-3694, NR-4067: Add Advanced Filter Search for Ports and Port Groups
Supported Platforms: N2 2845, N2 2847, 3299, 3299TT, 3808, 3808E, 4248-6XL, 4272, 4432
The Ports and Port Groups pages now have an advanced Filter dialog box that enables
you to sift through the port or port group records and display only those records that
meet specific search criteria. This is a handy tool when there are a lot of records to
search.
Access Packet Master > Ports > User Ports tab or Packet Master > Port Groups, then
click the Filter button to show the Filter dialog box. Select the filter options
to sift through the port records. Click Apply to display only those ports or port groups
that meet the selected search criteria. This is a handy tool to quickly filter or narrow down
the list when there are a lot of records to search.
The browser tab for the FabricFlow application now shows the device name along with
device model on each GUI browser tab, which helps you to quickly find a device when
multiple browser tabs are open. Also, when you hover your mouse over a GUI browser
tab, the device name and model number displays.
Issue Description
NR-5553 In certain situations, some filters do not install consistently in hardware
while associating a NetFlow profile to a configuration map.
NR-5572 Receiving the following message while associating NetFlow profile:
"Warning: The Packetron modules configuration failed. Packetron actions
will not take effect."
NR-5591 On the 3808, traffic flow is not working as expected in standby device when
HB mode is in Manual Inline.
NR-5624 Port-channel configuration maps are not forwarded to any traffic after a
reload when we have Load Balancing policy.
NR-5667 L2/L3 GRE and Dynamic VXLAN tunnels go down after a device reload.
NR-5896 Microburst status needs to be removed in the Filtering options in 3808 and
3299.
NR-6065 In 4248-6XL v12.2v GUI, a user cannot navigate to other pages in
configuration map filters.
NR-6071 Fan Status 2 on the N2 2847 S2 displays as "Not Operational." This issue
happens inconsistently.
NR-6290 When a user changes the IP mode of the 3299/3299T device from DHCP to
static, the gateway address gets lost and there is the device is unreachable.
Note: This issue does not affect Firefox versions 83 and earlier and versions 87
and later.
NR-3458 Version 12.3 supports switchname with more than 15 characters (up to 64).
v10.12.x supports switchname with a maximum of 15 characters.
If switchname is configured with more than 15 characters and a user tries
to downgrade to v10.12.x with the configuration of v12.2 (saved with write
startup-config in v12.2), then system instability is expected.
Workaround:
Because of this, if you configure v12.2 with a switchname more than 15
characters, and then plan to downgrade to v10.12.x versions, you need to
provide “write startup-downgrade,”
With this downgrade configuration, the switchname will be truncated to 15
characters (if originally configured for more than 15 characters).
This same configuration will work fine in v10.12.x versions without any
system instability.
Issue Description
NR-3700 The system will not allow a user to create two filters having the same
source/destination IP addresses but with different ERSPAN types.
For example, the following filters configuration is not valid:
packetron tunnel erspan t01 srcip 192.168.0.1 mask 32 dstip
10.10.0.1 version v2
packetron tunnel erspan t02 srcip 192.168.0.1 mask 32 dstip
10.10.0.1 version v3
The system will display an error message when a user tries to create and
save the second filter.
NR-3705 Setting force-speed to 10M and 100M is not supported on 1G copper SFPs
with SGMIII interface type configured. On the copper SFPs that use
1000Base-X interface type as the default (Finisar FCLF-8521-3, Finisar
FCLF8521P2BTL, Finisar FCLF8522P2BTL), only 1G speed is supported.
NR-3732 When a user connects two devices using Finisar Active Copper SFP, force
10M on one side and 100M on the other side, after 1-2 minutes, the 10M
side starts flapping.
There is no workaround for this issue. However, setting ports to 100M, 1G,
or Auto speed works fine. This limitation applies to 10M speed only.
NR-5003 L4 IP checksum is always recalculated. This is for L4 headers only.
Important! The v12.2.2 release is supported on the following platforms: 3299 and 3299TT
In v12.2.2, new enhancements were applied to the copper module for the 3299 platform,
which are designed to reduce the negotiation time and limit traffic loss during segment
switching scenarios.
The physical (PHY) layer settings were enhanced for better performance and are now
configurable, if needed, based on the desired peer device settings. You can use the CLI
to customize the following PHY properties for a more optimized link negotiation on the
copper ports (RJ45):
• Master/Slave Mode – Enables you to set the master-slave modes on the 3299
copper ports, which will force a link partner’s ports to have the applicable
master-slave settings when the copper port relays are switched from active to
passive state. This ensures the link partner’s ports will stay in an UP state with
minimal traffic loss.
• Crossover Mode – Enables you to set a fixed crossover mode that will force a
link partner’s ports to be in the proper crossover mode during an active to
passive state. This ensures the link stays in an UP state with minimal traffic loss.
When you configure the copper port optimization at the Bay (slot) level, the underlying
‘crossover’ and ‘master-slave’ mode settings will be applied to all interface ports within
the selected bay. Use the following CLI command to configure these PHY settings at the
bay level:
Niagara# configure terminal
Niagara(config)# set phy-properties { optimized | default } <slotid(0-
7)>
Configuring copper port optimization at the interface (physical port) level requires you
to set the ‘master-slave’ and ‘crossover’ mode settings individually, for each applicable
interface port. Use the following CLI command to configure these PHY settings at the
port level:
Niagara# configure terminal
Niagara(config)# interface ex 1/1
Niagara(config-if)# set master-slave-mode { default | auto | master |
slave }
Please make note of how optimization settings will work based on existing configuration
settings.
• If there are no saved configurations present, all ports are set to ‘Optimized’ at
each boot.
• If configuration settings are saved before a system reload is performed, all ports
are restored based on the saved configuration settings.
• Configured ports will go DOWN and come UP after optimization settings are
made. If the settings are made at the bay level, all the ports within the bay will
go DOWN and UP.
• The last configured setting value (either bay-level or port-level) is always applied
and saved.
Use the following ‘show’ command to view the crossover settings of all the copper
modules in the 3299 device:
Niagara# show port cross-over
Use the following ‘show’ command to view the master/slave settings of all the copper
modules in the 3299 device:
Niagara# show port master-slave
Note: This issue does not affect Firefox versions 83 and earlier and versions 87
and later.
NR-3458 Version 12.2 supports switchname with more than 15 characters (up to 64).
v10.12.x supports switchname with a maximum of 15 characters.
If switchname is configured with more than 15 characters and a user tries
to downgrade to v10.12.x with the configuration of v12.2 (saved with write
startup-config in v12.2), then system instability is expected.
Workaround:
Because of this, if you configure v12.2 with a switchname more than 15
characters, and then plan to downgrade to v10.12.x versions, you need to
provide “write startup-downgrade,”
With this downgrade configuration, the switchname will be truncated to 15
characters (if originally configured for more than 15 characters).
This same configuration will work fine in v10.12.x versions without any
system instability.
Two new traffic modes are available in v12.2.1 to support Active Tap functionality in the
FabricFlow bypass switch segments.
Tap-Split Mode
In Tap-Split mode, a copy of data traffic from network ports will be forwarded to the
appliance ports (i.e., N1—>A1, N2—>A2), and the traffic between the network ports will
continue to flow. If multiple appliances are present, a copy of the network port traffic will
be forwarded to all the appliance ports (i.e., N1—>A1, A3, N2—>A2, A4). Below is the
packet flow for Tap-Split mode.
Tap-Aggregation Mode
In Tap-Aggregation Mode, a copy of data traffic from both the network ports will be
forwarded to the appliance ports (i.e., (N1+N2)—>A1, A2), and the traffic between the
network ports will continue to flow. If multiple appliances are present, a copy of the
network port traffic will be forwarded to all the appliance ports (i.e., (N1+N2)—>A1, A2,
A3, A4). Below is the packet flow for Tap-Aggregation mode.
In the GUI, you can set these new traffic modes on the Heart-beat tab, located under
Bypass > Segment #/# > Advanced. In the CLI, use the following command to set the
active tap traffic modes:
Niagara(config-bypass-segment)# traffic mode { load-balance | tool-
chain | active-bypass | passive-bypass | tap-split | tap aggregation }
NOTE: These traffic modes require that the Heart-beat mode be set to Manual-Inline. Also,
configuration maps are not visible when an Active Tap traffic mode is used.
Note: This issue does not affect Firefox versions 83 and earlier and versions 87
and later.
NR-3458 Version 12.2 supports switchname with more than 15 characters (up to 64).
v10.12.x supports switchname with a maximum of 15 characters.
If switchname is configured with more than 15 characters and a user tries
to downgrade to v10.12.x with the configuration of v12.2 (saved with write
startup-config in v12.2), then system instability is expected.
Workaround:
Because of this, if you configure v12.2 with a switchname more than 15
characters, and then plan to downgrade to v10.12.x versions, you need to
provide “write startup-downgrade,”
With this downgrade configuration, the switchname will be truncated to 15
characters (if originally configured for more than 15 characters).
This same configuration will work fine in v10.12.x versions without any
system instability.
NOTE: Niagara Networks recently migrated to a new project tracking tool. As a result, the
feature numbering convention is now: NR-XXX.
Highlighted Features
The Niagara packet broker has the capability to filter packets based on different fields in
the Ethernet, IP, TCP and UDP headers. As of v12.1, the system can now also filter packets
based on the 3-bit VLAN priority field of the 802.1Q VLAN header.
The QoS VLAN Priority lets you assign a priority to outbound packets that contain the
specified VLAN-ID (VID). This 802.1 priority decides the outbound port queue to which
the packet is sent. Packets in a tagged VLAN carry the 802.1p priority with them to the
next downstream device.
You can use the CLI, REST API, or access Packet Master > Filter Templates > Filter
Criteria tab in the GUI to set VLAN Priority.
FabricFlow v12.2 introduces Microburst Detection for device data ports, Packetron virtual
ports, and Packetron module ports.
Microbursts are small, random spikes in network traffic that happen within a very short
time interval, which can cause network interfaces to become oversubscribed and drop
packets as a result. A key challenge to mitigating microbursts is the ability to detect them
in the first place. Many tools that watch for traffic anomalies usually poll at time intervals
that do not allow for microburst detection. Furthermore, due to the transient nature of
microbursts, they are often missed by standard monitoring tools that average statistics
over multiple seconds.
FabricFlow provides several options to detect and notify users about microbursts that
occur on the various ports in the system.
You can configure Microburst Detection for data ports and Packetron virtual ports in the
GUI, using the Advanced Configuration dialog box on the Ports List page.
NOTE: You can configure Microburst Detection for Packetron module ports using the CLI.
In addition to configuring Microburst Detection, FabricFlow uses Syslog and SNMP Trap
messages to provide notification when microbursts happen. And statistical information
is also available to view in the GUI and CLI, which includes count detail for packets/bytes
dropped due to microburst activity.
For detailed information on how to configure the Microburst Detection feature, and view
microburst-related notifications and statistics, see the “Niagara Packet Broker User
Guide v12.2,” “Niagara Bypass Switch v12.2,” and “Niagara Packetron User Guide v12.2,”
located on the Niagara Support Portal.
FabricFlow now supports IPv6 port egress filtering on packet broker platforms. An egress
filter is applied to a port and helps to filter outgoing data packets before the data leaves the
network. Egress filters can help stop unsafe activity or data from accessing other systems or
networks.
NOTE: If you are configuring one of the following platforms, you must first reserve filter
resources before you can use an IPv6 filter as an egress filter on a port: N2 2845, N2 2847,
4272, 4432, 4248-6XL.
An egress filter must be created as a filter template first before you can apply it to a port.
Once configured, the egress filter is added to a port using the Port Properties page.
For detailed information on how to configure an egress filter on a port, see the “Niagara
Packet Broker User Guide v12.2,” located on the Niagara Support Portal.
The Group Configuration page enables you to set up user groups and specify the ports and
feature privileges to which each group will have access. In previous releases, there was only
a single ‘Config Save’ privilege option that controlled who could use start-up configuration,
flash configuration, and remote configuration save options in the system.
To allow more control over assigning privileges to these save functions, the ‘Config Save’
privilege was separated into the following individual save privileges: Start-up Config Save,
Flash Config Save, Remote Config Save.
Now, any user who needs to perform one or more of the above functions must be a member
of a user group that has the privilege for that function set to Modify or Full. For example, to
select ‘Start-up Config Save’ as a save option, the user should be part of a group that has
Start-up Config Save privilege set to Modify or Full.
NOTE: If Steps 2 and 3 are not performed after an upgrade, the system privileges will function
in the same manner as earlier versions.
Backward Compatibility
When configurations are restored from firmware versions earlier than v12.2, the following
considerations apply:
• Because these are new privileges, whatever value was set for the old ‘Config Save’
privilege, that value is applied to the three new privileges. This is applicable when
configuration is restored from v10.12.0.1, v10.12.1, v10.12.2, or v10.12.3.
• If configuration is restored from firmware versions earlier than v10.12.0.1 the
‘System’ privilege value is applied to the three new privileges.
Privileges for
Privileges for
System Privileges for v10.12.0.1,
versions earlier
Function v12.2 v10.12.1, &
than v10.12.0.1
v10.12.2
1 Save the start-up Start-up Config Start-up Config save Start-up Config save
configuration save privilege set privilege set to Modify privilege set to Modify /
to Modify / Full / Full Full
2 Save the configuration Flash save privilege Flash save privilege Flash save privilege set
to flash set to Modify / Full set to Modify / Full to Modify / Full
3 Save the configuration Remote save Remote save privilege Remote save privilege
to remote server privilege set to set to Modify / Full set to Modify / Full
Modify / Full
4 Restore the System privilege Start-up Config save System save privilege set
configurations from set to Full privilege (or) Flash to Modify / Full
flash / remote server / save (or) Remote save
HTTP / SCP. set to Modify / Full
5 Erase the System privilege System save privilege System save privilege set
configurations set to Full set to Modify / Full to Modify / Full
6 Modify the file name to System privilege Start-up Config save System save privilege set
be saved in flash / set to Full (or) Flash privilege (or) Flash to Modify / Full
remote server Save privilege set save (or) Remote save
to Full (or) Remote set to Modify / Full
save privilege set
to Full
Each Packetron module installed requires its own firmware to function properly.
Typically, the firmware loaded on Packetron modules is the default Packetron firmware.
However, certain Packetron features require you to install a feature-specific firmware
onto the Packetron module instead of the default Packetron firmware.
The Packetron firmware files available for v12.2 release are as follows:
o Default Packetron default firmware: Packetron_Release_6.1.11
o Inline Decryption feature firmware: Packetron_Inline_Decryption_3.1.9
o Mobile Visibility feature firmware: Packetron_Mobile_Visibility_3.0.16
o Tap Decryption feature firmware: Packetron_Tap_Decryption_3.0.7
Note: If you are currently on a version of FabricFlow that is earlier than v10.12.3 and you
upgrade to v12.2, the following consideration applies:
If you decide to downgrade Mobile Visibility firmware on a Packetron module from
gsrm-2.0.0 to gsrm-1.0.32, the following error occurs:
Firmware upgrade for module 7 failed: Failed to mount the image.
Pktron Upgrade failed.
When this happens, the Packetron module configuration settings are temporarily cleared.
Note: The above does not apply if you are upgrading from v10.12.3 to 12.2.
Packetron Mobile Visibility introduces a new ‘Sampling’ feature that allows you to use
GTP-C traffic to sample incoming subscriber-aware traffic, which can then be sent to
various tools that may need the traffic data for further processing or analysis. Subscriber
sampling reduces the amount of traffic volume sent to the different tools, resulting in
more efficient data management and monitoring.
Sampling options are available when configuring a Packetron Mobile Visibility profile in
the GUI, CLI, or REST API.
In addition to the new Sampling feature, Packetron Mobile Visibility also supports a new
‘Whitelist’ feature. A whitelist is a list of IMSI, IMEI, or MSISDN identifiers that can be used
as GTP-C filter match criteria when configuring a Mobile Visibility GTP-C Correlation filter.
Whitelists are configurable through the GUI, CLI, or REST API. A new Whitelist
Management tab is available in the GUI under Packet Master > Packetron > Mobile
Visibility Global Configuration.
You can create a whitelist record in the system and then upload to the record, a whitelist
file that contains a list of entries for the type of identifier match criteria you want to use.
For example, if you want to use IMEIs as match criteria, then you would upload a whitelist
file that has a list of IMEIs and associate it to the whitelist record.
Each whitelist record must be linked to one or multiple Packetron modules and you can
have a maximum of 256 whitelists uploaded to a module.
Once a whitelist record is created, you can then use it as match criteria for a Mobile
Visibility profile with GTP-C Correlation filter.
For detailed information on how to configure Sampling options and Whitelists for
Packetron Mobile Visibility, see the “Niagara Packetron User Guide v12.2” located on the
Niagara Support Portal.
The following table shows a side-by-side comparison of the differences between how
Inline-Decryption was configured previously, and how it is now configured in v12.2.
The Packetron Inline-Decryption feature was enhanced to support URL category filtering.
A URL category is the domain portion of a URL or a list of regular expressions that can
be matched against a URL in HTTPS traffic. You can use this optional category with the
Inline-Decryption feature to filter website URL categories with the purpose to block or
allow access to one or more website URLs.
For example, you can configure a Domain URL category that filters for any URL that ends
with .com. using the following category criteria:
For example:
*.com will match any URL that ends with “.com”
abc.com, cpu.com, niagara.com, etc.
You can also use a RegEx URL category to match any keyword pattern you have in a URL.
The RegEx type follows the same syntax that is used in the Packetron RegEx feature.
For example, you can configure a RegEx URL category that filters for any URL that ends
with /forbidden using the following category criteria:
For example:
/forbidden$ will match any URL that ends with
example.com/a/b/forbidden
“/forbidden”
some.domain/path/forbidden
URL categories are configurable through the GUI or CLI. A new URL Categories tab is
available in the GUI under Packet Master > Packetron > Packetron Configuration to enter
URL category criteria or upload a separate .txt file that contains a list of URL category
criteria.
URL categories are applied to one or more filters created for an Inline Decryption profile.
For detailed information on how to configure URL categories and apply to filters for
Inline-Decryption, see “Niagara Packetron User Guide v12.2” located on the Niagara
Support Portal.
When ‘Transparent’ is selected, ciphers from the client’s ‘client hello’ are used to
negotiate with the server. Then, the negotiated cipher is used for client <-> decryption
connection.
When the gateway MAC address is configured, Packetron will obtain the address directly
from the MAC address field. However, if a user does not configure the Gateway MAC
address, Packetron will use the ARP to resolve the Gateway MAC address.
The gateway MAC address options are available when configuring the Packetron Inline-
Decryption profile.
The MAC type option can be dynamic or static. When set to dynamic, the ARP is used to
resolve the gateway MAC address. When set to static, the MAC Address field becomes
available so that you can enter the static MAC address.
For detailed information on how to gateway MAC address options for Packetron Inline-
Visibility, see the “Niagara Packetron User Guide v12.2,” located on the Niagara Support
Portal.
The packet broker transmits heart-beat packets at user-defined intervals to monitor the
appliance of a bypass segment. In earlier releases, 30 milli-seconds was the lowest
interval supported for heart-beat packet transmission. In v12.2, the packet broker now
supports 10 milli-second intervals for heart-beat packet transmission. Additionally, the
software default for heart-beat packet transmission is now changed to 10 milli-seconds.
Issue Description
NR-2579 Static L2 GRE termination is not working if the key is modified to the same
value for all the tunnels.
NR-2581 System allowing to create GRE tunnels more than the hardware limit when
split ports are used.
NR-2585 The Port Group dialog box displays unexpectedly.
NR-2586 In BCM platforms, traffic loss is observed when switching from primary to
backup ports in a port-channel and vice-versa, which is part of a bypass
segment configuration map.
NR-2587 The MPLS-strip advanced action radio button should be blocked when
output is virtual port.
NR-2590 Unable to modify the VLAN action from GUI.
NR-2594 In fixed NPBs, incorrect traffic is observed on appliance ports, when
Secondary appliance is added to traffic and with user-specific-traffic-flow
and failover mode as 'discard.'
NR-2608 Traffic gets in-discarded at the network ports when the traffic mode is
changed to tool-chain.
NR-2620 IPv6-flow label criteria should be removed from ingress filter in 3808 and
3299 devices.
NR-2756 On platforms 4432 and 4848-6XL, with firmware 10.12.3 installed, users are
unable to change port icon in GUI.
NR-2766 Traffic flow is not as expected when deleting second-to-last egress filter on
the physical port.
NR-2767 Egress Filter on the port disappeared when editing filter criteria of the filter
through CLI.
NR-2771 Critical Appliance heart-beat Type field should be removed in 3808 and
3299 as only one type of Critical Appliance heart-beat Type (Normal) is
supported.
NR-2801 All virtual port configuration maps remain disabled after performing a
restore.
NR-2804 A segment goes to bypass state when bringing primary appliance pair
down.
NR-2819 The Clear Statistics endpoint does not work for GTP correlation, GTP Load
Balance, TLS, and Tunnels.
NR-2832 The system should not allow a user to delete the last profile associated to a
configuration map if their virtual port is part of any map.
Issue Description
NR-2897 When the appliance ports are brought up with tap bypass enabled, this
causes system instability.
NR-2902 Alignment issues exist in the “show configuration map brief” response in
the CLI.
NR-3076 Many of the configurations are not restored properly when upgrading from
v10.12.3/v10.12.0 to v12.2.
NR-3107 Name field is not editable in the Edit Packetron Profile dialog box.
NR-3108 Reset option erases the name of the Inline-Decryption Policy and Filter.
NR-3129 Traffic gets dropped with advanced action tag vlan and egress filter added
with vlan priority for double tagged packets
NR-3153 L2/L3 GRE scaled termination tunnels are not retained after a reload.
NR-3159 When configuring a Mobile Visibility - GTP Correlation profile, the default
filter is removed when a user clicks the Reset button.
NR-3192 The Cancel button on the Bypass Segment > Advanced dialog box does not
work properly.
NR-3226 SNMP parameters from Solarwinds to packet broker device does not work.
NR-3254 Unable to remove SNMP Community index when the special characters are
included.
NR-3255 Non-admin group member should be able to access the 'show user active'
command in the CLI.
NR-3262 Memory leak happens when memory continues to increase for both RAM
and vsz of iss, when download sysconf request is invoked continuously via
script.
NR-3272 When segment mode is changed, the segment mode option for copper
module becomes greyed out in IO Modules page.
NR-3282 IPv4 remote manager service is not configured properly for several services
(SCP, SSH, TFTP).
NR-3456 PSU does not come on after disconnection the plug and then plugging back
into a power source.
NR-3464 When “Max Subscribers” option is changed for Mobile Visibility, a
confirmation dialog box should be invoked.
NR-3483 The system should validate Mobile Visibility "Max Subscribers" and "GSRM
Concurrent Bearer Limit" based on Packetron capabilities.
NR-3499 The GUI should allow the number of filters that are available.
Issue Description
NR-3524 The system should not allow a user to manage remote manager command
when all privileges are set to "None."
NR-3655 A user with "Modify" privilege for System and all other functions set to
"None" should not be allowed to restore the configurations in the GUI with
HTTP local.
NR-3666 NP errors display in the console while adding the maximum number of
Egress filters in the system.
NR-3782 Warning message is not flagged when subscribed maximum bandwidth of
packetron module (>80GB) is reached for particular scenarios in bare-metal
mode.
NR-3837 In Packetron Mobile Visibility, the GUI should not allow filters with a range
over the maximum 1M.
NR-3843 The following error is seen while downloading an SSL certificate from the
remote server: 'Error: Could not open the .pem file.'
NR-3945 User privileges do not work as expected when upgrading the system from
v10.12.3 to v12.2.
NR-3946 Crash seen during bypass segment update from GUI - Inconsistent (v12.2)
NR-3982 A segment does not move to Bypass state under the following scenario:
[ A secondary appliance is configured with strict-backup, and one primary
appliance is down and another primary is inactive.]
NR-4011 Remote Management - Rest IPv4 and IPv6 configuration prefix length
configuration displayed for Notation "Mask."
NR-4066 Bypass segment does not move back to an inline state when traffic
connection is restored after disabling bidirectional mode.
NR-4216 Creating or updating a Port channel with Round Robin port load type fails.
NR-4232 NetFlow GUI - Unable to delete Radius VSA record; NetFlow configure port
is moved to None when a user opens configuration dialog box.
NR-4321 Third Party and VM Modules are not getting updated to configure when a
particular feature is added to Packetron Modules tab.
Note: This issue does not affect Firefox versions 83 and earlier and versions 87
and later.
Issue Description
NR-3458 Version 12.2 supports switchname with more than 15 characters (up to 64).
v10.12.x supports switchname with a maximum of 15 characters.
If switchname is configured with more than 15 characters and a user tries
to downgrade to v10.12.x with the configuration of v12.2 (saved with write
startup-config in v12.2), then system instability is expected.
Workaround:
Because of this, if you configure v12.2 with a switchname more than 15
characters, and then plan to downgrade to v10.12.x versions, you need to
provide “write startup-downgrade,”
With this downgrade configuration, the switchname will be truncated to 15
characters (if originally configured for more than 15 characters).
This same configuration will work fine in v10.12.x versions without any
system instability.
NR-3996 Port speed of SFP FCLF8521P2BTL is supported for 1G only.
NR-4085 The left LED always displays SOLID GREEN due to design issues. However,
the right LED does behave correctly by FLASHING GREEN.
NR-4264 The two SFP+ ports on the 4432 support only 10G SFPs. 25G is not
supported and produces an error message.
Depending on your device, download release files from the following location:
• For 2825, 2845 S2, 2847 S2, 4248-6XL, 4272, and 4432, use the following URL:
ftp.niagaranetworks.com/BCMPM_HUI3Y
• For 3299 and 3299-TT, use the following URL:
ftp.niagaranetworks.com/MVLBP_FA47E
• For 3808 and 3808E, use the following URL:
ftp.niagaranetworks.com/MVLPM_MXJC8
• For 4248-6C and 4540, use the following URL:
ftp.niagaranetworks.com/BCMPM_HUI3Y
Below are the login credentials to connect to the Niagara FTP site:
• User name: support Password: Niagara123!
Note: If using FileZilla, you can add a bookmark for the remote directory to make navigation
easier. From the Main menu, select Bookmarks > Add Bookmarks. Then, choose Global
bookmark and type the remote directory path (e.g., /MVLBP_FA47E).
Note: Do not change any of the file names after you download an installation file.
Download the applicable ‘new-fix-iss-updater’ file that matches the major release
version of software currently installed on your system. This file is necessary to
prepare your current system for the new upgrade process. The following files are
available for download on the FTP site:
o new-fix-iss-updater-img-BCM-release-iss-10.9.0-v5.bin
o new-fix-iss-updater-img-BCM-release-iss-10.8.0-v5.bin
o new-fix-iss-updater-img-BCM-release-iss-10.7.0-v5.bin
o new-fix-iss-updater-img-BCM-release-iss-10.5.1-v5.bin (for users on v10.5.0
or 10.5.1)
• Download the installation update files:
Download the following set of installation files needed for the upgrade. Note: Do not
change the downloaded file names.
o iss-onie-update-img-BCM-release-iss-12.4.0.bin
o iss-update-img-BCM-release-iss-12.4.0.bin
Depending on your device, download the following installation file needed for the
upgrade. Note: Do not change the downloaded file name.
o For 2825, 2845 S2, 2847 S2, 4248-6XL, 4272, and 4432, use the following file:
iss-update-img-BCM-release-iss-12.4.0.bin
o For 3299 and 3299-TT, use the following file:
firmware-MVL-ARM-release-iss-12.4.0.img
o For 3808E, use the following file:
iss-update-img-MVL-release-iss-12.4.0.bin
Two checksum files are available in the FTP directory where you obtain the FabricFlow
firmware. These files show what the checksums are supposed to be for each file.
You can download the SHA256SUMS and MD5SUMS are the checksum files that you can
download to validate the integrity of each installation file. Below is an example that shows
the MD5SUMS file content for a previous firmware build set.
(Note: This is not the actual MD5SUMS file for this release.)
Keep in mind that if you save the configuration settings to Flash memory, the settings are
restored automatically after you complete the upgrade and reboot the system. However, if
you save the settings remotely or download the settings to your local computer, then you
must perform a system restore after upgrading and rebooting the system.
In the GUI, access the System > Save Configuration page to save the current configuration.
Note: To save the system configuration file to a remote TFTP server, a file with the same
name must already exist on the server and have the correct permissions assigned.
The following two issues in v12.2 release can cause a silent exhaustion of the SSD (flash
space) over time.
• https://niagara-networks.atlassian.net/browse/NR-4520
• https://niagara-networks.atlassian.net/browse/NR-4209
Any device running v12.2 has the possibility of SSD exhaustion and subsequent operational
failure.
If your device is currently on v12.2, view the following pages for workarounds to perform
before upgrading to a later version.
The main reason for SSD exhaustion is the accumulation of event logs over a long period of
time. If the unit is in this state, use the following steps to perform an upgrade:
1. Check the current flash usage on the system to see it is less than 80%. You can
check this either through the GUI or the CLI.
a) To check flash usage through the CLI, use the “show system resources all”
command and check the Current Flash Usage as shown below.
b) To check flash usage through the GUI, use the system resource page as shown
below.
2. If the current flash usage is less than 80%, then you can proceed with the upgrade.
3. If the current Flash usage is greater than 80%, follow the steps for Option 1 first. If
the Flash usage is still greater than 80%, follow the steps for Option 2.
Note: When the flash usage does not go below 80%, even after following the above two
options. Please contact the Niagara Support Team ([email protected]).
Note: If you have not downloaded the necessary MIB and installations files, see “Obtaining
Release Files from FTP Site.” Also, if you have not saved a copy of the system configuration,
see “Saving Current Configuration Settings.”
7. Click the System Firmware Upgrade button. The Upgrade dialog box displays
11. Wait for the fix update to complete. When finished, the Upgrade dialog box
redisplays.
16. Click the System Firmware Upgrade button. The Upgrade dialog box displays.
18. Click Browse to select the following firmware image update file:
iss-update-img-BCM-release-iss-12.4.0.bin
19. Wait for the image update to complete, which may take a few minutes. When
complete, a message displays prompting you to reboot the device.
You may also need to clear the browser cache before accessing the system after the
upgrade completes.
20. Log in to the FabricFlow Web GUI.
21. Access the System > System Information page to verify the system was
successfully updated to v12.4.
22. If your system configuration file was saved to flash memory, the system restores
the system files automatically after reboot. If your configuration file was stored in a
different location, access System > Remote Restore to restore system settings.
• If you have not downloaded the necessary MIB and installations files, see “Obtaining
Release Files from FTP Site.” Also, if you have not saved a copy of the system
configuration, see “Saving Current Configuration Settings.”
• If your device has one of the following firmware versions installed, you can follow
the instructions in this section to upgrade directly to version 12.4:
v12.1, v12.1.0.1, v12.2, v12.2.1, v12.3, v12.3.1
• If your device has v12.2 firmware versions installed, first follow the instructions in
“Manage v12.2 to v12.3 Upgrade Accessibility for High CPU Usage.” Then, you can
follow the procedure in this section to upgrade to v12.3.
In the Web GUI, access the System > Firmware Upgrade page to perform a firmware image
upgrade. If you saved the firmware installation files locally, use the HTTP option to retrieve
the files for the upgrade process.
Note: To perform a local install, the firmware installation files should be saved on the computer
where the Web GUI is being accessed. If you stored the files on a remote server, choose the TFTP
option to access the firmware files for upgrade.
3. Click the System Firmware Upgrade button. The Upgrade dialog box displays.
4. Select one of the following options from the Upgrade Via drop-down list:
o HTTP – Choose this option if the firmware file is stored on the local computer.
Proceed to Step 6.
o TFTP – Choose this option if the firmware file is stored on a remote server.
Proceed to Step 5.
5. If you selected TFTP:
Provide the TFTP server detail and then click Submit.
o Server Address Type – Choose if the IP address to the remote server is IPv4 or
IPv6.
o Server IP Address – Type the IP address of the remote server.
o Firmware File Name – Type the firmware file name. Depending on your
platform, use one of the following:
For 2825, 2845 S2, 2847 S2, 4248-6XL, 4272, 4432, and 4540, use:
iss-update-img-BCM-release-iss-12.4.0.bin
For 3299 and 3299-TT, use:
firmware-MVL-ARM-release-iss-12.4.0.img
For 3808 and 3808E, use:
iss-update-img-MVL-release-iss-12.4.0.bin
Click Browse to select the firmware update file, and then click Submit.
For 2825, 2845 S2, 2847 S2, 4248-6XL, 4272, 4432, and 4540, choose:
iss-update-img-BCM-release-iss-12.4.0.bin
For 3299 and 3299-TT, choose:
firmware-MVL-ARM-release-iss-12.4.0.img
For 3808 and 3808E, choose:
iss-update-img-MVL-release-iss-12.4.0.bin
7. Wait for the image update to complete, which may take a few minutes. When
complete, a message displays prompting you to reboot the device.
You may also need to clear the browser cache before accessing the system after the
upgrade completes.
9. Access the System > System Information page to verify the system was
successfully updated.
10. If your system configuration file was saved to flash memory, the system restores
the system files automatically after reboot. If your configuration file was stored in a
different location, access System > Remote Restore to restore system settings.
Need Assistance? Contact the support team if you see any of the above errors during the
upgrade process. http://support.niagaranetworks.com
Important! This matrix does not show in which firmware versions a specific feature is available. See the FabricFlow (Packet
Master) Release Notes to learn when new features are introduced for each release version.
FabricFlow Features 2825 2845 S2 2847 S2 3299 3299-TT 3808 3808E 4248-6C 4248-6XL 4272 4432 4540
Configuration Maps —
UDP Filters —
FabricFlow Features 2825 2845 S2 2847 S2 3299 3299-TT 3808 3808E 4248-6C 4248-6XL 4272 4432 4540
SCTP Filters — — — — —
GTP Filtering — — — — —
MPLS Filtering — — — — —
Configuration Map-Level
— — —
MPLS label Stripping
Modify Vlan —
Filter Statistics —
FabricFlow Features 2825 2845 S2 2847 S2 3299 3299-TT 3808 3808E 4248-6C 4248-6XL 4272 4432 4540
Bypass Segments
Tap-Bypass
Critical Appliance
LFD
Passive-Bypass — — —
Non-revertive Bypass — —
Segment Synchronization
within Devices
Segment Synchronization
— — — —
across Devices
FabricFlow Features 2825 2845 S2 2847 S2 3299 3299-TT 3808 3808E 4248-6C 4248-6XL 4272 4432 4540
Segment Synchronization in
— — — —
Active-Active mode
Secondary Appliance
Appliance Sharing —
Split Segments — — — — —
Virtual Segments — — — — — —
Redundancy — —
Port Groups
Port Channel —
Virtual Trunk —
Individual Port-Channel
— — — — —
Hash Policy
FabricFlow Features 2825 2845 S2 2847 S2 3299 3299-TT 3808 3808E 4248-6C 4248-6XL 4272 4432 4540
Ports
Reserved Ports — — — — —
Monitoring Heart-Beats — — — — —
Statistics
Traffic Rate
L1 Statistics and L1
Traffic Rate
MicroBurst Detection — — — — — —
IPv4 —
IPv6 —
FabricFlow Features 2825 2845 S2 2847 S2 3299 3299-TT 3808 3808E 4248-6C 4248-6XL 4272 4432 4540
L2 Filters (VLAN) — — — — —
Filter Templates —
Tunnelling
GRE Initiation —
GRE Termination — — —
VXLAN Initiation — — — — —
VXLAN Termination — — — — —
Packetron
Packet Slicing — — — — — — — —
Deduplication — — — — — — — —
NetFlow — — — — — — — —
RegEx — — — — — — — —
Data Masking — — — — — — — —
Application Filtering — — — — — — — —
ERSPAN Termination — — — — — — — —
FabricFlow Features 2825 2845 S2 2847 S2 3299 3299-TT 3808 3808E 4248-6C 4248-6XL 4272 4432 4540
GTP Termination — — — — — — — —
Inline Decryption — — — — — — — —
Virtualization Mode — — — — — — — —
Flow Slicing — — — — — — — —
User/Groups/Privileges
Management Features
Management Interface
Serial Console
IPv4 Management
IPv6 Management
FabricFlow Features 2825 2845 S2 2847 S2 3299 3299-TT 3808 3808E 4248-6C 4248-6XL 4272 4432 4540
Web UI (https)
IPv4 and IPv6
Radius remote
authentication
(IPv4 and IPv6)
TACACS remote
authentication
(IPv4 and IPv6)
Whitelist of IP address
(remote managers)
IPV4 and IPv6
Certificate Upload
License Upload
Syslog
FabricFlow Features 2825 2845 S2 2847 S2 3299 3299-TT 3808 3808E 4248-6C 4248-6XL 4272 4432 4540
PSU Monitoring
Fan Monitoring
Temperature Monitoring
Configuration backup
REST API