Why are networks so hard to build? | Hacker News Reader

Why are networks so hard to build?

snell-pym.org.uk

5 pointsalaricsp7 comments

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.

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 :-)

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. :-)

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?

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?

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. :-(

Al! You're famous!

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

Reply on news.ycombinator.com