Network Management and Monitoring
-
Ingress inline sFlow and sFlow collector statistics (QFX5130-32CD, QFX5130-48CM, QFX5230-64CD, QFX5240-64OD, QFX5240-64QD, QFX5700, and QFX5700E)—Ingress inline sFlow samples packets on ingress local ports in real time, providing timely visibility into live traffic without relying on control plane processing. The device handles sampling decisions, statistics collection, and sample-destination selection in the Packet Forwarding Engine after ingress processing and before queuing, minimizing forwarding impact. The device copies selected packet and mirrors to a configured analyzer (mirror-to-port) for detailed analysis while traffic moves normally. Inline operation ensures accurate flow insight at high speeds, with overhead controlled by a configurable sampling rate and consistent behavior regardless of the egress port.
-
AES-256 Encryption Algorithm Support for SNMPv3 (ACX7100-32C, ACX7100-48L, ACX7509, ACX7024, ACX7024X, PTX10001-36MR, PTX10002-36QDD, PTX10004, PTX10008, PTX10016, QFX5130-32CD, QFX5130E-32CD, QFX5130-48C, QFX5130-48CM, QFX5700, QFX5700E, QFX5220, QFX5230-64CD, QFX5240-64OD, and QFX5240-64QD)—You can configure Advanced Encryption Standard (AES) 256 algorithm for an SNMPv3 user. To configure AES-256 algorithms for an SNMPv3 user, include the
privacy-aes256statement at theedit snmp v3 usm local-engine user usernamehierarchy level. AES-256 is a symmetric encryption algorithm that uses a 256-bit key to encrypt or decrypt messages and provides high-level security for protecting sensitive information.[See Configure SNMPv3 Authentication Type and Encryption Type, show snmp v3, and usm.]
-
Timestamp option for tap-aggregation packets (QFX5220-32CD and QFX5220-128C)—You can configure the tap-aggregation feature to insert a timestamp in packets at data capture—before the packets are sent to the tool ports for analysis. The timestamp shows exactly when the data packet was captured.
Configure the Precision Time Protocol (PTP) reference clock on the tap-aggregation switch and ensure that PTP is running when the timestamp is inserted. Your tap-aggregation switch must also sync the PTP FPGA’s recovered time-of-day with the system chip’s time-of-day. The command you use to enable the timestamp option is:
[edit] user@switch# set interfaces interface-name timestamp ingress -
Ingress ACL UDF filtering function on tap ports on TAP-aggregation switches (QFX5130-32CD, QFX5130-48C, QFX5700, QFX5220, QFX5230-64CD, QFX5240-64OD, and QFX5240-64QD)—You can apply ingress access control list (ACL) with user-defined fields (UDF) on tap interfaces. This helps you choose the traffic to be sent to the tool interfaces on a tap-aggregation switch. If the ACL match conflicts with the tap-aggregation rule, the ACL match takes precedence.
Also on these switches, you can now configure the TAP-aggregation interfaces under the
[edit interfaces]hierarchy level as follows:-
Add an interface to a tap group with
[edit]user@switch# set interfaces interface-name unit 0 mode tap group tap-group-name
-
Add an interface to a tool group with
[edit]user@switch# set interfaces interface-name unit 0 mode tool group tool-group-name
-
-
Dropped-packet notification (QFX5240-64OD and QFX5240-64QD)—Packet drops are common occurrences on network switches and routers. Debugging packet drops can be complex and time-consuming. The packet-processing pipeline supports a limited set of drop counters, but these counters are insufficient for debugging complex packet-drop issues. Debugging difficulties can result in high mean times to recovery (MTTRs).
A feature called dropped-packet notification, also referred to as mirror on drop (MoD), can help you debug packet drops in real time. The areas of packet drop monitored include:
- Packets dropped due to processing in the ingress pipeline
- Packets dropped due to congestion in the MMU
Dropped-packet notification on the platforms named in this description is stateless and flow unaware.
You configure much of the dropped-packet notification feature at the
[edit forwarding-options mirror-profile]hierarchy level. -
1:N port mirroring for sending a source packet to multiple Layer 2 destinations (QFX5130-32CD|QFX5130E-32CD|QFX5130-48C|QFX5130-48CM|QFX5700|QFX5700E|QFX5220|QFX5230-64CD|QFX5240-64OD|QFX5240-64QD )—You can use the 1:N port mirroring feature to mirror traffic to multiple Layer 2 destinations. This feature requires either one or both of the following configurations:
-
A port-mirroring instance that is based on a firewall filter. Use the configuration statements in the
[edit forwarding-options port-mirroring instance]hierarchy. -
A native analyzer. Use the configuration statements in the
[edit forwarding-options analyzer]hierarchy.
For both the configuration methods, you must also configure next-hop groups with a group type of
layer-2to direct the mirrored packets to their destinations.[See 1:N Port Mirroring to Multiple Destinations on Switches.]
-