Introduction

Cisco doesn’t include much useful detail in their exam topics. The full description for this section is: 

1.1 Describe service provider architectures

    1.1.a Core architectures (Metro Ethernet, MPLS, unified MPLS, SR

I am going to focus this post on the Metro Ethernet portion of 1.1.a and follow up on the other topics in later posts. MPLS and Segment routing are pretty big concepts, so this single line implies a significant knowledge base in the test taker. Metro Ethernet by itself s vague because there are plenty of concepts that Cisco could be referring to with these two words.

Metro Ethernet Basic Concepts

Wikipedia has entries for both Metro Ethernet and Carrier Ethernet that are worth perusing. The implied meaning for Metro Ethernet would be “Ethernet services delivered within a metro area.” At the time of its invention that was probably something of a novel concept. At the time Metro Ethernet was invented, all long haul transport was some form of SONET carrier which was really designed to carry voice channels. It could carry data, but not in the same efficient way that Ethernet does. On the other hand, Ethernet was quickly becoming the de facto standard for enterprise LAN deployments (and by Ethernet I mean good old fasioned 10 Mbps with hubs). What if someone came up with a way to carry Ethernet around a city so that branch locations could be connected with an extension of the LAN technology? Thus, Metro Ethernet was created.

What makes the concept tricky is that the Metro Ethernet sometimes is used to refer to the type of service delivered, which could be done with Ethernet over SONET, L2VPN over a routed network, or over a purpose built Ethernet platform. On the other hand, sometimes it refers to the delivery technology itself, such as Metro Ethernet line cards for an Adtran TA5000 chassis or the Cisco ME series switches. I am going to assume we need to consider both, with the focus here being on Cisco of course.

Metro Ethernet Services

Thankfully, from a service standpoint Metro Ethernet is simple. First, some clever but wordy folks called the Metro Ethernet forum came up with long definitions of what Metro Ethernet really is. I’ll split their definitions into two categories, services and objects/terms.

First, the services really break down as follows:

1. Ethernet Private Line
   1. A point-to-point circuit that is port based. What goes in one port comes out the other. You can think of it as a big LAN cable.
   2. These days the services are designed to carry any and all VLANs with large MTUs (jumbo frames).
   3. These sort of circuits can forgo MAC learning within the ISP transport because there is only one exit point for any frame.
2. Ethernet Private LAN
   1. Same general idea as a private line, but as a multipoint service
   2. MAC learning is required for this service because of the multiple egress points that a frame might have
3. Ethernet Virtual Private Line
   1. Imagine that instead of an entire port, your service is defined as one or more VLANs that enter a port. The service provider will provide you with a VLAN ID to tag your traffic with so that it can be differentiated from other traffic
4. Ethernet Virtual Private LAN
   1. Same as (3) above but as a multipoint service.
5. E-Tree
   1. The E-Tree is more theoretical than real in most cases. It’s a rooted tree version of an E-LAN service. What this means is that traffic can only flow from spokes to hub and back, but not between spokes on the tree.
   2. What you will usually see deployed instead are multiple EVPLs witch each hub site having a dedicated VLAN back to the hub site. 

Metro Ethernet Terminology

I’ll pick out some of the more common terminology and standards you’ll see when talking about Metro Ethernet.

802.1Q – The standard that defines VLANs and such. Most Metro Ethernet services concern themselves with transporting 802.1Q frames for customers.

802.1AD – Standard for VLAN stacking and provider bridging. You’ll see it referenced more than used. Stacked headers and Ethertypes get messy quickly and different vendors decided to handle this in a different way.

MEF – Metro Ethernet Forum. The self appointed standard body in charge of Metro Ethernet service definitions.

UNI – User Network Interface. Where the customer plugs in

NNI – Network to Network Interface. Connecting Metro Ethernet networks together

ENNI – External NNI. How do we pass frames to other providers?

Really you should go read https://wiki.mef.net/display/CESG to get overloaded with terms. I’m not sure how much of this matters for the test though.

Metro Ethernet Service Delivery

I suspect that the meat of the bullet point in the exam topics is to know that you can use Metro Ethernet technology as a service delivery platform within the Metro area. Cisco had the ME series switches to support this concept but has really moved to MPLS to cover this now. Plenty of other vendors fill the space as well such as Accedian, Extreme, Calix, Ciena, etc. 

There are real limitations with using Ethernet as the service delivery platform that Cisco probably wants us to know.  I can think of the following:

1. Ethernet has poor support for ring and mesh topologies. Spanning tree is not suitable for service provider networks because convergence becomes terrible as nodes increase, and a service provider network can quickly grow to hundreds of nodes. This is resolved with G.8032 ERPS standards and careful network design, but things still suck to scale beyond 32 nodes.
2. Ethernet also has scaling issues due to VLAN limitations. You can support 4096 customers on a Metro Network without getting too clever.
3. Ethernet has poor orchestration concepts and is trusting by default. It’s plug and go, so unlike a routed network design where you have to make sure and design IP addressing before they work anyone can plug a node into the Metro Ethernet network and wreak havoc.
4. Think of the MAC address count too! Even the biggest MAC tables only support about 128K addresses. If you are doing MAC learning for multiple large customers your MAC tables might fill up.

For these reasons Cisco pushed heavily to MPLS based Ethernet service delivery (L2VPN) rather than delivering services over an Ethernet platform. 

Conclusion

It’s hard to say exactly what Cisco wants us know about this for the exam. I think some of the terms and the limitations of Ethernet as a service delivery are most likely. Cisco doesn’t heavily rely on Ethernet delivery in the Metro today, so I think this is more for comparison sake to the Cisco MPLS way.

Let me know if you want to add anything to this topic for studying. Otherwise I’ll see in the next post Study With Me | CCNP SP | SPCOR 350-501 | 1.1.a | Core Architectures | MPLS