Transforming Campus

Networks to Intent-Based
Networking
Pieter-Jan Nefkens

Cisco Press
221 River Street

Hoboken, NJ 07030 USA

ii Transforming Campus Networks to Intent-Based Networking

Transforming Campus Networks to Intent-Based

Networking
Pieter-Jan Nefkens

Copyright© 2020 Cisco Systems, Inc.

Published by:

Cisco Press
221 River Street
Hoboken, NJ 07030 USA

All rights reserved. This publication is protected by copyright, and permission must be obtained from the
publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form
or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding
permissions, request forms, and the appropriate contacts within the Pearson Education Global Rights &
Permissions Department, please visit www.pearson.com/permissions.
ScoutAutomatedPrintCode
Library of Congress Control Number: 2019914065

ISBN-13: 978-0-13-546633-9

ISBN-10: 0-13-546633-4
iv Transforming Campus Networks to Intent-Based Networking

Credits
Figure 2-3a Shutterstock

Figure 2-3b Shutterstock

Figure 3-1 Courtesy of The Open Group

Figure 6-11 Screenshot of NetBrain Technologies © NetBrain Technologies, Inc

Figure 9-2 Courtesy of Everett M. “Ev” Rogers

Figure 10-2 Screenshot of iPhone app © 2019 Apple Inc.

 v

Contents at a Glance
Introduction xx

Part I Overview of Intent-Based Networking 1

Chapter 1 Classic Campus Network Deployments 3

Chapter 2 Why Change Current Networks? A Need for Change 23

Chapter 3 Enterprise Architecture 37

Chapter 4 Cisco Digital Network Architecture 51

Chapter 5 Intent-Based Networking 77

Chapter 6 Tools for Intent 95

Part II Transforming to an Intent-Based Network 123

Chapter 7 Phase One: Identifying Challenges 129

Chapter 8 Phase Two: Prepare for Intent 147

Chapter 9 Phase Three: Design, Deploy, and Extend 179

Chapter 10 Phase Four: Enable Intent 213

Part III Organizational Aspects 227

Chapter 11 Architecture Frameworks 229

Chapter 12 Enabling the Digital Business 237

Chapter 13 IT Operations 251

Chapter 14 Tips to Make Your IBN Journey a Success 271

Appendix A Campus Network Technologies 283

Appendix B (online only) Sample Configurations 1

Index 321
vi Transforming Campus Networks to Intent-Based Networking

Contents
Introduction xx

Part I Overview of Intent-Based Networking 1

Chapter 1 Classic Campus Network Deployments 3

Campus Design Fundamentals 4
Three-Tier Design 6
Two-Tier/Collapsed-Core Design 8
Single-Switch Design 9
Wireless Networks 10
Central Controller with Central Breakout 12
Local Controller with Local Breakout 13
Central Controller with FlexConnect 13
Mobility Express 14
Anchor Controller 15
Design Choices 15
Handling Redundancy 16
Cloud-Managed 19
Summary 20

Chapter 2 Why Change Current Networks? A Need for Change 23

Wireless/Mobility Trends 23
Connected Devices (IoT/Non-User Operated Devices) 26
Complexity 28
Manageability 29
Cloud (Edge) 30
(Net)DevOps 32
Digitalization 35
Summary 36

Chapter 3 Enterprise Architecture 37

What Is an Architecture Framework? 37
The TOGAF® Standard 39
Aspects of the TOGAF® 40
Framework, Tool, and Methodology 40
Pragmatic Approach 40
Iterative 40
Four Types of Architectures 41
 Contents vii

Business Architecture 41
Data Architecture 42
Application Architecture 42
Technology Architecture 42
ADM 43
Preliminary Phase 44
Phase A. Architecture Vision 44
Phase B. Business Architecture 44
Phase C. Information Systems Architecture 44
Phase D. Technology Architecture 44
Phase E. Opportunities and Solutions 44
Phase F. Migration Planning 45
Phase G. Implementation Governance 45
Phase H. Architecture Change Management 45
Requirements Management 45
Guidelines and Principles 46
Building Blocks 46
Repository 47
Enterprise Architectures 48
Summary 49

Chapter 4 Cisco Digital Network Architecture 51

Requirements 51
Faster Innovation 52
Flexibility 52
Context 53
Intelligent Feedback Mechanism 53
Integration and Faster Deployment 53
Reducing Complexity and Cost 54
Simplicity 54
Increased Efficiency 54
Compliancy and Technology 55
Security 55
External Compliancy Rules and Regulations 55
High Availability 56
Cloud-Enablement 56
viii Transforming Campus Networks to Intent-Based Networking

Cisco DNA Design Concept 56

Cloud Service Management 57
Automation 58
Identity 58
Analytics 59
Infrastructure 59
Security 59
Design Principles 60
Virtualize Network Functions (VNF) 60
Design for Automation 62
Pervasive Analytics 65
Policy Driven and Software Defined 66
Common Design Principles 68
Cisco DNA-Ready Infrastructure 68
Open Standards 69
Use of API 70
Security Everywhere 71
Overview of Cisco Solutions 73
Summary 74

Chapter 5 Intent-Based Networking 77

What Is Intent? 78
Intent-Based Networking Perspective 80
Intent-Based Networking Designs 83
SDA 84
How SDA Works 86
Classic VLAN 88
Summary 91
Two Designs 93

Chapter 6 Tools for Intent 95

What Is Network Automation? 95
Network Automation Tools 97
Cisco DNA Center 97
Prime Infrastructure and APIC-EM 100
Network Services Orchestrator 101
Puppet Enterprise 103
Ansible 105
Control Engine 106
 Contents ix

Control Tower 107

Build Your Own Tool 109
Section Summary 111
Network Analytics 111
Validation of Intent 111
Network Function Analytics 111
Network Services Availability 112
Trend Analysis 112
Application Behavior Analytics 112
Network Analytics Tools 113
DNA Center Assurance 113
Prime Infrastructure 115
NetBrain 117
Ansible 118
Summary 119
Network Automation 119
Network Analytics 120

Part II Transforming to an Intent-Based Network 123

Chapter 7 Phase One: Identifying Challenges 129

Challenges in Day-to-Day Operations 129
Inventory 132
Level of Standardization 134
Existing and Up-to-Date Wired Campus Design 134
Wireless Design 134
Shared Switch Configuration 135
Access Port Configuration 135
Uplink Standardization 135
VLAN Configuration Consistent and Identical Across Locations 136
Standardized Configuration Across Locations 137
Maturity Level of an Organization 138
Level 1: Ad Hoc 138
Level 2: Repetitive But Intuitive 138
Level 3: Defined 139
Level 4: Managed and Measurable 139
Level 5: Optimized 139
COBIT Framework Summary 139
x Transforming Campus Networks to Intent-Based Networking

Stakeholders 141
Prioritize 142
Action Plan 143
Management Summary 143
Analysis 144
Action List 144
Decision List 144
Estimated Timeline 144
Summary 145

Chapter 8 Phase Two: Prepare for Intent 147

Matching Requirements 148
Organizational Requirements 148
Maturity Level of an Organization 148
Resource Availability 150
Network Infrastructure Requirements 151
Standardization of Campus Configuration 155
Migrating from Port Centric to Policy Centric 155
VLAN Numbering 159
Standardization of Configuration 160
Access Switch 160
Distribution Switch 161
Wireless Network 161
Introducing Assurance/Visibility 162
Introducing Automation 166
Day-n Operations 167
Day-0 Operations 169
Day-2 Operations 173
Day-1 Operations 174
Summary of Automation 174
Risks of This Phase 174
Summary 176

Chapter 9 Phase Three: Design, Deploy, and Extend 179

Lab Environment 179
Which Technology? 181
Software Defined Access 181
Classic VLAN 184
 Contents xi

Deploy a Baseline 187

SDA 188
LAN Automation 189
Manual Configuration 190
Section Summary 192
Classic VLAN 193
Extracting a Baseline 194
Migration Strategies 198
Convert to Intents 200
Extend Intent Based 202
Location 202
Intents 204
Section Summary 204
Increase Security 204
802.1x Security 205
Requirements 205
Phase One: Introducing and Configuring IEEE 802.1x 206
Phase Two: Monitor and Improve 207
Phase Three: Optimize Policies 207
Scalable Group Tags 208
Risks 209
Transition to SDA 209
Scalability 210
Training 210
Summary 211

Chapter 10 Phase Four: Enable Intent 213

Why Enable Intent Further? 213
APIs for Intent 215
Step 1: Identify Network Intents 217
Step 2: Generalize Network Intents 217
Step 3: Define Concept API Definitions 218
Step 4: Match API Calls Against Tool 219
Step 5: Create Network Intents Service Catalog 219
Bringing IBN to the Enterprise 220
Communication Plan 221
Understand the Business 222
xii Transforming Campus Networks to Intent-Based Networking

Set Up Pilots or Proof of Concepts 222

Build Apps/Portals to Support the Business 223
Share Successes and Failures 223
Intent-Based Examples 223
Response to Security Incidents 223
Organizing a Meeting 224
Authorized Access 225
Summary 226

Part III Organizational Aspects 227

Chapter 11 Architecture Frameworks 229

Enterprise Architecture 229
Impact of IBN 232
Analytics 232
Cloud Service Management and Automation 232
Infrastructure 232
Summary 235

Chapter 12 Enabling the Digital Business 237

What Is Digitalization? 237
Stages in Digitalization 239
Stage 1: Business and IT Alignment 239
Stage 2: IT as a Business Enabler 240
Stage 3: IT Proactively Supporting the Business 240
Stage 4: IT Changes Business Processes 241
Summary of Digitalization Stages 241
Design Thinking 242
Cisco Design Thinking Framework 243
Intent-Based Networking 245
Organizational Impact 246
Architecture 246
Network Design 247
Network Operations 248
Summary 249

Chapter 13 IT Operations 251

Common Frameworks Within IT Operations 252
ITIL 252
Stage 1: Service Strategy 254
 Contents xiii

Stage 2: Service Design 254

Stage 3: Service Transition 255
Stage 4: Service Operation 255
Stage 5: Continual Service Improvement (CSI) 255
DevOps 257
Lean 258
Five Key Principles 259
Lean for IT 261
Summary of Common Frameworks Within IT Operations 263
Potential Conflicts and Recommendations 264
Common Design Patterns Change 264
Management by Exception 265
Work Cross-Domain 266
Organizational Change 266
Summary 267
Common Design Pattern Change 268
Management by Exception 268
Cross Domain 269
Organizational Change 270

Chapter 14 Tips to Make Your IBN Journey a Success 271

Human Change 271
Fear 274
Quid Pro Quo and Incentives 274
Challenge 276
Failure 277
Forward Thinking 277
Ownership 278
Training and Demonstration 279
Stakeholders and Governance 279
Lifecycle Management 280
Summary 280

Appendix A Campus Network Technologies 283

Index 321
xiv Transforming Campus Networks to Intent-Based Networking

About the Author

Pieter-Jan Nefkens is a long-term Dutch-based IT and network consultant. From early
on in his career he has been connecting devices and people, even before the Internet
era. Pieter-Jan started his career immediately as an entrepreneur in IT with expertise in
networking, security, virtualization, and active software development. Throughout his
20+ years of experience as a consultant, he has always been on top of new trends and
technologies and applied them through implementation projects and consultancy to
solve specific business problems of his customers, varying from small companies to large
international operating enterprises. Pieter-Jan firmly believes that you can only consult
and apply technologies if you have used them yourself. Pieter-Jan has always had a
strong and close relationship with Cisco since the start of his career, resulting in his
participation in beta tests and early field trials, often being one of the first to deploy a
new network technology.

Sharing and applying new technology is in the DNA of Pieter-Jan, which resulted in his
becoming a Cisco Champion since 2017. Besides networking consultancy, Pieter-Jan also
participated in standardization processes for inland shipping across Europe.

Over the past years, Pieter-Jan has been working for both the Dutch government as well
as his own consultancy company.
 xv

About the Technical Reviewers

Denise Donohue has worked with information systems since the mid-1990s, and
network architecture since 2004. During that time she has worked with a wide range of
networks, private and public, of all sizes, across most industries. Her focus is on aligning
business and technology. Denise has authored several Cisco Press books and frequently
shares her knowledge in webinars and seminars, and at conferences. She holds CCIE
#9566 in Routing and Switching.

Shawn Wargo is a Principal Engineer of Technical Marketing (PTME) for the Cisco
Systems Enterprise Product Marketing team. Shawn has been with Cisco since 1999,
and worked in both TAC and Engineering, before becoming a TME in 2010. Shawn
primarily focuses on Catalyst multi-layer switching products, with special emphasis
on next-generation hardware (for example, Catalyst 9000) and software products (for
example, Cisco SD-Access).
xvi Transforming Campus Networks to Intent-Based Networking

Dedications
I would like to dedicate this book to my late father, Piet, whose guidance and counsel
I still miss, and my lovely and wonderful partner, Renate, who has been a great support
for me throughout the complete process from idea to actual writing of this book.
 xvii

Acknowledgments
I would like to thank and acknowledge several people who have helped me directly or
indirectly with the necessary skills that enabled me to write this book.

First of all, I would like to thank my partner, Renate, and our two beautiful daughters
for believing in me, accepting me for who I am, and supporting me when things got a bit
more challenging.

I would also like to thank my parents for allowing me to follow my dreams and to provide
me with the opportunities to learn skills and gain knowledge. I would specifically like to
thank my late father, Piet Nefkens; Jos van Splunder; and Lex de Lijster for teaching and
coaching me that consultancy in IT is only successful if you first understand the business
and then apply technology to solve a specific problem.

A big thank you goes out to Patrick Nefkens for reviewing my rough writing material and
providing honest and candid feedback. It helped me stay on track.

I would also like to thank Dick van den Heuvel for providing me the opportunity to start
working with DNA Center and help the team along with automation.

A thank you also goes out to Brett Bartow, Chris Cleveland, and everybody else at Cisco
Press for believing in this new concept of merging process and organizational aspects
with technologies in a single Cisco Press book.

I would also like to thank Brett Shore, Lauren Friedman, and Andrea Fisher Bardeau for
running the Cisco Champions program and allowing me into this program, and—via the
program and meeting Brett Bartow—making this book possible.

And, well, a very big and warm thank you goes out to all Cisco Champions. I am honored
to be part of that warm community of experts on networking for some years now. All
feedback, opinions, good recipes, and meetups have always been great and fun.

Also, a special acknowledgment goes out to the Piano Guys. Their music allowed me to
get into the necessary flow and focus for writing this book.

Finally, I would like to thank my technical reviewers Shawn Wargo and Denise Donohue
for their patience, commitment, and support in the adventure of writing my first book.
 xix

Command Syntax Conventions

The conventions used to present command syntax in this book are the same conventions
used in the IOS Command Reference. The Command Reference describes these conven-
tions as follows:

■ Boldface indicates commands and keywords that are entered literally as shown. In
actual configuration examples and output (not general command syntax), boldface
indicates commands that are manually input by the user (such as a show command).

■ Italic indicates arguments for which you supply actual values.

■ Vertical bars (|) separate alternative, mutually exclusive elements.

■ Square brackets ([ ]) indicate an optional element.

■ Braces ({ }) indicate a required choice.

■ Braces within brackets ([{ }]) indicate a required choice within an optional element.
xx Transforming Campus Networks to Intent-Based Networking

Introduction
Intent-Based Networking (IBN) is the next revolution in networking that Cisco, Juniper,
Gartner, and others are conveying. Cisco explains the concept with the Network
Intuitive communication and solutions such as Cisco DNA Center, Software Defined
Access, and Cisco SD-WAN. But IBN is much more than just a combination of those
technologies and solutions. It is also a concept on how a modern network infrastruc-
ture should be designed, managed, and operated, leveraging Cisco Digital Network
Architecture as the foundation.

And although the concept of IBN is accepted by the industry as the next generation of
network infrastructures, many IT specialists and organizations face the challenge of how
to design and transform network infrastructures and network operation teams into IBN,
specifically for existing environments. This challenge is mostly seen with questions like
“Yes, I do understand about IBN but how do I get started?”; “Now that I installed Cisco
DNA Center, what can I do with it?”; or “How can IBN help me in providing services
faster to my internal users?”

This book is written as a compendium to that challenge and its related questions, specifi-
cally focusing on campus enterprise networks. This book provides a detailed explanation
of IBN, specifically related to campus networks. With that background information,
this book documents a unique four-phase approach to answer the question of how an
organization can get started on the transformation (or journey as some call it) to IBN for
existing campus networks.
As IBN requires changes in both technologies (and how they are applied) and organi-
zations (how networks are managed), this book also provides tips on how change can
be realized throughout an organization. This book should be of help and support for
anybody who wants to transform their network into an Intent-Based Network.

A large part of my career as an engineer and consultant has been focused on enabling
change and making change happen. The change always involved technology in one way or
the other, primarily with use cases where technology would solve today’s or tomorrow’s
problems, or sometimes the technology would open up new innovative ideas and
concepts. As an external specialist, my role was always to help and support the
organization with the change of work.

Intent-Based Networking will bring very interesting times of change to the networking
industry in general. The network, specifically the campus, will play an important role in
the future of any organization. The rate of change is increasing too, which I see in my
day-to-day work as well. The ability to deploy intents in this manner is for me only the
first step. What would be the next step when you can do this? The opportunities are
really unlimited.

I have used my personal experiences and observations throughout this book together
with the concepts of Cisco DNA and IBN to support you on your journey to the next
generation of networks.
 Introduction xxi

I do hope that reading this book provides you with enough information and background
on why and how to transform an existing campus and network operations team to the
concept of Intent-Based Networking.
This book also has two appendixes that are used to provide you with conceptual
background information on the technologies named throughout this book as well as
reference configurations for the underlay of an Intent-Based Network.

Who Should Read This Book?

This book is written for network consultants, network architects (designers), senior
network engineers, and IT managers who have any questions related to IBN and how
existing campus networks can be transformed to IBN. A background in networking is
helpful when reading this book, but a deep technical understanding is not required as
each technology is explained at a conceptual level in an appendix.

How This Book Is Organized

This book covers a diverse set of topics related to the successful transformation of an
existing network to IBN and is divided into three logical parts that are best read
sequentially:

Part I, “Overview of Intent-Based Networking,” provides you with background infor-

mation related to campus networks and the concept of Intent-Based Networking (IBN).
This part contains a logical buildup of information, starting from common classic campus
network deployments, why change is required through architecture frameworks, to the
concept of IBN. If you are already familiar with the specific topic of a chapter, it is
possible to skip that chapter. Part I includes the following chapters:

■ Chapter 1, “Classic Campus Network Deployments”: This chapter provides you

with an overview of campus network deployments found in many organizations
today at a conceptual level. The chapter does not provide many details on how
technologies are configured and used within a campus network but focuses on
the conceptual designs and choices for a campus network with the advantages and
disadvantages of each choice. The chapter covers concepts such as a hierarchical
campus network, a collapsed-core model, different wireless deployment models, and
alternatives for typical networking technologies found in the campus network such
as the Spanning Tree Protocol (STP).

■ Chapter 2, “Why Change Current Networks? A Need for Change”: This chapter
provides a summary of external trends, drivers (or forces), that require the current
campus network design and operation to be changed to cope with these drivers. You
will learn about external trends such as wireless/mobility, (Net)DevOps, complexity,
cloud, and digitization.

■ Chapter 3, “Enterprise Architecture”: This chapter describes the concept of enter-

prise architecture, why that is beneficial to enterprises in general and specific to a
xxii Transforming Campus Networks to Intent-Based Networking

network design within the enterprise. You will learn that a network design
(or architecture) is part of a larger technology architecture and an architecture for
the enterprise or organization as a whole. This chapter uses the TOGAF® standard
for enterprise architectures both as an introduction to enterprise architecture as well
as an example for the relationship between network infrastructures and enterprise
architecture.

■ Chapter 4, “Cisco Digital Network Architecture”: This chapter provides you with a
detailed explanation of Cisco Digital Network Architecture (DNA) that Cisco intro-
duced in May 2016. Cisco DNA is an architecture that is intended to be the founda-
tion for both modern state-of-the-art network infrastructures as well as the concept
of Intent-Based Networking. You will learn the different requirements Cisco DNA
has, the building blocks of its architecture, and the different design principles.

■ Chapter 5, “Intent-Based Networking”: In this chapter you will learn the concept
of Intent-Based Networking (IBN) via the explanation of what Intent means, how
that can be applied to a network infrastructure, and how it relates to Cisco Digital
Network Architecture. You will learn how IBN can help the network operations
team cope with the changes described in Chapter 2 and be able to remain in con-
trol of the network. Chapter 5 also introduces two technical concepts, Software
Defined Access and Classic VLANs, that can be used to deploy an Intent-Based
Network. Intent-Based Network (or Intent-Enabled Network) is used throughout
this book as a network that is configured based on the concept of Intent-Based
Networking (IBN)—that is, IBN describes the concept, and Intent-Based Network is
an implementation of that concept.

■ Chapter 6, “Tools for Intent”: This chapter provides a short overview of the tools
that are available to enable Intent-Based Networking within the campus network. In
this chapter you will learn about important concepts within IBN, such as automation
and assurance, and which tools can fulfill those requirements for the concept of IBN.

Part II, “Transforming to an Intent-Based Network,” describes a four-phased approach

that supports you in a successful transformation to Intent-Based Networking, including
tips, tricks, and problems you might face during the transformation. It is best to read this
part completely and not skip a chapter as they are built on one another.

■ Chapter 7, “Phase One: Identifying Challenges”: This chapter describes the first
phase of the transformation and is all about identifying the requirements (I used the
word challenges on purpose, as that is more positive and challenges can be solved)
within a campus network and getting the proper support and commitment. You will
learn that IBN is a concept that not only involves (new) technologies and sets specific
hardware requirements but also sets requirements and expectations on the organiza-
tion. You will learn which challenges are to be identified on the required hardware
and software as well as challenges related to the organization and its processes. The
chapter ends with an action plan that contains details on how to approach the trans-
formation to IBN.
 Introduction xxiii

■ Chapter 8, “Phase Two: Prepare for Intent”: This chapter describes phase two of
the transformation. Phase two is used to prepare the campus network and the orga-
nization for the transformation. It starts with solving all the challenges identified
in the previous phase. After these challenges are solved, the remaining steps of the
phase focus on preparing the network (and network operations team) for a successful
transformation to IBN. You will learn about the standardization of the campus net-
work, the introduction of automation and assurance to the network operations team,
and why these steps are important for IBN. These steps also include tips on why and
how to execute them. The last section of this chapter contains information about
risks that you might encounter during this phase, including some suggestions on how
to cope with them.

■ Chapter 9, “Phase Three: Design, Deploy, and Extend”: This chapter provides all
information required to actually transform the campus network to an Intent-Based
Network. You will learn two technology concepts (Software Defined Access and
classic VLAN) that can be used to deploy your campus network with their pros
and cons. You will be executing sequential steps to gradually implement IBN on
the campus network. As with the previous phases, a special section on risks for this
phase allows you to identify and prepare for potential problems.

■ Chapter 10, “Phase Four: Enable Intent”: This chapter describes the last phase of
the transformation; now that the campus network is transformed to IBN, it is time
to fully take advantage of the possibilities created. The chapter involves a strategy
on how you can introduce IBN to the rest of the organization, including a special
methodology to allow the campus network to deliver services to the business on
demand.

Part III, “Organizational Aspects,” is quite a different part compared to the first two.
Whereas the first two are primarily focused on background information and hands-on
for the transformation, this part provides information on the impact that IBN has on the
organization. This part’s chapters can be read individually and are as follows:

■ Chapter 11, “Architecture Frameworks”: This chapter provides a quick recap of

architecture frameworks and provides an insight to how IBN will impact and change
the traditional enterprise architecture frameworks.

■ Chapter 12, “Enabling the Digital Business”: This chapter provides a more detailed
description of the concept of digitalization and digital business. It describes how
Intent-Based Networking fits within (and enables) the digital business and what
impact this will have on an organizational level.

■ Chapter 13, “IT Operations”: This chapter describes the relationship between IBN
and common IT operations. It provides an introduction to common IT operation
models such as ITIL, DevOps, and Lean. It also describes what impact and change
IBN will have on these IT operation models.

■ Chapter 14, “Tips to Make Your IBN Journey a Success”: The transformation
to IBN involves quite some change, including technical, organizational, and indi-
vidual. This chapter provides background information and tips on how change can
xxiv Transforming Campus Networks to Intent-Based Networking

be achieved at both an individual and an organizational level. It covers information

on human change and associated fears, and it provides tips you can use to make
the change happen. It also contains some final tips that can be used to make the
transformation to IBN last.

Part IV, “Appendixes” This book also has appendixes that provide you with conceptual
background information on the technologies named throughout this book as well as
reference configurations for the underlay of an Intent-Based Network:

■ Appendix A, “Campus Network Technologies”: This appendix provides a conceptual

overview of the different technologies used in this book that are commonly found
on a campus network. This appendix does not provide a detailed technical explana-
tion of the technologies but rather a more conceptual summary of the technology
and how it is applied. This appendix is a recommended read for less-technical readers
to provide a more common understanding of the technologies;

■ Appendix B, “Sample Configurations”: This appendix provides a set of sample

configurations that can be used on the campus network to implement IBN; this
appendix is rather technical as it contains specific configuration elements. It is
provided as a head start to Intent-Based Networking for network architects and
engineers.
 Chapter 5

Intent-Based Networking

By and large, Cisco DNA describes the requirements and operations of a network infra-
structure of an enterprise on an abstract level. Cisco DNA achieves this description by
dividing the requirements of the enterprise network into several functions and design
principles. Cisco DNA itself does not describe how to use or implement that network
architecture. You can compare it with the design of a large office building. The drawings
provide enough guidelines and a viewpoint of how the building will look. But it does not
provide details on which materials the contractor needs to create the building or which
functionality the building will be used for. Cisco DNA is nothing more than a description
of the network in an abstract manner.

Intent-Based Networking (IBN) provides a powerful description and methodology on

how you can use that network if it is built using Cisco DNA’s specifications and require-
ments. IBN is essentially a viewpoint or perspective of an implemented network using
Cisco DNA’s requirements, design functions, and abstraction levels.

But what is Intent Based Networking? What perspective does it provide? This chapter
describes IBN in more detail and covers the following topics:

■ What is Intent
■ Intent-Based Networking paradigm
■ IBN designs
■ Network as a platform
■ Possible IBN implementations
■ IBN examples
78 Chapter 5: Intent-Based Networking

What Is Intent?
To understand what Intent-Based Networking is, it is important to know more about what
Intent encompasses. Purpose is a synonym and probably makes the definition of intent
easier to understand.

Every person, department, or organization has multiple intents or purposes. An orga-

nization can have the purpose to provide the best in class of software to schools, or to
provide the best phones in the world. A business process can have the intent to fulfill its
described task in the most efficient manner. A person can of course have multiple intents
or purposes. In general, intent or purpose is a description of a goal to be achieved.

A good example of intent would be that my wife likes me to clear out the garbage cans
in the kitchen and put their contents in the containers outside our home. My actions to
fulfill her intent would then be: Take out the general-waste trash bag from the can in the
kitchen and carry it to the appropriate container outside. Walk back to the kitchen and
then take the bag of recyclable waste and put it in its correct container. Clean the kitchen
cans if needed and put new trash bags in them.

This example describes intent quite well. My wife has an intent, and I have described
steps to fulfill that intent. And once you take this point of view to many common tasks,
intent can be seen everywhere. Table 5-1 shows some examples of intent.

Table 5-1 Overview of Intents

Intent Execution Steps
I need the lawn Take the mower out of the garage, connect it to power, pull cord to
cut. start, push onto lawn and mow in lanes until lawn is finished, power
off the mower, remove grass from the lawn, disconnect the mower
from power cord, clean grass from the mower, and put it back in the
garage.
I’m organizing a Invite friends, prepare dinner as much as possible ahead of time, clean
dinner party. up the house, dress up, welcome friends, finish and serve the dinner,
clean up the table, and have a great evening.
I want to drive the Check whether enough fuel is in the car; if not, drive to the nearest gas
car. station and fill up the tank; start driving.
This sales order Check the stock for this order, search each item in warehouse, pick the
needs to be required items of the sales order, place them in a box, print the packing
shipped. slip and place it in the box, fill the box with bubble wrap and close it,
notify shipping organization of shipment, print the shipping label, stick
it on the box, and place the box on the outgoing platform.
Next year I need Prepare a budget proposal for the CFO explaining why replacement is
to replace fire- required, present the proposal, wait for approval, request quotes, pro-
walls. cure hardware, execute project to replace firewalls in production.
 What Is Intent? 79

Intent Execution Steps

This car needs to Procure all required parts, components, and implementation details;
be assembled. weld the chassis; place the chassis on the belt; let robots and workers
assemble all parts; execute quality and assurance testing; prepare the
car for shipment, and ship the car to the dealer.
I need to upgrade Determine the new version of the software, upgrade the test environ-
the code on the ment with the new version, execute tests to check if the new version
network switch. works with existing designs, validate results, request a change window
for update, notify end users, execute update, validate if the upgrade
was successful, update documentation, and close the change.

As you can see, intent is everywhere. An intent is essentially a brief description of the
purpose and a concrete predetermined set of steps that need to be executed to (success-
fully) achieve the intent. This principle can also be applied to the operation of a network
infrastructure. The intent and its steps describe very specifically what needs to be done
on the network to accomplish a specific task. Table 5-2 provides a number of examples of
how intent can be applied on a network infrastructure.

Table 5-2 Overview of Network-Based Intents

Intent Execution Steps
I have a telepres- Create an HD video session to the remote peer, create the required
ence session at end-to-end Quality of Service parameters for this specific session,
10:00 a.m. reserve the bandwidth, set up audio, validate performance, keep the
connection safe and secure during the session, once finished discon-
nect the HD video session, remove the end-to-end quality of service
session, and remove the bandwidth reservation.
This application is Take the existing access policy for that application from the datacen-
migrating to the ter policy, transform the policy into an application policy for Internet
cloud. access, deploy the policy on all perimeter firewalls, and change routing
for that application to the cloud.
This new IoT Create a new logical compartment on the network, create an IP-space,
application needs set up Internet access policies, create access policies to recognize the
to be enabled. IoT devices, and assign them to the logical compartment.
This application Once the user starts the run, request access to system via the network,
needs access to open the required ports and IP addresses for the device that user is
HR systems during connected with via an access policy, wait until salary run is finished,
salary runs. remove the temporary access policies, and clear the open connections.
Potential malware Reallocate the device to an investigate policy that includes in-depth
has been found on monitoring of traffic and host isolation, execute a Change-of-
a device. Authorization to place the device in the new policy, notify security
and administrator of a possible incident, and await investigation.
80 Chapter 5: Intent-Based Networking

Table 5-2 provides only a small number of examples, but the possibilities are endless. The
most important condition (and restriction) is that the proposed intent must be written
in controllable, repeatable execution steps, so that the automation function within Cisco
DNA can execute those steps automatically. In summary, Intent-Based Networking is a per-
spective or viewpoint on how a network infrastructure that meets Cisco DNA’s functions,
design principles, and requirements is operated. Using this perspective to operate the net-
work will in turn enable the enterprise to embrace digitalization and the digital enterprise.

The following sections describe in more detail how this perspective leverages Cisco
DNA’s functions and design principles to achieve Intent-Based Networking.

Intent-Based Networking Perspective

IBN can be seen as a perspective on a Cisco DNA-based network infrastructure that
describes how the network can be managed, operated, and enable a digital business. It
translates an intent within the business into the configuration of the network required
for that specific intent. This is achieved by defining the intent as a number of (repetitive)
steps that can be deployed. The IBN perspective uses all aspects of Cisco DNA (design
principles, concepts, and so on) to accomplish this method of approaching the network.
The IBN perspective is based on a systematic approach where the network infrastructure
is seen as a holistic system.

Figure 5-1 shows this systematic approach.

Business

1. Request an intent 6. Intent-based feedback

Translation

2. Request 5. Validation and

steps metrics

Activation Assurance
translates steps into validates intent based on
configuration. feedback and telemetry.

3. Execution of 4. Network-driven feedback

configuration changes (config and telemetry)

Network Infrastructure

Figure 5-1 IBN Systematic Approach to the Network

 Intent-Based Networking Perspective 81

This approach resembles the functional approach of Cisco DNA a lot. It is, of course,
a perspective on how a Cisco DNA-based network infrastructure is operated. This
approach is based on six steps in a continuous loop.
1. Request an intent: A part of the business, whether a process, front-end application,
or operator, specifies a specific Intent request to the network infrastructure. This is
of course based on a number of available intents, where the variety of the Intent also
depends on the organization and the level of availability.

The translation process, receiving the request for Intent, translates the specific intent
into a number of repetitive executable required steps. This is, for deploying a net-
work Intent, perhaps one of the most important aspects of Intent-Based Networking.
These steps need to be designed, tested, and defined within the translation process.
Depending on the solution, these steps could be predefined templates or specific
pieces of network configuration specific to the enterprise. The implementation of
these repetitive executable steps needs to be as predictable as possible and is quite
often defined by the network designer.

For example, if the intent is a new IoT network, the Intent is translated into steps like
create a new network, assign an IP-pool to that network, and place this network into
a single logically separated compartment.

2. Request steps: Once the required steps for the specific intent are defined and cre-
ated, the requested steps are sent to the Activation process. This process receives the
requested steps and translates these steps into device-specific configuration changes
that are required on the network infrastructure. The Activation process knows which
configuration changes are required on which devices and uses automation to activate
the changes on the applicable network devices. In turn the Activation process pushes
the required changes to the network infrastructure.

Based on the earlier example of intent, the Activation process translates the new net-
work into a new VRF on a number of core switches in the network and allocates a
new VLAN where the IoT devices are placed. The allocated IP pool is translated into
a DHCP scope on the device that provides DHCP services to the network. A security
policy can automatically be added to detect and authorize the new IoT devices.

3. Execution of configuration changes: This is the step where the Activation process
actually connects to the network devices and deploys the changes to the network
infrastructure. At this stage the requested Intent has been translated into a specific
configuration on the network infrastructure. The requested intent is implemented.
Although the Activation process performs pre- and postchecks to validate if the con-
figuration of the network infrastructure devices was successful, the Activation pro-
cess cannot determine whether the deployed configuration has the desired outcome.

4. Network-driven feedback: In this step, the network infrastructure devices provide

feedback to the assurance process. The feedback is based on a number of data flows,
including the generated network configuration, telemetry on the network, which
client is connected, and how clients behave on the network. The network-driven
feedback is used to validate if the executed configuration changes from step 3 have
resulted in the desired outcome.
82 Chapter 5: Intent-Based Networking

Using the same example, the IoT devices are now connected to the network and
assigned to the specific VLAN and VRF. Telemetry data on whether the IoT device
gets an IP address and which communication flows are seen by the network are sent
to the Assurance process.

5. Validation & metrics: In this step the Assurance process has analyzed and validated
the different data flows received from the network infrastructure devices. The
received data is combined and analyzed, and potential issues or correct operation
is sent back to the Translation process. This step provides the feedback on whether
the requested intent is working as expected, and which IP addresses clients have
received, including metrics on the usage, are provided to the Translation process.

Within the same example, the status of the intent, including client-related informa-
tion is sent to the translation process.

6. Intent-based feedback: The translation process receives metrics and the valida-
tion of the requested intent operation. The Translation process checks the status
of the requested intent continuously and determines whether problems exist with
the requested intent. In case of a problem, the operations team is informed of the
failed state, and the business can request the status of the requested intent as well.
Similarly, statistics on the usage of the requested intent are provided to the business
layer using application-based metrics such as number of devices, accumulated data
usage, and availability statistics, some of the most often used key performance indi-
cators for the business.

Within the same example, this step provides a positive status back to the business
that the requested intent is operating as requested and provides an aggregated over-
view on availability and bandwidth usage to the business. The new IoT application is
running successfully on the network.

These individual steps are executed for every requested intent. A large network can
quickly have hundreds of requested intents to be added and run on the network. In
addition to the requirement that these steps can run in parallel for different intents, the
network must also be able to validate whether the requested intents are still working as
expected. Therefore these steps, including the validation, are run in a continuous loop
(shown by the dotted arrows in Figure 5-1) to validate whether the network is operating
and working as designed. This allows the network to provide intelligent support to the
operation teams on the performance and operation of the network.

The first three steps of IBN are common in today’s campus networks. They are com-
monly deployed where automation is gaining momentum using a wide range of automa-
tion tools. The key difference between classic networks and an Intent-Based Network is
that with IBN there is automated validation of the changes made to the configuration.
The testing and validation of a configuration, also in operation, is unique to Intent-Based
Networking and raises the quality and capability of the network.

Another key difference is that for IBN all steps and communication are based on APIs
and models, conforming to Cisco DNA’s design principles. This provides a new unique
approach to the network, where applications can now automatically request intent to the
 Intent-Based Networking Designs 83

network without the network operations team requiring to perform these changes. The
feedback, based on the assurance, is also provided via APIs, so the same applications can
validate that the requested intent is working as operated.
These two aspects of IBN—automatically validating changes of the network, as well as
providing the network as a platform to software engineers—allow the enterprise to use
the network in new, intuitive ways and enable the digital business.

Intent-Based Networking Designs

Intent-Based Networking is a perspective to a Cisco Digital Network Architecture. This
means that specific designs and technologies are still required to allow a campus network
to become Intent-enabled. The following sections describe two common Intent-Based
designs (Software-Defined Access or using classic VLANs, known as non-Fabric) that can
be used for a campus network to enable IBN.

Before the two Intent-Based designs are described, it is important to be aware that both
designs have a certain set of requirements in common:

■ Policy-centric network: First and foremost is the requirement that an Intent-Based

design is based on a policy-centric environment and not a port-centric design. In
other words, the network is not configured on a port-by-port basis, but uses a cen-
tral policy server that pushes the required network port configuration as a policy to
a network port.

All policies for endpoints are pushed from this policy server into the network. This
is key to enable intent onto a network, as the intent for an endpoint can change over
time based on circumstances.

For a specific policy to be set to an access port (or wireless network), it is necessary
to know which endpoint is connecting to the network. Network Access Control (using
IEEE 802.1X standard or MAC Authentication Bypass) is required to identify the end-
point requesting access to the network and to provide it with the proper authorization
onto the network (by sending specific policies to the switch using RADIUS). A RADIUS
deployment, such as Cisco Identity Services Engine, is thus required for IBN.

■ Microsegmentation: To greatly enhance the security and tightly integrate it within

Cisco DNA (and thus IBN), you should be able to segment a network into smaller
bits than an IP subnet based on specific policies. This mechanism, already used in
the datacenter, is called microsegmentation. Microsegmentation creates the pos-
sibility of having a single IP network for all IoT devices and having a policy that
only IoT sensors are allowed to communicate with a local storage device where the
data for those sensors are stored, while other IoT devices do not have access to that
storage device. This microsegmentation must be based on a policy and be able to
be programmatically applied to the network. Scalable Group Tags (SGT, formerly
known as Security Group Tags) are used within a Software Defined Access (SDA)
network (more on SDA in the next section) to provide this microsegmentation.
Appendix A, “Campus Network Technologies,” describes in more detail how SGTs
facilitate the required microsegmentation.
84 Chapter 5: Intent-Based Networking

■ Feedback from network: One of the true distinctions between a classic campus net-
work as described in Chapter 1, “Classic Campus Network Deployments,” and IBN
is the feedback of the status of the network back to the controller. In other words,
within an IBN the network devices provide feedback to the controller about the
network’s state. This feedback is used to validate whether the network is accomplish-
ing the intent required. This feedback is of course received programmatically or via
telemetry. Several methods and technologies are available to provide this feedback.
The technical details for feedback are described in Appendix A, “Campus Network
Technologies.”

SDA
Software-Defined Access (SDA) is one of the latest technologies introduced in campus
networks. It is the most complete technology (or actually a combination of technologies)
that can enable Intent-Based Networking on your network.

The key concept of SDA is that there is a single, fixed underlay network and one or more
overlay networks (running on top of the underlay). This concept in itself is not new; it
is the founding principle for any network where encapsulating and decapsulating data
allows the data to be abstracted from the different OSI layers. This principle is also used
for VPNs over the Internet, CAPWAP tunnels for wireless communication, and within
datacenters.

The principle of an underlay and overlay network can best be described using a common
technology in enterprise networks—the Cisco Remote Access VPN solution based on
Cisco AnyConnect. This technology allows end users to connect securely to the enter-
prise network via a less secure network (Internet).

This is realized by creating specific group policies (and pools of IP addresses) on the
VPN headend device (a Cisco ASA firewall or Cisco Firepower Threat Defense firewall).

Users use the AnyConnect client to connect to the VPN headend over the Internet. Based
on the authentication and authorization, users are allocated a specific internal IP address
and the policies determining their access to the enterprise network. The user’s endpoint
uses the internal IP address to communicate with the enterprise network. This is accom-
plished by encapsulating the internal IP addresses into an outer packet destined to the
VPN headend.

At the VPN headend, the packet is decapsulated and routed into the enterprise network.
A similar path is realized for return traffic. The enterprise network only knows that the IP
address of that user needs to be sent to the VPN headend. The VPN headend takes the
internal traffic and encapsulates it in an outer packet with the destination of the public IP
address of the end user.

In this example, the underlay network is the Internet, and the overlay network is the
specific VPN group policy that the user is assigned to with the appropriate IP pool.
SDA takes the same principle but then applies it internally to the campus network. SDA
calls the underlay network a campus network, and it uses virtual networks on top of the
 Intent-Based Networking Designs 85

underlay to logically separate endpoints. In other words, there are no VLANs within an
SDA fabric. Figure 5-2 provides an overview of an SDA network.

Virtual Network Green

(Overlay) Border Node
(Distribution Switch)

Client
External
VN Green
Network

Control
Edge Node Edge Node Node
Client
VN Red (Access Switch) (Access Switch)
Virtual Network Red Fabric
(Overlay) (Underlay Network)

Figure 5-2 Overview of an SDA Network

SDA uses its own terminology to describe the roles and functions the switches (or in
some cases routers) perform within the SDA fabric:

■ Virtual Network: A virtual network is used to logically separate devices from

each other. It can be compared with the way VLANs are used to logically separate
devices on a switched network. A virtual network can be IPv4 or IPv6 based with
one or more pools of IP addresses, but it can also be used to create a logical Layer 2
network. Each virtual network has its own routing and forwarding table within the
fabric, comparable with VRF-Lite on switches. This principle provides the logical
separation of the virtual networks.

■ Fabric: A fabric is the foundation of the overlay network, which is used to imple-
ment the different virtual networks that run within a network. A fabric is a logically
defined grouping of a set of switches within the campus network, for example, a
single location. The fabric encompasses the protocols and technologies to transport
data from the different virtual networks over an underlay network. Because the
underlay network is IP based, it is relatively easy to stretch the underlay network
across fiber connections on the campus (connecting multiple buildings into a single
fabric) or even across a WAN (such as MPLS or an SD-WAN), factoring in specific
requirements for SDA. These requirements are explained in Appendix A, “Campus
Network Technologies.”

■ The underlay network: The underlay network is an IPv4 network that connects all
nodes within the fabric. An internal routing protocol (within an SDA-campus IS-IS is
commonly used, although OSPF is also possible) exchanges route information within
86 Chapter 5: Intent-Based Networking

the fabric between the nodes. The underlay network is used to transport the data
from the different virtual networks to the different nodes.

■ Edge node: The edge node is used to allow endpoints to connect to the fabric. It
essentially provides the same function as the access switch layer in a classic campus
network topology. From an SDA perspective, the edge node is responsible for encap-
sulating and decapsulating the traffic for that endpoint in the appropriate virtual
network. It also provides the primary role of forwarding traffic from the endpoint to
the rest of the network.

■ Border node: A fabric is always connected with external networks. The border node
is used to connect the different virtual networks to external networks. It is essential-
ly the default gateway of the virtual network to external networks. As each virtual
network is logically separated, the border node maintains a connection to the exter-
nal network for each individual virtual network. All traffic from the external network
is encapsulated and decapsulated to a specific virtual network, so that the underlay
network can be used to transport that data to the correct edge node.

■ Control node: The control node is a function that cannot be related to a function
within an existing classic campus network topology. The control node is responsible
for maintaining a database of all endpoints connected to the fabric. The database
contains information on which endpoint is connected to which edge node and within
which virtual network. It is the glue that connects the different roles. Edge nodes
and border nodes use the control node to look up the destination of a packet on the
underlay network to forward the inner packet to the right edge node.

How SDA Works

Now that the roles, functions, and concept of an underlay/overlay network are known,
how does SDA operate? What does an SDA network look like? The following paragraphs
describe the way endpoints within a virtual network communicate with each other.
Figure 5-3 provides an example topology of an SDA network.

www.myserver.com
PC1 (209.165.200.225)
SW1
10.0.0.4
Edge Node

192.168.0.0/30
.2
.1
VN Green: 10.0.0.0/24 Internet
.5 CSW1
.6
192.168.0.4/30 Border and
Control Node
SW2
PC2 Edge Node
10.0.0.5

Figure 5-3 Sample SDA Network

 Intent-Based Networking Designs 87

In this SDA fabric there are three switches. The CSW1 switch provides the Border and
Control functionality, while SW1 and SW2 are edge node devices in this fabric. Both SW1
and SW2 have an IP link to the CSW switch, using 192.168.0.0/30 and 192.168.0.4/30
subnets. There is a virtual network (VN) named green on top of the underlay network,
which uses the IP network 10.0.0.0/24 for clients. PC1 has IP address 10.0.0.4, and PC2 has
IP address 10.0.0.5. The default gateway for VN Green is 10.0.0.1.

CSW1 maintains a table of endpoints connected to the fabric and how to reach them. To
explain the concept and operations, Table 5-3 describes the required contents for this
example.

Table 5-3 Overview of Fabric-Connected Devices in CSW1

Endpoint Name IP Network SGT VN ID Reachable Via
PC1 10.0.0.4 Employee Green 192.168.0.2

PC2 10.0.0.5 Guest Green 192.168.0.6

Internet 0.0.0.0 Any Green 192.168.0.1,

192.168.0.5

In this network, if PC1 wants to communicate with www.myserver.com (IP

209.165.200.225), the following would happen:

1. After DNS resolution, the PC sends a TCP SYN packet to the default gateway
(10.0.0.1) for destination 209.165.200.225.

2. SW1 as edge switch receives this packet and, as it is an anycast gateway (see
Appendix A, “Campus Network Technologies” for more details), the packet is
analyzed.

3. SW1 performs a lookup on the CSW1 (as control node) for the destination
209.165.200.225.

4. CSW1 returns a response for the lookup ip-address 192.168.0.1 (IP address of border
node).

5. SW1 then encapsulates the complete TCP SYN packet in an SDA underlay network
packet with source IP address 192.168.0.2 and destination address 192.168.0.1 and
uses the global routing table to forward this new packet.

6. CSW1 receives the encapsulated underlay packet from SW1 and decapsulates it. It
then, as border router, uses the routing table of VN Green to forward the traffic to
the Internet.

7. The server www.myserver.com receives the TCP-SYN packet and generates a

response with a SYN-ACK packet back to 10.0.0.4.

8. The incoming SYN-ACK packet is received by CSW1 in the VN Green network. The
destination of the packet is 10.0.0.4.
88 Chapter 5: Intent-Based Networking

9. CSW1 performs a lookup to the control node for VN Green and IP address 10.0.0.4
and gets 192.168.0.2 as the underlay destination.

10. CSW encapsulates the SYN-ACK packet for 10.0.0.4 into an underlay packet with
destination 192.168.0.2.

11. The underlay packet is routed to SW1.

12. SW1 decapsulates the packet, recognizes it is for PC1 (IP 10.0.0.4 ) on VN Green,
and forwards, based on a local table, the packet to the proper access port.
13. PC1 receives the SYN-ACK packet and responds with an ACK to further establish
the TCP flow. The principle of lookup is repeated by SW1 for each packet received
from or sent to PC1.

The preceding steps provide a conceptual overview of how communication is estab-

lished and packets are encapsulated/decapsulated onto the underlay network. The same
mechanism is used for communication within the VN Green itself. The control node is
used as lookup to ask where a specific IP address is located, and then the original packet
is encapsulated in an underlay packet destined for the specific node in the fabric. If
microsegmentation policy would not allow communication from SGT Employee to SGT
Guest, an access list on the edge node would prevent that communication.

An SDA-based topology is very powerful and capable in enabling IBN. The underlay net-
work is set up only once, when the SDA network is created. In addition, there is increased
flexibility in adding or removing edge nodes when required (as it is essentially a router
in the underlay); all the endpoints are connected to one or more virtual networks. These
virtual networks can easily be added or removed from the SDA network, without ever
impacting the underlying network. This process of addition or removal can easily be pro-
grammed in small building blocks that automation can use. The Cisco DNA center solu-
tion is used to deploy and manage an SDA-based network.

Classic VLAN
Although SDA was designed and built for Cisco DNA and is meant to solve some prob-
lems on classic campus networks, not all enterprises can readily implement SDA in their
network. One of the main reasons is that there are some requirements on the network
hardware and topology to enable SDA. This is not only Cisco DNA Center but also a
full Identity Services Engine deployment as well as specific hardware such as the Cisco
Catalyst 9000 series access switches. Although the Catalyst 3650/3850 are capable of
running an SDA network, there are some limitations to that platform, such as an IP ser-
vices license and a limited number of virtual networks.

However, if you look at an SDA through a conceptual looking glass, it is possible to rep-
licate, with some limitations, the same concepts of SDA using classic VLANs and VRF-
Lite. It allows an organization to transform to IBN while also preparing the infrastructure
for SDA to take advantage of the concepts within SDA. Table 5-4 provides an overview of
the concepts used in SDA compared to the technologies that can be used for IBN within
a classic VLAN-based campus network.
 Intent-Based Networking Designs 89

Table 5-4 Overview of Design Choices for SDA and Campus Alternative
SDA Network Classic Campus Network
Endpoints are, based on identity, assigned Endpoints are assigned to a VLAN and SGT.
to a virtual network and an SGT.
Each virtual network has its own routing VRF-Lite can be used to logically separate IP
table and IP space. networks and have each VRF instance its own
routing table.
The provisioning of virtual networks is easy With automation tools, it is easy to program-
because the underlay is created only once matically add and remove VLANs on uplinks
and virtual networks can be added and as well as SVIs on the distribution switch.
removed without interrupting the underlay.
Routed links in the underlay are used to In a collapsed-core campus network, there is
remove Spanning Tree and Layer 2 com- no need for Spanning Tree, or a single Spanning
plexities. Tree instance can be run to prevent loops.
An underlay network is used to stretch a This is not possible without an encapsulation
fabric over multiple physical locations. protocol in classic networks.
A control node is used for lookup of end- This is not required as existing protocols like
points. ARP can be used.

With some limitations (specific conditions) it is possible to enable an IBN design using clas-
sic VLAN technologies. Limitations for such a design are a collapsed-core design, ability
to assign SGT, and VLANs using a policy server as well as preferably no Spanning Tree or a
single Spanning Tree instance. If you take these limitations, Figure 5-4 provides an intent-
based design based on a classic collapsed-core campus network topology and VRF-lite.

www.myserver.com
PC1 (209.165.200.225)
10.0.0.4
SW1
PortChannel
VLAN Allowed VLANs: 100,201
201
DSW1

Internet

VLAN PortChannel
Allowed VLANs: 100,201
201
PC2 SW2
10.0.0.5
Interface VLAN201
vrf forwarding green
ip address 10.0.0.1 255.255.255.0
ip route vrf green 0.0.0.0.0.0.0.0 gateway

Figure 5-4 Intent Design Based on Classic Campus Collapsed-Core Topology

90 Chapter 5: Intent-Based Networking

In this design PC1 and PC2 still have the same IP address but are now assigned into
VLAN 201 instead of virtual network green. VLAN 201 is configured on the DSW1 with
IP network 10.0.0.0/24 and a default gateway of 10.0.0.1 for the endpoints. The SGTs have
remained the same: Employee for PC1 and Guest for PC2.

Just as in the previous example, if PC1 would communicate with www.myserver.com on

209.165.200.225, it would send its TCP SYN packet to the default gateway on DSW1,
which in turn would forward it to the Internet, while return traffic would be sent via
Ethernet to PC1. ARP is used to map IP addresses into MAC addresses.

The principle of SGT ACLs to restrict traffic within a VRF is the same. In both SDA as
well as classic, the SGT ACL is pushed from the policy server to the access switch where
the endpoint is connected.

Although the end goal is logically separating traffic between endpoints, using SGT for
microsegmentation, there are some limitations and restrictions on a classic VLAN over an
SDA topology.

■ Spanning Tree: It is not preferred to run Spanning Tree on the network, as each
change in a VLAN can trigger a Spanning Tree recalculation, resulting in blocked
traffic for a period of time. If it is required to run Spanning Tree, then run a single
instance of Spanning Tree in MST mode, so that adding a VLAN does not trigger a
new STP topology as with per-VLAN Spanning Tree.

■ Management VLAN and VRF: It is required to have a dedicated VLAN and man-
agement VRF to be able to create or remove new VLANs. This VLAN may never be
removed from trunks and networks, as this is essentially the underlay network. The
automation tool that generates and provides the configuration communicates with all
devices in this management VLAN.

■ Configuration via automation tool only: The configuration of the campus net-
work can only be executed via the automation tool. This is generally true for
any environment that there should only be a single truth for the provisioning of a
network. In an IBN based on classic VLANs, this is more important as the automa-
tion tool will generate the VLAN identifiers automatically based on the virtual
networks to be deployed. Although it is common in enterprises to statically define
and assign VLANs, in this design that concept needs to be removed for automation
to work.

■ Standardized building blocks only: It is important to only allow standardized

building blocks, defined via the automation tool, on the campus network, where
the policy is assigned policy-centric using IEEE 802.1x and RADIUS. The building
block can then be standardized in such a way that small pieces of configuration code
can be generated on-the-fly to create or remove the required compartments on the
network. This is realized by creating small repetitive code blocks of command line
 Summary 91

configuration to be executed, for example, for the creation of a new compartment

on the access switch:
vlan $vlanid
name $vrfname
interface $PortChannelUplink
switchport trunk allowed vlan add $vlanid

If the campus network configuration cannot be standardized, it will not be possible

to enable an Intent-Based Network using VLANs.

■ Build your own automation: With SDA, a lot of automation and configuration is
executed by Cisco DNA Center in the background. With this design, an automation
tool needs to be installed and configured by the network team to provide similar
functionality. This can require some custom coding and testing before running the
solution in production. This could be Cisco DNA Center with templates or another
tool that provides automation functionality.

In summary, both mechanisms (SDA and classic VLAN) work quite similarly, and when
you take certain precautions and keep the limitations in mind, it is feasible to start with
IBN based on a classic collapsed-core topology. Part 2, “Transforming to an Intent-Based
Network,” provides more details on limitations, drawbacks, and when which technology
fits best for transforming a campus network to IBN.

Summary
Cisco Digital Network Architecture describes the requirements and operations of a net-
work infrastructure of an enterprise at a functional or abstract level. Cisco DNA achieves
this abstract description by dividing the requirements of the enterprise network into sev-
eral functions and design principles. It does not describe how to use or implement that
network architecture.

Intent-Based Networking (IBN) describes, using a powerful methodology, how a cam-

pus network can be built and operated using Cisco DNA as network architecture. IBN
is based on the premise that every endpoint that connects to the network consumes a
predefined set of services (that include access, connectivity, security policies, and other
network functions). In essence, every endpoint has a specific intent (or purpose) when
connecting to the network, and each intent is defined as a set of services to be delivered
to that endpoint.

This set of intents (that are deployed on the network) are defined dynamically based on
which endpoints are connected to the network. As soon as an intent is not required any-
more, its configuration is removed automatically from the network infrastructure.

Although IBN itself is not based on Cisco Digital Network Architecture, its description
and methodology are so similar to Cisco DNA that you can state it is a perspective of
Cisco DNA. IBN describes how a network based on Cisco DNA can be configured and
92 Chapter 5: Intent-Based Networking

operated by the network operations team. Figure 5-5 describes the systematic approach
IBN describes in providing intents to the network (by defining Intents as repetitive pieces
of configuration).

Business

1. Request an intent 6. Intent-based feedback

Translation

2. Request 5. Validation and

steps metrics

Activation Assurance
translates steps into validates intent based on
configuration. feedback and telemetry.

3. Execution of 4. Network-driven feedback

configuration changes (config and telemetry)

Network Infrastructure

Figure 5-5 IBN Systematic Approach to the Network

Figure 5-5 is similar to Cisco DNA, and IBN is based on six steps in a continuous loop:

1. Request intent; business or network operations request a specific intent.

2. Request steps; the intent is translated into a set of configuration changes to be executed.

3. Execution of configuration changes; network configuration changes are executed via

automation.

4. Network-driven feedback; the network infrastructure provides feedback on its operation.

5. Validation & metrics; the analytics component validates the received network-driven
feedback with the requested intents to validate that the requested intents are operat-
ing as requested and designed.

6. Intent-Based feedback; business-outcome based values are used to report on the sta-
tus of the requested intent and its operation.
 Summary 93

Two Designs
Two network designs are available to implement IBN:

■ Cisco Software Defined Access (SDA) is based on Cisco DNA and is the most com-
plete technology that can enable IBN on the campus network, but Cisco SDA does
have specific requirements on the network infrastructure devices (and Cisco DNA
Center).

■ Classic VLANs with VRF-Lite can be used, with limitations, as an alternative to SDA
for those organizations that are not (yet) able to meet the requirements of SDA.

IBN itself, and therefore both designs, relies on three key requirements on the campus
network to be successful:

■ Policy-centric network: The campus network is not configured port-by-port but

uses a policy-centric identity server so that based on the identity of the endpoint
the specific network policies (and thus the intents) can be pushed to the appropriate
network infrastructure device.

■ Microsegmentation: Microsegmentation is used within IBN to allow for more

granular security policies than those based solely on IP addresses.

■ Feedback from network: IBN relies heavily on the feedback that network
infrastructure devices provide back to the analytics component; it is used to
validate whether the requested intents are operating as designed and requested.

In conclusion, IBN is a perspective on Cisco Digital Network Architecture, and it

describes a powerful methodology of how a Cisco DNA-based network infrastructure
can be operated and managed. IBN can be used to provide the network operations team
with the tools and methods to cope with the exponential growth of devices connecting
to the campus network.
Index

ADM (Architecture Development

A Method), 43
phases of, 43–45
ABB (Architecture Building Blocks), 47
requirements management, 45
access (authorized), example of IBN,
225–226 Agile software engineering
methodology, 33–34
access layer, 4
analysis (action plans), 144
access port configuration, 135,
196, 207 analytics, 312
access requests, architecture application behavior analytics,
frameworks, 233–235 112–113
access switches architecture frameworks, 232
configuration, 125–126, 160–161 Cisco DNA, 59, 65–66
failures, 4–5 MDT, 316–318, 320
accounting, RADIUS, 293 NetFlow, 318–320
action plans, 143, 146 network analytics, 111, 120–121
action lists, 144 Ansible, 118–119
analysis, 144 application behavior analytics,
112–113
decision lists, 144
DNAC Assurance, 113–115
estimated timelines, 144–145
NetBrain, 117–118
management summaries, 143
network function analytics,
Activation process (IBN), 81
111–112
ad hoc operations (organizational
network services availability,
maturity), 138
112
322 analytics

Prime Infrastructure, 115–117 App-Credits use case, 225

trend analysis, 112 applications
validation of Intent, 111 architectures, 42, 230
network function analytics, 111–112 behavior analytics, 112–113
SNMP, 312–314, 320 business-supported apps/portals
Syslog, 314–316, 320 (communication plans), 223
anchor controller deployments, 15 enterprise building example (applica-
tion organization), 130–132
Ansible
AR (Augmented Reality), 215–216
component overview of, 105–106, 108
architecture frameworks, 231–232
control engine, 106
application architectures, 230
control tower, 107–108
benefits of, 38–39
network analytics, 118–119
building blocks, 231
network automation, 105–108
business architectures, 230
playbooks, 107
change, possibility of, 231
AP (Access Points), 10–11
Cisco DNA, 51
AR and, 216
analytics, 59, 65–66
CAPWAP tunnels, 10–11
API, 70–71
Mobility Express, 14–15
automation, 58, 62–65
API (Application Program Interface)
Cisco DNA-ready infrastruc-
calls, matching to tools, 219
tures, 68–69
Cisco DNA, 70–71
cloud service management,
concept API definitions, 218 57–58
definitions, 218 conceptual overview of, 56–57
Intent-based API, 215–217 design principles, 60–73
network intents identity, 58–59
API calls, matching to tools, 219 infrastructure, 59
concept API definitions, 218 open standards, 69–70
generalizing, 217–218 overview of Cisco solutions,
identifying, 217 73–74
service catalogs, 219–223 policies, 66–67
Prime Infrastructure, 116 requirements, 51–56
service catalogs, 219–223 RESTful API, 71
APIC-EM (Application Policy routed ports, 68–69
Infrastructure Controller- security, 59–60, 71–73
Enterprise Module), 100–101
software, 66–67
day-0 operations, 169–171
switchports, 68–69
PnP, 284–285
VNF, 60–61
 automation 323

data architectures, 230 authentication

defined, 37–39 asymmetric SSH key authentication
digitalization, 246–247 and Ansible, 106–107
DIY architectures, 49 IEEE 802.1X network access control
standard, 291–293
drawbacks of, 39
RADIUS, 293
enterprise architectures
Authentication Server (IEEE 802.1X),
drawbacks of, 39
291
guidelines/principles, 46
Authenticator (switch), IEEE 802.1X,
flexibility, 231 291
IBN, impact of, 232 authorization
access requests, 233–235 IBN, authorized access, 225–226
analytics, 232 RADIUS, 157, 293
automation, 232 VLAN, 157–158
Cloud Service Management, Autoconf, 207
232
automation, 174
infrastructure, 232–235
architecture frameworks, 232
implementation of, 231
build pipelines, 33
layered approach of, 229–230
Cisco DNA, 58, 62–65
overview of, 48–49
classic VLAN, 90–91, 185
repositories, 47–48
configuration changes, 173
reusability, 231
day-0 operations, 169–172
serviceability, 231
day-1 operations, 174
technology architectures,
day-2 operations, 173
230–231
day-n operations, 167–169
TOGAF®, 39–41, 48
IBN, transitioning to, 166–167
ADM, 43–45
LAN, 189–190
application architectures, 42
network automation, 111, 119–120
aspects of, 40–41
Ansible, 105–108
building blocks, 46–47
APIC-EM, 100–101
business architectures,
41–42 Cisco DNAC, 97–100
data architectures, 42 custom-built automation tools,
109–111
technology architectures,
42–43 defined, 95–97
Assurance process, 81–82, 162–166 NSO, 101–103
asymmetric SSH key authentication Prime Infrastructure, 100–101
and Ansible, 106–107 Puppet Enterprise, 103–105
324 automation

SWIM, 167
switch upgrades, 169
C
availability of resources, 150–151 calls (API), matching to tools, 219
campus networks
B Agile software engineering
methodology, 33–34
baselines, 187–188 Cloud Edge infrastructures, 30–32
classic VLAN, 193–199 cloud infrastructures, 30–32
SDA, 188–189 cloud-managed networks, 19–20
LAN automation, 189–190 collapsed core/two-tier topologies,
manual configuration, 8–9
190–193 complexity of, 28–29
bootstrap templates, 170–172 connected devices (IoT/non-user
border nodes operated devices), 26–27
dynamic VLAN, 190 development of, 23–26
SDA, 86 DevOps, 32–34
BPDU (Bridge Protocol Data Unit) digitalization, 35
packets, 16–17 functional layers, 4
BPDU Guard, 17–18 access layer, 4
breakouts core layer, 5–6
central controller with distribution layer, 4–5
central breakout deployments, hardware, inventories, 133–134, 152
12–13
IBN, transitioning to, 129
FlexConnect deployments,
access port configuration, 135
13–14
action plans, 143–146
local controller with local breakout
deployments, 13 Assurance process, 162–166
budget (prioritizing challenges in IBN automation, 166–167
transitions), 142 baselines, 187–199
build pipelines (automated), 33 challenges to day-to-day
building blocks (architecture operations, 129–132, 145
frameworks), 46–47, 231 change procedures, 149
business classic VLAN, 184–187
architectures, 41–42, 230 configuration standardization,
communication plans 222 160–162
processes and digitalization, 238 converting intents, 200–202
supported apps/portals (communica- day-0 operations, 169–172
tion plans), 223 day-1 operations, 174
 central controller with 325

day-2 operations, 173 uplink standardization,

day-n operations, 167–169 135–136
design/configuration documen- vendor/product selection, 149
tation, 149 visibility, 162–166
disaster recovery, 149 VLAN configuration standard-
enterprise building example ization, 136–137
(application organization), VLAN numbering, 159–160
130–132 wired campus design, 134
extracting intents, 201–202 wireless campus design,
generic IT visions/strategies, 134–135
149 manageability of, 29–30
incident management, 149 NetDevOps, 34–35
inventories, 132–134, 145, 152 redundancy, handling, 16–19
investment plans, 152–155 security, 29
lab environments, 179–181, shared switch configuration, 135
187
single switch topologies, 9–10
level of standardization,
software, inventories, 133, 152
134–138, 141–142, 145, 155
three-tier topologies, 6–8
lifecycle management, 149,
152–155 toolchains, 34–35
matching requirements, 148 trends in, 23–26
network infrastructure wired design, 134
requirements, 151–155 wireless design, 134–135
organizational maturity, CAPWAP (Control and Provisioning
138–140, 145 of Wireless Access Points) tunnels,
organizational requirements, 10–11
148–155 catalogs, network intents service,
port-centic to policy-centric 219–220
design migration, 155–159 business-supported apps/portals, 223
prioritizing challenges, pilots/proof of concepts, 222
142–143 sharing successes/failures,
resource availability, 150–151 221–222
risks of, 149, 174–176 understanding a business, 222
SDA, 181–184 CDB (Configuration Database) and
shared switch configuration, NSO, 101–102
135 central controller with
standardization across central breakout deployments,
locations, 137–138 12–13
upgrade plans, 151–152 FlexConnect deployments, 13–14
326 challenges

challenges architecture frameworks, 232

change management, 276–277 access requests, 233–235
day-to-day operations, 129–132, 145 analytics, 232
prioritizing in IBN transitions, automation, 232
142–143 Cloud Service Management,
chance of success (prioritizing 232
challenges in IBN transitions), 142 infrastructure, 232–235
change automation, 58, 62–65
change management, 271–272, 281 cloud service management, 57–58
challenges, 276–277 conceptual overview of, 56–57
communication, 276 design principles, 60–73
failures, 277 functions of, 213–214
fear of change, 274 identity, 58–59
focus, maintaining, 276 infrastructures, 59, 68–69
forward thinking, 277–278, 281 open standards, 69–70
governance, 279–280 overview of Cisco solutions, 73–74
incentives, 274–275 policies, 66–67
learning stages of a new skill, requirements, 51–56
272–273
RESTful API, 71
lifecycle management, 280
routed ports, 68–69
ownership, 281
security, 59–60, 71–73
ownership, taking, 278–279
software, 66–67
positivity, 281
switchports, 68–69
quid pro quo, 274–275
VNF, 60–61
speed of change, 281
Cisco DNAC (DNA Center), 97–100
stakeholders, 279–280
API, 215
training, 281
Assurance process, 162–166
training/demonstration, 279
DNAC Assurance, 113–115
enterprise architectures, 231
SDA, 182–183
procedures, 149
CiscoLive Europe intent API use case,
CICD (Continuous Integration/ 215–216
Continuous Delivery), 33–34
classic VLAN (Virtual Local Area
Cisco Design Thinking Framework, Networks), 184
243–245
automation, 185
Cisco DNA (Digital Network
baselines, 193–199
Architecture), 51, 77. See also IBN
IBN and, 88–91
analytics, 59, 65–66
Layer 2 intents, 185
API, 70–71
 configuration 327

overlay networks, 186 pilots/proof of concepts, 222

Scalable Group Tags, 185 successes/failures, sharing,
SDA and, 183–187 221–222
SDA topologies, 90–91 understanding a business, 222
templates, 186 complexity of campus networks,
28–29
testing, 186
compromise, IoC, 223–224
VRF-Lite distribution switches, 184
concept API definitions, 218
Cloud Edge infrastructures,
30–32 configuration
cloud access port configuration,
135, 196
Cloud Service Management
access switches, 125–126,
architecture frameworks, 232
160–161
Cisco DNA, 57–58
automation and configuration
infrastructures, 30–32 changes, 173
networks, 19–20 CDB and NSO, 101–102
COBIT (Control Objectives design/configuration documentation,
for Information and related 149
Technologies), 138
distribution switches, 124,
ad hoc operations, 138 126, 161
defined/documented processes/ generic (global) configuration, shared
responsibilities, 139 switch configuration, 135
framework summary, 139–140 global (generic) configuration,
internal control, 139 standardization, 160–162
intuitive operations, 138 Layer 3 configuration, shared switch
optimization, 139 configuration, 135
quality checks, 139 links, 191
repetitive operations, 138 loopback(), 191–192
risk management, 139 NTP, 161
version control, 139 ports, shared switch configuration,
135
collapsed core/two-tier topologies,
8–9, 89–90 SDA baselines, 190–193
commitment (prioritizing challenges shared switch configuration, 135
in IBN transitions), 142 Syslog, 161
communication underlay routing, 192
change management, 276 uplink port configuration, 196
plans, 221–222 VLAN, 136–137, 161–162
business-supported apps/ wireless networks, 161–162
portals, 223
328 connected devices (IoT/non-user operated devices)

connected devices (IoT/non-user central breakout deployments,

operated devices) 12–13
connections per capita, 27 FlexConnect deployments,
growth of, 26–27 13–14
control (internal), organizational local controller with local breakout
maturity, 139 deployments, 13
control nodes, SDA, 86 Mobility Express, 14–15
controllers design
anchor controller deployments, 15 Design Thinking, 242–245
central controller with central documentation, 149, 221
breakout deployments, 12–13 network design, 247–248
local controller with local breakout DevOps, 32–35, 257–258
deployments, 13 DHCP (Dynamic Host Configuration
wireless controllers, Cisco DNAC Protocol)
Assurance, 166 DHCP option 43, PnP, 285–286
core layer, 5–6 enterprise building example (applica-
CSI (Continual Service Improvement), tion organization), 131
255–256 LAN automation, 190
custom-built automation tools, PnP
109–111
day-0 operations, 170
CVD (Cisco Validated Designs), 3
DHCP option 43, 285–286
ZTP and, 287–288
D digitalization, 34–35
business processes, 238
data architectures, 42, 230
defined, 237–238
day-0 operations, 169–172
enterprise architectures, 246–247
day-1 operations, 174
IBN and, 245–246
day-2 operations, 173
model of, 238–239
day-n operations, 167–169
organizational impact, 246
day-to-day operations, challenges to,
129–132, 145 enterprise architectures,
246–247
defined/documented processes/
responsibilities (organizational network design, 247–248
maturity), 139 network operation, 248–249
demonstration/training, change stages of, 239, 241
management, 279 business and IT alignment, 239
deployments, wireless networks, 15 IT as business enabler, 240
anchor controller deployments, 15 IT change business processes,
central controller with 241
 enterprise architectures 329

IT proactive support of DNAC (DNA Center), 97–100

business, 240–241 API, 215
disaster recovery, 149 Assurance process, 162–166
distance-vector routing protocol, 299 DNAC Assurance, 113–115
distribution layer, 4 PnP, 286
distribution switches SDA, 182–183
configuration, 124, 126, 161 DNS (Domain Name System),
VRF-Lite distribution switches, 184 enterprise building example
DIY enterprise architectures, 49 (application organization), 131
DNA (Digital Network Architecture), documentation
51, 77. See also IBN design/configuration documentation,
analytics, 59, 65–66 149, 221
API, 70–71 organizational maturity, 139
architecture frameworks, 232 dynamic VLAN (Virtual Local Area
Networks), border nodes, 190
access requests, 233–235
analytics, 232
automation, 232 E
Cloud Service Management,
edge nodes, SDA, 85–86
232
enterprise architectures, 231–232
infrastructure, 232–235
application architectures, 230
automation, 58, 62–65
building blocks, 231
cloud service management, 57–58
business architectures, 230
conceptual overview of, 56–57
change, possibility of, 231
design principles, 60–73
data architectures, 230
functions of, 213–214
digitalization, 246–247
identity, 58–59
DIY architectures, 49
infrastructures, 59, 68–69
drawbacks of, 39
open standards, 69–70
flexibility, 231
overview of Cisco solutions, 73–74
guidelines/principles, 46
policies, 66–67
implementation of, 231
requirements, 51–56
layered approach of, 229–230
RESTful API, 71
overview of, 48–49
routed ports, 68–69
repositories, 47–48
security, 59–60, 71–73
reusability, 231
software, 66–67
serviceability, 231
switchports, 68–69
technology architectures, 230–231
VNF, 60–61
330 enterprise architectures

TOGAF®, 39–40, 48 fear of change, 274

ADM, 43–45 FinTech Ltd. use case, 25
application architectures, 42 automation, 64
aspects of, 40–41 communication and focus in change
building blocks, 46–47 management, 276
business architectures, 41–42 DIY architectures, 49
data architectures, 42 IBN technologies, choosing, 186
technology architectures, 42–43 intents, extracting, 201–202
enterprise building example first hop security, 196
(application organization), FlexConnect, central controller with
130–132 FlexConnect deployments, 13–14
estimated timelines (action plans), flexibility, enterprise architectures,
144–145 231
Ethernet and STP, 308–310, 320 focus, maintaining in change
examples of IBN (Intent-Based management, 276
Networking), 223 forward thinking, change
authorized access, 225–226 management, 277–278, 281
incident response security, 223–224 frameworks (architecture), 231–232
organizing meetings, 224–225 application architectures, 230
extended IBN (Intent-Based benefits of, 38–39
Networking) building blocks, 231
locations, 202–203 business architectures, 230
security, 204 change, possibility of, 231
IEEE 802.1X network access Cisco Design Thinking Framework,
control standard, 205–208 243–245
risks, 209 Cisco DNA, 51
scalability, 210 analytics, 59, 65–66
Scalable Group Tags, 208–209 API, 70–71
training, 210–211 automation, 58, 62–65
transitioning to SDA, 209–210 Cisco DNA-ready infrastruc-
tures, 68–69

F cloud service management,

57–58
fabrics, SDA, 85, 87 conceptual overview of, 56–57
failures design principles, 60–73
access switches, 4–5 identity, 58–59
change management, 277 infrastructure, 59
communication plans, sharing, 223 open standards, 69–70
 human change 331

overview of Cisco solutions, reusability, 231

73–74 serviceability, 231
policies, 66–67 technology architectures, 230–231
requirements, 51–56 TOGAF®, 39–41, 48
RESTful API, 71 ADM, 43–45
routed ports, 68–69 application architectures, 42
security, 59–60, 71–73 aspects of, 40–41
software, 66–67 building blocks, 46–47
switchports, 68–69 business architectures, 41–42
VNF, 60–61 data architectures, 42
data architectures, 230 technology architectures, 42–43
defined, 37–39 frequency band (unlicensed
digitalization, 246–247 spectrum), 26
DIY architectures, 49 functional layers, 4
drawbacks of, 39 access layer, 4
enterprise architectures core layer, 5–6
drawbacks of, 39 distribution layer, 4–5
guidelines/principles, 46
flexibility, 231 G
IBN, impact of, 232
access requests, 233–235 generic (global) configuration
analytics, 232 shared switch configuration, 135
automation, 232 standardization, 160–162
Cloud Service Management, 232 generic IT visions/strategies, 149
infrastructure, 232–235 governance in change management,
279–280
implementation of, 231
IT operations frameworks, 263
CSI in ITIL framework, H
255–256
hardware, inventories, 133–134, 152
DevOps, 257–258
human change, 271–272, 281
ITIL framework, 252–256
challenges, 276–277
Lean IT, 258–263
communication, 276
overusing, 252–253
failures, 277
ITIL framework, 252
fear of change, 274
layered approach of, 229–230
focus, maintaining, 276
overview of, 48–49
forward thinking, 277–278, 281
repositories, 47–48
332 human change

incentives, 274–275 digitalization and, 245–246

learning stages of a new skill, enterprise building example (applica-
272–273 tion organization), 130–132
ownership, 281 examples of, 223
ownership, taking, 278–279 authorized access, 225–226
positivity, 281 incident response security,
quid pro quo, 274–275 223–224
speed of change, 281 organizing meetings, 224–225
training, 279, 281 extended IBN
locations, 202–203

I security, 204–211
feedback
IBN (Intent-Based Networking), 77, intent-based feedback, 82
213–215). See also Cisco DNA network-driven feedback,
Activation process, 81 81–84, 93
API, 215–217 intent
calls, matching to tools, 219 defined, 78–80
concept API definitions, 218 example of, 78
definitions, 218 intent-based feedback, 82
generalizing network intents, network-based intents, 79–80
217–218 overview of, 78–79
identifying network intents, requesting, 81
217
metrics, 82
network Intent service catalogs,
microsegmentation, 83, 93
219–223
network analytics, 111, 120–121
architecture frameworks, IBN impact
on, 232 Ansible, 118–119
access requests, 233–235 application behavior analytics,
112–113
analytics, 232
DNAC Assurance, 113–115
automation, 232
NetBrain, 117–118
Cloud Service Management,
232 network function analytics,
111–112
infrastructure, 232–235
network services availability,
Assurance process, 81–82, 162–166
112
classic VLAN, 88–91
Prime Infrastructure, 115–117
collapsed core/two-tier topologies,
trend analysis, 112
89–90
validation of Intent, 111
design requirements, 83–84
 IBN (Intent-Based Networking) 333

network automation, 111, 119–120 change procedures, 149

Ansible, 105–108 classic VLAN, 184–187
APIC-EM, 100–101 configuration standardization,
Cisco DNAC, 97–100 160–162
custom-built automation tools, converting intents, 200–202
109–111 day-0 operations, 169–172
defined, 95–97 day-1 operations, 174
NSO, 101–103 day-2 operations, 173
Prime Infrastructure, 100–101 day-n operations, 167–169
Puppet Enterprise, 103–105 design/configuration
network-based intents, 79–80 documentation, 149
perspective, 80–83 disaster recovery, 149
policy-centric networks, 83, 93 extracting intents, 201–202
SDA, 84, 91 generic IT visions/strategies,
149
border nodes, 86
incident management, 149
classic VLAN over SDA
topologies, 90–91 inventories, 132–134, 145, 152
control nodes, 86 investment plans, 152–155
design choices, 88–89 lab environments, 179–181, 187
edge nodes, 85–86 level of standardization,
134–138, 141–142, 145, 155
example of, 86–88
lifecycle management, 149,
fabrics, 85, 87
152–155
operation of, 86–88
matching requirements, 148
overview of, 84–85
network infrastructure require-
underlay networks, 85–86 ments, 151–155
virtual networks, 85 organizational maturity,
security, IEEE 802.1X network 138–140, 145
access control standard, 205–208 organizational requirements,
systematic approach to networks, 80 148–155
transitioning to, 129 port-centic to policy-centric
access port configuration, 135 design migration, 155–159
action plans, 143–146 prioritizing challenges,
142–143
Assurance process, 162–166
resource availability, 150–151
automation, 166–167
risk management, 149
baselines, 187–199
risks of, 174–176
challenges to day-to-day opera-
tions, 129–132, 145 SDA, 181–184
334 IBN (Intent-Based Networking)

shared switch configuration, response security, example of IBN,

135 223–224
standardization across infrastructure
locations, 137–138 architecture frameworks,
tips for success. See change 232–235
management Cisco DNA, 59
upgrade plans, 151–152 Prime Infrastructure, 97–100,
uplink standardization, 115–117, 170
135–136 requirements (networks), 151–155
vendor/product selection, 149 installations (next-next-finish), 157
visibility, 162–166 intent API (Application Program
VLAN configuration Interface), 215–217
standardization, 136–137 Intent-Based Networking. See IBN
VLAN numbering, 159–160 intents
wired campus design, 134 IBN, transitioning to
wireless campus design, converting intents, 200–202
134–135
extracting intents, 201–202
Translation process, 82
Layer 2 intents, classic VLAN, 185
validation, 82
network intents
visibility, 162–166
API calls, matching to tools,
identity, Cisco DNA, 58–59 219
IEEE 802.1b, 23 concept API definitions, 218
IEEE 802.1X network access control generalizing, 217–218
standard, 156–157, 290–291, 319
identifying, 217
access port configuration, 207
service catalogs, 219–223
authentication process, 291–293
internal control (organizational
Authentication Server, 291 maturity), 139
Authenticator (switch), 291 intuitive operations (organizational
components of, 291–292 maturity), 138
IBN security, 205–208 inventories, transitioning to IBN,
RADIUS, 196, 205, 292–293 132–134, 145, 152
supplicants, 291 investment plans, 152–155
implementation of enterprise IoC (Indication of Compromise),
architectures, 231 223–224
incentives, change management, IoT (Internet of Things), growth of, 27
274–275 IP address pools, LAN automation,
incidents 189–190
management, 149 IPv6, first hop security, 196
 manageability of campus networks 335

ISE (Identity Services Engine), 157 redundancy, handling, 16–17

port-centic to policy-centric design VLAN, 305–308, 319
migration, 159 VXLAN, 301–302, 319
SDA, 183 Layer 2 intents, classic VLAN, 185
IS-IS, underlay routing configuration, Layer 2 networks, redundancy,
192 handling, 16–17
IT operations Layer 3 configuration, shared switch
conflicts/recommendations configuration, 135
changing design patterns, 264, Layer 3 networks, redundancy,
268 handling, 17
management by exception, Lean IT, 258–263
265–266, 268–269 learning stages of a new skill, 272–273
organizational change, LEI (Lean Enterprise Institute), 259
266–267, 270
lifecycle management, 149, 152–155,
working across domains, 266, 280
269–270
links, configuration, 191
digitalization
link-state routing protocol,
business and IT alignment, 239 299–300
IT as business enabler, 240 LISP (Locator/Identifier Separation
IT change business porcesses, Protocol), 302–305, 319
241 lists
IT proactive support of action lists, 144
business, 240–241
decision lists, 144
frameworks, 263
local controller with local breakout
CSI in ITIL framework, deployments, 13
255–256
locations, extended IBN, 202–203
DevOps, 257–258
LogiServ Inc. use case
ITIL framework, 252–256
automation, 169
Lean IT, 258–263
port-centic to policy-centric design
overusing, 252–253 migration, 158
ITIL framework, 252 standardization and design,
overusing frameworks, 252–253 221–222
visions/strategies (generic), 149 switch upgrades, 169
loopback(), configuration, 191–192
L
lab environments, 179–181, 187
M
LAN (Local Area Networks) manageability of campus networks,
automation, 189–190 29–30
336 management

management NetBrain, 117–118

classic VLAN over SDA topologies, NetDevOps, 34–35
90 NetFlow, 318–320
summaries (action plans), 143 networks
VRF, 90 analytics, 111, 120–121
matching API calls to tools, 219 Ansible, 118–119
maturity level of an organization, application behavior analytics,
138, 145 112–113
ad hoc operations, 138 DNAC Assurance, 113–115
defined/documented processes/ NetBrain, 117–118
responsibilities, 139
network function analytics,
internal control, 139 111–112
intuitive operations, 138 network services availability,
optimization, 139 112
organizational requirements, Prime Infrastructure, 115–117
148–150 trend analysis, 112
quality checks, 139 validation of Intent, 111
questions and related maturity levels, automation, 111, 119–120
140
Ansible, 105–108
repetitive operations, 138
APIC-EM, 100–101
risk management, 139
building automation tools,
version control, 139 109–111
MDT (Model-Driven Telemetry), Cisco DNAC, 97–100
316–318, 320
defined, 95–97
meetings, organizing, 224–225
NSO, 101–103
Meraki, 19–20
Prime Infrastructure, 100–101
microsegmentation, IBN, 83, 93
Puppet Enterprise, 103–105
mobility, trends in, 23–26
campus networks
Mobility Express, 14–15
access port configuration, 135
MSTP (Multiple Spanning Tree
action plans and IBN transi-
Protocol), 310
tions, 143–146
Agile software engineering
N methodology, 33–34
Assurance process, 162–166
NAD (Network Access Devices),
automation, 166–167
RADIUS servers, 293
baselines, 187–199
NED (Network Elements Drivers) and
NSO, 101 classic VLAN, 184–187
 networks 337

Cloud Edge infrastructures, stakeholders and IBN

30–32 transitions, 141–142, 145
cloud infrastructures, 30–32 standardization across
complexity of, 28–29 locations, 137–138
configuration standardization, toolchains, 34–35
160–162 transitioning to IBN. See IBN,
connected devices (IoT/non- transitioning to
user operated devices), trends in, 23–26
26–27 upgrade plans, 151–152
converting intents, 200–202 uplink standardization,
day-0 operations, 169–172 135–136
day-1 operations, 174 visibility, 162–166
day-2 operations, 173 VLAN configuration standard-
day-n operations, 167–169 ization, 136–137
development of, 23–26 VLAN numbering, 159–160
DevOps, 32–34 wired design, 134
digitalization, 35 wireless design, 134–135
extracting intents, 201–202 design, 247–248
hardware inventories, 133–134, digitalization, 35
152 network design, 247–248
inventories, 133, 145, 152 network operation, 248–249
investment plans, 152–155 infrastructure requirements, 151–155
lab environments, 179–181 intents, 79–80
level of standardization, API calls, matching to tools,
134–138, 145, 155 219
lifecycle management, 152–155 concept API definitions, 218
manageability of, 29–30 generalizing, 217–218
NetDevOps, 34–35 identifying, 217
organizational maturity, service catalogs, 219–223
138–140 NAD and RADIUS servers, 293
port-centic to policy-centric operation of, 248–249
design migration, 155–159
overlay networks and classic VLAN,
prioritizing challenges in IBN 186
transitions, 142–143
policy-centric networks, port-
SDA, 181–184 centic to policy-centric design
security, 29 migration, 155–159
shared switch configuration, services, network analytics, 112
135
338 networks

VLAN, 305–308, 311–312, fear of change, 274

319–320 focus, maintaining, 276
VXLAN, 301–302, 319 forward thinking, 277–278, 281
wireless networks governance, 279–280
configuration standardization, incentives, 274–275
161–162
learning stages of a new skill, 272–273
connected devices (IoT/
lifecycle management, 280
non-user operated devices),
26–27 ownership, 281
development of, 23–26 ownership, taking, 278–279
frequency band (unlicensed positivity, 281
spectrum), 26 quid pro quo, 274–275
security, 29 speed of change, 281
trends in, 23–26 stakeholders, 279–280
next-next-finish installations, 157 training, 281
non-user operated devices training/demonstration, 279
connections per capita, 27 organizational maturity, 138,
growth of, 26–27 148–150
NSO (Network Services ad hoc operations, 138
Orchestrator), 101 defined/documented processes/
CDB and, 101–102 responsibilities, 139
NED and, 101 internal control, 139
NTP configuration, 102–103 intuitive operations, 138
schematic overview, 101–102 optimization, 139
YANG and, 101–102 quality checks, 139
NTP (Network Translation Protocol), questions and related maturity levels,
configuration, 102–103, 161 140
repetitive operations, 138

O risk management, 139

version control, 139
open standards, Cisco DNA, 69–70 organizing
optimization (organizational applications, enterprise building
maturity), 139 example (application organiza-
option 43 (DHCP), and PnP, 285–286 tion), 130–132
order pickers, 24 meetings, example of IBN, 224–225
organizational change, 271–272, 281 overlay networks, classic VLAN, 186
challenges, 276–277 ownership, change management,
278–279, 281
communication, 276
failures, 277
 redundancy, handling 339

processes/responsibilities
P (organizational maturity), 139
product/vendor selection, 149
PacketFence, 158
proof of concepts/pilots
pilots/proof of concepts
(communication plans), 222
(communication plans), 222
protocols
playbooks and Ansible, 107
distance-vector routing protocol, 299
PnP (Plug-n-Play), 288, 319
link-state routing protocol, 299–300
APIC-EM and, 284–285
MSTP, 310
day-0 operations, 169–171
routing protocols, 298–300, 319
DHCP option 43, 285–286
RSTP, 310
DNAC and, 286
SNMP, 312–314, 320
Pokemon Go, 215
STP, 308–310
policies
VTP, 311–312, 320
Cisco DNA, 66–67
Puppet Enterprise, 103–105
policy-centric networks, port-
centic to policy-centric design Python and ZTP, 288
migration, 155–159
portals, business-supported apps/
portals (communication plans), 223
Q
ports QoS (Quality of Service), use case,
access port configuration, 135, 28–29
196, 207 quality checks (organizational
port-centic to policy-centric design maturity), 139
migration, 155–159 quid pro quo, change management,
routed ports 274–275
Cisco DNA, 68–69
switchports versus, 68–69 R
shared switch configuration, 135
RACI matrix, 141
switchports
RADIUS,
Cisco DNA, 68–69
RADIUS (Remote Access DialUp
routed ports versus,
Services), 293–295, 319
68–69
IEEE 802.1X, 292–293
uplink port configuration, 196
RADIUS servers, 158
positivity, change management, 281
authorization rules, 157
Prime Infrastructure, 97–100,
115–117, 170 IEEE 802.1X network access
control standard, 196, 205
prioritizing challenges in IBN
transitions, 142–143 redundancy, handling, 16–19
340 repetitive operations (organizational maturity)

repetitive operations (organizational border nodes, 86

maturity), 138 classic VLAN and, 90–91, 183–187
repositories (architecture), 47–48 control nodes, 86
requirements design choices, 88–89
IBN, transitioning to edge nodes, 85–86
matching requirements, 148 example of, 86–88
organizational requirements, fabrics, 85, 87
148–155
LISP, 302–305, 319
organizational requirements, maturity
operation of, 86–88
level of an organization, 148–150
overview of, 84–85
resource availability, 150–151
STP, 185
responsibilities/processes
(organizational maturity), 139 transitioning to, 209–210
RESTful API, Cisco DNA, 71 underlay networks, 85–86
reusability, enterprise architectures, virtual networks, 85
231 VXLAN, 301–302, 319
RFC 2058, RADIUS, 294–295 security
risk management, 139, 149 Cisco DNA, 59–60, 71–73
routed ports compromise, IoC, 223–224
Cisco DNA, 68–69 enterprise building example (applica-
switchports versus, 68–69 tion organization), 131
routing protocols, 298–299, 319 first hop security, 196
distance-vector routing protocol, 299 IBN, 204
link-state routing protocol, 299–300 IEEE 802.1X network access
control standard, 205–208
routing (underlay), configuration, 192
risks, 209
RSTP (Rapid Spanning Tree Protocol),
310 scalability, 210
Scalable Group Tags, 208–209

S training, 210–211
transitioning to SDA, 209–210
SBB (Solution Building Blocks), 47 incident response example,
scalability, extended IBN security, 223–224
210 IoC, 223–224
Scalable Group Tags. See SGT networks, 29
SDA (Software-Defined Access), 84, servers (RADIUS), 293
181–184, 284 service catalogs (network intents),
baselines, 188–189 219–220
LAN automation, 189–190 business-supported apps/portals, 223
manual configuration, 190–193 pilots/proof of concepts, 222
 successes 341

sharing successes/failures, 221–222 speed of change, change management,

understanding a business, 222 281
serviceability, enterprise SSH (Secure Shell), asymmetric SSH
architectures, 231 key authentication and Ansible,
106–107
SGT (Scalable Group Tags), 295–298,
319 SSID (Service Set Identifiers), VLAN
configuration standardization, 136
classic VLAN, 185
stakeholders
extended IBN, 208–209
change management, 279–280
shared switch configuration, 135
IBN, transitioning to, 141–142, 145
SharedService Group use case, 28–29
RACI matrix, 141
Cisco DNAC Assurance, 163–166
standardization
datacenter automation, 110–111
access switch configuration,
digitalization, IT proactive support
160–161
of business, 240
benefits of, 221
DNAC Assurance, 163–165
design and, 221
IT operation frameworks, overusing,
252–253 distribution switch configuration,
161
lab environments, 187
global (generic) configuration,
lifecycle management, 153
160–162
port-centic to policy-centric design
level of, 134–138, 145, 155
migration, 158
across locations, 137–138
Scalable Group Tags, 208–209
uplinks, 135–136
virtualizing network functions, 61
VLAN, 136–137, 161–162
VLAN configuration standardization,
136 wireless network configuration,
161–162
single switch topologies, 9–10
storage, repositories (architecture),
skills, learning stages of new, 272–273
47–48
slow change, change management, 281
STP (Spanning Tree Protocol),
small switches, topology of, 308–309 308–310, 320
SNMP (Simple Network Management classic VLAN over SDA topologies,
Protocol), 312–314, 320 90
software drawbacks, 16–17
Agile software engineering method- SDA and, 185
ology, 33–34
uplinks, blocking, 16–17
Cisco DNA, 66–67
successes
inventories, 133, 152
chance of success, prioritizing chal-
SDA, 181–184 lenges in IBN transitions, 142
Spanning Tree Protocol. See STP communication plans, sharing, 223
342 supplicants (IEEE 802.1X)

supplicants (IEEE 802.1X), 291 ADM, 43

SWIM (SoftWare Image phases of, 43–45
Management), 167 requirements management, 45
switches application architectures, 42
access switches aspects of, 40–41
configuration, 125–126 building blocks, 46–47
configuration standardization, business architectures, 41–42
160–161
data architectures, 42
automating upgrades, 169
technology architectures, 42–43
distribution switches
toolchains, 34–35
configuration, 124, 126
topologies
configuration standardization,
collapsed core/two-tier topologies,
161
8–9
VRF-Lite distribution switches,
lab topologies, 180–181
184
single switch topologies, 9–10
shared switch configuration, 135
small switches, 308–309
small switches, topology of, 308–309
three-tier topologies, 6–8
upgrading, 169
training
VRF-Lite distribution switches, 184
change management, 279, 281
switchports
extended IBN, 210–211
Cisco DNA, 68–69
Translation process (IBN), 82
routed ports versus, 68–69
trend analysis, network analytics, 112
Syslog, 161, 314–316, 320
tunnels (CAPWAP), 10–11
two-tier/collapsed core topologies,
T 8–9, 89–90

technology architectures, 42–43,

230–231 U
templates
UDLD (Unidirectional Link
bootstrap templates, 170–172
Detection), 18
classic VLAN, 186
underlay networks, SDA, 85–86
three-tier topologies, 6–8
underlay routing, configuration, 192
time (prioritizing challenges in IBN
understanding a business
transitions), 142
(communication plans), 222
timelines (action plans), estimated,
unlicensed spectrum (frequency
144–145
band), 26
TOGAF® (The Open Group
upgrade plans, 151–152
Architecture Framework),
39–41, 48 upgrading switches, 169
 VLAN (Virtual Local Area Networks) 343

uplinks datacenter automation,

blocking, 16–17 110–111
port configuration, 196 DNAC Assurance, 163–165
standardization, level of, 135–136 IT proactive support of
business, 240
use cases
lab environments, 187
App-Credits use case, 225
lifecycle management, 153
automation, 173
overusing IT operation
CiscoLive Europe use case,
frameworks, 252–253
Intent-based API, 215–216
port-centic to policy-centric
configuration and automation, 173
design migration, 158
examples of IBN, 223
Scalable Group Tags, 208–209
authorized access, 225–226
virtualizing network functions,
incident response security, 61
223–224
VLAN configuration standard-
organizing meetings, 224–225 ization, 136
FinTech Ltd. use case, 25
automation, 64
choosing IBN technologies, 186
V
communication and focus in validated designs, 3
change management, 276 vendor/product selection, 149
DIY architectures, 49 version control (organizational
extracting intents, 201–202 maturity), 139
incident response security, 223–224 virtual networks, SDA, 85
LogiServ Inc. use case visibility, transitioning to IBN,
automation, 169 162–166
port-centic to policy-centric VLAN (Virtual Local Area Networks),
design migration, 158 305–308, 319
standardization and design, authorization rules, 157–158
221–222 classic VLAN, 184–187
switch upgrades, 169 automation, 185
organizing meetings, 224–225 baselines, 193–199
QoS, 28–29 IBN and, 88–91
quid pro quo, change management, Layer 2 intents, 185
275 overlay networks, 186
SharedService Group use case, Scalable Group Tags, 185
28–29
SDA and, 183–187
Cisco DNAC Assurance,
SDA topologies, 90–91
163–166
344 VLAN (Virtual Local Area Networks)

templates, 186 AP, 10–11

testing, 186 CAPWAP tunnels, 10–11
VRF-Lite distribution switches, central controller with
184 central breakout deployments,
configuration standardization, 12–13
136–137, 161–162 FlexConnect deployments,
dynamic VLAN, border nodes, 190 13–14
management VLAN, classic VLAN configuration standardization,
over SDA topologies, 90 161–162
numbering, 159–160 connected devices (IoT/non-user
VTP, 311–312, 320 operated devices)
VNF (Virtualize Network Functions), connections per capita, 27
60–61 growth of, 26–27
vPC (Virtual PortChannel), 17–19 development of, 23–26
VRF (Virtual Routing and frequency band (unlicensed
Forwarding), classic VLAN over spectrum), 26
SDA topologies, 90 local controller with local breakout
VRF-Lite (Virtual Routing and deployments, 13
Forwarding-Lite), 184, 289–290, Mobility Express, 14–15
319
security, 29
VSS (Virtual Switching Solutions)
trends in, 23–26
redundancy, handling, 17–19
WLC, 10
teardowns, 180–181
WLC (Wireless LAN Controllers), 10
VTP (VLAN Trunking Protocol),
311–312, 320
VXLAN (Virtual eXtensible Local Y
Area Networks), 301–302, 319
YAML (YAML Ain’t Markup
Language), playbooks and Ansible,
W 107
YANG (Yet Another Next Generation)
WAN (Wide-Area Networks), and NSO, 101–102
enterprise building example
(application organization), 131
wired design, campus networks, 134 Z
wireless controllers, Cisco DNAC
ZTP (Zero Touch Provisioning), 288
Assurance, 166
DHCP and, 287–288
wireless design, campus networks,
134–135 operational flow of, 287–288
wireless networks, 11, 15 Python and, 288
anchor controller deployments, 15