The campus LAN is probably the most common network in use today, but its customary trio of layers is coming under examination as the need to reduce costs, add wireless access and increase performance continues to grow. Back to basics: a campus LAN interconnects users in separate and multi-floored buildings in a smallish area, …
Where is TRILL and Why Stacks are Awesome?
While it definitely commonplace to collapse the Core and Distribution layers where feasible and practical, I don't understand how one could have any discussion of a large, flat network without a mention of TRILL. Given the love lost over Spanning-Tree Protocol and the subsequent need for Layer 3 routing to segment STP, TRILL provides the defacto hope of collapsing large, distributed networks into a wide, flat topology that can be as interconnected and filled with loops as needed. Especially now, TRILL should be the first feature requirement for any Ethernet switch hardware selection process. Admins the world over will rejoice when they can execute "no spanning-tree" on all the switches.
Regarding stacking switches, there is a flip-side not mentioned by the author in the switch stack argument. The assumption not plainly stated, but inherent to the logic provided, largely holds that the campus network is managed in-house. Generally, if the stack will be managed by a third-party, that third-party will still charge on a physical chassis basis, not per logical device. So, it pays to understand the ramifications of such "simple" choices on the bottom line (or any of the other myriad areas of impact within IT beyond purely financial). There's also a need to evaluate vendor claims about stacking, as not all implementations may be equal (such as Cisco's StackWise or VSS).
I can't decide whether this is an advert for switch gear or just a bad idea. From all the networks I have ever seen, none of them have been designed with the mentaility of "lets see how many devices we can use for the sake of it." Also, when it talks about removing a layer such as the distribution layer, it fails to consider that it may be far more cost effective to keep it than to do what the article proposes.
Take the university where I studied, each student room comes equipped with an ethernet port. A hall of residence may have 20 blocks, each containing 12 rooms. The way the blocks are laid out means it's not feasible to run the access cabling between blocks, so as a result, each block has a small switch such as a Cisco 2960 with uplinks to a distribution switch in an office (say avg. 70m per link), and then finally a main trunk back to the core switch in the university's server room. The distance between the distribution switch and the core switch is on the order of 500m. If you removed the distribution layer of this network, suddenly the core switch would need to handle 20 times the number of ports than before, and you would need to run over 10km of fibre to achieve the what was previously done with under 2km.
In short, even if you're clever with your cabling, surely the cost of moving away from the three layer model becomes prohibitative once all the extra costs are factored in?
re. "Trouble at t'mill"
It's "Trouble at ' mill". The missing word 'the' is not pronounced in any part and the final 't' in 'at' has a definite vocal stop followed by a brief pause in place of the missing word 'the'.
Someone explain why a rise in wireless access increases the number of ports needed?
Multiple wireless devices connect to an access point that covers an area and only uses a single port. Wireless actually reduces the number of ports.
Somone think of the broadcast domain!
If you collapse these layers you end up with a massive broadcast domain and so you will be smashing your access to core links with ARP packets and the like. A really bad use of those links.
This article is just terrible. Has the guy who wrote it every seen cat 5 cable?
Re: Somone think of the broadcast domain!
The Broadcast domain issue could be mitigated through the use of VLANs I suppose, but even so, it's not an elegant solution and seems more like a stab at punting new gear!
Re: Somone think of the broadcast domain!
Broadcast domains aren't necessarily the problem they were in the distant, even recent, past. Most switches offer a suppression option to limit the transmission of multicast and broadcast frames and no sane network engineer would deploy ethernet without such safeguards anymore (hopefully). In addition, many of the legacy applications that relied on broadcasts are candidates for virtualization, where they can be fully isolated to broadcast as they see fit without compromising the rest of the infrastructure, providing an RTP, ICA or similar access method to the system. Obviously, that's not a one-size-fits-all description of the "ultimate" solution, to say the very least, though the point still remains that steps can be taken to address the "rage" potential of the broadcast domain that weren't viable 10 or even 5 years ago.
In fact, in the case of the stacked switches that appear as one large, Layer-3-aware device, every device shares a single ARP table, so there's no prolific propagation of ARPs as broadcasts as you would expect (instead, there's a hell of a lot of synchronization of the stack across the interswitch links, which can present it's own set of problems). It doesn't begin to consider of the pros or cons for implementing device stacks, but it's definitely a factor that any engineer worth his/her salt should consider in building their project requirements.
Concerning the article overall, I find it high-level enough to prevent it from being really useful to me, though I suppose that illustrates precisely the sort of audience it was intended to reach. Not sure I would call it terrible though. That's seems a bit too harsh, unless you really expected the article to reflect some expert-level white paper from Radia Perlman or Donald Eastlake.
Re: Somone think of the ARP table!
You've eliminated the large broadcast domain by routing, but you've increased the size of the ARP table. You now need a device with larger ARP tables than you used to with 3 tiers, which current cheap silicon doesn't have, since it was built expecting to need only enough ARP entries for a 3 tier application. (And typically ARP tables are replicated across a stack, so they don't scale up).