Carrier Ethernet 915-2624-01 RevD

(1)

Black Book

Edition 7

Carrier Ethernet

(2)

(3)

Your feedback is welcome

Our goal in the preparation of this Black Book was to create high-value, high-quality content. Your feedback is an important ingredient that will help guide our future books. If you have any comments regarding how we could improve the quality of this book, or suggestions for topics to be included in future Black Books, contact us at

[email protected]. Your feedback is greatly appreciated!

This publication may not be copied, in whole or in part, without Ixia’s consent.

RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the U.S. Government is subject to the restrictions set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR 52.227-19. Ixia, the Ixia logo, and all Ixia brand names and product names in this document are either trademarks or registered trademarks of Ixia in the United States and/or other countries. All other trademarks belong to their respective owners. The information herein is furnished for informational use only, is subject to change by Ixia without notice, and should not be construed as a commitment by Ixia. Ixia assumes no responsibility or liability for any errors or inaccuracies contained in this publication.

(4)

(5)

How to Read this Book

The book is structured as several standalone sections that discuss test methodologies by type. Every section starts by introducing the reader to relevant information from a

technology and testing perspective.

Each test case has the following organization structure:

Overview Provides background information specific to the test case.

Objective Describes the goal of the test.

Setup An illustration of the test configuration highlighting the test ports, simulated elements and other details.

Step-by-Step Instructions Detailed configuration procedures using Ixia test equipment and applications.

Test Variables A summary of the key test parameters that affect the test’s performance and scale. These can be modified to construct other tests.

Results Analysis Provides the background useful for test result analysis, explaining the metrics and providing examples of expected results.

Troubleshooting and Diagnostics

Provides guidance on how to troubleshoot common issues.

Conclusions Summarizes the result of the test.

Typographic Conventions

In this document, the following conventions are used to indicate items that are selected or typed by you:

• Bold items are those that you select or click on. It is also used to indicate text found on the current GUI screen.

(8)

Dear Reader

Ixia’s Black Books include a number of IP and wireless test methodologies that will help you become familiar with new technologies and the key testing issues associated with them.

The Black Books can be considered primers on technology and testing. They include test methodologies that can be used to verify device and system functionality and performance. The methodologies are universally applicable to any test equipment. Step by step instructions using Ixia’s test platform and applications are used to demonstrate the test methodology.

This seventh edition of the black books includes eighteen volumes covering some key technologies and test methodologies:

Volume 1 – Higher Speed Ethernet Volume 2 – QoS Validation

Volume 3 – Advanced MPLS

Volume 4 – LTE Evolved Packet Core Volume 5 – Application Delivery Volume 6 – Voice over IP

Volume 7 – Converged Data Center Volume 8 – Test Automation

Volume 9 – Converged Network Adapters

Volume 10 – Carrier Ethernet

Volume 11 – Ethernet Synchronization Volume 12 – IPv6 Transition Technologies Volume 13 – Video over IP

Volume 14 – Network Security Volume 15 – MPLS-TP

Volume 16 – Ultra Low Latency (ULL) Testing Volume 17 – Impairments

Volume 18 – LTE Access

A soft copy of each of the chapters of the books and the associated test configurations are available on Ixia’s Black Book website at http://www.ixiacom.com/blackbook. Registration is required to access this section of the Web site.

At Ixia, we know that the networking industry is constantly moving; we aim to be your technology partner through these ebbs and flows. We hope this Black Book series provides valuable insight into the evolution of our industry as it applies to test and measurement. Keep testing hard.

(9)

Carrier Ethernet

Test Methodologies

The tests in this booklet detail methodologies to verify the performance of Carrier Ethernet service enabling protocols. Subjects include Provider Bridges, Provider Backbone Bridges, Link OAM, Service OAM, E-LMI and Y.1564.

(10)

Introduction to Carrier Ethernet

Ethernet was developed as a LAN technology and was quickly adopted for its high speed, low latency, and plug-and-play features. Defined as an international standard by the IEEE 802.3 committee it has been widely deployed in the LAN. Since Ethernet provides the lowest cost per bit there was significant interest to use Ethernet in other parts of the network. First, Ethernet pushed into the Metro Area Networks (MAN) and its lower cost, lower complexity over existing technologies such as SONET/SDH proved successful. Although Ethernet usage continued to expand it was not without

challenges. As a replacement technology for other well established it lacked feature sets that other more mature MAN technologies addressed like scalability and reliability. For example, SONET/SDH can recover from a fault in sub 50 milliseconds. In an effort to accelerate the development and adoption of Ethernet as a service enabling

technology the Metro Ethernet Forum (MEF) was created. In addition to MAN services there was significant interest in using Ethernet as WAN L2 VPN service. The MEF has helped to advance this effort by defining Ethernet Services and related technical standards.

Since Ethernet is evolving from a LAN technology to a MAN technology and now even a WAN service it is becoming “Carrier Grade” and is now referred to as Carrier Ethernet. To achieve this status, the MEF has defined five attributes: Standardized Services,

Scalability, Reliability, Service Management and Quality of Service (See 0).

Figure 1-MEF Carrier Ethernet Attributes

To address the requirement for Standardized Services the MEF has defined the technical specification MEF 6 (now updated to 6.1) which outlines E-Line (EPL or EVPL), E-LAN and E-Tree services. Ethernet Private Line (EPL) defines the User Network Interface (UNI) as a

(11)

point services built by legacy technologies like TDM, SONET/SDH, Frame-Relay or ATM. E-LAN services can be used to replace multi-point-to-multi-point services built by legacy services like SONET/SDH, Frame-Relay, ATM or as an alternative to L3 based IP/MPLS. E-Tree is a rooted multipoint and again replaces services built with legacy technologies. These new connections are defined as Ethernet Virtual Connections (EVC). New Carrier Ethernet services are very attractive to enterprise customers since they are typically higher speed, lower cost and more flexible than legacy technologies. They are also effective for Service Providers since Ethernet is a less complicated, more cost effective transport to build services on. It is important to note that the MEF defines Carrier

Ethernet (CE) as a service from UNI to UNI. They do not define “how” a service is build end-to-end. Many networks have legacy infrastructures in the Metro and leverage an IP/MPLS core, so the actual implementation may be a mix of interworked technologies. A provider may choose to extend MPLS into the Metro and use PWE and VPLS to build CE services. Or, a provider may choose to upgrade or replace their existing Metro technology (like SONET) with native Ethernet switches (see 0). MEF 9 specification defines how to test MEF 6 service definitions.

Figure 2-Carrier Ethernet Architecture

To address the Quality of Service requirement the MEF has defined the MEF 10 (updated to 10.2) technical specification to define Service Attributes establishing traffic classes. This requires IEEE 802.1Q (VLAN) tagging providing use of the priority bits. Implementing QoS provides the ability to offer Service Level Agreements (SLA) and service profiles. The service definition can include bandwidth, latency, delay variation (jitter), frame loss and other bandwidth related parameters. MEF 14 specification defines how to test MEF 10 service attributes.

To address the scalability attribute of Carrier Ethernet services additional protocol development has evolved including IEEE 802.1ad Provider Bridges and IEEE 802.1ah Provider Backbone Bridges. These technologies enable service providers to build

(12)

Provider Bridges

The IEEE standard 802.1Q introduced VLAN “Q” tagging which provided a mechanism to virtually separate traffic into virtual LANs. The VLAN tag also added three bits for priority defined as Priority Code Points enabling up to eight levels of service. This was extremely effective for LAN based networks since IT managers could provide

connectivity with priority and security. As carriers began to use Ethernet in MANs a new standard was developed, IEEE 802.1ad Provider Bridges (PB). This standard defines how to add an additional VLAN tag to the Ethernet frame so that the provider could use tagging without using the customer tag. This new tag is defined as the S-VLAN tag (for Service Provider) while the existing tag is defined as the C-VLAN tag (for the Customer). One additional difference between the C-Tag and S-Tag is that the Canonical Format Indicator (CFI) bit is now used as a Drop Eligible Indicator (DEI) (see 0).

Figure 3-Sample Ethernet Frame Format adding VLAN Tags

This technology is often referred to as Q-in-Q since the original standard 802.1Q defines a VLAN tag and a second “Q” tag is being added. Since 802.1ad became a standard in 2005 it has been widely deployed as Ethernet use in the Metro increased. Leveraging Ethernet technology, 802.1Q and 802.1ad still use the same mechanisms including MAC address learning (with flooding) and Spanning Tree protocols are used for loop

prevention. Two limitations have been exposed as services have grown: MAC Learning and the 12 bit VLAN address space.

Since Provider bridges leverage Ethernet technology it results in all the Provider Bridges learning all the customer MAC addresses. This can begin to be a problem as customer networks grow and the numbers of customer networks grow. There are also concerns

(13)

number, but each E-Line configured uses a dedicated S-VLAN and providers are beginning to reach the address limitation in some networks. To address these limitations Provider Backbone Bridging evolved.

Provider Backbone Bridges

Provider Backbone Bridges (PBB) is defined by the IEEE 802.1ah (currently draft 4.2) specification. It was developed to address the scale limitations of PB and provide a migration path to a hierarchical Ethernet infrastructure. PBB encapsulates the client frame (which can be untagged, singled tagged or double tagged) with an additional MAC header, a Network tag (B-Tag) and a Service Instance Tag (I-TAG). (see 0)

Figure 4-Provider Backbone Bridges Ethernet Frame Format

While this may seem like a lot of overhead, most switches are leveraging hardware based forwarding and there is minimal performance impact. By using an additional MAC header the Backbone Destination Address (B-DA) and Backbone Source Address (B-SA) are used within the provider network preventing the core switches from needing to learn the customer MAC addresses.

With the addition of the I-Tag, the Service ID (I-SID) provides 24 bits (2^24) for unique backbone service identifiers within a single PBB Network. This is extremely scalable and attractive for Service Providers to migrate to. It also provides a nice migration path from PB since the frames can be directly encapsulated in PBB.

PBB is not yet widely implemented but there is growing interest and support being introduced by many Network Equipment Manufactures (NEM). Another standard in development is 802.1Qay Provider Backbone Bridging with Traffic Engineering (PBB-TE).

(14)

end to ensure the path is up. Using Service OAM an outage can be detected in sub-50ms and the node can move traffic to a backup path. PBB-TE is also gaining interest from Service Providers for certain service types.

Introduction to Ethernet OAM

Ethernet OAM

As Carrier Ethernet based services continue to grow Service Providers require an additional feature set to replace fault management capabilities legacy technologies provided. Operations Administration and Maintenance (OAM) benchmarks have been set by technologies like TDM, SONET, Frame-Relay and ATM. OAM benefits Service Providers by providing visibility to lower network layers and is used for troubleshooting and monitoring network services. OAM technologies can provide:

• Fault Detection • Fault Verification • Fault Isolation • Fault Recovery • Fault Notification

With these capabilities it can reduce OPEX by reducing truck rolls, troubleshooting time and overall network downtime. These are typically measured by Mean Time To

Diagnose (MTTD) and Mean Time To Repair (MTTR) metrics.

To address the MEF CE attribute for Service Management several technologies have been included as part of the new UNI Type 2 specifications. These include Link OAM, E-LMI (MEF 16) and Service OAM.

(15)

Link OAM

Link OAM is defined in the IEEE 802.3ah Clause 57 standard. It is referred to as “Ethernet in the first mile” since it only operates over a single segment and is typically used

between the Customer UNI (UNI-C) and Network UNI (UNI-N). This standard provides five key mechanisms:

Discovery The first phase of Link OAM session

establishment. It identifies devices in the network along with their OAM capabilities. Remote Loopback AN OAM entity can put its remote peer

into LB mode. This helps the network administrator during installation and troubleshooting.

Link Monitoring Provides a mechanism for an OAM entity to convey attributes and status in regard to link performance – particularly useful for slowly deteriorating link (e.g., symbol-error second count).

Remote Failure Indication Provides a way of detecting and

indicating compromised or downed links under a variety of conditions.

(Raises a flag at the local end, like SONET/SDH)

Polling of MIB Variables Read-only ‘in-band’ access to remote MIB variables

It uses a single OAM PDU format with a specific D-MAC, Type and Subtype. It is also a slow protocol so the max PDU rate is ten packets per second.

(16)

When testing Link OAM Ixia emulates the protocols as depicted below (see Figure 5.

Figure 5-. Ethernet Link OAM Testing

In addition to the Ethernet segments between the UNI-C and UNI-N Link OAM can be enabled on any segment in the network for additional OAM capabilities.

The MEF has defined MEF 21 technical specification as how to test Link OAM.

Service OAM

The second flavor of Ethernet OAM is known as Service OAM. A significant difference from Link OAM is that it can traverse layer 2 Ethernet hops running end-to-end over the service. There are two protocols that define Service OAM capabilities: IEEE 802.1ag Ethernet Connectivity and Fault Management (CFM) and ITU-T Y.1731 OAM Functions and Mechanisms for Ethernet Based Networks. The Y.1731 standard provides a superset of features. Both standards have in common the following:

Continuity Check Using a Continuity Check Message (CCM) over the service, each endpoint transmits a CCM at a configured interval (CCI). This is used as a “heartbeat” to ensure the other endpoints of the connection is up. Loopback This is essentially a layer 2 Ethernet ping

(echo request) which can be used to ping the far end MAC or points along the way.

Linktrace This is essentially a layer 2 Ethernet

traceroute which can be used to

determine the path to the far end MAC to isolate an issue.

(17)

In a Service OAM configuration there are two primary elements; a Maintenance End Point (MEP) and a Maintenance Intermediate Point (MIP). Service OAM also provides hierarchy so that Service Providers can segment the network into Maintenance Domains and also assign Levels. Levels are used so that different levels of visibility are provided on a service. This is especially useful if there are multiple operators’ networks that are used to build the service (see Figure 6).

Figure 6- Service OAM Hierarchy

The relationship between MEPs is known as a Maintenance Association (MA). Since Service Provider networks can enable hundreds or thousands of E-Line or E-LAN services the number of MAs maintained can get large quickly. Also, the CCI can be as fast as 3.33ms putting strain on the MPs that needs to maintain the Continuity Check Data Base (CCDB). Ixia can emulate MEPs and MEPs testing the Device Under Tests functionality and scalability when processing Service OAM messages.

Figure 7-Testing Service OAM

Y.1731 adds additional performance measurement capabilities including Delay Measurement, Delay Variation Measurement and Frame Loss. Since these typically require hardware processing only new generation equipment are enabling these

(18)

Ethernet Local Management Interface (E-LMI)

E-LMI is defined in the MEF 16 specification. The E-LMI protocol is used for the

configuration and management of Customer Edge (CE) equipment that does not rely on any IP based protocol like SNMP. The Ethernet flavor of this protocol is based on the ITU-T Q.933 and X.36 which defines Frame Relay Local Management Interface (FR-LMI). Enabling E-LMI provides a mechanism for a Service Provider to receive information and status of an Ethernet service and enable them to change the service status and

attributes. E-LMI is typically run on the User-Network-Interface (UNI) between the customer site (UNI-C) and the provider site (UNI-N).

Figure 8-E-LMI runs between the UNI-C and UNI-N The E-LMI protocol provides the following notifications:

• Notify the CE of the addition of an Ethernet Virtual Circuit (EVC) • Notify the CE of the deletion of an EVC

• Notify the CE of the availability state of a configured EVC (Active, Not Active, or Partially Active)

• Communicate UNI and EVC attributes to the CE

E-LMI messages are encapsulated within Ethernet frames and use the destination MAC address 01-80-C2-00-00-07. The Ethertype is 88-EE. The source address is the MAC of the sending port.

Note: The E-LMI message is not carried over a VLAN-tagged frame.

The following are the two messages defined for the E-LMI protocol: • Status

• Status Enquiry

(19)

• Message Type • Report Type

• Other information elements and sub-information elements Sub-information elements consist of:

• UNI Identifier • EVC Parameters • EVC Identifier • EVC Map Entry • Bandwidth Profile

EVC Status messages use the following possible states: New, Active, Not Active or Partially Active.

New Active Not Active

X X

X

Table 1. Possible Status Combinations for a Point-to-Point EVC

New Active Not Active Partially Active

X _X

X X

X

(20)

Report Type Information Element Value Information

Element

Full Status E-LMI Check Single EVC Asynchronous Status Full Status Continued Sequence Numbers X X X Data Instance X X X UNI Status X EVC Status X X X CE-VLAN ID/EVC MAP X X

(21)

E-LMI uses the following periodic polling and asynchronous updates: • Polling procedure invoked by CE

• N391 based Polling Counter, polling cycles between Full Status exchanges • N393 based Status Counter, number of consecutive errors

• T391 based Polling Timer (PT), UNI-C transmits Status Enquiry

• T392 based Polling Verification Timer (PVT), timer by which UNI-N Expects to be polled.

Figure 9-E-LMI Periodic Polling and Asynchronous Updates

E-LMI provides communication between the UNI-C and the UNI-N. This enables the Service Provider to manage the Carrier Ethernet service more effectively. E-LMI is added to the MEF UNI Type 2 Implementation Agreement defined in the MEF 20 specification.

(22)

Introduction to Ethernet Service Activation Testing

Ethernet Service Activation Measurement (SAM)

In 2010, ITU-T tried to address the shortcomings of RFC 2544 for Ethernet Service testing and defined new standards based test methodology which could assess the quality of service, and network performance of an Ethernet-based service. Y.1564 is designed for Ethernet-based services and does not specifically test or characterize performance using upper layer protocols as TCP. It started with Y.156 SAM, and is a standard with Y.1564 in March of 2011.

Why is a new test methodology needed?

RFC 2544 was created in 1999, test network devices, not services. There are a few disadvantages (most test suites however added additional functionality beyond the documented requirements.) The disadvantages are as follows:

• It is time consuming, since, each test is run sequentially, as designed • It is performance based, so it specifies a short duration

• The traffic requirement is a single stream, which does not address QoS based services

• The tests find the absolute performance limit of a device, not a service

• The throughput test uses a binary search which can have multiple iterations, and hence consume more time.

• The latency methodology specifies a sub-optimal mechanism, and not per-packet measurement

(23)

With these disadvantages, there is room for new methodology which is focused and optimized to test Ethernet-based services. These services include MEF standards like E-LINE, E-LAN and E-Tree (as defined in MEF 6.1). The methodology is designed to test end-to-end between the customer endpoints referred to as the UNI-C interfaces.

Figure 10-Ethernet Services are tested UNI-C to UNI-C Y.1564 is designed to test Ethernet-based service attributes including:

• Connection type

• Traffic parameters: QoS (including VLAN info.), traffic type (data vs. management), etc.

• Bandwidth profile (based on G.8011, applicable at the ingress and egress UNI) • Performance criteria: Frame Loss, Frame Delay, Frame Delay Variation

(24)

MEF 10.1 defines three types of bandwidth profiles including: port-based, port/VLAN-based, Port/VLAN/CoS-based. These are covered in Y.1564.

Figure 11-MEF 10.1 types of bandwidth profiles

A Bandwidth Profile defines the following attributes (as defined in G.8011):

• Committed Information Rate (CIR) – The maximum information rate the network is committed to transfer while meeting the performance level guaranteed in the Service Level Agreement (SLA). Performance guarantee is only at or below CIR. • Committed Burst Size (CBS) - The number of allocated bytes available for bursts

of ingress service frames transmitted at temporary rates above the CIR, while meeting the SLA

• Excess Information Rate (EIR) - The maximum information rate at which a user can exceed its expecting that excess traffic is carried through the network • Excess Burst Size (EBS) - The number of allocated EIR conformant bytes available

(25)

There are two main phases of the Y.1564 methodology; a “Configuration” phase and a “Performance “phase:

• Configuration: To validate that each Ethernet-based service is correctly configured

• Performance: To validate the quality of the services as delivered to the end-user

(26)

During the Network Configuration test, each service is tested individually with traffic starting at 25% of CIR, and stepping up to the configured CIR value. Post CIR, it steps to CIR+EIR. Final iteration is at CIR+EIR+ 25% EIR. In a typical test there are six iterations per configured service. After the Configuration test, is the Ethernet Services test runs parallel with CIR with single iteration of the configured services.

Figure 13-Network Configuration Test Iterations per Service Test results listed below are compared against the expected service level:

• Throughput - throughput results are available for all flows simultaneously. For each flow, the minimum, maximum, average and current throughput is displayed.

• Frame Transfer Delay (FTD) - FTD results are displayed for all flows simultaneously. For each flow, the minimum, maximum, mean, median and current FTD is

displayed. The display of the results also indicates whether the measurement is made end-to-end or round-trip.

• Frame Delay Variation (FDV) - FDV results are displayed for all flows

simultaneously. For each flow, the updated result or current FDV is displayed. The display of the results also indicates whether the measurement is made end-to-end or round-trip

• Frame Loss Ratio (FLR) - FLR results are displayed for all flows simultaneously. For each flow, the count and the ratio are displayed.

(27)

Based on the test results the service is within the SLA, and “pass” or exceed the expected SLA for delay, delay variation, or, loss and “fail”.

(28)

Testing Provider Bridges (802.1ad) and Provider Backbone Bridges

(802.1ah)

Introduction to Provider Bridges (802.1ad)

IEEE 802.1ad (Provider Bridges) is an amendment to IEEE 802.1Q that provides separate instances of the MAC services to multiple independent users of a Bridged LAN in a manner that does not require cooperation among the users, and requires a minimum of cooperation between the users and the provider of the MAC service.

802.1ad builds on the VLAN capability provided by 802.1Q and adds another level of VLAN hierarchy, the S-TAG, to the Ethernet Frame, that is to be used by the service providers to separate traffic coming from different customers using their own private VLANs.

Using 801.ad, service providers can let customers run their own VLANs using the VLAN provided by the service provider. This way the service provider can simply configure one VLAN for the customer and customer can then treat that VLAN as if it was a trunk.

Figure 14-Frame Format of Provider Bridges (802.1ad)

Relevant Standards

(29)

(30)

Test Case: Provider Bridges 802.1ad E-Line Services

Overview

The Provider bridges perform the forwarding of traffic on the basis of the correct B-Tag and I-SID values. In this test we will be using two Ixia ports acting as backbone bridges to send PBB traffic to the DUT. The egress traffic from the DUT is then tracked to ensure that the forwarding decisions are taken correctly.

Objective

The objective of this test is to verify that the DUT forwards customer frames that are configured with the correct Service TAG. In addition, the DUT should not forward traffic on to ports that are not configured with the correct C-TAG.

Setup

A pair of Ixia ports emulating as Backbone Edge Bridges are connected to the DUT. The DUT is configured for port-based service over S-VLAN 100. IxNetwork Port 1 and IxNetwork Port 2 are configured for traffic with S-VLAN 100 and C-VID 2-4094. IxNetwork Port 3 is configured with S-VLAN 200 and C-VID 2-4094.

In this test setup, the Provider Bridge DUT will be receiving Q-in-Q traffic from Ixia-emulated Backbone Edge Bridge (BEB) on its ingress port and forwarding the Q-in-Q traffic out to the correct egress port toward another Ixia-emulated BEB.

(31)

Step by Step Instructions

1. Add ports to the test setup.

Figure 16-Port Selection

2. In the Test Configuration window, click on Traffic. This will take you to the Traffic configuration window in the main pane in the center of GUI.

Figure 17-Traffic Configuration

3. Click the Advanced Wizard icon to start the traffic configuration.

(32)

4. First, name the Traffic Item. In the example, the Traffic Item is named PB for Provider Bridges.

a. In the Type of Traffic, select Raw.

b. Under Source/Destination Endpoints, select the Source and Destination ports. Then press Next.

Figure 19-Traffic Type and Endpoint Selection

5. In the Packet/QoS step, there is a packet editor view. Highlight the Ethernet II, then right-click select Append Protocol.

Figure 20-Append Protocol

6. In the Select Protocol pop-up window, select VLAN and press OK.

(33)

7. Select the VLAN header added in step 6 above, and select Append Protocol. Add another VLAN protocol header.

Figure 22-Appending VLAN Header

8. Click the icon for expanding the frame protocols tree node.

Figure 23-Expanding Protocols

9. Then, in the protocol tree, configure 4093 MAC Addresses for Destination and Source MAC Addresses.

Figure 24-MAC Address Configuration

• Click the clock icon to enable tracking on that particular field. The Tracking option will get statistics for the field selected. You may also review the fields on which tracking was enabled in the Track Flows by step, described below (step 16, page 27).

(34)

10. Highlight the Ethernet-Type and select Edit.

(35)

11. Enter a single value of 88a8 to change the Ether-type from 0x8100 to 0x88A8.

Figure 26-Entering Ethernet-Type Value

12. Now move to the first VLAN header and configure its VLAN-ID (S-TAG) to have the value 100.

Figure 27-Configuring Outer VLAN-ID Value

13. Moving onto the next VLAN header, configure an incrementing range of VLAN-IDs that will configure the C-TAG values from 2 to 4094 for a total of 4093 C-TAGs.

(36)

The above steps will result in the frames being generated as shown in Figure 29.

Figure 29-Resultant Frame Created 14. Click the icon in the left pane.

15. Under Flow Group Transmission Mode, select Fixed Packet Count and enter 5000 in the Stop After packets field.

Figure 30-Setting Fixed Number of Packets to be Transmitted 16. Click Flow Tracking in the left pane.

Under Track Flows by, you will see tracking already set on the fields for which tracking was enabled earlier (step 9 page 24).

Note: You may check the Enable Egress Tracking box to enable Egress tracking

(37)

17. Click at the bottom on the Advanced Traffic Wizard window.

18. Apply traffic by clicking the traffic apply button

19. Switch view to the Statistics page by clicking in the left pane. This will display the Traffic Statistics window

20. Click the start traffic button .

Pressing this button should send 5000 packets that were configured in step 15 above. We will confirm this by looking at the statistics.

21. Click Traffic Item Statistics. This will bring the statistics for the Traffic Item PB we configured through the Advanced Traffic Wizard.

Figure 31-Selecting Traffic Item Statistics 22. Now start traffic by clicking the start traffic icon

Notice that 5000 frames were transmitted and all of them were received with no packet loss.

(38)

23. To confirm that the traffic was sent from the correct MAC Address source, right-click the Traffic Item PB and select Drill Down per Ethernet II: Source MAC

Address.

Figure 33-Drilling down to View Statistics by Source MAC addresses

24. This will present a drill-down list of all Source MAC Addresses. Each row contains the traffic statistics associated with each Source MAC address. Notice that there are a total of 4093 rows. This corresponds to the number of Source MAC

Addresses configured in Step 9, above.

Figure 34-Per-Session Statistics Arranged by Source MAC Addresses

Results Analysis

DUT 802.1ad bridging performance can be judged using multiple criteria. Checking that the DUT forwarded the statistics to the correct port with zero loss indicates that only the

(39)

hand, the port with a different S-TAG value configured received no frames, indicating the correct behavior by the DUT.

Test Variables

The following variables can be used to verify the behavior of a DUT bridge: 1. Source and Destination MAC Addresses

Increasing the number of MAC Addresses results in DUT having to store more MAC Addresses in its MAC Address table.

2. S-TAG 3. C-TAG

The larger the number of S-TAG and C-TAGs configured, the more state DUT has to maintain to forward the frames to the correct destination

4. Ports with different associated S-TAG and C-TAG values

The larger the number of ports, the more state needs to be maintained at the DUT to associate ports with TAG values.

Troubleshooting and diagnostics

Problem

Description

100 % frame loss

on Receive port Confirm that the Receive port is configured with the correct S-TAG/C-TAG. If true, then check that the transmit port’s S-TAG and C-TAG values match the ones on the expected receive port.

Or the DUT has not done the MAC Address learning on all ports, resulting in traffic loss.

Need to ensure that if Spanning Tree is enabled on the port, the port will be in blocking state.

0% frame loss on incorrect Receive port (Port 3 in this setup)

Confirm configured S-TAG/C-TAG values. Also check that the transmit port’s S-TAG and C-TAG values match the ones on the expected receive port and not the incorrect receive port

Conclusions

(40)

Introduction to Provider Backbone Bridges (802.1ah)

IEEE 802.1ah (Provider Backbone Bridges, PBB) provides for routing of customer networks over service provider networks while preserving each customer’s unique VLAN

definitions.

The main thrust of 802.1ah is the complete separation of provider and customer

domains. This requires a new Ethernet header that has the following basic components. Backbone:

Backbone Destination Address (B-DA) Backbone Source Address (B-SA) Service:

Service Instance VLAN Identifier (I-SID) Backbone VLAN ID (B-VID)

Original Ethernet frame: MAC source address MAC destination address Customer VLAN ID (C-TAG) Payload

(41)

The bridges in PBB learn on the basis of B-SA and the ingress port values and are unaware of the customer MAC address. This allows for complete separation between the customer and provider domains.

To distinguish between services in the PBB domain, I-SID values are used. In networks each service (customer VLAN) is mapped to an I-SID, this way the service provider can burn a B-TAG for each customer and use I-SID to separate different services for each customer. This allows for much higher scalability numbers.

(42)

Test Case: Provider Bridges 802.1ah E-LAN Services

Overview

The PBB Backbone bridges perform the forwarding of traffic on the basis of the correct B-Tag and I-SID values. In this test we will be using three Ixia ports acting as backbone bridges. One Ixia emulated backbone bridge port will be transmitting MAC-in-MAC traffic to the DUT and the other two Ixia emulated backbone bridge ports will be receiving traffic from the DUT. The egress traffic from the DUT is then tracked to ensure that the forwarding decisions are taken correctly.

Objective

The objective of this test is to verify that the DUT forwards backbone frames only to those bridges that are configured with correct I-SID and B-TAG values. The DUT should not forward traffic on to ports that are not configured with the correct values.

(43)

Setup

A pair of Ixia ports emulating Backbone Edge Bridges are connected to the DUT. The DUT is configured for I-SID values 1->10 and B-TAG 100-> 110 on DUT port 2. While DUT port 3 is configured for a different set of I-SID and B-TAG values.

Ixia port 1 is going to transmit MAC-in-MAC backbone traffic to the DUT (Provider Backbone Bridge) and Ixia ports 2 and 3 are set to receive forwarded traffic from the DUT. Since the DUT is forwarding traffic, both the Ixia ports are expecting to receive the traffic from Ixia port1.

(44)

Step by Step Instructions

1. Add ports to the test setup.

Figure 37-Selecting Ports

2. In the Test Configuration window, click Traffic. This will take you to the Traffic configuration window in the main pane in the center of the GUI.

Figure 38-Configuring Traffic Options

3. Click the Advanced Wizard icon to start the traffic configuration.

(45)

4. First, name the Traffic Item. In the example, the Traffic Item is named PBB for Provider Backbone Bridges.

• In the Type of Traffic, select Raw.

• Under Source/Destination Endpoints, select the Source and Destination ports. Press Next.

Figure 40-Selecting Traffic Type and Endpoints

5. In the Packet/QoS step, there is a packet editor view. Highlight Ethernet II, then right-click select Replace Protocol.

Figure 41-Replacing Ethernet with MAC-in-MAC

6. In the Select Protocol pop-up window, select MAC in MAC and press OK.

(46)

The packet format will change as shown in Figure 43.

Figure 43-MAC-in-MAC Frame 7. Click the icon for expanding the protocols tree node.

Figure 44-Expanding Frame Tree Protocols

8. In the protocol tree, configure 4093 MAC Addresses for Destination and Source MAC Addresses.

Figure 45-Configuring Backbone Source and Destination MAC Addresses 9. Configure 10 B-TAG values in the B-VLAN ID field and enable tracking.

Figure 46-Configuring B-TAG Values and Enabling Tracking

(47)

• The Tracking option provides the ability to get statistics for the field selected.

10. Configure I-SID value (1 through 10) in the I-Tag branch.

(48)

11. Enable Tracking by clicking the clock icon next to the I-SID field. • The above steps will result in the frame shown in Figure 48.

Figure 48-Final MAC-in-MAC Frame 12. Click the in the left pane.

13. Under Flow Group Transmission Mode, select Fixed Packet Count and enter 6000 in the Stop After packets field.

(49)

14. Click on Flow Tracking in the left pane.

Under Track Flows by, you will see tracking already set on the fields for which tracking was enabled in the previous steps.

15. Click the icon in the left pane and then click the View Flow

Groups/Packets button on the top right.

This will result in all the 4093 generated packets to be listed:

Figure 50-Previewing the generated frames

16. Click on at the bottom on Advanced Traffic Wizard window. This will generate the Traffic Item.

17. Apply Traffic Item to the ports by clicking the traffic apply button

18. Switch view to the Statistics page by clicking the button in the left hand pane. This will display the Traffic Statistics window.

19. Click the start traffic button .

Pressing this button should send 6000 packets that we configured in step 13, above. We will confirm this by looking at the statistics.

(50)

20. Click on Traffic Item Statistics. This will display the statistics for the Traffic Item PBB we configured through Advanced Traffic Wizard.

Figure 51-Selecting Traffic Item Statistics 21. Now start traffic.

Notice that 6000 frames were transmitted and half of them were received with 50% packet loss.

Figure 52-Traffic Item Statistics

22. Click Port Statistics in the left pane to bring up traffic statistics per port.

Figure 53-Per-port traffic statistics

Notice that one port has received 6000 packets, whereas the other has received none.

(51)

23. To confirm that the traffic was sent with the correct B-TAG source, right-click the Traffic Item and select Drill Down per MAC in MAC: B-VLAN ID.

Figure 54-Drilling down to MAC-in-MAC B-TAG values

24. This will display the User Defined Statistics view, with statistics for all the B-TAGs traffic

(52)

25. To observe the traffic statistics by I-SID, right-click the Traffic Item and select Drill

Down per MAC in MAC: I-SID.

Figure 56-Traffic Statistics Arranged by MAC-in-MAC I-SID Values

Results Analysis

DUT 802.1ah bridging performance can be judged using multiple criteria. Confirming that the DUT forwarded the statistics to the correct port with zero loss indicates that only the pertinent traffic from the MAC-in-MAC cloud was forwarded to the correct port. On the other hand, the port with a different S-TAG value received no frames, indicating the correct behavior by DUT. Since we had configured both the ports to receive traffic, we are showing a 50% loss as the received frames total exactly 50% of the expected received frames.

Test Variables

The following variables can be used to verify the behavior of DUT bridge: 1. Source and Destination MAC Addresses

Increasing the number of MAC Addresses results in the DUT having to store more MAC Addresses in its MAC Address table.

2. B-TAG 3. I-SID

The larger the number of B-TAG and I-SIDs configured, the more states the DUT has to maintain to forward the frames to the correct destination.

(53)

The larger the number of ports, the more states that need to be maintained at the DUT to associate ports with TAG values.

Troubleshooting and diagnostics

Problem

Description

100 % frame loss

on Receive port Confirm that the Receive port is configured with the correct TAG/C-TAG. If that is true, then check that the transmit port’s S-TAG and C-S-TAG values match the ones on the expected

receive port.

Or the DUT has not done the MAC Address learning on all ports, resulting in traffic loss.

Need to ensure that if Spanning Tree is enabled on the port, the port will be in blocking state.

0% frame loss on incorrect Receive port (Port 3 in this setup)

Confirm configured S-TAG/C-TAG values. Also check that the transmit port’s S-TAG and C-TAG values match the ones on the expected receive port and not the incorrect receive port

Conclusions

Ethernet 802.1ad E-Line provides for point-to-point service on provider networks.

(54)

Ethernet/Link OAM (802.3ah) Functional Verification

Introduction to Ethernet/Link OAM

Ethernet/Link OAM is used between two Data Termination Equipment (DTE) devices to monitor the operation and health condition of a physical link, and to improve fault isolation when trouble arises. Under the IEEE 802.3ah architecture, OAMPDUs are an integral component. These packet data units (PDUs) are normal Ethernet frames that use a specific multicast destination address and EtherType.

Figure 57-OAMPDU Format and Flag/Code Definition

The discovery is the first phase of the IEEE 802.3ah OAM protocol and it consists of a sequence of OAMPDU exchanges between local and remote DTEs to discover each other’s capabilities, such as mode, loopback support, maximum PDU size, and a few other state and configuration parameters. When both ends of the link are satisfied with the settings uncovered during discovery, link OAM is enabled on the link.

(55)

Remote failure is indicated by three flags in the OAMPDU for easy diagnostics and isolation. Link Fault flag is raised when a DTE stops receiving a transmit signal from its peer. Dying Gasp flag is raised when a DTE is about to reset, reboot, or otherwise go to an operationally down state. Critical Event flag indicates a severe error condition that does not result in a complete re-set or re-boot by the peer entity.

Ethernet/Link OAM also defines a set of standard event conditions that Ethernet links should monitor in normal operation and, if detected, should notify a peer entity. These conditions reflect a degraded, but not yet inoperable, Ethernet connection. These conditions include threshold-crossing alarms on the frequency of symbol errors and frame errors.

Ethernet/Link OAM further provides the capability to put a remote entity into loopback mode using a loopback-control OAMPDU. When an OAM entity is in loopback mode, every frame received is transmitted back on that same port except for OAMPDUs and pause frames.

Last but not least, the IEEE 802.3ah Ethernet OAM specifications define a generic mechanism for one OAM entity to query another for the value of any management information base (MIB) variable, which is known as MIB variable retrieval. MIB variables include all performance and error statistics maintained on an Ethernet link. This

capability provides a generic monitoring capability for one DTE to monitor any parameter on another DTE for performance or error detection.

(56)

Test Case: Ethernet/Link OAM Discovery Functional Verification

Overview

OAM discovery is the first phase in OAM protocol operation and is delivered over Information TLV PDU (code=0x00). It contains both the local and remote information for the physical link. A loss of link or a non-reception of OAMPDU for 5 seconds will cause re-start of the OAM discovery process.

(57)

Both local and remote information TLVs are further divided to contain many state and configuration parameters, as detailed below. The OAM discovery process is to ensure both ends of the link agree on the capabilities and, when they do, OAM is enabled.

Figure 59-Information TLV Expanded

Vars – Variable Retrieval support Events – Link Events support LB – Loopback support Unidir – Unidirectional support Mode – Active or Passive mode Max OAM PDU Size – Max PDU size

Objective

There are many variants of the same test as each capability bit can deserve a separate test case. For complete and accurate protocol conformance verification, Ixia IxANVL Link OAM Test Suite is recommended. For the tests presented as examples here, the objective is to illustrate how to use IxNetwork to perform sample tests that include

1) verification of DUT mode (active or passive), and 2) verification of DUT Vars, Events, LB and Unidirectional capability support.

(58)

Setup

There is only one Ethernet/Link OAM session per physical port, therefore a single test port is sufficient to perform all the needed verification, as illustrated in the diagram below. More test ports can be used to scale up the test.

Figure 60-Ethernet/Link OAM Test Setup

Step by Step Instructions, OAM Discovery

(59)

Figure 61-Launch Link-OAM Protocol Wizard

2. On Screen #2 of 5, use the default MAC address or modify as appropriate. Click to set the Operation Mode to be Active or Passive.

When a port is configured in Passive mode, it is not supposed to initiate

Discovery process nor should it send Variable Request PDU or Loopback Control PDU. If you’re testing a DUT that operates in Passive mode, then you must

configure Ixia to be in Active mode. If you’re testing a DUT that operates in Active mode, you can configure Ixia in either Active or Passive mode.

(60)

3. Enable applicable capability bits (all are selected in this example) and remote failure indication flags (none are selected). Keep in mind that all flags can be toggled on or off in the GUI after wizard configuration. Organization Specific TLV can be configured in a separate pop-up window.

(61)

4. On Screen #3 of 5, enter events notification details as desired. This will be used by Ixia emulated OAM entity to report to DUT about its error conditions. The

emulation software is fairly open in terms of error conditions that can be simulated.

(62)

5. On screen #4 of 5, input the number of MIB variables that will be used to respond to the DUT when MIB variable request is received by the Ixia emulator. For a large number of entries, it is common practice to click the column header and then perform a grid level operation such as increment or decrement.

(63)

6. On the last screen of the Link OAM wizard, assign a meaningful name and then select either option 2 or 3 to save the configuration to the physical port.

Figure 65-Link-OAM wizard screen #5 of 5

Once the configuration is done via the wizard, you can go the GUI to make protocol-specific changes and to observe DUT behavior. You can achieve many functional verifications using this method. Below are a few examples to show you how to achieve specific test objectives.

(64)

7. To change Ixia emulated OAM mode from Active to Passive or vice versa, go to

Information OAMPDU tab and click the Operation Mode to select Active or Passive. Then either click Start to start the emulation or click Restart Discovery if

the emulation has started already.

Figure 66-Change of Operation Mode

If the DUT is configured as Active mode, you will see discovery information from Ixia as shown in Figure 67.

(65)

If both ixia and the DUT are configured as Passive mode, you will not be able to see any learned info, as shown in Figure 68.

Figure 68-No Discovery Info When Both Are in Passive

8. To send new capability options from Ixia to the DUT and/or to send remote failure indication, simply toggle the applicable bits under Information OAMPDU and click Send Update Parameters.

(66)

9. To verify new capability and remote failure indication from the DUT and ensure it reflects what was advertised by Ixia.

(67)

10. To view capability and remote failure indication flags advertised by the DUT, simply go to the Learned Info and click Refresh. It also displays all other values in the OAMPDU. The expected result is that Remote Stable = Yes and Local

Discovery State = Send_Any. If either the remote or local state is different, it is a

good indication that there are mismatches in advertised capabilities.

Figure 71-View of DUT Capability Options and Remote Failure Flags

In addition to the learned info for a specific session, the statistics page also provides a global view of all events in a single page across all test ports involved. The DUT also provides similar CLI to show all OAM statistics on a single test port.

(68)

(69)

Test Variables

Any of the following variables may be used to verify DUT Link OAM discovery functions: Number of test ports – if there is a need to verify OAM capability across multiple DUT

ports

Operation Mode

Remote Failure Indication flags Capability flags

MTU Size OUI values

Result Analysis

When sending new capability options or new remote failure indication flags, you can go to the DUT and verify if it is being learned by the DUT. Ixia has exposed all options in the GUI as radio buttons. Simply click the application options, then click Send Updated

Parameters.

(70)

Figure 75-DUT Display of New Capability and Remote Failure Flags

When verifying the DUT’s new capability or remote failure indication flags, go to

Learned Info under the protocol tree pane. The Discovered Info tab will display every

single protocol option learned from the DUT. It is very easy to verify that they are consistent with the DUT’s configuration and, if not, where the differences are.

(71)

Troubleshooting and diagnostics

Problem

Description

Cannot display learned info from DUT

Check to make sure either the DUT or Ixia emulator is configured in Active mode. If both are configured in passive mode, none of them will start discovery process hence no learned info will be displayed.

DUT does not reflect new capability options or new failure indications

When new options or flags are toggled, it’s required to click the Send Updated Parameters button in order to force the on –the-fly change.

Conclusions

Ethernet/Link OAM discovery is the first phase of OAM protocol operation. Ixia OAM emulator provides the flexibility and ease of use to verify all protocol options and flags.

DUT Config Excerpt

Interface FastEthernet1/0/1 switchport mode access ethernet oam mode passive

ethernet oam remote-loopback supported no etherent oam link-monitor on

(72)

Test Case: Ethernet/Link OAM Event Notification

Overview

Ethernet/Link OAM Event Notification is meant to notify the remote entity about the local link conditions in terms of errors. These conditions include threshold-crossing alarms on the four categories of errors listed below.

Figure 77-Link OAM Event Notification PDU Format

Errored Symbol Period Event - A window, measured in number of symbols, where the number of errored symbols exceeded a threshold.

Errored Frame Event - A window, measured in 100ms intervals, where the number of errored frames exceeded a threshold.

Errored Frame Period Event - A window, measured in received frames, where the number of errored frames exceeded a threshold.

Errored Frame Seconds Summary - A window, in 100ms intervals, where the number of errored frame seconds exceeded a threshold.

(73)

Objective

The objective of this test is to illustrate how to use IxNetwork either to inject applicable error events to a DUT or to observe error events reported by a DUT when link monitoring is enabled.

Setup

A single test port is sufficient to complete the functional verification of event notification, as illustrated below. More ports can be used if more OAM sessions are required.

Figure 78-Ethernet/Link OAM Event Notification Setup

Step by Step instructions, OAM Event Notification

1. Steps 1 to 5 in the Ethernet/Link OAM Discovery test (page 49) can be re-used to set up OAM emulation. They are not repeated here for this test.

(74)

2. To send event notification TLVs to the DUT, first select the test port on the protocol tree. Then go to Event TLVs tab. Enable one Error Event at a time or all at once. When ready to send, click Start/Send button. By default the error event is sent as a single shot. You can configure Ixia to send periodically. You can verify if the DUT has successfully received and interpreted the TLV by type corresponding CLI. The diagram below shows DUT CLI output in conjunction with Ixia setup for

Errored Symbol Period Event.

(75)

3. Similarly, enable the Ixia side to send the Errored Frame Event TLV with desired parameter and verify from the DUT whether or not the DUT has received and interpreted the TLV that matches Ixia’s setup. The diagram below shows Ixia’s setup and the corresponding output from the DUT.

(76)

4. In a very similar way, you can enable the other two error events, Errored Frame

Period and Errored Frame Seconds, one at a time. Or you can enable all error

events together and verify the DUT’s CLI output. Below is an example of DUT CLI output when all four error events are enabled.

(77)

5. To verify the DUT’s capability of event notification, select Learned Info from the protocol tree. Then select the Event Notification tab. Click Refresh to get the latest view what has been learned from the DUT.

Figure 82-Verifying DUT Event Notification Capability

Test Variables

Any of the following variables may be used to verify DUT Link OAM Event Notification functions:

• Number of test ports – if there is a need to verify OAM Event Notification across multiple DUT ports

• Operation Mode – Active or Passive

• Event Notification in conjunction with Remote Failure Indication flags • Event Notification in conjunction with Capability flags

(78)

Results Analysis

By use of Learned Info on Ixia and CLI output on DUT, it is very easy to verify if the DUT has received and interpreted a specific error event correctly, based on standard. Ixia Link-OAM emulation also gives global statistics that contain every single Link OAM operation statistic in a single page.

(79)

Troubleshooting and diagnostics

Problem

Description

Check to make sure either the DUT or Ixia emulator is configured in Active mode. If both are configured in passive mode, none of them will start discovery process, so no learned info will be displayed.

DUT does not reflect new event notification

When new options or flags are toggled, it is required to click the Send Updated Parameters button to force the on–the-fly change before clicking on Start/Send Link Event PDU

Ixia is not sending

Event Notification During discovery phase, if Ixia concludes that local is not in stable state (can be verified via Learned >Discovered Info->Local Information-Info->Local Stable), it will refuse to send any Event Notification to DUT. To fix this, you can override the local stable state as shown here:

Conclusions

Ethernet/Link OAM Event Notification allows communication to the peer regarding current link status in terms of error conditions. Ixia Link-OAM emulation provides a powerful yet flexible means to either inject applicable error events to the DUT or to verify error conditions from the DUT.

DUT Config Excerpt

Interface FastEthernet1/0/1

switchport mode access ethernet oam mode passive

ethernet oam remote-loopback supported ethernet oam

(80)

Test Case: Ethernet/Link OAM Remote Loopback

Overview

Loopback is an effective trouble shooting and isolation method that is commonly used by traditional technologies such as SONET/SDH, T1/E1 and so many others. In order for Ethernet to replace the old technologies, it must support loopback. Ethernet/Link OAM defines procedures to put a remote entity into loopback mode using a loopback-control OAMPDU.

When an OAM entity is in loopback mode, every frame received is transmitted back on that same port except for OAMPDUs and pause frames. When an OAM entity is

configured in Passive mode, it can only respond to, but not initiate, a loopback request. In order to both initiate and respond to a loopback request, it must be configured in Active mode.

(81)

Objective

The test objective is to discover whether or not the DUT can respond to and/or initiate a loopback request. Data plane traffic is used to verify the hardware status.

Setup

One or more Ixia test ports can be used to verify DUT’s OAM loopback capability.

Figure 85-Link OAM Remote Loopback Test Setup

Step by Step Instructions

1. Repeat steps 1 thru 5 in the Ethernet/Link OAM Discovery test (page 49) if needed for a quick emulation setup using the Link-OAM protocol wizard.

(82)

2. Configure Ixia as Active mode.

Figure 86-Configure Ixia Link-OAM in Active Operation Mode

3. Verify the DUT is also in Active mode and, more importantly, the DUT indeed supports Remote Loopback.

(83)

4. To send a loopback request, first select the Learned Info. Then choose Enable

Loopback and click Send Loopback. To confirm DUT loopback status, click Refresh and verify Remote Mux Action and Remote Parser Action. Also confirm

loopback status from the DUT — both before and after the request.

Figure 88-Sequence to Send a Loopback Request

(84)

(85)

5. Ultimately, you will need to verify the loopback by use of data plane traffic. The simplest way to do this is to click Quick Flow Groups and add 1 flow group to the port in use. A quick flow group will be generated.

(86)

6. You can quickly modify the content of the frame by clicking the Encapsulation

Editor and modifying the Src/Dest MAC address as appropriate. Add any high

layer protocols as you wish.

Figure 92-Modify Frame Contents As Needed

7. Click L2-L3 Traffic to push flow group definition to Ixia hardware and then click the green arrow to start sending traffic. Verify the traffic from Statistics > Port

Statistics. As expected, Frames TX and Frames RX, as well as Frames Tx Rate and Frames Rx Rate are matching. A small variant is due to the OAMPDUs.

(87)

Figure 94-Traffic Statistics Clearly Shows Loopback by DUT

8. To disable the loopback, simply go to Learned Info and click to select Disable

Loopback command, then click Send Loopback. The DUT status can be verified

in many ways — the simplest and most reliable one is to check traffic stats. The port used for sending a loopback command no longer receives traffic; and the other port is receiving traffic now since the DUT is a layer 2 switch, in this case, and it is broadcasting frames to all ports.

Disable Loopback

(88)

9. In some cases a Loopback command cannot be sent from Ixia due to local unstable state as indicated by the error message Packet Sent: 0 Error: Discovery not in stable state. To fix this, you can go to the Advanced tab and select

Override Local Stable and then Send Updated Parameters.

Figure 96-Trouble Shoot if Loopback Can’t be Sent

(89)

10. To test the DUT’s ability to issue a loopback request, you can type the

appropriate CLI from the DUT and then go to the Ixia port and check on the

Learned Info > Local Information. It should show the port is in LB state with DISCARD mux action. Should you decide to send traffic to test he loopback,

make sure you set the Ethernet Type to match the traffic you’re sending from the DUT.

Figure 98-Verify DUT’s Ability to Send Loopback Request

(90)

Test Variables

Any of the following variables may be used to verify DUT Link OAM Loopback functions: • Number of test ports — if there is a need to verify OAM Loopback across multiple

DUT ports

• Operation Mode — Active or Passive — Only Active mode supports Loopback request. Passive mode can only respond but can’t initiate.

• Loopback request in conjunction with Remote Failure Indication flags • Loopback in conjunction with Capability flags

• Loopback only on data but not on OAMPDUs and Pause frames • Traffic rate and packet size

Results Analysis

Loopback state can be verified in multiple ways. The DUT usually has a CLI to clear the display interface state. Ixia learned info will show all discovered info including loopback state. Most importantly, loopback can be confirmed using data plane traffic.

Troubleshooting and diagnostics

Problem

Description

Check to make sure either the DUT or Ixia emulator is configured in Active mode. If both are configured in passive mode, none of them will start the discovery process, so no learned info will be displayed.

DUT won’t respond to Ixia loopback reqeust

When Ixia is in Local Unstable state during discovery phase with DUT, it will not be able to send Loopback command. To fix it, you can override the local stable state via the Advanced function. Ixia cannot

loopback traffic to DUT

Most likely the DUT is sending/forwarding traffic with a different Ethernet Type value than default “0xFFFF”.

Conclusions

Ethernet/Link OAM Loopback allows the remote end to loopback the traffic for efficient trouble shooting in a real network. Ixia’s Link OAM emulation provides the ability to verify both the DUT’s response to a loopback request and its ability to initiate a

(91)

loopback request. The loopback state can be verified by multiple means including use of data plane traffic.

DUT Config Excerpt

Interface FastEthernet1/0/1

switchport mode access

ethernet oam remote-loopback supported ethernet oam