

Why are networks so hard to build? - alaricsp
http://www.snell-pym.org.uk/archives/2009/09/09/why-are-networks-so-hard-to-build/

======
theBobMcCormick
The article is full of poorly written handwaving. Every problem _looks_ easy
from a distance. The devil is in the details. Sure it sounds like networking
should be "just plug a bunch of boxes together and let them figure it out".
But that's about as naive as saying we shouldn't have bother with these pesky
programming language things.. We should just be able to describe what we want
the computer to do in english! :-) Yeah, that's likely.

Aside from the run-on sentences and other grammatical problems with the piece,
specific comments in that article also lead me to believe the author doesn't
know much about networking. Take this one for example:

 _"We don't need a cable between every pair of switches carrying the same
subnet, though; a switch will happily forward traffic coming from one trunk
out to another trunk, but we need to be mindful of our uptime requirements; if
an intermediate switch or trunk fails, then the subnet will be shattered into
pieces unless we set up alternative paths through the network (andsuffer the
consequences of Spanning Tree Protocol aka STP, which doesn't yet support
VLANs very well; you pretty much have to trunk every VLAN to every switch if
you're using STP and VLANs together"_

Say what? Every working network engineer in the world will be quite suprised
to know that STP doesn't support VLAN's well. They'll also be quite surprised
at the assertion that VLAN trunking is required _because_ of STP?!?! That
whole sentence is so wrong I'm not sure where to begin.

~~~
alaricsp
Sorry about the bad grammar :-)

Ok, the deal with STP and VLANs is thus: STP works at the level of the actual
Ethernet cables in the system, rather than the VLANs.

Imagine you have four switches, A B C and D. Say vlan 1 exists on A and B;
vlan 2 on C and D, and vlan 3 on all four, and physical cables (carrying
tagged VLANs) run from A-B (vlans 1 and 3), A-C (just vlan 3), B-D (just vlan
3), and C-D (vlans 2 and 3); eg, they're in a square. And you enable STP.

STP will cause the switches ( _ignoring_ VLANs) to choose one of those four
cables to disable, to remove the cycle in the network. It's as likely to
disable the A-B or C-D cables, which will then split vlan 1 or 3 in half.

The solution is to make all VLANs present on all switches and (tagged) on all
inter-switch trunks, so that any cable can be disabled and connectivity
continues; there are extensions to STP that are aware of VLANs (such as the
Cisco proprietary per-VLAN spanning tree); there's the recent (2003?) Multiple
Spanning Tree Protocol (MSTP), but that's not supported by the switches I've
been playing with, so useless to me at least :-)

~~~
theBobMcCormick
I'm actually rather surprised to hear about switches that don't support MSTP.
I've worked with managed switches from some rather low tier manufacturers like
Milan, Allied Telesys, Adtran, etc. that still support MSTP. MSTP actually
isn't that recent. It was incorporated into 802.1q in 2003, but it was
introduced as an amendment to 802.1q in 802.1s way back in 1998. If you've got
gear that doesn't support MSTP (or the Cisco proprietary RSTP), through it
out. Failover and convergence time with original STP is atrociously slow.

At any rate, I still don't see this as a STP/VLAN problem. If you want network
redundancy than clearly your redundant links need to carry _all_ of your
VLAN's. Otherwise you'll have redundancy for some VLAN's but not others.
That's not STP's fault, it's just plain logic.

Not that I think STP is a great protocol mind you. It sucks in MANY ways. Just
not in the ways you seem to be claiming it does. :-)

~~~
alaricsp
Perhaps I've just been unlucky ;-) This was Allied Telesyn kit IIRC.

But this is by the by! Rather than a damning indictment of STP, my real point
was that having to configure all the layers of a network - physical cabling,
VLANs, routing, firewalling - independently involves a load of effort that I'm
not convinced is necessary. It'd be lovely to have routing functions occur in
every switch, automatically routing between VLANs that are present together on
the switch, and then doing MPLS-esque fast switching of frames across the
network to destination switches if not - merging the switching and routing
layers of the stack would just simplify things; why should we need the complex
techniques we have to make networks resilient to failure?

------
bensummers
The idea of describing what you want to achieve rather than the steps to
implement it is appealing.

Could something like Chef or Puppet be used at the network level?

~~~
theBobMcCormick
Something like Chef or Puppet could, in theory, be used at the network level.
The problem with those two applications specifically is that they expect to
run a client on the machines they configure, something that's not possible
with most network gear. But you certainly could build something like Chef or
Puppet that runs centrally and connects out with Telnet or SSH to the each
piece of network gear to configure them.

There are some commercial systems (like CiscoWorks) that are _kind_ of like
this, but all the useful functionality is bogged down in enterprisy
crappyness. :-(

------
Moschops
Al! You're famous!

P.S. My web mail interface still getting worse :)

