Flattening Ethernet Ethernet needs to become a lean, mean networking machine, and the way to do that, we're told, is to flatten the fabric, avoid layer the processing and keep as much as possible down in Layer 2. Is this real? What does it mean for performance, network management and open Ethernet standards? Three experts tell you how they see it …
Inefficient use of Ethernet is because of poorly written software not because of flaws in the makeup of the OSI model. Anyone who has used Outlook over a WAN knows what I am talking about. 3K of traffic is generated to successfully deliver and confirm delivery of a 1K email. Plus all the other background crap MS crams up my network with.
MS is not the only manufacturer who needs to stop making software that turns my network into a Hen Party.
Or it hasn't been since the days of thick yellow cable. It's an amorphous L2/L3 hybrid and we all know that layer violations only cause pain. Routing and bandwidth management aren't L2 functions and defining something as L2 simply because it happens in a device labelled "switch" rather than "router" simply illustrates a failure to understand that a network is more than just a collection of datalinks.
Which I think is more or less what the "experts" were trying to say before they had their words coerced to fit an editorial premise.
The old three-layer architecture of Access, Distribution, Core is nowadays Access and Distribution only - collapsed core model.
Top-Of-Row = Access
End-Of-Row = Distribution
STP blocking on redundant paths (manually for determinism, I prefer)
Terminate VLANs on EOR Distribution switches e.g Catalyst 6500/ FWSM combo or other
or,
Terminate those VLANs directly on a pair of HSRP/ VRRP capable aggregation routers
The goal:
Terminate L2 and simplify STP as close to source as possible with L3 routing
Also, modern protocols aren't broadcast-based. IPX/SPX, NetBEUI/ NetBIOS are all long-gone. Mapping a /24 to a VLAN is no longer required because the broadcast protocols either don't exist or because servers are much more powerful than they were back in the day. It's all Unicast P2P traffic.
If this article wants to discuss "EAST-WEST" architectures such as you might see with a SAN it should be more about FCoE or newer products/ ethernet fabrics and how that fits into the classical L2 design.
What problem are we trying to solve, here? High-speed switching/ low latency trading applications? What?
Answer that question, provide a solution. Show me.
My understanding of the article is that switch fabrics will replace spanning-tree.
The current model (whether two or three layers) requires inefficient designs to provide redundancy due to spanning-tree blocking any loops in a layer-2 Ethernet network. The switch fabric allows the loops to be removed via smarter switches.
Why is this important?
In a virtualised environment, a server moving from one physical host in rack A to another physical host in rack B would cause either capacity or cost issues with the typical north-south network. Being able to connect east-west in addition to north-south allows for server transitions (whether due to hardware failures, server load or administration) to be handled gracefully.
Here's a basic illustration of a simple scenario:
Traditional tree:
A
/ \
B C
/ \ / \
D E F G
Moving a server from D to G would HAVE to go D->B->A->C->G, using bandwidth on all of those switches. If, e.g, other heavy traffic is happening from E to F at the same time, the B->A->C links could easily become saturated.
Fabric:
("=" means links pass through the line, so, e.g, A is actually directly linked to all of B, C, D, E, F and G)
A=B=C=D=E=F=G
Now that same server move would go D->G, only using those switches, and the E->F traffic can happen independently, and A, B, and C don't have to carry any of that traffic.
As I see it, it's essentially expanding the internal switch fabric concept to the connections between switches as well.
You are - maybe - part of the way there in the example of a financially constrained or poorly designed/ provisioned DC environment.
But I have to disagree with you. Sure virtualisation places extra loads on physical servers and associated L2/3 throughput.
I would like to see an article or some clarification on who is using these new technologies and what it delivers to them.
Banking, maybe, to exploit and execute trading discrepancies. I heard a rumour that Google are using Astaro switches in their DCs because of their low L2 latency.
I deployed NEXUS in one DC so that the server guys could 10G whack off over some new switching fabric that they never needed - the purchasing decision went over my head - and Juniper switching gear is crap anyway.
I am quite progressive and for high speed ethernet switching - would risk buying ASTARO but they will become just as bloated as everyone else when they implement full feature sets in their equipment.
Let's keep it simple. I want to know:
1. Who is it intended for?
2. Why do we want to do it?
If they cannot answer those questions, it is just marketing crap.
Spot on. We have a quarter century of experience that tells that operations involving massive amounts of layer 2 interconnection lead to massive operational problems. There's a *reason* that hierarchical networks with layer 3 routing evolved once you have more than a couple of hundred hosts. The reason is that they work better.
OK, there's an effort known as TRILL to use layer 3 routing techniques at layer 2. But it won't provide the logical subdivision that you need to make the network manageable. This stuff is all doomed. They are trying to solve a problem that was solved by the invention of OSPF twenty years ago.
Please don't bother with more articles on this dead end technology.
This post has been deleted by its author
@Steve Knox, re:
A
/ \
B C
/ \ / \
D E F G
So... traditional STP really won't cope with just putting a link between B and C, and perhaps between D, E, F or G? (Some Googling).Nope! Well, it won't collapse but it won't take advantage of the links either.
So, STP assumes a root switch, and always calculates shortest path to the root switch. So if you put in links between B and C, and between D, E, F, G, those links will be DISABLED, the link D-E for instance will only go live if the D-B link fails (since the shortest path to root switch A would then be D->E->B->A instead of D->B->A).
It seems to me that a "smarter" STP that tolerates a full mesh would be a great idea. It also sounds like this is not on the table at the moment. So this would have manually administered switching. I read some cellular carriers are looking at using Ethernet with both STP and ARP stripped out for their point-to-point links now, it has lower overhead than SONET but they were concerned about security implications of both STP and ARP, preferring to manually specify the ethernet address of each side of the link.
The replacement technology for STP is here already. It's broadly know as Layer 2 Multi Pathing (L2MP). There are two approaches but only one looks serious and that's called Transparent Redundant Interconnection of Lots of Links ( TRILL ) and you can find details on the IETF using your favourite search engine.
Cisco has a proprietary and pre-standards implementations of TRILL that they call FabricPath which is shipping today.
There are a few switches which will do some of this, but a full mesh is what fabrics are all about.
OSPF is fine but it's an IP protocol. I used it 15 years ago to solve ISP issues with static IP users dialling into nodes in multiple cities as a F'instance. There's no MAC-based equivalent (which is what a fabric is about)
The drawbacks of STP rebuilding trees is a biggie - especially when you consider any server which is using bonded ethernets and LACP will cause a STP rebuild every time a port goes up or down (which means STP is no longer something which just rebuilds occasionally)
I would love to lay my hands on switches which can do full fabric MAC and IP routing across multiple buildings/fibre links. It'd solve a number of storm issues which keep cropping up in an academic environment as well as the issues mentioned by Steve Knox and hopefully cope with "any IP address on any switch port" type issues too (we have far too many hosts to run 'em all in one subnet, so L3 routing MUST take place somewhere and cisco kit is kinda broken if there are multiple routers on one LAN)
All the talk of auto configuring, self healing fabric is great but the Internet can not be viewed as friendly territory where every other switch and router is trusted. Just think back to the Chinese traffic grab a few years ago and consider the implications of a few forged hop counts that can cause traffic to be routed from New York to Washington DC via Beijing or Tehran. That trust mistake was made 40 years ago with the initial design and should not be repeated.
Once you acknowledge the trust issue all the automated solutions collapse and the hierarchical arrangement makes sense - rings of trust are more accurately branches of trust and you stay as far from the root as possible. Fabric only works within limited areas of trust and the best way to interconnect these zones will still be hierarchical.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
