Came across an interesting slide show, The Ultimate guide to the flat data center network. at Network World. From page 7:
All of the major switch vendors have come out with approaches that flatten the network down to two tiers, and in some cases one tier. The two-tier network eliminates the aggregation layer and creates a switch fabric based on a new protocol dubbed TRILL for Transparent Interconnection of Lots of Links. Perlman is a member of the IETF working group developing TRILL.
For myself, I have been designing two tier networks for about 6 years now with my favorite protocol ESRP. I won’t go into too much detail this time around, click the link for an in-depth article but here is a diagram I modified from Extreme to show what my deployments have looked like:
Sample ESRP Mesh network
ESRP is very simple to manage, scalable, mature, and with a mesh design like the above, the only place it needs to run is on the core. The edge switches can be any model, any vendor, managed, and even unmanaged switches will work without trouble. Fail over is sub second, not quite the 25-50ms that EAPS provides for voice grade, not that I have had any way to accurately measure it but I would say it’s reasoanble to expect a ~500ms fail over in an all-Extreme network(where the switches communicate via EDP), or ~750-1000ms for switches that are not Extreme.
Why ESRP? Well because as far as I have seen since I started using it, there is no other protocol on the market that can do what it can do (at all, let alone as easily as it can do it).
Looking at TRILL briefly, it is unclear to me if it provides layer 3 fault tolerance or if you still must use a 2nd protocol like VRRP, ESRP or HSRP(ugh!) to do it.
The indication I get is that it is a layer 2 only protocol, if that is the case, seems very short sighted to design a fancy new protocol like that and not integrate at least optional layer 3 support, we’ve been running layer 3 for more than a decade on switches.
In case you didn’t know, or didn’t click the link yet, ESRP by default runs in both Layer 2 and Layer 3, though optionally can be configured to run in only one layer if your prefer.
I used to be a fan of ESRP, until Extreme’s platforms started having frequent master master assertion issues. EAPS was marginally better but too much trouble to maintain and grow. I’m a little surprised Extreme has survived since Juniper released their EX platform. The EX has superior availability and features. Extreme might still be fine in a Corp IT environment but has no business in a production revenue generating environment.
Comment by Tinkthank — September 15, 2010 @ 10:48 pm
If they make their platform simpler to manage I’ll check them out again, as-is way too complicated, doesn’t need to be that complex to run a switch.
http://www.techopsguys.com/2009/09/29/simple-network-management/
I understand simplicity doesn’t matter to some folks, but as someone who works with servers, networking, storage, etc, simplicity allows me to be significantly more productive with less resources. Most of the network engineers I have personally worked with could benefit from simplicity as well, unfortunately in a lot of cases I knew more about networking than they did(which is sad!).
thanks for the post!
Comment by Nate — September 16, 2010 @ 7:44 am
If you’re automating all your switch configs then the only time you’re concerned about extra commands is when you’re sanity checking configs. Too many network engineers are averse to automation. Which is a shame, since human factors are responsible for the majority of network outages. (unless of course you run purple network hardware)
Comment by tinkthank — September 16, 2010 @ 4:33 pm
yeah, I’ve never worked with a network engineer who really knew anything about automation.
Comment by Nate — September 16, 2010 @ 4:39 pm
[…] to make the leap into a distributed system such as TRILL. Given TRILL is a layer 2 only protocol (which I complained about a while ago), I wonder how they handle layer 3 traffic, is it distributed in a similar manor? What is the […]
Pingback by Dell’s distributed core « TechOpsGuys.com — November 15, 2011 @ 9:59 am