Segment Routing for

Service Provider and

Enterprise Networks
Florian Deragisch (CCIE #47970)
Leonir Hoxha (CCIE #49534)
Rene Minder (CCIE #8003)
Matthys “Thys” Rabe (CCIE #4237)
Kateel Vijayananda

Cisco Press
Hoboken, New Jersey
ii Segment Routing for Service Provider and Enterprise Networks

Segment Routing for Service Provider and

Enterprise Networks
Florian Deragisch
Leonir Hoxha
Rene Minder
Matthys Rabe
Kateel Vijayananda

Copyright© 2025 Cisco Systems, Inc.

Published by:
Cisco Press

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

No patent liability is assumed with respect to the use of the information contained herein. Although
every precaution has been taken in the preparation of this book, the publisher and author assume no
responsibility for errors or omissions. Nor is any liability assumed for damages resulting from the use of
the information contained herein.

$PrintCode
Library of Congress Control Number: 2024945941

ISBN-13: 978-0-13-823093-7

ISBN-10: 0-13-823093-5

Warning and Disclaimer

This book is designed to provide information about segment routing. 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 authors and are not necessarily those of
Cisco Systems, Inc.

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

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
information. Use of a term in this book should not be regarded as affecting the validity of any trademark
or service mark.
 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.

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

GM K12, Early Career and Professional Learning: Technical Editors: Jakub Horn, Christian
Soo Kang Schmutzer, Luc Andrew Burdet, Johan Gustawsson,
Bram Van der Zwet
Alliances Manager, Cisco Press: Caroline Antonio
Editorial Assistant: Cindy Teeters
Director, ITP Product Management: Brett Bartow
Designer: Chuti Prasertsith
Managing Editor: Sandra Schroeder
Composition: codeMantra
Development Editor: Ellie C. Bru
Indexer: Timothy Wright
Senior Project Editor: Mandie Frank
Proofreader: Barbara Mack
Copy Editor: Kitty Wilson

Americas Headquarters Asia Pacific Headquarters Europe Headquarters

Cisco Systems, Inc. Cisco Systems (USA) Pte. Ltd. Cisco Systems International BV Amsterdam,
San Jose, CA Singapore The Netherlands

Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco Website at www.cisco.com/go/offices.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks,
go to this URL: www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does
not imply a partnership relationship between Cisco and any other company. (1110R)
iv Segment Routing for Service Provider and Enterprise Networks

About the Authors

All the authors of this book are integral members of Cisco’s professional services and
product sales organizations. They have built extensive experience and expertise
throughout their careers, working closely with service providers and enterprise custom-
ers to design, implement, transform, and optimize cutting-edge network solutions.

Florian Deragisch, CCIE #47970, is a Technical Leader, working with large service
provider and carrier-grade enterprise customers. He joined Cisco in 2012 as part of a
graduate program, where he discovered his passion for service provider designs and tech-
nologies. After gaining extensive exposure to MPLS-based networks and services, he
embraced the evolution toward segment routing with his first SR-MPLS deployment in
2018. More recently, he has focused on the migration and deployment of L2VPN/L3VPN
SRv6 services to build simple and highly scalable network architectures. He holds a mas-
ter’s degree in electrical engineering and information technology from the Swiss Federal
Institute of Technology in Zurich and a Cisco Internetwork Expert certification (CCIE
#47970). When not busy with work, he enjoys traveling to explore new places, cultures,
and food.

Leonir Hoxha, CCIE #49534, has been with Cisco Systems since 2013, taking on
various roles on the Professional Services team and later on the Pre-sales team—from
troubleshooting to designing and implementing large-scale networks with a focus on
service provider technologies, specifically MPLS services. In his current role as a
Solutions Architect, he supports service providers and enterprise customers by under-
standing their requirements and providing cutting-edge solutions. An active speaker at
Cisco Live conferences, he has delivered numerous sessions on segment routing across
Europe, the United States, and Australia. He holds a bachelor’s degree in computer
science and a Cisco Internetwork Expert certification (CCIE #49534). In his free time,
he enjoys electronic music, a nod to his first job as a DJ during his teenage years.

Rene Minder, CCIE #8003, is a Senior Program Advisor and Solution Architect with
over 25 years of experience in the IT industry. He has been responsible for architecture
and delivery in more than 70 customer engagements, evolving their networks and manage-
ment infrastructures as well as the processes for developing, testing, and deploying them.
He has led end-to-end IT architecture projects encompassing everything from portals
offering service self-administration capabilities, to IT applications that automatically
configure and test changes, to invoicing. His efforts have led to significant improvements
in customer satisfaction, operational efficiency, and overall agility. He holds Lifetime
Emeritus status for his Cisco Internetwork Expert certification (CCIE #8003).

Matthys “Thys” Rabe, CCIE #4237, a Lifetime Emeritus Cisco Certified Internetwork
Expert (CCIE #4237), is a Technical Leader at Cisco Systems and holds a diploma in
electrical engineering (telecommunications). With more than 25 years of experience in IP
and MPLS operations with various service providers in South Africa and Switzerland, he
has spent the past 10 years as a Technical Support Engineer focused on Swisscom. Prior
to working at Cisco Systems, he was part of the Core IP Engineering team with a Swiss-
based mobile provider. When he’s not working, he enjoys fishing with his brothers in
various southern African countries.
 v

Kateel Vijayananda, is a solutions architect at Cisco Systems and has more than 30 years
of experience in the networking industry. His expertise includes IPv6, IP services, design
of large-scale networks for enterprise and service provider customers, and QoS assurance
in IP networks. He has been with Cisco Systems since 2001, involved in several projects
for service providers to deploy IP-based services using MPLS and segment routing.
Before joining Cisco, he worked at Swisscom, a service provider in Switzerland, where
he was responsible for developing MPLS VPN services. He is the co-author of the book
Developing IP-Based Services: Solutions for Service Providers and Vendors. He
holds a master’s degree in computer science from the University of Maryland at College
Park and a PhD in computer science from the Swiss Federal Institute of Technology at
Lausanne (EPFL). In his spare time, he enjoys traveling and cooking.
vi Segment Routing for Service Provider and Enterprise Networks

About the Technical Reviewers

Jakub Horn has worked for more than 20 years at Cisco Systems and currently serves as
a Principal Technical Marketing Engineer, specializing in cutting-edge technologies for
service providers. Prior to this role, Jakub was a Network Consulting Engineer, delivering
strategic solutions to global clients. His journey in tech began at IBM, where he honed
his skills in networking and computer systems. Today, Jakub’s expertise is centered on
SRv6 technology, driving innovation in network architecture. As a passionate technolo-
gist, he continuously explores new advancements to shape the future of connectivity.

Christian Schmutzer is a Distinguished Engineer at Cisco Systems and has been with the
company since 1998. Early in his career, he primarily worked on the design and deploy-
ment of large service provider backbones. He has been part of a business unit since 2005,
serving as a technical subject matter expert for market-leading routing platforms such as
the Cisco 7600 and ASR 9000. Since 2013, he has focused on packet/optical network
architectures, future product definition, technology innovation, and leading customer
deployments. He is the holder of several patents and the author of a series of IETF
standards documents.

Bram van der Zwet is the Lead Architect for Network & Infrastructure at Swisscom, where
he has been shaping the network architecture and technical strategy for Swisscom’s IP and
optical networks. His responsibilities extend to overseeing the physical infrastructure from
Swisscom’s IT and data centers down to the central offices in regional networks. He holds a
degree from Delft University of Technology and is based in Bern, Switzerland. With more
than 25 years of experience at Swisscom and a history of strategic roles driving innovation
and excellence, he has become a key figure in the telecommunications industry.

Johan Gustawsson is a Senior Director within Cisco Data Center and Service Provider,
focusing on driving the direction and strategy for routing and architectures. He has spent
his entire career operating and building mass-scale networks, pioneering and driving
market disruptions across routing and optical domains. Prior to joining Cisco, Johan was
the Head of Network Architecture, Strategy, and Engineering at Arelion (formerly Telia
Carrier), leading a globally distributed organization at the world’s number-one-ranked
Internet backbone. Johan holds a degree in Engineering from the KTH Royal Institute of
Technology in Stockholm.

Luc André Burdet is a Senior Technical Leader in Engineering at Cisco, where he has
been instrumental in driving innovation and strategic initiatives since May 2012. With
more than 12 years of experience at Cisco, he focuses on advancing the company’s engi-
neering capabilities and leading key technical projects. He holds a master’s degree from
ETH Zürich and is based in Ottawa, Ontario. Luc André’s technical expertise and leader-
ship have established him as a pivotal figure in the networking industry, significantly
contributing to Cisco’s engineering excellence.
 vii

Acknowledgments
First and foremost, we would like to thank our main reviewers, Jakub Horn and Christian
Schmutzer, for their meticulous reviews and invaluable feedback. Their dedication and
attention to detail have significantly enhanced the quality of this book.

We also extend our thanks to Luc Andre Burdet for his expertise in the chapter focused
on Layer 2 VPN technologies, and to Bram Van der Zwet and Johan Gustawsson for
reviewing the chapters on business opportunities and organizational considerations. Your
feedback has been instrumental in ensuring the accuracy and relevance of the information
presented.

Special thanks to Marcel Witmer for all the support around PLE and integrated visibility
and to Christian Schmutzer for his solid insight and input on PLE. We also appreciate
Kaela Loffler and Ramiro Nobre for providing an overview on how micro-drops can
influence overall service performance. Similarly, we would like to express our gratitude
to Carmine Scarpitta and Ahmed Abdelsalam for their guidance on FRRouting’s SRv6
implementation.

The authors had the pleasure of collaborating with Swisscom, a leading service provider
based in Switzerland, on several aspects covered in this book. The insights gained from
Swisscom’s exposure to engineering, migrations, and operations have enriched the
content, providing field perspectives that are invaluable for readers.

This book wouldn’t have been possible without the support of many people on the Cisco
Press team. Brett Bartow, Product Line Manager of the Pearson IT professional Group,
was instrumental in sponsoring the book and driving it to execution. Sandra Schroeder,
Managing Editor, was masterful with book graphics. Ellie Bru, Development Editor, has
done a wonderful job in the technical review cycle; it has been a pleasure working with
you. Mandie Frank, Senior Project Editor, thank you for leading the book to success
through the production cycle. Kitty Wilson, Copy Editor, thank you for polishing up the
book and making the content more shiny. Also, many thanks to the numerous Cisco Press
unknown soldiers working behind the scenes to make this book happen.

We would like to express our deepest gratitude to our Cisco management for supporting
and encouraging us in creating this book. Thank you to everyone who has contributed to
this book. Your support and expertise have made this project possible.

Finally, we would like to extend our heartfelt thanks to our families. Your unwavering
support, patience, and understanding have been our pillars of strength throughout the
writing process. The countless hours spent away from you to work on this book have not
gone unnoticed, and we are deeply grateful for your encouragement and understanding.
viii Segment Routing for Service Provider and Enterprise Networks

Contents at a Glance
Introduction xx

Part I Introduction
Chapter 1 MPLS in a Nutshell 1

Chapter 2 What Is Segment Routing over MPLS (SR-MPLS)? 33

Chapter 3 What Is Segment Routing over IPv6 (SRv6)? 103

Part II Segment Routing

Chapter 4 Segment Routing in Detail 219

Chapter 5 Migrating to Segment Routing 353

Part III Service Design

Chapter 6 L2VPN Service Deployment: Configuration and Verification Techniques 439

Chapter 7 L3VPN Service Deployment: Configuration and Verification Techniques 605

Chapter 8 Service Assurance 783

Chapter 9 High Availability and Fast Convergence 857

Part IV Business and Operational Considerations

Chapter 10 Business Opportunities 997

Chapter 11 Organizational Considerations 1043

Appendix A Reference Diagrams and Information 1109

Index   1115

Online Element:

Chapter 12 SRv6 Ecosystem Deployment Use Cases 1

 ix

Reader Services
Register your copy at www.ciscopress.com/title/ISBN for convenient access to
downloads, updates, and corrections as they become available. To start the registration
process, go to ciscopress.com/register and log in or create an account*. Enter the product
ISBN 9780138230937 and click Submit. When the process is complete, you will find
any available bonus content under Registered Products.

*Be sure to check the box that you would like to hear from us to receive exclusive
discounts on future editions of this product.
For access to any available bonus content associated with this title, visit ciscopress.com/sr,
sign in or create a new account, and register ISBN 9780138230937 by December 31, 2027.
x Segment Routing for Service Provider and Enterprise Networks

Contents
Introduction xx

Part I Introduction

Chapter 1 MPLS in a Nutshell   1

How MPLS Operates   4
MPLS Label Structure   6
Control Plane and Data Plane   10
Label Distribution Protocol (LDP)   11
Label Allocation Mechanism   12
MPLS Label Operations   14
Traffic Forwarding Using Labels   15
MPLS VPN Services Overview   16
MPLS Traffic Protection   18
Challenges and Shortcomings of MPLS   19
MPLS Label Space Limitation   20
LSP and Summarization   21
Inter-AS Limitations   21
Lack of End-to-end QoS Control   21
Configuration and Operational Complexity of MPLS/VPN
and BGP   22
RSVP-Based Traffic Engineering   22
LDP–IGP Synchronization   24
Load Balancing and Hashing   25
Beyond MPLS   28
Summary   30
References and Additional Reading   32

Chapter 2 What Is Segment Routing over MPLS (SR-MPLS)?   33

Problem Description and Requirements   40
Segment Routing over MPLS (SR-MPLS)   41
Data Plane   41
Segment Identifier (SID)   42
SID Allocation   43
IGP Prefix Segment (Prefix SID)   45
IGP Adjacency Segment (Adjacency SID)   47
BGP Prefix Segment (BGP Prefix SID)   49
 Contents xi

BGP Peering Segments (BGP Peering SIDs)   50

Binding Segment (Binding SID)   52
IGP Extensions   53
IS-IS Extensions for Segment Routing (RFC 8667)   53
OSPF Extensions for Segment Routing (RFC 8665)   64
IGP Flexible Algorithm (Flex Algo) (RFC 9350)   73
MP-BGP Extensions   83
SR Prefix SID Extensions for BGP (RFC 8669)   85
BGP Link-State Extensions for SR (RFC 9085)   87
BGP Link-State Extensions for SR BGP Egress Peer Engineering
(RFC 9086)   95
Summary   99
References and Additional Reading   100

Chapter 3 What Is Segment Routing over IPv6 (SRv6)?   103

Introduction   103
Segment Routing over IPv6 (SRv6)   103
IPv6 for SRv6 Recap   104
SRv6 Network Programming (RFC 8986)   107
SRv6 Segment Identifier (SID)   107
IPv6 Segment Routing Header (SRH) (RFC 8754)   123
Penultimate Segment Pop of the SRH   127
Ultimate Segment Pop of the SRH   129
Ultimate Segment Decapsulation   130
SRv6 Policy Headend Behaviors   132
SRv6 Policy Endpoint Behaviors   141
SRv6 Headend and Endpoint Behavior Overview   146
SRv6 Network Programming Extension: SRv6 uSID Instruction   147
uN Endpoint Variants   152
uA Endpoint Variants   156
SID Compression   161
Addressing Considerations   162
IPv6 Addressing   162
SRv6 Locator Addressing Scheme   165
Summarization   172
IGP Extensions   175
IS-IS Extensions for Segment Routing over IPv6 (RFC 9352)   175
xii Segment Routing for Service Provider and Enterprise Networks

MP-BGP Extensions   186

BGP Overlay Services on SRv6 (RFC 9252)   186
BGP Link-State Extensions for SRv6 (RFC 9514)   201
SR-Powered Network Evolution   205
MPLS Network Architecture: Control and Data Plane Overview   205
SR-MPLS Network Architecture: Control and Data
Plane Overview   207
SRv6 Network Architecture: Control and Data Plane Overview   209
Network Evolution at a Glance   210
SR-MPLS or SRv6   212
Benefits of Deploying Segment Routing   212
Hardware and Software Support   214
Feature Support   215
Summary   215
References and Additional Reading   217

Part II Segment Routing

Chapter 4 Segment Routing in Detail   219

Link-State IGPs   221
IS-IS   221
IS-IS Levels   222
IS-IS Areas   222
IS-IS Router Types   222
IS-IS Routing   222
IS-IS Route Propagation and Leaking   223
IS-IS Overload Bit   223
OSPF   224
OSPF SPF Algorithm   224
OSPFv3   225
OSPFv3 Route Summarization   225
OSPFv3 Route Filtering   225
Segment Routing Baseline   225
SR-MPLS Baseline   226
Segment Routing Global Block (SRGB)   226
Segment Routing Local Block (SRLB)   227
SR-MPLS Addressing   227
SR-MPLS Configuration   228
 Contents xiii

SR-MPLS Verification   231

SRv6 Baseline   236
SRv6 uSID   236
SRv6 Addressing   237
SRv6 uSID Configuration   239
SRv6 uSID Verification   241
Segment Routing Control Plane (IGP)   243
SR-MPLS Control Plane   243
SR-MPLS IS-IS   244
SR-MPLS OSPF   250
SR-MPLS Anycast SID   254
SRv6 Control Plane   257
SRv6 IS-IS   257
SRv6 OSPF   301
Multiplane Topologies with Flex Algos   301
Components of SR Flex Algos   302
Flex Algo Use Cases Scenarios   304
SR-MPLS Configuration for Flex Algo Use Cases   322
Segment Routing Control Plane (BGP)   324
BGP Prefix SID   324
BGP Prefix SID Configuration   324
BGP Prefix SID Verification   327
Intra-AS BGP-LU with a BGP Prefix SID   328
Intra-AS BGP-LU Design   330
BGP Additional Path   331
Intra-AS BGP-LU Configuration   332
Intra-AS BGP-LU Verification   337
Data Forwarding from PE-1 to PE-3   341
Inter-AS BGP-LU   343
Inter-AS BGP-LU Design   343
Inter-AS BGP-LU Configuration   344
Inter-AS BGP-LU Verification   345
Data Forwarding from PE-1 to PE-5   349
Summary   350
References and Additional Reading   352
xiv Segment Routing for Service Provider and Enterprise Networks

Chapter 5 Migrating to Segment Routing   353

Deployment Models   354
Migration Strategies   355
SR-MPLS Migration   358
SR-MPLS Reference Network Topology   358
Enabling SR-MPLS in an Existing Network (Coexistence)   358
Enabling SR-MPLS on P2, P3, and PE-3   360
Enabling and Preferring SR-MPLS on P1, P2, and PE-1   363
Building a New SR-MPLS Network   365
Enabling SRMS   365
Enabling LDP on the Border Node   372
Enabling the BGP Prefix SID in an SR-MPLS Network   376
BGP Proxy Prefix SID   383
SRv6 Migration   387
Building a New SRv6 Network Using an SRv6 IWG   389
Migration Use Case   391
Building a New SRv6 Network Using Inter-AS Option A   401
Migration Use Case   403
Building a New SRv6 Network Using Dual-Connected PE Devices   413
Migration Use Case   415
High Availability   425
Active-Active   425
Active-Backup   426
Load Sharing   426
Migration Paths from MPLS to SRv6   427
Flat MPLS Network   429
Unified MPLS Network   430
MPLS Network with Inter-AS Option C   431
Carrier Supporting Carrier MPLS Network   434
Summary   435
References and Additional Reading   437

Part III Service Design

Chapter 6 L2VPN Service Deployment: Configuration and

Verification Techniques   439
L2VPN (EVPN)   440
EVPN in Detail   442
 Contents xv

EVPN Instance (EVI)   445

Ethernet Segment (ES)   447
Ethernet Tag ID   450
EVPN BGP Routes   452
EVPN E-LAN   472
SRv6 EVPN E-LAN Service Configuration and Verification   474
EVPN E-Tree   551
SRv6 EVPN E-Tree Service Configuration   552
EVPN E-Line   569
SRv6 EVPN E-Line (VPWS) Service Configuration   571
Summary   602
References and Additional Reading   602

Chapter 7 L3VPN Service Deployment: Configuration and

Verification Techniques   605
L3VPN   606
SRv6 L3VPN Overlay Service   608
SRv6 L3VPN Full-Mesh Service   610
SRv6 L3VPN Hub-and-Spoke Service   636
SRv6 L3VPN Extranet Service   657
SR-MPLS L3VPN Overlay Service   677
SR-MPLS L3VPN Full-Mesh Service   688
SR-MPLS L3VPN Hub-and-Spoke Service   719
SR-MPLS L3VPN Extranet Service   752
Route Target Constraint   767
Route Target Constraint Configuration and Verification   771
Summary   780
References and Additional Reading   781

Chapter 8 Service Assurance   783

Transport   784
Segment Routing Data Plane Monitoring (SR-DPM)   788
SR-DPM Configuration and Verification   789
Path Tracing (PT)   798
Services   806
L2VPN Service Assurance   806
Ethernet Connectivity Fault Management (CFM)   808
ITU-T Y.1731 Performance Measurement   816
xvi Segment Routing for Service Provider and Enterprise Networks

L3VPN Service Assurance   834

IPSLA and TWAMP   834
Summary   855
References and Additional Reading   855

Chapter 9 High Availability and Fast Convergence   857

BFD Failure Detection Mechanism   858
BFD BoB Configuration   865
BFD BoB Verification   868
BFD BLB Configuration   872
BFD BLB Verification   874
Topology-Independent Loop-Free Alternate (TI-LFA)   878
Link Protection Configuration   883
Link Protection Verification: SR-MPLS   885
Link Protection Verification: SRv6   902
Node Protection Configuration   914
Node Protection Verification: SR-MPLS   917
Node Protection Verification: SRv6   919
SRLG Protection Configuration   921
SRLG Protection Verification: SR-MPLS   923
SRLG Protection Verification: SRv6   931
Microloop Avoidance   935
BGP PIC Edge   943
BGP PIC Edge Configuration: SR-MPLS   948
BGP PIC Edge Verification: SR-MPLS   951
BGP PIC Edge Configuration: SRv6   962
BGP PIC Edge Unipath Verification: SRv6   970
BGP PIC Edge Multipath Verification: SRv6   981
Summary   995
References and Additional Reading   995

Part IV Business and Operational Considerations

Chapter 10 Business Opportunities   997

Technological Opportunities and Benefits   999
Fewer Protocols   999
More QoS Options   1001
SR from the Access Network to the Data Center Network   1003
Traffic Engineering and Network Slicing   1005
 Contents xvii

Scale   1007
Routed Optical Networks   1008
Benefit 1: Simplified Long-Distance Connectivity   1008
Benefit 2: Easier and Cost-Effective Scaling   1009
Benefit 3: Simplified Redundancy   1009
Private Line Emulation   1011
Integrated Visibility   1017
Intent-Driven Configuration of Visibility Features   1018
Intent-/Model-Based Assurance   1019
High-Precision Probing   1020
Path Tracing   1023
New Hardware Generation   1025
CapEx Savings   1026
OpEx Savings   1030
Business Case Guidance   1032
Summary   1039
References and Additional Reading   1040

Chapter 11 Organizational Considerations   1043

Scenario 1: Replacing or Enhancing a Legacy Network with SR   1046
Knowledge   1046
Migration Strategy   1049
IT Evolution and Gap Awareness   1051
Scenario 2: Consolidating Networks and Services   1056
Domain Definitions   1056
Domain Architecture Blueprint   1059
Domain Responsibilities and Their Architectural Implications   1067
Domain Organization and Transformation   1074
Existing and New Processes   1083
Service Portfolio Consolidation   1083
Development and Release Methodology   1084
Process with a Clear Flow   1086
Environments   1089
Domain Releases: A Symphony of Component Builds and
Release Candidates   1096
Tooling: Embracing Automation for Environment and
Process Efficiency   1097
Tooling: Source of Truth   1098
xviii Segment Routing for Service Provider and Enterprise Networks

Tooling: Binary Repository   1100

Tooling: Pipelines   1101
Change Management Across Domains   1104
Summary   1106
References and Additional Reading   1107

Appendix A Reference Diagrams and Information   1109

SR-MPLS Reference Network   1109
SRv6 Reference Network   1111
SR Migration Reference Network   1112

Index 1115

Online Element:

Chapter 12 SRv6 Ecosystem Deployment Use Cases   1

SRv6 Open-Source Implementations   2
Linux Kernel   2
Free Range Routing (FRR)   7
Vector Packet Processor (VPP)   9
Software for Open Networking in the Cloud (SONiC)   13
SRv6 Open-Source Lab Deployment Examples   17
Linux SRv6 Deployment   18
Containerlab   20
Linux Underlay Connectivity   24
Linux IPv4 L3VPN Service   27
Linux IPv6 L3VPN Service   32
Linux IPv4/IPv6 L3VPN Service   34
Linux Point-to-Point L2VPN Service   36
VPP SRv6 Deployment   39
Basic VPP Setup   40
VPP Underlay Connectivity   43
VPP IPv4 L3VPN Service   45
VPP IPv6 L3VPN Service   54
VPP Point-to-Point L2VPN Service   57
SRv6 L3VPN Interoperability   61
Free Range Routing IPv4 L3VPN Service   62
Cisco Catalyst 8000V Edge IPv4 L3VPN Service   75
Summary   82
References and Additional Reading   83
 xix

Icons Used in This Book

Router Layer 3 Storage Fibre Channel Network

Switch Fabric Switch Cloud, White

Headquarters Branch Server Server WIFI

Satellite Phone Satellite House Debian

Dish

VPP Ubuntu

Command Syntax Conventions

The conventions used to present command syntax in this book are the same conventions
used in Cisco’s Command Reference. The Command Reference describes these
conventions as follows:

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

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

■■ Braces { } indicate a required choice.

xx Segment Routing for Service Provider and Enterprise Networks

Introduction
Welcome to the future of MPLS and the realm of advanced networking technologies,
where efficiency, scalability, and reliability are paramount. This book is your gateway to
mastering segment routing (SR), a revolutionary technology that transforms IP data trans-
port and network operations. From the foundational principles of MPLS to state-of-the-
art implementations of SR over MPLS (SR-MPLS) and SR over IPv6 (SRv6), this book
offers a comprehensive guide that bridges the gap between theory and practice.

The chapters cover the entire spectrum of SR, providing a holistic understanding of
the technology. They feature practical examples for SR on both IOS XR and IOS XE
platforms, ensuring that you have the knowledge to implement SR in different network
environments.

This book also goes beyond technical details. It delves into the business opportunities
and organizational implications of adopting SR, offering valuable insights into how SR
can drive growth, improve customer experience, and streamline operations. Dedicated
sections on the SRv6 ecosystem in data centers and cloud environments showcasing
network functions virtualization (NFV) prepare you for the next wave of networking
innovations.

Available online content enables you to gain hands-on practice and reinforce the theories
covered. A business case template provides a tool to legitimize investments in SR
technologies and calculate potential returns.

By the end of this book, you’ll be equipped with the knowledge and tools to implement
and manage SR technologies effectively, helping you stay ahead in this ever-evolving field.

What Sets This Book Apart

What distinguishes our book is its unique blend of content, offering readers an
unparalleled experience that combines theoretical aspects of segment routing with
hands-on experience from actual deployments.

■■ Practical insights: Drawing from real-world experiences, particularly our collaboration

with Swisscom, this book provides real-world insights that bridge the gap between
theory and practice. In this book you will find detailed configurations, design guide-
lines, and troubleshooting tips that are directly applicable to your work environment.

■■ Step-by-step approach: The content of this book is structured to guide you

through a logical progression of information, from basic concepts to advanced
implementations, making it suitable for both beginners and seasoned professionals.
Each chapter builds on the previous one, providing a smooth learning curve.

■■ Future-proofing: With a dedicated section on the future of SRv6, featuring

open-source SRv6 NFV implementations that can fit in data centers and cloud
environments, this book prepares you for the next wave of networking innovations.
 Introduction xxi

■■ Interactive learning: Downloadable content provides lab topology definitions,

configurations, scripts, and templates to help you set up your own labs and
experiment with them. Additionally, a lab guide is available, offering the option to
run your lab in the cloud.

■■ Beyond technology: In addition to technical content, the business-oriented chapters

outline the benefits of adopting SR and offer guidance in various areas to help
leadership and teams smoothly transition to SR.

Goals and Methods

The primary goal of this book is to provide a thorough understanding of SR by offering
detailed explanations, configuration examples, verification hints, and packet captures.
It walks you through foundational concepts and practical implementations.

Two reference lab topologies, one for SR-MPLS and one for SRv6, are consistently
referenced throughout the technical chapters. To make the learning process interactive
and engaging, the downloadable lab support material enables you to set up your own lab
so you can replicate and apply the described theory.

Who Should Read This Book?

This book is designed for network engineers, architects, and operators who are involved
in the design, deployment, and management of modern networking infrastructures. It is
also valuable for IT professionals, students, and researchers who wish to deepen their
understanding of SR technologies. Business leaders and decision makers will find the
chapters on new service opportunities and what to consider within an organization on
the journey to SR particularly insightful.

How This Book Is Organized

The chapters in this book guide you from basic concepts to advanced implementations,
ensuring a logical progression of information. A recap of MPLS is followed by an in-
depth exploration of SR, detailed configurations, migration strategies, service assurance,
and high availability. The final chapters provide a glimpse into the future of SRv6 in data
centers and cloud environments, explore business opportunities that justify investment in
this new technology, and offer non-technical thoughts to streamline the transition to SR.

This book is broken into 12 chapters and an appendix:

■■ Chapter 1, “MPLS in a Nutshell”: This chapter provides an introduction to MPLS

technology and its significance in modern networking as well as an overview of
MPLS mechanisms and benefits.

■■ Chapter 2, “What Is Segment Routing over MPLS (SR-MPLS)?”: This chapter

provides a basic introduction to the general concepts of segment routing (SR) and
explores SR-MPLS in the control plane and data plane.
xxii Segment Routing for Service Provider and Enterprise Networks

■■ Chapter 3, “What Is Segment Routing over IPv6 (SRv6)?”: This chapter explores
SRv6 in the control plane and data plane and provides an overview of the evolution
and simplification of SR-driven networks.

■■ Chapter 4, “Segment Routing in Detail”: This chapter includes detailed information

on configuration and verification of SR on Cisco devices and describes design
guidelines and advanced features for SR networks.

■■ Chapter 5, “Migrating to Segment Routing”: This chapter is a practical roadmap

for migrating from MPLS to SR and presents strategies for greenfield and brownfield
deployments.

■■ Chapter 6, “L2VPN Service Deployment: Configuration and Verification

Techniques”: This chapter provides an overview of customer-related L2VPN
services implemented on an SRv6 underlay network. It includes basic configuration
methodologies and service verifications.

■■ Chapter 7, “L3VPN Service Deployment: Configuration and Verification

Techniques”: This chapter provides an overview of customer-related L3VPN
services implemented on SRv6 and SR-MPLS underlay networks. It includes basic
configuration methodologies and service verifications.

■■ Chapter 8, “Service Assurance”: This chapter presents procedures and processes for
improving customer experience and satisfaction. It includes a discussion of tools and
protocols for SLA monitoring and fault management in the transport network layer,
as well as in the L2VPN and L3VPN service overlays.

■■ Chapter 9, “High Availability and Fast Convergence”: This chapter introduces

technologies and features for high availability and fast convergence in SR networks.
It includes a detailed discussion of failure detection, path computation, and network
convergence.

■■ Chapter 10, “Business Opportunities”: This chapter describes the benefits of

investing in SR and why network service providers should transition to this
technology. It offers insights into how SRv6 can offer substantial opportunities and
advantages over SR-MPLS as well as business case calculation guidance.

■■ Chapter 11, “Organizational Considerations”: This chapter examines the impact of

SR on organizational structures and processes and provides a guide to managing the
transformation to a programmable SR network.

■■ Chapter 12, “SRv6 Ecosystem Deployment Use Cases”: This online only chapter
discusses the potential of SRv6 in data centers and cloud environments. It provides
examples and interoperability scenarios involving open-source software.

■■ Appendix A, “Reference Diagrams and Information”: This appendix describes

the reference diagrams and information of the SR-MPLS, SRv6, and SR migration
network topologies used throughout the book in a single location for the reader’s
convenience.
 Introduction xxiii

Downloadable Content
Readers can access downloadable content using the companion website as per the
instructions below:

1. The user enters ciscopress.com/sr in his browser or clicks the hyperlink in the online
book version.

2. The user completes the registration/login process.

3. The user confirms the already prepopulated ISBN number of the book and answers a
proof-of-purchase challenge question, to access additional content.
4. The user clicks on the desired attachment.

The following attachments can be downloaded for use with this book:

■■ SR-MPLS-Reference-Configuration-Lab.zip: These files, which can be used across

the entire book, include a reference diagram and configurations to deploy an
SR-MPLS and services lab.

■■ SRv6-Reference-Configurations-Lab.zip: These files, which can be used across the

entire book, include a reference diagram and configurations to deploy an SRv6 and
services lab.

■■ SRv6-Online-Lab-Guide.pdf: This guide provides clear instructions on how to use an

online lab, offering you the flexibility to run your SRv6 lab in the cloud.

■■ SRv6-Migration-Lab.zip: These files, which are meant to be used with Chapter 5,

include a reference diagram and configuration for migration use cases.

■■ SRv6-Linux-Lab.zip: These files, which are meant to be used with Chapter 12,
include a container-based lab topology definition and initialization script required to
spin up the SRv6 Linux lab topology.

■■ SRv6-VPP-Lab.zip: These files, which are meant to be used with Chapter 12,
include a bash script to spin up the SRv6 VPP topology, VPP instances, and startup
configurations.

■■ SRv6-Interop-Lab.zip: These files, which are meant to be used with Chapter 12,
include a Cisco CML topology definition and a running configuration of PE1
(IOS XR), P (IOS XE), and PE3 (IOS XE), as well as FRR settings and configuration
for PE2 (FRR).

■■ Segment-Routing-Business-Case-Template.xlsx: This file, which is meant to be used

with Chapter 10, includes a Microsoft Excel–based business case template to help
you create your case for SR in your organization. Please review the provided sample
data and update all cells that have a yellow background to reflect your specific
information.

Note This book contains references to the companion website in later chapters which
leverage the previously listed downloadable content.
This page intentionally left blank
 Chapter 1

MPLS in a Nutshell

Multiprotocol Label Switching (MPLS) is a well-established data transmission technology

that is widely used among telecommunication companies, service providers, and enter-
prise networks. MPLS technology can transport protocols such as IP, Ethernet, ATM,
SDH, and SONET. Any incoming data packet with source and destination IP addresses is
encapsulated by appending a tag. This tag, in MPLS terminology, is a label. MPLS tech-
nology has become a vital component of modern networking infrastructure. It allows for
efficient data transfer and management by providing a streamlined approach to packet
forwarding. Using label forwarding instead of IP routing has also led to significant net-
work performance and scalability improvements.

In the late 1990s, the first implementations of MPLS marked a significant advancement,
making it possible to append tags to data packets and route them through a chain of
nodes. MPLS was revolutionary because it enabled constant-length lookups on a 4-byte
label, making packet forwarding much more efficient compared to the variable-prefix-
length IP lookups used in traditional IP routing. Initially, MPLS used Tag Distribution
Protocol (TDP) to attach labels to packets; it later evolved to use Label Distribution
Protocol (LDP) for more sophisticated label management. MPLS can operate on a BGP-
free core, significantly reducing the memory requirements for core routers. A BGP-free
core means only the provider edge (PE) nodes use BGP, and the core (P) nodes are BGP
free. The use of MPLS labels for forwarding enabled a wide variety of data types to be
carried across a single network infrastructure. These innovations made MPLS a powerful
tool for optimizing network performance and scalability.

With traditional MPLS technology, LDP labels need to follow whatever the interior
gateway protocol (IGP) chooses as the best path. The advantage of MPLS is that no IP
lookup is conducted on the transit nodes (core nodes); instead, only label-based forward-
ing is performed. The fact that a router does not have to do an IP lookup in the routing
table but instead forwards the packets based on the label itself brought a lot of possibili-
ties in terms of how packets are processed, resulting in higher performance of the router
2 Chapter 1: MPLS in a Nutshell

itself and, most significantly, offering differentiated services on top of the MPLS-based
network.

MPLS is a shared network infrastructure used for a wide range of services. With it, there
is no need for distinct physical network infrastructure to serve different services for end
customers. Providing various services and solutions using a shared network infrastructure
lowers the overall cost for network operators. Network operators can provide multiple
services over MPLS networks for their end customers, making deployment of these ser-
vices technically independent from the MPLS layer. Speaking of services, MPLS provides
the possibility to offer services such as Internet services for private and public customers
as well as virtual private network (VPN) services. From a high-level point of view, VPN
services can be classified into the following categories:

■■ Layer 3 VPN: Known as L3VPN and described in RFC 2547

■■ Layer 2 VPN: Known as L2VPN and described in RFC 4664

■■ Multicast VPN: Known as mVPN and described in RFC 6513

L3VPN services offer an efficient way to provide any-to-any mesh connectivity at the
IP address level. Each customer edge (CE) device attaches to a provider edge (PE) node,
establishing IP-based neighborship through an IGP, Border Gateway Protocol (BGP), or
static configuration. PE nodes connect to multiple CE devices and maintain separate
routing tables for each customer using virtual routing and forwarding (VRF) instances.
VRF instances ensure local routing table separation, while L3VPN enables deterministic
connectivity among different VRF instances.

In an L3VPN setup, each PE node creates a unique VRF instance for every customer,
ensuring isolation of each customer’s routing information. The PE nodes receive IP pre-
fixes from their connected CE devices and use Multiprotocol BGP (MP-BGP) to distrib-
ute these prefixes to other PE devices in the network. MP-BGP extends BGP to support
multiple address families, enabling the PE nodes to handle both IPv4 and IPv6 prefixes as
well as VPN-IPv4 and VPN-IPv6 prefixes.
The process begins when a CE router advertises its routes to the connected PE router.
The PE router assigns a VPN label to each route and includes this label when advertising
the route to other PE routers using MP-BGP. When a remote PE router receives these
routes, it updates its VRF tables accordingly and distributes the prefixes to the appropri-
ate CE devices.

L3VPN leverages MPLS to ensure that data packets follow the predetermined paths
across the provider’s network, ensuring quality of service (QoS) and optimizing resource
utilization. MPLS labels are used to steer the packets through the provider network,
enabling features such as traffic engineering and fast rerouting in the event of node or
link failure.
 MPLS in a Nutshell 3

VRF instances also enable the use of overlapping IP address spaces from different cus-
tomers, eliminating the risk of IP address conflicts. This capability is beneficial for net-
work operators hosting multiple customers with their own private IP address spaces.

L2VPN services extend Layer 2 connectivity across an MPLS network, enabling enter-
prises to link dispersed sites as if they were on the same LAN. Each CE device connects
to a PE node, establishing point-to-point or multipoint Layer 2 connections to remote CE
devices.

In traditional L2VPN solutions, PE nodes use pseudowires for point-to-point connections

(Virtual Private Wire Service [VPWS]) and Virtual Private LAN Service (VPLS) for multi-
point-to-multipoint Ethernet services. Pseudowires emulate direct links between CE devices
by encapsulating Layer 2 frames into MPLS packets, which are then forwarded across the
MPLS network. VPLS creates a full mesh network, providing any-to-any Layer 2
connectivity by replicating and forwarding Ethernet frames to the correct destinations.

From a network operator’s perspective, implementing L2VPN involves configuring PE

nodes to handle various customer connections. Each PE node maintains virtual forward-
ing instances (VFIs) for VPLS, which manage the customer-specific forwarding tables.
These VFIs enable the PE nodes to handle Ethernet frames from multiple customers inde-
pendently, ensuring that traffic from different customers remains isolated. The Layer 2
frames are encapsulated into MPLS labels and steered toward an egress PE node, where
decapsulation takes place before the original frames are forwarded to the destination site
or CE node. This book will delve into the next generation of L2VPN services: Ethernet
VPN (EVPN).

mVPN with mLDP, as detailed in RFC 6513, optimizes multicast data distribution in
MPLS networks. Between the PE and CE routers, protocols such as Protocol Independent
Multicast (PIM) and Internet Group Management Protocol (IGMP) are used. Within the
MPLS core, mLDP establishes multicast distribution trees. These trees, constructed as
point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) label-switched paths
(LSPs), enable efficient multicast traffic delivery. mLDP extends LDP to dynamically sig-
nal and create these LSPs, forming a scalable multicast routing framework. This approach
eliminates the need for traditional GRE tunnels. By leveraging MPLS infrastructure, net-
work operators can deliver multicast services within an MPLS VPN. mLDP simplifies the
control plane by utilizing existing LDP mechanisms, seamlessly integrating with current
MPLS deployments, and provides the capability to support large-scale multicast deploy-
ments across MPLS networks.

Apart from the VPN services, other use cases for MPLS are traffic engineering and traf-
fic protection and restoration. Large service providers and enterprise networks need a
scalable and more efficient way to achieve the same result with less effort and lower
operational costs. Traffic engineering in MPLS allows network operators to control the
flow of data through the network by optimizing the path that packets take. MPLS Traffic
Engineering (MPLS TE) enables the creation of LSPs that can be dynamically adjusted
based on current network conditions and policies. MPLS supports fast reroute (FRR)
4 Chapter 1: MPLS in a Nutshell

techniques that can switch traffic to a precalculated backup path in the event of a failure.
This is important for maintaining service continuity, especially in networks that sup-
port critical services. Chapter 9, “High Availability and Fast Convergence,” is dedicated
to a traffic-protection methodology called Topology-Independent Loop-Free Alternate
(TI-LFA) with segment routing. TI-LFA provides link and node protection in any topol-
ogy, which is not the case with other legacy protection mechanisms.

MPLS is a technology that brings many benefits to modern networks, including:

■■ Efficiency: By pooling network resources, MPLS enables efficient utilization of

both bandwidth capacity and network node capabilities. This means that critical and
SLA-based applications can operate at maximum capacity without affecting other
applications.

■■ Reduced cost: MPLS eliminates the necessity to operate dedicated routers and
WAN circuits to suit various customers. It provides a more cost-effective way to
manage and provision network services.

■■ Improved scalability: The P nodes do not use BGP because they are only involved
in label forwarding and do not perform any IP lookups. BGP is used on the PE nodes
to exchange customer routers. Therefore, the core devices remain BGP free.

■■ Agility: In traditional network models, it can be difficult to respond quickly to

demands for new applications and services. MPLS, on the other hand, allows net-
works to grow, change, or be reduced without requiring new hardware or additional
WAN circuits. This makes it easier to adapt to changing business needs and to
onboard new customers in hours rather than days or weeks.

■■ Improved reliability: MPLS provides several mechanisms for fast rerouting of traffic
in the event of link or node failures, which reduces downtime and improves service
availability.

This introductory chapter provides an overview of MPLS technology. For those with
experience in MPLS, it provides a logical path to understanding segment routing technol-
ogy and Segment Routing over IPv6 (SRv6) throughout coming chapters. For those with-
out experience in MPLS technology, it provides a solid foundation to understand MPLS
fundamentals.

How MPLS Operates

Now that you have had a 30,000-foot overview of the MPLS technology, in the following
sections of this chapter, we will examine the details of the MPLS label structure, how a
label is allocated, and which protocol allocates a label. We will distinguish between the
control plane and the data plane, and we will analyze label operations.

Figure 1-1 shows the device roles and their functions within an MPLS network domain.
 How MPLS Operates 5

Service Provider

RR
P
Customer PE
Customer
CE CE
PE
P
P

IP
MPLS Domain
MPLS

Figure 1-1 MPLS Domains

MPLS networks consist of several types of routers, each with a specific function:

■■ Provider (P) router, also known as label switch router (LSR):

■■ All interfaces are MPLS enabled and participate in MPLS label switching.
P routers are part of the transport across the MPLS backbone.

■■ P node runs an IGP protocol such as OSPF or IS-IS (in the case of segment
routing). With legacy MPLS, the LSR is also LDP enabled for label distribution
and signaling.

■■ P node does not run BGP peering internally or externally (so it has a BGP-free
core), except when the P router also acts as BGP route reflector (RR)

■■ Backbone routes are part of the global routing table and do not participate in
any VRF.

■■ An LSR does not contain any customer routes, but MPLS-encapsulated customer
traffic is label forwarded on LSRs.

■■ Provider edge (PE) router, also known as label edge router (LER):

■■ Core-facing interfaces are MPLS enabled, while customer-facing interfaces are

IP or L2 enabled.

■■ PE routers are border routers (ABRs/ASBRs) and contain knowledge of customer

routes as well as MPLS backbone routes.

■■ Customer routes are part of a VRF instance, and each VRF instance creates its
own routing table separately from other VRF instances.

■■ PE routers peer directly with CE routers via BGP, IGPs, or static routing.
■■ BGP full mesh between PEs or PEs with RRs is mandatory to advertise and dis-
tribute customer routes to each other for end-to-end reachability.
6 Chapter 1: MPLS in a Nutshell

■■ BGP route reflector (RR):

■■ BGP RRs simplify the configuration of BGP peering sessions in large MPLS
networks.

■■ RRs act as central points for BGP route reflection in an MPLS network, reducing
the number of BGP peering sessions required between PE routers.

■■ In an MPLS network, BGP RRs are used to distribute IP routes and VPN routes
among the PE routers.

■■ Customer edge (CE) router:

■■ CE routers are located at the customer sites and are responsible for connecting
a customer’s LAN to the MPLS network. A CE typically has multiple Layer 3
interfaces and is connected to the PE router via a Layer 3 interface. A CE router is
responsible for forwarding customer traffic to the PE router, which then encapsu-
lates it to MPLS packets and adds the appropriate labels before forwarding them
to the P router.

Overall, the roles of PE, P, and CE routers are crucial in the functioning of MPLS net-
works. A PE router connects customer sites to the MPLS network, a P router is respon-
sible for transporting labeled packets across the network, and a CE router is responsible
for connecting the customer’s network to the service provider network. By dividing the
responsibilities of these routers in this way, MPLS is able to efficiently transport traffic
across large-scale networks while still maintaining security and privacy for each
customer site.

MPLS enables the effective exchange of VPN routes using Multiprotocol Border
Gateway Protocol (MP-BGP). Within an MPLS network, the core nodes are BGP free,
whereas the PE nodes have BGP deployed, allowing for end-to-end customer routes trans-
port. The provider network PEs can use MP-BGP to communicate and exchange custom-
er routes dynamically, enhancing the scalability of routing and forwarding features of the
underlying network infrastructure. Because MPLS operates on a BGP-free core network,
BGP RRs are essential to support a large number of iBGP peering between PE devices.
An RR reduces the iBGP peerings required for PE full mesh connectivity and IP/VPN/
EVPN/mVPN route propagation over MPLS networks, where PE devices only peer with
the RRs, and no direct peering between PE devices is required.

MPLS Label Structure

In traditional IP packet forwarding, each node independently analyzes the IP header to
determine the next hop—a process known as per-hop routing. This involves an IP lookup
in the routing table at each node along the path from source to destination. MPLS simpli-
fies this by performing an IP lookup only at the LER. Subsequent nodes use label look-
ups, decoupling IP from the underlying transport in the core network.

An MPLS header is a 32-bit value inserted between the Layer 2 and Layer 3 headers of an
IP packet by an ingress LER when the packet enters the MPLS network. The ingress LER
 How MPLS Operates 7

adds a label to the packet to identify a specific LSP for packet forwarding across the net-
work. Each LSR along the path looks up the label to determine the next LSR and swaps
the label with a new one before forwarding the packet. This process continues until the
packet reaches the egress LER. The path from the ingress LER, through the LSRs to the
egress LER is known as the LSP.

To help you understand the MPLS header, Figure 1-2 provides a detailed overview, and
the following list describes the fields in the header:

20 bits 3 bits 1 bit 8 bits

MPLS Label Value EXP bit BoS TTL

Layer 2 Header MPLS Header Layer 3 Header Payload

Figure 1-2 MPLS Header

■■ MPLS Label Value: This field consists of 20 bits. The label value range in this field
starts from 0 and goes up to the maximum of 1,048,575, hence the limitation of
~1 million MPLS labels. The first 16 label values, from 0 to 15, are reserved for oper-
ational reasons and have a special meaning to an MPLS-enabled node, as specified in
RFC 3032 and RFC 7274.

■■ Experimental (EXP) bit: This field consists of 3 bits. Initially, those bits were not
used but were specified for later use as MPLS development advanced. Today, this
field is used for QoS treatment on a packet.

■■ Bottom of Stack (BoS): This field consists of only 1 bit and two possible values:
0 or 1. If the value is 0, there is more than one label in the stack, and a node must
continue processing the next label from the stack of labels. If the value is 1, it means
the label is the last one (bottom) in the stack of labels, and the node must do an IP
lookup or L2 Ethernet lookup afterward, but only if there is no additional label, such
as a service label.

■■ Time to Live (TTL): This field provides the same function as a TTL field in an IP
header: It helps avoid endless packet loops. Since intermediate MPLS nodes do not
perform IP lookups, there is no way to check the TTL of an IP packet, so we need
the TTL field in the MPLS header. For each hop a labeled packet travels, the TTL
value decreases by one. The default TTL value is 255.

Packet forwarding using MPLS labels can be as simple as imposing a single label on top
of an incoming packet or as complex as imposing a set of labels, where these set of labels
are part of a label stack. A label stack (see RFC 3032) is a container that keeps MPLS
8 Chapter 1: MPLS in a Nutshell

labels in last-in, first-out (LIFO) order. In this case, a top label from the label stack, as
shown in Figure 1-3, is processed first, and depending on the necessary MPLS label oper-
ation, the MPLS-enabled node processing the packet either forwards the labeled packet
to an outgoing interface without any modification (top label swapped) or a more complex
operation occurs, resulting in either a PUSH (adding an additional label) or POP (remov-
ing a label) operation.

As shown in Figure 1-3, the top label and any label below has a value of 0 in the BoS field,
but the bottom label always has the value 1 and an instruction with the meaning that this
is the last label in the stack. Once the last label from the stack is processed and popped,
an IP lookup is commonly done as the last step to forward the packet to a next hop.

MPLS Label EXP bit BoS = 0 TTL Top Label

MPLS Label EXP bit BoS = 0 TTL ...

MPLS Label EXP bit BoS = 1 TTL Bottom Label

Figure 1-3 MPLS Label Stack

See the section “MPLS Label Operations,” later in this chapter, for a detailed explanation
of MPLS label operations.

We briefly mentioned the reserved label range (0–15), which has a special meaning for an
MPLS-enabled node. As of this writing, only some of the reserved labels are officially
assigned for any use:

■■ IPv4 explicit null label (0): The advantage of the explicit null label is that MPLS
EXP bits are preserved throughout the MPLS network. When a PE node receives a
labeled packet with an explicit null label, the label stack is stripped off, and IPv4 for-
warding is performed. From a PHP (P) node perspective, it performs the swap opera-
tion, essentially replacing the top label with a null label, and the service label remains
untouched. Figure 1-4 shows an example of the Explicit null label.

Control Plane

Explicit Null
PE P PE

IP IP
S: Label S: Label
Data Plane T: Label NULL Label

Figure 1-4 IPv4 Explicit Null Label (0)

 How MPLS Operates 9

■■ Router alert label (1): The label value 1 is assigned as the top label or anywhere in
the label stack except as the bottom label. The router alert label does not hold any
forwarding path information, and the primary purpose is to have the node examine
the packet thoroughly before forwarding it to the next hop. A practical use case is an
LSP ping, which intermediate nodes must process up to the destination. Once a node
finishes the packet examination, the next label in the stack is checked for forwarding
information. Before the labeled packet is put to the outgoing interface for forwarding
to the next hop, the RA label (1) is added to the label stack as the top label.

■■ IPv6 explicit null label (2): The label value 2 is assigned to the last MPLS label in the
stack, also known as the bottom label. It signals to the node that the label stack must
be removed, and packet forwarding is now based on the IPv6 header. Much as with
label value 0, the label stack is stripped off when the node receives a labeled packet
with explicit null label value 2.

■■ Implicit null label (3): The label value 3 is assigned by an egress PE device to inform
the directly connected P node to perform a POP operation whenever the P node
forwards traffic to the egress PE device. This method is also called penultimate hop
popping (PHP). Egress PE devices benefit from PHP because the incoming packet
is unlabeled; the egress PE device performs only a simple IP lookup to forward the
packet. Implicit null does not mean the incoming packet is always unlabeled (in the
case of MPLS/VPN); it just means that the top label from the label stack is popped
(removed). The advantage of implicit null is the performance of the PE router, which
does not need to do a label lookup but only a single IP lookup. The disadvantage
of implicit null is mainly related to QoS: If the transport label contains MPLS EXP
bits for QoS, then this information is lost. Figure 1-5 shows an example of an MPLS
VPN packet where the transport label is popped, and the service label remains until
it reaches the egress PE router.

Control Plane

Implicit Null
PE P PE

IP IP
S: Label S: Label
Data Plane T: Label

Figure 1-5 Implicit NULL Label (3)

Note The MPLS reserved labels that are registered with IANA are listed at https://
www.iana.org/assignments/mpls-label-values/mpls-label-values.txt.
10 Chapter 1: MPLS in a Nutshell

Control Plane and Data Plane

To operate IP/MPLS networks, it is important to understand the difference between
the control plane and the data plane (also known as the forwarding plane), especially in
troubleshooting situations.

The control plane is crucial in establishing and managing a network, performing tasks
such as topology discovery and assigning label values to be used by the network devices.
The control plane of a network device is responsible for managing routing protocols, cal-
culating optimal paths, maintaining routing tables, handling network topology updates,
assigning MPLS labels, enforcing routing policies, and maintaining neighbor relationships.
As shown in Figure 1-6, IGPs are part of the control plane, and network devices running
the same IGP can distribute their IGP database (topology, nodes, links, and prefixes) to
each other so that there is a common view of the network. Next, the network devices
analyze the IGP database, pick all necessary prefixes from it, and populate the Routing
Information Base (RIB) with destination addresses, the outgoing interfaces, and possibly
the next-hop address. In the case of MPLS based on LDP, every routing entry in the RIB
is assigned a label and stored in a separate database called the Label Information Base
(LIB), which is also part of the control plane.

So you have seen that the network devices learn all necessary prefixes (IGP) and labels
(LDP) and store them in their respective databases (RIB and LIB). Let us briefly look into
the data plane. For a network device to forward IP or labeled packets, the forwarding
information is written to the hardware itself. Any fixed router or line card of a modular
router contains a Forwarding Information Base (FIB) table stored locally, which pro-
vides destination IP prefixes, next hops, and outgoing interfaces. Finally, label-based
forwarding is done by looking up the forwarding information in the Label Forwarding
Information Base (LFIB). The LFIB provides the incoming and outgoing label information
with the respective outgoing interfaces to forward any labeled traffic. LDP feeds the LFIB
with all the necessary label information.

Control Plane

OSPF / IS-IS

Routing Table (RIB)

Label Distribution Protocol

Data Plane

Forwarding Table (FIB)

Incoming Outgoing

IP and Labeled Packets Label Forwarding (LFIB) IP and Labeled Packets

Figure 1-6 Control Plane and Data Plane

 How MPLS Operates 11

Label Distribution Protocol (LDP)

LDP enables PE and P nodes to automatically generate, distribute to peer devices, and
request label-to-prefix binding information from peer devices in a network, thus facilitat-
ing the forwarding of data packets across the network, which is the fundamental aspect
of MPLS networks. Using LDP, a node can discover peers and establish LDP sessions
with them to exchange label binding information. LDP operates on a peer-to-peer basis,
with each node in the network communicating with its neighbors to exchange label infor-
mation. This enables PE and P nodes to distribute their local label bindings and establish
an end-to-end label-switched path (LSP) throughout the MPLS network.

LDP uses two types of label distribution methods:

■■ Downstream-on-demand: This method is used when a node requires a label for a

specific prefix. In this scenario, the requesting node sends a label request message to
its neighbor, and the neighbor responds with a label mapping message.

■■ Unsolicited downstream: This method is used when a node has label information to
share with its neighbors. In this scenario, the node sends a label mapping message to
its neighbors, which they can then use to update their forwarding tables.

MPLS nodes use LDP to distribute labels along normally routed paths to support MPLS
forwarding. The nodes create a label forwarding table from this information, which maps
each incoming data packet to its corresponding label. MPLS forwarding differs from IP
forwarding, where a device examines the destination address in the IP header and per-
forms a route lookup. In MPLS forwarding, the nodes look at the incoming label, consult
the LFIB, and forward the packet to the next hop. In MPLS networks, a group of packets
assigned to a specific LSP are transported by being associated with a label mapping or
binding that contains a label. This label serves as an identifier for the group of packets,
which are collectively referred to as a forwarding equivalence class (FEC).

LDP was standardized by the Internet Engineering Task Force (IETF) in RFC 5036. As
shown in Figure 1-7, neighbor discovery in LDP uses UDP port 646, and session estab-
lishment with the discovered neighbor uses TCP port 646. Nodes initiate the discovery
phase by transmitting, at regular intervals, hello packets on UDP port 646 to the multi-
cast address 224.0.0.2; they listen to this port for potential hello messages from other LDP
nodes. This process allows all directly connected nodes to learn about each other and
establish hello adjacencies. If two LDP speakers agree on the shared parameters,
they establish neighbor adjacency by using TCP. An LDP ID, a unique identifier assigned
to each node in the network, is typically assigned based on the node’s IP address and
included in all label distribution messages that the node exchanges. LDP neighbors initi-
ate the exchange of label bindings using the already established TCP connection once the
LDP adjacency is up and running—assuming that label allocation has already been com-
pleted independently by each node.

LDP can discover peers that are not directly connected if you provide a node with the IP
address of one or more peers. The node sends targeted hello messages to UDP port 646
on each remote peer. If the targeted peer responds with a targeted hello message to the
12 Chapter 1: MPLS in a Nutshell

initiator, an LDP targeted adjacency is created, and session establishment can proceed.
Targeted LDP sessions are used in specific scenarios such as for traffic protection, traffic
engineering, and L2VPN point-to-point circuits, also known as pseudowires.

10.0.10.1/32 10.0.10.2/32
Loopback0

Loopback0
2) TCP connection created between the nodes. LDP
ID used for unicast messages between the LDP
adjacencies.

10.50.50.0/30

P1 P2
1) LDP Hello sent to multicast address 224.0.0.2 with
UDP port 646 as destination.

Figure 1-7 LDP Adjacency

In summary, LDP plays a critical role in legacy MPLS networks, as it automatically

distributes labels to each node in the network, enabling the identification and routing
of data packets. Nodes communicate with their neighbors in a peer-to-peer fashion to
exchange label information through LDP. The label distribution process involves exchang-
ing label mapping information, which is used to create a label forwarding table at each
node. A node receives an incoming packet and looks up the corresponding label in its for-
warding table before forwarding the packet to the next node in the chain.

Label Allocation Mechanism

An MPLS-enabled node must allocate labels to IP prefixes that are present in the rout-
ing table (RIB). When a node receives an incoming packet, it needs to determine how
to forward it based on the information in the packet’s label. The LDP label allocation
process involves assigning a unique label to each prefix on a device level and distributing
that label to all LSRs in the network. This process—such as label 25 assigned to prefix
10.0.10.1/32—is known as label mapping. If an incoming packet is not labeled, the inter-
mediate LSR (P router) might drop the packet in case of MPLS/VPN traffic. The process
of label mapping has local significance, meaning that any MPLS-enabled node allocates
labels to IP prefixes independently of the other MPLS nodes.

The MPLS domain requires end-to-end label switching for any traffic entering until it
reaches the egress PE device. The node generates a label and allocates it to an IP prefix,
and it stores this information locally in the LIB. The LFIB, which is part of the data plane
for MPLS traffic, also stores the same information. The responsibility for generating a
label does not lie with an IGP. Instead, LDP, Resource Reservation Protocol (RSVP), and
BGP are mechanisms that generate and distribute labels to other neighbors internally to
the MPLS domain or external domains.
 How MPLS Operates 13

In summary, the label allocation process involves assigning a label for each prefix in the
network domain and distributing these labels to all network nodes.

Label allocation and distribution with LDP was the standard for many years. Figure 1-8
provides a visual representation of this process.

10.0.10.1/32

Loopback
PE1 P1 P2 PE2
use label 19 for use label 22 for use label 3 for
prefix 10.0.10.1/32 prefix 10.0.10.1/32 prefix 10.0.10.1/32

Label 0 is Explicit NULL

Label 3 is Implicit NULL

Figure 1-8 Label Allocation

This is the label allocation process that is occurring in Figure 1-8:

Step 1. PE2 has a loopback interface configured with IP address 10.0.10.1/32. PE2
assigns a local label 3 (implicit null) to IP prefix 10.0.10.1/32. This is called a
label mapping, and it is stored in the LIB (control plane). The same informa-
tion is also stored in the LFIB (data plane).

Step 2. PE2 uses LDP to propagate the label mapping (10.0.10.1 to 3) to all directly
connected peers—in this case, to P2.

Step 3. P2 receives the label mapping from step 2 and stores it in the LIB and LFIB.
From P2’s point of view, label 3 will be used as the outgoing label for 10.0.10.1

Step 4. P2 assigns its own label for 10.0.10.1—in this case, label 22—to advertise it
further to P1.

Step 5. P1 receives label 22 for prefix 10.0.10.1, stores it in the LIB and LFIB as an
outgoing label, and assigns an incoming label for prefix 10.0.10.1—in this case,
label 19—and propagates it to PE1.

Step 6. PE1 receives label 19 from P1 and stores it as an outgoing label in the LIB and
LFIB.

To summarize, label allocation is performed when every node in the MPLS domain
assigns a label to each prefix in the routing table independently of other nodes, making it
locally significant. The node then dynamically propagates label mapping to other directly
connected peers using LDP.
14 Chapter 1: MPLS in a Nutshell

MPLS Label Operations

To process MPLS-encapsulated packets arriving on an ingress interface, a node needs to
follow one of three predefined label operations (see Figure 1-9):

Label PUSH Label POP

Label SWAP

IP IP

IP Label: 25 IP IP Label: 25 IP

Label: 25 Label: 48 Label: 25 Label: 36 Label: 28 Label: 25

Figure 1-9 MPLS Label Operations

■■ PUSH: For any incoming packet, a label is added on top of the packet. If the incom-
ing packet already has a label, an additional label is added on top of that label, thus
creating a label stack. Usually, a PE node performs the PUSH operation. However,
there are instances in which a P node also performs a PUSH operation during a fail-
ure event, when the fast reroute mechanism is activated.

■■ SWAP: For any incoming labeled packet, the node inspects the incoming label and
swaps it with the outgoing label. SWAP operations are usually performed by
P nodes.

■■ POP: For any incoming labeled packet, the node inspects the incoming label, pops
(removes) the top label from the label stack, and forwards the packet. In cases where
the top label is the last label, the node removes the label stack and forwards the pack-
et based on a standard IP lookup—except when the label allocation mode on a PE
node is set to per-prefix or per-CE, in which case no IP lookup is needed. The POP
operation is usually performed by both PE and P nodes.

Apart from the label operations mentioned previously, in certain circumstance, an MPLS-
enabled node can also push two or more labels on top of the label stack. This is espe-
cially important when using MPLS applications such as MPLS/VPN, traffic engineering,
and FRR. In the case of MPLS/VPN, a node imposes one BGP label for the VPN prefix,
also called a service label, and another label (LDP) for the transport prefix, also called
transport label. In case of traffic engineering, where a strict end-to-end path is desired,
the ingress PE node must push all the necessary labels in the label stack. In the case of
FRR, if a node or a link in the path fails, the node must react immediately by rerouting
the traffic through a backup path, and this is achieved by manipulating the original label
stack of the labeled packet, essentially removing and adding more than one label on top
of the packet.
 How MPLS Operates 15

Traffic Forwarding Using Labels

Traditional Layer 3 forwarding mechanisms require every router along the packet’s path
to extract all the necessary information from the Layer 3 header in order to forward the
packet. The longest prefix match in the routing table is then performed based on the
extracted data to determine the packet’s next hop.

Usually, only the destination address field in the header is important. However, in some
instances, other header fields are crucial. Therefore, each router must independently ana-
lyze the header as the packet passes through.

In MPLS label forwarding, the incoming packet’s Layer 3 header analysis is performed
once, at the ingress PE node. The Layer 3 header is transformed into an unstructured,
fixed-length value called a label. Multiple headers can be mapped to the same label if
they lead to the same selection of the next hop. Essentially, a label is assigned to each
forwarding equivalence class (FEC) that includes a group of packets that are indistinguish-
able by the forwarding function.

The initial label choice does not need to be based entirely on the contents of the
Layer 3 packet header. For instance, routing policies can influence forwarding decisions
at subsequent hops. After a label is assigned, a short label header is added to the front of
the Layer 3 packet, which is carried along with the packet across the network. At subse-
quent hops through each MPLS router in the network, labels are swapped, and forward-
ing decisions are made using the MPLS forwarding table lookup for the label carried in
the packet header.

There is no need to reevaluate the packet header as it moves across the network. Because
the label is of a fixed length and unstructured, the MPLS forwarding table lookup pro-
cess is simple and fast.

Figure 1-10 illustrates label-based forwarding.

In Out Next-hop In Out Next-hop

19 22 P2 150 - CE1

In Out Next-hop In Out Next-hop

- 19 P1 22 POP PE2

VPN prefix:
10.0.10.0 /24

PE1 P1 P2 PE2

IP 10.0.10.21 10.0.10.21 10.0.10.21 10.0.10.21 10.0.10.21

Service 150 150 150
Transport 19 22

Figure 1-10 Label-Based Forwarding

16 Chapter 1: MPLS in a Nutshell

A PE router normally has at least one CE node directly connected. The CE router adver-
tises its own IP prefixes to the PE router dynamically, using a protocol such as BGP
or OSPF. Open Shortest Path First (OSPF) is a popular IGP used in large enterprise
networks. In contrast, BGP is more prevalent in large service provider networks. When
L3VPN is employed to serve customers, any protocol can be used as a VRF-aware
instance between the PE and CE nodes.

PE1 receives an IP packet from a VPN customer and performs an IP lookup based on
the destination IP address in the IP header of the incoming packet. Because this is a
VPN-based service, PE1 creates a label stack and imposes two labels on the label stack:
The bottom one is a BGP label 150, also called a service label, and the top label is the
transport label created by LDP. No label operation is performed on the bottom label
until it reaches the egress PE node—in this case PE2. The forwarding mechanism in the
MPLS transport is performed using the top label. After the label stack is imposed on the
IP packet, via a PUSH operation, PE1 forwards the data traffic to the next hop, which
is P1. At the ingress port of P1, the data traffic arrives with the top label 19. P1 checks
its own LFIB and recognizes the need to perform the SWAP operation, so it replaces
the label 19 with label 22 and forwards the labeled packet to P2 as the next hop via the
outgoing interface. P2 performs the POP operation to the incoming label 22 due to the
implicit null and forwards it via the outgoing interface to the next hop, PE2. PE2 checks
the incoming service label 150 and recognizes that this label has to be removed, so a POP
operation is performed, and the IP packet is routed normally to the CE node via a non-
labeled outgoing interface.

MPLS VPN Services Overview

To define a Multiprotocol Label Switching virtual private network (MPLS VPN), it is nec-
essary first to understand the general concept of a VPN. A VPN is a network that utilizes
other public or private networks to provide private network services while operating on
an IP-based infrastructure. It comprises a group of sites that can privately communicate
with one another. VPN sites use a common routing table and operate as a network where
customers can connect to multiple sites using a shared MPLS provider core infrastruc-
ture. A site might have one or more CE nodes attached to one or more PE nodes.

MPLS VPNs operate at Layer 3 and adopt a peer model, allowing the service provider
and customer to exchange routing information at this layer. This peer model facilitates
data transmission between customer sites through the service provider’s network without
customer intervention. Consequently, when a new site integrates into the MPLS VPN, the
PE to which the new site is connected is the only one that needs an update with the new
configuration for that particular VPN customer.

For completeness, Figure 1-11 shows the end-to-end MPLS VPN architecture from a
high-level point of view.
 How MPLS Operates 17

Customer-A
IP GP
CE
Ro MP-iB MP
Customer-A
uti
ng -iB ng CE
RR GP uti
Ro
IP

g PE
utin
Ro P
IP
PE IP R
P outin
Customer-B P g
CE Customer-B
CE

MPLS Backbone

Figure 1-11 MPLS VPN Architecture

VRF is a technique used in MPLS VPNs to separate the routing tables of different cus-
tomers at the same PE device. VRF maintains a separate routing table for each VPN cus-
tomer, allowing for secure and efficient routing between sites.

An MPLS VPN consists of the following components:

■■ VRF instances: Each VRF instance represents a different VPN network. A VRF
instance contains its own routing table, which is separate from the global routing
table (GRT) of the PE router. This separation allows for secure routing between dif-
ferent VPNs.

■■ MP-BGP: This protocol is used for the distribution of VPN routes between the PE
routers. Each PE router maintains a BGP session with other PE routers or a route
reflector in the network. When a new VPN route is learned, it is advertised to other
PE routers using BGP. BGP also allows for the exchange of VPN-related information,
such as the route distinguisher (RD).

■■ VPNv4/VPNv6 Address Family: The VPNv4/VPNv6 address family is used for the
distribution of VPN routes between the PE routers. Each VPN route contains an
RD and a VPNv4/VPNv6 prefix. The VPNv4/VPNv6 prefix is a combination of the
customer’s IP prefix and the RD. The PE routers use the RD to distinguish between
routes belonging to different VPNs. This essentially allows the same customer pri-
vate IP addresses to exist in different VRF instances. In this case, IP address overlap
does not cause an issue due to the different RD values appended.

■■ Route distinguisher (RD): The RD is a 64-bit value that is used to uniquely identify
the VPN or customer prefix. An RD is appended to each IP Prefix which results in a
96-bit VPN route and allows the PE router to distinguish between routes that belong
to different VPNs.

■■ Route target (RT): The RT is a 64-bit BGP extended community that is used to con-
trol the distribution of VPN routes within the MPLS VPN. The RT is assigned to
18 Chapter 1: MPLS in a Nutshell

each VPN route by the PE router at the ingress point of the VPN. The RT is used by
the other PE routers to determine which VRF table to insert the VPN route into.

In summary, VRF is a key component of MPLS VPNs that enables separate and indepen-
dent routing between different VPNs. The use of RDs and VPN-IPv4 addresses allows
for the unique identification of VPN routes, and BGP is used to distribute VPN routes
between PE routers. The RT is used to control the distribution of VPN routes within the
MPLS VPN, ensuring that each VPN route is inserted into the correct VRF table.

MPLS Traffic Protection

MPLS FRR provides resiliency in the event of link or node failure by creating backup
paths for each primary path, as shown in Figure 1-12. A primary path is the normal path
that packets take across the network, and a detour backup path is available in case of fail-
ure on the primary path.

Primary Path Primary Path

Node Protection
Link Protection

ath
up P
PE PE PE Back PE

Backup Path

Figure 1-12 MPLS Node and Link Protection

Each prefix in the network has a backup path calculated by every router in the network.
Let’s briefly look at how routers calculate their backup paths:

Step 1. To calculate a backup path, a router must determine the next-best available
path to reach the destination prefix in the case of a primary path failure. This
is done using the loop-free alternate (LFA) traffic protection technique. LFA
finds a backup path that does not result in a forwarding loop and that is guar-
anteed to be loop free. However, it does not protect all possible topologies.

Step 2. After calculating the backup path, the router generates a new label stack that
represents the backup path and installs it into the router’s forwarding table.
The label stack has one or more labels, with the first label pointing to the next
hop router on the backup path.

Step 3. When a failure occurs on the primary path, the router swaps the primary
path’s label stack with the backup path’s label stack. This action causes the
packets to be forwarded along the backup path instead of the primary path.
The label stack of the backup path includes the necessary node labels (PQ
nodes) along the path to the destination prefix. When the packet reaches the
 Challenges and Shortcomings of MPLS 19

next hop router on the backup path, the router pops the top label and for-
wards the packet to the following next hop router based on the label stack
information.

Step 4. The router switches back to the primary path by swapping the label stack of
the backup path with the primary path’s label stack after the primary path is
restored. This process enables the packets to be forwarded along the primary
path again.

In the realm of networking, FRR presents a temporary solution to minimize packet loss.
The computation of backup path, however, may not guarantee sufficient bandwidth, lead-
ing to potential congestion on the alternate routes. It is crucial to note that the ingress
router possesses complete knowledge of LSP policy constraints, making it the only
entity capable of generating appropriate long-term alternate paths.

Apart from MPLS LFA (IGP and LDP), backup paths can also be created through RSVP
sessions and, as with all RSVP sessions, require additional state and network overhead.
Consequently, a node creates at most one backup path for every LSP that has FRR capa-
bility. Formulating multiple backup paths for each LSP leads to unnecessary overhead,
without considerable additional benefits. Also, an important aspect of FRR technology is
that it is considered a temporary solution to an intermittent network problem. A network
operator should not rely permanently on a backup path. When a link or node fails, traf-
fic from the primary path takes a detour toward a backup path, and it might happen that
now the backup path is congested due to heavy traffic. This is the main reason traffic
should always be routed back to the primary path after the primary path has recovered
and links/nodes are stable enough to carry the original traffic.

Challenges and Shortcomings of MPLS

Although modern networks have widely adopted MPLS, which provides benefits such as
traffic engineering, and virtual private networks (VPNs), it is important to be aware of
some challenges and shortcomings. The following challenges are the most important:

■■ MPLS label space limitation

■■ LSP and summarization

■■ Inter-AS limitations

■■ RSVP-based traffic engineering

■■ LDP–IGP synchronization

■■ Load balancing and hashing

To give you a comprehensive understanding of these challenges, the following sections

provide details.
20 Chapter 1: MPLS in a Nutshell

MPLS Label Space Limitation

To understand the MPLS label space limitation, it is essential to understand how MPLS
works.

Each packet entering the network is assigned a 20-bit number called an MPLS label, and
this assignment process creates LSPs through the network. The ingress router assigns the
labels that the network uses to forward the packets through the network. Once a packet
reaches a core (P) router, the core router uses the label to determine the next hop for the
packet. The core router then swaps the incoming label with the outgoing label and for-
wards the packet to the next hop.

The MPLS label space limitation is a challenge that arises because there is a finite num-
ber of labels that can be used in an MPLS network. The label space is limited to 2^20
(1,048,576) labels, which may seem like a large number, but it can be easily exhausted in
large networks—and this can cause several problems. One of the most significant prob-
lems is that it limits the scalability of the network when there may be requirements for
additional nodes, links, or VPN prefixes. In large networks, the number of labels required
can quickly exceed the available label space. When this happens, no new transport or
service label can be generated, the network may become unstable, and packets may be
dropped, leading to poor network performance.

Another problem caused by the label space limitation is that it can limit the number
of VPN routes (L2VPN/L3VPN services) that can be supported in the network. VPNs
can be created in MPLS networks in two ways: by assigning different labels to different
VPNs (per-VRF label allocation mode) or by assigning different labels per prefix per VPN
(per-prefix label allocation mode). When the label space is exhausted, it may not be pos-
sible to create new VPNs or assign labels to new customer prefixes, limiting the network’s
ability to support new customers or expand its services.

When the ASBR label allocation is on a per-prefix basis, even when the remote PE device
is advertising a label per VRF instance (per-VRF label allocation), the egress ASBR allo-
cates a label for each received prefix, resulting in faster label space depletion in the ASBR.

Similarly, at this writing, the global Internet routing table covers roughly 970,000 IPv4
and 200,000 IPv6 prefixes. Offering IPv4 Internet service as part of a VPN would be
problematic using per-prefix label allocation since it would exhaust more than 90% of the
available label space on the egress PEs providing this service.

Considering the limitations of MPLS label space, there is no real solution to this issue.
However, a couple optimizations can be considered in managing label allocation in large-
scale networks:

■■ Allocating labels on a per-VRF basis instead of per prefix can significantly decrease
the number of required service labels.

■■ With label allocation for host only (/32) routes, LDP assigns labels only for loopback
interfaces instead of for physical links.
 Challenges and Shortcomings of MPLS 21

■■ Assessing alternative inter-AS or intra-AS connectivity models can help you reduce
label allocation.

LSP and Summarization

In an MPLS network, a network operator creates an LSP to define the path a packet
should follow through the network. An LSP is a preconfigured path that connects a
source node to a destination node, and each device along the path forwards the packet to
the next device. The parameters used for creating LSPs include source and destination IP
addresses.

MPLS LSPs face a challenge when summarized routes are advertised instead of more
specific routes, such as /32 host routes. Sometimes network operators may want to adver-
tise summarized routes to the rest of the network, and although this scenario may make
sense in some instances from a network design perspective, it is not recommended in an
MPLS environment. PE and P routers must know each other’s /32 loopback addresses
and potentially their physical interfaces to have a complete view of the underlay network.
This allows each service node (PE node) to create an LSP with remote service node PEs
and ensures appropriate end-to-end label forwarding.

Inter-AS Limitations
Inter-AS routing refers to the exchange of routing information and traffic between
different ASs that are managed by same or different organizations or service providers.
In an MPLS network, communication between ASs is facilitated by BGP. BGP as a stan-
dard protocol is used to exchange routing information between different ASs, while
MPLS VPNs provide a way to extend a private network across multiple ASs using
end-to-end LSPs.

However, MPLS IPv4 and IPv6 networks face several limitations when it comes to inter-
domain routing, which can impact the performance and scalability of the network. The
following sections examine some of these challenges and shortcomings.

Lack of End-to-end QoS Control

One of the main limitations of MPLS networks in inter-AS routing is the lack of
end-to-end QoS control. MPLS networks provide QoS capabilities through DiffServ
(Differentiated Services), which can be used to prioritize traffic and allocate network
resources based on various criteria, such as traffic type, application, and user. However,
these QoS mechanisms are limited to the boundaries of the MPLS network and do not
extend to other ASs.

In inter-AS scenarios, traffic may traverse multiple ASs, each with its own QoS policies
and capabilities. This can result in inconsistent QoS behavior across the network and
affect the performance of delay-sensitive applications such as voice and video. To address
22 Chapter 1: MPLS in a Nutshell

this limitation, network operators must coordinate with other ASs to ensure that QoS
policies are aligned and consistent across the entire traffic path.

Configuration and Operational Complexity of MPLS/VPN and BGP

A challenge in inter-AS routing using MPLS networks is the complexity of configuring
BGP/MPLS VPNs. BGP/MPLS VPNs provide a way to extend a private network across
multiple ASs using MPLS tunnels. However, configuring MPLS VPNs can be a complex
and time-consuming process, particularly in large-scale networks with multiple ASs.

BGP/MPLS VPNs require careful planning and configuration to ensure that the routing
information is exchanged correctly between ASs and that the MPLS tunnels are estab-
lished and maintained properly. Moreover, changes in the network topology or routing
policies may impact the BGP/MPLS VPN configuration, requiring network operators to
constantly monitor and adjust the configuration. During network migrations or mergers,
there is usually a high likelihood that this issue will rise, and a proper transport and ser-
vices layer planning and design are mandatory.

Technical implementation differences might occur, which may result in different out-
come. To address operational complexity, network operators can use automated network
management and orchestration tools that can simplify network design, deployment, and
management. Service providers can use tools such as network controllers, intent-based
networking systems, and software-defined networking (SDN) platforms to automate net-
work operations and reduce the risk of errors.

RSVP-Based Traffic Engineering

Resource Reservation Protocol Traffic Engineering (RSVP-TE) is a protocol used in
MPLS networks for traffic engineering. Its primary function is to establish LSPs through
the network, which are used to forward traffic from one point to another. RSVP-TE is an
extension of RSVP.

One of the key features of RSVP-TE is its ability to signal traffic engineering tunnels.
Traffic engineering tunnels are used to optimize network performance and avoid congest-
ed links. RSVP-TE uses tunnel signaling to create these traffic engineering tunnels.

When a traffic engineering tunnel is requested, RSVP-TE initiates a signaling process that
involves the exchange of messages between the nodes in the network along the path of
the tunnel. The nodes along the path reserve the necessary resources for the tunnel, and
the tunnel is established. Once the tunnel is established, traffic is directed along the path
of the tunnel.

RSVP-TE uses several different messages for signaling LSPs and traffic engineering tun-
nels. These messages include the Path message, which is used to advertise the path of
the LSP or tunnel, and the Reservation message, which is used to reserve the necessary
resources for the LSP or tunnel. RSVP-TE also uses other messages for error handling and
other functions.
 Challenges and Shortcomings of MPLS 23

In addition to its signaling functions, RSVP-TE also provides support for traffic engineer-
ing metrics such as link utilization. This allows network operators to monitor and opti-
mize network performance based on various traffic engineering criteria.

When a traffic engineering tunnel is established using RSVP-TE, it involves the signaling
of an LSP through the underlay network. This LSP is used as the traffic engineering
tunnel, and traffic is forwarded along this LSP according to the traffic engineering
requirements.

The signaling of an RSVP-TE tunnel consists of:

■■ RSVP-TE Path message: The first step in tunnel signaling is the sending of an RSVP-
TE Path message from the headend node of the tunnel to the tailend node. The Path
message carries information about the source and destination of the tunnel, along
with any traffic engineering requirements, such as bandwidth, latency.

■■ Path message processing: When the Path message reaches a node in the network,
it is processed and forwarded to the next node along the path of the tunnel. During
this processing, the node checks if it has enough resources to accommodate the
tunnel, and if it does, it reserves the necessary resources for the tunnel. If there are
insufficient resources, the node may send an RSVP-TE ResvErr message back to the
headend node, indicating that the tunnel cannot be established.

■■ RSVP-TE Resv message: Once the necessary resources have been reserved, the
tailend node sends an RSVP-TE Resv message back to the headend node, indicating
that the tunnel has been established. The Resv message includes information about
the path of the tunnel, along with any labels that have been assigned to the LSP.

■■ Resv message processing: When the Resv message reaches a node in the network,
it is processed and forwarded to the previous node along the path of the tunnel.
During this processing, the node installs any labels that have been assigned to the
LSP and establishes an FEC for the LSP.

■■ Tunnel forwarding: Once the LSP has been established and labeled, traffic can be
forwarded along the path of the tunnel using label swapping and forwarding. Each
node along the path of the tunnel forwards traffic based on the labels assigned to
the LSP, ensuring that traffic is directed along the path of the tunnel according to the
traffic engineering requirements.

Throughout this process, each node in the network is responsible for signaling the next
node in the path of the tunnel. This hop-by-hop signaling ensures that each node has the
necessary resources reserved for the tunnel and that labels are correctly assigned to the
LSP at each hop.

While RSVP-TE has been used in the past for traffic engineering, it has several limitations
and drawbacks, which have led to its reduced popularity in modern networks. These are
some of the limitations of RSVP-TE:
24 Chapter 1: MPLS in a Nutshell

■■ Scalability: RSVP-TE requires maintenance of LSP state information along the path,
which can lead to scalability issues in large networks with a large number of LSPs.

■■ Complexity: The RSVP-TE protocol is complex, which makes it difficult to deploy

and maintain in large networks.

■■ Resource consumption: The RSVP-TE protocol can consume significant network

resources due to the need to maintain LSP state information and the requirement for
end-to-end signaling.

Due to these limitations, RSVP-TE is not always the best choice for implementing traffic
engineering in modern networks.

LDP–IGP Synchronization
MPLS LDP–IGP synchronization is a critical mechanism for ensuring reliable packet for-
warding in an MPLS network. Before any MPLS traffic is forwarded, IGP and LDP must
be in sync to avoid packet loss. Packet loss can occur if a node begins forwarding traffic
using a new IGP adjacency before the LDP label exchange completes between the peers
on that link. Similarly, if an LDP session closes, the device may continue to forward traf-
fic using the link associated with the LDP peer, which can lead to packet loss.

To prevent these issues, MPLS LDP–IGP synchronization ensures that the LDP is fully
established before the IGP path is used for traffic forwarding. This is accomplished by
enabling LDP–IGP synchronization on each interface associated with an IGP OSPF or
IS-IS process. Network operators can then prevent traffic blackholing and ensure reliable
packet forwarding across their MPLS network.

When LDP–IGP synchronization is enabled on an interface, LDP checks whether any peer
connected to the interface is reachable by looking up the peer’s transport address in the
routing table. If there’s a routing entry (including longest match or default routing entry)
for the peer, LDP assumes that LDP–IGP synchronization is required for the interface and
notifies the IGP to wait for LDP convergence. However, LDP–IGP synchronization with
peers requires that the routing table be accurate for the peer’s transport address. If the
routing table shows a summary route, a default route, or a statically configured route for
the peer, it may not be the correct route for the peer. Thus, it’s essential to verify that the
route in the routing table can reach the peer’s transport address to prevent traffic black-
holing due to a missing label for that prefix.

Inaccurate routes in the routing table can cause issues with LDP session establishment,
which causes the IGP to wait for LDP convergence unnecessarily for the sync hold-down
time. This can lead to delays in forwarding traffic and potential packet loss.

A permanent solution to LDP–IGP synchronization issue is segment routing (SR) tech-

nology. With SR, when an IGP protocol advertises its own link-state database to other
adjacent nodes, it also advertises SR-based labels (SIDs) at the same time. Thus, you end
up with no delay in label distribution or in traffic forwarding due to IGP or LDP process
initialization.
 Challenges and Shortcomings of MPLS 25

Load Balancing and Hashing

Many service providers see flat or even slightly decreasing revenues. Reducing costs
while efficiently operating network devices and transmission links is crucial. Network
capacity and redundancy are pillars of core transport networks which often rely on the
following fundamental building blocks:

■■ Equal-cost multipath (ECMP)

■■ Link aggregation groups (LAGs) or link bundles

ECMP is a routing strategy in which a route is reachable via multiple best paths. As the
name implies, those routes have to be equal to qualify, which in the scope of IGP means
that the cumulative cost or metric along the path is the same. ECMP is common in highly
symmetrical networks such as backbones where this kind of behavior is usually desired.

Aggregating several links into a single virtual interface (LAG or bundle) is another com-
mon strategy in backbone networks to facilitate smooth bandwidth extension. The vir-
tual interface is treated as a large pipe, where each physical bundle member is considered
equal, assuming that the transmission speed is the same. Some service providers refrain
from using bundles because the members are not equal with respect to the distance in
the underlying optical transport network. In order to be able to distinguish the interfaces,
it may be preferrable to have several ECMP links instead of a single large pipe.

ECMP and LAG are often used in parallel to simplify capacity planning, flatten traffic
bursts, and improve network availability in the event of node or link failures. ECMP load
balancing and LAG hashing work identically on most routing platforms. The idea is that
packets are evenly distributed across multiple paths or links. This is done by calculating
an n-tuple hash, where several of the following fields are usually taken into account:

■■ Router ID

■■ Source and Destination MAC Address (L2)

■■ Source and Destination IP Address (L3)

■■ Source and Destination Port (L4)

■■ MPLS Label (or Flow Label, in the case of IPv6)

The exact fields and number of fields used for hashing depend on the traffic type and the
underlying hardware architecture. It is important that packets belonging to the same flow
are hashed along the same path. If they’re not, per-packet load balancing may be required,
which can lead to issues such as buffering and retransmissions on endpoints due to out-
of-order packets or jitter or latency caused by different distances between available paths
in the optical transport network.
Figure 1-13 shows some sample packets of different L2VPN and L3VPN services with
two transport labels and a service label. It should become evident that extracting the
proper Layer 2, Layer 3, or Layer 4 fields for MPLS services is nontrivial. On top of this,
the presence of MPLS labels may lead to poor hashing diversity or even incorrect hashing
parameters.
26 Chapter 1: MPLS in a Nutshell

MPLS Services (L3VPN)

Transport Transport Layer 3 Layer 4

L3VPN over Layer 2 Service
Label Label Header Header
BGP-LU over LDP Header Label
LDP BGP-LU Customer Customer

Transport Transport Layer 3 Layer 3 Layer 4

GRE over L3VPN over Layer 2 Service GRE
Label Label Header Header Header
BGP-LU over LDP Header Label Header
LDP BGP-LU GRE Customer Customer

MPLS Services (L2VPN)

Transport Transport Flow Label PW Control Layer 2 Layer 3

L2VPN over BGP-LU Layer 2 PW
Label Label (FAT) Word Header Header
over LDP (CW+FAT) Header Label
LDP BGP-LU (optional) (optional) Customer Customer

Transport Transport Entropy PW Control Layer 2 Layer 3

L2VPN over BGP-LU Layer 2 Entropy Label PW
Label Label Indicator Word Header Header
over LDP (CW+EL) Header (optional) Label
LDP BGP-LU (optional) (optional) Customer Customer

Figure 1-13 Label Stack Example of MPLS Services

There following RFCs describe improvements to the hashing of L2VPN/L3VPN MPLS

services:

■■ RFC 6790: The Use of Entropy Labels in MPLS Forwarding

■■ RFC 4385: Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over
an MPLS PSN

■■ RFC 6391: Flow-Aware Transport of Pseudowires over an MPLS Packet Switched

Network

By default and depending on the platform capability, standard L3VPN provides good
hashing results, except with services where the vast majority of fields are the same and
the customer-specific information is hidden too deeply in the packet. GRE over L3VPN
over BGP-LU over LDP is such a problematic service, where an overlay using GRE is
spanned between two CE nodes over an L3VPN. With a multitude of customer services
being transported through a single GRE tunnel, it would require a deeper packet inspec-
tion to be able to extract all customer-specific information. Lacking this inspection
would result in poor hashing as there would be a single hash for all customers.

RFC 6790 defines the concept of an Entropy label, which is applicable to both L2VPN
and L3VPN services and eliminates the need for deep inspection on transit routers.
Instead, the ingress PE device extracts the relevant field of the service before the MPLS
encapsulation takes place; then the device computes the hash and pushes the result as
an additional label onto the stack. Transit routers no longer need to guess the underlying
packet structure and can instead effectively load balance traffic by relying on the packet’s
MPLS label stack. For this to work, all devices in the path must support the Entropy
label.
 Challenges and Shortcomings of MPLS 27

The inspection of L2VPN services is more challenging than the inspection of L3VPN ser-
vices. As presented in the beginning of this chapter, the MPLS header does not specify
the payload that follows after popping the Bottom of Stack (BoS) label. Instead, the
router has to make an educated guess. In order not to sacrifice too much performance or
too many network processor cycles, it is common to inspect the first nibble that follows
the BoS label.

Example 1-1 shows an extract of an IPv4 L3VPN packet capture.

Example 1-1 MPLS Packet Capture Extract (IPv4)

Ethernet II, Src: RealtekU_12:7a:d0 (52:54:00:12:7a:d0), Dst: RealtekU_10:63:17

(52:54:00:10:63:17)
MultiProtocol Label Switching Header, Label: 24012, Exp: 0, S: 0, TTL: 254
MultiProtocol Label Switching Header, Label: 24139, Exp: 0, S: 1, TTL: 254
Internet Protocol Version 4, Src: 10.0.0.1, Dst: 10.0.0.2
0100 .... = Version: 4
<example shortened for brevity>

Note that the first nibble after the BoS label is 0100, which refers to an IPv4 header,
whereas a nibble of 0110 would point to an IPv6 header. Other values would be treated as
Layer 2 payload. This pragmatic approach falls apart as soon as MAC addresses start with
0x4 or 0x6, which causes the packet to be misinterpreted as an IP packet. The resulting
load balancing would be nondeterministic and would most likely negatively impact the
end-user experience of the service.

RFC 4385 defines the Ethernet control word, which solves the misinterpretation issue by
inserting a 4-byte control word where the first nibble is 0000. In essence, ensures that
transit routers do not falsely interpret the L2VPN pseudowire payload as IPv4 or IPv6
traffic and possibly extract source and destination IP addresses. For this to work, the
ingress and egress PE devices have to agree on the usage of the control word.

The third improvement relates to multiple flows going over a single pseudowire. In this
case, there may be one or more transport labels and a pseudowire label present (refer to
Figure 1-13). Transit routers may not be able to inspect the Layer 2 information to distin-
guish the different flows. Instead, the P nodes compute the same hash for all flows, pre-
venting proper load balancing. This problem description may sound familiar to the GRE
use case introduced earlier. It can be solved by using the Entropy label as well.

There is yet another L2VPN-exclusive solution to this problem. RFC 6391 introduces an
additional label in the MPLS label stack called the Flow label. The Flow label is imposed
by the ingress PE node based on the relevant fields of the flow, which for an L2VPN
could be source/destination addresses of Layer 2 and Layer 3 (if present). It is important
to note that all packets belonging to the same flow must be transported using the same
Flow label to guarantee that the same path is taken across the network for all packets
belonging to the same flow. For this to work, ingress and egress PE devices have to agree
on the usage of the Flow label.
28 Chapter 1: MPLS in a Nutshell

Note The Entropy label is applicable to both L2VPN and L3VPN services and must be
supported on all nodes in the path, whereas the Flow label is limited to L2VPN services
but requires support on the PE nodes only.

Beyond MPLS
Many of the protocols and technologies that power the Internet today have their origin
in the research and development conducted at the Defense Advanced Research Projects
Agency (DARPA). The ARPANET, an early predecessor of the Internet, became opera-
tional in 1969, and the Internet Protocol suite (TCP/IP) was initially specified in 1973.
Unsurprisingly, the native Internet Protocol (IP) lacks many of the requirements of mod-
ern networks, which evolved gradually over time and grew at an unprecedented pace.
Consequently, existing protocols had to be augmented, and completely new protocols
became necessary to fill gaps. The following use cases are examples:

■■ Exhaustion of IPv4 addressing space:

■■ Workaround: Private IPv4 addresses (RFC 1918), Network Address Translation

(NAT)

■■ Solution: Internet Protocol version 6 (IPv6)

■■ Lack of virtual private network (VPN):

■■ Solutions: MPLS VPN, DMVPN (GRE/IPsec), VXLAN

■■ Enhanced load balancing in the VPN context:

■■ Solutions: Flow-Aware Transport (FAT) label (RFC 6391), Entropy label (RFC
6790), VXLAN UDP

■■ Lack of traffic engineering (TE):

■■ Solutions: RSVP-TE, SR-TE

■■ Lack of service chaining:

■■ Solution: Network service header (NSH) (RFC 8300)

MPLS is a mature technology and still heavily used in service provider and carrier-grade
enterprise networks more than 20 years after its initial deployment. It overcomes several
of the shortcomings of native IP routing, especially related to VPN services, but has its
fair share of suboptimal traits, as discussed in the previous section. MPLS support in
certain network areas, such as the access or data center network, has traditionally been
rather limited. As of today, there is no de facto standard for a unified underlay data plane
that connects endpoints in the access network, core, and data center.

In recent years, an increasing number of software-defined networking (SDN) solutions

have come to market, marking a paradigm shift compared to how traditional networks are
built, managed, and operated. SDN is a bit of a buzzword and means different things to
different people. It is generally agreed that SDN is an approach to a network architecture
 Beyond MPLS 29

that delivers a centralized and programmable network that is more flexible and easier to
manage. The brain of the SDN architecture is a controller that enables centralized man-
agement and control, automation, and policy enforcement across both physical and vir-
tual network elements. SDN solutions are often limited to a single network domain. For
instance, Cisco’s SDN portfolio includes the following solutions:

■■ Data center: Application Centric Infrastructure (ACI)

■■ Wide-area network: Software-Defined WAN (SD-WAN)

■■ Campus: Software-Defined Access (SD-Access)

■■ Core: Crosswork Network Controller (CNC)

Some third-party SDN solutions, especially in the field of SD-WAN, make bold claims
around the demise of MPLS and position themselves as superior successors. This kind
of marketing talk should be taken with a grain of salt. Comparing SD-WAN and MPLS is
like comparing apples to oranges. One is an SDN solution that usually spans an overlay
network over one or more transport networks, and the other is a packet-forwarding
technique in the underlay transport network. In fact, many SD-WAN deployments rely on
a mix of MPLS and low-cost broadband to interconnect the different sites.

It should become clear that MPLS is not the silver bullet to all network requirements and
use cases. As a wise man once said, “The art of prophecy is very difficult, especially
with respect to the future.” However, looking into the crystal ball, it is almost certain
that MPLS will remain an integral part of any service provider network in the foreseeable
future. At the same time, promising new technology may cause major disruptions in the
networking industry and become the MPLS successor: Segment Routing IPv6 (SRv6).

The details of SRv6 will be introduced Chapter 3, “What Is Segment Routing IPv6
(SRv6)?” but for now, it is just important to understand that SRv6 relies on the IPv6 data
plane and not on MPLS. In a way, it is a step back to the roots (or the OSI model) and
addresses many of the challenges and shortcomings of MPLS:

■■ Extensive IPv6 addressing space

■■ Virtual private networks (VPNs) using the IPv6 data plane

■■ Native load balancing, thanks to the IPv6 Flow label

■■ Traffic engineering using the IPv6 data plane

■■ Service chaining using the IPv6 data plane

At the same time, the potential of SRv6 goes much further and does not stop at replacing
MPLS. Recall that MPLS support in some network domains is rather limited, and alterna-
tive overlay techniques such as VXLAN are heavily used (for instance, in the data center).
Due to the IPv6 data plane of SRv6, there is an opportunity to unify the underlay end-
to-end and use a single BGP-based control plane layer to provision services between the
access and the data center network.
30 Chapter 1: MPLS in a Nutshell

The journey to SRv6 is still at an early stage but continues to gain momentum. This book
provides an in-depth approach to both theory and practice to be prepared for the transi-
tion from MPLS to SRv6 with or without an intermediate stop at SR-MPLS. Either way,
the final destination of this network transition should be SRv6.

Summary
MPLS is a protocol that enables efficient forwarding of data packets across a network by
assigning labels to the packets. Labels are used to identify paths through the network so
packets can be quickly routed between nodes. MPLS operates at Layer 2.5, between the
network layer (Layer 3) and the data link layer (Layer 2) of the OSI model.

MPLS has a label structure that consists of a 20-bit label value, a 3-bit Experimental
(EXP) field, a 1-bit Bottom of Stack (BoS) indicator, and an 8-bit Time to Live (TTL) field.
A label is inserted between the Layer 2 and Layer 3 headers of a packet. The Label Value
field contains a unique identifier for the label, the EXP field is used to prioritize packets,
and the TTL field is used to limit the lifespan of the packet, which also helps to break a
routing loop in the core.

The control plane and the data plane are the two planes in MPLS. The control plane sets
up the label-switched paths (LSPs) and manages the label distribution among routers. It
exchanges label information between routers using Label Distribution Protocol (LDP) or
Resource Reservation Protocol (RSVP). The data plane forwards the packets based on the
labels assigned in the control plane.

LDP is used to distribute labels between routers in the network and is therefore a proto-
col that runs between MPLS-enabled routers. When a router receives a packet, it checks
the label assigned to the packet and uses the label to forward the packet along the LSP.
LDP also supports label stacking, where multiple labels can be assigned to a packet,
allowing it to be routed through a more specific path, or follow a specific constraint.

When a packet enters an MPLS network, the router performs a label imposition (with a
PUSH operation). As it traverses through the network, its label is swapped as it passes
through each LSR. When it reaches its final destination, the label is removed (with a POP
operation). Traffic forwarding using labels enables MPLS networks to quickly and effi-
ciently forward traffic based on the labels assigned to each packet. Each node in the net-
work maintains a label forwarding table that maps incoming labels to outgoing labels—
essentially outgoing interfaces.

Traffic protection is a widespread use case for MPLS in the backbone and core networks.
When combined with segment routing, the fast-reroute mechanism called TI-LFA is a key
benefit for network operators using SR MPLS. TI-LFA is built explicitly to cover 100%
traffic protection in the event of a node or link failure in an SR-enabled network. TI-LFA
precalculates the backup path for any failure scenario, from any node in the network, so
if a link failure is detected, the backup path takes over in less than 50 ms.
 Summary 31

MPLS VPN services are a popular use case for MPLS, where VPN services are provided
to customers over a shared service provider network. MPLS VPNs allow customers to
securely connect their geographically dispersed sites by using virtual connections that
are separate from the public Internet. The transport label is part of the MPLS forwarding
in the core, whereas the service label is used to represent customer routes that are part of
a VRF instance. Various categories of VPNs are available: L2VPN, L3VPN, and Multicast
VPN (mVPN).

While MPLS has proven to be a reliable and scalable backbone solution for service pro-
viders and large enterprise networks, challenges and shortcomings limit its potential. One
of the challenges of MPLS is its label space limitation. MPLS labels have a fixed length,
which limits the number of labels that can be used in a network to 2^20.

Inter-AS limitations are another challenge of MPLS. MPLS was initially designed to work
within a single administrative domain, which can make it difficult to connect networks
from different domains. More recently, BGP Labeled Unicast was introduced to help with
inter-AS, 6PE, unified MPLS, and CSC scenarios. BGP-LU is a key benefit for extending
MPLS VPN services support over inter-AS domains.

RSVP-based traffic engineering is a method of controlling network traffic flows using

MPLS, but it also has limitations. RSVP is a complex protocol that can be difficult to
manage and scale, particularly in large networks. An RSVP-TE Path message is sent from
the headend node to the tailend node, carrying info about tunnels source, destination,
and traffic requirements. Each node along the path processes it, checks for resources, and
either reserves them or sends a ResvErr message. The tailend node sends an RSVP-TE
Resv message back to the headend node, indicating the establishment of the tunnel, and
includes path and label information. RSVP-based traffic engineering can lead to ineffi-
cient use of network resources if not configured and managed properly by the network
operator.

Service chaining complexities are another challenge of MPLS. Service chaining involves
forwarding packets through a sequence of network functions or services, which can be
complex to implement in MPLS networks. SRv6 has a far greater applicability for service
chaining compared to MPLS technology.

In the long run, while MPLS has proven to be a reliable and scalable solution for trans-
port networks for many years, network operators are adopting segment routing and SRv6
as the new standard deployment. Greenfield and brownfield deployments are both appro-
priate candidates for implementing SR MPLS or SRv6. In the case of SRv6, it can be used
not only in traditional service provider architecture deployments but also in other areas,
such as data centers, where it is necessary to push traffic through virtual machines, con-
tainers, and different virtual functions. The only requirement in that case is a plain IPv6
data plane without MPLS.
32 Chapter 1: MPLS in a Nutshell

References and Additional Reading

■■ RFC 6790: The Use of Entropy Labels in MPLS Forwarding, www.rfc-editor.org/
info/rfc6790
■■ RFC 4385: Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over
an MPLS PSN, www.rfc-editor.org/info/rfc4385
■■ RFC 6391: Flow-Aware Transport of Pseudowires over an MPLS Packet Switched
Network, www.rfc-editor.org/info/rfc6391
■■ RFC 1918: Address Allocation for Private Internets, www.rfc-editor.org/info/rfc1918
■■ RFC 8300: Using the Encapsulation for Lower-Layer Protocols (ELP) over TCP to
Encapsulate Routing and Control Protocols, www.rfc-editor.org/info/rfc8300
■■ RFC 3032: MPLS Label Stack Encoding, www.rfc-editor.org/info/rfc3032
■■ RFC 7274: An Entropy Label Capability for MPLS Forwarding, www.rfc-editor.org/
info/rfc7274
■■ RFC 2547: BGP/MPLS VPNs, www.rfc-editor.org/info/rfc2547
■■ RFC 4664: Framework for Layer 2 Virtual Private Networks (L2VPNs),
www.rfc-editor.org/info/rfc4664
■■ RFC 6513: Multicast in MPLS/BGP IP VPNs, www.rfc-editor.org/info/rfc6513
■■ RFC 5036: LDP Specification, www.rfc-editor.org/info/rfc5036
Index

Symbols configuration, 271

use case, 272–282
* wildcard, 1112 verification, 272
architecture, SPRING, 40–41

A area
IS-IS, 222
ABR (area border router), 5, 38, 39, 224 OSPF, 224
acceptance test, 1085, 1087 ASBR (autonomous system border router),
5, 20
active-active mode, 425
assembler code, 34–35
active-backup mode, 426
assurance, intent-/model-based,
address family, BGP, 84 1019–1020. See also service assurance
adjacency, IS-IS, verification, 265–266 automation, 1065, 1097–1098
adjacency segment, 226 pipeline, 1098, 1101–1104
Adjacency SID, 47–49, 226 solution lifecycle, 1067
Adj-SID sub-TLV, 59–61, 68–69 test, 1094
algorithm. See also Flex Algo
operator-defined, 74–75
SPF (Shortest Path First), 56, 73–74, 220
B
Angstrom era, ONLINE backup path, 19
anycast, set, 219 base format, 108
anycast SID, 45, 47, 219 BD (bridge domain), 447
SR-MPLS, 254–255 BFD (Bidirectional Forwarding Detection),
configuration, 254–256 857–859. See also BLB (BFD over
verification, 256–257 Logical Bundle); BoB (BFD over
Bundle)
SRv6, 270–271
1116 BFD (Bidirectional Forwarding Detection)

async mode, 859–860 enabling in an SR-MPLS network,

BLB, 861 376–383
configuration, 872–874 verification, 327–328
packet capture, 863–865 protocol ID, 96
verification, 874–883 proxy Prefix SID, 383–387
BoB, 861 RR (route reflector), 6
configuration, 865–868 UPDATE message, 83–84, 86–87, 96–98,
186, 187–188, 190, 191, 203–204
packet capture, 863
for SRv6 L2 services, 192–193
verification, 868–871
for SRv6 L3 services, 194–195,
demand mode, 859
196–198
echo, 859–860
BGP Link-State extensions for SR, 87–95
over LAG interfaces, 860
BGP Peering SID, 50–52
packet capture, 861–862
BGP Prefix SID, 49–50, 85–87
SH (single-hop) sessions, 860–861
BGP-LU (BGP Labeled Unicast), 220
BG (bridge group), 447
inter-AS, 343
BGP. See also MP-BGP (Multiprotocol
configuration, 344–345
Border Gateway Protocol)
data forwarding, 349–350
address families, 84
design, 343
-free core, 1
verification, 345–348
L3VPN, Flex Algo, 318–322
intra-AS
Link-State Extensions for SRv6, 201–205
design, 330
MP_REACH_NLRI path attribute,
608–609 with Prefix SID, 328–330
multiprotocol, 17 binary repository, 1100–1101
NHT (next hop tracking), 220 Binding Segment SID, 52–53
operational complexity, 22 BLB (BFD over Logical Bundle), 860, 861
PIC (Prefix Independent Convergence), configuration, 872–874
292–293 packet capture, 863–865
PIC Edge, 945–948 verification, 874–883
multipath verification, SRv6, BoB (BFD over Bundle), 860, 861
981–995 configuration, 865–868
unipath configuration, SR-MPLS, packet capture, 863
948–951
verification, 868–871
unipath configuration, SRv6,
broadcast domain, EVPN, 444
962–970
brownfield deployment, 354
unipath verification, SR-MPLS,
951–962 coexistence migration strategy, 356–357
unipath verification, SRv6, 970– IPv6 backhaul strategy, 356–357
981 SR-MPLS, 358–360
Prefix SID, 324, 609–610 enabling and preferring on P1, P2,
configuration, 324–326 and PE-1, 363–365
 command/s 1117

enabling on P2, P3, and PE-3, microloop avoidance rib-update-delay

360–363 5000, 942–943
BVLAN (BFD over VLAN over Bundle), pcap trace, ONLINE-ONLINE
860 ping, 249, 254, 270, 349, 423, 635, 676,
767, ONLINE-ONLINE, ONLINE-

C ONLINE, ONLINE-ONLINE,
ONLINE-ONLINE, ONLINE-
ONLINE
CCM (Continuity Check Message), 809–
ping ethernet cfm domain service, 815
810
segment-routing mpls sr-prefer, 361
CE (customer edge) router, 5, 6
service vpp status, ONLINE-ONLINE
CFM (Ethernet Connectivity Fault
Management), 808 service vpp stop, ONLINE-ONLINE
CCM (Continuity Check Message), show bfd ipv6 session, 868–869
809–810 show bfd ipv6 session interface bundle-
configuration, 811–812 Ether 1 detail, 869
Linktrace Protocol, 811 show bfd ipv6 session interface TF0/0/0/0
detail, 870–871
Loopback Protocol, 810
show bfd neighbors, 877
MA (maintenance association), 808
show bfd neighbors interface port-
MD (maintenance domain), 808
channel 1 details, 877–878
MEP (maintenance endpoint), 808–809
show bfd session, 875
MIP (maintenance intermediate point),
show bfd session interface bundle-ether 1
809
detail, 875–876
PDUs, 809
show bgp ipv4 labeled-unicast, 347, 348,
verification, 813–816 377–378, 379–381, 713, 740–741
change management, 1104–1106 show bgp ipv4 rt-filter, 771, 774
CI/CD/CT (continuous integration/ show bgp ipv4 rt-filter neighbors,
continuous delivery/continuous 774–775
testing), 1101
show bgp ipv4 unicast, 328, 348,
Cilium, ONLINE 713–714
CML (Cisco Modeling Lab), ONLINE show bgp ipv4 vpn, ONLINE-ONLINE
code, assembler, 34–35 show bgp l2vpn evpn bridge-domain,
coexistence brownfield strategy, 356–357 446, 521–522, 525–527, 537, 540,
collision, label, 43 549–550, 568–569

command/s show bgp l2vpn evpn bridge-domain

200-BD, 527–529
containerlab deploy, ONLINE
show bgp l2vpn evpn bridge-domain
containerlab inspect, ONLINE-ONLINE 200-BD received-sids wide, 523–524
debug lacp packets, 483 show bgp l2vpn evpn bridge-domain
help sr localsid, ONLINE-ONLINE VPWS:300, 594–599
hw-module, 240 show bgp l2vpn evpn rd, 458–461, 464,
hw-module bfd-hw-offload enable 467–469, 470, 523, 601
location, 867 show bgp l2vpn evpn route-type, 530
1118 command/s

show bgp l2vpn evpn route-type 766, 955–957, 960–962, 974–975,

ethernet-segment, 530–532, 600 979, 986–988, 991–992
show bgp l2vpn evpn summary, 518–519 show ethernet cfm local meps domain
show bgp segment-routing srv6, service, 813
ONLINE-ONLINE show ethernet cfm peer meps domain
show bgp summary, ONLINE-ONLINE service, 814–815
show bgp vpnv4 uni vrf, ONLINE- show ethernet sla operations detail
ONLINE profile, 820–821, 827–828
show bgp vpnv4 unicast, 741–742 show ethernet sla statistics brief profile,
821–823, 829–830
show bgp vpnv4 unicast advertised
summary, 408–409 show ethernet sla statistics detail profile,
823–825, 831–834
show bgp vpnv4 unicast vrf, 626,
628–630, 646–647, 649–650, show evpn ethernet-segment, 494, 580
651–652, 655, 659–661, 663, show evpn ethernet-segment interface
667–668, 670, 673–674, 702–703, BE200 carving detail, 496–498
704–705, 705–706, 733–735, show evpn ethernet-segment interface
758–759, 760, 951–953, 954, BE300 carving detail, 581–582
958–960, 971–973, 976–977,
show evpn ethernet-segment interface
982–984, 989–990
Bundle-Ether260 detail, 538–539
show bgp vpnv4 unicast vrf local-sids,
show evpn evi, 498, 583–584
627, 647–648, 663–664, 671
show evpn evi ead, 584–585
show bgp vpnv4 unicast vrf received-sids,
627–628, 648, 664, 671 show evpn evi inclusive-multicast detail,
502–503
show bgp vrf, 276, 320–321, 409–410,
420–421 show evpn evi vpn 200 mac, 501–502
show bgp vrf nexthop-set, 634, 650, 667 show evpn evi vpn 205 mac, 560–561
show bgp vrf-db table, 566–567, 656 show evpn evi vpn-id 200 detail,
499–500
show bgp vrf-db table all, 519–521, 594
show evpn summary, 493–494
show bpg vpnv4 unicast vrf, 665–666
show interfaces brief, 477–478, 483,
show bundle bundle-Ether 200, 478, 484
574–575, ONLINE-ONLINE
show bundle bundle-Ether 250, 481, 482
show ip cef detail, 715, 717, 718, 744,
show bundle bundle-Ether 300, 575–576 745–746, 749
show cef, 887–888, 892–893, 898–899, show ip cef internal, 889–890, 894–895,
926 900–901, 930–931
show cef detail, 714–715, 716, 717–718, show ip cef vrf, ONLINE-ONLINE
743, 744–745, 747, 748, 749–750
show ip cef vrf detail, 711, 739, 765, 957
show cef ipv6, 904–905, 908–909,
show ip ospf database, 234
912–913, 937–940, 942
show ip route repair-paths, 888–889, 893,
show cef ipv6 detail, 980–981, 993–994
899–900, 928, 954–955
show cef vrf, 276, 279
show ip route vrf, 737, 762
show cef vrf detail, 632–633, 654,
show ip route vrf repair-paths, 709
669–670, 675, 709–711, 738, 764,
show ipsla statistics 11, 843–844
 command/s 1119

show ipsla statistics 21, 844–846 show lacp, 479–480, 576–577

show ipsla statistics aggregated 11, show lacp bundle-Ether 250, 481, 482
846–847 show memif, ONLINE-ONLINE
show ipsla statistics aggregated 21, show mpls forwarding, 362, 364, 374
847–850
show mpls oam dpm adjacency, 797
show ipsla twamp session, 854
show mpls oam dpm prefix, 797
show ipv6 cef, ONLINE-ONLINE
show mpls oam dpm summary, 795–796
show ipv6 route isis, ONLINE-ONLINE
show route, 891, 896–897, 917–918,
show isis adjacency, 265–266 924–925
show isis database, 233, 247, 265, 272, show route 10.0.1.8/32, 886–887
288, 291, 299, 309–310
show route ipv6, 280–281, 282, 289, 290,
show isis fast-reroute summary, 884 291–292, 300, 311–312, 903–904
show isis fast-reroute ti-lfa tunnel, 894, show route ipv6 detail, 906–907,
900, 929 911–912
show isis flex-algo, 308 show route vrf, 278
show isis ipv4 fast-reroute detail, 887, show route vrf detail, 631–632, 653–654,
892, 898, 904, 918, 925, 927–928, 668–669, 674–675, 708, 736, 761,
933–934, 934 762–763, 973–974, 977–978,
show isis ipv6 fast-reroute detail, 908, 985–986
912 show segment-routing srv6 capabilities-
show isis neighbor, ONLINE-ONLINE parameters, ONLINE-ONLINE
show isis rib, 929–930 show segment-routing srv6 locator,
show isis srv6 locators det, ONLINE- ONLINE-ONLINE, ONLINE-
ONLINE ONLINE
show l2vpn bridge-domain bd-name 200- show segment-routing srv6 locator
BD detail, 508–510 MAIN detail, ONLINE-ONLINE
show l2vpn bridge-domain bd-name show segment-routing srv6 locator
detail, 563–565 MAIN sid, 513–514, 546–547
show l2vpn bridge-domain brief, 508, show segment-routing srv6 sid, 503–504,
511, 544 586, ONLINE-ONLINE, ONLINE-
ONLINE
show l2vpn forwarding bridge-domain
ELAN-BG:200-BD mac-address show segment-routing srv6 sid detail,
location 0/RP0/CPU0, 510–511 633, 634–635, 656
show l2vpn forwarding bridge-domain show segment-routing traffic-eng policy,
ELAN-BG:210-BD mac-address 274–275
location 0/RP0/CPU0, 545 show slrg name, 932
show l2vpn forwarding xconnect detail show sr localsids, ONLINE-ONLINE,
location, 591 ONLINE-ONLINE
show l2vpn mac-learning, 512 show sr policies, ONLINE-ONLINE
show l2vpn mac-learning mac all location, show sr steering-policies, ONLINE-
511 ONLINE
show l2vpn xconnect group VPWS-XC,
589–591
1120 command/s

show trace, ONLINE-ONLINE, RIB/FIB update time, 858

ONLINE-ONLINE, ONLINE- RLFA (Remote Loop-Free Alternate),
ONLINE 880–882
systemctl restart frr, ONLINE-ONLINE topology update and repair path
traceroute, 249, 312, 342, 362–363, computation time, 858
364–365, 375–376, 382, 383, 412, 423, CPU (central processing unit), 33, 35,
645, 677, 718–719, 750–751, 767 ONLINE
traceroute ethernet cfm domain service, ISA (instruction set architecture), 35
816
program counter, 35
compiler, 34
CSC MPLS network migration, 434–435
Containerlab, ONLINE-ONLINE
Linux SRv6 lab deployment, ONLINE-
ONLINE D
topology definition, ONLINE, ONLINE-
ONLINE DARPA (Defense Advanced Research
Projects Agency), 28
containerlab deploy command, ONLINE
data plane, 10
containerlab inspect command, ONLINE-
ONLINE MPLS, 205–207
CONTINUE operation, 41 segment routing, 36–37
control plane, 10, 87–88 SONiC (Software for Open Networking
in the Cloud), ONLINE
MPLS, 205–207
SR-MPLS, 41–42, 207–209
show isis database, 257
SRv6, 209–210
SR-MPLS, 207–209, 243–244
VPP (Vector Packet Processor), ONLINE-
SRv6, 209–210, 257
ONLINE
traceroute, 254
database, label switching, 43, 44. See also
VPP (Vector Packet Processor), ONLINE- FIB (Forwarding Information Base);
ONLINE RIB (Routing Information Base)
converged SR domain, 1083 debug lacp packets command, 483
development and release process, deployment model
1084–1086
brownfield, 354
environments, 1089–1096
greenfield, 354
key phases, 1086–1089
dev pipeline, 1098
service portfolio consolidation,
development and release process, 1084
1083–1084
automation, 1097–1098
convergence, 878–879. See also
Microloop Avoidance domain releases, 1096–1097
calculating, 858 key phases, 1086–1089
failure event detection time, 858 lab environments, 1089–1096
IPFRR (IP Fast Reroute), 878–881 testing, 1097
microloops, 935 development test, 1091
network event information propagation Dijkstra SPF algorithm, 224
time, 858
 E-Line 1121

disaggregation, SONiC (Software for recommendations for components,

Open Networking in the Cloud), 1070–1071
ONLINE-ONLINE responsibilities, 1067–1069
domain, 1043. See also converged SR SAP (service access point), 1058–1059
domain
segment routing, 38
architecture blueprint, 1059–1061
squads, 1082
API gateway and graphical user
teams, 1082–1083
interface, 1061–1062
downstream on-demand, 11
apps and microservices, 1065
DPDK, ONLINE-ONLINE
error and event handling, 1066
dual-homed greenfield strategy, 356
inventories, 1063–1064
messaging, 1066
network resources, 1065 E
resource fulfillment, 1064
ECMP (equal-cost multipath), 25, 38,
rollout and migration automation,
798–800
1064–1065
EFP (Ethernet flow point), 447
security measures and events,
1066 E-LAN, 472–473
service and resource assurance, port-active multihomed service
1062–1063 access circuit configuration,
service catalog, 1063 474–477
service orchestration, 1064 access circuit verification,
477–484
solution lifecycle automation,
1067 BGP configuration, 514–518
workflow automation engine, BGP verification, 518–533
1065 EVPN configuration, 484–491
workforce and customer apps, EVPN verification, 491–504
1066 L2VPN configuration, 504–507
availability of components as shared L2VPN verification, 507–514
services by other domains, 1070
route types and usage, 473
boundaries, 1056–1058, 1059
single-homed service, 533–534
component criticality, 1069
BGP configuration, 520–547
component sourcing, 1071–1074
BGP verification, 547–551
converged SR, 1083
EFP configuration, 534–535
development and release
methodology, 1084–1086 EFP verification, 535

service portfolio consolidation, EVPN configuration, 535–536

1083–1084 EVPN verification, 536–542
key roles, 1075–1082 L2VPN configuration, 542–543
organization and transformation, 1074– L2VPN verification, 543–547
1075 E-Line
all-active BGP
1122 E-Line

configuration, 591–593 Ethernet OAM (Operations,

verification, 593–601 Administration, and Maintenance),
806–807
all-active EFP (access circuit)
Ethernet tag ID, 450–452
configuration, 571–574
EVC (Ethernet virtual circuit), 447
verification, 574–577
EVI (EVPN instance), 444, 445–447
all-active EVPN
EVPN (Ethernet VPN), 212, 215,
configuration, 577–579
440–441
verification, 579–586
aliasing, 444
all-active L2VPN
benefits, 443–444
configuration, 586–588
BGP routes, 452–454
verification, 588–591
broadcast domain, 444
BGP route types and usage, 570–571
E-LAN, 472–473
End behavior, SRv6, 113–114
port-active MHD BGP
End.B6.Encaps behavior, 142–143 configuration, 514–518
End.B6.Encaps.Red behavior, 143–144 port-active MHD BGP
End.B6.Insert behavior, 144–145 verification, 518–533
End.B6.Insert.Red behavior, 145–146 port-active MHD EVPN
End.DT2M behavior, SRv6, 122–123 configuration, 484–491

End.DT2U behavior, SRv6, 120–121 port-active MHD EVPN

verification, 491–504
End.DT4 behavior, SRv6, 116–117
port-active MHD L2VPN
End.DX2 behavior, SRv6, 119 configuration, 504–507
End.DX4 behavior, SRv6, 117–118 port-active MHD L2VPN
endpoint behaviors, 141 verification, 507–514
SID (segment identifier), 1113 port-active multihomed service,
SRv6 policy, 141, 146 474–484
uSID (micro SID), 149–150 route types and usage, 473
endpoint node, 126 SHD BGP configuration, 520–547
endpoint/egress node, 38 SHD BGP verification, 547–551
end-to-end QoS, MPLS (Multiprotocol SHD EFP configuration, 534–535
Label Switching), 21–22 SHD EFP verification, 535
End.X behavior, SRv6, 114–115 SHD EVPN configuration,
EPE (egress peer engineering), 41 535–536
ES (Ethernet segment), 445, 447–449 SHD EVPN verification, 536–542
ESI (Ethernet segment identifier), 445, SHD L2VPN configuration,
449–450 542–543
Ethernet CFM (Connectivity Fault SHD L2VPN verification,
Management). See CFM (Ethernet 543–547
Connectivity Fault Management) single-homed service, 533–534
E-Line
 Flex Algo 1123

all-active BGP configuration, Route Type 3, 467–469, 512

591–593 Route Type 4, 470–472
all-active BGP verification, VLAN services interfaces, 451–452
593–601
EVPN VPWS, 191–192, 199–200
all-active EFP configuration,
extranet L3VPN
571–574
over SR-MPLS
all-active EFP verification,
574–577 configuration, 752–756
all-active EVPN configuration, verification, 756–767
577–579 over SRv6
all-active EVPN verification, configuration, 657
579–586 verification, 662–677
all-active L2VPN configuration,
586–588
all-active L2VPN verification, F
588–591
BGP route types and usage, F3216 format, 148
570–571 failure event detection time, 858
ES (Ethernet segment), 445, 447–449 FEC (forwarding equivalence class), 11
ESI (Ethernet segment identifier), 445, FIB (Forwarding Information Base), 10
449–450 pre- and post-failure entries, 936–942
Ethernet tag ID, 445, 450–452 update time, 858
E-Tree, 551–552 flat MPLS network migration, 429–430
BGP configuration, 565 Flex Algo, 73–78, 1005–1007
BGP verification, 565–569 assigning to a BGP L3VPN service,
EFP (access circuit) configuration, 318–322
553–555 calculation of a path, 303
EFP (access circuit) verification, definition, 302
555–556
definition advertisement, 302
EVPN configuration, 556–559
disjoint paths, 312–313
EVPN verification, 559–561
configuration, 313–315
L2VPN configuration, 561–563
verification, 315–318
L2VPN verification, 563–565
installation of forwarding entries, 303
EVI (EVPN instance), 445–447
link attribute advertisement, 302–303
MAC VRF instance, 444
low-latency path, 304–305
MEF 6.3, 441–442
configuration, 305–308
Route Type 1
verification, 308–312
per-ESI Ethernet A-D route,
metrics, 78
454–458
prefix metric, 303
per-EVI Ethernet A-D route,
458–463 SID advertisement, 303
Route Type 2, 463–466 SR-MPLS configuration, 322–324
1124 Flex Algo

sub-sub-TLVs, 79–83 enabling SRMS, 365–372

use cases, 304 enabling the BGP Prefix SID,
Flexible Algorithm Definition sub-TLV, 376–383
78–79 SRv6
Flow Label field, IPv6 header, 104–106 building a new network using an
forwarding plane, 10 IWG, 389–401
FRR (Fast Reroute), 18–19, 41, 858 building a new network using
dual-connected PE devices,
FRR (Free Range Routing), ONLINE-
413–424
ONLINE
building a new network using
daemons, ONLINE-ONLINE
inter-AS Option A, 401–413
IPv4 L3VPN service, ONLINE-ONLINE
GUA (global unicast address), 162, 164
release 9.1, ONLINE-ONLINE

H
SRv6 headend and endpoint support,
ONLINE-ONLINE
system architecture, ONLINE
hash, n-tuple, 25
vytish, ONLINE-ONLINE
headend behaviors, 132
full-mesh L3VPN
header
over SR-MPLS
IPv6, 104
BGP label allocation modes, 701
Flow Label field, 104–106
configuration, 689–700
Next Header field, 106
verification, 701–719
Traffic Class field, 104
over SRv6
MPLS, 6–7
BGP configuration on PE-2,
624–625 segment routing, 36–37, 106–107,
125–127. See also SRH (segment
configuration, 610–622
routing header)
full-mesh verification, 625–636
fields, 124–125
SRv6 configuration, 623–624
Penultimate Segment Pop,
VRF and interface configuration, 127–128
622
Ultimate Segment Pop, 129
USD (Ultimate Segment
G Decapsulation), 130–132
help sr localsid command, ONLINE-
GRE over L3VPN, 26 ONLINE
greenfield deployment, 354 H.Encaps behavior, 132–133
dual-homed migration strategy, 356 H.Encaps.L2 behavior, 135
interworking migration strategy, 355–356 H.Encaps.L2.Red behavior, 136–137
SR-MPLS, 365 H.Encaps.Red behavior, 133–135
BGP proxy Prefix SID, 383–387 high-availability, 425, 857–858. See
enabling LDP on the border node, also BFD (Bidirectional Forwarding
372–376 Detection); FRR (Fast Reroute);
LFA (Loop-Free Alternate); TI-LFA
 IOS XR 1125

(Topology-Independent Loop-Free segments, 36

Alternate) summarization, 220
active-active, 425 IMIX (Internet Mix), ONLINE
active-backup, 426 integration test, 1080, 1091
BFD (Bidirectional Forwarding intent-driven configuration, 1018
Detection), 857–859
intent-/model-based assurance,
async mode, 859–860 1019–1020
BLB, 861 inter-AS BGP-LU, 341–342, 343
BoB, 861, 863 configuration, 344–345
demand mode, 859 data forwarding, 349–350
echo, 859–860 design, 343
over LAG interfaces, 860 verification, 345–348
packet capture, 861–862 inter-AS routing, 21
SH (single-hop) sessions, 860–861 Option A, 401–413
FRR (Fast Reroute), 858 Option C, 431–433
LFA (Loop-Free Alternate), 879–880 interface, loopback, 163–164
load sharing, 426 interface loopback address, SRv6,
TI-LFA (Topology-Independent Loop- 237–238
Free Alternate), 883 interworking greenfield strategy, 355–356
high-level programming language, 33–34 intra-AS BGP-LU
high-precision probing, 1020–1023 BGP Additional Path feature, 331–332
H.Insert behavior, 138–140 configuration, 332–337
hub-and-spoke L3VPN design, 330
over SR-MPLS with Prefix SID, 328–330
configuration, 719–732 verification, 337–341
verification, 732–751 IOS XE, 251–253
over SRv6 advertising the BGP Prefix SID, 326
configuration, 636–645 assigning Prefix SID to Loopback0, 231
verification, 645–657 BGP-LU session on ASBR-3, 344
hw-module bfd-hw-offload enable location configuring anycast SID, 256
command, 867
enabling segment routing, 230
hw-module command, 240
enabling segment routing for IS-IS, 246
enabling segment routing for OSPF, 250
I SR-MPLS IS-IS verification, 247–248
verifying Prefix SID assignment, 236
IGP (interior gateway protocol), 10
verifying the advertisement of the
link-state. See IS-IS; OSPF (Open Shortest anycast SID, 257
Path First)
IOS XR
PCE (path computation element), 211
advertise the SRv6 locator, 307
Prefix SID, 45–47
1126 IOS XR

advertising the BGP Prefix SID, 326 iproute2, ONLINE-ONLINE, ONLINE,

assigning an SRv6 locator to flex algo ONLINE, ONLINE-ONLINE
128, 307 IPSLA, 834
assigning link delay, 307 configuration, 836–843
assigning Prefix SID to Loopback0, 231 verification, 843–851
BGP-LU session on ASBR-1, 344 IPv6
Cisco EVC framework, 446–447 backhaul brownfield strategy, 356–357
configuring anycast SID, 255–256 GUA (global unicast address), 162, 164
configuring anycast SRv6 locator on P-3, header
271 Flow Label field, 104–106
configuring IS-IS on ABR-1, 263 Next Header field, 106
configuring IS-IS on P-1, 262–263 Traffic Class field, 104
configuring IS-IS on PE-1, 263–264 LLA (link local address), 162, 164–165
configuring IS-IS on RR-1, 264–265 ULA (unique local address), 162
enabling segment routing, 230 ISA (instruction set architecture), 35
enabling segment routing for IS-IS, 246 IS-IS. See also SR-MPLS, IS-IS; SRv6,
enabling segment routing for OSPF, 250 IS-IS
enabling SRv6, 240 areas, 222
enabling UPA processing, 298 extensions for segment routing (RFC
increasing the maximum number of 8667), 53–54
UPAs, 297 Adj-SID sub-TLV, 59–61
modifying the UPA lifetime, 296 Flex Algo sub-sub-TLVs, 79–83
prefix tagging for UPA generation, 297 LAN-Adj-SID sub-TLV, 61
propagating UPAs from IS-IS to Level 1, Prefix-SID sub-TLV, 57–59
298 Router Capability TLV, 54–57
selectively generating UPAs, 297 Segment Routing Algorithm sub-
SR-MPLS IS-IS verification, 247 TLV, 55–56
SR-MPLS OSPF verification, 250–251 SID/Label Binding TLV, 61–62
SRv6-TE policy and traffic steering using SID/Label sub-TLV, 63–64
color, 273–274 SRLB sub-TLV, 56–57
summary route advertisement, 286 extensions for SRv6, 175–176
summary route for flex algo 128, 308 segment routing over IPv6
suppressing default route generation, 286 capabilities, 180–183
UPA announcement, 296 segment routing over IPv6 locator,
verifying Prefix SID assignment, 235 176–180
verifying the advertisement of the SIDs, 183–186
anycast SID, 257 levels, 222
IoT (Internet of things), 37 LSP (label switched path), 179–180
IP (Internet Protocol), 28 overload bit, 223
IPFRR (IP Fast Reroute), 878–881 route leaking, 223
 label/s 1127

route propagation, 223 BGP configuration on PE-2,

router types, 222 624–625
routing, 222 configuration, 610–622
verifying Prefix SID assignment, 235 SRv6 configuration, 623–624
ITU-T Y.1731 Performance Measurement verification, 625–636
delay and jitter measurement VRF and interface configuration,
622
configuration, 818–820
GRE over, 26
verification, 820–825
hub-and-spoke, over SR-MPLS
SLM (synthetic loss measurement), 816
configuration, 719–732
configuration, 826–827
verification, 732–751
verification, 827–834
hub-and-spoke, over SRv6, 636
configuration, 636–645
L verification, 645–657
interoperability, ONLINE-ONLINE
L2VPN, 3, 27. See also EVPN (Ethernet
VPN) Cisco Catalyst 8000V Edge IPv4
L3VPN service, ONLINE-
pseudowire, 11–12
ONLINE
service assurance, 806–807
FRR IPv4 L3VPN service,
CFM (Ethernet Connectivity ONLINE-ONLINE
Fault Management),
over SR-MPLS, 677–679
808–816. See also CFM
(Ethernet Connectivity Fault configuration, 679–685
Management) verification, 686–688
ITU-T Y.1731 Performance over SRv6, 608
Measurement. See ITU-T Y.1731 BGP Prefix SID path attribute,
Performance Measurement 609–610
L3VPN, 2, 605–606 MP_REACH_NLRI path attribute,
extranet 608
over SR-MPLS, configuration, NLRI, 608
752–756 service assurance, 834, 847–850
over SR-MPLS, verification, IPSLA, 834. See also IPSLA
756–767
TWAMP, 835–836. See also
over SRv6, 656 TWAMP (Two-Way Active
over SRv6, configuration, 657–662 Measurement Protocol);
over SRv6, verification, 662–677 TWAMP Light
Flex Algo, 318–322 lab environment, 1089–1093
full-mesh, over SR-MPLS development, 1096–1097
BGP label allocation modes, 701 preparation and construction, 1093–1096
configuration, 689–700 label/s, 1, 7–9
verification, 701–719 allocation, 12–13
full-mesh, over SRv6 -based forwarding, 15–16
1128 label/s

collisions, 43 lab deployment, ONLINE-ONLINE

POP operation, 14 Containerlab, ONLINE-ONLINE
PUSH operation, 14 Layer 3 overlay services, ONLINE
service, 14, 16 Linux IPv4 L3VPN service,
space limitation, 20–21 ONLINE-ONLINE
SWAP operation, 14 Linux IPv4/IPv6 L3VPN service,
ONLINE-ONLINE
LAG (link aggregation group), 25, 105
Linux IPv6 L3VPN service,
LAN-Adj-SID sub-TLV, 61
ONLINE-ONLINE
LDP (Label Distribution Protocol), 1, 12.
Linux point-to-point L2VPN
See also mLDP
service, ONLINE-ONLINE
downstream on-demand, 11
overlay services VPN-1, ONLINE-
enabling on the border node, 372–376 ONLINE
ID, 11 overlay services VPN-2, ONLINE-
-IGP synchronization, 24 ONLINE
label/s overlay services VPN-3, ONLINE-
allocation, 12–13 ONLINE
-based forwarding, 15–16 underlay connectivity, ONLINE-
ONLINE
service, 14, 16
underlay domain transport,
space limitation, 20–21 ONLINE-ONLINE
neighbor discovery, 11–12 network stack, ONLINE-ONLINE
unsolicited downstream, 11 RPD (routing policy database), ONLINE-
legacy network. See also domain ONLINE, ONLINE-ONLINE
replacing or enhancing with SR SRv6 endpoint support, ONLINE-
IT evolution and gap awareness, ONLINE
1051–1056 SRv6 headend support, ONLINE-
migration strategy, 1049–1051 ONLINE
required knowledge and expertise, SRv6 overlay services configuration,
1046–1049 ONLINE-ONLINE
SR consolidation, 1056–1074 uA/End.X (NEXT-CSID) endpoint
behavior, ONLINE
LER (label edge router), 5
LLA (link local address), 162, 164–165
levels, IS-IS, 222
load sharing, 426
LFA (Loop-Free Alternate), 878–880
locator addressing scheme, SRv6,
LFIB (Label Forwarding Information
165–169
Base), 10
large-scale deployments, 170–172
Linktrace Protocol, 811
small- and medium-scale deployments,
Linux SRv6/Linux kernel, ONLINE-
169–170
ONLINE
uSID, 238–239
Containerlab topology definition,
ONLINE-ONLINE loopback interface, 163–164
hardware offloading, ONLINE-ONLINE Loopback Protocol, 810
 MPLS (Multiprotocol Label Switching) 1129

LSA (link-state advertisement), 224 dual-homed greenfield strategy, 356

LSD (label switching database), 43, 44 interworking greenfield strategy,
LSP (label switched path), 21 355–356
echo request packet, 790–791 IPv6 backhaul brownfield strategy,
356–357
IS-IS, 179–180
MPLS to SRv6, 427–429
labels, 380
CSC MPLS network, 434–435
LSR (label switch router), 5
flat MPLS network, 429–430
MPLS network with inter-AS
M option C, 431–433
unified MPLS network, 430–432
MA (maintenance association), 808
SR-MPLS, 358
MAC VRF instance, 444
SRv6, 387–389
MCD (Midpoint Compressed Data),
building a new network using an
800–801
IWG, 389–401
MD (maintenance domain), 808
building a new network using
MEF (Metro Ethernet Forum), 441–442 dual-connected PE devices,
message/s 413–424
BGP Route Target Constraint, 770 building a new network using
BGP UPDATE, 83–84, 86–87, 96–98, inter-AS Option A, 401–413
186, 187–188, 190, 191, 203–204 MIP (maintenance intermediate point),
for SRv6 L2 services, 192–193 809
for SRv6 L3 services, 194–195, mLDP, 3
196–198 MP_REACH_NLRI path attribute,
SR-MPLS DPM syslog, 798 608–609
methodology, 1084 MP-BGP (Multiprotocol Border Gateway
Protocol), 6, 17
metrics, Flex Algo, 78
extension/s, 83–85
Microloop Avoidance, 935, 942–943
BGP Link-State, 87–95
local protection, 935–940
BGP Link-State extensions for SR
remote protection, 940–941 BGP Egress Peer Engineering
microloop avoidance rib-update-delay (RFC 9086), 95–98
5000 command, 942–943 BGP overlay services on SRv6,
microloops, 935 186–201
migration test, 1096 BGP Prefix SID, 85–87
migration to segment routing, 353–354. MPLS (Multiprotocol Label Switching),
See also brownfield deployment; 4, 6, 28, 440. See also LDP (Label
greenfield deployment Distribution Protocol)
coexistence brownfield strategy, 356–357 backbone routes, 5
deployment models BGP-free core, 1
brownfield, 354 CE (customer edge) router, 6
greenfield, 354 control plane, 205–207
1130 MPLS (Multiprotocol Label Switching)

data plane, 205–207 network, as a computer, 37

FRR (fast reroute), 18–19 network event information propagation
header, 6–7 time, 858
L2VPN, 3, 27. See also L2VPN Next Header field, IPv6 header, 106
L3VPN, 2, 26. See also L3VPN NEXT operation, 41
label/s, 1, 7–9 NLRI, 201–203, 608
-based forwarding, 15–16 Node SID, 45–46, 226
POP operation, 14 nonrouted SID, 110–111
PUSH operation, 14 n-tuple hash, 25
service, 16
space limitation, 20–21 O
SWAP operation, 14
LDP (Label Distribution Protocol), 11, 12 open-source SRv6, ONLINE, ONLINE-
ONLINE. See also open-source SRv6
downstream on-demand, 11
lab deployment
-IGP synchronization, 24
FRR (Free Range Routing), ONLINE-
unsolicited downstream, 11 ONLINE
LER (label edge router, 5 daemons, ONLINE-ONLINE
LSP (label switched path), 21 release 9.1, ONLINE-ONLINE
LSR (label switch router), 5 SRv6 headend and endpoint
mLDP, 3 support, ONLINE-ONLINE
operational complexity, 22 system architecture, ONLINE
pseudowire, 440 vytish, ONLINE-ONLINE
QoS, end-to-end, 21–22 Linux kernel, ONLINE-ONLINE
RSVP-TE, 22–23 hardware offloading, ONLINE-
limitations, 23–24 ONLINE

tunnel, 22–23 network stack, ONLINE-ONLINE

services, 2 SRv6 endpoint support, ONLINE-

ONLINE
traffic protection, 18
SRv6 headend support, ONLINE-
Unified, 210 ONLINE
use cases, 3–4 uA/End.X (NEXT-CSID) endpoint
VPN, 16–18, 20 behavior, ONLINE
VRF instance, 3, 5 SONiC (Software for Open Networking
MPLS TE (Traffic Engineering), 3–4 in the Cloud), ONLINE-ONLINE
mVPN, 3 cli, ONLINE
container modules, ONLINE-

N ONLINE
data plane, ONLINE
disaggregation, ONLINE-
neighbor adjacency, LDP, 11
ONLINE
neighbor discovery, LDP (Label
sonic-cfggen, ONLINE
Distribution Protocol), 11–12
 overload bit 1131

system architecture, ONLINE- underlay domain transport,

ONLINE ONLINE-ONLINE
VPP (Vector Packet Processor), ONLINE- VPP (Vector Packet Processor), ONLINE-
ONLINE ONLINE
data plane, ONLINE-ONLINE basic setup, ONLINE-ONLINE
endpoint support, ONLINE- IPv4 L3VPN service, ONLINE-
ONLINE ONLINE
headend support, ONLINE- IPv6 L3VPN service, ONLINE-
ONLINE ONLINE
linux-cp control plane integration point-to-point L2VPN service,
plug-in, ONLINE-ONLINE ONLINE-ONLINE
pps (packets per second), underlay connectivity, ONLINE-
ONLINE-ONLINE ONLINE
vector packet processing graph, operator-defined algorithm, 74–75
ONLINE-ONLINE optical transport network (OTN),
open-source SRv6 lab deployment 73–74
L3VPN interoperability, ONLINE- OSPF (Open Shortest Path First). See also
ONLINE SR-MPLS, OSPF; SRv6, OSPF
Cisco Catalyst 8000V Edge IPv4 ABR (area border router), 224, 229
L3VPN service, ONLINE- areas, 224
ONLINE
extensions for segment routing (RFC
FRR IPv4 L3VPN service, 8665), 64
ONLINE-ONLINE
Adj-SID sub-TLV, 68–69
Linux SRv6, ONLINE-ONLINE
Prefix Range TLV, 72–73
Containerlab, ONLINE-ONLINE
Prefix-SID sub-TLV, 70–71
Layer 3 overlay services, ONLINE
Segment Routing Algorithm TLV,
Linux IPv4 L3VPN service, 65
ONLINE-ONLINE
SID/Label Range TLV, 65–66
Linux IPv4/IPv6 L3VPN service,
SRLB TLV, 66–67
ONLINE-ONLINE
SRMS Preference TLV, 67
Linux IPv6 L3VPN service,
ONLINE-ONLINE LSA (link-state advertisement), 224
Linux point-to-point L2VPN shortest path tree, 224
service, ONLINE-ONLINE SPF (Shortest Path First) algorithm, 224
overlay services VPN-1, ONLINE- verifying Prefix SID assignment, 235
ONLINE OSPFv3, 225
overlay services VPN-2, ONLINE- route filtering, 225
ONLINE
route summarization, 225
overlay services VPN-3, ONLINE-
ONLINE overlay, 1018
underlay connectivity, ONLINE- overload bit, IS-IS, 223
ONLINE
1132 P router

P End.B6.Encaps.Red behavior,
143–144
End.B6.Insert behavior, 144–145
P router, 6
End.B6.Insert.Red behavior,
path attribute. See also BGP
145–146
BGP Prefix SID, 609–610
endpoint behaviors, 141, 146
MP_REACH_NLRI, 608–609
headend behaviors, 132, 140
path divergence, 788–789
H.Encaps behavior, 132–133
pcap trace command, ONLINE-ONLINE
H.Encaps.L2 behavior, 135
PCE (path computation element), 211
H.Encaps.L2.Red behavior,
PE router, 5, 606, 767–768 136–137
RTC (route target constraint), 768–771 H.Encaps.Red behavior, 133–135
configuration, 771–774 H.Insert behavior, 138–140
memberships, 769 POP operation, 14
verification, 774–780 pps (packets per second), ONLINE-
Penultimate Segment Pop, 127–128 ONLINE
per-ESI Ethernet A-D route, 454–458 Prefix Attribute Flags sub-TLV, 178–179
per-EVI Ethernet A-D route, 458–463 prefix metric, Flex Algo, 303
PHP (penultimate hop popping), 39 Prefix Range TLV, 72–73
PIC (Prefix Independent Convergence), Prefix SID, 76–77, 226
943, 944–945 BGP, 324
PIC Edge configuration, 324–326
multipath verification, SRv6, 981–995 enabling in an SR-MPLS network,
unipath 376–383
SR-MPLS, configuration, 948–951 proxy, 383–387
SR-MPLS, verification, 951–962 verification, 327–328
SRv6, configuration, 962–970 verifying, 235–236
SRv6, verification, 970–981 Prefix SID TLV, 95
ping command, 249, 254, 270, 292, 349, Prefix-SID sub-TLV, 58–59, 70–71
423, 635, 676, 767, ONLINE-ONLINE, primary path, 18
ONLINE-ONLINE, ONLINE-ONLINE,
program counter, 35
ONLINE-ONLINE, ONLINE-ONLINE
protocol ID, BGP, 96
ping ethernet cfm domain service
command, 815 pseudowire, 3, 11–12, 27, 440
pipeline, 1101–1104 P-space, 881–882, 896–897
PLE (private line emulation), 1011–1017 PT (Path Tracing), 784, 787, 798–801,
1023–1025
PLR (point of local repair), 878–879
MCD (Midpoint Compressed Data),
policy
800–801
segment routing, 38–40, 41, 52–53
probe packets, 801–806
SRv6, 126
PUSH operation, 14, 41
End.B6.Encaps behavior, 142–143
 RR (route reflector) 1133

Q-R RIB (Routing Information Base), 10, 12,

858
RLFA (Remote Loop-Free Alternate),
QoS, end-to-end, 21–22 880–882
Q-space, 881–882, 896–897 RONs (routed optical networks),
RD (route distinguisher), 17 1008–1011
reachability route filtering, OSPFv3, 225
SR-MPLS, verification, 248–249, route leaking, IS-IS, 223
253–254 route propagation, IS-IS, 223
SRv6, verification, 270 route summarization. See also
UPA (Unreachability Prefix summarization
Announcement), 293–295 OSPFv3, 225
configuration, 295–298 SRv6, 172–175
verification, 298–301 Route Type 1
resource assurance, 1062–1063 per-ESI Ethernet A-D route, 454–458
RFC 4385, 26, 27 per-EVI Ethernet A-D route, 458–463
RFC 4760, 84 Route Type 2, 463–466
RFC 5036, 11 Route Type 3, 467–469, 512
RFC 5357, 785 Route Type 4, 470–472
RFC 6391, 26 routed SID, 110–111
RFC 6513, 3 router
RFC 6790, 26, 26 area border, 5, 38, 224
RFC 7432, 449, 454 autonomous system border, 5, 20
RFC 7855, 40–41 CE (customer edge), 5, 6
RFC 8317, 552 IS-IS, 222
RFC 8402, 87–88 label edge, 5
RFC 8667, IS-IS extensions for segment label switch, 5
routing, 53–57, 256
P (provider), 6
RFC 8668, 48, 93
PE (provider edge), 5, 606, 767–768
RFC 8754, 123–132
PLR (point of local repair), 878–879
RFC 8762, 785
P-space, 881–882, 896–897
RFC 8986, 107, 111
Q-space, 881–882, 896–897
RFC 9085, 87–95
Router Capability TLV, 54–57
RFC 9086, 95–98
routing, inter-AS, 21
RFC 9252, 186–201
RPD (routing policy database), ONLINE-
RFC 9350, 74 ONLINE, ONLINE-ONLINE
RFC 9352, 175–186 RR (route reflector), 6
RFC 9356, 48 RTC (route target constraint), 768–771
RFC 9417, 1020 configuration, 771–774
memberships, 769
1134 RR (route reflector)

verification, 774–780 transport-related. See transport-related

RSVP-TE, 22–23 service assurance
limitations, 23–24 service catalog, 1063
tunnel, 22–23 service chaining, 213
RT (route target), 17–18, 389, 390 service label, 14, 16
RTC (route target constraint), 768–771 service orchestration, 1064
configuration, 771–774 service portfolio consolidation,
1083–1084
memberships, 769
service provider/s
verification, 774–780
benefits of SRv6 adoption, 998–999
network evolution, 210–212
S PE (provider edge) routers, 606. See also
PE router
SAP (service access point), 1058–1059
technological opportunities and benefits
scalability, 220 of SR
SDN (software-defined networking), CapEx savings, 1026–1029
28–29
fewer protocols, 999–1001
segements, 36
integrated visibility, 1017–1018
Segment Routing Algorithm sub-TLV,
more QoS options, 1001–1003
55–56
new hardware generation, 1025
Segment Routing Algorithm TLV, 65
OpEx savings, 1030–1032
Segment Routing Capability sub-TLV,
54–55 PLE (private line emulation),
1011–1017
segment-routing mpls sr-prefer command,
361 RONs (routed optical networks),
1008–1011
sensors, IoT, 37
scale, 1007–1008
service assurance, 783, 1062–1063
traffic engineering and network
L2VPN, 806–807
slicing, 1005–1007
CFM (Ethernet Connectivity
unification across domains,
Fault Management),
1003–1005
808–816. See also CFM
(Ethernet Connectivity Fault service vpp status command, ONLINE-
Management) ONLINE
ITU-T Y.1731 Performance service vpp stop command, ONLINE-
Measurement. See ITU-T Y.1731 ONLINE
Performance Measurement show bfd ipv6 session command,
L3VPN, 834 868–869
IPSLA, 834. See also IPSLA show bfd ipv6 session interface bundle-
Ether 1 detail command, 869
TWAMP, 835–836. See also
TWAMP (Two-Way Active show bfd ipv6 session interface TF0/0/0/0
Measurement Protocol); detail command, 870–871
TWAMP Light show bfd neighbors command, 877
 show cef vrf detail command 1135

show bfd neighbors interface port-channel show bgp vpnv4 unicast vrf command,
1 details command, 877–878 626, 628–630, 646–647, 649–650,
show bfd session command, 875 651–652, 655, 659–661, 663,
667–668, 670, 673–674, 702–703,
show bfd session interface bundle-ether 1
704–705, 705–706, 733–735,
detail command, 875–876
758–759, 760, 951–953, 954,
show bgp ipv4 labeled-unicast command, 958–960, 971–973, 976–977,
347, 348, 377–378, 379–381, 713, 982–984, 989–990
740–741
show bgp vpnv4 unicast vrf local-sids
show bgp ipv4 rt-filter command, 771, command, 627, 647–648, 663–664,
774 671
show bgp ipv4 rt-filter neighbors show bgp vpnv4 unicast vrf received-sids
command, 774–775 command, 627–628, 648, 664, 671
show bgp ipv4 unicast command, 328, show bgp vrf command, 276, 320–321,
348, 713–714 409–410, 420–421
show bgp ipv4 vpn command, ONLINE- show bgp vrf nexthop-set command, 634,
ONLINE 650, 667
show bgp l2vpn evpn bridge-domain show bgp vrf-db table all command,
200-BD command, 527–529 519–521, 594
show bgp l2vpn evpn bridge-domain show bgp vrf-db table command,
200-BD received-sids wide command, 566–567, 656
523–524
show bpg vpnv4 unicast vrf command,
show bgp l2vpn evpn bridge-domain 665–666
command, 446, 521–522, 525–527,
show bundle bundle-Ether 200 command,
537, 540, 549–550, 568–569
478, 484
show bgp l2vpn evpn bridge-domain
show bundle bundle-Ether 250 command,
VPWS:300 command, 594–599
481, 482
show bgp l2vpn evpn rd command,
show bundle bundle-Ether 300 command,
458–461, 464, 467–469, 470, 523,
575–576
601
show cef command, 887–888, 892–893,
show bgp l2vpn evpn route-type
898–899, 919, 926
command, 530
show cef detail command, 714–715, 716,
show bgp l2vpn evpn route-type ethernet-
717–718, 743, 744–745, 747, 748,
segment command, 530–532, 600
749–750
show bgp l2vpn evpn summary command,
show cef ipv6 command, 904–905,
518–519
908–909, 912–913, 936–937,
show bgp segment-routing srv6 937–940, 942
command, ONLINE-ONLINE
show cef ipv6 detail command, 980–981,
show bgp summary command, ONLINE- 993–994
ONLINE
show cef vrf command, 276, 279
show bgp vpnv4 uni vrf command,
show cef vrf detail command, 632–633,
ONLINE-ONLINE
654, 669–670, 675, 709–711, 738,
show bgp vpnv4 unicast command, 764, 766, 955–957, 960–962,
741–742 974–975, 979, 986–988, 991–992
1136 show ethernet cfm local meps domain service command

show ethernet cfm local meps domain show ip ospf database command, 234
service command, 813 show ip route repair-paths command,
show ethernet cfm peer meps domain 888–889, 893, 899–900, 928,
service command, 814–815 954–955
show ethernet sla operations detail profile show ip route vrf command, 737, 762
command, 820–821, 827–828 show ip route vrf repair-paths command,
show ethernet sla statistics brief profile 709
command, 821–823, 829–830 show ipsla statistics 11 command,
show ethernet sla statistics detail profile 843–844
command, 823–825, 831–834 show ipsla statistics 21 command,
show evpn ethernet-segment command, 844–846
494, 580 show ipsla statistics aggregated 11
show evpn ethernet-segment interface command, 846–847
BE200 carving detail command, show ipsla statistics aggregated 21
496–498 command, 847–850
show evpn ethernet-segment interface show ipsla twamp session command, 854
BE300 carving detail command,
show ipv6 cef command, ONLINE-
581–582
ONLINE
show evpn ethernet-segment interface
show ipv6 route isis command, ONLINE-
Bundle-Ether260 detail command,
ONLINE
538–539
show isis adjacency command, 265–266
show evpn evi command, 498, 540–542,
583–584 show isis database command, 233, 247,
257, 265, 272, 288, 291, 299,
show evpn evi ead command, 501,
309–310
584–585
show isis fast-reroute summary command,
show evpn evi inclusive-multicast detail
884
command, 502–503
show isis fast-reroute ti-lfa tunnel
show evpn evi vpn 200 mac command,
command, 894, 900, 929
501–502
show isis flex-algo command, 308
show evpn evi vpn 205 mac command,
560–561 show isis ipv4 fast-reroute detail
command, 887, 892, 898, 904, 918,
show evpn evi vpn-id 200 detail
920–921, 925, 927–928, 933–934
command, 499–500
show isis ipv6 fast-reroute detail
show evpn summary command, 493–494
command, 908, 912
show interfaces brief command, 477–478,
show isis neighbor command, ONLINE-
483, 574–575, ONLINE-ONLINE
ONLINE
show ip cef detail command, 715, 717,
show isis rib command, 929–930
718, 744, 745–746, 749
show isis srv6 locators det command,
show ip cef internal command, 889–890,
ONLINE-ONLINE
894–895, 900–901, 930–931
show l2vpn bridge-domain bd-name 200-
show ip cef vrf command, ONLINE-
BD detail command, 508–510
ONLINE
show l2vpn bridge-domain bd-name detail
show ip cef vrf detail command, 711, 739,
command, 563–565
765, 957
 SID (segment identifier) 1137

show l2vpn bridge-domain brief show segment-routing srv6 locator

command, 508, 511, 544 command, ONLINE-ONLINE,
show l2vpn forwarding bridge-domain ONLINE-ONLINE
ELAN-BG:200-BD mac-address show segment-routing srv6 locator MAIN
location 0/RP0/CPU0 command, detail command, ONLINE-ONLINE
510–511 show segment-routing srv6 locator MAIN
show l2vpn forwarding bridge-domain sid command, 513–514, 546–547
ELAN-BG:210-BD mac-address show segment-routing srv6 sid command,
location 0/RP0/CPU0 command, 545 503–504, 586, ONLINE-ONLINE,
show l2vpn forwarding xconnect detail ONLINE-ONLINE
location command, 591 show segment-routing srv6 sid detail
show l2vpn mac-learning command, 512 command, 633, 634–635, 656
show l2vpn mac-learning mac all location show segment-routing traffic-eng policy
command, 511 command, 274–275
show l2vpn xconnect group VPWS-XC show slrg name command, 932
command, 589–591 show sr localsids command, ONLINE-
show lacp bundle-Ether 250 command, ONLINE, ONLINE-ONLINE
481, 482 show sr policies command, ONLINE-
show lacp command, 479–480, 576–577 ONLINE
show memif command, ONLINE-ONLINE show sr steering-policies command,
show mpls forwarding command, 362, ONLINE-ONLINE
364, 374 show trace command, ONLINE-ONLINE,
show mpls oam dpm adjacency command, ONLINE-ONLINE, ONLINE-ONLINE
797 SID (segment identifier), 36–37,
show mpls oam dpm prefix command, 42–43
797 Adjacency, 47–49, 226
show mpls oam dpm summary command, allocation, 43–44, 115
795–796 anycast, 45, 47, 219
show route 10.0.1.8/32 command, BGP Peering, 50–52
886–887
BGP Prefix, 49–50, 85–87
show route command, 891, 896–897,
Binding Segment, 52–53
917–918, 924–925
block addressing considerations,
show route ipv6 command, 280–281,
163
282, 289, 290, 291–292, 300,
311–312, 903–904 compression, 161–162
show route ipv6 detail command, Node, 38–39
906–907, 911–912 Prefix, 45–47, 76–77
show route vrf command, 278 SRv6, 107–108, 183–186
show route vrf detail command, 631–632, End behavior, 113–114
653–654, 668–669, 674–675, 708, End.DT2M behavior,
736, 761, 762–763, 973–974, 122–123
977–978, 985–986
End.DT2U behavior, 120–121
show segment-routing srv6 capabilities-
parameters command, ONLINE- End.DT4 behavior, 116–117
ONLINE
1138 SID (segment identifier)

End.DX2 behavior, 119 BGP Link-State extensions, 87–95

End.DX4 behavior, 117–118 business case guidance, 1032–1034,
endpoint behaviors, 1113 1036–1037
End.X behavior, 114–115 opportunity analysis, 1037–1038
Locator field, 108–110 refining known CapEx,
1034–1035
routed/nonrouted, 110–111
refining known OpEx, 1035–1036
verification, 266–270
data plane, 36–37
SID/Label Binding TLV, 61–62
domain, 38
SID/Label Range TLV, 65–66
enabling
SID/Label sub-TLV, 63–64
on IOS XE, 230
SID/Label TLV, 91
on IOS XR, 230
SLA (service-level agreement), 783–784,
806 endpoint/egress node, 38
SLM (synthetic loss measurement), 816 EPE (egress peer engineering), 41
configuration, 826–827 feature support, 215
verification, 827–834 header, 106–107
SLRG (shared risk link group), 921. See IETF standards, 39, 40
also TI-LFA (Topology-Independent IS-IS extensions (RFC 8667), 53–54
Loop-Free Alternate), SLRG protection Adj-SID sub-TLV, 59–61
SmartNICs, ONLINE Flex Algo sub-sub-TLVs, 79–83
software-defined networking, 28–29 LAN-Adj-SID sub-TLV, 61
SONiC (Software for Open Networking in Prefix-SID sub-TLV, 57–59
the Cloud), ONLINE-ONLINE
Router Capability TLV, 54–57
cli, ONLINE
Segment Routing Algorithm sub-
container modules, ONLINE-ONLINE TLV, 55–56
data plane, ONLINE SID/Label Binding TLV, 61–62
disaggregation, ONLINE-ONLINE SID/Label sub-TLV, 63–64
sonic-cfggen, ONLINE SRLB sub-TLV, 56–57
system architecture, ONLINE-ONLINE network as a computer, 37
source code repository, 1098–1100 OSPF extensions (RFC 8665), 64
source node, 126 Adj-SID sub-TLV, 68–69
source routing, 35–36 Prefix Range TLV, 72–73
source/ingress node, 38 Prefix-SID sub-TLV, 70–71
SPF (Shortest Path First) algorithm, 56, Segment Routing Algorithm TLV,
73–74, 220, 224 65
SPRING architecture, 40–41 SID/Label Range TLV, 65–66
SR (segment routing), 225. See also SRLB TLV, 66–67
SR-MPLS
SRMS Preference TLV, 67
adjacency segment, 226
policy, 38–40
benefits, 212–214
policy/ies, 41, 52–53
 SR-MPLS 1139

replacing or enhancing a legacy network BGP proxy Prefix SID, 383–387

with. See also legacy network enabling LDP on the border node,
IT evolution and gap awareness, 372–376
1051–1056 enabling SRMS, 365–372
migration strategy, 1049–1051 enabling the BGP Prefix SID,
required knowledge and expertise, 376–383
1046–1049 configuration, 228–229
SID (segment identifier), 36–37 assign the prefix SID, 230–231
source/ingress node, 38 enable segment routing, 230
SPRING architecture, 70–77 reconfiguring the SRGB/SRLB,
transit node, 38 229
SR-DPM (Segment Routing Data Plane control plane, 207–209, 243–244
Monitoring), 784, 788–789 data forwarding, 341–342
adjacency verification and validation, data plane, 41–42, 207–209
790–792
enabling in an existing network
configuration, 789–790 (coexistence), 358–360
prefix reachability verification, 793–798 enabling and preferring on P1, P2,
SRGB (segment routing global block), and PE-1, 363–365
44–45, 226–227 enabling on P2, P3, and PE-3,
reconfiguring, 229 360–363
verifying, 232–234 Flex Algo, 322–324
SRH (segment routing header), 36–37, IS-IS, 244–246
123–124, 125–127, 147 configuration, 246
fields, 124–125 verification, 247–249
Penultimate Segment Pop, 127–128 L3VPN overlay service, 677–679
Ultimate Segment Pop, 129 BGP label allocation modes, 701
USD (Ultimate Segment Decapsulation), configuration, 679–685
130–132
extranet, configuration, 752–756
uSID instruction, 147–148
extranet, verification, 756–767
SRLB (segment routing local block), 45,
full-mesh, configuration, 689–700
227–228
full-mesh, verification, 701–719
reconfiguring, 229
hub-and-spoke, configuration,
verifying, 232–234
719–732
SRLB sub-TLV, 56–57
hub-and-spoke, verification,
SRLB TLV, 66–67 732–751
SR-MPLS, 41 verification, 686–688
addressing, 227 label, collisions, 43
anycast SID, 254–255 LSD (label switching database), 43
configuration, 254–256 migration to segment routing, 358
verification, 256–257 OSPF, 250
building a new network, 365
1140 SR-MPLS

configuration, 250 control plane, 209–210, 257

verification, 250–253 data plane, 209–210
Prefix SID, 45–47 endpoint node, 126
reachability, verification, 248–249, Flex Algo, 301. See also Flex Algo
253–254 hardware and software support, 214
SID (segment identifier), 42–43 interface loopback address, 237–238
Adjacency, 47–49 IS-IS, 257–260
allocation, 43–44 anycast SID, 270–271
anycast, 47 anycast SID configuration, 271
BGP Peering, 50–52 anycast SID use case, 272–282
BGP Prefix, 49–50 anycast SID verification, 272
Binding Segment, 52–53 configuration, 260–265
Node, 45–46 reachability verification, 270
sub-TLVs, 57–61 summarization, 282–285
SRGB (segment routing global block), summarization configuration,
44–45 286–287
SRLB (segment routing local block), 45 summarization verification,
verify the SRGB and SRLB, 232–234 287–292
verifying the Prefix SID assignment, UPA (Unreachability Prefix
235–236 Announcement), 293–295
SRMS (segment routing mapping server), UPA configuration, 295–298
365–372 UPA verification, 298–301
SRMS Preference TLV, 67 verification, 265
SR-PM (Segment Routing Performance verify the SIDs, 266–270
Measurement), 784
verifying IS-IS adjacency,
end-to-end delay measurement of any 265–266
endpoint, 786
verifying the database, 266
end-to-end SR policy delay measurement,
IS-IS extensions (RFC 9352), 175–176
785–786
segment routing over IPv6
end-to-end SR policy liveness detection,
capabilities, 180–183
787
segment routing over IPv6 locator,
link delay measurement, 785
176–180
PT (Path Tracing), 787
SIDs, 183–186
SRv6, 29–30, 103, 213–214, 601,
IWG (interworking gateway), 389–390
ONLINE-ONLINE
L3VPN overlay service, 608. See also
BGP link-state extensions, 201–205
full-mesh L3VPN
building a new network
BGP Prefix SID path attribute,
using an IWG, 389–401 609–610
using dual-connected PE devices, extranet, configuration, 657–662
413–424
extranet, verification, 662–677
using inter-AS Option A, 401–413
full-mesh, configuration, 610–625
 standards 1141

full-mesh, verification, 625–636 End.X behavior, 114–115

hub-and-spoke, configuration, Locator field, 108–110
636–645 routed/nonrouted, 110–111
hub-and-spoke, verification, source node, 126
645–657
SRH, 125–127
MP_REACH_NLRI path attribute,
fields, 124–125
608
Penultimate Segment Pop,
NLRI, 608
127–128
locator addressing scheme, 165–169
Ultimate Segment Pop, 129
large-scale deployments, 170–172
USD (Ultimate Segment
small- and medium-scale Decapsulation), 130–132
deployments, 169–170
standards, 103
MP-BGP extensions, BGP overlay
summarization, 172–175
services, 186–201
transit node, 126
open-source. See open-source SRv6
uSID (micro SID), 236, 239
policy, 126
allocation, 236–237
End.B6.Encaps behavior, 142–143
globally significant, 150–151
End.B6.Encaps.Red behavior,
143–144 instruction extension, 147–150
End.B6.Insert behavior, 144–145 locally significant, 150–151
End.B6.Insert.Red behavior, locator addressing scheme,
145–146 238–239
endpoint behaviors, 141, 146 routed/nonrouted, 151
headend behaviors, 132, 140 uA endpoint variants, 156–160
H.Encaps behavior, 132–133 uN endpoint variants, 152–155
H.Encaps.L2 behavior, 135 verification, 241–242
H.Encaps.L2.Red behavior, uSID configuration, 239
136–137 enable SRv6 uSIDs, 239–240
H.Encaps.Red behavior, 133–135 modify SRv6 parameters, 240
H.Insert behavior, 138–140 VPNv6 services, 194–195
SID (segment identifier), 107–108 SRv6 BGP PeerNode SID TLV, 205
block addressing considerations, SRv6 End SID sub-TLV, 179
163 SRv6 End.X SID sub-TLV, 183–185
compression, 161–162 SRv6 Locator TLV, 177–178
End behavior, 113–114 SRv6 Service Data sub-sub-TLV, 188–189
End.DT2M behavior, 122–123 SRv6 SID Information sub-TLV, 188
End.DT2U behavior, 120–121 stakeholder testing, 1088
End.DT4 behavior, 116–117 standards
End.DX2 behavior, 119 segment routing, 39, 40
End.DX4 behavior, 117–118 SRv6, 103
endpoint behaviors, 1113
1142 stitching RT

stitching RT, 390 automation, 1094

sub-sub-TLV, 79–80 development, 1091
Flex Algo, 79–83 integration, 1080, 1091
SRv6 IS-IS, 185–186 migration, 1096
SRv6 Service Data, 188–189 stakeholder, 1088
sub-TLV unit, 1079, 1087
Adj-SID, 59–61, 68–69 TI-LFA (Topology-Independent Loop-Free
Flexible Algorithm Definition, 78–79 Alternate), 883
IS-IS Flexible Algorithm Definition, combined SRLG and node protection,
77–79 934
LAN-Adj-SID, 61 link protection
Prefix Attribute Flags, 178–179 configuration, 883–885
Prefix-SID, 58–59, 70–71 SR-MPLS verification, 885–902
Segment Routing Algorithm, 55–56 SRv6 verification, 902–914
Segment Routing Capability, 54–55 node protection
SID/Label, 63–64 configuration, 914–917
SRLB, 56–57 SR-MPLS verification, 917–919
SRv6 End SID, 179 SRv6 verification, 919–921
SRv6 End.X SID, 183–185 tiebreakers, 916
SRv6 Locator, 176–177 SLRG protection
SRv6 SID Information, 188 configuration, 921–923
summarization, 220 SR-MPLS verification, 923–931
IS-IS, 172–175, 282–285 SRv6 verification, 931–948
OSPFv3, 225 time/timer, 857–858
SWAP operation, 14 EVPN E-LAN port-active MHD EVPN,
491
synchronization, LDP–IGP, 24
failure event detection, 858
systemctl restart frr command, ONLINE-
ONLINE network event information propagation,
858
topology update and repair path
T computation, 858
TLV (type length value), 53. See also ISIS;
tcpdump, ONLINE-ONLINE OSPF; sub-sub-TLV; sub-TLV
TDP (Tag Distribution Protocol), 1. See L2 Bundle Member Attributes, 93
also LDP (Label Distribution Protocol)
Prefix Range, 72–73
TE (traffic engineering), 35–36, 38, 41,
Prefix-SID, 95
210, 213
Router Capability, 54–57
teams, 1082–1083. See also domain
Segment Routing Algorithm, 65
test/ing, 1067, 1080, 1086, 1088, 1097
SID/Label, 91
acceptance, 1085, 1087
 VPN 1143

SID/Label Binding, 61–62

SID/Label Range, 65–66
U
SRLB, 66–67 ULA (unique local address), 162
SRMS Preference, 67 Ultimate Segment Pop, 129
SRv6 BGP PeerNode SID, 205 underlay connectivity, 1018
SRv6 Locator, 177–178 Linux SRv6, ONLINE-ONLINE
topology VPP (Vector Packet Processor), ONLINE-
definition, ONLINE ONLINE
update and repair path computation time, Unified MPLS, 210
858 unified MPLS network migration,
traceroute command, 249, 254, 312, 342, 430–432
362–363, 364–365, 375–376, 382, unit test, 1079, 1087
383, 412, 423, 645, 677, 718–719,
750–751, 767 unsolicited downstream, 11

traceroute ethernet cfm domain service UPA (Unreachability Prefix

command, 816 Announcement), 293–295

traffic blackholing, 788 configuration, 295–298

Traffic Class field, IPv6 header, 104 verification, 298–301

traffic load balancing, 798–799 update packing, 190–191

transit node, 38, 126 USD (Ultimate Segment Decapsulation),

130–132
transport-related service assurance
uSID (micro SID), 36–37, 147–149, 236,
PT (Path Tracing), 784, 787, 798–801, 239
1023–1025
allocation, 236–237
MCD (Midpoint Compressed
Data), 800–801 configuration, 239

probe packets, 801–806 endpoint behaviors, 149–150

SR-DPM (Segment Routing Data Plane F3216 format, 148

Monitoring), 788–789 globally significant, 150–151
adjacency verification and locally significant, 150–151
validation, 790–792 locator addressing scheme, 238–239
configuration, 789–790 SRv6 configuration
prefix reachability verification, enable SRv6 uSIDs, 239–240
793–798
modify SRv6 parameters, 240
TTL (Time to Live), 7
verification, 241–242
tunnel, RSVP-TE, 22–23
uA endpoint variants, 156–160
TWAMP (Two-Way Active Measurement
uN endpoint variants, 152–155
Protocol), 306–307, 835–836
TWAMP Light, 785
configuration, 851–853 V
verification, 853–854
VPLS (Virtual Private LAN Service), 440
VPN, 20
1144 VPN

extranet, 657 underlay connectivity, ONLINE-

intranet, 657 ONLINE
MPLS, operational complexity, 22 linux-cp control plane integration plug-
in, ONLINE-ONLINE
VRF (virtual routing and forwarding),
17–18 pps (packets per second), ONLINE-
ONLINE
VPP (Vector Packet Processor), ONLINE-
ONLINE vector packet processing graph,
ONLINE-ONLINE
data plane, ONLINE-ONLINE
VPWS (Virtual Private Wire Service),
DPDK, ONLINE-ONLINE
440
endpoint support, ONLINE-ONLINE
VRF (virtual routing and forwarding),
headend support, ONLINE-ONLINE 17–18, 605, 606
lab deployment, ONLINE-ONLINE VRF instance, 3, 38, 5
basic setup, ONLINE-ONLINE vytish, ONLINE-ONLINE
IPv4 L3VPN service, ONLINE-

W-X-Y-Z
ONLINE
IPv6 L3VPN service, ONLINE-
ONLINE
wildcard, *, 1112
point-to-point L2VPN service,
ONLINE-ONLINE