Cisco

Certified
DevNet
Professional
DEVCOR 350-901
Official Cert Guide

JASON DAVIS,
HAZIM DAHIR,
STUART CLARK,
QUINN SNYDER

Cisco Press

BOOK.indb 1 19/05/22 5:49 PM

 ii Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Cisco Certified DevNet Professional

DEVCOR 350-901 Official Cert Guide
Jason Davis

Hazim Dahir

Stuart Clark

Quinn Snyder

Copyright© 2023 Cisco Systems, Inc.

Published by:
Cisco Press

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying, recording, or by any information storage and retrieval
system, without written permission from the publisher, except for the inclusion of brief quotations in a
review.
ScoutAutomatedPrintCode
Library of Congress Control Number: 2022933631

ISBN-13: 978-0-13-737044-3

ISBN-10: 0-13-737044-X

Warning and Disclaimer

This book is designed to provide information about the Cisco DevNet Professional DEVCOR 350-901
exam. Every effort has been made to make this book as complete and as accurate as possible, but no
warranty or fitness is implied.

The information is provided on an “as is” basis. The authors, Cisco Press, and Cisco Systems, Inc. shall
have neither liability nor responsibility to any person or entity with respect to any loss or damages arising
from the information contained in this book or from the use of the discs or programs that may
accompany it.

The opinions expressed in this book belong to the author and are not necessarily those of Cisco Systems, Inc.

Trademark Acknowledgments
All terms mentioned in this book that are known to be trademarks or service marks have been
appropriately capitalized. Cisco Press or Cisco Systems, Inc., cannot attest to the accuracy of this infor-
mation. Use of a term in this book should not be regarded as affecting the validity of any trademark or
service mark.

Special Sales
For information about buying this title in bulk quantities, or for special sales opportunities (which may
include electronic versions; custom cover designs; and content particular to your business, training goals,
marketing focus, or branding interests), please contact our corporate sales department at corpsales@
pearsoned.com or (800) 382-3419.

For government sales inquiries, please contact [email protected].

For questions about sales outside the U.S., please contact [email protected].

BOOK.indb 2 19/05/22 5:49 PM

 iii

Feedback Information
At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each book
is crafted with care and precision, undergoing rigorous development that involves the unique expertise of
members from the professional technical community.

Readers’ feedback is a natural continuation of this process. If you have any comments regarding how we
could improve the quality of this book, or otherwise alter it to better suit your needs, you can contact us
through email at [email protected]. Please make sure to include the book title and ISBN in your
message.

We greatly appreciate your assistance.

Editor-in-Chief: Mark Taub Technical Editors: Bryan Byrne, Joe Clark

Alliances Manager, Cisco Press: Arezou Gol Editorial Assistant: Cindy Teeters

Director, ITP Product Management: Brett Bartow Cover Designer: Chuti Prasertsith

Executive Editor: Nancy Davis Composition: Codemantra

Managing Editor: Sandra Schroeder Indexer: Cheryl Lenser

Development Editor: Ellie Bru Proofreader: Donna E. Mulder

Senior Project Editor: Tonya Simpson

Copy Editor: CAH Editing

BOOK.indb 3 19/05/22 5:49 PM

 iv Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Pearson’s Commitment to Diversity, Equity,

and Inclusion
Pearson is dedicated to creating bias-free content that reflects the diversity of all learn-
ers. We embrace the many dimensions of diversity, including but not limited to race,
ethnicity, gender, socioeconomic status, ability, age, sexual orientation, and religious or
political beliefs.

Education is a powerful force for equity and change in our world. It has the potential to
deliver opportunities that improve lives and enable economic mobility. As we work with
authors to create content for every product and service, we acknowledge our responsibil-
ity to demonstrate inclusivity and incorporate diverse scholarship so that everyone can
achieve their potential through learning. As the world’s leading learning company, we have
a duty to help drive change and live up to our purpose to help more people create a bet-
ter life for themselves and to create a better world.

Our ambition is to purposefully contribute to a world where

■ Everyone has an equitable and lifelong opportunity to succeed through learning

■ Our educational products and services are inclusive and represent the rich diversity
of learners

■ Our educational content accurately reflects the histories and experiences of the
learners we serve

■ Our educational content prompts deeper discussions with learners and motivates
them to expand their own learning (and worldview)

While we work hard to present unbiased content, we want to hear from you about any
concerns or needs with this Pearson product so that we can investigate and address them.

Please contact us with concerns about any potential bias at https://www.pearson.com/

report-bias.html.

BOOK.indb 4 19/05/22 5:49 PM

 v

About the Authors

Jason Davis is a distinguished engineer for the DevNet program in the Developer Rela-
tions organization at Cisco. His role is technical strategy lead for the DevRel organization
as he collaborates with various Cisco business unit leaders, partners, customers, and other
industry influencers. Jason is focused on automation, orchestration, cloud-native technol-
ogies, and network management/operations technologies. He has a tenured career work-
ing with hundreds of customers, worldwide, in some of the largest network automation
and management projects and is sought out for consulting and innovative leadership. His
former experience as a U.S. Army Signal Corps officer has provided insights to defense,
government, and public-sector projects, while his extensive work in professional services
at Cisco has spanned commercial, large-enterprise, and service provider segments. Most
of his customer engagements have been in automotive, manufacturing, large retail, large
event venues, and health care. Jason has achieved Cisco Live Distinguished Speaker Hall
of Fame status and is an automation/monitoring lead for the network operations center
(NOC) at Cisco Live events in the U.S. and Europe. He resides in Apex, North Carolina,
and enjoys IoT projects, home automation, and audio/video technologies in houses of
worship. Jason and his wife, Amy, have four children whom they homeschool and cherish
daily. Jason is found on social media @SNMPguy.

Hazim Dahir, CCIE No. 5536, is a distinguished engineer at the Cisco office of the
CTO. He is working to define and influence next-generation digital transformation
architectures across multiple technologies and verticals. Hazim started his Cisco tenure
in 1996 as a software engineer and subsequently moved into the services organization
focusing on large-scale network designs. He’s currently focusing on developing architec-
tures utilizing security, collaboration, Edge computing, and IoT technologies addressing
the future of work and hybrid cloud requirements for large enterprises. Through his pas-
sion for engineering and sustainability, Hazim is currently working on advanced software
solutions for electric and autonomous vehicles with global automotive manufacturers.
Hazim is a Distinguished Speaker at Cisco Live and is a frequent presenter at multiple
global conferences and standards bodies. He has multiple issued and pending patents and
a number of innovation and R&D publications.

Stuart Clark, DevNet Expert #2022005, started his career as a hairdresser in 1990,
and in 2008 he changed careers to become a network engineer. After cutting his teeth
in network operations, he moved to network projects and programs. Stuart joined Cisco
in 2012 as a network engineer, rebuilding one of Cisco’s global networks and designing
and building Cisco’s IXP peering program. After many years as a network engineer, Stu-
art became obsessed with network automation and joined Cisco DevNet as a developer
advocate for network automation. Stuart contributed to the DevNet exams and was part
of one of the SME teams that created, designed, and built the Cisco Certified DevNet
Expert. Stuart has presented at more than 50 external conferences and is a multitime
Cisco Live Distinguished Speaker, covering topics on network automation and method-
ologies. Stuart lives in Lincoln, England, with his wife, Natalie, and their son, Maddox.
He plays guitar and rocks an impressive two-foot beard while drinking coffee. Stuart can
be found on social media
@bigevilbeard.

BOOK.indb 5 19/05/22 5:49 PM

 vi Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Quinn Snyder is a developer advocate within the Developer Relations organization inside
Cisco, focusing on datacenter technologies, both on-premises and cloud-native. In this
role, he aligns his passion for education and learning with his enthusiasm for helping the
infrastructure automation community grow and harness the powers of APIs, structured
data, and programmability tooling. Prior to his work as a DA, Quinn spent 15 years in a
variety of design, engineering, and implementation roles across datacenter, utility, and
service provider customers for both Cisco and the partner community. Quinn is a proud
graduate of Arizona State University (go Sun Devils!) and a Cisco Network Academy
alumnus. He is the technical co-chair of the SkillsUSA–Arizona Internetworking contest
and is involved with programmability education at the state and regional level for the
Cisco Networking Academy. Quinn resides in the suburbs of Phoenix, Arizona, with his
wife, Amanda, and his two kids. In his free time, you can find him behind a grill, behind
a camera lens, or on the soccer field coaching his daughter’s soccer teams. Quinn can be
found on social media @qsnyder, usually posting a mixture of technical content and his
culinary creations.

About the Technical Reviewers

Bryan Byrne, CCIE No. 25607 (R&S), is a technical solutions architect in Cisco’s Global
Enterprise segment. With more than 20 years of data networking experience, his current
focus is helping his customers transition from traditional LAN/WAN deployments toward
Cisco’s next-generation software-defined network solutions. Prior to joining Cisco, Bryan
spent the first 13 years of his career in an operations role with a global service provider
supporting large-scale IP DMVPN and MPLS networks. Bryan is a multitime Cisco Live
Distinguished Speaker, covering topics on NETCONF, RESTCONF, and YANG. He is a
proud graduate of The Ohio State University and currently lives outside Columbus, Ohio,
with his wife, Lindsey, and their two children, Evan and Kaitlin.

Joe Clarke, CCIE No. 5384, is a Cisco Distinguished Customer Experience engineer. Joe
has contributed to the development and adoption of many of Cisco’s network operations
and automation products and technologies. Joe evangelizes these programmability and
automation skills in order to build the next generation of network engineers. Joe is a Dis-
tinguished Speaker at CiscoLive!, and is certified as a CCIE and a Cisco Certified DevNet
Specialist (and a member of the elite DevNet 500). Joe provides network consulting and
design support for the CiscoLive! and Internet Engineering Task Force (IETF) conference
network infrastructure deployments. He also serves as co-chair of the Ops Area Work-
ing Group at the IETF. He is a coauthor of Network Programmability with YANG: The
Structure of Network Automation with YANG, NETCONF, RESTCONF, and gNMI as
well as a chapter coauthor in the Springer publication Network-Embedded Management
and Applications: Understanding Programmable Networking Infrastructure. He is an
alumnus of the University of Miami and holds a bachelor of science degree in computer
science. Outside of Cisco, Joe is a commercial pilot, and he and his wife, Julia, enjoy fly-
ing around the east coast of the United States.

BOOK.indb 6 19/05/22 5:49 PM

 vii

Dedications
Jason Davis:

When you set off to write a book, how do you quantify the time needed to study, write,
and refine? You need time to obtain and configure the lab equipment for examples. There
are still family, career, personal health, and welfare activities that demand attention. How
can you plan when your job and a global health crisis demand the utmost in flexibility
and focus? To all the family and supporters of writers, thank you; there should be a spe-
cial place in heaven for you. I am indebted to my wife, Amy, and my children, Alyssa,
Ryan, Micaela, and Maleah. You provided me with the time and space to do this, espe-
cially through the hardships of 2021. Finally, I am thankful that my God has provided
opportunities and skills to impact technology in some small part and in a positive way;
because He has shown His love for me in innumerable ways, I am motivated to share the
same with others.

Hazim Dahir:

To my father, my favorite librarian: I wish this book could have made it to your shelf. I
think of you every day. To my mother, with heartfelt gratitude for all your love, prayers,
and guidance. I am a better person, husband, father, brother, and engineer because of
you two.

To my amazing wife, Angela: no words or pages can grasp how indebted I am to you for
your encouragement, patience, and wisdom.

To my children, Hala, Leila, and Zayd. I love watching you grow. Thank you for being
such a joy. Never give up on your dreams.

To my sisters, Hana and Dina, and brother Gary. My team.

To Bill, Sylvia, and Karen Moseley. We can do this!

Stuart Clark:

This book is dedicated to my amazing Natalie (Mouse) and our son, Maddox, and our
beloved dog, Bailey, who sadly passed while I was authoring this book. Without their
love, support, and countless cups of coffee, this book would have never been possible. I
would like to thank my father, George, and mother, Wendy Clark, for providing me with
the work ethic I have today; and Natalie’s father and mother, Frank and Barbara Thomas,
for giving me my very first networking book and helping me transition into a new
career. A big thank you to my mentors Mandy Whaley, Denise Fishburne, Joe Clarke,
and my metaldevops brother Jason Gooley, who have helped and guided me for many
years at Cisco.

BOOK.indb 7 19/05/22 5:49 PM

 viii Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Quinn Snyder:

Writing a book is an unknown unknown to a first-time author. You have read the prod-
ucts from others, but you don’t know what you don’t know when you set out to write
your own. The only known you have is the support of the people behind you, who make
it possible to think, to work, to create, and to inspire you. They are there for your late
nights, the constant tapping of the keys, listening to you ramble on about what you’ve
just put to paper. This book would not have been possible without the support of
those behind me, propping me up, cheering me along, and believing in me. To my wife,
Amanda, you are my rock—my biggest fan and supporter—and the one who has always
believed in me, and I wouldn’t have been able to do this without you. To my children,
Nicolas and Madelyn, you have given me the space to create and do, and have inspired
me to show you that anything is possible. To my mother, Cynthia, you have inspired a
never-quit work ethic that sticks with me to this day. I thank you all for giving me those
gifts, and I dedicate this book to you.

BOOK.indb 8 19/05/22 5:49 PM

 ix

Acknowledgments
Jason Davis:
Most who know me understand that I appreciate telling stories, especially with humor.
While that humor may not be recognized, it is mine nonetheless, so thank you to those
who have endured it for years. I am thankful for the opportunity to pivot from writ-
ing blogs, whitepapers, and presentations to writing this book. It has been an exercise
in patience and personal growth. The support team at Cisco Press—Nancy, Ellie, and
Tonya—you’ve been great, valuable partners in this endeavor.

I am thankful to a cadre of supportive managers at Cisco over the years who helped me
grow technically and professionally; Mike, Dave, Rich, and Ghaida, you have been awe-
some! Hazim, Stuart, and Quinn, thank you for joining me on this journey. Besides being
wonderful coworkers, our collaboration, though separated by states and countries, has
turned into friendship that has made a mark.

Hazim Dahir:
This book would not have been possible without two SUPER teams. The A Team: Jason,
Stuart, and Quinn. Thank you for an amazing journey and expert work. “Technically,” you
complete me! And, the Cisco Press team: Nancy Davis, Ellie Bru, Tonya Simpson, and
their teams. Thank you for all your help, guidance, and most importantly, your patience.

Special thanks go to Kaouther Abrougui for her contributions to the Security chapter,
Mithun Baphana for his Webex contributions, and to David Wang for his Git contribu-
tions. Kaouther, Mithun, and David are experts in their fields, and we’re lucky to have
them join us.

Many thanks go to Firas Ahmed, for his encouragement, technical reviews, and support.

A great deal of gratitude goes to Hana Dahir, an engineer at heart, who reviewed various
content for me.

I am very thankful to the following Cisco colleagues and leaders: Yenu Gobena, Saad
Hasan, Carlos Pignataro, Jeff Apcar, Vijay Raghavendran, Ammar Rayes, Nancy
Cam-Winget, and many others who supported me throughout my career and encouraged
me to break barriers.

Stuart Clark:
Being a first-time author was such a daunting task, but the great people at Cisco Press,
Nancy and Ellie; my coauthors, Hazim, Jason, and the BBQ Pit Master Quinn; technical
reviewers, Joe Clarke and Bryan Byrne, kept me in check and supporting every chapter. A
huge thank you to my leadership at DevNet—Matt Denapoli, Eric Thiel, and Grace Fran-
cisco—for always supporting my goals and ambitions. Janel Kratky, Kareem Iskander, and
Hank Preston for their vast support and encouragement since joining the DevNet team
in 2017. My dearest friends, Patrick Rockholz and Du’An Lightfoot, whose faith in me is
always unfaltering.

BOOK.indb 9 19/05/22 5:49 PM

 x Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Quinn Snyder:
I’d like to thank the crew at Cisco Press for wading through my incoherent ramblings
and turning them into something worth reading. To Ellie and Nancy, thank you for the
patience and dealing with my inane questions. To Joe Clarke, thank you for your techni-
cal expertise in the review process.

Thank you to my DevNet leaders—Grace, Eric, Matt, and Jeff—for bringing me into this
amazing team and supporting my growth and development to make this work possible.

A special thanks to the guy who taught me “how to DA,” John McDonough. You set me
on a path for success and showed me the ropes, and for that I am grateful. To Kareem
Iskander, thanks for just being there. You always have listened to me, picked me up, and
pushed me forward. To my partners in crime (both with and without beards)—Jason,
Hazim, and Stuart—you guys believed that I could and gave me a shot. I have appreciated
our meetings, our late-night messaging sessions, and the friendship that has developed.

Finally, a special thank you to the man who guided me so many years ago, Barry Wil-
liams. Without your Cisco classes, your instruction, your belief, and never accepting “just
good enough,” I wouldn’t have had the foundation that I do today. You helped a kid from
rural Arizona see the big world and what was possible if I stuck with it, and because of
that, I am where I am today.

BOOK.indb 10 19/05/22 5:49 PM

 xi

Contents at a Glance
Introduction xxviii

Part I Software Development and Design

Chapter 1 Software Development Essentials 2

Chapter 2 Software Quality Attributes 26

Chapter 3 Architectural Considerations and Performance Management 56

Chapter 4 Version Control and Release Management with Git 86

Part II APIs
Chapter 5 Network APIs 130

Chapter 6 API Development 162

Part III Application Development, Deployment, and Security

Chapter 7 Application Deployment 192

Chapter 8 Security in Application Design 246

Part IV Infrastructure and Automation

Chapter 9 Infrastructure 286

Chapter 10 Automation 310

Chapter 11 NETCONF and RESTCONF 346

Chapter 12 Model-Driven Telemetry 386

Chapter 13 Open-Source Solutions 444

Chapter 14 Software Configuration Management 508

Chapter 15 Hosting an Application on a Network Device 524

Part V Platforms
Chapter 16 Cisco Platforms 568

Chapter 17 Final Preparation 648

BOOK.indb 11 19/05/22 5:49 PM

 xii Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Appendix A Answers to the “Do I Know This Already?” Questions 654

Appendix B Cisco DevNet Professional DEVCOR 350-901 Exam Updates 672

Glossary 675

Index 684

Online Elements
Appendix C Memory Tables

Appendix D Memory Tables Answer Key

Appendix E Dashboard Basics

Glossary

BOOK.indb 12 19/05/22 5:49 PM

 xiii

Reader Services

BOOK.indb 13 19/05/22 5:49 PM

 xiv Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Contents
Introduction xxviii

Part I Software Development and Design

Chapter 1 Software Development Essentials 2

“Do I Know This Already?” Quiz 2
Foundation Topics 4
A Brief History of the Future 4
The Evolution 5
Automation, Orchestration, and DevOps 6
Software Architecture and Design 9
Architecture Requirements 10
Functional Requirements 13
Nonfunctional Requirements 13
Architectural Patterns 14
Software Development Lifecycle (SDLC) Approach 15
Software Development Models 17
Waterfall 17
Agile Software Development 18
Scrum 19
Extreme Programming 19
Kanban 19
Lean 19
Which Model? 20
Architecture and Code Reviews 21
Software Testing 22
Exam Preparation Tasks 23
Review All Key Topics 24
Complete Tables and Lists from Memory 24
Define Key Terms 24
References 24

Chapter 2 Software Quality Attributes 26

“Do I Know This Already?” Quiz 26
Foundation Topics 29
Quality Attributes and Nonfunctional Requirements 29
Brief Overview of the Most Common Quality Attributes 29
Measuring Quality Attributes 35

BOOK.indb 14 19/05/22 5:49 PM

 Contents xv

Modularity in Application Design 36

Benefits of Modularity 36
Modularity Coding Best Practices 37
Microservices and Modular Design 40
Scalability in Application Design 41
Horizontal Scalability 41
Vertical Scalability 42
Practical Scalability in Application Design 43
High Availability and Resiliency in Application Design 44
Failure or Fault Detection 46
Recovery: High Availability in Practice 47
Prevention 50
High Availability Planning and the Responsibilities of the Developer 50
High Availability Deployment Models 51
Exam Preparation Tasks 53
Review All Key Topics 53
Complete Tables and Lists from Memory 53
Define Key Terms 53
References 54

Chapter 3 Architectural Considerations and Performance Management 56

“Do I Know This Already?” Quiz 57
Foundation Topics 59
Maintainable Design and Implementation 59
Maintaining a SOLID Design 60
Single Responsibility Principle (SRP) 61
Open-Closed Principle (OCP) 62
Liskov’s Substitution Principle (LSP) 63
Interface Segregation Principle (ISP) 64
Dependency Inversion Principle (DIP) 65
Latency and Rate Limiting in Application Design and Performance 66
Designing for Application Low Latency and High Performance 69
Architecture Trade-offs 69
Improving Performance 69
Design and Implementation for Observability 73
Logging 74
Metrics 76

BOOK.indb 15 19/05/22 5:49 PM

 xvi Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Tracing 77
Good Documentation Practices: An Observability Reminder 78
Database Selection Criteria 79
Database Requirements Gathering 80
Data Volume 81
Data Velocity 82
Data Variety 82
Exam Preparation Tasks 83
Review All Key Topics 83
Complete Tables and Lists from Memory 83
Define Key Terms 84
References 84

Chapter 4 Version Control and Release Management with Git 86

“Do I Know This Already?” Quiz 86
Foundation Topics 88
Version Control and Git 88
Git Workflow 88
Branch and Pull Workflow 89
Pros 89
Cons 89
Sample Setup 90
Sample Branch and Pull Workflow 90
Fork and Pull Workflow 104
Pros 105
Cons 105
Sample Setup 105
Sample Fork and Pull Workflow 106
Git Branching Strategy 121
What Is a Branching Strategy? 121
The Most Important Factor When Selecting a Git Branching Strategy 122
Popular Git Branching Strategies 122
When to Use GitHub Flow 122
When to Use Git Flow 123
When to Use GitLab Flow 123
Recommended GitHub Settings 125
Configuring the PR Merge Button 125
Configuring a Branch Protection Rule to Require Code Reviews 125

BOOK.indb 16 19/05/22 5:49 PM

 Contents xvii

Exam Preparation Tasks 127

Review All Key Topics 128
Complete Tables and Lists from Memory 128
Define Key Terms 128
References 128

Part II APIs

Chapter 5 Network APIs 130

“Do I Know This Already?” Quiz 130
Foundation Topics 132
What Are APIs? 132
Methods 133
Objects 134
Formats 134
APIs vs. No API 135
Web Scraping 135
Jeff Bezos’s API Mandate: How the AWS API-Driven Cloud Was
Born 136
Calling an API 138
What Is API Development? 144
API Architectural Styles 146
Selecting an API Style 147
HTTP/JSON 149
REST/JSON 150
Cache-Control 151
REST vs. RPC 152
gRPC 154
OpenAPI/Swagger 155
Network API Styles 157
NETCONF APIs 158
Exam Preparation Tasks 160
Review All Key Topics 160
Complete Tables and Lists from Memory 160
Define Key Terms 160
References 161

BOOK.indb 17 19/05/22 5:49 PM

 xviii Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Chapter 6 API Development 162

“Do I Know This Already?” Quiz 163
Foundation Topics 165
Creating API Clients 165
Code Generation Client API Libraries for IMDb 165
Adding CLI Wrapper Code 174
Making Calls to IMDb Using a CLI Program 174
API Design Considerations 177
API Authentication Models 179
Flow Control (Pagination vs. Streaming) 181
Error Handling, Timeouts, and Rate Limiting 184
Caching 188
Exam Preparation Tasks 189
Review All Key Topics 189
Complete Tables and Lists from Memory 189
Define Key Terms 189
References 189

Part III Application Development, Deployment, and Security

Chapter 7 Application Deployment 192

“Do I Know This Already?” Quiz 193
Foundation Topics 194
The Evolution of Application Responsibilities 194
The Hybridization of Development and Operations 194
The Journey to DevOps 195
A Cultural Shift 196
The Emergence of the Site Reliability Engineer(ing) 196
SRE Responsibilities and Tenets 197
SRE vs. DevOps 198
Continuous Integration/Continuous Delivery (Deployment) 198
Continuous Integration (CI) 199
Continuous Delivery: One of the CDs 200
Continuous Deployment: The Other CD 200
CI/CD Pipeline Implementation 201
Pipeline Components 203
Build 204
Test 205
Release/Deliver 205

BOOK.indb 18 19/05/22 5:49 PM

 Contents xix

Deploy 205
Adding Deployment to Integration 207
Deploying to Infrastructure (Terraform + Atlantis) 207
Deploying Applications (Flux + Kubernetes) 213
Application Deployment Methods over Time 218
The 2000s: Sysadmins, Terminals, and SSH 218
The 2010s: Automated Configuration Management 220
The 2020s: The Clouds Never Looked So Bright 224
Managed Kubernetes (e.g., GKE) 224
Containers on Serverless Clouds (e.g., AWS ECS on Fargate) 227
Serverless Functions (e.g., AWS Lambda) 234
Software Practices for Operability: The 12-Factor App 238
Factor 1: Codebase 239
Factor 2: Dependencies 239
Factor 3: Config 239
Factor 4: Backing Services 240
Factor 5: Build, Release, Run 240
Factor 6: Processes 240
Factor 7: Port Binding 241
Factor 8: Concurrency 241
Factor 9: Disposability 241
Factor 10: Dev/Prod Parity 241
Factor 11: Logs 242
Factor 12: Admin Processes 242
Summary 243
Exam Preparation Tasks 243
Review All Key Topics 243
Complete Tables and Lists from Memory 244
Define Key Terms 244
References 244

Chapter 8 Security in Application Design 246

“Do I Know This Already?” Quiz 247
Foundation Topics 248
Protecting Privacy 250
Personally Identifiable Information 250
Data States 250
Laws, Regulations, and Standards for Protecting Privacy 251

BOOK.indb 19 19/05/22 5:49 PM

 xx Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Storing IT Secrets 252

Public Key Infrastructure (PKI) 254
Certificate Revocation 256
Hierarchical Multiple CA Infrastructure 257
TLS, PKI, and Web Applications Security 257
Browser Security Issues 261
Securing Web and Mobile Applications 262
Injection Attacks 263
Cross-Site Scripting 264
OAuth Authorization Framework 266
How Does OAuth Work? 266
OAuth 2.0 Two-Legged Authorization 268
OAuth 2.0 Three-Legged Authorization 269
Additional OAuth Authorization Code Grant Types 271
OAuth 2.0 Client Credentials 271
Resource Owner Password Credential Flow 272
OAuth 2.0 Implicit Flow 275
OAuth 2.0 Authorization Code Flow 276
OAuth 2.0 PKCE Flow 278
Refresh Token Flow 280
OAuth 2.0 Device Code Flow 281
Exam Preparation Tasks 283
Review All Key Topics 283
Complete Tables and Lists from Memory 284
Define Key Terms 284
References 284

Part IV Infrastructure and Automation

Chapter 9 Infrastructure 286

“Do I Know This Already?” Quiz 286
Foundation Topics 288
Network Management 288
Methods of Network Provisioning 290
CLI/Console 291
SNMP 294
File Transfer Methods 297
Element Management Systems 297
Embedded Management 299

BOOK.indb 20 19/05/22 5:49 PM

 Contents xxi

Zero-Touch Provisioning (ZTP) 300

Atomic or SDN-Like/Controller-Based Networking 303
Advanced Concepts—Intent-Based Networking 305
Summary 307
Exam Preparation Tasks 307
Review All Key Topics 307
Complete Tables and Lists from Memory 307
Define Key Terms 307
References 308

Chapter 10 Automation 310

“Do I Know This Already?” Quiz 311
Foundation Topics 313
Challenges Being Addressed 313
Differences of Equipment and Functionality 314
Proximity of Management Tools and Support Staff 316
Speed of Service Provisioning 317
Accuracy of Service Provisioning 319
Scale 323
Doing More with Less 329
Software-Defined Networking (SDN) 329
What Is SDN and Network Programmability? 329
Approach 330
Nontraditional Entities 331
Industry Impact 331
New Methods 331
Normalization 332
Enabling Operations 332
Enabling Career Options 332
Use Cases and Problems Solved with SDN 332
Overview of Network Controllers 334
The Cisco Solutions 335
Application Programming Interfaces (APIs) 335
REST APIs 336
API Methods 337
API Authentication 337
API Pagination 337

BOOK.indb 21 19/05/22 5:49 PM

 xxii Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Payload Data Formats JSON XML 338

XML 338
JSON 340
Cross-Domain, Technology-Agnostic Orchestration (CDTAO) 342
Impact to IT Service Management and Security 343
Exam Preparation Tasks 344
Review All Key Topics 344
Complete Tables and Lists from Memory 345
Define Key Terms 345
References 345

Chapter 11 NETCONF and RESTCONF 346

“Do I Know This Already?” Quiz 346
Foundation Topics 348
Catalyst for NETCONF 348
Content 349
Operations 350
Messages 350
Transport 351
Atomic and Model-Driven Configuration Management 351
How to Implement NETCONF 354
Enabling NETCONF on IOS XE 355
Enabling NETCONF on IOS XR 356
Enabling NETCONF on NX-OS 357
Basic Manual Use of NETCONF 358
YANG Models 365
The Evolution with RESTCONF 371
The RESTCONF Protocol Stack 372
RESTCONF Operations 372
RESTCONF and Authentication 373
RESTCONF URIs 373
Performing a RESTCONF GET Operation with cURL 375
Performing RESTCONF GET Operations with the Postman Utility 377
Management Solutions Using NETCONF and RESTCONF 382
Exam Preparation Tasks 383
Review All Key Topics 383
Complete Tables and Lists from Memory 383
Define Key Terms 383
References 384

BOOK.indb 22 19/05/22 5:49 PM

 Contents xxiii

Chapter 12 Model-Driven Telemetry 386

“Do I Know This Already?” Quiz 387
Foundation Topics 389
Transformation of Inventory, Status, Performance, and Fault Monitoring 389
Scaling with the Push Model 391
How to Implement Model-Driven Telemetry 393
Dial-In and Dial-Out Mode 395
Encoding (Serialization) 395
Protocols 396
Configuring MDT in IOS-XR 398
Configuring Dial-Out Mode 398
Step 1: Create a Destination Group 398
Step 2: Create a Sensor Group 400
Step 3: Create a Subscription 400
Step 4: Verify the Dial-Out Configuration 401
Configuring Dial-In Mode 402
Step 1: Enable gRPC 402
Step 2: Create a Sensor Group 404
Step 3: Create a Subscription 405
Step 4: Validate the Configuration 405
Picking Sensor Paths and Metrics 407
Researching Public Documentation 407
Extracting Model Support from the Device—NETCONF Manually 408
Extracting Model Support from the Device—Python and NETCONF 410
Digging into the YANG Models 414
Installing Docker to the Linux VM 414
Installing the YANG Suite Docker Image to the Linux VM 415
Practical Application of Streaming Telemetry 423
Using Telegraph, InfluxDB, and Grafana 426
Installing InfluxDB 426
Installing Telegraf 428
Beyond MDT—Event-Driven Telemetry 434
Other Considerations—Disk Usage 440
Frequency of Telemetry Push 441
Exam Preparation Tasks 441
Review All Key Topics 441

BOOK.indb 23 19/05/22 5:49 PM

 xxiv Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Complete Tables and Lists from Memory 442

Define Key Terms 442
References 442

Chapter 13 Open-Source Solutions 444

“Do I Know This Already?” Quiz 445
Foundation Topics 447
Infrastructure-as-Code (IaC) Concepts 447
Imperative and Declarative Models 448
Provisioning or Configuration Management 449
Differences Between Agent and Agentless Solutions 450
Agent-Based Solutions—Puppet and Chef 450
Agentless Solutions—Ansible and Terraform 474
Installing Ansible from the Package Manager 474
Installing the Latest Ansible from a Virtual Python Environment
with pip 476
Configuring Ansible Inventory 481
Creating a Project-Level Inventory File 482
Creating an Ansible Playbook to Obtain show Command Results 483
Filtering, Templating, and Jinja2 487
Using Ansible to Modify Device Configurations 488
Terraform Overview 493
Installing Terraform 494
Using Terraform 496
Cisco Solutions Enabled for IaC 501
Exam Preparation Tasks 502
Review All Key Topics 502
Complete Tables and Lists from Memory 503
Define Key Terms 503
References 503

Chapter 14 Software Configuration Management 508

“Do I Know This Already?” Quiz 508
Foundation Topics 510
Software Configuration Management (SCM) 510
SCM Definitions and Standards 510
Why Do You Need SCM? 511
Which SCM Process Is Best for You? 512
Ansible 512

BOOK.indb 24 19/05/22 5:49 PM

 Contents xxv

Terraform 515
Terraform or Ansible: A High-Level Comparison 518
Business and Technical Requirements 519
Architectural Decisions 519
Technical Debt 520
Exam Preparation Tasks 521
Review All Key Topics 521
Complete Tables and Lists from Memory 522
Define Key Terms 522
References 522

Chapter 15 Hosting an Application on a Network Device 524

“Do I Know This Already?” Quiz 524
Foundation Topics 527
Benefits of Edge Computing 527
Virtualization Technologies 527
Type-1 Hypervisors 528
Type-2 Hypervisors 528
Linux Containers (LXC) 529
Docker Containers 530
Application Container Ideas 532
Platforms Supporting Application Containers 533
How to Implement Application Containers 534
Validating Prerequisites 534
Enabling Application Hosting Framework 536
Using Cisco DNA Center for App Hosting 538
Using Cisco IOx Local Manager for App Hosting 547
Using the Command-Line Interface for App Hosting 553
Interacting with App Hosted iPerf3 556
Best Practices for Managing Application Containers 563
Exam Preparation Tasks 565
Review All Key Topics 565
Complete Tables and Lists from Memory 565
Define Key Terms 565
References 566

BOOK.indb 25 19/05/22 5:49 PM

 xxvi Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Part V Platforms

Chapter 16 Cisco Platforms 568

“Do I Know This Already?” Quiz 568
Foundation Topics 571
Webex 571
Enabling the Webex REST API/SDK Access 572
Webex API Documentation 573
API Examples 575
SDK Examples 577
Firepower 582
Enabling API/SDK Access to Firepower 582
Firepower API Documentation 583
Meraki 592
Enabling API/SDK Access to Meraki 592
Meraki API Documentation 593
Meraki SDK Documentation 594
Meraki Authorization 596
Intersight 601
Enabling API Access to Intersight 601
Intersight API Documentation 603
Intersight SDK Documentation 605
Intersight Authorization 606
UCS Manager 611
Enabling API Access to UCS Manager 611
UCS Manager API Documentation 611
Python SDK Documentation 617
PowerShell SDK Documentation 622
Additional UCS Manager Programmability Resources 628
DNA Center 628
Enabling API/SDK Access to DNA Center 630
DNA Center API Documentation 631
DNA Center SDK Documentation 635
SDK Authorization 637
AppDynamics 639
Exam Preparation Tasks 646
References 646

BOOK.indb 26 19/05/22 5:49 PM

 Contents xxvii

Chapter 17 Final Preparation 648

Getting Ready 648
Tools for Final Preparation 649
Pearson Cert Practice Test Engine and Questions on the Website 649
Accessing the Pearson Test Prep Software Online 649
Accessing the Pearson Test Prep Software Offline 649
Customizing Your Exams 650
Updating Your Exams 651
Premium Edition 651
Chapter-Ending Review Tools 652
Suggested Plan for Final Review/Study 652
Summary 652

Appendix A Answers to the “Do I Know This Already?” Questions 654

Appendix B Cisco DevNet Professional DEVCOR 350-901 Exam Updates 672

Glossary 675

Index 684

Online Elements
Appendix C Memory Tables

Appendix D Memory Tables Answer Key

Appendix E Dashboard Basics

Glossary

BOOK.indb 27 19/05/22 5:49 PM

 xxviii Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Command Syntax Conventions

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

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

■ Italic indicates arguments for which you supply actual values.

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

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

■ Braces ({ }) indicate a required choice.

■ Braces within brackets ([{ }]) indicate a required choice within an optional element.

BOOK.indb 28 19/05/22 5:49 PM

 Introduction xxix

Introduction
This book was written to help candidates improve their network programmability and
automation skills—not only for preparing to take the DevNet Professional DEVCOR
350-901 exam but also for real-world skills in any production environment.

You can expect that the blueprint for the DevNet Professional DEVCOR 350-901 exam
tightly aligns with the topics contained in this book. This was by design. You can follow
along with the examples in this book by utilizing the tools and resources found on the
DevNet website and other free utilities such as Postman and Python.

We are targeting any and all learners who are learning these topics for the first time
as well as those who wish to enhance their network programmability and automation
skillset.

Be sure to visit www.cisco.com to find the latest information on DevNet Professional

DEVCOR 350-901 exam requirements and to keep up to date on any new exams that are
announced.

Goals and Methods

The most important and somewhat obvious goal of this book is to help you pass the
DevNet Professional DEVCOR 350-901 exam. In fact, if the primary objective of this
book were different, then the book’s title would be misleading; however, the methods
used in this book to help you pass the DevNet Professional exam are designed to also
make you much more knowledgeable about how to do your job. Although this book and
the companion website together have more than enough questions to help you prepare
for the actual exam, the method in which they are used is not to simply make you memo-
rize as many questions and answers as you possibly can.

One key methodology used in this book is to help you discover the exam topics that you
need to review in more depth, to help you fully understand and remember those details,
and to help you prove to yourself that you have retained your knowledge of those topics.
So, this book does not try to help you pass by memorization but helps you truly learn
and understand the topics. The DevNet Professional exam is just one of the foundation
exams in the DevNet certification suite, and the knowledge contained within is vitally
important to consider yourself a truly skilled network developer. This book would do
you a disservice if it didn’t attempt to help you learn the material. To that end, the book
will help you pass the DevNet Professional exam by using the following methods:

■ Helping you discover which test topics you have not mastered

■ Providing explanations and information to fill in your knowledge gaps

■ Supplying exercises and scenarios that enhance your ability to recall and deduce the
answers to test questions

BOOK.indb 29 19/05/22 5:49 PM

 xxx Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Who Should Read This Book?

This book is intended to help candidates prepare for the DevNet Professional DEVCOR
350-901 exam. Not only can this book help you pass the exam, but it can also help you
learn the necessary topics to provide value to your organization as a network developer.

Passing the DevNet Professional DEVCOR 350-901 exam is a milestone toward becom-
ing a better network developer, which, in turn, can help with becoming more confident
with these technologies.

Strategies for Exam Preparation

The strategy you use for the DevNet Professional exam might be slightly different than
strategies used by other readers, mainly based on the skills, knowledge, and experience
you already have obtained.

Regardless of the strategy you use or the background you have, the book is designed
to help you get to the point where you can pass the exam with the least amount of time
required. However, many people like to make sure that they truly know a topic and thus
read over material that they already know. Several book features will help you gain the
confidence that you need to be convinced that you know some material already and to
also help you know what topics you need to study more.

The Companion Website for Online Content Review

All the electronic review elements, as well as other electronic components of the book,
exist on this book’s companion website.

How to Access the Companion Website

To access the companion website, which gives you access to the electronic content with
this book, start by establishing a login at www.ciscopress.com and registering your book.
To do so, simply go to www.ciscopress.com/register and enter the ISBN of the print
book: 9780137370443. After you have registered your book, go to your account page
and click the Registered Products tab. From there, click the Access Bonus Content link
to get access to the book’s companion website.

Note that if you buy the Premium Edition eBook and Practice Test version of this book
from Cisco Press, your book will automatically be registered on your account page. Sim-
ply go to your account page, click the Registered Products tab, and select Access Bonus
Content to access the book’s companion website.

BOOK.indb 30 19/05/22 5:49 PM

 Introduction xxxi

How to Access the Pearson Test Prep (PTP) App

You have two options for installing and using the Pearson Test Prep application: a web
app and a desktop app. To use the Pearson Test Prep application, start by finding the
registration code that comes with the book. You can find the code in these ways:

■ Print book: Look in the cardboard sleeve in the back of the book for a piece of
paper with your book’s unique PTP code.

■ Premium Edition: If you purchase the Premium Edition eBook and Practice Test
directly from the Cisco Press website, the code will be populated on your account
page after purchase. Just log in at www.ciscopress.com, click Account to see details
of your account, and click the Digital Purchases tab.

■ Amazon Kindle: For those who purchase a Kindle edition from Amazon, the access
code will be supplied directly from Amazon.

■ Other Bookseller eBooks: Note that if you purchase an eBook version from any
other source, the practice test is not included because other vendors to date have not
chosen to vend the required unique access code.

NOTE Do not lose the activation code because it is the only means with which you can
access the QA content with the book.

When you have the access code, to find instructions about both the PTP web app and
the desktop app, follow these steps:
Step 1. Open this book’s companion website, as shown earlier in this Introduction
under the heading “How to Access the Companion Website.”
Step 2. Click the Practice Exams button.
Step 3. Follow the instructions listed there both for installing the desktop app and for
using the web app.
Note that if you want to use the web app only at this point, just navigate to
www.pearsontestprep.com, establish a free login if you do not already have one, and
register this book’s practice tests using the registration code you just found. The process
should take only a couple of minutes.

NOTE Amazon eBook (Kindle) customers: It is easy to miss Amazon’s email that lists
your PTP access code. Soon after you purchase the Kindle eBook, Amazon should send
an email. However, the email uses very generic text and makes no specific mention of
PTP or practice exams. To find your code, read every email from Amazon after you pur-
chase the book. Also do the usual checks for ensuring your email arrives, like checking
your spam folder.

BOOK.indb 31 19/05/22 5:49 PM

 xxxii Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

NOTE Other eBook customers: As of the time of publication, only the publisher and
Amazon supply PTP access codes when you purchase their eBook editions of this book.

How to Use This Book

Although this book could be read cover-to-cover, it is designed to be flexible and allow
you to easily move between chapters and sections of chapters to cover just the material
that you need more work with. This book was written to include not only reference mate-
rials and study guides for the exam but also rich reference material for your day-to-day
technical requirements.

The core chapters, Chapters 1 through 17, cover the following topics:

■ Chapter 1, “Software Development Essentials”: This chapter introduces software

architecture, architecture requirements, and software development models.

■ Chapter 2, “Software Quality Attributes”: This chapter discusses in detail quality

attributes or nonfunctional requirements and discusses in detail modularity, scalabil-
ity, and high availability in application design.

■ Chapter 3, “Architectural Considerations and Performance Management”: This

chapter continues to discuss another set of nonfunctional requirements and how
they relate to design trade-offs. It discusses performance, observability, and database
selection criteria.

■ Chapter 4, “Version Control and Release Management with Git”: This chapter dis-
cusses the basics of version control, Git’s way of managing version controls and col-
laboration, and then covers in detail branching strategies and why they’re important
for the success of any project.

■ Chapter 5, “Network APIs”: This chapter covers how software developers can use
application programming interfaces (APIs) to communicate with and configure net-
works and how APIs are used to communicate with applications and other software.

■ Chapter 6, “API Development”: This chapter focuses on application programming

interface development and covers both API design and API architecture.

■ Chapter 7, “Application Deployment”: This chapter covers the code-to-production

process, including organizational structures, responsibilities, and tooling required.
Historical as well as current deployment models are discussed, as well as design fac-
tors to enable portable applications between hosting locations.

■ Chapter 8, “Security in Application Design”: This chapter discusses security

practices for application development. It starts by defining privacy and personally
identifiable information and how to protect them. Then it covers the public key
infrastructure (PKI), how to secure web applications, and the OAuth Authorization
framework.

BOOK.indb 32 19/05/22 5:49 PM

 Introduction xxxiii

■ Chapter 9, “Infrastructure”: This chapter covers aspects of network infrastructure

management and automation. Some historical context is provided, but exam prepa-
ration is focused on newer programmability features that enable automation and
orchestration.

■ Chapter 10, “Automation”: This chapter covers topics such as SDN, APIs, and
orchestration. Additional helpful context is provided around the impact to IT service
management.

■ Chapter 11, “NETCONF and RESTCONF”: This chapter covers the NETCONF,
YANG, and RESTCONF technologies with examples that will be helpful in your
preparation and professional use.

■ Chapter 12, “Model-Driven Telemetry”: This chapter is focused on model-driven

telemetry, its purpose, and how it is implemented. In support of your learning, exam
preparation, and professional use, there are also examples for using MDT.

■ Chapter 13, “Open-Source Solutions”: This chapter covers several open-source

solutions that are helpful in many environments. Examples for deployment and usage
provide insight and help inform your implementation decisions.

■ Chapter 14, “Software Configuration Management”: This chapter discusses soft-

ware configuration management: what is it, why is it important, and how do you
decide which system is best for your project? We also discuss Ansible and Terraform
and their strengths and weaknesses.

■ Chapter 15, “Hosting an Application on a Network Device”: This chapter provides

insights on how to run containerized workloads on a network device. Some best
practices are also shared to encourage your best uses.

■ Chapter 16, “Cisco Platforms”: Finally, this chapter contains a mix of practical API
and SDK usage examples across several platforms, such as Webex, Meraki, Intersight,
DNA Center, and AppDynamics. If you have some of these solutions, the examples
should reveal methods to integrate with them programmatically. If you don’t use the
platforms, this chapter should reveal the “art of the possible.”

■ Chapter 17, “Final Preparation”: This chapter details a set of tools and a study plan
to help you complete your preparation for the DEVCOR 350-901 exam.

Certification Exam Topics and This Book

The questions for each certification exam are a closely guarded secret. However, we do
know which topics you must know to successfully complete this exam. Cisco publishes
them as an exam blueprint for the DevNet Professional DEVCOR 350-901 exam.
Table I-1 lists each exam topic listed in the blueprint along with a reference to the book
chapter that covers the topic. These are the same topics you should be proficient in when
working with network programmability and automation in the real world.

BOOK.indb 33 19/05/22 5:49 PM

 xxxiv Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Table I-1 DEVCOR 350-901 Exam Topics and Chapter References

DEVCOR 350-901 Exam Topic Chapter(s) in Which Topic Is

Covered
1.0 Software Development and Design Chapter 1
1.1 Describe distributed applications related to the Chapter 2
concepts of front-end, back-end, and load balancing
1.2 Evaluate an application design considering scalability Chapter 2
and modularity
1.3 Evaluate an application design considering Chapter 2
high availability and resiliency (including on-premises,
hybrid, and cloud)
1.4 Evaluate an application design considering latency and Chapter 3
rate limiting
1.5 Evaluate an application design and implementation Chapter 3
considering maintainability
1.6 Evaluate an application design and implementation Chapter 3
considering observability
1.7 Diagnose problems with an application given logs Chapter 3
related to an event
1.8 Evaluate choice of database types with respect to Chapter 3
application requirements (such as relational, document,
graph, columnar, and time series)
1.9 Explain architectural patterns (monolithic, services Chapter 2
oriented, microservices, and event driven)
1.10 Utilize advanced version control operations with Git Chapter 4
1.10.a Merge a branch
1.10.b Resolve conflicts
1.10.c git reset
1.10.d git checkout
1.10.e git revert
1.11 Explain the concepts of release packaging and Chapter 4
dependency management
1.12 Construct a sequence diagram that includes API calls Chapter 5
2.0 Using APIs Chapter 5
2.1 Implement robust REST API error handling for Chapter 6
timeouts and rate limits
2.2 Implement control flow of consumer code for Chapter 6
unrecoverable REST API errors
2.3 Identify ways to optimize API usage through HTTP Chapter 6
cache controls
2.4 Construct an application that consumes a REST API Chapter 6
that supports pagination
2.5 Describe the steps in the OAuth2 three-legged Chapter 8
authorization code grant flow

BOOK.indb 34 19/05/22 5:49 PM

 Introduction xxxv

DEVCOR 350-901 Exam Topic Chapter(s) in Which Topic Is

Covered
3.0 Cisco Platforms Chapter 16
3.1 Construct API requests to implement ChatOps with Chapter 16
Webex Teams API
3.2 Construct API requests to create and delete objects Chapter 16
using Firepower device management (FDM)
3.3 Construct API requests using the Meraki platform to Chapter 16
accomplish these tasks
3.3.a Use Meraki Dashboard APIs to enable an SSID
3.3.b Use Meraki location APIs to retrieve location data
3.4 Construct API calls to retrieve data from Intersight Chapter 16
3.5 Construct a Python script using the UCS APIs to Chapter 16
provision a new UCS server given a template
3.6 Construct a Python script using the Cisco DNA Chapter 16
Center APIs to retrieve and display wireless health
information
3.7 Describe the capabilities of AppDynamics when Chapter 16
instrumenting an application
3.8 Describe steps to build a custom dashboard to present Chapter 16
data collected from Cisco APIs
4.0 Application Deployment and Security Chapter 8
4.1 Diagnose a CI/CD pipeline failure (such as missing Chapter 7
dependency, incompatible versions of components, and
failed tests)
4.2 Integrate an application into a prebuilt CD Chapter 7
environment leveraging Docker and Kubernetes
4.3 Describe the benefits of continuous testing and static Chapter 7
code analysis in a CI pipeline
4.4 Utilize Docker to containerize an application Chapter 15
4.5 Describe the tenets of the “12-factor app” Chapter 7
4.6 Describe an effective logging strategy for an Chapter 7
application
4.7 Explain data privacy concerns related to storage and Chapter 8
transmission of data
4.8 Identify the secret storage approach relevant to a given Chapter 8
scenario
4.9 Configure application specific SSL certificates Chapter 8
4.10 Implement mitigation strategies for OWASP threats Chapter 8
(such as XSS, CSRF, and SQL injection)
4.11 Describe how end-to-end encryption principles apply Chapter 8
to APIs

BOOK.indb 35 19/05/22 5:49 PM

 xxxvi Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

DEVCOR 350-901 Exam Topic Chapter(s) in Which Topic Is

Covered
5.0 Infrastructure and Automation Chapters 9 and 10
5.1 Explain considerations of model-driven telemetry Chapter 12
(including data consumption and data storage)
5.2 Utilize RESTCONF to configure a network device Chapter 11
including interfaces, static routes, and VLANs (IOS XE only)
5.3 Construct a workflow to configure network Chapter 13
parameters with:
5.3.a Ansible playbook
5.3.b Puppet manifest
5.4 Identify a configuration management solution to Chapter 14
achieve technical and business requirements
5.5 Describe how to host an application on a network Chapter 15
device (including Catalyst 9000 and Cisco IOx-enabled
devices)

Each version of the exam can have topics that emphasize different functions or features,
and some topics can be rather broad and generalized. The goal of this book is to provide
the most comprehensive coverage to ensure that you are well prepared for the exam.
Although some chapters might not address specific exam topics, they provide a founda-
tion that is necessary for a clear understanding of important topics. Your short-term goal
might be to pass this exam, but your long-term goal should be to become a qualified net-
work developer.

It is also important to understand that this book is a “static” reference, whereas the
exam topics are dynamic. Cisco can and does change the topics covered on certification
exams often.

This exam guide should not be your only reference when preparing for the certification
exam. You can find a wealth of information available at Cisco.com that covers each topic
in great detail. If you think that you need more detailed information on a specific topic,
read the Cisco documentation that focuses on that topic.

Note that as automation technologies continue to develop, Cisco reserves the right to
change the exam topics without notice. Although you can refer to the list of exam topics
in Table I-1, always check Cisco.com to verify the actual list of topics to ensure that you
are prepared before taking the exam. You can view the current exam topics on any current
Cisco certification exam by visiting the Cisco.com website, choosing Menu, and Training &
Events, then selecting from the Certifications list. Note also that, if needed, Cisco Press
might post additional preparatory content on the web page associated with this book at
http://www.ciscopress.com/title/9780137370443. It’s a good idea to check the website a
couple of weeks before taking your exam to be sure that you have up-to-date content.

BOOK.indb 36 19/05/22 5:49 PM

 xxxvii

Credits
Figure 4-1 through Figure 4-29, Figure 4-32 through Figure 4-34, Figure 6-8, Figure 6-9,
Figure 11-10, Figure 11-11, Figure 12-6, Figure 12-27, Figure 12-28: GitHub, Inc

Figure 5-3 through Figure 5-6, Figure 6-10, Figure 6-11, Figure 6-13: IMDb-API

Figure 5-8, Figure 11-14 through Figure 11-19, Figure 16-16 through Figure 16-19,
Figure 16-31, Figure 16-41 through Figure 16-43: Postman, Inc

Figure 6-1 through Figure 6-7: SmartBear Software

Figure 7-3 through Figure 7-5: HootSuite Media Inc

Figure 7-7, Figure 7-8: Weaveworks, Inc

Figure 7-10, Figure 7-11: Jupyter

Figure 7-9, Figure 7-12 through Figure 7-16: Amazon Web Services, Inc

Figure 8-7 through Figure 8-10: DigiCert, Inc

Figure 9-3: Coleman Yuen/Pearson Education Asia Limited

Figure 9-5: vystekimages/Shutterstock

Figure 9-7: faithie/123RF

Figures 9-13 and 9-14, arm icons: De-V/Shutterstock

Figure 10-2: Twitter, Inc

Figure 10-3: Natata/Shutterstock

Figure 10-4: Rawpixel.com/Shutterstock

Figure 10-5: Andrey_Popov/Shutterstock

Figure 10-7 icons: Sergii Korolko/Shutterstock, Vitaly Korovin/Shutterstock,

Gazlast/Shutterstock, dodi31/Shutterstock, Stokkete/Shutterstock, Pavel Ignatov/
Shutterstock

Figure 10-12: Tribalium/Shutterstock, KJBevan/Shutterstock

Figure 12-21 through Figure 12-25, Figure E-1, Figure E-2: Grafana Labs

Logo in Figure 13-3: Puppet

Figure 13-5: Puppet

Figure 13-6, Figure 14-6 through Figure 14-8: HashiCorp

Figure 16-44, Figure 16-45: AppDynamics

Table 2-2: Permission to reproduce extracts from British Standards is granted by BSI
Standards Limited (BSI). No other use of this material is permitted. British Standards can
be obtained in PDF or hard copy formats from the BSI online shop: https://shop.
bsigroup.com/.

A01_Davis_FM_pi-pxxxvii.indd 37 20/05/22 9:55 PM

 CHAPTER 10

Automation

This chapter covers the following topics:

■ Challenges Being Addressed: This section identifies the challenges that need to be
addressed with the advent of software-defined networking, DevOps, and network
programmability.

■ Software-Defined Networking (SDN): This section covers the genesis of software-

defined networking, its purpose, and the value gained.

■ Application Programming Interfaces (APIs): This section provides guidance around

application programming interfaces. Network engineering and operations were very
different before APIs; some environments are still resistant to change, but the benefits
outweigh the risks of not embracing them.

■ REST APIs: This section provides insights to the functionality and benefit of REST
APIs and how they are used.

■ Cross-Domain, Technology-Agnostic Orchestration: This section contains material

that is not covered in the DEVCOR certification test. However, as network IT con-
tinues to transform, it provides an important consideration for the transformation of
environments.

■ Impact to IT Service Management and Security: This section acknowledges the

influence of IT service management and security to network programmability. With
so many companies investing in ITIL and TOGAF methodologies in the early 2010s,
understanding the alignments is helpful.

This chapter maps to the second part of the Developing Applications Using Cisco
Core Platforms and APIs v1.0 (350-901) Exam Blueprint Section 5.0, “Infrastructure and
Automation.”
As we’ve learned about the infrastructure involved in network IT and see the continued
expansion, we also recognize that static, manual processes can no longer sustain us. When
we were managing dozens or hundreds of devices using manual methods of logging in to ter-
minal servers, through a device’s console interface, or through inband connectivity via SSH,
it may have been sufficient. However, now we are dealing with thousands, tens of thousands,
and in a few projects I’ve been on, hundreds of thousands of devices. It is simply untenable
to continue manual efforts driven by personal interaction. At some point, these valuable
engineering, operations, and management resources must be refocused on more impactful
activities that differentiate the business. So, automation must be embraced. This chapter
covers some key concepts related to automation: what challenges need to be addressed, how
SDN and APIs enable us, and the impact to IT service management and security.

BOOK.indb 310 19/05/22 5:53 PM

 “Do I Know This Already?” Quiz
The “Do I Know This Already?” quiz allows you to assess whether you should read this
entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in
doubt about your answers to these questions or your own assessment of your knowledge
of the topics, read the entire chapter. Table 10-1 lists the major headings in this chapter and
their corresponding “Do I Know This Already?” quiz questions. You can find the answers in
Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes.”

Table 10-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section Questions
Challenges Being Addressed 1–5
Software-Defined Networking (SDN) 6
Application Programming Interfaces (APIs) 11
REST APIs 7–10

1. When you are considering differences in device types and function, which technology
provides the most efficiencies?
a. Template-driven management
b. Model-driven management
c. Atomic-driven management
d. Distributed EMSs
2. The SRE discipline combines aspects of _______ engineering with _______ and
_______.
a. Hardware, software, firmware
b. Software, infrastructure, operations
c. Network, software, DevOps
d. Traffic, DevOps, SecOps
3. What do the Agile software development practices focus on?
a. Following defined processes of requirements gathering, development, testing, QA,
and release.
b. Giving development teams free rein to engineer without accountability.
c. Pivoting from development sprint to sprint based on testing results.
d. Requirements gathering, adaptive planning, quick delivery, and continuous
improvement.
4. Of the software development methodologies provided, which uses a more visual
approach to the what-when-how of development?
a. Kanban
b. Agile
c. Waterfall
d. Illustrative

BOOK.indb 311 19/05/22 5:53 PM

 312 Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

5. Concurrency focuses on _______ lots of tasks at once. Parallelism focuses on _______

lots of tasks at once.
a. Doing; working with
b. Exchanging; switching
c. Threading; sequencing
d. Working with; doing
6. The _______ specification, originally the _______ specification, defines a model for
machine-readable interface files for describing, producing, consuming, and visualizing
RESTful web services.
a. OpenAPI; Swagger
b. REST; CLI
c. SDN; Clean Slate
d. OpenWeb; CORBA
7. What would be the correct method to generate a basic authentication string on a
macOS/Linux CLI?
a. echo -n 'username:password' | openssl md5
b. echo -n 'username:password' | openssl
c. echo -n 'username:password' | openssl base64
d. echo -n 'username&password' | openssl base64
8. What does XML stand for?
a. Extendable machine language
b. Extensible markup language
c. Extreme machine learning
d. Extraneous modeling language
9. In JSON, what are records or objects denoted with?
a. Angle braces < >
b. Square brackets [ ]
c. Simple quotes “ ”
d. Curly braces { }
10. Which REST API HTTP methods are both idempotent?
a. PATCH, POST
b. HEAD, GET
c. POST, OPTIONS
d. PATCH, HEAD
11. Which are APIs? (Choose two.)
a. REST
b. RMON
c. JDBC
d. SSH

BOOK.indb 312 19/05/22 5:53 PM

 Chapter 10: Automation 313

Foundation Topics
Challenges Being Addressed
As described in the chapter introduction, automation is a necessity for growing sophis-
ticated IT environments today. Allow me to share a personal example: if you’ve been to a
CiscoLive conference in the US, it is common to deploy a couple thousand wireless access
points in the large conference venues in Las Vegas, San Diego, and Orlando. I’m talking a
million square feet plus event spaces.
Given that the network operations center (NOC) team is allowed onsite only four to five
days before the event starts, that’s not enough time to manually provision everything with
a couple dozen event staff volunteers. The thousands of wireless APs are just one aspect
of the event infrastructure (see Figure 10-1). There are still the 600+ small form-factor
switches that must be spread across the venue to connect breakout rooms, keynote areas,
World of Solutions, testing facilities and labs, the DevNet pavilion, and other spaces (see
Figure 10-2).

Figure 10-1 Moving a Few Wireless APs

10

BOOK.indb 313 19/05/22 5:53 PM

 314 Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Figure 10-2 Lots of Equipment to Stage

Automation is a “do or die” activity for our businesses: without it, we overwork individuals
and that impacts the broader organization. Automation must also extend beyond provision-
ing into the wide-scale collection of performance, health, and fault information.
Discerning companies are investigating how artificial intelligence and machine learning (AI/
ML) can benefit them in obtaining new operational insights and reducing human effort even
more.
We might even acknowledge “change is hard and slow.” If you started networking after prior
experience with a more programmatic environment or dealt with other industries where mass
quantities of devices were managed effectively, you might wonder why network IT lags. This
is a fair question, but also to be fair, enormous strides have been made in the last 10 years
with an industry that found its start in ARPANET at the end of the 1960s. Cisco incorpo-
rated in 1984, and the industry has been growing in scale and functionality ever since.
Being involved in the latter part of the first wave of network evolution has been a constant
career of learning and advancing skills development. The change and expansion of scope and
function with networking have been very interesting and fulfilling for me.

Differences of Equipment and Functionality

Some of the challenges with networking deal with the diversity of equipment and function-
ality. In the last part of the 1960s and early 1970s, the aforementioned ARPANET included
few network protocols and functions. A router’s purpose was to move traffic across different,
isolated network segments of specialized endpoints. The industry grew with shared media
technologies (hubs), then to switches. Businesses started acquiring their own servers; they
weren’t limited to government agencies and the development labs of colleges and universities.
Slowly, home PCs contributed to a burgeoning technology space.

BOOK.indb 314 19/05/22 5:53 PM

 Chapter 10: Automation 315

Connectivity technology morphed from more local-based technologies like token ring and
FDDI to faster and faster Ethernet-based solutions, hundred megabit and gigabit local inter-
faces, also influencing the speed of WAN technologies to keep up.
Switches gave advent to more intelligent routing and forwarding switches. IP-based telephony
was developed. Who remembers that Cisco’s original IP telephony solution, Call Manager,
was originally delivered as a compact disc (CD), as much software was?
Storage was originally directly connected but then became networked, usually with different
standards and protocols. The industry then accepted the efficiencies of a common, IP-based
network. The rise of business computing being interconnected started influencing home
networking. Networks became more interconnected and persistent. Dial-up technologies and
ISDN peaked and started a downward trend in light of always-on cable-based technologies
to the home. Different routing protocols needed to be created. Multiple-link aggregation
requirements needed to be standardized to help with resiliency.
Wireless technologies came on the scene. Servers, which had previously been mere end-
points to the network, now became more integrated. IPv6. Mobile technologies. A lot of
hardware innovations but also a lot of protocols and software developments came in parallel.
So why the history lesson? Take them as cases in point of why networking IT was slow in
automation. The field was changing rapidly and growing in functionality. The scope and pace
of change in network IT were unlike those in any other IT disciplines.
Unfortunately, much of the early development relied on consoles and the expectation of a
human administrator always creating the service initially and doing the sustaining changes.
The Information Technology Information Library (ITIL) and The Open Group Architecture
Framework (TOGAF) service management frameworks helped the industry define structure
and operational rigor. Some of the concepts seen in Table 10-2 reflect a common vocabulary
being established.

Table 10-2 Operational Lifecycle

Operational Perspective Function
Day-0 Initial installation
Day-1 Configuration for production purpose
Day-2 Compliance and optimization
Day-X Migration/decommissioning

The full lifecycle of a network device or service must be considered. All too often the “spin-
up” of a service is the sole focus. Many IT managers have stories about finding orphaned
recurring charges from decommissioned systems. Migrating and decommissioning a service
are just as important as the initial provisioning. We must follow up on reclaiming precious
consumable resources like disk space, IP addresses, and even power. 10
In the early days of compute virtualization, Cisco had an environment called CITEIS—Cisco
IT Elastic Infrastructure Services, which were referred to as “cities.” CITEIS was built to pro-
mote learning, speed development, and customer demos, and to prove the impact of automa-
tion. A policy was enacted that any engineer could spin up two virtual machines of any kind
as long as they conformed to predefined sizing guidelines. If you needed something differ-
ent, you could get it, but it would be handled on an exception basis. Now imagine the num-
ber of people excited to learn a new technology all piling on the system. VMs were spun up;

BOOK.indb 315 19/05/22 5:53 PM

 316 Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

CPU, RAM, disk space, and IP addresses consumed; used once or twice, then never accessed
again. A lot of resources were allocated. In the journey of developing the network program-
mability discipline, network engineers also needed to apply operational best practices. New
functions were added to email (and later send chat messages to) the requester to ensure the
resources were still needed. If a response was not received in a timely fashion, the resources
were archived and decommissioned. If no acknowledgment came after many attempts over
a longer period, the archive may be deleted. These kinds of basic functions formed the basis
of standard IT operations to ensure proper use and lifecycle management of consumable
resources.
With so many different opportunities among routing, switching, storage, compute, collabo-
ration, wireless, and such, it’s also understandable that there was an amount of specialization
in these areas. This focused specialization contributed to a lack of convergence because each
technology was growing in its own right; the consolidation of staff and budgets was not
pressuring IT to solve the issue by building collaborative solutions. But that would change.
As addressed later in the topics covering SDN, the industry was primed for transformation.
In today’s world of modern networks, a difference of equipment and functionality is to be
expected. Certainly, there are benefits recognized with standardizing device models to pro-
vide efficiencies in management and device/module sparing strategies. However, as network
functions are separated, as seen later with SDN, or virtualized, as seen with Network Func-
tion Virtualization (NFV), a greater operational complexity is experienced. To that end, the
industry has responded with model-driven concepts, which we cover in Chapter 11, “NET-
CONF and RESTCONF.” The ability to move from device-by-device, atomic management
considerations to more service and function-oriented models that comprehend the relation-
ships and dependencies among many devices is the basis for model-driven management.

Proximity of Management Tools and Support Staff

Another situation that needed to be addressed was the proximity of management tools and
support staff. Early networks were not as interconnected, persistent, or ingrained to as many
aspects of our lives as they are now. It was common to deploy multiple copies of manage-
ment tools across an environment because the connectivity or basic interface link speed
among sites often precluded using a central management tool. Those were the days of “Hey,
can you drive from Detroit down to Dayton to install another copy of XYZ?”
Support staff existed at many large sites, sometimes with little collaboration among them or
consistency of service delivery across states or countries.
Because early networks often metered and charged on traffic volume across a wide area,
they were almost disincentivized to consolidate monitoring and management. “Why would I
want to run more monitoring traffic and increase my cost? I only want ‘business-critical traf-
fic’ across those WAN links now.” However, fortunately, even this way of thinking changed.
Today networks are more meshed, persistent, highly available, and faster connected. There
is little need to deploy multiple management tools, unless it is purposeful for scale or
functional segmentation. The support teams today may include a “follow the sun” model
where three or four different support centers are spread across the globe to allow personnel
to serve others in their proximate time zone. As businesses experience higher degrees of

BOOK.indb 316 19/05/22 5:53 PM

 Chapter 10: Automation 317

automation and orchestration, there is reduced need for on-shift personnel. Consolidation of
support teams is possible. This pivot to a more on-call or exception-based support model is
desired. The implementation of self-healing networks that require fewer and fewer support
personnel is even more desirable. Google’s concept of site reliability engineering (SRE) is an
example of addressing the industry’s shortcomings with infrastructure and operations sup-
port. The SRE discipline combines aspects of software engineering with infrastructure and
operations. SRE aims to enable highly scalable and reliable systems. Another way of thinking
about SRE is what happens when you tell a software engineer to do an operations role.

Speed of Service Provisioning

With early networks being “small” and “specialized,” there was a certain acceptance to how
long it took to provision new services. The network engineer of the late 1990s and early
2000s might have experienced lead times of many months to get new circuits from their
WAN service provider. However, this was an area of transformation in network IT also. Net-
works became more critical to businesses. Soon, having a web presence, in addition to any
brick-and-mortar location, was a necessity. This would drive a need for faster service provi-
sioning and delivery. Previous manual efforts that included a “truck roll,” or someone driving
to another location, put too much latency into the process.
Businesses that could provide a service in weeks were driving a competitive differentiator to
those that took months. Then this model progressed to those that could provide services in
days versus weeks, and now you see the expectation of minutes, or “while I watch from my
browser.”
Business models have greatly changed. The aforementioned brick-and-mortar model was
the norm. As the Internet flourished, having a web presence became a differentiator, then a
requirement. To that end, so many years later, it is very difficult to find impactful domain
names to register. Or it may cost a lot to negotiate a transfer from another owner!
Today, the physical presence is not required and is sometimes undesirable. More agile busi-
ness models mean companies can be operated out of the owner’s home. Fulfillment can be
handled by others, and the store or marketplace is handled through a larger e-commerce
entity like Amazon, Alibaba, or eBay.
It is impossible to provide services in such a rapid fashion without automation. The customer
sitting at a browser expects to see an order confirmation or expected service access right
then. Indeed, some customers give up and look for alternative offers if their request is not
met as they wait.
This expectation of now forces businesses to consolidate their offers into more consistent or
templatized offers. The more consistent a service can be delivered, the better suited it is for
automation. It’s the exceptions that tend to break the efficiencies of automation and cause
longer service delivery cycles.
10
This rapid pace of service delivery influenced IT service management and development with
DevOps and models like Agile and Lean. Figure 10-3 depicts the Agile methodology.

BOOK.indb 317 19/05/22 5:53 PM

 318 Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Figure 10-3 Agile Methodology

Agile, as a software development practice, focuses on extracting requirements and develop-
ing solutions with collaborative teams and their users. Planning with an adaptive approach to
quick delivery and continuous improvement sets Agile apart from other, less flexible mod-
els. Agile is just one software development methodology, but it has a large following and is
suggested for consideration in your network programmability journey. Several more of the
broad spectrum of methodologies and project management frameworks are described in
Table 10-3.

Table 10-3 Software Development Methodologies and Frameworks

Method Name Description
Agile Flexible and incremental design process focused on collaboration
Kanban Visual framework promoting what, when, and how to develop in
small, incremental changes; complements Agile
Lean Process to create efficiencies and remove waste to produce more
with less
Scrum Process with fixed-length iterations (sprints); follows roles,
responsibilities, and meetings for well-defined structure; derivative
of Agile
Waterfall Sequential design process; fully planned; execution through phases

Whatever model you choose, take time to understand the pros and cons and evaluate against
your organization’s capabilities, culture, motivations, and business drivers. Ultimately, the
right software development methodology for you is the one that is embraced by the most
people in the organization.

BOOK.indb 318 19/05/22 5:53 PM

 Chapter 10: Automation 319

Accuracy of Service Provisioning

Walt Disney is known for sharing this admirable quote, “Whatever you do, do it well.” That
has been the aspiration of any product or service provider. The same thinking can be drawn
to network service provisioning: nobody truly intends to partially deploy a service or to
deploy something that will fail. One reason accuracy of service provisioning struggled before
network programmability hit its stride was due to the lack of programmatic interfaces.
As we mentioned before, much of the genesis of network IT, and dare we say even IT more
broadly, was founded on manual command-line interface interactions. Provisioning a device
meant someone was logging into it and typing or pasting a set of configuration directives.
The task wasn’t quite as bad as that in Figure 10-4, but it sure felt that way!

Figure 10-4 Not Quite This Painful

A slightly more advanced method might be typing or pasting those directives and putting
them into a file to be transferred to the device and incorporated into its running configura-
tion state. However, these manual efforts still required human interaction and an ability to
translate intent to a set of configuration statements.
Some automations were, and sometimes still are, simply the collection and push of those
same CLI commands (see Figure 10-5), but in an unattended fashion by a script or manage-
ment application. 10

BOOK.indb 319 19/05/22 5:53 PM

 320 Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Figure 10-5 Automating the CLI

The fact that the foundation has been based on CLI automation seems to imply that the
industry was conceding the “best” way to interact with a device was through the CLI. A lot
of provisioning automation occurs through CLI with many management applications and
open-source solutions.
Yet the CLI, while suited for human consumption, is not optimal for programmatic use. If
the command syntax or output varies between releases or among products, the CLI-based
solutions need to account for the differences. Consider the command output for show
interface in Example 10-1.
Example 10-1 Show Interface Output

Switch# show interface te1/0/2

TenGigabitEthernet1/0/2 is up, line protocol is up (connected)
Hardware is Ten Gigabit Ethernet, address is 0023.ebdd.4006 (bia 0023.ebdd.4006)
MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 10Gb/s, link type is auto, media type is 10GBase-SR
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:04, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)

BOOK.indb 320 19/05/22 5:53 PM

 Chapter 10: Automation 321

5 minute input rate 5000 bits/sec, 9 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec
200689496 packets input, 14996333682 bytes, 0 no buffer
Received 195962135 broadcasts (127323238 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 127323238 multicast, 0 pause input
0 input packets with dribble condition detected
7642905 packets output, 1360729535 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out

What are the options for extracting information like number of multicast packets output?
The use of Python scripts is in vogue, so let’s consider that with Example 10-2, which
requires a minimum of Python 3.6.
Example 10-2 Python Script to Extract Multicast Packets

import paramiko
import time
import getpass
import re

username = input('Enter Username: ')

userpassword = getpass.getpass('Enter Password: ')
devip = input('Enter Device IP: ')
devint = input('Enter Device Interface: ')

try:
devconn = paramiko.SSHClient()
devconn.set_missing_host_key_policy(paramiko.AutoAddPolicy())
devconn.connect(devip, username=username, password=userpassword,timeout=60)
chan = devconn.invoke_shell()
chan.send("terminal length 0\n")
time.sleep(1)
chan.send(f'show interface {devint}')
time.sleep(2)
10
cmd_output = chan.recv(9999).decode(encoding='utf-8')
devconn.close()
result = re.search('(\d+) multicast,', cmd_output)
if result:
print(f'Multicast packet count on {devip} interface {devint} is {result.
group(1)}')
else:
print(f'No match found for {devip} interface {devint} - incorrect
interface?')

BOOK.indb 321 19/05/22 5:53 PM

 322 Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

except paramiko.AuthenticationException:
print("User or password incorrect - try again")
except Exception as e:
err = str(e)
print(f'ERROR: {err}')

There’s a common theme in methodologies that automate against CLI output which requires
some level of string manipulation. Being able to use regular expressions, commonly called
regex, or the re module in Python, is a good skill to have for CLI and string manipula-
tion operations. While effective, using regex can be difficult skill to master. Let’s call it
an acquired taste. The optimal approach is to leverage even higher degrees of abstraction
through model-driven and structure interfaces, which relieve you of the string manipulation
activities. You can find these in solutions like pyATS (https://developer.cisco.com/pyats/)
and other Infrastructure-as-Code (IaC) solutions, such as Ansible and Terraform.
Product engineers intend to maintain consistency across releases, but the rapid rate of
change and the intent to bring new innovation to the industry often result in changes to
the command-line interface, either in provisioning syntax and arguments or in command-
line output. These differences often break scripts and applications that depend on CLI; this
affects accuracy in service provisioning. Fortunately, the industry recognizes the inefficien-
cies and results of varying CLI syntax and output. Apart from SNMP, which generally lacked
a strong provisioning capability, one of the first innovations to enable programmatic interac-
tions with network devices was the IETF’s NETCONF (network configuration) protocol.
We cover NETCONF and the follow-on RESTCONF protocol in more detail later in this
book. However, we can briefly describe NETCONF as an XML representation of a device’s
native configuration parameters. It is much more suited to programmatic use. Consider now
a device configuration shown in an XML format with Figure 10-6.

Figure 10-6 Partial NETCONF Device Configuration

BOOK.indb 322 19/05/22 5:53 PM

 Chapter 10: Automation 323

Although the format may be somewhat unfamiliar, you can see patterns and understand
the basic structure. It is the consistent structure that allows NETCONF/RESTCONF and an
XML-formatted configuration to be addressed more programmatically. By referring to tags
or paths through the data, you can cleanly extract the value of a parameter without depend-
ing on the existence (or lack of existence) of text before and after the specific parameter(s)
you need. This capability sets NETCONF/RESTCONF apart from CLI-based methods that
rely on regex or other string-parsing methods.
A more modern skillset would include understanding XML formatting and schemas, along
with XPath queries, which provide data filtering and extraction functions.
Many APIs output their data as XML- or JSON-formatted results. Having skills with XPath
or JSONPath queries complements NETCONF/RESTCONF. Again, we cover these topics
later in Chapter 11.
Another way the industry has responded to the shifting sands of CLI is through abstracting
the integration with the device with solutions like Puppet, Chef, Ansible, and Terraform.
Scripts and applications can now refer to the abstract intent or API method rather than a
potentially changing command-line argument or syntax. These also are covered later in this
book.

Scale
Another challenge that needs to be addressed with evolving and growing network is scale.
Although early and even some smaller networks today can get by with manual efforts of a
few staff members, as the network increases in size, user count, and criticality, those models
break. Refer back to Figure 9-19 to see the growth of the Internet over the years.
Scalable deployments are definitely constrained when using CLI-based methodologies, espe-
cially when using paste methodologies because of flow control in terminal emulators and
adapters. Slightly more efficiencies are gained when using CLI to initiate a configuration file
transfer and merge process.
Let me share a personal example from a customer engagement. The customer was dealing
with security access list changes that totaled thousands of lines of configuration text and
was frustrated with the time it took to deploy the change. One easy fix was procedural: cre-
ate a new access list and then flip over to it after it was created. The other advice was show-
ing the customer the inefficiency of CLI flow-control based methods. Because the customer
was copying/pasting the access list, they were restricted by the flow control between the
device CLI and the terminal emulator.

Strike one: CLI/terminal.

Strike two: Size of access list.
Strike three: Time to import. 10
Pasting the customer’s access list into the device’s configuration took more than 10 minutes.
I showed them the alternative of putting the configuration parameters into a file that could
be transferred and merged with the device and the resulting seconds that this approach took
instead. Needless to say, the customer started using a new process.
Using NETCONF/RESTCONF protocols to programmatically collect information and
inject provisioning intent is efficient. In this case, it is necessary to evaluate the extent of

BOOK.indb 323 19/05/22 5:53 PM

 324 Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

deployment to gauge the next level of automation for scale. Here are some questions to ask
yourself:

■ How many devices, nodes, and services do I need to deploy?

■ Do I have dependencies among them that require staggering the change for optimal
availability? Any primary or secondary service relationships?

■ How much time is permitted for the change window, if applicable?

■ How quickly can I revert a change if unexpected errors occur?

Increasingly, many environments have no maintenance windows; there is no time that they
are not doing mission-critical work. They implement changes during all hours of the day
or night because their network architectures support high degrees of resiliency and avail-
ability. However, even in these environments, it is important to verify that the changes being
deployed do not negatively affect the resiliency.
One more important question left off the preceding list for special mention is “How much
risk am I willing to take?” I remember working with a customer who asked, “How many
devices can we software upgrade over a weekend? What is that maximum number?”
Together, we created a project and arranged the equipment to mimic their environment as
closely as possible—device types, code versions, link speeds, device counts. The lab was
massive—hundreds of racks of equipment with thousands of devices. In the final analysis,
I reported, “You can effectively upgrade your entire network over a weekend.” In this case,
it was 4000 devices, which at the time was a decent-sized network. I followed by saying,
“However, I wouldn’t do it. Based on what I know of your risk tolerance level, I would sug-
gest staging changes. The network you knew Friday afternoon could be very different from
the one Monday morning if you run into an unexpected issue.” We obviously pressed for
extensive change testing, but even with the leading test methodologies of the time, we had
to concede something unexpected could happen. We saved the truly large-scale changes for
those that were routine and low impact. For changes that were somewhat new, such as new
software releases or new features and protocols, we established a phased approach to gain
confidence and limit negative exposure.

■ Lab testing of single device(s) representing each model/function

■ Lab testing of multiple devices, including primary/backup peers

■ Lab testing of multiple devices, including primary/backup peers to maximum scale

possible in lab

■ Production deployment of limited device counts in low-priority environments

(10 percent of total)

■ Change observation for one to two weeks (depending on criticality of change)

BOOK.indb 324 19/05/22 5:53 PM

 Chapter 10: Automation 325

■ Production deployment of devices in standard priority environments (25 percent of

total)

■ Change observation for two to four weeks (depending on criticality of change)

■ Second batch deployment in standard priority environments (25 percent of total)

■ Change observation for two to four weeks (depending on criticality of change)

■ Production deployment of devices in high-priority environments (10 percent of total)

■ Change observation for two to four weeks (depending on criticality of change)

■ Second batch deployment of high-priority environments (10 percent of total)

■ Change observation for two to four weeks (depending on criticality of change)

■ Third batch deployment of high-priority environments (20 percent of total)

As you contemplate scale, if you’re programming your own solutions using Python scripts or
similar, it is worthwhile to understand multithreading and multiprocessing. A few definitions
of concurrency and parallelism also are in order.
An application completing more than one task at the same time is considered concurrent.
Concurrency is working on multiple tasks at the same time but not necessarily simultane-
ously. Consider a situation with four tasks executing concurrently (see Figure 10-7). If you
had a virtual machine or physical system with a one-core CPU, it would decide the switching
involved to run the tasks. Task 1 might go first, then task 3, then some of task 2, then all of
task 4, and then a return to complete task 2. Tasks can start, execute their work, and com-
plete in overlapping time periods. The process is effectively to start, complete some (or all)
of the work, and then return to incomplete work where necessary—all the while maintain-
ing state and awareness of completion status. One issue to observe is that concurrency may
involve tasks that have no dependency among them. In the world of IT, an overall workflow
to enable a new web server may not be efficient for concurrency. Consider the following
activities:

1. Create the virtual network.

2. Create the virtual storage volume.
3. Create the virtual machine vCPUs and vMemory.
4. Associate the VM vNet and vStorage.
5. Install the operating system to the VM.
6. Configure the operating system settings.
7. Update the operating system.
10
8. Install the Apache service.
9. Configure the Apache service.

BOOK.indb 325 19/05/22 5:53 PM

 326 Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Figure 10-7 Workflow Creating a Web Server

Several of these steps depend on a previous step being completed. So, this workflow is not
well suited to concurrency. However, deploying software images to many devices across the
network would be well suited. Consider these actions on a multidevice upgrade process (see
Figure 10-8):

1. Configure Router-A to download new software update (wait for it to process, flag it to
return to later, move on to next router), then . . .
2. Configure Router-B to download new software update (wait for it to process, flag it to
return to later, move on to next router), then . . .
3. Configure Router-C to download new software update (wait for it to process, flag it to
return to later, move on to next router), then . . .
4. Check Router-A status—still going—move on to next router.
5. Configure Router-D to download new software update (wait for it to process, flag it to
return to later, move on to next router).
6. Check Router-B status—complete—remove flag to check status; move to next router.
7. Configure Router-E to download new software update (wait for it to process, flag it to
return to later, move on to next router).
8. Check Router-A status—complete—remove flag to check status; move to next router.
9. Check Router-C status—complete—remove flag to check status; move to next router.
10. Check Router-D status—complete—remove flag to check status; move to next router.
11. Check Router-E status—complete—remove flag to check status; move to next router.

BOOK.indb 326 19/05/22 5:53 PM

 Chapter 10: Automation 327

Router-A

Router-B

Router-C

Router-D

Router-E

Figure 10-8 Concurrency Example

Parallelism is different in that an application separates tasks into smaller activities to process
in parallel on multiple CPUs simultaneously. Parallelism doesn’t require multiple tasks to
exist. It runs parts of the tasks or multiple tasks at the same time using multicore functions
of a CPU. The CPU handles the allocation of each task or subtask to a core.
Returning to the previous software example, consider it with a two-core CPU. The following
actions would be involved in this multidevice upgrade (see Figure 10-9):

1. Core-1: Configure Router-A to download new software update (wait for it to process, flag
it to return to later, move on to next router), while at the same time on another CPU . . .
2. Core-2: Configure Router-B to download new software update (wait for it to process,
flag it to return to later, move on to next router).
3. Core-1: Configure Router-C to download new software update (wait for it to process,
flag it to return to later, move on to next router).
4. Core-1: Check Router-A status—still going—move on to next router.
5. Core-2: Configure Router-D to download new software update (wait for it to process,
flag it to return to later, move on to next router).
6. Core-2: Check Router-B status—complete—remove flag to check status; move to next
router.
7. Core-2: Configure Router-E to download new software update (wait for it to process,
flag it to return to later, move on to next router).
8. Core-1: Check Router-A status—complete—remove flag to check status; move to next 10
router.
9. Core-1: Check Router-C status—complete—remove flag to check status; move to next
router.
10. Core-1: Check Router-D status—complete—remove flag to check status; move to next
router.
11. Core-2: Check Router-E status—complete—remove flag to check status; move to next
router.

BOOK.indb 327 19/05/22 5:53 PM

 328 Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Router-A

Router-B

Router-C

Router-D

Router-E
Figure 10-9 Parallelism Example
Because two tasks are executed simultaneously, this scenario is identified as parallelism. Par-
allelism requires hardware with multiple processing units, cores, or threads.
To recap, a system is concurrent if it can support two or more tasks in progress at the same
time. A system is parallel if it can support two or more tasks executing simultaneously. Con-
currency focuses on working with lots of tasks at once. Parallelism focuses on doing lots of
tasks at once.
So, what is the practical application of these concepts? In this case, I was dealing with the
Meraki Dashboard API; it allows for up to five API calls per second. Some API resources
like Get Organization (GET /organizations/{organizationId}) have few key-values to return,
so they are very fast. Other API resources like Get Device Clients (GET /devices/{serial}/cli-
ents) potentially return many results, so they may take more time. Using a model of parallel-
ism to send multiple requests across multiple cores—allowing for some short-running tasks
to return more quickly than others and allocating other work—provides a quicker experience
over doing the entire process sequentially.
To achieve this outcome, I worked with the Python asyncio library and the semaphores feature
to allocate work. I understood each activity of work had no relationship or dependency on
the running of other activities; no information sharing was needed, and no interference across
threads was in scope, also known as thread safe. The notion of tokens to perform work was
easy to comprehend. The volume of work was created with a loop building a list of tasks; then
the script would allocate as many tokens as were available in the semaphore bucket. When the

BOOK.indb 328 19/05/22 5:53 PM

 Chapter 10: Automation 329

script first kicked off, it had immediate access to do parallel processing of the four tokens I
had allocated. As short-running tasks completed, tokens were returned to the bucket and made
available for the next task. Some tasks ran longer than others, and that was fine because the
overall model was not blocking other tasks from running as tokens became available.

Doing More with Less

Continuing in the theme of challenges being addressed, we must acknowledge the busi-
ness pressures of gaining efficiencies to reduce operation expenses (OpEx) and potentially
improve margins, if applicable. Network IT varies between a necessary cost center and a
competitive differentiating profit center for many businesses. It is not uncommon for the
cost center–focused businesses to manage budgets by reducing resources and attempting to
get more productivity from those remaining. The profit center–focused businesses may do
the same, but mostly for margin improvement.
Automation, orchestration, and network programmability provide the tools to get more done
with less. If tasks are repetitive, automation reduces the burden—and burnout—on staff.
Team members are able to focus on more strategic and fulfilling endeavors.
In reflection with the previous section on scale, if you have a lot of tasks that would benefit
from parallel execution, if they are not dependent on each other, then it makes sense to allo-
cate more threads/cores to the overall work. Efficient use of existing resources is desirable. It
is a waste of resources if a system with many cores is often idle.
When building automated solutions, observe the tasks and time the original manual pro-
cess from end to end. After you have automated the process, measure the runtime of the
newly automated process and provide reporting that shows time and cost savings with the
automation. Having practical examples of return on investment (ROI) helps decision makers
understand the benefits of automation and encourage its implementation. You’re building the
automation; you can create your own telemetry and instrumentation!

Software-Defined Networking (SDN)

The catalyst for software-defined networking is largely attributed to Stanford University’s
Clean Slate Program in 2008. Cisco was a sponsor of this project, which reimagined what a
new Internet would look like if we set aside conventional norms of traditional networks and
worked from a clean slate. It was difficult to develop next-generation routing or connectivity
protocols if the equipment available was purposely programmed to follow the original con-
ventions. Programmable logic arrays (PLAs) were pretty expensive to test theories, so a more
software-based approach was proposed.

What Is SDN and Network Programmability?

Definitions of SDN and network programmability varied among network IT vendors, but
some points were generally agreed upon. As illustrated in Figure 10-10, SDN is 10
■ An approach and architecture in networking where control and data planes are decou-
pled, and intelligence and state are logically centralized

■ An enabling technology where the underlying network infrastructure is abstracted

from the applications (network virtualization)

■ A concept that leverages programmatic interfaces to enable external systems to influ-

ence network provisioning, control, and operations

BOOK.indb 329 19/05/22 5:53 PM

 330 Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Figure 10-10 The SDN Concept

Although all of these definitions were exciting and transformative, the last item of leverag-
ing programmatic interfaces appeals mostly to the network programming crowd. The last
item also enables us to influence the first two through provisioning and monitoring network
assets.
In my talks at CiscoLive, I would share that SDN was

■ An approach to network transformation*

■ Empowering alternative, nontraditional entities to influence network design and opera-

tions

■ Impacting the networking industry, challenging the way we think about engineering,
implementing, and managing networks

■ Providing new methods to interact with equipment and services via controllers and
APIs

■ Normalizing the interface with equipment and services

■ Enabling high-scale, rapid network and service provisioning and management

■ Providing a catalyst for traditional route/switch engineers to branch out

Approach
So, why the asterisk next to an approach to network transformation? Well, it wasn’t the first
attempt at network transformation. If we consider separation of the control plane and data
plane, we can look no further than earlier technologies, such as SS7, ATM LANE, the wire-
less LAN controller, and GMPLS. If we were considering network overlays/underlays and
encapsulation, the earlier examples were MPLS, VPLS, VPN, GRE Tunnels, and LISP. Finally,
if our consideration was management and programmatic interfaces, we had SNMP, NET-
CONF and EEM. Nonetheless, SDN was a transformative pursuit.

BOOK.indb 330 19/05/22 5:53 PM

 Chapter 10: Automation 331

Nontraditional Entities
What about those nontraditional entities influencing the network? As new programmatic
interfaces were purposely engineered into the devices and controllers, a new wave of net-
work programmers joined the environment. Although traditional network engineers skilled
up to learn programming (and that may be you, reading this book!), some programmers who
had little prior networking experience decided to try their hand at programming a network.
Or the programmers decided it was in their best interests to configure an underpinning net-
work for their application themselves, rather than parsing the work out to a network provi-
sioning team.
Regardless of the source of interaction with the network, it is imperative that the new inter-
faces, telemetry, and instrumentation be secured with the same, if not more, scrutiny as the
legacy functions. The security policies can serve to protect the network from unintentional
harm by people who don’t have deep experience with the technology and from the inten-
tional harm of bad actors.

Industry Impact
The impact to the network industry with operations and engineering was greatly influenced
by control plane and data plane separation and the development of centralized controllers.
The network management teams would no longer work as hard to treat each network asset as
an atomic unit but could manage a network en masse through the controller. One touchpoint
for provisioning and monitoring of all these devices! The ACI APIC controller is acknowl-
edged as one of the first examples of an SDN controller, as seen in Figure 10-11. It was able
to automatically detect, register, and configure Cisco Nexus 9000 series switches in a data
center fabric.

Spine Switches
ACI ACI

ACI ACI ACI ACI

Leaf Switches

Physical ESX Server

APIC

VM1 VM2

APIC APIC

10
Figure 10-11 Cisco ACI Architecture with APIC Controllers
New Methods
With respect to new methods, protocols, and interfaces to managed assets, APIs became
more prolific with the SDN approach. Early supporting devices extended a style of REST-
like interface and then more fully adopted the model. First NETCONF and then RESTCONF
became the desired norm. Centralized controllers, like the wireless LAN controller, ACI’s

BOOK.indb 331 19/05/22 5:53 PM

 332 Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

APIC controller, Meraki, and others, prove the operational efficiency of aggregating the
monitoring and provisioning of fabrics of devices. This model has coaxed the question
“What else can we centralize?”

Normalization
SDN’s impact on network normalization is reflected in the increasingly standardized inter-
faces. While SNMP had some utility, SDN provided a fresh opportunity to build and use
newer management technologies that had security at their core, not just a “bolt-on” consid-
eration. Although the first API experiences felt a bit like the Wild Wild West, the Swagger
project started to define a common interface description language to REST APIs. Swagger
has since morphed into the OpenAPI initiative, and specification greatly simplifies API
development and documentation tasks.

Enabling Operations
Network operations, service provisioning, and management were influenced with SDN
through the new interfaces, their standardization, and programmatic fundamentals. Instead
of relying on manual CLI methods, operators began to rely on their growing knowledge base
of REST API methods and sample scripts in growing their operational awareness and ability
to respond and influence network functions.
Besides the REST API, other influences include gRPC Network Management Interface
(gNMI), OpenConfig, NETCONF, RESTCONF, YANG, time-series databases, AMQP pub-
sub architectures, and many others.

Enabling Career Options

Finally, SDN provided traditional network engineers an opportunity to extend their skills
with new network programming expertise. The traditional network engineer with years of
domain experience could apply that knowledge in an impactful way with these program-
matic interfaces. They could deploy more services at scale, with fewer errors and more
quickly.
How impactful could SDN be? Let’s consider the early days of IP telephony: it didn’t ramp
up as quickly as desired. On one side there were the traditional “tip-ring telco” team mem-
bers; on the other side was the new “packet-switch” team. IP telephony technology was slow
to gain momentum because few individuals crossed the aisle to learn the other side and
become change and translation agents for the greater good. When people started to under-
stand and share the nuanced discipline of the other side, then SDN started to make strides.
Network programmability is in that same transition: there are strong network engineers who
understand their tradition route/switch technology. Likewise, there are very strong software
developers who understand how to build apps and interact with systems; they just don’t have
the network domain expertise. As network engineers skill up with the automation and net-
work programming discipline, they bring their experience of networks with them. So, let’s
do IT!

Use Cases and Problems Solved with SDN

SDN aimed to address several use cases. The research and academic communities were look-
ing for ways to create experimental network algorithms and technologies. The hope was to
turn these into new protocols, standards, and products. Because existing products closely

BOOK.indb 332 19/05/22 5:53 PM

 Chapter 10: Automation 333

adhered to well-defined routing protocol specifications, SDN was to help separate the cur-
rent norms from new, experimental concepts.
The massively scalable data center community appreciated SDN for the ability to separate
the control plane from the data plane and use APIs to provide deep insight into network traf-
fic. Cloud providers drew upon SDN for automated provisioning and programmable network
overlays. Service providers aligned to policy-based control and analytics to optimize and
monetize service delivery. Enterprise networks latched onto SDN’s capability to virtualize
workloads, provide network segmentation, and orchestrate security profiles.
Nearly all segments realized the benefits of automation and programmability with SDN:

■ Centralized configuration, management control, and monitoring of network devices

(physical or virtual)

■ The capability to override traditional forwarding algorithms to suit unique business or

technical needs

■ The capability of external applications or systems to influence network provisioning

and operation

■ Rapid and scalable deployment of network services with lifecycle management

Several protocols and solutions contributed to the rise of SDN. See Table 10-4 for examples.

Table 10-4 Contributing Protocols and Solutions to SDN

Protocol/Solution Definition Function
OpenFlow Layer-2 programmable
forwarding protocol and
specification for switch
manufacturing
I2RS Interface to Routing System Layer-3 programmable
protocol to the routing
information base (RIB);
allowed manipulation and
creation of new routing
metrics
PCEP Path Computation Element L3 protocol capable of
Protocol computing a network
path or route based on a
network graph and applying
computational constraints
BGP-LS/FS BGP Link-State / Flow Spec The ability to gather IGP 10
topology of the network
and export to a central SDN
controller or alternative
method to remotely triggered
black hole filtering useful for
DDoS mitigation

BOOK.indb 333 19/05/22 5:53 PM

 334 Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Protocol/Solution Definition Function

OpenStack Hypervisor technology for
virtualization of workloads
OMI Open Management Open-source Common
Infrastructure Information Model
with intent to normalize
management
Puppet Agent-based configuration
management solution
embedded in devices (later
updated to agentless)
Ansible Agentless configuration
management solution
NETCONF Network Configuration IETF working group
standard specification normalizing
configuration across vendors
using XML schemas (later
updated with YANG)
YANG Data Modeling Language Data modeling language for
defining IT technologies and
services

Overview of Network Controllers

One of the main benefits of SDN was the notion of control plane and data plane separation.
You can think of the control plane as the brains of the network: it makes forwarding deci-
sions based on interactions with adjacent devices and their forwarding protocols. The data
plane is the muscle, acting on the forwarding decisions programmed into it. Routing proto-
cols like OSPF and BGP operate in the control plane. A link aggregation protocol like LACP
or the MAC address table would be representative of the data plane.
The first traditional networks combined the functionality of the control plane/data plane
into the same device. Each device acted autonomously, creating and executing its own for-
warding decisions. With the advent of SDN, the notion of centralizing that brain function
into one control unit yet keeping the data plane function at the managed device was the new
architectural goal. These centralized controllers aggregated the monitoring and management
function. They oftentimes also provided that centralized forwarding path determination and
programming function.
The separation of functional planes also resulted in the definition of new overlay and under-
lay functionality. Network overlays defined that tunnel endpoints terminated on routers and
switches. The physical devices executed the protocols to handle resiliency and loops. Some
examples are OTV, VXLAN, VPLS, and LISP.
Host overlays defined that tunnel endpoints terminated on virtual nodes. Examples of host
overlays are VXLAN, NVGRE, and STT. Finally, integrated overlays allowed for physical
or virtual endpoints in tunnel termination. The Cisco ACI fabric with Nexus 9000 series
switches are examples of integrated overlays.

BOOK.indb 334 19/05/22 5:53 PM

 Chapter 10: Automation 335

The Cisco Solutions

Cisco has many offerings in the SDN space, the most prominent being the Cisco ACI fabric
with Nexus 9000 series switches. Software-defined access (SDA) is enabled by Cisco DNA
Center on enterprise fabric-enabled devices. Software-defined wide-area networks (SD-
WANs) can be seen in the acquired technologies of Viptela, resulting in the vManage solu-
tion for central cloud management, authentication, and licensing.
Network Function Virtualization (NFV) enables cloud technology to support network func-
tions, such as the Cisco Integrated Services Virtual Router (ISRv), ASAv, and vWLC. The
Cisco Managed Services Accelerator (MSX) provides automated end-to-end SD-WAN ser-
vices managed from the service provider cloud.

Application Programming Interfaces (APIs)

Application programming interfaces are the foundational method for interacting with
devices, applications, controllers, and other networked entities. Although the command-
line interface has reigned supreme for years, we must admit, if an entity has an API, it is the
desirable method for interacting with it.
APIs are common in many fashions: some are application to application, whereas others are
application to hardware entity. Consider some of the following interactions as examples:

■ DNAC software controller API call to Cisco Support API endpoint for opening cases:
software to software

■ Cisco Intersight with UCS IMC for device registration, monitoring, and provisioning
from the cloud: software to hardware

■ Network Services Orchestrator (NSO) to ASR1000 for provisioning and monitoring:

software to hardware

To use an API, you must know the way to make requests, how to authenticate to the service,
how to handle the return results (data encoding), and other conventions it may use, such as
cookies. Public APIs often involve denial-of-service protections beyond authentication, such
as rate limiting the number of requests per time period, the number of requests from an IP
endpoint, and pagination or volume of data returned.
For the purposes of network IT, we mostly focus on web APIs, as we discuss in the next
section on REST APIs, but other common APIs you may experience are the Java Database
Connectivity (JDBC) and Microsoft Open Database Connectivity (ODBC) APIs. JDBC and
ODBC permit connections to different types of databases, such as Oracle, MySQL, and
Microsoft SQL Server, with standard interfaces that ease application development.
The Simple Object Access Protocol (SOAP) is also a well-known design model for web ser-
10
vices. It uses XML and schemas with a strongly typed messaging framework. A web service
definition (WSDL) defines the interaction between a service provider and the consumer. In
Cisco Unified Communications, the Administrative XML Web Service (AXL) is a SOAP-
based interface enabling insertion, retrieval, updates, and removal of data from the Unified
Communication configuration database.
Because a SOAP message has the XML element of an “envelope” and further contains
a “body,” many people draw the parallel of SOAP being like a postal envelope, with the

BOOK.indb 335 19/05/22 5:53 PM

 336 Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

necessary container and the message within, to REST being like a postcard that has none of
the “wrapper” and still contains information. Figure 10-12 illustrates this architecture.

POST /v1/devices

Figure 10-12 Cisco ACI Architecture with APIC Controllers

APIs are used in many Internet interactions—logins, data collection, performance reporting,
analytics. Microservices are associated with APIs as self-contained, lightweight endpoints
that you can interact with to gather data or effect change. They are usually specific to a
function, such as validate login, and are engineered with resiliency in mind, so continuous
integration/continuous deployment (CI/CD) processes allow for routine maintenance without
service impact to users.

REST APIs
RESTful APIs (or representational state transfer APIs) use Web/HTTP services for read and
modification functions. This stateless protocol has several predefined operations, as seen
in Table 10-5. Because it’s a stateless protocol, the server does not maintain the state of a
request. The client’s request must contain all information needed to complete a request, such
as session state.

Table 10-5 REST API Operation Types

Method Function Idempotency Safety/Read-
only Function
GET Reads resource data, settings YES YES
HEAD Tests the API endpoint for validity, YES YES
accessibility, and recent modifications;
similar to GET without response
payload
POST Creates a new resource NO NO
PUT Updates or replaces a resource YES NO
PATCH Modifies changes to a resource (not NO NO
complete replacement)
DELETE Deletes a resource YES NO
CONNECT Starts communications with the YES YES
resource; opens a tunnel
OPTIONS Provides information about the YES YES
capabilities of a resource, without
initiating a resource retrieval function

BOOK.indb 336 19/05/22 5:53 PM

 Chapter 10: Automation 337

API Methods
Another important aspect of a RESTful API is the API method’s idempotency, or capabil-
ity to produce the same result when invoked, regardless of the number of times. The same
request repeated to an idempotent endpoint should return an identical result regardless of
two executions or hundreds.

API Authentication
Authentication to a RESTful API can take any number of forms: basic authentication, API
key, bearer token, OAuth, or digest authentication, to name a few. Basic authentication is
common, where the username is concatenated with a colon and the user’s password. The
combined string is then Base64-encoded. You can easily generate the authentication string
on macOS or other Linux derivatives using the built-in openssl utility. Windows platforms
can achieve the same result by installing OpenSSL or obtaining a Base64-encoding utility.

NOTE Do not use an online website to generate Base64-encoded authentication strings.

You do not know whether the site is logging user input, and security may be undermined.

Example 10-3 shows an example of generating a basic authentication string with openssl on
macOS.
Example 10-3 Generating Base64 Basic Authentication String on MacOS

Mac ~ % echo -n 'myusername:DevNet4U!' | openssl base64

bXl1c2VybmFtZTpEZXZOZXQ0VSE=
Mac ~ %

This method is not considered secure due to the encoding; at a minimum, the connection
should be TLS-enabled so that the weak security model is at least wrapped in a layer of
transport encryption.
Either API key or bearer token is more preferable from a security perspective. These models
require you to generate a one-time key, usually from an administrative portal or user profile
page. For example, you can enable the Meraki Dashboard API by first enabling the API for
your organization: Organization > Settings > Dashboard API access. Then the associated
Dashboard Administrator user can access the My Profile page to generate an API key. The
key can also be revoked and a new key generated at any time, if needed.

API Pagination
API pagination serves as a method to protect API servers from overload due to large data
retrieval requests. An API may limit return results, commonly rows or records, to a specific
count. For example, the DNA Center REST API v2.1.2.x limits device results to 500 records 10
at a time. To poll inventory beyond that, you would use pagination:

GET /dna/intent/api/v1/network-device/{index}/{count}
For example, if you had 1433 devices in inventory, you would use these successive polls:

GET /dna/intent/api/v1/network-device/1/500

GET /dna/intent/api/v1/network-device/501/500

GET /dna/intent/api/v1/network-device/1000/433

BOOK.indb 337 19/05/22 5:53 PM

 338 Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Other APIs may provide different cues that pagination was in effect. The API return results
may include the following parameters:

Records: 2034

First: 0

Last: 999

Next: 1000

Payload Data Formats JSON XML

When dealing with REST APIs, you often need to provide a request payload containing
parameters. The parameters could be anything—username to provision, interface name to
poll, operating system template for a virtual machine. The API response payload body like-
wise has information to be consumed. In either case, it is common to work with XML- or
JSON-formatted data, although others are possible and less common. These two data encod-
ing models are conducive to programmatic use.

XML
The Extensible Markup Language (XML) is a markup language and data encoding model
that has similarities to HTML. It is used to describe and share information in a programmatic
but still humanly readable way.
XML documents have structure and can represent records and lists. Many people look at
XML as information and data wrapped in tags. See Example 10-4 for context.
Example 10-4 XML Document

<Document>
<Nodes>
<Node>
<Name>Router-A</Name>
<Location>San Jose, CA</Location>
<Interfaces>
<Interface>
<Name>GigabitEthernet0/0/0</Name>
<IPv4Address>10.1.2.3</IPv4Address>
<IPv4NetMask>255.255.255.0</IPv4NetMask>
<Description>Uplink to Switch-BB</Description>
</Interface>
<Interface>
<Name>GigabitEthernet0/0/1</Name>
<IPv4Address>10.2.2.1</IPv4Address>
<IPv4NetMask>255.255.255.128</IPv4NetMask>
<Description />
</Interface>
</Interfaces>
</Node>
</Nodes>
</Document>

BOOK.indb 338 19/05/22 5:53 PM

 Chapter 10: Automation 339

In this example, the structure of this XML document represents a router record. <Docu-
ment>, <Nodes>, <Node>, <Name>, and <Location> are some of the tags created by the
document author. They also define the structure. Router-A, San Jose, CA, and GigabitEther-
net0/0/0 are values associated with the tags. Generally, when an XML document or schema
is written, the XML tags should provide context for the value(s) supplied. The values associ-
ated with the tags are plaintext and do not convey data type. As a plaintext document, XML
lends well to data exchange and compression, where needed.
XML has a history associated with document publishing. Its functional similarity with
HTML provides value: XML defines and stores data, focusing on content; HTML defines
format, focusing on how the content looks. The Extensible Stylesheet Language (XSL) pro-
vides a data transformation function, XSL Transformations (XSLT), for converting XML
documents from one format into another, such as XML into HTML. When you consider
that many APIs output results in XML, using XSLTs to convert that output into HTML is an
enabling feature. This is the basis for simple “API to Dashboard” automation.
Referring to Example 10-4, you can see that XML documents contain starting tags, such as
<Node>, and ending (or closing) tags, such as </Node>. There is also the convention of an
empty element tag; note the <Description /> example. All elements must have an end tag or
be described with the empty element tag for well-formed XML documents. Tags are case
sensitive, and the start and end tags must match case. If you’re a document author, you are
able to use any naming style you wish: lowercase, uppercase, underscore, Pascal case, Camel
case, and so on. It is suggested that you do not use dashes (-) or periods (.) in tags to prevent
misinterpretation by some processors.
All elements must be balanced in nesting, but the spacing is not prescribed. A convention
of three spaces aids the reader. It is acceptable for no spacing in a highly compressed docu-
ment, but the elements must still be nested among start and end tags.
XML can have attributes, similar to HTML. In the HTML example <img src="devnet_
logo.png" alt="DevNet Logo" />, you can recognize attributes of src and alt with values of
"devnet_logo.png" and "DevNet Logo". Similarly, in XML, data can have attributes—for
example, <interface type="GigabitEthernet">0/0/0</interface>.
Attribute values, such as “GigabitEthernet”, must be surrounded by double quotes. Values
between tags, such as 0/0/0, do not require quotes.
XML documents usually start with an XML declaration or prolog to describe the version
and encoding being used, but it is optional:

<?xml version="1.0" encoding="UTF-8"?>

XML documents are often described as trees composed of elements. The root element starts
the document. Branches and child elements define the structure with elements potentially
having subelements, or children. In Example 10-4, the root element is <Document>. Because 10
XML does not predefine tags, you may see other root element tags. Some common ones are
<Root>, <DocumentRoot>, <Parent>, and <rootElement>. It is up to the document author to
define the tags and structure.
The <Nodes> element is a child. The <Node> elements are also children. The <Node>
elements are also siblings to each other, as a list of records. The <Name>, <IPv4Address>,
<IPv4NetMask>, and <Description> elements are children to <Node>, siblings to each other
and form a record. Because there are multiple <Node> elements, a list is formed.

BOOK.indb 339 19/05/22 5:53 PM

 340 Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

XML documents can be viewed in browsers, typically through an Open File function. The
browser may render the XML with easy-to-understand hierarchy and expand or collapse
functions using + and -or ^ and > gadgets. See Figure 10-13 for another example of ACI
XML data, rendered in a browser.

Figure 10-13 ACI XML Data Rendered in Browser

JSON
JavaScript Object Notation (JSON) is a newer data encoding model than XML and is
growing in popularity and use with its more compact notation, ease of understanding, and
closer integration with Python programming. It is lightweight, self-describing, and program-
ming language independent. If your development includes JavaScript, then JSON is an easy
choice for data encoding with its natural alignment to JavaScript syntax.
The JSON syntax provides data being written as name-value pairs. Data is separated by com-
mas. Records or objects are defined by curly braces { }. Arrays and lists are contained within
square brackets [ ].
The name of a name-value pair should be surrounded by double quotes. The value should
have double quotes if representing a string. It should not have quotes if representing a
numeric, Boolean (true/false), or null value. See Example 10-5 for a sample JSON record.

BOOK.indb 340 19/05/22 5:53 PM

 Chapter 10: Automation 341

Example 10-5 REST API Payload as JSON

{
"Document": {
"Nodes": {
"Node": {
"Name": "Router-A",
"Location": "San Jose, CA",
"InterfaceCount": 2,
"Interfaces": {
"Interface": [
{
"Name": "GigabitEthernet0/0/0",
"IPv4Address": "10.1.2.3",
"IPv4NetMask": "255.255.255.0",
"Description": "Uplink to Switch-BB",
"isConnected": true
},
{
"Name": "GigabitEthernet0/0/1",
"IPv4Address": "10.2.2.1",
"IPv4NetMask": "255.255.255.128",
"Description": null,
"isConnected": false
}
]
}
}
}
}
}

Using this example, you can compare the structure with the previous XML representation.
There is a list of interfaces; each interface is a record or object.
With APIs, the system may not give you a choice of data formatting; either XML or JSON
may be the default. However, content negotiation is supported by many APIs. If the server
drives the output representation, a Content-Type header shows “application/xml” or “appli-
cation/json” as the response body payload type.
If the requesting client can request what’s desired, then an Accept header specifies similar 10
values for preference. With some APIs, appending .xml or .json to the request URI returns
the data with the preferred format.

BOOK.indb 341 19/05/22 5:53 PM

 342 Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

Cross-Domain, Technology-Agnostic Orchestration

(CDTAO)
This section is not part of the official DEVCOR certification; however, in the spirit of grow-
ing network programmability skills, it does seem appropriate to discuss. You may skip this
section if you prefer.
Most work in network IT tends to be very domain-specific. It’s not unusual to see engineers
and operators focus on specific technologies—enterprise networking, route/switch, wire-
less, storage networks, compute, wide-area networking, MPLS, security, and so on. However,
many do embrace multidomain expertise.
Often the management applications follow a similar segmentation. It is easy to appreciate,
then, when management apps bring a multidomain perspective to monitoring, provisioning,
and management. However, consider why you’re doing IT: there’s a lot to support a business
and the apps it depends on for the services it provides. Some typical supporting technolo-
gies include DNS, server connectivity, link aggregation, routing, switching, storage, compute,
virtualized workloads, authentication, databases, firewall security, content filtering security,
threat mitigation security, and application hosting. I’m sure you can think of many more!
So, is your operational perspective keeping up with the scope of your IT services? If you
end up using multiple tools for different domains or scale or geographical segments or secu-
rity segmentation, do you have an aggregate view of the health of your IT services, or do
you switch back and forth between multiple tools? Doesn’t this issue get exacerbated when
you pull in other IT vendors and open-source solutions? Is this something you accept as
“the way it is” or do you try to “glue” together these systems for more unified operational
insight?
How do you glue these systems together?
APIs are the unifying capability that enable you to achieve that glue. Most partner-vendors,
Cisco included, strive to provide the best customer experience possible with their product
and service offers. However, there are many customer segments, different sizes, different
areas of concentration, and constraints. I have been asked, “Why isn’t there just one manage-
ment tool?” Can you imagine the size in server requirements, cost, and maintenance neces-
sary to provide such a solution? Would the broad functions, some of which don’t apply to
your circumstances, distract your focus or enable it? In a friendly recognition to Hasbro, the
movie series, and the legacy Cisco management suite, we would have to call it “Cisco Opti-
mus Prime”! Most would agree that’s a bit unrealistic. Even building an uber-modular frame-
work to allow the specific selection of desired functions and device support would increase
complexity.
So is there an answer? Most providers enable their tools with APIs. If you pick the tools and
apps you need based on function, need, cost, and preference, then you can obtain a converged
operational perspective by using orchestration to collect the key health indicators from the
individual tools and controllers. The orchestrator’s workflow would also include activities to
create dashboards and portals unifying the information into converged operational portals
that direct your attention to the domain-specific management tools, as necessary.
Is this possible? It’s not provided out of the box, again due to the variety of device types and
functions, but it is doable. Consider the portal developed for the CiscoLive NOC in Figure

BOOK.indb 342 19/05/22 5:53 PM

 Chapter 10: Automation 343

10-14. This example represents, essentially, a mashup of key health metrics from several tools:
Prime Infrastructure, DNA Center, vCenter, Prime Network Registrar, Hyperflex, and so on.

Figure 10-14 NOC Dashboard

So what does the technology-agnostic part of Cross-Domain, Technology-Agnostic Orches-
tration (CDTAO) entail? It’s a wonderful concept to glue together network IT services in
a cross-domain perspective. What about some out-of-the-box thinking that also brings in
non-networking IT? From Figure 10-14, you can observe collaboration, digital signage, and
NetApp storage. What other network-connected technology (think IoT) can be accessed and
operational insight retrieved?
What industry do you work in?

■ Healthcare: Pull in network-connected systems, such as blood-pressure cuffs, pulse ox

monitors, and crash carts.

■ Financial: Pull in ATM (cash, not legacy networking!), vault/deposit box status.

■ Retail: Fork lifts, credit card and point-of-sale terminals.

■ Education: Digital projector status, teacher location/availability, bus/parking lot,

camera status.

If you add “business care-abouts” to the network IT perspectives, does that allow you to see
contribution and impact of the supporting infrastructure to the broader company? Sure, it
10
does!

Impact to IT Service Management and Security

This section is a continuation and amplification of the earlier “Software-Defined Networking
(SDN)” section mentioning the impact of other nontraditional entities influencing the net-
work. In a traditional networking case, you probably wrapped security around your change
management and provisioning of the network devices, even if performed manually. SSH was
enabled; access lists permitting only NOC or other specific personnel and network ranges

BOOK.indb 343 19/05/22 5:53 PM

 344 Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide

were configured; logging and accounting were enabled; possibly two-factor or multifactor
authentication was provisioned. In any case, security was given a strong consideration.
So now that network devices, management applications, and controllers have program-
matic interfaces to extract and change functions of networks, are you continuing the same
scrutiny? Are you the main source of API integration, or were other people with strong
programming experience brought in to beef up automation? Do they have strong network-
ing experience in concert with their programming skills? Are they keeping in touch with you
about changes? Oh no! Did that network segment go down?
Okay, enough of the histrionic “what if” scenario. You just need to make sure the same rigor
applied to traditional network engineering and operations is also being applied to newer,
SDN, and programmatic environments.
What are the leading practices related to programmable networks? First, consider your risk.
What devices and services are managed through controllers? They should be secured first
because they have the broadest scope of impact with multiple devices in a fabric. Enable all
the security features the controller provides with the least amount of privileges necessary to
the fewest number of individuals (and other automated systems). If the controller has limited
security options, consider front-ending it with access lists or firewall services to limit access
and content. Remember to implement logging and accounting; then review it periodically.
The next order of business should be high-priority equipment where the loss of availability
has direct service, revenue, or brand recognition impact. It’s the same activity: tighten up
access controls to the newer programmatic interfaces and telemetry.
Finally, go after the regular and low-priority equipment to shore up their direct device man-
agement interfaces in a similar fashion.

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a couple
of choices for exam preparation: the exercises here, Chapter 17, “Final Preparation,” and the
exam simulation questions in the Pearson Test Prep Software Online.

Review All Key Topics

Review the most important topics in this chapter, noted with the Key Topic icon in the outer
margin of the page. Table 10-6 lists a reference of these key topics and the page numbers on
which each is found.

Table 10-6 Key Topics for Chapter 10

Key Topic Element Description Page
Number
Figure 10-3 Agile Methodology 318
Paragraph SDN concepts 329
Table 10-4 Contributing Protocols and Solutions to SDN 333
Table 10-5 REST API Operation Types 336
Paragraph XML description 338
Paragraph JSON description 340

BOOK.indb 344 19/05/22 5:53 PM

 Chapter 10: Automation 345

Complete Tables and Lists from Memory

Print a copy of Appendix C, “Memory Tables” (found on the companion website), or at least
the section for this chapter, and complete the tables and lists from memory. Appendix D,
“Memory Tables Answer Key,” also on the companion website, includes completed tables
and lists to check your work.

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

JavaScript Object Notation (JSON), Network Configuration Protocol (NETCONF), REST,

Extensible Markup Language (XML), YANG

References
URL QR Code
https://developer.cisco.com/pyats/

10

BOOK.indb 345 19/05/22 5:53 PM

 Index

A downloading and installing Ansible,

474–481
installing Terraform, 494–496
acceptance testing, 22, 23
Jinja2 filtering, 487–488
access tokens (OAuth 2.0), 181
modifying device configurations,
accessibility as quality attribute, 32
488–493
accessing Pearson Test Prep software,
playbooks in Ansible, 483–487
649–650
project-level inventory files in Ansible,
accountability as quality attribute, 32
482–483
ACI tenant deployment with
Agile, 18–20, 317–318
Terraform, 496–501
Agile Manifesto, 18–19
ACID properties, 148
agrparse, 174
active recovery (hot standby), 47–48
alpha testing, 22
admin processes in 12-factor applica-
tion design, 242 Amazon Web Services (AWS)
administrative requirements for soft- ECS on Fargate, 227–234
ware architecture, 13 Jeff Bezos’s API mandate, 136–138
agent-based configuration manage- Lambda, 234–238
ment, 450–473 analyzability as quality attribute, 33
downloading and installing Puppet, Ansible, 334
453–458
as agentless solution, 450, 474–493
extracting information via Puppet,
configuring inventory, 481–482
459–463
downloading and installing,
NX-OS devices with Puppet, 465–469
474–481
Puppet manifests, 469–473
Jinja2 filtering, 487–488
Puppet platform support matrix, 451
modifying device configurations,
Python scripts with Puppet, 463–465 488–493
agentless configuration management playbooks, 483–487
solutions, 450, 474–501
project-level inventory files,
ACI tenant deployment, 496–501 482–483
configuring Ansible inventory, comparison with Terraform, 518–519
481–482
described, 512–514

BOOK.indb 684 19/05/22 5:58 PM

 in evolution of application deploy- documentation, 603–605
ment, 221–223 enabling access, 601–603
with NETCONF and RESTCONF, 382 Jeff Bezos’s API mandate, 136–138
API keys, 180 lack of, 135
Apigee, 147 Meraki
APIs (application programming authorization, 596–600
interfaces)
documentation, 593–594
AppDynamics, 639–646
enabling access, 592–593
architectural styles
NETCONF APIs, 158–159
gRPC, 154–155
operational overview, 335–336
OpenAPI/Swagger, 155–156
pagination, 337–338
purpose of, 146
payload data formats, 338
REST vs. RPC, 152–154
JSON, 340–341
selecting, 147–148
XML, 338–340
authentication, 337
performance
authentication types, 139, 162,
caching, 163, 188
179–181
error handling/timeouts/rate lim-
calling, 138–144
iting, 184–188
components of, 132
pagination, 162
formats, 134–135
streaming vs. pagination,
methods, 133–134 181–184
objects, 134 public/open, 140
definition of, 132 RESTful APIs, 157–158. See also
development RESTCONF
CLI wrapper code, 174–177 cache-control, 151–152
client creation, 165–173 constraints on, 157
design considerations, 177–178 documentation, 631–635
IMDb API example, 165–173 enabling DNA center access,
methods for, 162 630–631
purpose of, 162 enabling Firepower access,
582–583
security, 162, 179–181
enabling Webex access, 572–573
tools for, 146–147
Firepower documentation,
types of APIs, 144–145
583–585
headers, 139
Firepower use cases, 585–592
HTTP requests, 149–150
HTTP status codes, 184
idempotency, 337
JSON, 150–151
Intersight
NETCONF APIs vs.159
authorization, 606–611

BOOK.indb 685 19/05/22 5:58 PM

 686 APIs (application programming interfaces)

operation types, 336 cloud services, 224–238

streaming APIs vs.181–184 sysadmins compiling from
uniform interfaces, 158 source code, 218–220
Webex documentation, 573–575 SRE, 196–198
Webex use cases, 575–577 DevOps vs.198
UCS Manager responsibilities of, 197–198
documentation, 611–617 12-factor application design, 238–242
enabling access, 611 admin processes, 242
web scraping as alternative, 135–136 backing services, 240
APM (application performance moni- build/release/run stages, 240
toring) applications, 77 codebase, 239
AppDynamics, 77, 639–646 concurrency, 241
application containers configuration, 239
implementation, 534 dependencies, 239
Cisco DNA Center for applica- disposability, 241
tion hosting, 538–547 logs, 242
Cisco IOx Local Manager for parity, 241–243
application hosting, 547–552
port binding, 241
CLI for application hosting,
processes, 240
553–556
application design
enabling application hosting
framework, 536–537 API design considerations, 177–178
validating prerequisites, availability and resiliency in, 44–53
534–536 deployment models, 51–53
interaction with iPerf3, 556–563 failure prevention, 50
management best practices, 563–565 fault detection, 46–47
platforms supporting, 533 planning, 50–51
use cases, 532 recovery, 47–50
application deployment requirements, 45
CI/CD database selection in, 79–83
components of, 198–201 data variety, 82–83
integration deployment, 207–217 data velocity, 82
pipeline implementation, data volume, 81–82
201–203 types of databases, 80–81
stages of, 203–206 maintainability in, 59–66
DevOps, responsibilities of, 194–196 DIP (dependency inversion
evolution of methods, 218–238 principle), 65–66
automated configuration ISP (interface segregation
management, 220–224 principle), 64–65

BOOK.indb 686 19/05/22 5:58 PM

 authenticity as quality attribute 687

LSP (Liskov’s substitution prin- concurrency, 241

ciple), 63–64 configuration, 239
modularity and, 59 dependencies, 239
OCP (open-closed principle), disposability, 241
62–63
logs, 242
SOLID design, 60–66
parity, 241–243
SRP (single responsibility prin-
port binding, 241
ciple), 61
processes, 240
modularity in, 36–41
application hosting
benefits of, 36–37
with Cisco DNA Center, 538–547
best practices, 37–40
with Cisco IOx Local Manager,
definition of, 36
547–552
microservices and, 40–41
with CLI, 553–556
for performance
enabling framework, 536–537
caching, 70–71
application performance monitoring
exponential backoff, 72–73 (APM) applications, 77
latency, 66–73 application programming interfaces.
observability, 73–79 See APIs (application programming
parallel processing, 72 interfaces)
rate limiting, 71–72 architectural decisions, 519–520
trade-offs in, 69 architectural styles (APIs)
scalability in, 41–44 gRPC, 154–155
horizontal, 41–42 OpenAPI/Swagger, 155–156
practical, 43–44 purpose of, 146
vertical, 42–43 REST vs. RPC, 152–154
security selecting, 147–148
CIA triad, 248–249 architecture. See software architecture
IT secrets storage, 252–254 Atlantis, 207–213
OAuth 2.0, 266–283 atomic configuration management,
model-driven vs.351–354
OWASP, 262–266
atomic network management,
PKI, 254–262
controller-based vs.303–305
privacy, 250–252
atomicity as ACID property, 148
top 10 risks, 249–250
authentication
12-factor application design, 238–242
for APIs, 139, 162, 179–181, 337
admin processes, 242
RESTCONF and, 373
backing services, 240
Webex API, 575–577
build/release/run stages, 240
authenticity as quality attribute, 32
codebase, 239

BOOK.indb 687 19/05/22 5:58 PM

 688 authorization

authorization. See also OAuth 2.0 provisioning vs.449

DNA Center, 637–639 automation
Intersight, 606–611 APIs
Meraki, 596–600 authentication, 337
authorization code flow (OAuth 2.0), idempotency, 337
276–278 JSON and, 340–341
automated configuration manage- operational overview, 335–336
ment. See also SCM (software con-
pagination, 337–338
figuration management); streaming
telemetry payload data formats, 338
agent-based solutions, 450–473 RESTful APIs, 336
downloading and installing Pup- XML and, 338–340
pet, 453–458 CDTAO, 342–343
extracting information via Pup- challenges addressed by, 313–329
pet, 459–463 accuracy of provisioning,
NX-OS devices with Puppet, 319–323
465–469 diversity of equipment and func-
Puppet manifests, 469–473 tionality, 314–316
Puppet platform support matrix, proximity of management tools
451 and support staff, 316
Python scripts with Puppet, reducing operation expenses,
463–465 329
agentless solutions, 450, 474–501 scalability in provisioning,
ACI tenant deployment, 496–501 323–328
configuring Ansible inventory, speed of provisioning, 317–318
481–482 in evolution of network management
downloading and installing and software development, 6–7
Ansible, 474–481 in failure prevention, 50
installing Terraform, 494–496 IT service management and security,
Jinja2 filtering, 487–488 343–344
modifying device configurations, SDN, 329–335
488–493 Cisco solutions for, 335
playbooks in Ansible, 483–487 definition of, 329–332
project-level inventory files in network controllers, 334
Ansible, 482–483 use cases, 332–334
atomic vs. model-driven, 351–354 autoscaling in application design, 42
in evolution of application deploy- availability
ment, 220–224
in application design, 44–53
imperative vs. declarative models,
deployment models, 51–53
448–449

BOOK.indb 688 19/05/22 5:58 PM

 caching 689

failure prevention, 50 current changes review, 94

fault detection, 46–47 pros and cons, 89
planning, 50–51 sample exercise, 90–103
recovery, 47–50 sample setup, 90
requirements, 45 staged changes review, 94
definition of, 249 branches (Git)
as quality attribute, 30, 32 branch protection rules, 125–126
availability monitoring of application branching strategies, 121–123
containers, 564 definition of, 121
AWS (Amazon Web Services) Git Flow, 123
ECS on Fargate, 227–234 GitHub Flow, 122–123
Jeff Bezos’s API mandate, 136–138 GitLab Flow, 123
Lambda, 234–238 list of, 122
selecting, 122
B creating, 93–94, 111
pushing
backing services in 12-factor applica-
to forked repo, 114
tion design, 240
to origin repo, 97
bandwidth, 66
browser security, 261–262
basic authentication (APIs), 179
bug fixes, cost of, 60
BCP (business continuity planning),
50–51 bugs, definition of, 46
bearer authentication (APIs), 180 build stage (CI/CD), 204
best practices business continuity planning (BCP),
50–51
for application container management,
563–565 business process management in evolu-
tion of network management and
in modular design, 37–40
software development, 6
beta testing, 22
business requirements for software
Bezos, Jeff, API mandate, 136–138 architecture, 12, 13
BGP-LS/FS (BGP Link-State/Flow
Spec), 333
black-box design in modular design, 39
C
black-box testing, 23 cache-control, 151–152
blue-green deployment (CI/CD), 206 caching
Branch and Pull Workflow (Git), 89–103 for API performance, 163, 188
branches for application performance,
creating, 93–94 70–71
pushing to origin repo, 97

BOOK.indb 689 19/05/22 5:58 PM

 690 cadence-based telemetry

cadence-based telemetry. See MDT deploy, 205–206

(model-driven telemetry) release/deliver, 205
calling APIs, 138–144 test, 205
canary deployment (CI/CD), 206 cisco_node_utils Ruby gem, installing,
capacity as quality attribute, 31 465
CAs (certificate authorities) ciscopuppet module, installing, 463
hierarchical structure of, 257 CITEIS (Cisco IT Elastic Infrastructure
purpose of, 254–256 Services), 315
web application security, 257–260 CLI (command-line interface)
CD (continuous delivery), 200 accuracy of provisioning, 319–323
CD (continuous deployment), 200–201 on Ansible, 514
CDNs (content delivery networks/con- application hosting with, 553–556
tent distribution networks), 188 definition of, 174
CDTAO (cross-domain, technology- IMDb API example, 174–177
agnostic orchestration), 342–343 network provisioning, 291–294
certificate path validation (CPV), 260 wrapper code for APIs, 174–177
certificates Click
format of, 256 command creation, 175
revoking, 256–257 group creation, 175
Chef help function, 176
as agent-based solution, 450–451 importing, 175
described, 512 purpose of, 174
in evolution of application deploy- client credential flow (OAuth 2.0),
ment, 221 271–272
choosing. See selecting clients (APIs)
CI (continuous integration), 199–200 creating, 165–173
CIA (confidentiality, integrity, availabil- definition of, 138
ity) triad, 248–249
IMDb API example, 165–173
CI/CD (continuous integration/continu-
close-session operation (NETCONF),
ous delivery (deployment)), 290
350
components of, 198–201
cloud availability deployment model,
integration deployment, 207–217 52
to cloud-native applications, cloud services in evolution of applica-
213–217 tion deployment, 224–238
to infrastructure, 207–213 containers on serverless clouds,
pipeline implementation, 201–203 227–234
stages of, 203–206 managed Kubernetes, 224–226
build, 204 serverless functions, 234–238

BOOK.indb 690 19/05/22 5:58 PM

 containers 691

cloud-native applications, integration agent-based solutions, 450–473

deployment to, 213–217 downloading and installing Pup-
clustering pet, 453–458
in application design, 41–42 extracting information via Pup-
for high availability, 51–52 pet, 459–463
code adaptation, cost of, 60 NX-OS devices with Puppet,
465–469
code comments as documentation, 79
Puppet manifests, 469–473
code refactoring, cost of, 60
Puppet platform support matrix,
code reviews, 21–22
451
codebase
Python scripts with Puppet,
in 12-factor application design, 239 463–465
technical debt of, 520 agentless solutions, 450, 474–501
coding standards for maintainability, ACI tenant deployment, 496–501
59
configuring Ansible inventory,
cohesion in modular design, 37–38 481–482
cold standby (spare recovery), 49 downloading and installing
command-line interface (CLI). See CLI Ansible, 474–481
(command-line interface) installing Terraform, 494–496
commands (Click), creating, 175 Jinja2 filtering, 487–488
common toolsets for maintainability, modifying device configurations,
59 488–493
compatibility as quality attribute, 31 playbooks in Ansible, 483–487
compiling from source code, 218–220 project-level inventory files in
concurrency Ansible, 482–483
in 12-factor application design, 241 atomic vs. model-driven, 351–354
definition of, 325–327 in evolution of application deploy-
confidentiality, definition of, 249 ment, 220–224
configuration imperative vs. declarative models,
448–449
in 12-factor application design, 239
provisioning vs.449
of Ansible inventory, 481–482
CONNECT requests, 336
of MDT
consistency as ACID property, 148
dial-in mode, 402–406
console, network provisioning from,
dial-out mode, 398–402
291–294
in IOS-XR, 397–398
constraints (limitations)
configuration management, auto-
on RESTful APIs, 157
mated. See also SCM (software con-
figuration management); streaming for software architecture, 10
telemetry containers. See also application
containers

BOOK.indb 691 19/05/22 5:58 PM

 692 containers

Docker, 530–531 data encoding

LXC (Linux Containers), 529–530 JSON, 340–341
on serverless clouds, 227–234 XML, 338–340
content delivery networks/content dis- data in motion, 250–251
tribution networks (CDNs), 188 data in use, 251
content layer (NETCONF), 349 data localization, definition of, 251
continuous delivery (CD), 200 data plane, 303–304
continuous deployment (CD), 200–201 data privacy, definition of, 251
continuous integration (CI), 199–200 data sources (Terraform), 517
control plane, 303–304 data sovereignty, definition of, 251
controller-based network management, data states, 250–251
atomic vs.303–305
data variety, 82–83
cookie authentication (APIs), 180–181
data velocity, 82
copy-config operation (NETCONF),
data volume, 81–82
350
databases
coupling
injection attacks, 263–264
DIP (dependency inversion principle)
and, 65–66 selecting in application design, 79–83
in modular design, 37–38 data variety, 82–83
CPV (certificate path validation), 260 data velocity, 82
credentials. See IT secrets stor- data volume, 81–82
age; OAuth 2.0; PKI (public key types of databases, 80–81
infrastructure) declarative configuration management
cross-domain, technology-agnostic models, 448–449
orchestration (CDTAO), 342–343 DELETE requests, 133–134, 336
cross-site scripting (XSS), 264–266 delete-config operation (NETCONF),
culture in evolution of network man- 350
agement and software development, deliver stage (CI/CD), 205
8
dependencies
cURL, RESTCONF GET operations
in 12-factor application design, 239
with, 375–377
in modular design, 38
current changes (Git), reviewing, 94,
112 dependency inversion principle (DIP),
65–66
customizing exam modes, 650–651
deploy stage (CI/CD), 205–206

D deployment models for high avail-

ability, 51–53. See also application
deployment
data at rest, 251
design. See application design
data backup and replication for high
destination groups, creating, 398–399
availability, 51

BOOK.indb 692 19/05/22 5:58 PM

 edge computing 693

device code flow (OAuth 2.0), 281–283 YANG Suite installation, 415–423
DevOps, 290 documentation
in evolution of network management for application performance, 78–79
and software development, 8 DNA Center APIs, 631–635
key practices in, 8 DNA Center SDKs, 635–637
responsibilities of, 194–196 Firepower, 583–585
vs. SRE, 198 Intersight APIs, 603–605
dial-in mode (streaming telemetry), 392 Intersight SDKs, 605
configuring, 402–406 for maintainability, 59
definition of, 394 Meraki APIs, 593–594
dial-out vs.395 Meraki SDKs, 594–596
dial-out mode (streaming telemetry), researching sensor paths, 407
392
UCS Manager APIs, 611–617
configuring, 398–402
UCS Manager PowerShell SDKs,
definition of, 394 622–628
dial-in vs.395 UCS Manager Python SDKs, 617–622
digital certificates. See certificates Webex, 573–575
DIP (dependency inversion principle), DOM-based XSS, 266
65–66
downloading
disaster recovery, 47
Ansible, 474–481
disaster recovery planning (DRP),
Pearson Test Prep software, 649–650
50–51
Puppet, 453–458
disk space usage, EDT vs. MDT,
440–441 YANG models, 369–371
disposability in 12-factor application DRP (disaster recovery planning),
design, 241 50–51
distributed tracing, 77 durability as ACID property, 148
DNA Center, 628–639
API documentation, 631–635 E
application hosting with, 538–547
eager loading, 70–71
enabling access, 630–631
ECS (Elastic Container Service),
purpose of, 628–629
227–234
SDK authorization, 637–639
edge computing
SDK documentation, 635–637
application containers
Docker
Cisco DNA Center for applica-
containers, 530–531. See also applica- tion hosting, 538–547
tion containers
Cisco IOx Local Manager for
installing, 414–415 application hosting, 547–552

BOOK.indb 693 19/05/22 5:58 PM

 694 edge computing

CLI for application hosting, Webex, 572–573

553–556 application hosting framework,
enabling application hosting 536–537
framework, 536–537 gRPC, 402–404
implementation, 534 NETCONF
interaction with iPerf3, 556–563 on IOS XE, 355–356
management best practices, on IOS XR, 356–357
563–565
on NX-OS, 357–358
platforms supporting, 533
encoding (streaming telemetry)
use cases, 532
definition of, 395
validating prerequisites,
types of, 395–396
534–536
endpoints (APIs), definition of, 138
benefits of, 527
errors
virtualization technologies, 527–531
APIs, 184–188
Docker containers, 530–531
definition of, 46
LXC (Linux Containers),
529–530 event streaming, definition of, 15
Type-1 hypervisors, 528 event-driven architecture, definition of,
15
Type-2 hypervisors, 528–529
event-driven telemetry (EDT)
edit-config operation (NETCONF), 350
definition of, 390
EDT (event-driven telemetry)
MDT vs.434–441
definition of, 390
evolution
MDT vs.434–441
of application deployment methods,
EEM (Embedded Event Manager),
218–238
299–300
automated configuration man-
Elastic Container Service (ECS),
agement, 220–224
227–234
cloud services, 224–238
elasticity
sysadmins compiling from
in application deployment, 223
source code, 218–220
in application design, 43
of network management and software
EMSs (element management systems), development, 5–8
297–299
exam preparation, 648–652
enabling
customizing exams, 650–651
access
tips for, 648–649
DNA Center, 630–631
tools for, 649–650
Firepower, 582–583
updating exams, 651
Intersight, 601–603
exponential backoff for application
Meraki, 592–593 performance, 72–73
UCS Manager, 611

BOOK.indb 694 19/05/22 5:58 PM

 future-proofing, cost of 695

extensibility in application design, 62–63 Firepower Management Center (FMC),

Extensible Markup Language (XML), 582
338–340, 349, 395 firewalls. See Firepower
external APIs, 145 five nines (availability), 45
extracting model support fixed window (rate limiting), 187
manually via NETCONF, 408–410 Flash Card Mode (exam preparation),
with Python and NETCONF, 410–413 650
Extreme Programming (XP), 19, 20 flow control. See performance
Flux, 213–217

F FMC (Firepower Management Center),

582
facter utility (Puppet), 459–463 forced loading, 70–71
failures Fork and Pull Workflow (Git), 104–120
availability and recovery, 47–50 branches
definition of, 46 creating, 111
prevention of, 50 pushing to forked repo, 114
Fargate, 227 current changes review, 112
fat interfaces, 64 pros and cons, 105
fault detection, availability and, 46–47 sample exercise, 106–120
fault monitoring in application contain- sample setup, 105
ers, 564 staged changes review, 112–113
fault tolerance as quality attribute, 32 formats (APIs), 134–135
faults, definition of, 46 four nines (availability), 45
FCAPS (Fault, Configuration, Account- FTD (Firepower Threat Defense). See
ing, Performance, and Security) Firepower
model in evolution of network man- FTP (File Transfer Protocol), 297
agement and software development, 5
functional appropriateness as quality
FDM (Firepower Device Management), attribute, 31
582
functional correctness as quality attri-
Fiddler, 147 bute, 31
file transfer methods, 297 functional requirements for software
File Transfer Protocol (FTP), 297 architecture, 10–11, 12–13
Firepower, 582–592 comparison with nonfunctional, 12
documentation, 583–585 relationship with nonfunctional, 29
enabling access, 582–583 functional stability as quality
purpose of, 582 attribute, 31
use cases, 585–592 functional testing, 23
Firepower Device Management future-proofing, cost of, 60
(FDM), 582

BOOK.indb 695 19/05/22 5:58 PM

 696 GDPR (General Data Protection Regulation)

G as architectural style, 154–155

definition of, 390
GDPR (General Data Protection Regu- enabling, 402–404
lation), 251–252 in MDT, 397
get operation (NETCONF), 350
GET operation (RESTCONF) H
with cURL, 375–377
with Postman, 377–382 HCL (HashiCorp Configuration Lan-
guage), 494, 518
GET requests, 133, 149, 336
HEAD requests, 336
get-config operation (NETCONF), 350
headers (APIs), 139, 149–150
Git
Health Insurance Portability and
branching strategies, 121–123
Accountability Act (HIPAA), 252
definition of, 121
heartbeats for fault detection, 46
Git Flow, 123
hello packets for fault detection, 46
GitHub Flow, 122–123
help function (Click), 176
GitLab Flow, 123
high availability. See availability
list of, 122
HIPAA (Health Insurance Portability
selecting, 122 and Accountability Act), 252
features of, 88 horizontal scaling in application design,
recommended settings, 125–126 41–42
workflows, 88–89 hot standby (active recovery), 47–48
Branch and Pull Workflow, HTTP requests, 149–150
89–103 HTTP status codes, 184
Fork and Pull Workflow, hybrid availability deployment model,
104–120 53
Git Flow, 122, 123 hybrid scaling in application design, 42
GitHub Flow, 122–123, 125–126 hypervisors
GitLab Flow, 122, 123 definition of, 527–528
GKE (Google Kubernetes Engine), Type-1, 528
224–226
Type-2, 528–529
gNMI (gRPC Network Management
Interface), 390, 392
GPB (Google Protocol Buffer), 396 I
Grafana
I2RS (Interface to Routing System),
installing, 430–434 333
purpose of, 426 IaC (Infrastructure as Code), 447–448
GraphQL, 147 agent-based solutions, 450–473
gRPC (Google Remote Procedure Call) agentless solutions, 474–501

BOOK.indb 696 19/05/22 5:58 PM

 interpolation (Terraform) 697

Cisco solutions for, 501–502 agent-based solutions, 450–473

IBN (intent-based networking), agentless solutions, 474–501
305–306 Cisco solutions for, 501–502
ICMP echo/echo-reply for fault detec- injection attacks, 263–264
tion, 46–47
inside-out design (APIs), 178
idempotency of APIs, 337
installability as quality attribute, 33
IETF RFC 5424 (Syslog), logging with,
installing
75
Ansible, 474–481
IMDb API
cisco_node_utils Ruby gem, 465
calling, 140–144
ciscopuppet module, 463
CLI wrapper code, 174–177
Docker, 414–415
client creation, 165–173
Grafana, 430–434
imperative configuration management
models, 448–449 InfluxDB, 426–427
implicit flow (OAuth 2.0), 275–276 jq utility, 460
importing Click, 175 Puppet, 453–458
INET data types, 366 pyang tool, 368–369
InfluxDB Telegraf, 428
installing, 426–427 Terraform, 494–496
purpose of, 426 YANG Suite, 415–423
information security. See security integration deployment (CI/CD),
207–217
infrastructure. See also IaC (Infrastruc-
ture as Code) to cloud-native applications, 213–217
integration deployment to, 207–213 to infrastructure, 207–213
network management, 288–290 integration testing, 22
atomic vs. controller-based net- integrity
working, 303–305 definition of, 249
intent-based networking, as quality attribute, 32
305–306 intent-based networking (IBN),
network provisioning, 290–291 305–306
from CLI/console, 291–294 interface segregation principle (ISP),
EEM, 299–300 64–65
element management systems, Interface to Routing System (I2RS),
297–299 333
file transfer methods, 297 interfaces in modular design, 39–40
SNMP, 294–297 internal APIs, 144–145
ZTP, 300–303 interoperability as quality attribute,
30, 31
technical debt of, 520
interpolation (Terraform), 517–518
Infrastructure as Code (IaC), 447–448

BOOK.indb 697 19/05/22 5:58 PM

 698 Intersight

Intersight, 601–611 as data encoding method, 396

API documentation, 603–605 data encoding with, 340–341
authorization, 606–611 REST and, 150–151
enabling access, 601–603 RPC and, 152–154
purpose of, 601
SDK documentation, 605 K
inventory (Ansible)
configuring, 481–482 Kanban, 19, 318
project-level files, 482–483 keys. See IT secrets storage; OAuth 2.0;
PKI (public key infrastructure)
inventory management for application
containers, 563–564, 565 kill-session operation (NETCONF), 350
IOS XE, enabling NETCONF on, KIND (Kubernetes in Docker),
355–356 214–215
IOS XR Kubernetes
configuring MDT in, 397–398 integration deployment in, 213–217
enabling NETCONF on, 356–357 managed Kubernetes, 224–226
IOx
described, 534 L
enabling, 536–537
Lambda, 234–238
IOx Local Manager, application hosting
with, 547–552 latency, 66–73
iPerf3, interaction with, 556–563 definition of, 67
isolation factors affecting, 67–68
as ACID property, 148 high performance design, 69–73
in failure prevention, 50 side effects of, 69
ISP (interface segregation principle), laws governing privacy protection,
64–65 251–252
IT secrets storage, 252–254 lazy loading, 70–71
IT service management, automation leaky bucket (rate limiting), 187
and, 343–344 Lean, 19, 20, 318
learnability as quality attribute, 32
J limitations (constraints)
on RESTful APIs, 157
JDBC (Java Database Connectivity), for software architecture, 10
335
Linux Containers (LXC), 529–530
Jinja2 filtering, 487–488
Linux VM
jq utility, installing, 460
Docker installation, 414–415
JSON (JavaScript Object Notation)
YANG Suite installation, 415–423

BOOK.indb 698 19/05/22 5:58 PM

 metrics 699

Liskov’s substitution principle (LSP), MDT (model-driven telemetry)

63–64 configuring
load balancing in application design, dial-in mode, 402–406
41–42
dial-out mode, 398–402
lock operation (NETCONF), 350
in IOS-XR, 397–398
logging. See also monitoring
definition of, 390
for application performance, 74–76
dial-in/dial-out comparison, 395
definition of, 73
EDT vs.434–441
Python levels of, 75
encodings in, 395–396
with Syslog (IETF RFC 5424), 75
implementation, 393–395
logs in 12-factor application design,
protocols in, 396–397
242
sensor path selection, 407–413
loose coupling. See coupling
extracting NETCONF capabili-
low-level documentation, 79
ties with Python, 410–413
LSP (Liskov’s substitution principle),
manually extracting NETCONF
63–64
capabilities, 408–410
LXC (Linux Containers), 529–530
public documentation for, 407
terminology, 394–395
M use cases, 423–425
YANG model investigation via YANG
maintainability
Suite, 414–423
in application design, 59–66
mean time between failures (MTBF), 45
DIP (dependency inversion prin-
mean time to repair (MTTR), 45, 47
ciple), 65–66
measurability of nonfunctional require-
ISP (interface segregation prin-
ments, 29, 35–36
ciple), 64–65
Meraki, 592–600
LSP (Liskov’s substitution prin-
ciple), 63–64 API documentation, 593–594
modularity and, 59 authorization, 596–600
OCP (open-closed principle), enabling access, 592–593
62–63 purpose of, 592
SOLID design, 60–66 SDK documentation, 594–596
SRP (single responsibility prin- merge button settings (Git), 125
ciple), 61 messages layer (NETCONF), 350–351
as quality attribute, 33 methods (APIs), 133–134
managed Kubernetes, 224–226 metrics
management plane, 303–304 for application performance, 76–77
manifests (Puppet), 469–473 definition of, 73
manual usage of NETCONF, 358–364

BOOK.indb 699 19/05/22 5:58 PM

 700 microservices

microservices
definition of, 14
N
modular design and, 40–41 naming conventions for maintainability,
mobile application security, 262–266 59
model-driven configuraiton manage- native models, 366
ment, atomic vs.351–354 NETCONF, 334. See also RESTCONF
model-driven telemetry (MDT). See APIs, 158–159
MDT (model-driven telemetry)
definition of, 322
model-view-controller (MVC), defini-
implementation, 354–364
tion of, 15
on IOS XE, 355–356
modifiability as quality attribute, 30,
33 on IOS XR, 356–357
modularity in application design, 36–41 manual usage, 358–364
benefits of, 36–37 on NX-OS, 357–358
best practices, 37–40 layers in, 349–351
definition of, 36 content, 349
maintainability and, 59 messages, 350–351
microservices and, 40–41 operations, 350
scalability and, 43–44 transport, 351
monitoring. See also logging; streaming management solutions with, 382–383
telemetry mapping to RESTCONF operations,
application containers, 564 372–373
for application performance, 73–79 in MDT, 396
documentation, 78–79 extracting capabilities with
Python, 410–413
logging, 74–76
manually extracting capabilities,
metrics, 76–77
408–410
tracing, 77–78
origin of, 348–349
with Embedded Event Manager,
YANG models and, 365–371
299–300
network APIs. See APIs (application
evolution from SNMP to streaming
programming interfaces)
telemetry, 386–391
network controllers, 334
for fault detection, 46
network management
MTBF (mean time between failures), 45
atomic vs. controller-based network-
MTTR (mean time to repair), 45, 47
ing, 303–305
multiprocessing, 72
evolution of, 5–8
multithreading, 72
improvements in, 288–290
MVC (model-view-controller), defini-
intent-based networking, 305–306
tion of, 15

BOOK.indb 700 19/05/22 5:58 PM

 object-oriented design (OOD) 701

network management systems (NMS) nonfunctional requirements for soft-

in evolution of network management ware architecture, 11–12, 13–14,
and software development, 5 29–36
with NETCONF and RESTCONF, architectural decisions, 519–520
382–383 comparison with functional, 12
proximity of tools and support staff, ISO/IEC 25010 standard, 31–33
316 measurability of, 29, 35–36
SNMP, 294–297 most common, 29–30, 519
network operations center (NOC) in stages of, 35
evolution of network management
technical debt, 520–521
and software development, 6
nonrepudiation as quality attribute, 32
network programmability, definition of,
329–332 northbound APIs, 135
network provisioning, 290–291 NoSQL (nonrelational) databases, 80
accuracy of, 319–323 NSO (Network Services Orchestrator),
382
from CLI/console, 291–294
NX-OS devices
configuration management vs.449
enabling NETCONF on, 357–358
EEM, 299–300
with Puppet, 465–469
element management systems,
297–299
file transfer methods, 297 O
scalability in, 323–328
OAS (OpenAPI Specification),
SNMP, 294–297
155–156, 165
speed of, 317–318
OAuth 2.0, 181, 266–283
ZTP, 300–303
authorization code flow, 276–278
Network Services Orchestrator (NSO),
client credential flow, 271–272
382
device code flow, 281–283
new features and upgrades, cost of, 60
implicit flow, 275–276
Nginx, 186
operational overview, 266–268
NMS (network management systems)
PKCE flow, 278–280
in evolution of network management
and software development, 5 refresh token flow, 280–281
with NETCONF and RESTCONF, resource owner password credential
382–383 flow, 272–274
proximity of tools and support staff, three-legged authorization, 269–270
316 two-legged authorization, 268–269
SNMP, 294–297 object-oriented design (OOD)
NOC (network operations center) in for maintainability, 59
evolution of network management SOLID design, 60–66
and software development, 6

BOOK.indb 701 19/05/22 5:58 PM

 702 objects (APIs)

objects (APIs), 134 outside-in/user interface design

observability for application perfor- (APIs), 178
mance, 73–79 OWASP (Open Web Application Secu-
documentation, 78–79 rity Project), 249, 262–266
logging, 74–76 ownership in evolution of network
management and software develop-
metrics, 76–77
ment, 6
tracing, 77–78
OCP (open-closed principle), 62–63
ODBC (Open Database Connectivity),
P
335
pagination, 70, 162, 181–184,
OMI (Open Management Infrastruc- 337–338
ture), 334
parallel processing
on-premises availability deployment
for application performance, 72
model, 52
definition of, 327–328
OOD (object-oriented design)
parity in 12-factor application design,
for maintainability, 59
241–243
SOLID design, 60–66
partner APIs, 145
open APIs, definition of, 140
passive recovery (warm standby), 48
Open Web Application Security Proj-
PATCH requests, 133, 336
ect (OWASP), 249, 262–266
patterns (software architecture), 14–15
open YANG models, 366
PCEP (Path Computation Element Pro-
OpenAPI Specification (OAS), 155–
tocol), 333
156, 165
PCI DSS (Payment Card Industry Data
open-closed principle (OCP), 62–63
Security Standard), 252
OpenFlow, 333
PDIOO (planning , design, implementa-
open-source solutions, purpose of, 444 tion, operation, and optimization)
OpenStack, 334 model, 288–289
operability as quality attribute, 32 Pearson Cert Practice Test Engine, 649
operation expenses, reducing, 329 Pearson Test Prep software
operational lifecycle of devices, 315 accessing, 649–650
operations layer (NETCONF), 350 customizing, 650–651
optimization, cost of, 60 Premium Edition, 651
OPTIONS requests, 336 updating, 651
orchestration performance
CDTAO, 342–343 of APIs
in evolution of network management caching, 163, 188
and software development, 6–7 error handling/timeouts/rate
output values (Terraform), 517 limiting, 184–188

BOOK.indb 702 19/05/22 5:58 PM

 protobufs 703

pagination, 162 Postman, 146

streaming vs. pagination, DNA Center documentation,
181–184 633–635
in application design Firepower documentation, 584–585
caching, 70–71 Intersight documentation, 603–605
exponential backoff, 72–73 Meraki authorization, 596–600
latency, 66–73 Meraki documentation, 593–594
observability, 73–79 RESTCONF GET operations with,
parallel processing, 72 377–382
rate limiting, 71–72 PowerShell, UCS Manager documenta-
tion, 622–628
trade-offs in, 69
practical applications. See use cases
as quality attribute, 30
practical scaling in application design,
performance efficiency as quality attri-
43–44
bute, 31
Practice Exam Mode (exam prepara-
performance monitoring of application
tion), 650
containers, 564
predictive analytics in failure preven-
performance optimization, cost of, 60
tion, 50
performance testing, 23
Premium Edition of Pearson Test Prep
picking. See selecting software, 651
PII (personally identifiable informa- preparation for exam, 648–652
tion), 250
customizing exams, 650–651
ping for fault detection, 46–47
tips for, 648–649
pip, installing Ansible via, 476–481
tools for, 649–650
PKCE flow (OAuth 2.0), 278–280
updating exams, 651
PKI (public key infrastructure),
prerequisites, validating, 534–536
254–262
prevention
browser security, 261–262
cost of, 60
certificate revocation, 256–257
of failures, 50
hierarchical structure of, 257
privacy protection, 250–252
purpose of CAs, 254–256
problem prevention, cost of, 60
web application security with TLS,
257–260 processes in 12-factor application
design, 240
planning for high availability, 50–51
programmability, definition of,
playbooks (Ansible), 483–487,
329–332
488–493
project-level inventory files in Ansible,
port binding in 12-factor application
482–483
design, 241
protecting privacy, 250–252
portability as quality attribute, 33
protobufs, 396
POST requests, 133, 336

BOOK.indb 703 19/05/22 5:58 PM

 704 Protocol Buffer (Protobuf) IDL (Interface Definition Language)

Protocol Buffer (Protobuf) IDL (Inter- pushing branches (Git)

face Definition Language), 154–155 to forked repo, 114
protocols in MDT, 396–397 to origin repo, 97
providers (Terraform), 517 PUT requests, 133, 336
provisioning networks, 290–291 pyang tool, 368–369, 382
accuracy of, 319–323 Python
from CLI/console, 291–294 AppDynamics APIs, 642–646
configuration management vs.449 DNA Center authorization, 637–639
EEM, 299–300 DNA Center documentation, 635–637
element management systems, extracting model support with,
297–299 410–413
file transfer methods, 297 installing Ansible via pip, 476–481
scalability in, 323–328 Intersight authorization, 606–611
SNMP, 294–297 Intersight documentation, 605
speed of, 317–318 logging levels, 75
ZTP, 300–303 Meraki authorization, 596–600
public APIs, 140, 335 Meraki documentation, 594–596
public documentation. See scripts with Puppet, 463–465
documentation
UCS Manager documentation,
public key infrastructure (PKI). See PKI 617–622
(public key infrastructure)
publisher/subscriber (pub/sub) model,
definition of, 15 Q
Puppet, 334
quality attributes. See nonfunc-
as agent-based solution, 450–473 tional requirements for software
downloading and installing, architecture
453–458
extracting information, 459–463
manifests, 469–473
R
NX-OS devices with, 465–469 rate limiting
Puppet platform support matrix, APIs, 184–188
451 for application performance,
Python scripts with, 463–465 71–72
described, 512 recoverability as quality attribute, 32
in evolution of application deploy- recovery, availability and, 47–50
ment, 221 reducing operation expenses, 329
with NETCONF and RESTCONF, 383 redundancy, recovery and, 47–50
push model in streaming telemetry, reflected XSS, 265
391–392

BOOK.indb 704 19/05/22 5:58 PM

 RESTful APIs 705

refresh tokens (OAuth 2.0), 181, planning, 50–51

280–281 recovery, 47–50
regulations governing privacy protec- as quality attribute, 30
tion, 251–252
resource owner password credential
relational databases, 80 flow (OAuth 2.0), 272–274
release stage (CI/CD), 205 resource utilitization as quality attri-
reliability as quality attribute, 30, 32 bute, 31
remote-procedure call (RPC) resources (Terraform), 517
definition of, 147 response time (RT). See latency
gRPC, 390 respositories (Git). See Git
REST vs.152–154 REST (representational state transfer).
replaceability as quality attribute, 33 See also RESTCONF; RESTful APIs
representational state transfer. See definition of, 147
REST (representational state RPC vs.152–154
transfer) RESTCONF
requirements authentication, 373
for database selection definition of, 371
data variety, 82–83 GET operations
data velocity, 82 with cURL, 375–377
data volume, 81–82 with Postman, 377–382
types of databases, 80–81 management solutions with, 382–383
for software architecture, 10–14 in MDT, 396
architectural decisions, 519–520 operations, 372–373
availability, 45 protocol stack, 372
business, 12 URIs, 373–374
comparison of functional and RESTful APIs, 157–158
nonfunctional, 12
cache-control, 151–152
constraints (limitations), 10
constraints on, 157
functional, 10–11, 12–13, 29
DNA Center
nonfunctional, 11–12, 13–14,
documentation, 631–635
29–36, 519
enabling access, 630–631
technical debt, 520–521
Firepower
resiliency
documentation, 583–585
in application design, 44–53
enabling access, 582–583
availability requirements, 45
use cases, 585–592
deployment models, 51–53
HTTP status codes, 184
failure prevention, 50
JSON, 150–151
fault detection, 46–47
NETCONF APIs vs.159

BOOK.indb 705 19/05/22 5:58 PM

 706 RESTful APIs

operation types, 336 SCM (software configuration manage-

streaming APIs vs.181–184 ment). See also automated configura-
tion management
uniform interfaces, 158
Ansible
Webex
comparison with Terraform,
documentation, 573–575
518–519
enabling access, 572–573
described, 512–514
use cases, 575–577
definitions and standards, 510–511
retries, recovery and, 49
in evolution of application deploy-
reusability as quality attribute, 33 ment, 220–224
reviewing list of systems, 512
current changes (Git), 94, 112 for maintainability, 59
staged changes (Git), 94, 112–113 purpose of, 511–512
reviews, 21–22 Terraform
revoking certificates, 256–257 comparison with Ansible,
rollbacks, recovery and, 50 518–519
rolling deployment (CI/CD), 206 described, 515–518
RPC (remote-procedure call) scope in modular design, 38
definition of, 147 Scrum, 19, 20, 318
gRPC, 390 SDKs (software development kits). See
REST vs.152–154 also clients (APIs)
RT (response time). See latency DNA Center
RTT (round-trip time), 66–67 authorization, 637–639
documentation, 635–637

S enabling access, 630–631

Firepower, enabling access, 582–583
SaltStack in evolution of application Intersight
deployment, 221 authorization, 606–611
sanity checks for fault detection, 47 documentation, 605
Sarbanes-Oxley Act of 2002 (SOX), Meraki
252
authorization, 596–600
scalability
documentation, 594–596
in application design, 41–44
enabling access, 592–593
horizontal, 41–42
UCS Manager
practical, 43–44
additional resources, 628
vertical, 42–43
PowerShell documentation,
in network provisioning, 323–328 622–628
of streaming telemetry, 391–392 Python documentation, 617–622

BOOK.indb 706 19/05/22 5:58 PM

 sensor groups, creating 707

Webex implicit flow, 275–276

documentation, 573–575 operational overview, 266–268
enabling access, 572–573 PKCE flow, 278–280
use cases, 577–582 refresh token flow, 280–281
SDLC (software development lifecycle) resource owner password cre-
phases of, 15–17 dential flow, 272–274
software architecture in, 510 three-legged authorization,
269–270
SDN (software-defined networking),
290, 329–335 two-legged authorization,
268–269
atomic networking vs.303–305
OWASP, 262–266
Cisco solutions for, 335
PKI, 254–262
contributing protocols and solutions,
333–334 browser security, 261–262
definition of, 329–332 certificate revocation, 256–257
error reduction in, 68 hierarchical structure of, 257
in evolution of network management purpose of CAs, 254–256
and software development, 7 web application security with
network controllers, 334 TLS, 257–260
northbound/southbound APIs, 135 privacy, 250–252
use cases, 332–334 as quality attribute, 30, 32
secrets. See IT secrets storage top 10 risks, 249–250
Secure Copy Protocol, 297 selecting
Secure File Transfer Protocol (SFTP), API architectural styles, 147–148
297 databases in application design, 79–83
security data variety, 82–83
in API development, 162, 179–181 data velocity, 82
of application containers, 564 data volume, 81–82
automation and, 343–344 types of databases, 80–81
CIA triad, 248–249 Git branching strategies, 122
in evolution of network management sensor paths, 407–413
and software development, 5 extracting NETCONF capabili-
IT secrets storage, 252–254 ties with Python, 410–413
for network provisioning, 293–294 manually extracting NETCONF
OAuth 2.0, 266–283 capabilities, 408–410
authorization code flow, public documentation for, 407
276–278 self-testing for fault detection, 46
client credential flow, 271–272 sensor groups, creating, 400,
device code flow, 281–283 404–405

BOOK.indb 707 19/05/22 5:58 PM

 708 sensor paths

sensor paths SNMP (Simple Network Management

definition of, 390, 394 Protocol)
selecting, 407–413 in evolution of network management
and software development, 5
extracting NETCONF capabili-
ties with Python, 410–413 network provisioning, 294–297
manually extracting NETCONF transition to streaming telemetry,
capabilities, 408–410 386–391
public documentation for, 407 SOA (service-oriented architecture),
definition of, 14–15
server load balancing in application
design, 41–42 SOAP (Simple Object Access Protocol),
definition of, 148, 335–336
serverless clouds, containers on,
227–234 software architecture
serverless functions, 234–238 application design
servers (APIs), definition of, 138 availability and resiliency in,
44–53
serviceability as quality attribute, 30
database selection in, 79–83
service-level agreement (SLA), 45
maintainability in, 59–66
service-oriented architecture (SOA),
definition of, 14–15 modularity in, 36–41
sessions (streaming telemetry), defini- scalability in, 41–44
tion of, 394 application performance
SFTP (Secure File Transfer Protocol), caching, 70–71
297 exponential backoff, 72–73
Simple Network Management Protocol latency, 66–73
(SNMP)
observability, 73–79
in evolution of network management
parallel processing, 72
and software development, 5
rate limiting, 71–72
network provisioning, 294–297
trade-offs in, 69
Simple Object Access Protocol (SOAP),
definition of, 148, 335–336 definition of, 9
simple ping for fault detection, 46–47 patterns, 14–15
single responsibility principle (SRP), 61 requirements, 10–14
site reliability engineering (SRE), architectural decisions, 519–520
196–198, 290 business, 12
DevOps vs.198 comparison of functional and
responsibilities of, 197–198 nonfunctional, 12
six nines (availability), 45 constraints (limitations), 10
SLA (service-level agreement), 45 functional, 10–11, 12–13, 29
sliding window (rate limiting), 188 nonfunctional, 11–12, 13–14,
29–36, 519
SMIv2 data types, 365–366
technical debt, 520–521

BOOK.indb 708 19/05/22 5:58 PM

 streaming telemetry 709

reviews, 21–22 Scrum, 19

in software development cycle, 510 waterfall, 17–18
software configuration management software engineers, definition of, 5
(SCM). See also automated configu- software quality. See nonfunc-
ration management tional requirements for software
Ansible architecture
comparison with Terraform, software-defined networking (SDN).
518–519 See SDN (software-defined
described, 512–514 networking)
definitions and standards, 510–511 SOLID design, 60–66
in evolution of application deploy- DIP (dependency inversion principle),
ment, 220–224 65–66
list of systems, 512 ISP (interface segregation principle),
64–65
for maintainability, 59
LSP (Liskov’s substitution principle),
purpose of, 511–512
63–64
Terraform
OCP (open-closed principle), 62–63
comparison with Ansible,
SRP (single responsibility principle),
518–519
61
described, 515–518
source code, compiling from, 218–220
software developers, definition of, 5
southbound APIs, 135
software development
SOX (Sarbanes-Oxley Act of 2002),
costs associated with, 60 252
evolution of, 5–8 spare recovery (cold standby), 49
methodologies and frameworks, 318 SQL (Structured Query Language)
reviews, 21–22 databases, 80
testing, 22–23 SRE (site reliability engineering),
software development kits (SDKs). See 196–198, 290
SDKs (software development kits) DevOps vs.198
software development lifecycle (SDLC) responsibilities of, 197–198
phases of, 15–17 SRP (single responsibility principle), 61
software architecture in, 510 staged changes (Git), reviewing, 94,
software development models, 112–113
17–21 standards of privacy protection,
Agile, 18–20 251–252
comparison of, 20–21 stored XSS, 264
Extreme Programming, 19 storing IT secrets, 252–254
Kanban, 19 streaming, 181–184
Lean, 19 streaming telemetry
Grafana, installing, 430–434

BOOK.indb 709 19/05/22 5:58 PM

 710 streaming telemetry

InfluxDB, installing, 426–427 system testing, 23

MDT system upgrades, recovery and, 49–50
dial-in mode configuration,
402–406
dial-in/dial-out comparison, 395
T
dial-out mode configuration, Tail-f Systems, 382
398–402 technical debt, 520–521
EDT vs.434–441 technical requirements for software
encodings in, 395–396 architecture, 13–14
implementation, 393–395 Telegraf
IOS-XR configuration, 397–398 installing, 428
protocols in, 396–397 purpose of, 426
sensor path selection, 407–413 telemetry. See streaming telemetry
terminology, 394–395 Terraform
use cases, 423–425 as agentless solution, 450, 493–501
YANG model investigation via ACI tenant deployment, 496–501
YANG Suite, 414–423 installing, 494–496
push model, 391–392 comparison with Ansible, 518–519
Telegraf, installing, 428 described, 493–494, 515–518
transition from SNMP, 386–391 in evolution of application deploy-
stress testing, 23 ment, 221
Structured Query Language (SQL) integration deployment to infrastruc-
databases, 80 ture, 207–213
Study Mode (exam preparation), 650 test preparation, 648–652
subscriptions customizing exams, 650–651
creating, 400–401, 405 tips for, 648–649
definition of, 395 tools for, 649–650
substitutability in application design, updating exams, 651
63–64 test stage (CI/CD), 205
Swagger, 147, 155–156 testability as quality attribute, 30, 33
SwaggerHub, 165–166 testing, 22–23
sysadmins in evolution of application TFTP (Trivial File Transfer Protocol),
deployment, 218–220 297
Syslog, logging with, 75 three nines (availability), 45
Syslog-NG utility, running in applica- three-legged authorization (OAuth 2.0),
tion container, 559–563 269–270
system requirements for software throughput, 66–67
architecture, 13

BOOK.indb 710 19/05/22 5:58 PM

 use cases 711

TIG stack. See Grafana; InfluxDB; two nines (availability), 45

Telegraf two-legged authorization (OAuth 2.0),
time series databases (TSDB), 80–81 268–269
time-based telemetry. See MDT (model- Type-1 hypervisors, 528
driven telemetry) Type-2 hypervisors, 528–529
timeouts
APIs, 184–188
recovery and, 49
U
time-series metrics. See metrics UCS Manager, 611–628
TLS (Transport Layer Security), 162, additional resources, 628
251, 257–260 API documentation, 611–617
token authentication (APIs), 180 enabling access, 611
token bucket (rate limiting), 187 PowerShell SDK documentation,
tracing 622–628
for application performance, 77–78 purpose of, 611
definition of, 74 Python SDK documentation, 617–622
transport (streaming telemetry) Unified Computing System Manager.
definition of, 395 See UCS Manager
protocols in, 396–397 uniform interfaces in RESTful APIs,
158
transport layer (NETCONF), 351
unit testing, 22
Transport Layer Security (TLS), 162,
251, 257–260 unlock operation (NETCONF), 350
Trivial File Transfer Protocol (TFTP), updating Pearson Test Prep software,
297 651
TSDB (time series databases), 80–81 URIs (Uniform Resource Identifiers),
134, 150, 373–374
12-factor application design, 238–242
URLs (Uniform Resource Locators),
admin processes, 242
150
backing services, 240
usability as quality attribute, 30, 32
build/release/run stages, 240
usability testing, 23
codebase, 239
use cases
concurrency, 241
for application containers, 532
configuration, 239
definition of, 13
dependencies, 239
Firepower API, 585–592
disposability, 241
for MDT, 423–425
logs, 242
for SDN, 332–334
parity, 241–243
Webex API, 575–577
port binding, 241
Webex SDK, 577–582
processes, 240

BOOK.indb 711 19/05/22 5:58 PM

 712 user error protection as quality attribute

user error protection as quality attri- LXC (Linux Containers),

bute, 32 529–530
user interface aesthetics as quality Type-1 hypervisors, 528
attribute, 32 Type-2 hypervisors, 528–529
user requirements for software archi- in evolution of network management
tecture, 13 and software development, 6
user stories, definition of, 13 visibility in 12-factor application
users (APIs), definition of, 138 design, 242
volume of data, 81–82
V
validating
W
gRPC dial-in configuration, 405–406 warm standby (passive recovery), 48
prerequisites, 534–536 waterfall model, 17–18, 20, 318
variables (Terraform), 517 web application security
variety of data, 82–83 OWASP, 262–266
Vault (Ansible), 481–482 TLS and, 257–260
VCS (version control system). See ver- web scraping, 135–136
sion control Webex, 571–582
velocity of data, 82 API examples, 575–577
verifying dial-out configuration, documentation, 573–575
401–402
enabling REST API/SDK access,
version control 572–573
CI/CD and, 198–199 purpose of, 571–572
Git SDK examples, 577–582
Branch and Pull Workflow, white-box testing, 23
89–103
workflows (Git), 88–89
branching strategies, 121–123
Branch and Pull Workflow, 89–103
features of, 88
branch creation, 93–94
Fork and Pull Workflow,
current changes review, 94
104–120
pros and cons, 89
recommended settings, 125–126
pushing branches to origin repo,
workflows, 88–89
97
for maintainability, 59
sample exercise, 90–103
vertical scaling in application design,
sample setup, 90
42–43
staged changes review, 94
virtualization
Fork and Pull Workflow, 104–120
in edge computing, 527–531
branch creation, 111
Docker containers, 530–531

BOOK.indb 712 19/05/22 5:58 PM

 ZTP (zero-touch provisioning) 713

current changes review, 112 EDT vs.434–441

pros and cons, 105 extracting support for
pushing branches to forked repo, manually via NETCONF,
114 408–410
sample exercise, 106–120 with Python and NETCONF,
sample setup, 105 410–413
staged changes review, 112–113 investigation via YANG Suite,
414–423

X list of, 412–413

management solutions for, 382
XML (Extensible Markup Language), in MDT and EDT, 390
338–340, 349, 395 NETCONF and, 365–371
XP (Extreme Programming), 19, 20 public documentation for, 407
XSS (cross-site scripting), 264–266 YANG Suite, 382, 415–423

Y Z
YANG models, 334 ZTD (zero-touch deployment), 449
data types in, 365–366 ZTP (zero-touch provisioning),
downloading, 369–371 300–303

BOOK.indb 713 19/05/22 5:58 PM