ON THIS PAGE
Guidelines for Configuring Routers to Support an ETH-DM Session
Guidelines for Managing ETH-DM Statistics and ETH-DM Frame Counts
Example: Configuring One-Way Ethernet Frame Delay Measurements with Single-Tagged Interfaces
Example: Configuring Two-Way Ethernet Frame Delay Measurements with Single-Tagged Interfaces
Configure Ethernet Frame Delay Measurement Sessions
Use this topic to understand how to configure Ethernet frame delay measurement sessions. You can start either a one-way Ethernet delay measurement session or a two-way Ethernet delay measurement session. Also, use this topic to view the delay measurement statistics and frame counts.
Guidelines for Configuring Routers to Support an ETH-DM Session
Keep the following guidelines in mind when configuring routers to support an Ethernet frame delay measurement (ETH-DM) session:
Configuration Requirements for ETH-DM
You can obtain ETH-DM information for a link that meets the following requirements:
The measurements can be performed between peer maintenance association endpoints (MEPs) on two routers.
The two MEPs must be configured on two Ethernet physical interfaces or on two Ethernet logical interfaces. For more information, see Configuring a MEP to Generate and Respond to CFM Protocol Messages.
The two MEPs must be configured—on their respective routers—under the same maintenance association (MA) identifier. For more information, see Creating a Maintenance Association.
On both routers, the MA must be associated with the same maintenance domain (MD) name. For more information, see Creating a Maintenance Domain.
On both routers, periodic packet management (PPM) must be running on the Routing Engine and Packet Forwarding Engine, which is the default configuration. You can disable PPM on the Packet Forwarding Engine only. However, the Ethernet frame delay measurement feature requires that distributed PPM remain enabled on the Packet Forwarding Engine of both routers. For more information about
ppm, see the Junos OS Routing Protocols Library for Routing Devices.If the PPM process (
ppm) is disabled on the Packet Forwarding Engine, you must re-enable it. Re-enabling distributedppmentails restarting theethernet-connectivity-fault-managementprocess, which causes all connectivity fault management (CFM) sessions to re-establish. For more information about CFM sessions, see Configuring Ethernet Local Management Interface.
The Ethernet frame delay measurement feature is supported only for MEPs configured on Ethernet physical or logical interfaces on DPCs in MX Series routers. The ETH-DM feature is not supported on aggregated Ethernet interfaces or LSI pseudowires.
Configuration Options for ETH-DM
By default, the ETH-DM feature calculates frame delays using software-based timestamping of the ETH-DM PDU frames sent and received by the MEPs in the session. As an option that can increase the accuracy of ETH-DM calculations when the DPC is loaded with heavy traffic in the receive direction, you can enable hardware-assisted timestamping of session frames in the receive direction.
See Also
Guidelines for Starting an ETH-DM Session
Keep the following guidelines in mind when preparing to start an Ethernet frame delay measurement (ETH-DM) session:
ETH-DM Session Prerequisites
Before you can start an ETH-DM session, you must configure two MX Series routers to support ETH-DM by defining the two CFM-enabled physical or logical Ethernet interfaces on each router. This entails creating and configuring CFM maintenance domains, maintenance associations, and maintenance association end points on each router. For more information about enabling CFM on an Ethernet interface, see Creating a Maintenance Domain.
The Ethernet frame delay measurement feature is supported only for maintenance association end points configured on Ethernet physical or logical interfaces on DPCs in MX Series routers. The ETH-DM feature is not supported on aggregated Ethernet interfaces or LSI pseudowires.
For specific information about configuring routers to support ETH-DM, seeGuidelines for Configuring Routers to Support an ETH-DM Session and Configuring Routers to Support an ETH-DM Session.
ETH-DM Session Parameters
You can initiate a one-way or two-way ETH-DM session by entering
the monitor ethernet delay-measurement operational command
at a router that contains one end of the service for which you want
to measure frame delay. The command options specify the ETH-DM session
in terms of the CFM elements:
The type of ETH-DM measurement (one-way or two-way) to be performed.
The Ethernet service for which the ETH-DM measurement is to be performed:
CFM maintenance domain—Name of the existing maintenance domain (MD) for which you want to measure Ethernet frame delays. For more information, see Creating a Maintenance Domain.
CFM maintenance association—Name of an existing maintenance association (MA) within the maintenance domain. For more information, see Creating a Maintenance Association.
Remote CFM maintenance association end point—The unicast MAC address or the numeric identifier of the remote maintenance association end point (MEP)—the physical or logical interface on the remote router that resides in the specified MD and is named in the specified MA—with which to perform the ETH-DM session. For more information, see Configuring a MEP to Generate and Respond to CFM Protocol Messages.
Optional specifications:
Count—You can specify the number of ETH-DM requests to send for this frame delay measurement session. The range is from 1 through 65,535 frames. The default value is 10 frames.
NOTE:Although you can trigger frame delay collection for up to 65,535 ETH-DM requests at a time, a router stores only the last 100 frame delay statistics per CFM session (pair of peer MEPs).Frame interval—You can specify the number of seconds to elapse between ETH-DM frame transmittals. The default value is 1 second.
For more detailed information about the parameters you can specify
to start an ETH-DM session, see the monitor ethernet delay-measurement operational command description in the CLI Explorer.
Restrictions for an ETH-DM Session
The following restrictions apply to an ETH-DM session:
You cannot run multiple simultaneous ETH-DM sessions with the same remote MEP or MAC address.
For a given ETH-DM session, you can collect frame delay information for a maximum of 65,535 frames.
For a given CFM session (pair of peer MEPs), the ETH-DM database stores a maximum of 100 statistics, with the older statistics being “aged out” as newer statistics are collected for that pair of MEPs.
For one-way delay measurements collected within the same CFM session, the 100 most recent ETH-DM statistics can be retrieved at any point of time at the router on which the receiver MEP is defined.
For two-way delay measurements collected within the same CFM session, the 100 most recent ETH-DM statistics can be retrieved at any point of time at the router on which the initiator MEP is defined.
Depending on the number of frames exchanged in the individual ETH-DM sessions, the ETH-DM database can contain statistics collected through multiple ETH-DM sessions.
If graceful Routing Engine switchover (GRES) occurs, any collected ETH-DM statistics are lost, and ETH-DM frame counts are reset to zeroes. GRES enables a router with dual Routing Engines to switch from a primary Routing Engine to a backup Routing Engine without interruption to packet forwarding. For more information, see the Junos OS High Availability User Guide.
Accuracy of frame delay data is compromised when the system is changing (such as from reconfiguration). We recommend performing Ethernet frame delay measurements on a stable system.
See Also
Guidelines for Managing ETH-DM Statistics and ETH-DM Frame Counts
ETH-DM Statistics
Ethernet frame delay statistics are the frame delay and frame delay variation values determined by the exchange of frames containing ETH-DM protocol data units (PDUs).
For a one-way ETH-DM session, statistics are collected in an ETH-DM database at the router that contains the receiver MEP. For a detailed description of one-way Ethernet frame delay measurement, including the exchange of one-way delay PDU frames, see Ethernet Frame Delay Measurements Overview.
For a two-way ETH-DM session, statistics are collected in an ETH-DM database at the router that contains the initiator MEP. For a detailed description of two-way Ethernet frame delay measurement, including the exchange of two-way delay PDU frames, see Ethernet Frame Delay Measurements Overview.
A CFM database stores CFM-related statistics and—for Ethernet
interfaces that support ETH-DM—the 100 most recently collected
ETH-DM statistics for that pair of MEPs. You can view ETH-DM statistics
by using the delay-statistics or mep-statistics form of the show oam ethernet connectivity-fault-management command to display the CFM statistics for the MEP that collects
the ETH-DM statistics you want to view.
Table 1 describes the ETH-DM statistics calculated in an ETH-DM session.
Field Name |
Field Description |
|---|---|
|
For a one-way ETH-DM session, the frame delay, in microseconds, collected at the receiver MEP. To display frame delay statistics for a given one-way ETH-DM
session, use the |
|
For a two-way ETH-DM session, the frame delay, in microseconds, collected at the initiator MEP. When you start a two-way frame delay measurement, the CLI output displays each DMR frame receipt timestamp and corresponding DMM frame delay and delay variation collected as the session progresses. To display frame delay statistics for a given two-way ETH-DM
session, use the |
|
When you start a two-way frame delay measurement, the CLI output includes a runtime display of the average two-way frame delay among the statistics collected for the ETH-DM session only. When you display ETH-DM statistics using a For example, suppose you start two one-way ETH-DM sessions for
50 counts each, one after the other. If, after both measurement
sessions complete, you use a |
|
When you start a two-way frame delay measurement, the CLI output includes a runtime display of the average two-way frame delay variation among the statistics collected for the ETH-DM session only. When you display ETH-DM statistics using a |
|
When you start a two-way frame delay measurement, the CLI output includes a runtime display of the lowest two-way frame delay value among the statistics collected for the ETH-DM session only. When you display ETH-DM statistics using a |
|
When you start a two-way frame delay measurement, the CLI output includes a runtime display of the highest two-way frame delay value among the statistics collected for the ETH-DM session only. When you display ETH-DM statistics using a |
†When you start a one-way
frame delay measurement, the CLI output displays |
|
ETH-DM Statistics Retrieval
At the receiver MEP for a one-way session, or at the initiator MEP for a two-way session, you can display all ETH-DM statistics collected at a CFM session level by using the following operational commands:
show oam ethernet connectivity-fault-management delay-statistics maintenance-domain md-name maintenance-association ma-name <local-mep mep-id> <remote-mep mep-id> <count count>show oam ethernet connectivity-fault-management mep-statistics maintenance-domain md-name maintenance-association ma-name <local-mep mep-id> <remote-mep mep-id> <count count>
ETH-DM Frame Counts
The number of ETH-DM PDU frames exchanged in a ETH-DM session are stored in the CFM database on each router.
Table 2 describes the ETH-DM frame counts collected in an ETH-DM session.
Field Name |
Field Description |
|---|---|
|
Number of one-way delay measurement (1DM) PDU frames sent to the peer MEP in this session. Stored in the CFM database of the MEP initiating a one-way frame delay measurement. |
|
Number of valid 1DM frames received. Stored in the CFM database of the MEP receiving a one-way frame delay measurement. |
|
Number of invalid 1DM frames received. Stored in the CFM database of the MEP receiving a one-way frame delay measurement. |
|
Number of delay measurement message (DMM) PDU frames sent to the peer MEP in this session. Stored in the CFM database of the MEP initiating a two-way frame delay measurement. |
|
Number of delay measurement reply (DMR) frames sent (in response to a received DMM). Stored in the CFM database of the MEP responding to a two-way frame delay measurement. |
|
Number of valid DMR frames received. Stored in the CFM database of the MEP initiating a two-way frame delay measurement. |
|
Number of invalid DMR frames received. Stored in the CFM database of the MEP initiating a two-way frame delay measurement. |
ETH-DM Frame Count Retrieval
Each router counts the number of ETH-DM frames sent or received and stores the counts in a CFM database.
Frame Counts Stored in CFM Databases
You can display ETH-DM frame counts for MEPs assigned to specified Ethernet interfaces or for specified MEPs in CFM sessions by using the following operational commands:
show oam ethernet connectivity-fault-management interfaces(detail|extensive)show oam ethernet connectivity-fault-management mep-database maintenance-domain md-name maintenance-association ma-name <local-mep mep-id> <remote-mep mep-id>
One-Way ETH-DM Frame Counts
For a one-way ETH-DM session, delay statistics are collected at the receiver MEP only, but frame counts are collected at both MEPs. As indicated in Table 2, one-way ETH-DM frame counts are tallied from the perspective of each router in the session:
At the initiator MEP, the router counts the number of 1DM frames sent.
At the receiver MEP, the router counts the number of valid 1DM frames received and the number of invalid 1DM frames received.
You can also view one-way ETH-DM frame counts—for a receiver MEP—by
using the show oam ethernet connectivity-fault-management mep-statistics command to display one-way statistics and frame counts together.
Two-Way ETH-DM Frame Counts
For a two-way ETH-DM session, delay statistics are collected at the initiator MEP only, but frame counts are collected at both MEPs. As indicated in Table 2, two-way ETH-DM frame counts are tallied from the perspective of each router in the session:
At the initiator MEP, the router counts the number of DMM frames sent, valid DMR frames received, and invalid DMR frames received.
At the responder MEP, the router counts the number of DMR frames sent.
You can also view two-way ETH-DM frame counts—for an initiator MEP—by
using the show oam ethernet connectivity-fault-management mep-statistics command to display two-way statistics and frame counts together.
See Also
Configuring Routers to Support an ETH-DM Session
- Configuring MEP Interfaces
- Ensuring That Distributed ppm Is Not Disabled
- Enabling the Hardware-Assisted Timestamping Option
- Configuring the Server-Side Processing Option
Configuring MEP Interfaces
Before you can start an Ethernet frame delay measurement session across an Ethernet service, you must configure two MX Series routers to support ETH-DM.
To configure an Ethernet interface on a MX Series router to support ETH-DM:
Ensuring That Distributed ppm Is Not Disabled
By default, the router’s period packet management
process (ppm) runs sessions distributed to the Packet Forwarding
Engine in addition to the Routing Engine. This process is responsible
for periodic transmission of packets on behalf of its various client
processes, such as Bidirectional Forwarding Detection (BFD), and it
also receives packets on behalf of client processes.
In addition, ppm handles time-sensitive periodic
processing and performs such processes as sending process-specific
packets and gathering statistics. With ppm processes running
distributed on both the Routing Engine and the Packet Forwarding Engine,
you can run such processes as BFD on the Packet Forwarding Engine.
Distributed ppm Required for ETH-DM
Ethernet frame delay measurement requires that ppm remains distributed to the Packet Forwarding Engine. If ppm is not distributed to the Packet Forwarding Engines of both routers,
ETH-DM PDU frame timestamps and ETH-DM statistics are not valid.
Before you start ETH-DM, you must verify that the following configuration statement is NOT present:
[edit]
routing-options {
ppm {
no-delegate-processing;
}
}
If distributed ppm processing is disabled (as shown
in the stanza above) on either router, you must re-enable it in order
to use the ETH-DM feature.
Procedure to Ensure that Distributed ppm is Not Disabled
To ensure that distributed ppm is not disabled
on a router:
Connectivity fault management (CFM) sessions operate in centralized
mode over AE interfaces by default. Y.1731 performance monitoring
(PM) is supported on centralized CFM sessions over AE interfaces.
Also, distribution of CFM session over AE interfaces to line cards
is supported from Junos OS Release 13.3. To enable the distribution
of CFM sessions and to operate in centralized mode, include the ppm delegate-processing statement at the [edit routing-options
ppm] hierarchy level. The mechanism that enables distribution
of CFM sessions over AE interfaces provides the underlying infrastructure
to support PM over AE interfaces. In addition, periodic packet management
(PPM) handles time-sensitive periodic processing and performs such
processes as sending process-specific packets and gathering statistics.
With PPM processes running distributed on both the Routing Engine
and the Packet Forwarding Engine, you can run performance monitoring
processes on the Packet Forwarding Engine.
See Also
Enabling the Hardware-Assisted Timestamping Option
By default, Ethernet frame delay measurement uses software for timestamping transmitted and received ETH-DM frames. For Ethernet interfaces, you can optionally use hardware timing to assist in the timestamping of received ETH-DM frames to increase the accuracy of delay measurements.
Enabling hardware-assisted timestamping of received frames can increase the accuracy of ETH-DM calculations when the DPC is loaded with heavy traffic in the receive direction.
Starting in Junos OS Release 20.4R1, by default the hardware
assistance is used for timestamping Ethernet frame delay frames on
AFT based MX Series line cards, even if the hardware-assisted-timestamping is not configured.
To enable Ethernet frame delay measurement hardware assistance
on the reception path, include the hardware-assisted-timestamping statement at the [edit protocols oam ethernet connectivity-fault-management
performance-monitoring] hierarchy level:
[edit protocols] oam { ethernet { connectivity-fault-management { performance-monitoring { hardware-assisted-timestamping; } } } }
See Also
Configuring the Server-Side Processing Option
You can delegate the server-side processing (for both two-way delay measurement and loss measurement) to the Packet Forwarding Engine to prevent overloading on the Routing Engine. By default, the server-side processing is done by the Routing Engine.
To configure the server-side processing option:
See Also
Triggering an Ethernet Frame Delay Measurements Session
Before Ethernet frame delay measurement statistics can be displayed,
they must be collected. To trigger Ethernet frame delay measurement,
use the monitor ethernet delay-measurement (one-way | two-way)
(remote-mac-address) maintenance-domain name maintenance-association ma-id [count count] [wait time] operational command.
The fields for this command are described in Table 3.
Parameter |
Parameter Range |
Description |
|---|---|---|
|
NA |
Perform a one-way or two-way (round-trip) delay measurement. |
remote-mac-address |
Unicast MAC address |
Send delay measurement frames to the destination unicast MAC address (use the format xx:xx:xx:xx:xx:xx). Multicast MAC addresses are not supported. |
|
1–8191 |
The MEP identifier to use for the measurement. The discovered MAC address for this MEP identifier is used. |
|
Existing MD name |
Specifies an existing maintenance domain (MD) to use for the measurement. |
|
Existing MA identifier |
Specifies an existing maintenance association (MA) identifier to use for the measurement. |
|
1–65535 (default: 10) |
(Optional) Specifies the number of Ethernet frame delay frames to send. The default is 10. |
wait time |
1–255 seconds (default: 1) |
(Optional) Specifies the number of seconds to wait between frames. The default is 1 second. |
If you attempt to monitor delays to a nonexistent MAC address, you must exit the application manually using ^C:
user@host> monitor ethernet delay-measurement two-way 00:11:22:33:44:55 Two-way ETH-DM request to 00:11:22:33:44:55, Interface ge-5/2/9.0 ^C --- Delay measurement statistics --- Packets transmitted: 10, Valid packets received: 0 Average delay: 0 usec, Average delay variation: 0 usec Best case delay: 0 usec, Worst case delay: 0 usec
See Also
Starting an ETH-DM Session
- Using the monitor ethernet delay-measurement Command
- Starting a One-Way ETH-DM Session
- Starting a Two-Way ETH-DM Session
Using the monitor ethernet delay-measurement Command
After you have configured two MX Series routers to support ITU-T Y.1731 Ethernet frame delay measurement (ETH-DM), you can initiate a one-way or two-way Ethernet frame delay measurement session from the CFM maintenance association end point (MEP) on one of the routers to the peer MEP on the other router.
To start an ETH-DM session between the specified local
MEP and the specified remote MEP, enter the monitor ethernet
delay-measurement command at operational mode.
The syntax of the command is as follows:
monitor ethernet delay-measurement (one-way | two-way) maintenance-domain md-name maintenance-association ma-name (remote-mac-address | mep remote-mep-id) <count frame-count> <wait interval-seconds> <priority 802.1p value> <size> <no-session-id-tlv> <xml>
For a one-way frame delay measurement, the command displays a runtime display of the number of 1DM frames sent from the initiator MEP during that ETH-DM session. One-way frame delay and frame delay variation measurements from an ETH-DM session are collected in a CFM database at the router that contains the receiver MEP. You can retrieve ETH-DM statistics from a CFM database at a later time.
For a two-way frame delay measurement, the command displays two-way frame delay and frame delay variation values for each round-trip frame exchange during that ETH-DM session, as well as a runtime display of useful summary information about the session: average delay, average delay variation, best-case delay, and worst-case delay. Two-way frame delay and frame delay variation values measurements from an ETH-DM session are collected in a CFM database at the router that contains the initiator MEP. You can retrieve ETH-DM statistics from a CFM database at a later time.
Although you can trigger frame delay collection for up to 65,535 ETH-DM requests at a time, a router stores only the last 100 frame delay statistics per CFM session (pair of peer MEPs).
For a complete description of the monitor ethernet delay-measurement operational command, see the CLI Explorer.
See Also
Starting a One-Way ETH-DM Session
To start a one-way Ethernet frame delay measurement session,
enter the monitor ethernet delay-measurement one-way command
from operational mode, and specify the peer MEP by its MAC address
or by its MEP identifier.
For example:
user@host> monitor ethernet delay-measurement one-way 00:05:85:73:39:4a maintenance-domain md6 maintenance-association ma6 count 10 One-way ETH-DM request to 00:05:85:73:39:4a, Interface xe-5/0/0.0 1DM Frames sent : 10 --- Delay measurement statistics --- Packets transmitted: 10 Average delay: NA, Average delay variation: NA Best case delay: NA, Worst case delay: NA
If you attempt to monitor delays to a nonexistent MAC
address, you must type Ctrl + C to explicitly quit the monitor ethernet
delay-measurement command and return to the CLI command prompt.
See Also
Starting a Two-Way ETH-DM Session
To start a two-way Ethernet frame delay measurement session,
enter the monitor ethernet delay-measurement two-way command
from operational mode, and specify the peer MEP by its MAC address
or by its MEP identifier.
For example:
user@host> monitor ethernet delay-measurement two-way 00:05:85:73:39:4a maintenance-domain md6 maintenance-association ma6 count 10 Two-way ETH-DM request to 00:05:85:73:39:4a, Interface xe-5/0/0.0 DMR received from 00:05:85:73:39:4a Delay: 100 usec Delay variation: 0 usec DMR received from 00:05:85:73:39:4a Delay: 92 usec Delay variation: 8 usec DMR received from 00:05:85:73:39:4a Delay: 92 usec Delay variation: 0 usec DMR received from 00:05:85:73:39:4a Delay: 111 usec Delay variation: 19 usec DMR received from 00:05:85:73:39:4a Delay: 110 usec Delay variation: 1 usec DMR received from 00:05:85:73:39:4a Delay: 119 usec Delay variation: 9 usec DMR received from 00:05:85:73:39:4a Delay: 122 usec Delay variation: 3 usec DMR received from 00:05:85:73:39:4a Delay: 92 usec Delay variation: 30 usec DMR received from 00:05:85:73:39:4a Delay: 92 usec Delay variation: 0 usec DMR received from 00:05:85:73:39:4a Delay: 108 usec Delay variation: 16 usec --- Delay measurement statistics --- Packets transmitted: 10, Valid packets received: 10 Average delay: 103 usec, Average delay variation: 8 usec Best case delay: 92 usec, Worst case delay: 122 usec
If you attempt to monitor delays to a nonexistent MAC
address, you must type Ctrl + C to explicitly quit the monitor ethernet
delay-measurement command and return to the CLI command prompt.
See Also
Example: Configuring One-Way Ethernet Frame Delay Measurements with Single-Tagged Interfaces
This example uses two MX Series routers: MX-1 and MX-2. The configuration creates a CFM down MEP session on a VLAN-tagged logical interface connecting the two (ge-5/2/9 on Router MX-1 and ge-0/2/5 on Router MX-2).
These are not complete router configurations.
Configuration on Router MX-1:
[edit]
interfaces {
ge-5/2/9 {
vlan-tagging;
unit 0 {
vlan-id 512;
}
}
}
protocols {
oam {
ethernet {
connectivity-fault-management {
traceoptions {
file eoam_cfm.log size 1g files 2 world-readable;
flag all;
}
linktrace {
path-database-size 255;
age 10s;
}
maintenance-domain md6 {
level 6;
maintenance-association ma6 {
continuity-check {
interval 100ms;
hold-interval 1;
}
mep 201 {
interface ge-5/2/9.0;
direction down;
auto-discovery;
}
}
}
}
}
}
}
Configuration on Router MX-2:
[edit]
interfaces {
ge-0/2/5 {
vlan-tagging;
unit 0 {
vlan-id 512;
}
}
}
protocols {
oam {
ethernet {
connectivity-fault-management {
traceoptions {
file eoam_cfm.log size 1g files 2 world-readable;
flag all;
}
linktrace {
path-database-size 255;
age 10s;
}
maintenance-domain md6 {
level 6;
maintenance-association ma6 {
continuity-check {
interval 100ms;
hold-interval 1;
}
mep 101 {
interface ge-0/2/5.0;
direction down;
auto-discovery;
}
}
}
}
}
}
}
From Router MX-2, start a one-way delay measurement to Router MX-1.
user@MX-2> monitor ethernet delay-measurement one-way mep 201 maintenance-domain md6 maintenance-association ma6 count 10 One-way ETH-DM request to 00:90:69:0a:43:94, Interface ge-0/2/5.0 1DM Frames sent : 10 --- Delay measurement statistics --- Packets transmitted: 10 Average delay: NA, Average delay variation: NA Best case delay: NA, Worst case delay: NA
The counters are displayed as part of the local MEP database on Router MX-2.
user@MX-2> show oam ethernet connectivity-fault-management mep-database maintenance-domain md6 maintenance-domain ma6
Maintenance domain name: md6, Format: string, Level: 6
Maintenance association name: ma6, Format: string
Continuity-check status: enabled, Interval: 100ms, Loss-threshold: 3 frames
MEP identifier: 101, Direction: down, MAC address: 00:90:69:0a:48:57
Auto-discovery: enabled, Priority: 0
Interface name: ge-0/2/5.0, Interface status: Active, Link status: Up
Defects:
Remote MEP not receiving CCM : no
Erroneous CCM received : no
Cross-connect CCM received : no
RDI sent by some MEP : no
Statistics:
CCMs sent : 1590
CCMs received out of sequence : 0
LBMs sent : 0
Valid in-order LBRs received : 0
Valid out-of-order LBRs received : 0
LBRs received with corrupted data : 0
LBRs sent : 0
LTMs sent : 0
LTMs received : 0
LTRs sent : 0
LTRs received : 0
Sequence number of next LTM request : 0
1DMs sent : 10
Valid 1DMs received : 0
Invalid 1DMs received : 0
DMMs sent : 0
DMRs sent : 0
Valid DMRs received : 0
Invalid DMRs received : 0
Remote MEP count: 1
Identifier MAC address State Interface
201 00:90:69:0a:43:94 ok ge-0/2/5.0The remote MEP database statistics are available on Router MX-1.
user@MX-1> show oam ethernet connectivity-fault-management mep-database maintenance-domain md6
Maintenance domain name: md6, Format: string, Level: 6
Maintenance association name: ma6, Format: string
Continuity-check status: enabled, Interval: 100ms, Loss-threshold: 3 frames
MEP identifier: 201, Direction: down, MAC address: 00:90:69:0a:43:94
Auto-discovery: enabled, Priority: 0
Interface name: ge-5/2/9.0, Interface status: Active, Link status: Up
Defects:
Remote MEP not receiving CCM : no
Erroneous CCM received : no
Cross-connect CCM received : no
RDI sent by some MEP : no
Statistics:
CCMs sent : 1572
CCMs received out of sequence : 0
LBMs sent : 0
Valid in-order LBRs received : 0
Valid out-of-order LBRs received : 0
LBRs received with corrupted data : 0
LBRs sent : 0
LTMs sent : 0
LTMs received : 0
LTRs sent : 0
LTRs received : 0
Sequence number of next LTM request : 0
1DMs sent : 0
Valid 1DMs received : 10
Invalid 1DMs received : 0
DMMs sent : 0
DMRs sent : 0
Valid DMRs received : 0
Invalid DMRs received : 0
Remote MEP count: 1
Identifier MAC address State Interface
101 00:90:69:0a:48:57 ok ge-5/2/9.0The remote Router MX-1 should also collect the delay statistics (up to 100 per session) for display with mep-statistics or delay-statistics.
user@MX-1> show oam ethernet connectivity-fault-management mep-statistics maintenance-domain md6
MEP identifier: 201, MAC address: 00:90:69:0a:43:94
Remote MEP count: 1
CCMs sent : 3240
CCMs received out of sequence : 0
LBMs sent : 0
Valid in-order LBRs received : 0
Valid out-of-order LBRs received : 0
LBRs received with corrupted data : 0
LBRs sent : 0
LTMs sent : 0
LTMs received : 0
LTRs sent : 0
LTRs received : 0
Sequence number of next LTM request : 0
1DMs sent : 0
Valid 1DMs received : 10
Invalid 1DMs received : 0
DMMs sent : 0
DMRs sent : 0
Valid DMRs received : 0
Invalid DMRs received : 0
Remote MEP identifier: 101
Remote MAC address: 00:90:69:0a:48:57
Delay measurement statistics:
Index One-way delay Two-way delay
(usec) (usec)
1 370
2 357
3 344
4 332
5 319
6 306
7 294
8 281
9 269
10 255
Average one-way delay : 312 usec
Average one-way delay variation: 11 usec
Best case one-way delay : 255 usec
Worst case one-way delay : 370 usecuser@MX-1> show oam ethernet connectivity-fault-management delay-statistics maintenance-domain md6
MEP identifier: 201, MAC address: 00:90:69:0a:43:94
Remote MEP count: 1
Remote MAC address: 00:90:69:0a:48:57
Delay measurement statistics:
Index One-way delay Two-way delay
(usec) (usec)
1 370
2 357
3 344
4 332
5 319
6 306
7 294
8 281
9 269
10 255
Average one-way delay : 312 usec
Average one-way delay variation: 11 usec
Best case one-way delay : 255 usecWhen two systems are close to each other, their one-way delay values are very high compared to their two-way delay values. This is because one-way delay measurement requires the timing for the two systems to be synchronized at a very granular level and MX Series routers do not support this granular synchronization. However, two-way delay measurement does not require synchronized timing, making two-way delay measurements more accurate.
See Also
Example: Configuring Two-Way Ethernet Frame Delay Measurements with Single-Tagged Interfaces
This example uses two MX Series routers: MX-1 and MX-2. The configuration creates a CFM down MEP session on a VLAN-tagged logical interface connecting the two (ge-5/2/9 on Router MX-1 and ge-0/2/5 on Router MX-2).
These are not complete router configurations.
Configuration on Router MX-1:
[edit]
interfaces {
ge-5/2/9 {
vlan-tagging;
unit 0 {
vlan-id 512;
}
}
}
protocols {
oam {
ethernet {
connectivity-fault-management {
traceoptions {
file eoam_cfm.log size 1g files 2 world-readable;
flag all;
}
linktrace {
path-database-size 255;
age 10s;
}
maintenance-domain md6 {
level 6;
maintenance-association ma6 {
continuity-check {
interval 100ms;
hold-interval 1;
}
mep 201 {
interface ge-5/2/9.0;
direction down;
auto-discovery;
}
}
}
}
}
}
}
Configuration on Router MX-2:
[edit]
interfaces {
ge-0/2/5 {
vlan-tagging;
unit 0 {
vlan-id 512;
}
}
}
protocols {
oam {
ethernet {
connectivity-fault-management {
traceoptions {
file eoam_cfm.log size 1g files 2 world-readable;
flag all;
}
linktrace {
path-database-size 255;
age 10s;
}
maintenance-domain md6 {
level 6;
maintenance-association ma6 {
continuity-check {
interval 100ms;
hold-interval 1;
}
mep 101 {
interface ge-0/2/5.0;
direction down;
auto-discovery;
}
}
}
}
}
}
}
From Router MX-1, start a two-way delay measurement to Router MX-2.
user@MX-1> monitor ethernet delay-measurement two-way mep 101 maintenance-domain md6 maintenance-association ma6 count 10 Two-way ETH-DM request to 00:90:69:0a:48:57, Interface ge-5/2/9.0 DMR received from 00:90:69:0a:48:57 Delay: 100 usec Delay variation: 0 usec DMR received from 00:90:69:0a:48:57 Delay: 92 usec Delay variation: 8 usec DMR received from 00:90:69:0a:48:57 Delay: 92 usec Delay variation: 0 usec DMR received from 00:90:69:0a:48:57 Delay: 111 usec Delay variation: 19 usec DMR received from 00:90:69:0a:48:57 Delay: 110 usec Delay variation: 1 usec DMR received from 00:90:69:0a:48:57 Delay: 119 usec Delay variation: 9 usec DMR received from 00:90:69:0a:48:57 Delay: 122 usec Delay variation: 3 usec DMR received from 00:90:69:0a:48:57 Delay: 92 usec Delay variation: 30 usec DMR received from 00:90:69:0a:48:57 Delay: 92 usec Delay variation: 0 usec DMR received from 00:90:69:0a:48:57 Delay: 108 usec Delay variation: 16 usec --- Delay measurement statistics --- Packets transmitted: 10, Valid packets received: 10 Average delay: 103 usec, Average delay variation: 8 usec Best case delay: 92 usec, Worst case delay: 122 usec
The counters are displayed as part of the MEP database on Router MX-1 maintenance domain MD6.
user@MX-1> show oam ethernet connectivity-fault-management mep-database maintenance-domain md6
Maintenance domain name: md6, Format: string, Level: 6
Maintenance association name: ma6, Format: string
Continuity-check status: enabled, Interval: 100ms, Loss-threshold: 3 frames
MEP identifier: 201, Direction: down, MAC address: 00:90:69:0a:43:94
Auto-discovery: enabled, Priority: 0
Interface name: ge-5/2/9.0, Interface status: Active, Link status: Up
Defects:
Remote MEP not receiving CCM : no
Erroneous CCM received : no
Cross-connect CCM received : no
RDI sent by some MEP : no
Statistics:
CCMs sent : 894
CCMs received out of sequence : 0
LBMs sent : 0
Valid in-order LBRs received : 0
Valid out-of-order LBRs received : 0
LBRs received with corrupted data : 0
LBRs sent : 0
LTMs sent : 0
LTMs received : 0
LTRs sent : 0
LTRs received : 0
Sequence number of next LTM request : 0
1DMs sent : 0
Valid 1DMs received : 0
Invalid 1DMs received : 0
DMMs sent : 10
DMRs sent : 0
Valid DMRs received : 10
Invalid DMRs received : 0
Remote MEP count: 1
Identifier MAC address State Interface
101 00:90:69:0a:48:57 ok ge-5/2/9.0The collected MEP statistics are saved (up to 100 per remote MEP or per CFM session) and displayed as part of the MEP statistics on Router MX-1.
user@MX-1> show oam ethernet connectivity-fault-management mep-statistics maintenance-domain md6
MEP identifier: 201, MAC address: 00:90:69:0a:43:94
Remote MEP count: 1
CCMs sent : 3154
CCMs received out of sequence : 0
LBMs sent : 0
Valid in-order LBRs received : 0
Valid out-of-order LBRs received : 0
LBRs received with corrupted data : 0
LBRs sent : 0
LTMs sent : 0
LTMs received : 0
LTRs sent : 0
LTRs received : 0
Sequence number of next LTM request : 0
1DMs sent : 0
Valid 1DMs received : 0
Invalid 1DMs received : 0
DMMs sent : 10
DMRs sent : 0
Valid DMRs received : 10
Invalid DMRs received : 0
Remote MEP identifier: 101
Remote MAC address: 00:90:69:0a:48:57
Delay measurement statistics:
Index One-way delay Two-way delay
(usec) (usec)
1 100
2 92
3 92
4 111
5 110
6 119
7 122
8 92
9 92
10 108
Average two-way delay : 103 usec
Average two-way delay variation: 8 usec
Best case two-way delay : 92 usec
Worst case two-way delay : 122 usec
The collected delay statistics are also saved (up to 100 per session) and displayed as part of the MEP delay statistics on Router MX-1.
user@MX-1> show oam ethernet connectivity-fault-management delay-statistics maintenance-domain md6
MEP identifier: 201, MAC address: 00:90:69:0a:43:94
Remote MEP count: 1
Remote MAC address: 00:90:69:0a:48:57
Delay measurement statistics:
Index One-way delay Two-way delay
(usec) (usec)
1 100
2 92
3 92
4 111
5 110
6 119
7 122
8 92
9 92
10 108
Average two-way delay : 103 usec
Average two-way delay variation: 8 usec
Best case two-way delay : 92 usec
Worst case two-way delay : 122 usecSee Also
Managing Continuity Measurement Statistics
Displaying Continuity Measurement Statistics
Purpose
Display continuity measurement.
The show oam ethernet connectivity-fault-management delay-statistics
maintenance-domain md1 maintenance-association ma1 command is
enhanced to display continuity measurement statistics for MEPs in
the specified CFM maintenance association (MA) within the specified
CFM maintenance domain (MD).
Action
To display the ETH-DM statistics collected for MEPs belonging to MA
ma1and within MDmd1:user@host> show oam ethernet connectivity-fault-management delay-statistics maintenance-domain md1 maintenance-association ma1
See Also
Clearing Continuity Measurement Statistics
Purpose
Clear the continuity measurement statistics
By default, statistics are deleted for all MEPs attached to CFM-enabled interfaces on the router. However, you can filter the scope of the command by specifying an interface name.
Action
To clear the continuity measurement statistics for all MEPs attached to CFM-enabled interfaces on the router:
user@host> clear oam ethernet connectivity-fault-management continuity-measurement maintenance-domain md-name maintenance-association ma-name local-mep local-mep-id remote-mep remote-mep-id
See Also
Viewing Ethernet Frame Delay Measurements Statistics
Once Ethernet frame delay measurement statistics have been collected, they can be displayed.
To retrieve the last 100 Ethernet frame delay measurement
statistics per remote MEP or per CFM session, two types of show commands are provided:
For all OAM frame counters and Ethernet frame delay measurement statistics
For Ethernet frame delay measurement statistics only
To retrieve all Ethernet frame delay measurement statistics
for a given session, use the show oam ethernet connectivity-fault-management
mep-statistics maintenance-domain name maintenance-association name [local-mep identifier] [remote-mep identifier] [count count] command.
To retrieve only Ethernet frame delay measurement statistics
for a given session, use the show oam ethernet connectivity-fault-management
delay-statistics maintenance-domain name maintenance-association name [local-mep identifier] [remote-mep identifier] [count count] command.
The only difference in the two commands is the use of
the mep-statistics and delay-statistics keyword.
The fields for these commands are described in Table 4.
Parameter |
Parameter Range |
Description |
|---|---|---|
|
Existing MD name |
Specifies an existing maintenance domain (MD) to use. |
|
Existing MA identifier |
Specifies an existing maintenance association (MA) identifier to use. |
|
1–8191 |
When a MEP has been specified, display statistics only for the local MEP. |
|
1–8191 |
When a MEP has been specified, display statistics only for the discovered MEP. |
|
1–100 (default:100) |
The number of entries to display in the results table. By default, all 100 entries are displayed if they exist. |
For each MEP, you will see frame counters for sent and received Ethernet frame delay measurement frames whenever MEP statistics are displayed.
See Also
Managing ETH-DM Statistics and ETH-DM Frame Counts
- Displaying ETH-DM Statistics Only
- Displaying ETH-DM Statistics and Frame Counts
- Displaying ETH-DM Frame Counts for MEPs by Enclosing CFM Entity
- Displaying ETH-DM Frame Counts for MEPs by Interface or Domain Level
- Clearing ETH-DM Statistics and Frame Counts
Displaying ETH-DM Statistics Only
Purpose
Display ETH-DM statistics.
By default, the show oam ethernet connectivity-fault-management
delay-statistics command displays ETH-DM statistics for MEPs
in the specified CFM maintenance association (MA) within the specified
CFM maintenance domain (MD).
Action
To display the ETH-DM statistics collected for MEPs belonging to MA
ma1and within MDmd1:user@host> show oam ethernet connectivity-fault-management delay-statistics maintenance-domain ma1 maintenance-association ma1
To display the ETH-DM statistics collected for ETH-DM sessions for the local MEP
201belonging to MAma2and within MDmd2:user@host> show oam ethernet connectivity-fault-management delay-statistics maintenance-domain md2 maintenance-association ma2 local-mep 201
To display the ETH-DM statistics collected for ETH-DM sessions from local MEPs belonging to MA
ma3and within MDmd3to remote MEP302:user@host> show oam ethernet connectivity-fault-management delay-statistics maintenance-domain md3 maintenance-association ma3 remote-mep 302
See Also
Displaying ETH-DM Statistics and Frame Counts
Purpose
Display ETH-DM statistics and ETH-DM frame counts.
By default, the show oam ethernet connectivity-fault-management
mep-statistics command displays ETH-DM statistics and frame
counts for MEPs in the specified CFM maintenance association (MA)
within the specified CFM maintenance domain (MD).
Action
To display the ETH-DM statistics and ETH-DM frame counts for MEPs in MA
ma1and within MDmd1:user@host> show oam ethernet connectivity-fault-management mep-statistics maintenance-domain md1 maintenance-association ma1
To display the ETH-DM statistics and ETH-DM frame counts for the local MEP
201in MAma2and within MDmd2:user@host> show oam ethernet connectivity-fault-management mep-statistics maintenance-domain md2 maintenance-association ma2 local-mep 201
To display the ETH-DM statistics and ETH-DM frame counts for the local MEP in MD
md3and within MAma3that participates in an ETH-DM session with the remote MEP302:user@host> show oam ethernet connectivity-fault-management mep-statistics maintenance-domain ma3 maintenance-association ma3 remote-mep 302
See Also
Displaying ETH-DM Frame Counts for MEPs by Enclosing CFM Entity
Purpose
Display ETH-DM frame counts for CFM maintenance association end points (MEPs).
By default, the show oam ethernet connectivity-fault-management
mep-database command displays CFM database information for MEPs
in the specified CFM maintenance association (MA) within the specified
CFM maintenance domain (MD).
At the router attached to the initiator MEP for a one-way session, or at the router attached to the receiver MEP for a two-way session, you can only display ETH-DM frame counts.
Action
To display CFM database information (including ETH-DM frame counts) for all MEPs in MA
ma1within MDmd1:user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain ma1 maintenance-association ma1
To display CFM database information (including ETH-DM frame counts) only for local MEP
201in MAma1within MDmd1:user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md2 maintenance-association ma2 local-mep 201
To display CFM database information (including ETH-DM frame counts) only for remote MEP
302in MDmd3within MAma3:user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain ma3 maintenance-association ma3 remote-mep 302
See Also
Displaying ETH-DM Frame Counts for MEPs by Interface or Domain Level
Purpose
Display ETH-DM frame counts for CFM maintenance association end points (MEPs).
By default, the show oam ethernet connectivity-fault-management
interfaces command displays CFM database information for MEPs
attached to CFM-enabled Ethernet interfaces on the router or at a
maintenance domain level. For Ethernet interfaces that support ETH-DM,
any frame counts are also displayed when you specify the detail or extensive command option.
At the router attached to the initiator MEP for a one-way session, or at the router attached to the receiver MEP for a two-way session, you can only display ETH-DM frame counts.
Action
To display CFM database information (including ETH-DM frame counts) for all MEPs attached to CFM-enabled Ethernet interfaces on the router:
user@host> show oam ethernet connectivity-fault-management interfaces detail
To display CFM database information (including ETH-DM frame counts) only for the MEPs attached to CFM-enabled router interface
ge-5/2/9.0:user@host> show oam ethernet connectivity-fault-management interfaces ge-5/2/9.0 detail
To display CFM database information (including ETH-DM frame counts) only for MEPs enclosed within CFM maintenance domains (MDs) at level
6:user@host> show oam ethernet connectivity-fault-management interfaces level 6 detail
See Also
Clearing ETH-DM Statistics and Frame Counts
Purpose
Clear the ETH-DM statistics and ETH-DM frame counts.
By default, statistics and frame counts are deleted for all MEPs attached to CFM-enabled interfaces on the router. However, you can filter the scope of the command by specifying an interface name.
Action
To clear the ETH-DM statistics and ETH-DM frame counts for all MEPs attached to CFM-enabled interfaces on the router:
user@host> clear oam ethernet connectivity-fault-management statistics
To clear the ETH-DM statistics and ETH-DM frame counts only for MEPs attached to the logical interface
ge-0/5.9.0:user@host> clear oam ethernet connectivity-fault-management statistics ge-0/5/9.0