- play_arrow Overview
- play_arrow Network Monitoring by using SNMP
- SNMP Architecture and SNMP MIBs Overview
- Understand SNMP Implementation in Junos OS
- Configure SNMP in Junos OS
- Configure Options on Managed Devices for Better SNMP Response Time
- Enterprise Specific Utility MIB to Enhance SNMP Coverage
- Optimize the Network Management System Configuration for the Best Results
- Interfaces to Accept SNMP Requests
- Configure SNMP for Routing Instances
- Configure SNMP Remote Operations
- SNMP Traps
- SNMP Traps Supported by Junos OS
- Trace SNMP Activity
- Access Privileges for an SNMP Group
- Configure Local Engine ID on SNMPv3
- Configure SNMPv3
- Configure SNMPv3 Authentication Type and Encryption Type
- SNMPv3 Traps
- SNMPv3 Informs
- SNMP Communities
- MIB Views
- SNMP MIBs Supported by Junos OS and Junos OS Evolved
- Junos OS SNMP FAQs
- play_arrow Remote Network Monitoring (RMON) with SNMP Alarms and Events
- play_arrow Accounting Options
- play_arrow Monitoring Options
- play_arrow Interface Alarms
- play_arrow IP Monitoring
- play_arrow sFlow Monitoring Technology
- play_arrow Adaptive Sampling for Routers and Switches
- play_arrow Packet Flow Accelerator Diagnostics Software
-
- play_arrow Monitoring Common Security Features
- play_arrow Performance Management
- play_arrow Port Mirroring
- play_arrow Port Mirroring and Analyzers
- Port Mirroring and Analyzers
- Configuring Port Mirroring and Analyzers
- Configuring Port Mirroring Instances
- Configuring Port Mirroring on Physical Interfaces
- Configuring Port Mirroring on Logical Interfaces
- Configuring Port Mirroring for Multiple Destinations
- Configuring Port Mirroring for Remote Destinations
- Configuring Port Mirroring Local and Remote Analysis
- 1:N Port Mirroring to Multiple Destinations on Switches
- Example: Configure Port Mirroring with Family any and a Firewall Filter
- Monitoring Port Mirroring
- Configure Packet Mirroring with Layer 2 Headers for Layer 3 Forwarded Traffic
- Troubleshooting Port Mirroring
-
- play_arrow System Log Messages
- play_arrow Network Management and Troubleshooting
- Compressing Troubleshooting Logs from /var/logs to Send to Juniper Networks Technical Support
- Monitoring and Troubleshooting
- Troubleshooting System Performance with Resource Monitoring Methodology
- Configuring Data Path Debugging and Trace Options
- Using MPLS to Diagnose LSPs, VPNs, and Layer 2 Circuits
- Using Packet Capture to Analyze Network Traffic
- On-Box Packet Sniffer Overview
- Troubleshooting Security Devices
- play_arrow Configuration Statements and Operational Commands
Configure Unified ISSU for 802.1ag CFM
A unified in-service software upgrade (ISSU) enables you to upgrade between two different Junos OS releases with no disruption on the control plane and with minimal disruption of traffic. Unified ISSU is automatically enabled for the Connectivity Fault Management (CFM) protocols and interoperates between local and remote maintenance endpoints (MEPs).
The Junos OS provides support for unified ISSU using the loss threshold type length value (TLV), which is automatically enabled for CFM. TLVs are described in the IEEE 802.1ag standard for CFM as a method of encoding variable-length and optional information in a protocol data unit (PDU). The loss threshold TLV indicates the loss threshold value of a remote MEP. The loss threshold TLV is transmitted as part of the CFM continuity check messages.
Starting in Junos OS Release 15.1, configuring ISSU with CFM (802.1ag) is supported only on MX and PTX routers that support TLV. Interoperation with other vendors is not supported.
During a unified ISSU, the control plane may go down for several seconds and cause CFM continuity check packets to get dropped. This may cause the remote MEP to detect a connectivity loss and mark the MEP as down. To keep the MEP active during a unified ISSU, the loss threshold TLV communicates the minimum threshold value the receiving MEP requires to keep the MEP active. The receiving MEP parses the TLV and updates the loss threshold value, but only if the new threshold value is greater than the locally configured threshold value.
An overview of CFM is described starting in IEEE 802.1ag OAM Connectivity Fault Management Overview, and you should further observe the additional requirements described in this topic.
Table 1 shows the Loss Threshold TLV format.
Parameter | Octet (sequence) | Description |
---|---|---|
Type=31 | 1 | Required. Required. If 0, no Length or Value fields follow. If not 0, at least the Length field follows the Type field. |
Length=12 | 2 | Required if the Type field is not 0. Not present if the Type field is 0. The 16 bits of the Length field indicate the size, in octets, of the Value field. 0 in the Length field indicates that there is no Value field. |
OUI | 3 | Optional. Organization unique identifier (OUI), which is controlled by the IEEE and is typically the first three bytes of a MAC address (Juniper OUI 0x009069). |
Subtype | 1 | Optional. Organizationally defined subtype. |
Value | 4 | Optional. Loss threshold value. |
Flag | 4 | Optional. Bit0 (identifies an ISSU is in progress) Bit1-31 (reserved) |
Junos OS provides configuration support for the convey-loss-threshold
statement, allowing you to control the transmission of the loss
threshold TLV in continuity check messages PDUs. The convey-loss-threshold
statement specifies that the loss threshold TLV must be transmitted
as part of the continuity check messages. If the convey-loss-threshold
statement is not specified, continuity check messages transmit this
TLV only when a unified ISSU is in progress. The Junos OS provides
this configuration at the continuity-check level. By default, continuity
check messages do not include the loss threshold TLV.
To configure the convey loss threshold, use the convey-loss-threshold
statement at the [edit protocols oam ethernet connectivity-fault-management
maintenance-domain identifier maintenance-association identifier continuity-check]
hierarchy level.
For the remote MEP, the loss threshold TLV is transmitted only
during the unified ISSU if the convey-loss-threshold
statement
is not configured. The remote MEP switches back to the default loss
threshold if no loss threshold TLV is received or the TLV has a default
threshold value of 3.
An example of the ISSU configuration statements follows:
protocols { oam { ethernet { connectivity-fault-management { maintenance-domain identifier { level number; maintenance-association identifier { continuity-check { convey-loss-threshold; interval number; loss-threshold number; hold-interval number; } } } } } } }
The Junos OS saves the last received loss threshold TLV from
the remote MEP. You can display the last saved loss threshold TLV
that is received by the remote MEP, using the show oam ethernet
connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier
command, as in the following example:
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md3 maintenance-association ma5 local-mep 2 remote-mep 1 Maintenance domain name: md3, Format: string, Level: 3 Maintenance association name: ma3, Format: string Continuity-check status: enabled, Interval: 1s, Loss-threshold: 3 frames MEP identifier: 2, Direction: up, MAC address: 00:19:e2:b0:76:be Auto-discovery: enabled, Priority: 0 Interface status TLV: none, Port status TLV: none Connection Protection TLV: yes Prefer me: no, Protection in use: no, FRR Flag: no Interface name: xe-4/1/1.0, Interface status: Active, Link status: Up Loss Threshold TLV: Loss Threshold: 3 , Flag: 0x0 Remote MEP identifier: 1, State: ok MAC address: 00:1f:12:b7:ce:79, Type: Learned Interface: xe-4/1/1.0 Last flapped: Never Continuity: 100%, Admin-enable duration: 45sec, Oper-down duration: 0sec Effective loss threshold: 3 frames Remote defect indication: false Port status TLV: none Interface status TLV: none Connection Protection TLV: Prefer me: no, Protection in use: no, FRR Flag: no Loss Threshold TLV: #Displays last received value Loss Threshold: 3 , Flag: 0x0
The Junos OS saves the last transmitted loss threshold TLV from
a local MEP. You can display the last transmitted loss threshold TLV
and the effective loss (operational) threshold for the remote MEP,
using the show oam ethernet connectivity-fault-management mep-database
maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier
command, as in the following example:
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md3 maintenance-association ma5 local-mep 2 remote-mep 1 Maintenance domain name: md3, Format: string, Level: 3 Maintenance association name: ma3, Format: string Continuity-check status: enabled, Interval: 1s, Loss-threshold: 3 frames MEP identifier: 2, Direction: up, MAC address: 00:19:e2:b0:76:be Auto-discovery: enabled, Priority: 0 Interface status TLV: none, Port status TLV: none Connection Protection TLV: yes Prefer me: no, Protection in use: no, FRR Flag: no Interface name: xe-4/1/1.0, Interface status: Active, Link status: Up Loss Threshold TLV: #Displays last transmitted value Loss Threshold: 3 , Flag: 0x0 Remote MEP identifier: 1, State: ok MAC address: 00:1f:12:b7:ce:79, Type: Learned Interface: xe-4/1/1.0 Last flapped: Never Continuity: 100%, Admin-enable duration: 45sec, Oper-down duration: 0sec Effective loss threshold: 3 frames #Displays operational threshold Remote defect indication: falsePort status TLV: none Interface status TLV: none Connection Protection TLV: Prefer me: no, Protection in use: no, FRR Flag: no Loss Threshold TLV: Loss Threshold: 3 , Flag: 0x0
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.