Transforming Campus Networkingptgmedia.pearsoncmg.com/images/9780135466339/...Network Automation 119...

http://www.facebook.com/share.php?u=http://www.informIT.com/title/9780135466339

http://twitter.com/?status=RT: download a free sample chapter http://www.informit.com/title/9780135466339

https://plusone.google.com/share?url=http://www.informit.com/title/9780135466339

http://www.linkedin.com/shareArticle?mini=true&url=http://www.informit.com/title/9780135466339

http://www.stumbleupon.com/submit?url=http://www.informit.com/title/9780135466339/Free-Sample-Chapter

Transforming Campus Networks to Intent-Based Networking

Pieter-Jan Nefkens

Cisco Press221 River Street

Hoboken, NJ 07030 USA

ii Transforming Campus Networks to Intent-Based Networking

Transforming Campus Networks to Intent-Based NetworkingPieter-Jan Nefkens

Copyright© 2020 Cisco Systems, Inc.

Published by:

Cisco Press221 River StreetHoboken, 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

http://www.pearson.com/permissions

iv Transforming Campus Networks to Intent-Based Networking

CreditsFigure 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

ContentsIntroduction 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



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 AuthorPieter-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 astrong 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 ReviewersDenise 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

DedicationsI 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

AcknowledgmentsI 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 ConventionsThe 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

IntroductionIntent-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 OrganizedThis 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.

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

Intent-Based Networking

Chapter 5

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 cut.

Take the mower out of the garage, connect it to power, pull cord to 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 dinner party.

Invite friends, prepare dinner as much as possible ahead of time, clean 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 car.

Check whether enough fuel is in the car; if not, drive to the nearest gas station and fill up the tank; start driving.

This sales order needs to be shipped.

Check the stock for this order, search each item in warehouse, pick the required items of the sales order, place them in a box, print the packing 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 to replace fire-walls.

Prepare a budget proposal for the CFO explaining why replacement is required, present the proposal, wait for approval, request quotes, pro-cure hardware, execute project to replace firewalls in production.

What Is Intent? 79


This car needs to be assembled.

Procure all required parts, components, and implementation details; 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 the code on the network switch.

Determine the new version of the software, upgrade the test environ-ment with the new version, execute tests to check if the new version 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


I have a telepres-ence session at 10:00 a.m.

Create an HD video session to the remote peer, create the required end-to-end Quality of Service parameters for this specific session, 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 migrating to the cloud.

Take the existing access policy for that application from the datacen-ter policy, transform the policy into an application policy for Internet access, deploy the policy on all perimeter firewalls, and change routing for that application to the cloud.

This new IoT application needs to be enabled.

Create a new logical compartment on the network, create an IP-space, set up Internet access policies, create access policies to recognize the IoT devices, and assign them to the logical compartment.

This application needs access to HR systems during salary runs.

Once the user starts the run, request access to system via the network, open the required ports and IP addresses for the device that user is connected with via an access policy, wait until salary run is finished, remove the temporary access policies, and clear the open connections.

Potential malware has been found on a device.

Reallocate the device to an investigate policy that includes in-depth monitoring of traffic and host isolation, execute a Change-of-Authorization to place the device in the new policy, notify security and administrator of a possible incident, and await investigation.


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 PerspectiveIBN 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.

1. Request an intent 6. Intent-based feedback

2. Requeststeps

5. Validation andmetrics

3. Execution ofconfiguration changes

4. Network-driven feedback(config and telemetry)

Business

Translation

Activationtranslates steps into

configuration.

Assurancevalidates intent based onfeedback 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.


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


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 DesignsIntent-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.


■ 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


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.

Edge Node(Access Switch)

Virtual Network Red(Overlay)

ClientVN Green

ClientVN Red

Virtual Network Green(Overlay)

Edge Node(Access Switch)

ControlNode

Fabric(Underlay Network)

Border Node(Distribution Switch)

ExternalNetwork

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


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(209.165.200.225)

CSW1Border and

Control Node

Internet

SW2Edge Node

PC110.0.0.4

PC210.0.0.5

VN Green: 10.0.0.0/24

.1

.5.6

.2192.168.0.0/30

192.168.0.4/30

SW1Edge Node

Figure 5-3 Sample SDA Network

http://www.myserver.com


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.




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.


Table 5-4 Overview of Design Choices for SDA and Campus Alternative

SDA Network Classic Campus Network

Endpoints are, based on identity, assigned to a virtual network and an SGT.

Endpoints are assigned to a VLAN and SGT.

Each virtual network has its own routing table and IP space.

VRF-Lite can be used to logically separate IP networks and have each VRF instance its own routing table.

The provisioning of virtual networks is easy because the underlay is created only once and virtual networks can be added and removed without interrupting the underlay.

With automation tools, it is easy to program-matically add and remove VLANs on uplinks as well as SVIs on the distribution switch.

Routed links in the underlay are used to remove Spanning Tree and Layer 2 com-plexities.

In a collapsed-core campus network, there is no need for Spanning Tree, or a single Spanning Tree instance can be run to prevent loops.

An underlay network is used to stretch a fabric over multiple physical locations.

This is not possible without an encapsulation protocol in classic networks.

A control node is used for lookup of end-points.

This is not required as existing protocols like 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(209.165.200.225)

Interface VLAN201vrf forwarding greenip address 10.0.0.1 255.255.255.0ip route vrf green 0.0.0.0.0.0.0.0 gateway

DSW1

Internet

SW2

PC110.0.0.4

VLAN

201

VLAN

201PC2

10.0.0.5

PortChannelAllowed VLANs: 100,201

PortChannelAllowed VLANs: 100,201

SW1

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



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.

SummaryCisco 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


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).

1. Request an intent 6. Intent-based feedback

2. Requeststeps

5. Validation andmetrics

3. Execution ofconfiguration changes

4. Network-driven feedback(config and telemetry)

Business

Translation

Activationtranslates steps into

configuration.

Assurancevalidates intent based onfeedback 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

AABB (Architecture Building Blocks), 47

access (authorized), example of IBN, 225–226

access layer, 4

access port configuration, 135, 196, 207

access requests, architecture frameworks, 233–235

access switches

configuration, 125–126, 160–161

failures, 4–5

accounting, RADIUS, 293

action plans, 143, 146

action lists, 144

analysis, 144

decision lists, 144

estimated timelines, 144–145

management summaries, 143

Activation process (IBN), 81

ad hoc operations (organizational maturity), 138

ADM (Architecture Development Method), 43

phases of, 43–45

requirements management, 45

Agile software engineering methodology, 33–34

analysis (action plans), 144

analytics, 312

application behavior analytics, 112–113

architecture frameworks, 232

Cisco DNA, 59, 65–66

MDT, 316–318, 320

NetFlow, 318–320

network analytics, 111, 120–121

Ansible, 118–119


DNAC Assurance, 113–115

NetBrain, 117–118

network function analytics, 111–112

network services availability, 112

322 analytics

Prime Infrastructure, 115–117

trend analysis, 112

validation of Intent, 111


SNMP, 312–314, 320

Syslog, 314–316, 320

anchor controller deployments, 15

Ansible

component overview of, 105–106, 108

control engine, 106

control tower, 107–108

network analytics, 118–119

network automation, 105–108

playbooks, 107

AP (Access Points), 10–11

AR and, 216

CAPWAP tunnels, 10–11

Mobility Express, 14–15

API (Application Program Interface)

calls, matching to tools, 219

Cisco DNA, 70–71

concept API definitions, 218

definitions, 218

Intent-based API, 215–217

network intents

API calls, matching to tools, 219


generalizing, 217–218

identifying, 217

service catalogs, 219–223

Prime Infrastructure, 116


APIC-EM (Application Policy Infrastructure Controller-Enterprise Module), 100–101

day-0 operations, 169–171

PnP, 284–285

App-Credits use case, 225

applications

architectures, 42, 230

behavior analytics, 112–113

business-supported apps/portals (communication plans), 223

enterprise building example (applica-tion organization), 130–132

AR (Augmented Reality), 215–216

architecture frameworks, 231–232

application architectures, 230

benefits of, 38–39

building blocks, 231

business architectures, 230

change, possibility of, 231

Cisco DNA, 51

analytics, 59, 65–66

API, 70–71

automation, 58, 62–65

Cisco DNA-ready infrastruc-tures, 68–69

cloud service management, 57–58

conceptual overview of, 56–57

design principles, 60–73

identity, 58–59

infrastructure, 59

open standards, 69–70

overview of Cisco solutions, 73–74

policies, 66–67

requirements, 51–56

RESTful API, 71

routed ports, 68–69

security, 59–60, 71–73

software, 66–67

switchports, 68–69

VNF, 60–61

automation 323

data architectures, 230

defined, 37–39

digitalization, 246–247

DIY architectures, 49

drawbacks of, 39

enterprise architectures

drawbacks of, 39

guidelines/principles, 46

flexibility, 231

IBN, impact of, 232

access requests, 233–235

analytics, 232

automation, 232

Cloud Service Management, 232

infrastructure, 232–235

implementation of, 231

layered approach of, 229–230

overview of, 48–49

repositories, 47–48

reusability, 231

serviceability, 231

technology architectures, 230–231

TOGAF®, 39–41, 48

ADM, 43–45


aspects of, 40–41

building blocks, 46–47

business architectures, 41–42



Assurance process, 81–82, 162–166

asymmetric SSH key authentication and Ansible, 106–107

authentication

asymmetric SSH key authentication and Ansible, 106–107

IEEE 802.1X network access control standard, 291–293

RADIUS, 293

Authentication Server (IEEE 802.1X), 291

Authenticator (switch), IEEE 802.1X, 291

authorization

IBN, authorized access, 225–226

RADIUS, 157, 293

VLAN, 157–158

Autoconf, 207

automation, 174


build pipelines, 33

Cisco DNA, 58, 62–65

classic VLAN, 90–91, 185

configuration changes, 173


day-1 operations, 174


day-n operations, 167–169

IBN, transitioning to, 166–167

LAN, 189–190

network automation, 111, 119–120

Ansible, 105–108

APIC-EM, 100–101

Cisco DNAC, 97–100

custom-built automation tools, 109–111

defined, 95–97

NSO, 101–103


Puppet Enterprise, 103–105

324 automation

SWIM, 167

switch upgrades, 169

availability of resources, 150–151

Bbaselines, 187–188

classic VLAN, 193–199

SDA, 188–189

LAN automation, 189–190

manual configuration, 190–193

bootstrap templates, 170–172

border nodes

dynamic VLAN, 190

SDA, 86

BPDU (Bridge Protocol Data Unit) packets, 16–17

BPDU Guard, 17–18

breakouts

central controller with

central breakout deployments, 12–13

FlexConnect deployments, 13–14

local controller with local breakout deployments, 13

budget (prioritizing challenges in IBN transitions), 142

build pipelines (automated), 33

building blocks (architecture frameworks), 46–47, 231

business

architectures, 41–42, 230

communication plans 222

processes and digitalization, 238

supported apps/portals (communica-tion plans), 223

Ccalls (API), matching to tools, 219

campus networks


Cloud Edge infrastructures, 30–32

cloud infrastructures, 30–32

cloud-managed networks, 19–20

collapsed core/two-tier topologies, 8–9

complexity of, 28–29

connected devices (IoT/non-user operated devices), 26–27

development of, 23–26

DevOps, 32–34

digitalization, 35

functional layers, 4

access layer, 4

core layer, 5–6

distribution layer, 4–5

hardware, inventories, 133–134, 152

IBN, transitioning to, 129

access port configuration, 135

action plans, 143–146

Assurance process, 162–166

automation, 166–167

baselines, 187–199

challenges to day-to-day operations, 129–132, 145

change procedures, 149


configuration standardization, 160–162

converting intents, 200–202



central controller with 325



design/configuration documen-tation, 149

disaster recovery, 149

enterprise building example (application organization), 130–132

extracting intents, 201–202

generic IT visions/strategies, 149

incident management, 149

inventories, 132–134, 145, 152

investment plans, 152–155

lab environments, 179–181, 187

level of standardization, 134–138, 141–142, 145, 155

lifecycle management, 149, 152–155

matching requirements, 148

network infrastructure requirements, 151–155

organizational maturity, 138–140, 145

organizational requirements, 148–155

port-centic to policy-centric design migration, 155–159

prioritizing challenges, 142–143

resource availability, 150–151

risks of, 149, 174–176

SDA, 181–184

shared switch configuration, 135

standardization across locations, 137–138

upgrade plans, 151–152

uplink standardization, 135–136

vendor/product selection, 149

visibility, 162–166

VLAN configuration standard-ization, 136–137

VLAN numbering, 159–160

wired campus design, 134

wireless campus design, 134–135

manageability of, 29–30

NetDevOps, 34–35

redundancy, handling, 16–19

security, 29


single switch topologies, 9–10

software, inventories, 133, 152

three-tier topologies, 6–8

toolchains, 34–35

trends in, 23–26

wired design, 134

wireless design, 134–135

CAPWAP (Control and Provisioning of Wireless Access Points) tunnels, 10–11

catalogs, network intents service, 219–220

business-supported apps/portals, 223

pilots/proof of concepts, 222

sharing successes/failures, 221–222

understanding a business, 222

CDB (Configuration Database) and NSO, 101–102




326 challenges

challenges

change management, 276–277

day-to-day operations, 129–132, 145

prioritizing in IBN transitions, 142–143

chance of success (prioritizing challenges in IBN transitions), 142

change

change management, 271–272, 281

challenges, 276–277

communication, 276

failures, 277

fear of change, 274

focus, maintaining, 276

forward thinking, 277–278, 281

governance, 279–280

incentives, 274–275

learning stages of a new skill, 272–273

lifecycle management, 280

ownership, 281

ownership, taking, 278–279

positivity, 281

quid pro quo, 274–275

speed of change, 281

stakeholders, 279–280

training, 281

training/demonstration, 279

enterprise architectures, 231

procedures, 149

CICD (Continuous Integration/Continuous Delivery), 33–34

Cisco Design Thinking Framework, 243–245

Cisco DNA (Digital Network Architecture), 51, 77. See also IBN


API, 70–71



analytics, 232

automation, 232







functions of, 213–214

identity, 58–59

infrastructures, 59, 68–69



policies, 66–67


RESTful API, 71


security, 59–60, 71–73

software, 66–67


VNF, 60–61

Cisco DNAC (DNA Center), 97–100

API, 215



SDA, 182–183

CiscoLive Europe intent API use case, 215–216

classic VLAN (Virtual Local Area Networks), 184

automation, 185


IBN and, 88–91

Layer 2 intents, 185

configuration 327

overlay networks, 186

Scalable Group Tags, 185

SDA and, 183–187

SDA topologies, 90–91

templates, 186

testing, 186

VRF-Lite distribution switches, 184


cloud

Cloud Service Management


Cisco DNA, 57–58

infrastructures, 30–32

networks, 19–20

COBIT (Control Objectives for Information and related Technologies), 138

ad hoc operations, 138

defined/documented processes/responsibilities, 139

framework summary, 139–140

internal control, 139

intuitive operations, 138

optimization, 139

quality checks, 139

repetitive operations, 138

risk management, 139

version control, 139

collapsed core/two-tier topologies, 8–9, 89–90

commitment (prioritizing challenges in IBN transitions), 142

communication

change management, 276

plans, 221–222

business-supported apps/ portals, 223


successes/failures, sharing, 221–222


complexity of campus networks, 28–29

compromise, IoC, 223–224


configuration

access port configuration, 135, 196

access switches, 125–126, 160–161

automation and configuration changes, 173

CDB and NSO, 101–102

design/configuration documentation, 149

distribution switches, 124, 126, 161

generic (global) configuration, shared switch configuration, 135

global (generic) configuration, standardization, 160–162

Layer 3 configuration, shared switch configuration, 135

links, 191

loopback(), 191–192

NTP, 161

ports, shared switch configuration, 135

SDA baselines, 190–193


Syslog, 161

underlay routing, 192

uplink port configuration, 196

VLAN, 136–137, 161–162

wireless networks, 161–162

328 connected devices (IoT/non-user operated devices)

connected devices (IoT/non-user operated devices)

connections per capita, 27

growth of, 26–27

control (internal), organizational maturity, 139

control nodes, SDA, 86

controllers


central controller with central breakout deployments, 12–13


wireless controllers, Cisco DNAC Assurance, 166

core layer, 5–6

CSI (Continual Service Improvement), 255–256


CVD (Cisco Validated Designs), 3

Ddata architectures, 42, 230





day-to-day operations, challenges to, 129–132, 145

defined/documented processes/responsibilities (organizational maturity), 139

demonstration/training, change management, 279

deployments, wireless networks, 15







design

Design Thinking, 242–245

documentation, 149, 221

network design, 247–248

DevOps, 32–35, 257–258

DHCP (Dynamic Host Configuration Protocol)

DHCP option 43, PnP, 285–286

enterprise building example (applica-tion organization), 131

LAN automation, 190

PnP


DHCP option 43, 285–286

ZTP and, 287–288


business processes, 238

defined, 237–238

enterprise architectures, 246–247

IBN and, 245–246

model of, 238–239

organizational impact, 246



network operation, 248–249

stages of, 239, 241

business and IT alignment, 239

IT as business enabler, 240

IT change business processes, 241

enterprise architectures 329

IT proactive support of business, 240–241


distance-vector routing protocol, 299

distribution layer, 4

distribution switches

configuration, 124, 126, 161


DIY enterprise architectures, 49

DNA (Digital Network Architecture), 51, 77. See also IBN


API, 70–71



analytics, 232

automation, 232







functions of, 213–214

identity, 58–59

infrastructures, 59, 68–69



policies, 66–67


RESTful API, 71


security, 59–60, 71–73

software, 66–67


VNF, 60–61

DNAC (DNA Center), 97–100

API, 215



PnP, 286

SDA, 182–183

DNS (Domain Name System), enterprise building example (application organization), 131

documentation

design/configuration documentation, 149, 221

organizational maturity, 139

dynamic VLAN (Virtual Local Area Networks), border nodes, 190

Eedge nodes, SDA, 85–86









drawbacks of, 39

flexibility, 231






reusability, 231

serviceability, 231


330 enterprise architectures

TOGAF®, 39–40, 48

ADM, 43–45


aspects of, 40–41





enterprise building example (application organization), 130–132

estimated timelines (action plans), 144–145

Ethernet and STP, 308–310, 320

examples of IBN (Intent-Based Networking), 223

authorized access, 225–226

incident response security, 223–224

organizing meetings, 224–225

extended IBN (Intent-Based Networking)

locations, 202–203

security, 204


risks, 209

scalability, 210

Scalable Group Tags, 208–209

training, 210–211

transitioning to SDA, 209–210

Ffabrics, SDA, 85, 87

failures

access switches, 4–5

change management, 277

communication plans, sharing, 223

fear of change, 274

FinTech Ltd. use case, 25

automation, 64

communication and focus in change management, 276


IBN technologies, choosing, 186

intents, extracting, 201–202

first hop security, 196

FlexConnect, central controller with FlexConnect deployments, 13–14

flexibility, enterprise architectures, 231

focus, maintaining in change management, 276

forward thinking, change management, 277–278, 281

frameworks (architecture), 231–232


benefits of, 38–39




Cisco Design Thinking Framework, 243–245

Cisco DNA, 51


API, 70–71


Cisco DNA-ready infrastruc-tures, 68–69




identity, 58–59

infrastructure, 59


human change 331


policies, 66–67


RESTful API, 71


security, 59–60, 71–73

software, 66–67


VNF, 60–61


defined, 37–39



drawbacks of, 39

enterprise architectures

drawbacks of, 39


flexibility, 231

IBN, impact of, 232


analytics, 232

automation, 232




IT operations frameworks, 263

CSI in ITIL framework, 255–256

DevOps, 257–258

ITIL framework, 252–256

Lean IT, 258–263

overusing, 252–253

ITIL framework, 252




reusability, 231

serviceability, 231


TOGAF®, 39–41, 48

ADM, 43–45


aspects of, 40–41





frequency band (unlicensed spectrum), 26

functional layers, 4

access layer, 4

core layer, 5–6

distribution layer, 4–5

Ggeneric (global) configuration


standardization, 160–162


governance in change management, 279–280

Hhardware, inventories, 133–134, 152

human change, 271–272, 281


communication, 276

failures, 277

fear of change, 274



332 human change



ownership, 281


positivity, 281



training, 279, 281

IIBN (Intent-Based Networking), 77,

213–215). See also Cisco DNA

Activation process, 81

API, 215–217

calls, matching to tools, 219


definitions, 218

generalizing network intents, 217–218

identifying network intents, 217

network Intent service catalogs, 219–223

architecture frameworks, IBN impact on, 232


analytics, 232

automation, 232



Assurance process, 81–82, 162–166



design requirements, 83–84

digitalization and, 245–246

enterprise building example (applica-tion organization), 130–132

examples of, 223




extended IBN

locations, 202–203

security, 204–211

feedback

intent-based feedback, 82

network-driven feedback, 81–84, 93

intent

defined, 78–80

example of, 78

intent-based feedback, 82

network-based intents, 79–80


requesting, 81

metrics, 82

microsegmentation, 83, 93

network analytics, 111, 120–121

Ansible, 118–119



NetBrain, 117–118




trend analysis, 112


IBN (Intent-Based Networking) 333

network automation, 111, 119–120

Ansible, 105–108

APIC-EM, 100–101



defined, 95–97

NSO, 101–103



network-based intents, 79–80

perspective, 80–83

policy-centric networks, 83, 93

SDA, 84, 91

border nodes, 86

classic VLAN over SDA topologies, 90–91

control nodes, 86

design choices, 88–89

edge nodes, 85–86

example of, 86–88

fabrics, 85, 87

operation of, 86–88


underlay networks, 85–86

virtual networks, 85

security, IEEE 802.1X network access control standard, 205–208

systematic approach to networks, 80

transitioning to, 129


action plans, 143–146




challenges to day-to-day opera-tions, 129–132, 145

change procedures, 149








design/configuration documentation, 149




incident management, 149

inventories, 132–134, 145, 152


lab environments, 179–181, 187

level of standardization, 134–138, 141–142, 145, 155

lifecycle management, 149, 152–155


network infrastructure require-ments, 151–155

organizational maturity, 138–140, 145



prioritizing challenges, 142–143



risks of, 174–176

SDA, 181–184

334 IBN (Intent-Based Networking)



tips for success. See change management





VLAN configuration standardization, 136–137


wired campus design, 134

wireless campus design, 134–135

Translation process, 82

validation, 82


identity, Cisco DNA, 58–59

IEEE 802.1b, 23

IEEE 802.1X network access control standard, 156–157, 290–291, 319


authentication process, 291–293

Authentication Server, 291

Authenticator (switch), 291

components of, 291–292

IBN security, 205–208

RADIUS, 196, 205, 292–293

supplicants, 291

implementation of enterprise architectures, 231

incentives, change management, 274–275

incidents

management, 149

response security, example of IBN, 223–224

infrastructure

architecture frameworks, 232–235

Cisco DNA, 59

Prime Infrastructure, 97–100, 115–117, 170

requirements (networks), 151–155

installations (next-next-finish), 157

intent API (Application Program Interface), 215–217

Intent-Based Networking. See IBN

intents

IBN, transitioning to



Layer 2 intents, classic VLAN, 185

network intents




identifying, 217


internal control (organizational maturity), 139

intuitive operations (organizational maturity), 138

inventories, transitioning to IBN, 132–134, 145, 152


IoC (Indication of Compromise), 223–224

IoT (Internet of Things), growth of, 27

IP address pools, LAN automation, 189–190

IPv6, first hop security, 196

manageability of campus networks 335

ISE (Identity Services Engine), 157

port-centic to policy-centric design migration, 159

SDA, 183

IS-IS, underlay routing configuration, 192

IT operations

conflicts/recommendations

changing design patterns, 264, 268

management by exception, 265–266, 268–269

organizational change, 266–267, 270

working across domains, 266, 269–270

digitalization

business and IT alignment, 239

IT as business enabler, 240

IT change business porcesses, 241

IT proactive support of business, 240–241

frameworks, 263

CSI in ITIL framework, 255–256

DevOps, 257–258

ITIL framework, 252–256

Lean IT, 258–263

overusing, 252–253

ITIL framework, 252

overusing frameworks, 252–253

visions/strategies (generic), 149

Llab environments, 179–181, 187

LAN (Local Area Networks)



VLAN, 305–308, 319

VXLAN, 301–302, 319

Layer 2 intents, classic VLAN, 185

Layer 2 networks, redundancy, handling, 16–17

Layer 3 configuration, shared switch configuration, 135

Layer 3 networks, redundancy, handling, 17

Lean IT, 258–263


LEI (Lean Enterprise Institute), 259

lifecycle management, 149, 152–155, 280

links, configuration, 191

link-state routing protocol, 299–300

LISP (Locator/Identifier Separation Protocol), 302–305, 319

lists

action lists, 144

decision lists, 144


locations, extended IBN, 202–203

LogiServ Inc. use case

automation, 169


standardization and design, 221–222


loopback(), configuration, 191–192

Mmanageability of campus networks,

29–30

336 management

management

classic VLAN over SDA topologies, 90

summaries (action plans), 143

VRF, 90

matching API calls to tools, 219

maturity level of an organization, 138, 145





optimization, 139


quality checks, 139

questions and related maturity levels, 140




MDT (Model-Driven Telemetry), 316–318, 320

meetings, organizing, 224–225

Meraki, 19–20

microsegmentation, IBN, 83, 93

mobility, trends in, 23–26


MSTP (Multiple Spanning Tree Protocol), 310

NNAD (Network Access Devices),

RADIUS servers, 293

NED (Network Elements Drivers) and NSO, 101

NetBrain, 117–118

NetDevOps, 34–35

NetFlow, 318–320

networks

analytics, 111, 120–121

Ansible, 118–119



NetBrain, 117–118




trend analysis, 112



Ansible, 105–108

APIC-EM, 100–101

building automation tools, 109–111


defined, 95–97

NSO, 101–103



campus networks


action plans and IBN transi-tions, 143–146






networks 337


cloud infrastructures, 30–32

complexity of, 28–29









DevOps, 32–34

digitalization, 35


hardware inventories, 133–134, 152

inventories, 133, 145, 152


lab environments, 179–181

level of standardization, 134–138, 145, 155

lifecycle management, 152–155

manageability of, 29–30

NetDevOps, 34–35

organizational maturity, 138–140


prioritizing challenges in IBN transitions, 142–143

SDA, 181–184

security, 29


stakeholders and IBN transitions, 141–142, 145


toolchains, 34–35

transitioning to IBN. See IBN, transitioning to

trends in, 23–26




VLAN configuration standard-ization, 136–137


wired design, 134

wireless design, 134–135

design, 247–248

digitalization, 35


network operation, 248–249

infrastructure requirements, 151–155

intents, 79–80




identifying, 217


NAD and RADIUS servers, 293


overlay networks and classic VLAN, 186

policy-centric networks, port-centic to policy-centric design migration, 155–159

services, network analytics, 112

338 networks

VLAN, 305–308, 311–312, 319–320

VXLAN, 301–302, 319

wireless networks





security, 29

trends in, 23–26

next-next-finish installations, 157

non-user operated devices


growth of, 26–27

NSO (Network Services Orchestrator), 101

CDB and, 101–102

NED and, 101

NTP configuration, 102–103

schematic overview, 101–102

YANG and, 101–102

NTP (Network Translation Protocol), configuration, 102–103, 161

Oopen standards, Cisco DNA, 69–70

optimization (organizational maturity), 139

option 43 (DHCP), and PnP, 285–286

order pickers, 24

organizational change, 271–272, 281


communication, 276

failures, 277

fear of change, 274



governance, 279–280




ownership, 281


positivity, 281



stakeholders, 279–280

training, 281

training/demonstration, 279

organizational maturity, 138, 148–150





optimization, 139

quality checks, 139

questions and related maturity levels, 140




organizing

applications, enterprise building example (application organiza-tion), 130–132

meetings, example of IBN, 224–225

overlay networks, classic VLAN, 186

ownership, change management, 278–279, 281

redundancy, handling 339

PPacketFence, 158

pilots/proof of concepts (communication plans), 222

playbooks and Ansible, 107

PnP (Plug-n-Play), 288, 319

APIC-EM and, 284–285


DHCP option 43, 285–286

DNAC and, 286

Pokemon Go, 215

policies

Cisco DNA, 66–67

policy-centric networks, port-centic to policy-centric design migration, 155–159

portals, business-supported apps/portals (communication plans), 223

ports

access port configuration, 135, 196, 207


routed ports

Cisco DNA, 68–69

switchports versus, 68–69


switchports

Cisco DNA, 68–69

routed ports versus, 68–69

uplink port configuration, 196

positivity, change management, 281

Prime Infrastructure, 97–100, 115–117, 170

prioritizing challenges in IBN transitions, 142–143

processes/responsibilities (organizational maturity), 139

product/vendor selection, 149

proof of concepts/pilots (communication plans), 222

protocols



MSTP, 310

routing protocols, 298–300, 319

RSTP, 310

SNMP, 312–314, 320

STP, 308–310

VTP, 311–312, 320


Python and ZTP, 288

QQoS (Quality of Service), use case,

28–29

quality checks (organizational maturity), 139

quid pro quo, change management, 274–275

RRACI matrix, 141

RADIUS,

RADIUS (Remote Access DialUp Services), 293–295, 319

IEEE 802.1X, 292–293

RADIUS servers, 158

authorization rules, 157

IEEE 802.1X network access control standard, 196, 205


340 repetitive operations (organizational maturity)

repetitive operations (organizational maturity), 138

repositories (architecture), 47–48

requirements

IBN, transitioning to



organizational requirements, maturity level of an organization, 148–150


responsibilities/processes (organizational maturity), 139

RESTful API, Cisco DNA, 71

reusability, enterprise architectures, 231

RFC 2058, RADIUS, 294–295

risk management, 139, 149

routed ports

Cisco DNA, 68–69

switchports versus, 68–69

routing protocols, 298–299, 319



routing (underlay), configuration, 192

RSTP (Rapid Spanning Tree Protocol), 310

SSBB (Solution Building Blocks), 47

scalability, extended IBN security, 210

Scalable Group Tags. See SGT

SDA (Software-Defined Access), 84, 181–184, 284


LAN automation, 189–190

manual configuration, 190–193

border nodes, 86

classic VLAN and, 90–91, 183–187

control nodes, 86

design choices, 88–89

edge nodes, 85–86

example of, 86–88

fabrics, 85, 87

LISP, 302–305, 319



STP, 185

transitioning to, 209–210

underlay networks, 85–86

virtual networks, 85

VXLAN, 301–302, 319

security

Cisco DNA, 59–60, 71–73

compromise, IoC, 223–224

enterprise building example (applica-tion organization), 131

first hop security, 196

IBN, 204


risks, 209

scalability, 210


training, 210–211

transitioning to SDA, 209–210

incident response example, 223–224

IoC, 223–224

networks, 29

servers (RADIUS), 293

service catalogs (network intents), 219–220

business-supported apps/portals, 223


successes 341

sharing successes/failures, 221–222


serviceability, enterprise architectures, 231

SGT (Scalable Group Tags), 295–298, 319

classic VLAN, 185

extended IBN, 208–209


SharedService Group use case, 28–29

Cisco DNAC Assurance, 163–166

datacenter automation, 110–111

digitalization, IT proactive support of business, 240


IT operation frameworks, overusing, 252–253

lab environments, 187




virtualizing network functions, 61

VLAN configuration standardization, 136


skills, learning stages of new, 272–273

slow change, change management, 281

small switches, topology of, 308–309

SNMP (Simple Network Management Protocol), 312–314, 320

software

Agile software engineering method-ology, 33–34

Cisco DNA, 66–67

inventories, 133, 152

SDA, 181–184

Spanning Tree Protocol. See STP

speed of change, change management, 281

SSH (Secure Shell), asymmetric SSH key authentication and Ansible, 106–107

SSID (Service Set Identifiers), VLAN configuration standardization, 136

stakeholders

change management, 279–280

IBN, transitioning to, 141–142, 145

RACI matrix, 141

standardization

access switch configuration, 160–161

benefits of, 221

design and, 221

distribution switch configuration, 161

global (generic) configuration, 160–162

level of, 134–138, 145, 155

across locations, 137–138

uplinks, 135–136

VLAN, 136–137, 161–162

wireless network configuration, 161–162

storage, repositories (architecture), 47–48

STP (Spanning Tree Protocol), 308–310, 320

classic VLAN over SDA topologies, 90

drawbacks, 16–17

SDA and, 185

uplinks, blocking, 16–17

successes

chance of success, prioritizing chal-lenges in IBN transitions, 142

communication plans, sharing, 223

342 supplicants (IEEE 802.1X)

supplicants (IEEE 802.1X), 291

SWIM (SoftWare Image Management), 167

switches

access switches

configuration, 125–126


automating upgrades, 169

distribution switches

configuration, 124, 126

configuration standardization, 161



small switches, topology of, 308–309

upgrading, 169


switchports

Cisco DNA, 68–69

routed ports versus, 68–69

Syslog, 161, 314–316, 320

Ttechnology architectures, 42–43,

230–231

templates

bootstrap templates, 170–172

classic VLAN, 186


time (prioritizing challenges in IBN transitions), 142

timelines (action plans), estimated, 144–145

TOGAF® (The Open Group Architecture Framework), 39–41, 48

ADM, 43

phases of, 43–45

requirements management, 45


aspects of, 40–41





toolchains, 34–35

topologies


lab topologies, 180–181


small switches, 308–309


training

change management, 279, 281

extended IBN, 210–211

Translation process (IBN), 82

trend analysis, network analytics, 112

tunnels (CAPWAP), 10–11

two-tier/collapsed core topologies, 8–9, 89–90

UUDLD (Unidirectional Link

Detection), 18

underlay networks, SDA, 85–86

underlay routing, configuration, 192

understanding a business (communication plans), 222

unlicensed spectrum (frequency band), 26


upgrading switches, 169

VLAN (Virtual Local Area Networks) 343

uplinks

blocking, 16–17

port configuration, 196

standardization, level of, 135–136

use cases

App-Credits use case, 225

automation, 173

CiscoLive Europe use case, Intent-based API, 215–216

configuration and automation, 173

examples of IBN, 223




FinTech Ltd. use case, 25

automation, 64

choosing IBN technologies, 186

communication and focus in change management, 276




LogiServ Inc. use case

automation, 169


standardization and design, 221–222



QoS, 28–29

quid pro quo, change management, 275

SharedService Group use case, 28–29

Cisco DNAC Assurance, 163–166

datacenter automation, 110–111


IT proactive support of business, 240

lab environments, 187


overusing IT operation frameworks, 252–253



virtualizing network functions, 61

VLAN configuration standard-ization, 136

Vvalidated designs, 3


version control (organizational maturity), 139

virtual networks, SDA, 85

visibility, transitioning to IBN, 162–166

VLAN (Virtual Local Area Networks), 305–308, 319

authorization rules, 157–158


automation, 185


IBN and, 88–91

Layer 2 intents, 185

overlay networks, 186

Scalable Group Tags, 185

SDA and, 183–187

SDA topologies, 90–91

344 VLAN (Virtual Local Area Networks)

templates, 186

testing, 186


configuration standardization, 136–137, 161–162

dynamic VLAN, border nodes, 190

management VLAN, classic VLAN over SDA topologies, 90

numbering, 159–160

VTP, 311–312, 320

VNF (Virtualize Network Functions), 60–61

vPC (Virtual PortChannel), 17–19

VRF (Virtual Routing and Forwarding), classic VLAN over SDA topologies, 90

VRF-Lite (Virtual Routing and Forwarding-Lite), 184, 289–290, 319

VSS (Virtual Switching Solutions)


teardowns, 180–181

VTP (VLAN Trunking Protocol), 311–312, 320

VXLAN (Virtual eXtensible Local Area Networks), 301–302, 319

WWAN (Wide-Area Networks),

enterprise building example (application organization), 131

wired design, campus networks, 134

wireless controllers, Cisco DNAC Assurance, 166

wireless design, campus networks, 134–135

wireless networks, 11, 15


AP, 10–11

CAPWAP tunnels, 10–11





connected devices (IoT/non-user operated devices)


growth of, 26–27





security, 29

trends in, 23–26

WLC, 10

WLC (Wireless LAN Controllers), 10

YYAML (YAML Ain’t Markup

Language), playbooks and Ansible, 107

YANG (Yet Another Next Generation) and NSO, 101–102

ZZTP (Zero Touch Provisioning), 288

DHCP and, 287–288

operational flow of, 287–288

Python and, 288

Transforming Campus Networkingptgmedia.pearsoncmg.com/images/9780135466339/...Network Automation 119...

Documents

Transcript of Transforming Campus Networkingptgmedia.pearsoncmg.com/images/9780135466339/...Network Automation 119...