Campus Fabric: preparing for the IoT surge

5 April 2017

Regular readers will know we've written a lot about the software-defined network (SDN), from explaining the concept in a two-page customer briefing, to building up a bricks and mortar analogy for what it actually means in real life. Inspired by Cisco's recent launch of Campus Fabric, I wanted to take a look at what comes next - and why we need it.

As a quick recap, SDN is all about the move away from traditional, hardware-defined IT delivery to agile, software-defined resources, called up through code. Fellow solutions architect Daren Vallyon recently wrote about upgrades to Cisco's DNA Fabric, and particularly the way network functions have now been pulled in and virtualised through NFV, allowing them to be run independently of the underlying hardware.

Bit by bit, these kind of changes represent fundamental shifts in the way networks are provisioned, designed and used, but underneath it all there's still the need for LAN and WAN architecture with increasingly powerful capabilities. With Campus Fabric, Cisco takes the intelligence of this hardware on a step, bringing in industry-leading technologies like TrustSec, and building in more functionality that's more easily configured and deployed.

New threads

There's a lot to Campus Fabric (I'm going to abbreviate it to CF), but I wanted to give some concrete examples of how it moves things on, particularly in the area of security and in the ease with which secure access can be configured and controlled.

First, let's look at how you might segregate a network. Obviously we've been able to achieve that for some time though manual mechanisms like using different IP subnets or creating VLANs. With CF we can create multiple segregated virtual networks (VN) that span the same underlying hardware. Using TrustSec we create role-based security group tags to identify people right on the edge of the network, allocate them to the correct VN, and enforce a security policy throughout the network's entirety.

A key thing to note here is that it's access by the person, not the device, that's being authenticated and secured. Virtual networks provide us with a really hardcore level of segregation between one user group and another - acting almost like a firebreak, and allowing some incredibly powerful security. That's useful for conventional scenarios such as controlling access by different user groups, but also for more extreme examples. Take two completely different organisations that share a campus and require total security from each other: they can use all the same hardware, but be safely penned into two separate VNs.

Best practice

The next thing I wanted to highlight is how in CF, Cisco has finally found a solution to a problem many of us will be familiar with - stretched VLANs. Say you've got a head office in Brighton and a branch in London, and in both you're running a legacy app that only works if all its instances are on the same subnet. There's never been an entirely satisfactory answer to enabling that before: currently the only real way is to stretch a VLAN across two or more sites, but doing so opens you up to major problems like spanning tree loops, and big network outages.

Obviously we might hope that app developers would write better code, but until then CF lets us build an underlying network on completely sound design principles, and enable a single-stranded VLAN to be tunnelled over the top of it. This overlay (see diagram) might still fail - it's terrible network design, after all - but it will fail on its own, and won't impact on the underlying network and all the other business systems that depend on it.

Stretching VLANS.png

Finally, consider a scenario where a server has been decommissioned by your server team, but they forgot to update the people who manage your firewalls, routers and switches. What if another device comes along and occupies the server's vacated IP address? If old network rules persist, that device is going to be exposed to traffic that could compromise it, or be allowed privileged access to your resources - or, in the nightmare scenario, both.

Even if the address remains unused, at some point an auditor is going to discover those old rules and wonder why they haven't been removed - that's really not great from a compliance point of view. With TrustSec, network policies are enforced based on identity, and any privileged levels of access disappear as soon as the server is switched off. That kind of automated de-risking is a step on from what we've achieved for clients in the past with identity-based network services.

Laying the foundations

There you've got just three examples of how Campus Fabric represents another step up in the intelligence of networks. As we've written before, the ongoing simplification and automation of network provisioning helps enable more powerful features, reduces the IT team's workload, and allows a more dynamic and modern network.

As I mentioned, it's also an essential step forward: the Internet of Things is coming, and with it a surge in the number, type and potential security weaknesses of devices that are going to want network access. Essential to managing this will be the ability to segregate IoT traffic, effectively controlling the access, ingress and egress of data generated by this influx in devices.

Intelligent, software-defined networks are going to be key to both reaping the benefits of the explosion in connected devices, and placing powerful, easily configured limits on the damage they can do to your critical business systems. With Campus Fabric, Cisco is already putting the necesary tools in our hands.

 

Want to talk about future-proofing your network? Call us on 01273 957500, or get in touch online.

Header image: Volker Kannacher/Flickr, Creative Commons.