Cumulo Ethernet: Building Ethernet cloud fabrics

Scaling up Ethernet for the cloud means longer wires and many more of them, plus many more switches. What are the effects of linking all this gear together? Do new risks emerge? Can we get economies of scale? What about security with multiple users of network links? Is ordinary Ethernet good enough? Three experts put forward …

[phuzz]

TCP/IP not designed for WAN?

From Tony Lock's article:

"Most of the protocols that are commonly used in networking, most notably TCP/IP, were...not designed for use in WANs"

I'm pretty sure TCP/IP was designed from the beginning for WAN use. The hint is the letter I in the acronym.

[Etherealmind]

Technically, he is referring to the use of VJ algorithm for fast start TCP connections which reduced the effectiveness of TCP in low bandwidth networks.

However, TCP is well suited for lossy networks, which is true for WANs.

So I guess you are both right.

[netdad]

"Wasted" link capacity with STP?

Disclaimer: My business isn't well suited to things like OTV or other L2 over L3 type technologies. The gear that supports it is too latency intensive.

I constantly disagree when people say "half of the links in a STP network are unused." This is only true if you choose to leave them that way. Per vlan RSTP and MSTP allows you to load balance your forwarding paths in the data center on a vlan or vlan group basis. The same follows for Ethernet over the WAN. And.. The same problem occurs in failure scenarios with any non-STP technology you choose - you will are left with some subset of cross sectional bandwidth when core or distribution nodes fail.

The benefit of non-STP architectures is that it does the load balancing for you, similar to how you can get a good load balance over a port channel based a familiar has such as srcip-dstip-port. Some environments are simpler to load balance with STP than others, and changing traffic patterns can make your scheme invalid over time. So there is more management overhead when using STP to load balance.

A carefully designed STP network can be very effective and very reliable. Too many junior engineers and so called senior engineers have given it a black eye, over time. That ridiculous hospital network mishap comes to mind as an example. For me, I haven't seen anything that is really better. Any of the multipathing LAN technologies bring with them new/different problems. I think they need more time to mature. If STP is not usable for you, I would recommend you first look at L3 racks before jumping head first into MLAG, VPC, etc...

One should strive to avoid building huge layer-2 networks in the first place. QFabric seems like the best of the local data center multipathing technologies out there. MLAG and VPC don't even come close (though it's pretty early to declare that, I know.)

Just my handful of pocket change :)