This blog represents some thoughts I’ve been mulling over for a while since my last large network assessment.
Looking at it from the Cisco perspective, but also from what I’m seeing with other vendors, automation may require us to rethink modularity in networks. Specifically, the automation tool may provide the most value when it is used exclusively for one of the modules discussed below.
TL;DR. WLAN is now part of campus wired in terms of automation and management tools (at least on the Cisco side, and apparently moving in that direction for others). And data center switching is likely another monolithic module. The network edge is still … a hot multi-vendor mess with no simpler solution?
The biggest implication there is: buying purely WLAN plus controller (“WLC”) may not be something you want to buy separately from your campus switching switches and management platform.
Another implication (reality) is the data center may well be separate switches and fabric as well as provisioning system. Arguably a more demanding environment, bigger MAC tables, “fancier” routing/VXLAN, etc.
And, of course, SD-WAN ate the WAN. Perhaps with some indigestion from gobbling too quickly. Well, less contentiously: SD-WAN replaced the WAN.
The Changing Network Design Architectural Elements
It appears to me that network design is becoming more aggregated and integrated. Each vendor is pushing automation and management. Typically, only for its hardware and via its tools. Yeah, exceptions exist (e.g. Juniper Apstra).
For smaller sites, manual configuration may not be overwhelming, allowing opting out of the vendor tools. On the other hand, some of the very detailed alerting and troubleshooting “assurance” expertise built into the tools could really benefit small sites with a small staff, especially if skills / compensation are a challenge. Automated upgrades ditto. Ops management (inventory, EOS/EOL, security notices by version, etc.) can help as well. Although all that might come at extra cost, presenting a tough choice. Automation tools won’t quit and are likely to do fewer stupid things (modulo bugs)?
For bigger sites, I see automated provisioning (and change tracking) as having enhanced value. If you have 50 sites, you do not want to add a new VRF manually! Full-time employment of the wrong kind. And likely error-prone. Boring, repetitive work tends to have that effect! Don’t get me started on botched QoS deployments, where un-noticed buffer over-runs caused lines of config to go missing. If you’re doing QoS, DNAC or other automation counterpart is the only way to go!
For those who try to avoid vendor lock-in, there are also tools that help you manage and automate single- or multi-vendor networks, for example, NetCraftsmen’s partner Gluware.
There is a whole blog or debate topic lurking there, complexity versus value. My sense is that many sites would like more vendor tools doing automation for them, but staff skills and the learning curve with a new product and some tech complexity is a significant deterrent. Licensing cost perhaps another barrier.
Ok, so what are the aggregates (basic network components) here? Expanding on the above a little, the “chunks” are:
- Campus (Cisco SD-Access, any other campus management tools from other vendors?). This includes wireless.
- Data center (Cisco ACI or DCNM, Juniper Apstra (sort of multi-vendor), what else?)
- Fiber / metro Ethernet / WAN / SD-WAN / VPN (“inter-site networking”) – possibly 2-3 of these as components, depending on site size and distance. E.g., metro Ethernet in the HQ region, SD-WAN for various small to medium-sized field offices.
- Internet Edge
- Cloud(s)
And the point to calling them “aggregates” is that campus and data center may each well be made up of devices from a single vendor. If your WAN and VPN have been updated, they likely are now SD-WAN from a single vendor.
Fiber / metro Ethernet is somewhat of a gray area. Unless there are devices to manage, they may just be fiber-based connections between sites, no real control tie-in. “Expensive cabling”?
Internet edge is a mix of vendors and devices and is likely to stay that way. I think I’ve covered it enough in the prior blogs, and politeness says I should not blog about it for another year.
Cloud can be regarded as more sites, but with virtual network devices/routing that might NOT be under central tool control. (Exceptions: ACI? VMware??) Assuming you do cloud-native rather than virtual devices.
With Cisco SD-Access and I believe Arista’s Mojo Networks WLAN (cloud-controlled) and Junipers MIST, there is central control, but traffic no longer funnels (bottlenecks) through the controller. That is much more scalable to support the newer, faster WiFi standards.
With most vendors, WiFi / WLAN is and has been an overlay upon campus (etc.), transporting traffic back to the central controller. But now, WLAN has become part of the campus network(s), at least for Cisco, Arista, and Juniper. Rather than just an overlay. For at least Cisco and Juniper, the WLAN management is also becoming blended with the campus automation/management tool as well. One tool, preferably. I believe this is also the case with Aruba.
Looked at from a different perspective, “simple” means fewer vendors and tools?
Future WLAN
WLAN is cheaper than cabling. And if your users and devices are (mostly) wireless, you save on switches/switch ports. University campuses have been finding this helps stretch their refresh budget.
The downside is doing a solid post-deployment WLAN survey for holes in coverage is costly. One university I’ve worked with discovered that initially, and basically is using trouble tickets as a chance to go check out an area and fix coverage holes. Two cautions: could lead to majorly annoyed “customers”, and you can’t keep simply putting up APs to plug holes: too much RF can and will bite you. (I’ve heard enough stories where people walked themselves into that particular wall. It cost them money and time and then had to re-survey anyway.)
Conclusions
The material above has attempted to describe the options I’m aware of. If there are some I’ve missed, or if you think about some of this in a really different way, please let me know or blog about it. I’d like to think I’m still learning after all these years!
The reason I thought it useful to cover all this is that a couple of customers are starting to deal with equipment refresh, and the WLAN refresh may be viewed by management or staff as decoupled from the campus switching. It probably WAS independent from the campus switching, an overlay to the WLC, the last time WLAN got refreshed. The difference now is (1) the automation system and (2) the fact that with growing WLAN bandwidth, the WLC controller becomes a potential bottleneck. Hair-pinning traffic (to the WLC then back to the data center or another user) is not wonderful either.
