Ethernet
Virtualization – Part 2 - The Abstraction of the Computer
Here's the second part of our Virtualization series and a continuation of Virtualization - Part 1 – The Abstraction of the Internet.
A computer consists of several key elements that along with software (and firmware) provide useful applications like the browser you are using to read this blog from our web servers.
Here are some of the items that are noteworthy:
Central Processing Unit (CPU) – aka Pentium for you wintel folks, is the heart of the computer and executes instructions (software or firmware) that are programmed by a software engineer.
Input/Output Devices – Provides a method to enter , display or share information from the computer, for example: Display, keyboard, mouse.
Random Access Memory (RAM) – Is memory that is accessed by the CPU which losses its contents when you remove power. RAM (Typically) is the fastest memory that a CPU and “read” or “write”.
Disk Drive – Is memory that is also accessed by the CPU which doesn’t lose its contents when you remove power. Disks are slower than RAM.
Flash Memory – Is like RAM but has the characteristics of a disk drive.
Data Bus – Depending on the CPU (8 bit, 16 bit, 32 bit or 64 bits wide) is where the CPU can read or write data from or to the various memory devices, Input/Output devices. Each bit is a “1” or “0”.
Address Bus – Also dependent on the CPU , this is where the CPU (using bits) selects the location in memory to read or write data.
Firmware – aka BIOS for wintel folks, is software that is used to “boot” (restart from a known state) the computer that resides in Flash memory or a Programmable Read Only Memory (PROM).
Software – eg Office.
Operating System – eg Windows, is a layer of software that abstracts the hardware and controls the overall operation of the computer.Networks – Are communication systems that allow computers to share information.
Programming Languages – A CPU can only understand binary (“1” or “0” s) for the instructions it executes. There are various instructions to read , write, add, multiply, subtract , divide and move data. However, Humans need to abstract the instructions into words to make it easier. These languages define the way words are used forming a grammer (just like English or Spanish) . The first form of languages are assembler languages which are specific to a CPU and not portable, the subsequent languages like C, C++, FORTRAN, Pascal provided more functionality with Database languages like 3GL, 4GL etc..
A computer can be a main frame, a desktop or your laptop which were confined to a area (room, your desk or your lap).
Advances in networking have provided efficient methods of distributing the CPU from Disks, Input/Output devices.
Storage Area Networks are clusters of disk drives that are no longer directly connected to the computer using the various buss’s described above. This is a key level of abstraction which has allowed distributed computing to evolve into GRID computing where the software is one place, the CPUs in another and memory in yet another. Distributed computing provides more efficient use of computing at unparalleled level of disaster recovery.
Why is this important?
Computing has and will continue to be the mother of invention for advances not only in the hardware or software but also in the networks that connect everything together like the Internet or also an Enterprise VPN.
More later :
Virtualization – Part 3 - The Abstraction of Applications
Concepts of a Application Programmers Interface (API), examples and pitfalls for APIs and the abstraction of Web Services.
The Seven Wonders of Telecommunications
The Seven Wonders of Telecommunications
This is a post that was inspired by the latest poll results on the latest Seven Wonders of the World. In case you missed the list: The final tally produced this list of the world's top human-built wonders: Link here
- · The Great Wall of China
- · Petra in Jordan
- · Brazil's statue of Christ the Redeemer
- · Peru's Machu Picchu
- · Mexico's Chichen Itza pyramid
- · The Colosseum in Rome
- · India's Taj Mahal
I created this list with telecommunications as the focus, and the criteria involved technologies and products that had the broadest and most significant impact to telecommunications.
1) The telephone - I believe this should fall in the “Ya think?!?!” category. Humans have an insatiable urge to communicate, and the phone was the first and most significant step to communications across a significant (beyond yelling) distance. I will say that, at times, yelling can be more effective though. ;)
2) The modem – Here I am referring to the Hayes Communications “Smartmodem” that became the standard for digital communications across an analog network (POTS)
3) TCP/IP – The Internet protocol suite. With the importance of the Internet, this is more/less a no-brainer.
4) SIP – Session Initiation Protocol has won out as the defacto standard for Voice over IP and its associated applications.
5) Ethernet – The reason Ethernet is listed here is simply due to its simplicity. The LAN standard just isn’t difficult to understand and use. With Ethernet creeping into the WAN as well, things are getting bigger, faster and less expensive.
6) WIFI – This article here explains it all. WIFI more important than Starbucks coffee?!?!? That puts is on the list of seven!!
7) Asterisk – I am putting this open-source IP-PBX due to the fact that it single-handedly exposed the craziness in IP-PBX pricing models. It’s better, fast, and a whole heck of a lot cheaper. This would need to get some more maturity before it made the “all-time” list.
Adam “voiploser” Uzelac
Blackhat study reveals Ethernet less secure than IP-VPN
This presentation from the blackhat conference in Europe last year speaks directly to the point about the security issues between IP-VPN and Ethernet that I took issue with in my last blog.
A couple of the key points that I took from this presentation were:
- In the case of both Ethernet VPNs and IP-VPNs, in order to hack into a customers network from outside the network, the attacker must have access to the provider's core routers. (pg. 26)
- If an attacker has penetrated the customer's network through a backdoor or through weak physical security, he has some interesting options with an Ethernet VPN that do not exist on an IP-VPN network, especially in a VPLS environment. (pg. 34 and others)
- A reminder about how much I dislike spanning tree (pg. 38)
Hat Tip to Jim Lippard
Ethernet, the latest religion
If you've been on the technical side of this industry even a short time, you've no doubt run across debates that are so monumental and so emotion-driven that they are labeled religious debates. Perhaps the debates are not really so monumental, but each side of the issue often represents a fundamentally different philosophy. Some favorites of mine?
- Mac vs. Windows
- PC w/ Unix vs. Unix Workstation
- BSD vs. SVR4
- Emacs vs. vi (or any other editor, really)
- EISA vs. VLB
- USB vs. Firewire
- VHS vs. Betamax?
That's why it makes me chuckle a bit to see the same type of argument used in to promote Ethernet as a substitute for IP-VPN in this article about advertising.com switching out their IP-VPN.
The first sentence is fine. It's true, Ethernet (or an MPLS-based IP-VPN solution) eliminates the need for firewalls at each site. You can safely run in a closed network environment with no IPsec tunnels or other hassle. The downside to that, however, is that each site now has to use the main corporate center for all Internet traffic, which puts more strain on the WAN...which is great for the backbone provider. Ultimately it means more business for them.Bavisi said that because VPLS is a L2 service there is no need for the firewalls the London office of Advertising.com previously had to manage at the remote sites. ?Both IPsec [a.k.a. DIY] VPNs and IP VPNs delivered by carriers over MPLS networks are at Layer 3, and thus face security issues,? he said.
The second sentence I quoted is the FUD factor coming into play. There could not possibly a difference in the security risk between an Ethernet VPN running IP and a closed IP-VPN network running IP. The security risks inherent with an IP network, especially one connected to the Internet somewhere, are not necessarily lessened by moving to an Ethernet network, and the process of centralizing Internet Access and firewalls into one or more main hubs is a common design element in layer 2 and layer 3 VPN's alike.
In a way, the recent development effort into Ethernet remind me of one of the Fundamental Truths of Networking, as cited in RFC 1925.
Ethernet as a WAN protocol (and the use of VLAN's for logical seperation, QoS, and site identifiers) reminds me an awful lot of ATM and Frame Relay, and MPLS reminds me an awful lot of ATM too. ATM had QoS and Traffic Engineering and IP didn't, so along came MPLS to give some traffic engineering function and they put CoS into IP. Now that we're trying to use Ethernet in the WAN, we've got to add all that stuff to it as well, so we'll run it over MPLS and make 802.1p to give it QoS. We're re-inventing the wheel!(11) Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.
Those of you involved in the creation of these new Ethernet standards should remember your your RFC's. That way you'd know that the twelfth fundamental rule of networking is
In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.
The session wasn't named 10Gig and the Next-Gen network
The title of the panel was 10GigE and the Next-Gen Network, not 10G and the Next-Gen network. Why is Ethernet so key to the next gen network compared to 10G in general, and perhaps more importantly why has SONET/SDH becomes a 2nd class citizen in the network compared to Ethernet?
I could have only focused on how great our own network is and all the various Ethernet products we have and how they work, but I like to try give my presentations some general educational value or to be thought-provoking in some way. The last time I tried this at an Ethernet conference I was referred to as a fox in the hen-house, so I toned it down a bit and just provided some data for people to mull over.
You'll recall from a previous conversation about how cost scales in a network that as new technology is released you tend to get a 4x improvement in bandwidth for about twice the interface cost as the previous step. The chart below uses current pricing from router vendors for SONET/SDH interfaces. Notice the nice clean trend...cost/meg dropped as speed increases. Then it takes an unexpected twist when you hit 10G, and it flattens. What a shock it was when we had to finish budget planning the year before our vendors had released their pricing on 10G interfaces and we had to project their cost. We had to change some plans based on the price of a 10G interface being twice what we projected.
The next interesting thing that happened was that 10GigE intefaces came out and the pricing was half of what the SONET interface was! We got back to our 4x/double cost trend, but the catch was that it had to be a 10GigE interface. Perhaps there is some cost between the optics for SONET and Ethernet (as a result of volume), but enough to justify a difference of $90,000 in list price? This was only of limited usefulness to us, however, because there was no 10GigE WAN capability then, so it was only useful intra-POP.
Also notice the pricing of similar interfaces on a Switch/router. A switch/router is a platform that was originally introduced as an Ethernet Switch (e.g. a Cisco Catalyst 6500), but by replacing the main processor board with a router board, it becomes a router! Voila! When Switch/routers were first introduced, they lacked a great many features of their larger full-scale router-brethren had, but that's all changing now. Switch/routers not only have almost all of the software functionality of a larger-scale router, but they have POS interfaces as well. The price/meg on a 10GigE on a Foundry/Force10/Cisco OSR7600 is under $1/meg!
To further illustrate the disparity between routers and switch/routers, see the next chart. I've drawn a floating bar in the center of the chart that represents the range of prices for a 2.5Gig SONET circuit. If you can make the switch from a router to a switch router during your upgrade from a 2.5Gig platform to a 10Gig platform, you will actually see your total cost (not just your cost/meg) drop! That's right, your 10GigE interface will run you around $10,000/port vs. your old 2.5Gig SONET interfaces that run $25,000 and up.
I would prefer to have some illustrations of the architecture of a router vs. switch to show you, but the vendor presentations that I have that illustrate the material are all confidential. If you can get a hold of such drawings, you'll see that many of the different components that perform various functions inside the platform are pretty much the same. In short, there's not a lot of difference between a router and a switch/router from a hardware design aspect, any more than there is a difference between a 10GigE and a 10G SONET interface on a router. So why the huge cost disparity?
I will tell you that if these costs don't fall in line with each other soon, the players offering these big-iron boxes for tall prices are going to find themselves with a dead-end platform.
If they do drop their prices to compete, it may be too late for them to fix the trend. SONET may have lost favor, and it did nothing to deserve last place in that race...it is the victim of market dynamics.
Not only will switch/routers become increasingly popular, but 10G waves can be delivered as Ethernet as commonly as SONET on newer DWDM platforms.
And with the growth curve on the MPLS network looking like this next diagram, the typical SONET/SDH 4x jump is not enough. 10x jump, please! We need 100GigE, not 40G.
Here's a shout-out to Randall Pearl in our engineering department for providing all the figures used to make these charts.
Advanced Solutions are an Art (Part 2)
I’d like to expand on my thought process from my last blog on Advanced Solutions are an Art (Part 1).
When I closed the blog , and I quote:
“Advanced solutions are an art, anyone can propose a solution, not everyone can deliver one that meets customer needs while still being economically feasible.”
I wanted to continue the discussion and start a dialogue as to what a service provider actually provides on a day to day basis?
A service provider provides a service, a service is defined by the technologies, the processes, the systems and most of all the people within the service providers environment.
All of these define something I like to call the “Service Layer”.
A service layer in this context addresses 4 key capabilities within a service provider:
- Sales
- Service Delivery
- Maintenance
- Billing
Lets take a moment to peel the onion on each of the capabilities:
- Sales includes the following functions: sales engineering, account management, customer support, pricing, marketing, proposal development that all lead to an order.
- Service Delivery in the process of orchestrating the delivery of individual components that together provide a complex service, the capability is completed when the customer accepts the service and the service provider can start billing.
- Maintenance is by far the most important capability, like I said, anyone can sell a service, anyone can delivery a service, not everyone can support the service when a customer calls at 3am!
- Billing from a providers perspective is the really important, after all providers are meant to provide a return on investment, and just as important to enterprises as provider costs are typically a cost center and accuracy and support are key.
Maintenance is so important, we’ll do a deep dive in Part 3.
Carrier Ethernet Summit
I attended the last day of the Carrier Ethernet Summit in San Diego last week, as part of my panel on Ethernet supporting Enterprise Services.
As I listened to what my peers had to say, such as Telcove and Yipes, I once again found myself puzzling over the statements they made in regards to Ethernet. I wanted very much to talk philosophically about ethernet as a carrier architecture, and whether all these extensions they want to add to it really make sense.
Unfortunately, my talk was already written. My three slides went like this:
Ethernet Myths
- Ethernet is established as a Simple and Easy Protocol in the LAN, so it makes sense to use it in the WAN
- Ethernet is more cost effective than SONET/SDH for the carrier
- VPLS is the latest and greatest way to do Ethernet
- Ethernet is the best way to support converged applications: Voice, video, and data.
- Ethernet means the carrier has a demark at the customer premise
Ethernet Truths
- Ethernet interfaces for routers are cheaper than their SONET/SDH equivalents
- Ethernet in the WAN is an afterthought, as evidenced by the many new standards currently in development (WAN-Phy)
- Ethernet does seem simple, but with all the extensions (802.1q, 802.1p, LAN-Phy, WAN-Phy) it is becoming even more complicated than the existing WAN standards.
- IP, not Ethernet, is the key to supporting the convergence of applications onto a single network
IP-VPN vs. Ethernet
- Access protocol and type (e.g. ethernet, SONET, DS3, E1, HDLC, PPP, SDH, Frame Relay, ATM) can be selected on a port-by-port basis
- non-IP protocols are typically already tunneled in IP for transport over the WAN
- Disaster recovery can occur with greater intelligence in an IP-VPN
- IP-VPNs are capable of providing superior Class of Service functionality
- Access to value-add applications such as VoIP, Video conferencing, VPN Remote Access, Internet Firewall and collaboration tools is much easier to provide in an all-IP environment
As you can see, a fair amount of this material was selected from a previous post I made.
One of the things that caught my eye during the Yipes presentation was a statement made by Keao about how customers demand the aboslute lowest in latency and jitter, and ethernet was best in both areas. He mentioned an application run by a financial services institution that required 250 microseconds of latency. Yes, MICRO seconds, not milliseconds... that's point-two-five milliseconds. Keao said that because ethernet didn't have the queuing requirements that a router had, that it was the only way to provide the level of service required.
I have three things to say in response to that:
- That sounds like a very poorly designed application if it can't deal with at least 10ms of jitter. Even VoIP phones are designed to allow for more jitter than that (although more than 30ms will result in an increase in latency as a result of the increased size of the jitter buffer that is allocated in the end-points). Chances are good that this application will be redesigned over the next few years to perform adequately on an IP network, and the requirement for a super stringent data network will be moot.
- The ability to prioritize ethernet frames a la 802.1p will increase the buffers in ethernet equipment re-creating the delay attributed (by a marketing presentation) to making IP slower
- Looking at our SLA management tool (also available to customer now as well), it shows an average jitter of .31ms. I am looking at the path between Amsterdam and Tokyo and it is only .12ms, well within the tolerances of that crazy application.
Brian van Dussen from In-Stat, after referring to me as the fox in the henhouse, asked me what I made of the massive growth in sales of ethernet products (a bit tongue in cheek, I suspect). There is no denying that Ethernet is ubiquitous in the LAN and growing quickly in the MAN (probably due to the increasing affordability of dark fiber to the enterprise). The growth of IP-based applications as well as the convergence of legacy applications to IP is going to drive usage and expansion of the LAN and MAN infrastructures that support it, which is predominantly ethernet. One question that I have is how Ethernet is growing relative to IP growth...is it growing at a faster rate or equivalent? Can you even compare the growth in Ethernet equipment sales with sales of TDM and metro gear? Can you compare it with IP equipment sales? The complexity of the relationships between all of these types of technology suggests to me that such an observation, even if it can be stastically modeled, is meaningless.
I question is how smart it is to make the entire world one big Ethernet. It just seems to me that people are spending huge amounts of time and money to re-invent the functionality in Ethernet that the Internet Protocol already gives us, and yet ethernet will never replace IP, so what exactly are we trying to accomplish here?
Ethernet in the Enterprise
If you are a regular reader of my blog you may recall one of my earlier stories Ethernet - What's the big deal?.
I'll be speaking at the Carrier Ethernet Summit in San Diego on June 29th on a panel titled "Ethernet Supporting Enterprise Services" which will be touching on these points:
- Enterprise applications and challenges driving demand
- Supporting convergence of voice, data and video
- Metro Ethernet versus inter-metro Ethernet WANs
- Pros and cons of layer 3 VPNs versus Ethernet-based VPNs
- Scalability, global coverage and VPLS
- End-to-end SLAs
I decided to check out who my co-panelists would be and found this Ethernet Whitepaper from Telcove, a network operator on the east coast. I would love to be able to recommend this white paper, but unfortunately it contains many fallacies in addition to attributing some things to Ethernet that it doesn't deserve. It makes a number of very compelling sounding points that I will refute here.
1) Ethernet is the most efficient and flexible transport technology for VoIP, VPN, remote storage, audio and video teleconferencing and multimedia content sharing.
Really! So all I need is an ethernet connection and I'll have access to VoIP, VPNs, remote storage, audio conferencing and more? Let me plug in my Mac II with my ethernet card. Does your VoIP service work over Ethertalk? IP is the efficient and flexible protocol that makes VoIP, VPN's, and the other applications mentioned work so efficiently and flexibly. IP is so flexible, in fact, that it works with Ethernet as well as many other mediums such as SONET, SDH, Dialup/PPP, Satellite, Packet Radio, Token Ring, FDDI, RPR, ATM, Frame Relay, you get the idea.
2) Ethernet benefits the service provider by enabling service upgrades to be done remotely without requiring a truck roll or additional equipment at the central office or customer location.
Maybe, maybe not. If you have a device at the customer premise, say a managed router, and you want to add a feature, you may need to do a truck roll to upgrade software on the router. Chances are, even if it's not a router there is some sort of premise-based aspect to the service and it may require a field upgrade from time to time. The real benefit is that if most of the intelligence is provided in the providers network, as would be the case with MPLS-based IP-VPNs, it is easier for the carrier to release new features because they do not have to develop them for both their IP-VPN offer as well as their Managed Solutions offer.
3) Ethernet growth in the WAN and MAN is driven by distributed workforces and supply chains and supporting technology-based processes such as CRM, ERP, and SFA.
The applications mentioned can absolutely be held responsible for driving demand for data services in the WAN and MAN. Ethernet growth is driven by data growth, and therefore Ethernet is driven by those applications? I think that Ethernet growth in the WAN and MAN must be driven by other factors besides only MAN/WAN purchasing unless that growth is in fact tracking at the same rate of growth.
4) [Ethernet interfaces are cheaper, therefore] Enterprises can take advantage of commodity pricing for router interfaces as well as more elegantly connect to the WAN, that is, without the need for complex protocol translation or interworking functions.
Yes, Ethernet interfaces are cheaper than SONET/SDH interfaces, much cheaper. But routers are routers, and "complex protocol translation and interworking functions" are what routers do. It's just as much work for a router to decapsulate an IP packet from an Ethernet Frame and put it back into an Ethernet Frame as it is to put it in some other kind of frame, whether that's Packet over SONET (POS), PPP, or HDLC. The only thing simpler is if you substitute a switch for the router, but this may not be possible in some designs. You may need that router in order to terminate VLANs, where each VLAN goes off to a different location.
As for elegantly connecting to the WAN, elegance doesn't usually require protocol extensions. A new protocol extension called WAN-Phy gives ethernet some critical things that SONET has like error checking and correction. Such capabilities are necessary to enable the detection of problems in the long-haul circuit, such as timing-slips or dirty connectors and are crucial to troubleshooting performance problems. Not all hardware vendors support WAN-Phy yet, so make sure your carrier can do this for you if your equipment supports it.
5) Because of VoIP, Ethernet has emerged as the technology of choice for converging multiple service-specific networks onto a single, packet-based infrastructure equally capable of supporting traditional data applications as well as business-critical communications such as voice, thus, enabling tremendous operations cost-savings.
Compared to the POTS line or the ISDN line, Ethernet is winning. But VoIP did not and does not require Ethernet for a converged network, it will run over anything that runs IP...probably why they decided to call it Voice over IP instead of Voice over Ethernet. The runner up for Ethernet is probably Token ring, and although I haven't tried it, I'm sure VoIP works on it just fine. Token ring and other competitors like LANtastic got beat by Ethernet primarily due to speed. When Ethernet hit 100Mbps, the writing was on the wall. Once Ethernet won the LAN battle, then it got cheap. When it got fast and it was ubiquitous, it was the natural choice for business use.
6) Traditional WAN Transport services are available only in non-granular tiers, such as 1.5Mbps, 45Mbps, 155Mbps, 622Mbps etc. where as Ethernet is available not only in 10Mbps, 100Mbps, 1000Mbps but is also available in graduations of that such as 10Mbps, 20Mbps, 30Mbps, etc.
This is theoretically true, but you know what they say about theory and practice. In practice, it depends entirely upon the technology being used to deliver Ethernet. Some premise-based Ethernet solutions rely on traditional TDM for transport between the customer premise and the carrier, and as a result the limitations are present for the Ethernet solution as well. The customer port might be set for 100Mbps, but if a DS3 loop is used, the throughput may only go up to 45Mbps (or more likely less than 40Mbps accounting for overhead). The carrier may choose to offer full 100Mbps service using a 155Mbps local loop, or they may offer tiers with the service, eating the cost of the faster local loop hoping to make it back on the service offering or on future service upgrades. Global Crossing offers tiered service on virtually all port sizes, Ethernet or SONET. You can order a 300Mbps service on a 2.5Gbps local loop and increase it over time as your needs grow, so this granular tiering capability is a function of the providers service and billing model, not as a direct result of using Ethernet.
7) Ethernet promises to save the carrier operational expenses since a single network is cheaper to run than multiple service-specific networks (ATM, Frame Relay, TDM, IP).
A single network? Sure. Ethernet? Maybe combined with another technology that is media transport agnostic like IP, sure. We achieved a single converged core at Global Crossing using MPLS, which (unlike Ethernet) has traffic engineering capabilities in addition to working over Ethernet and non-Ethernet media, while carrying ethernet or just IP. Some of our competition is making their single core network an IP network, which also has traffic engineering capabilities although not as advanced as MPLS.
8) VPLS lets carriers offer consistent and more reliable service and SLA guarantees beyond the metropolitan-area boundary. VPLS will be very important for maintaining QoS through a multivendor infrastructure.
Are you guys talking about the same VPLS that I know of, Virtual Private LAN Service? The key thing that VPLS brings to the table that isn't covered via other methods of Ethernet service is the ability for the provider edge router to act as a smart bridge or switch in that it learns MAC Address's. This means that it figures out on it's own where every computer on the network lives and maps it to one it's port for that ethernet VPN. If they don't know which port the MAC address is on, they have to broadcast on all ports in order to find it.
You've got QoS capability if your equipment supports 802.1p (the p is for prioritization, the Ethernet version of IP's ToS bit for identifying traffic classes used for QoS), which you don't automatically get with VPLS. I'm not really sure why Telcove thinks that VPLS is the key to support QoS across multiple vendors when it seems to me that the vendors need to support the IEEE standard 802.1p not the IETF draft standard VPLS.
And lastly, SLA guarantees between the metro-area's are a business aspect backed up by mature long-haul transports like DWDM, SONET, or MPLS, which may or may not have Ethernet associated with them. VPLS, due to its complexity, may even make it harder for a carrier to back up an SLA.
Again, as I said before, if you want your global carrier to act as a big ethernet switch, VPLS is not likely to scale to large numbers of PC's. It was difficult for RFC1483 bridging Ethernet over Frame Relay, which is roughly equivalent to VPLS which is bridging Ethernet over MPLS (or other).
This will be the main point of my talk. Ethernet does have its place in the Carrier's transport portfolio, but it is far from the future of carrier networking.
Ethernet -- What's the big deal?
Don't get me wrong, Bob Metcalfe invented a good thing in Ethernet, but I wonder if people aren't just a little too in love with it. I've been a happy user of Ethernet ever since I first got into networking. I never really had to deal with token ring, although I did work with FDDI a bit in the early nineties. I even had the joy of working with 10base2 (thinnet) and 10base5 (anyone remember vampire tap transceivers?) when I was an assistant network manager at the UofA, which was a royal pain in the neck troubleshoot when it broke, and I'm very happy for everyone that 10baseT is now the standard for everyday ethernet use (100mbit and lower).
But I'm not talking about any of that. What I'm talking about is everyoine asking for their network service as ethernet. It's not a problem in and of itself, but what I have personally found (and would love to be validated in this, so please leave comments) is every customer that asks for it wants it for a different reason, and many of those reasons are false, based on misconstrued data and market propaganda.
When I ask customers why they want ethernet, here are some the answers I've heard (all of which stem from some sort of misconception):
- I want you, my VPN provider, to have a demark at my premise
- It's simpler, because it's layer 2
- I can use cheaper hardware because I don't need routers any more
- VPLS is a superior way to build VPN's
Part of the problem is that there are so many ways to utilize ethernet as part of a network design, but I emphasize that it is part of a network design, not usually the network design itself.
Let's take each of the misconceptions one at a time. Ethernet does not necessarily mean the provider has a demark at your premise. It depends on how it's delivered. Unless a customer specifies that they are looking for a managed service where we put a router at your prem and manage it for you, we'll assume that you want to get a quote for an ethernet local loop from your local provider, and we'll use that to deliver access to your location instead of a traditional T1/E1/DS3/OC-n local loop.
The next one is one of my favorites, because using a protocol designed for LANs and putting it in the WAN is anything but simple. Some of you IT managers probably still have to deal with those nasty things called broadcast storms because you've got too many PC's on your network trying to talk at the same time. The problem is solved by breaking the network up into multiple collision domains by adding routers. Now, imagine that your LAN now has as much as 200ms of latency between nodes, and imagine the effect of a broadcast storm. Disasterous! Don't plan on connecting your switches right to an all ethernet WAN, not only is it a recipe for disaster but with many implementations of ethernet VPNs it doesn't work because each path to each site is mapped into a different Virtual LAN (VLAN), and recombining these VLAN's into one LAN requires a router, even if you're using VPLS.
So, all that said, there are still good reasons to use ethernet. For one thing, the cost of a router interface is cheaper than that of a SONET interface on a per-meg basis, especially if you use one of those hybrid switch/routers like you'll find from vendors such as Foundry and Cisco (their 7600 OSR). Also, some local carriers to have an ethernet product that offers a better price/meg on Ethernet than for traditional pricing. Availability of such access can really help you stretch your IT budget dollar to provide more for your internal customers.
If this proves to be a topic of interest for our readers, I'll be sure and post many followup blogs on this subject.









