I've been a network engineer for more years than I'd care to admit, and having worked in IT, as a partner SE, and in TAC, I know how network engineers think. We like predictability, and we figure we know how to build networks that work. A bit like the auto mechanic looking at an electric car, we tend to say, "that's interesting," scratch our heads, and then go back to what we know well.
Since we've been building networks the same way for 20 years, network engineers often go back to their tried and true methods of doing things. Thus, when they look at a technology like Software-Defined Access, which employs LISP, VXLAN, and SGTs, sometimes they want to revert to Spanning Tree and HSRP and forget about fabrics. I've also talked to some engineers who've been through the SD-Access deep dives, who've done the packet walks and looked at the frame formats, and yet who still cannot understand why to bother with fabric at all!
In my session entitled "SD-Access: Why is my Salsa so Tasty", we take a look back at how we build networks, and why we need to change. The old paradigm for access networking is quite well known: layer 2 at the distribution and access layers, layer 3 at the core layer with the default gateways running HSRP, and Spanning Tree to block loops. Over the years, improvements came along to this basic model. STP yielded to RSTP, GLBP improved upon HSRP, and eventually box aggregation technologies like VSS and Stackwise Virtual did away with STP altogether.
Some customers tried a routed access model, hoping for the predictability of routing protocols like OSPF, but were stymied by the inability to stretch VLANs, a necessity particularly for IOT devices. But none of these solutions dealt with the increasing complexity of access control policies. I remember, in one of my IT jobs, sorting through a lengthy ACL only to find a "permit any any" at the top of it. Someone added it for troubleshooting and never removed it! Regardless, almost all security policy is based on IP address, an identifier more of where you are than of who you are.
We can solve security challenges with Cisco Group-Based Policy (GBP), also known as TrustSec. GBP uses a Scalable Group Tag (SGT), to classify users. Users are identified and assigned an SGT using 802.1x, MAC Authentication Bypass, and other techniques. Their security policy now follows them through the network, tagged in the packet header.
GBP works great, and for many customers is an ideal choice. However, it does not solve the network-level challenges discussed earlier. A pure-TrustSec network still faces the same problems with link redundancy and failover, and layer 2 stretching. Also, when SGTs scale the policies can become complex. With SD-Access, we solve the layer 2/3 problems while also adding a new construct called virtual networks. VNs allow for macro-segmentation, which not only provides a high level of security, but also allows for simplification of SGT-based policy.
While SGTs and policy are automated with Identity Services Engine (ISE), in a pure GBP environment there is still a fair amount of manual configuration of end-devices, which must be done box-by-box. Network engineers have been doing CLI device-by-device for years, but I always like to ask them: Is that really the best use of your time? Do you really like doing the same configuration on hundreds of devices?
Some tools like Ansible and NETCONF can help automate configuration, they usually involve templating configuration which can be a lot of work in itself. If you have multiple device types in your network, you also need to handle the varying configuration formats yourself. With Cisco DNA Center, you can manage all of your devices from a single place, and it knows what type of device it is talking to, so you don't have to build multiple templates.
In short, while Cisco offers a lot of great solutions to manage your campus network, SD-Access ties together the best of them.
Using SD-Access to solve real-world challenges
Let's look at a use case that is very relevant today. We've installed SD-Access at a US hospital, where it fit their needs perfectly. Hospitals have high security requirements, and also have devices like EKG machines and CT scanners that frequently use static IP addresses and don't run 802.1x. Despite their often aging software, life-saving medical devices require a high level of security. Hospitals provide a perfect use case for macro-segmentation. Within a medical devices VN, we probably don't want the CT scanner talking to the EKG machine, so a micro-segmentation policy is also essential.
How do we classify these devices when they don't run 802.1x? Using the new Endpoint Analytics feature in Cisco DNAC, we can combine SD-AVC data from our switches with crowdsourced data in the cloud to accurately classify them using AI/ML. Because these devices are often running old software, we also want to know what they are doing. If the CT scanner is talking to the IP cameras, there may be something wrong. We can use Cisco DNAC Group-Based Policy Analytics to see what SGTs are talking to each other and craft our policies accordingly.
Our hospital needed to ramp up quickly during the COVID-19 crisis. In addition to their main hospital, they needed to build an expansion ER and add multiple tents for COVID testing. The expansion ER needed access to some corporate resources, while the tents simply needed Internet access. To accomplish this we built a full fabric for the expansion ER, and used Fabric-in-a-Box for the testing tents. But how could we ensure the new ER and tents could securely access corporate resources and the Internet?
If you've worked with SD-Access, you know that the way in and out of a fabric is through the border. Traditionally, when we set up multiple SD-Access sites, each site had to send traffic out its local border. Now, with SD-Access Remote Border for Multisite, we can terminate traffic for specific VNs on other borders. This fit perfectly with the needs of our hospital. They pointed the expansion ER and the tents to their DMZ borders for guest Internet, and pointed the expansion ER back to the main hospital borders to access corporate VNs. Thus, they were able to easily achieve traffic steering that would be quite difficult with a traditional network.
Moving forward with SD-Access
SD-Access is an advanced technology which solves many of the common problems network engineers have been facing for decades. We've seen how it solved the problems faced by one hospital, and how it enabled them to handle the sudden crisis with agility. There are a lot of Cisco Live sessions on SD-Access. I encourage you to watch, learn, and tell us about your own deployment! Questions? Post them below in the comments.
ASR 9000 Bunble Vlan Config interface Bundle-Ether16description Bundlels for Customersbundle minimum-active links 1! interface TenGigE0/0/0/2description Link to customers - expects Q-in-Q VLANsbundle id 16 mode activecdp!interface Bundle-Ether16...
Hello Cisco Team, I am using Static NAT to make my internal server accessible from Internet.My WAN IP is *.*.*.117 255.255.255.248My Server LAN IP is 10.132.62.25 I am using CISCO 2811 router.WAN IP on int fe0/1 ip nat outside LAN...
Anyone have any insight into identifying the correct snmp oid for a C9500-48Y4C stack running 16.12.3?usual cpu snmp oid of 188.8.131.52.184.108.40.206.220.127.116.11.1.5.1 yields no such instance.Documentation points to an oid of .18.104.22.168.22.214.171.124.126.96.36.199.1.25 for 5mina...